Tip for anyone presenting a new programming language, IMHO: include a 10-to-20 line program on the front page to give people a quick idea of what it looks like.
After a few clicks, I think I found the "Hello World" example,
begin-handler /hello-world public
get-param name
@This is Hello World from <<p-out name>>
end-handler
That isn't the sense I get from the example. It shows an entire user-facing web application being written in this language, with every indication that the author thinks this is an appropriate use case.
Gliimly is a very high-level modeling language. It's about solving problems by modeling the solution and connecting the components to create high-performance, low-footprint executables; and not about managing memory, manipulating bits and bytes or writing complex code.
Syntax matters
Syntax of a language matters, not just for writing code now, but for someone else reading it years later. Gliimly language is designed to be intuitive, easy and rapid in use on both ends, and to be close to the way humans are wired, rather than machines.
Language
Gliimly programming language is memory-safe, meaning it will prevent you from accidentally overwriting memory or freeing it when it shouldn't be. Gliimly's memory-handling is not limited to just memory safety; it also includes automatic freeing of memory at the end of a request, preventing memory leaks which can be fatal to long running processes. Similarly, files open with file-handling statements are automatically closed at the end of each request, serving the same purpose.
Types
Gliimly is a strongly-typed language, with only three primitive types (numbers, strings and booleans) and a number of structured types (message, split-string, array, index, index-cursor, fifo, lifo, list, file and service). Gliimly is a declarative language, with a few lines of code implementing large functionalities. Gliimly is also very simple - it does not even have expressions! That's because it's designed to achieve application goals with less coding.
Gliimly statements are designed for safety, ease of use, and ability to write stable code. Most statements typically perform common complex tasks with options to easily customize them; such options are compile-time whenever possible, increasing run-time performance.
It's interesting, something to look into. It's not a general purpose language, true, and I think that's a good thing. General purpose languages are too broad for the topic of web services. It's like when SQL came out long ago to make database programming specialized. I think we need something like that for web services, and Gliimly may be a good step forward.
Yeah I meant that in a good way. You can build powerful stuff with a DSL that doesn't include the normal imperative programming constructs that most general purpose programming languages, but also some specialized programming languages like bash, include. jq is a nice alternative to python for sifting through JSON for many things.
I think glimly is an interesting project but I wonder why they don't use something like mustache ({{ param1 }} for escaped and {{{ param2 }}} for unescaped) instead of p_web
The criticism wasn’t only about how limited the DSL was — it was about how some of the design choices are repeating patterns which are very common sources of security defects. HTML and SQL are DSLs themselves and have non-trivial security contexts.
Most of the offered cryptographic primitives (encrypt-data[1], decrypt-data[2], derive-key[3]) are not easy to use correctly.
The encrypt/decrypt data interface uses AES-256-CBC with (seemingly) no authentication, and the key derivation uses PBKDF2 with default iterations of 1000 and vague instructions on which value to choose. No interface to a memory-hard KDF is available.
This, along with the notion of memory safety from untested C code doesn't really instill a sense of confidence in me...
I would suggest throwing away all the cryptographic primitives you currently have and instead interface with libsodium, which is a library designed for the rest of us non-cryptographers.
The only owner of this project is "Gliim LLC" and it's written in C with cryptic commit messages. This looks dangerous. If this is an honest project and not an attempt to inject malware into other people's projects, you should:
- Say who you are.
- Commit as individuals, not as the company.
- Explain how this is memory safe. The C language makes that seem very unlikely.
Pasting the e-mail address into a search engine reveals another work by the same person. In particular, https://vixra.org/pdf/1208.0044v2.pdf . The fact the person publishes under Vixra likely means they are not someone malicious, just what some in the mathematics community call a "crank".
Another term for it would be "fringe science". The paper is an amusing thought experiment based on some baseless assumptions; it would be foolish to assume that it describes any kind of physical reality.
Does personal identification make someone more trustworthy? IMO trust comes from history. I.e. maintaining a project for a long time, working on multiple projects, various contributions, then external factors like community, committers + number of eyes on the code.
I see it is implemented in C. Doesn't this add a substantial attack surface, especially relevant for web services? How is the "memory-safe" claim justified?
There is a pervasive, cultural lack of formal verification in software, and it's risky, terrible, and should be stopped. Formal verification can takes multiple forms and operates at different spans across the layers of the stack. We need more of it to prove the correctness of compilers, libraries, and programs. It is a lot of work, but it's critical to proving things are as good, as say, seL4.
Yes, it opens a large attack surface for a group of people who thinks “memory-safe” is only possible when that word appears on the top of a language’s features list.
The phrase "programming language for web services" remind me of Borland Charlotte language introduced 20 years ago. Those days the term web services means SOAP, however. :)
> Some people get it in their heads that their commit history needs to be "clean". It doesn't...
If by "clean" you mean "readable" (in the literate-programming sense), then I'd be a strong advocate of that.
I would like to one day see a repo that is maintained in such a way that, if you just dump out the commits in chronological order (e.g. `git log --patch --reverse --pretty=format:"%s"`), the result is essentially a jupyter notebook that explains the system being built as it builds it.
Such a thing would require a lot of rebasing, of course.
I think this repo is clearly the result of "development in private", but I don't think the commit messages here were "cleaned up." I think this is just this person's way of using git in a single-user context — they just want to incrementally save WIPs, so they number them. (Maybe they even use an editor plugin that does this for them on save, or through a keyboard-shortcut.)
That being said, I do sometimes also see this in the cases of private repos that were so messy and fraught, with long-lived now unmergeable feature branches, that the best way to integrate everything was to just convert each long-lived branch into a set of .patch files; manually prune and edit those .patch files in a text editor; and then `git am` each patchset into a synthetic commit. Those commits don't really have coherent purposes — they're just incremental steps of a single long integration — so you may as well just number them. (Usually, though, people rebase-squash these all once they're done.)
Which, if the case, is even more awful. Now to understand the change history, I need to consult/cross-reference some documentation page that might 404 in the future. Additionally, the releases have many un-related changes grouped together (as one would expect for a release, not a commit).
Lately I've become fond of the squash-merge. All development is in a branch, and to merge you open a Pull Request (or equivalent on whatever platform you use). The PR gets squashed into one commit that references the original PR, which retains all of the commit history and discussion/review comments. Best of all worlds in my opinion, and frees developers to commit freely without consequence or care.
Just to comment on your last paragraph - I don't really understand people's obsession with having squashed commits on main. I may not have a local copy of the branch that was merged months ago, so I can't get the un-squashed history without jumping through hoops. It also makes tools like git-bisect much less useful.
With my team, once you are done with your PR, you do a quick rebase pass over your branch and squash any remaining partial/in progress/fixup commits into a final set of meaningful logical commits - this set gets merged into mainline wholesale, without any further squashing.
Each commit has the ticket id in the commit message, so you can find all related changes easily if ever needed. This gives us history that's both granular enough to be useful, and meaningful.
(Granted, if your team is disciplined enough to only have very small and granular PRs that only deliver a small logical unit of change at a time, the distinction between approaches becomes moot... but in my experience most PRs tend to be a little bigger that that, and contain at least a couple of related but distinct sets of changes)
And yeah, the commit history in this project is just hilarious.
> With my team, once you are done with your PR, you do a quick rebase pass over your branch and squash any remaining partial/in progress/fixup commits into a final set of meaningful logical commits - this set gets merged ...
A lack of this simple discipline is what causes people to push for squashing. If you squash every PR then your commits may be too coarse, but you don't end up with random "fix tests" commits everywhere. If it's not part of your company culture to do the cleanup then it's harder to get that rolling than to just impose a repo rule that only squash merges are allowed in.
>Some people get it in their heads that their commit history needs to be "clean". It doesn't...
I do not care about git commit history at all. Do not squash. Don't do anything other than commit, push, and merge PRs. I don't delete old branches, I don't do anything beyond the basics. I don't even use rebase. It has never bit me in the ass at all in all the years I've been running this team. The less I have to do with git, the better.
Exactly. We have a beautiful tool that can maintain an unbroken historical record without being a burden... and then we use it to rewrite history? Nooooo!!
I guess it depends on the developers and how they choose to commit. On my team we don't commit unless we're ready to push, so we aren't creating 100s of commits for every feature or bug fix. Some developers seem to think they need to commit every 2 seconds for every tiny little change. That's just seems like a waste of time to me, and it also creates the need to squash and do more stuff with git. Anything that distracts me from writing software and putting work into the code is a distraction, and git is a distraction. I don't really want to deal with git as often or as much as some developers seem to use it constantly to commit everything...
Dunno for me it's great to commit if I just made substantial work but it's not ready yet. It's assuring that my work won't be accidentally lost if I mess up. Especially it's great to commit at the end of the day or if I just wrote tests which all pass. Stuff works, I can move on, and forget about it. Next day when I write more code, and something breaks (but worked yesterday) I can easily see the diff between yesterday and today and see what changed and where I'm currently at. Commit messages remind me of what I did, step by step. Then I push to the dev environment and if QA finds bugs, I commit new changes which fix the bugs. It's also great for the reviewer - they only have to look at the single bugfix commit, the rest of the code is fine (already reviewed). I don't find a use for squashing, modern tools allow to see several commits as one diff.
> This has the appearance of "developed in private, cleansed, thrown over the wall" sort of thing.
To be honest, I do this with personal projects, and by "this" I mean I finish the project, try to polish it and "cleanse" it as much as possible, and then git commit add with message "Initial commit", and after that of course I have proper commits for bug fixes, feature additions, etc.
Commit history has to be clean just as much as code has to be clean. That is to say, it doesn't - but it's far nicer working with clean code than tangled uncommented messes.
Most of the commit messages in my personal projects say “Temp” and yet to see any issues with that. I have some repos where I maintain commit messages (by inertia) and it always bugs me as an utterly useless routine.
In the rare case when I have to investigate history, there are actual code changes and all the tools to navigate them. There’s no “read through the log to find a change” in my workflow, just like there’s no “read through code to find an identifier”.
It doesn’t mean that this works for all projects and workflows. People report their day saved by a commit message. But that blanket belief in sacred commit messages is just that. It’s not unusual to see a 1-person repo to contain synthetic messages cause under no peer pressure people act like it’s natural to them.
I tried Gliimly. I just had to after some really weird comments below that start like a gossip club and then degenerate into preferences for git commiting (like anyone cares about either). Anyway, Gliimly's simple to write code with, and without being too pedantic about what some people think "web service" or "service-oriented" means, it did what I needed it to do. That is to say, I was able to build a web application for work (insurance) pretty darn quickly, all in a REST-like structure of service calls. I am not a fan of an object oriented paradigm, though the company I work for (still) uses C++. I used to be all over it. But it's gotten so complicated that I am looking to make a 180 and find something so simple it stinks. Gliimly could be it, or not, but I like simpler. Is it safe? I did try some nasty stuff that would overwrite memory, and the program stopped with the appropriate message. I tried SQL injection and couldn't do it. So the fact it's written in C doesn't mean anything, I mean lots and lots of critical software are written in it. I haven't run into any bugs, and compiler error message were pretty descent. The performance was better than C++ for the same legacy app we have, and that's about 12x larger in terms of source code. Overall, Gliimly is something I could work with, assuming it stays, which is a big if. Most projects like this eventually lose steam unless they get some kind of sponsorship from a "consortium" of companies, but hey, some work out without that kind of backing just on their merit. Time will tell.
My first impression is that like with HTMX, it's for a style of web apps that has few uses nowadays.
The benefit of the HTML syntax quickly goes away if it has a JavaScript frontend. The routing doesn't make sense in a non-trivial app. For a non-trivial app, something more flexible like Django's routing system makes sense.
It says it's service-oriented. It doesn't have what I expect from something service-oriented in its big example, though. For instance the entry point to the app is /session/start and it doesn't route based on HTTP methods. https://gliimly.blogspot.com/2024/11/multi-tenant-saas-notes...
>My first impression is that like with HTMX, it's for a style of web apps that has few uses nowadays.
What do you mean? I see nothing common with HTMX. It feels more like old PHP5 projects, where they mixed business logic with controllers, database access and template rendering all in one big soup.
Even PHP had a composable expression syntax (e.g. nested arithmetic/string/array expressions, function calls, etc). I don't think this does; every statement seems to be a unique, standalone thing.
That may be a good thing. I think it's more natural to have it that way. I always wondered why a keyword in a programming language must have this rigid meaning. In English, that's not the case, there's a context.
Gliimly seems much simpler than PHP or other "classic" programming languages out there (C++, Java, Go, whatever). I think there's something to the idea of expressing programming closer to English, in a declarative way.
I'll give it a try, I'd love to type (much) less and just sort of "talk" programming, because that's what this looks like.
Tip for anyone presenting a new programming language, IMHO: include a 10-to-20 line program on the front page to give people a quick idea of what it looks like.
After a few clicks, I think I found the "Hello World" example,
There's a more extensive worked example at:
https://gliimly.blogspot.com/2024/11/multi-tenant-saas-notes...
And, at a glance, I see:
- HTML output being constructed by string concatenation.
- SQL queries being constructed by what looks like sprintf.
- No functions, just HTTP handlers, some of them marked as "private".
- No expression system, just non-composable commands like "hash-string" or "match-regex".
- No evidence of an object or class system.
- Some evidence of filenames with 'magical' behavior like "before-handler.gliim".
None of this fills me with confidence. This is a toy at best.
It's a lot like https://hurl.dev/ or https://jqlang.github.io/jq/ - it's an intentionally limited DSL.
I think if it were more like https://hurl.dev/ I might find it slightly more interesting.
> it's an intentionally limited DSL.
That isn't the sense I get from the example. It shows an entire user-facing web application being written in this language, with every indication that the author thinks this is an appropriate use case.
About that: https://gliimly.github.io/about-gliim.html
Modeling language
Gliimly is a very high-level modeling language. It's about solving problems by modeling the solution and connecting the components to create high-performance, low-footprint executables; and not about managing memory, manipulating bits and bytes or writing complex code.
Syntax matters
Syntax of a language matters, not just for writing code now, but for someone else reading it years later. Gliimly language is designed to be intuitive, easy and rapid in use on both ends, and to be close to the way humans are wired, rather than machines.
Language
Gliimly programming language is memory-safe, meaning it will prevent you from accidentally overwriting memory or freeing it when it shouldn't be. Gliimly's memory-handling is not limited to just memory safety; it also includes automatic freeing of memory at the end of a request, preventing memory leaks which can be fatal to long running processes. Similarly, files open with file-handling statements are automatically closed at the end of each request, serving the same purpose.
Types
Gliimly is a strongly-typed language, with only three primitive types (numbers, strings and booleans) and a number of structured types (message, split-string, array, index, index-cursor, fifo, lifo, list, file and service). Gliimly is a declarative language, with a few lines of code implementing large functionalities. Gliimly is also very simple - it does not even have expressions! That's because it's designed to achieve application goals with less coding.
Statements (see also https://gliimly.github.io/statements.html)
Gliimly statements are designed for safety, ease of use, and ability to write stable code. Most statements typically perform common complex tasks with options to easily customize them; such options are compile-time whenever possible, increasing run-time performance.
It's interesting, something to look into. It's not a general purpose language, true, and I think that's a good thing. General purpose languages are too broad for the topic of web services. It's like when SQL came out long ago to make database programming specialized. I think we need something like that for web services, and Gliimly may be a good step forward.
Yeah I meant that in a good way. You can build powerful stuff with a DSL that doesn't include the normal imperative programming constructs that most general purpose programming languages, but also some specialized programming languages like bash, include. jq is a nice alternative to python for sifting through JSON for many things.
I think glimly is an interesting project but I wonder why they don't use something like mustache ({{ param1 }} for escaped and {{{ param2 }}} for unescaped) instead of p_web
The criticism wasn’t only about how limited the DSL was — it was about how some of the design choices are repeating patterns which are very common sources of security defects. HTML and SQL are DSLs themselves and have non-trivial security contexts.
from the main doc, I don't think this is the intended use case.
it is about apis, not html.
it is about chaining webservice calls, not using sql.
it's for business logic, not generic programming needing classes
my guess is that this wants to be the excell of the aws era.
Most of the offered cryptographic primitives (encrypt-data[1], decrypt-data[2], derive-key[3]) are not easy to use correctly.
The encrypt/decrypt data interface uses AES-256-CBC with (seemingly) no authentication, and the key derivation uses PBKDF2 with default iterations of 1000 and vague instructions on which value to choose. No interface to a memory-hard KDF is available.
This, along with the notion of memory safety from untested C code doesn't really instill a sense of confidence in me...
I would suggest throwing away all the cryptographic primitives you currently have and instead interface with libsodium, which is a library designed for the rest of us non-cryptographers.
[1]: https://gliimly.github.io/encrypt-data.html [2]: https://gliimly.github.io/decrypt-data.html [3]: https://gliimly.github.io/derive-key.html
The only owner of this project is "Gliim LLC" and it's written in C with cryptic commit messages. This looks dangerous. If this is an honest project and not an attempt to inject malware into other people's projects, you should:
Tip: use the patch format feature of GitHub to view people's e-mail addresses.
Looking at the commit log, the initial commit caught my attention. The author of the initial commit does not link to any particular account on GitHub. See https://github.com/gliimly/gliimly/commit/23e44479d675d3124e...
From here, we can see some identity.
Pasting the e-mail address into a search engine reveals another work by the same person. In particular, https://vixra.org/pdf/1208.0044v2.pdf . The fact the person publishes under Vixra likely means they are not someone malicious, just what some in the mathematics community call a "crank".Thanks for the sleuthing work.
And by “crank” do you mean a recluse? Or someone off of the grid?
The first definition in [0], that is:
[0] https://dictionary.cambridge.org/dictionary/english/crankAnother term for it would be "fringe science". The paper is an amusing thought experiment based on some baseless assumptions; it would be foolish to assume that it describes any kind of physical reality.
Does personal identification make someone more trustworthy? IMO trust comes from history. I.e. maintaining a project for a long time, working on multiple projects, various contributions, then external factors like community, committers + number of eyes on the code.
I see it is implemented in C. Doesn't this add a substantial attack surface, especially relevant for web services? How is the "memory-safe" claim justified?
There is a pervasive, cultural lack of formal verification in software, and it's risky, terrible, and should be stopped. Formal verification can takes multiple forms and operates at different spans across the layers of the stack. We need more of it to prove the correctness of compilers, libraries, and programs. It is a lot of work, but it's critical to proving things are as good, as say, seL4.
We need more Ada / SPARK!
Yes, it opens a large attack surface for a group of people who thinks “memory-safe” is only possible when that word appears on the top of a language’s features list.
Right click → Inspect element, find `body { letter-spacing: 2px }` and uncheck. AHHHHHHHH much better
The phrase "programming language for web services" remind me of Borland Charlotte language introduced 20 years ago. Those days the term web services means SOAP, however. :)
I'm still not getting it, this looks like a standard language + swapped keywords + web service libraries, what does the new language accomplish?
I really love the commit messages. This style adds a lot of value.
This has the appearance of "developed in private, cleansed, thrown over the wall" sort of thing.
The commit messages probably mean something to whoever is behind Gliim LLC.
Some people get it in their heads that their commit history needs to be "clean". It doesn't...
> Some people get it in their heads that their commit history needs to be "clean". It doesn't...
If by "clean" you mean "readable" (in the literate-programming sense), then I'd be a strong advocate of that.
I would like to one day see a repo that is maintained in such a way that, if you just dump out the commits in chronological order (e.g. `git log --patch --reverse --pretty=format:"%s"`), the result is essentially a jupyter notebook that explains the system being built as it builds it.
Such a thing would require a lot of rebasing, of course.
---
But of course, actually looking at giimly's commit history (https://github.com/gliimly/gliimly/commits/main/), you don't mean "readable." You mean "says nothing."
I think this repo is clearly the result of "development in private", but I don't think the commit messages here were "cleaned up." I think this is just this person's way of using git in a single-user context — they just want to incrementally save WIPs, so they number them. (Maybe they even use an editor plugin that does this for them on save, or through a keyboard-shortcut.)
That being said, I do sometimes also see this in the cases of private repos that were so messy and fraught, with long-lived now unmergeable feature branches, that the best way to integrate everything was to just convert each long-lived branch into a set of .patch files; manually prune and edit those .patch files in a text editor; and then `git am` each patchset into a synthetic commit. Those commits don't really have coherent purposes — they're just incremental steps of a single long integration — so you may as well just number them. (Usually, though, people rebase-squash these all once they're done.)
> If by "clean" you mean "readable" (in the literate-programming sense), then I'd be a strong advocate of that
I don't disagree. However the commit messages should have some meaning.
Looking at the repo closer, it appears the commit messages are release numbers:
Commit 91: https://github.com/gliimly/gliimly/commit/956f8001890d85a4d3...
Release 91: https://gliimly.blogspot.com/2024/11/gliimly-91-released.htm...
Which, if the case, is even more awful. Now to understand the change history, I need to consult/cross-reference some documentation page that might 404 in the future. Additionally, the releases have many un-related changes grouped together (as one would expect for a release, not a commit).
Lately I've become fond of the squash-merge. All development is in a branch, and to merge you open a Pull Request (or equivalent on whatever platform you use). The PR gets squashed into one commit that references the original PR, which retains all of the commit history and discussion/review comments. Best of all worlds in my opinion, and frees developers to commit freely without consequence or care.
Just to comment on your last paragraph - I don't really understand people's obsession with having squashed commits on main. I may not have a local copy of the branch that was merged months ago, so I can't get the un-squashed history without jumping through hoops. It also makes tools like git-bisect much less useful.
With my team, once you are done with your PR, you do a quick rebase pass over your branch and squash any remaining partial/in progress/fixup commits into a final set of meaningful logical commits - this set gets merged into mainline wholesale, without any further squashing.
Each commit has the ticket id in the commit message, so you can find all related changes easily if ever needed. This gives us history that's both granular enough to be useful, and meaningful.
(Granted, if your team is disciplined enough to only have very small and granular PRs that only deliver a small logical unit of change at a time, the distinction between approaches becomes moot... but in my experience most PRs tend to be a little bigger that that, and contain at least a couple of related but distinct sets of changes)
And yeah, the commit history in this project is just hilarious.
> With my team, once you are done with your PR, you do a quick rebase pass over your branch and squash any remaining partial/in progress/fixup commits into a final set of meaningful logical commits - this set gets merged ...
A lack of this simple discipline is what causes people to push for squashing. If you squash every PR then your commits may be too coarse, but you don't end up with random "fix tests" commits everywhere. If it's not part of your company culture to do the cleanup then it's harder to get that rolling than to just impose a repo rule that only squash merges are allowed in.
>Some people get it in their heads that their commit history needs to be "clean". It doesn't...
I do not care about git commit history at all. Do not squash. Don't do anything other than commit, push, and merge PRs. I don't delete old branches, I don't do anything beyond the basics. I don't even use rebase. It has never bit me in the ass at all in all the years I've been running this team. The less I have to do with git, the better.
When I learned about git commit squashing I was sincerely disturbed.
Exactly. We have a beautiful tool that can maintain an unbroken historical record without being a burden... and then we use it to rewrite history? Nooooo!!
At our organization, no one squashes or rebases either. We never delete branches. It's been like this for around 15 years. Not a single problem.
I guess it depends on the developers and how they choose to commit. On my team we don't commit unless we're ready to push, so we aren't creating 100s of commits for every feature or bug fix. Some developers seem to think they need to commit every 2 seconds for every tiny little change. That's just seems like a waste of time to me, and it also creates the need to squash and do more stuff with git. Anything that distracts me from writing software and putting work into the code is a distraction, and git is a distraction. I don't really want to deal with git as often or as much as some developers seem to use it constantly to commit everything...
git commit -m "added a blank line"
Dunno for me it's great to commit if I just made substantial work but it's not ready yet. It's assuring that my work won't be accidentally lost if I mess up. Especially it's great to commit at the end of the day or if I just wrote tests which all pass. Stuff works, I can move on, and forget about it. Next day when I write more code, and something breaks (but worked yesterday) I can easily see the diff between yesterday and today and see what changed and where I'm currently at. Commit messages remind me of what I did, step by step. Then I push to the dev environment and if QA finds bugs, I commit new changes which fix the bugs. It's also great for the reviewer - they only have to look at the single bugfix commit, the rest of the code is fine (already reviewed). I don't find a use for squashing, modern tools allow to see several commits as one diff.
> This has the appearance of "developed in private, cleansed, thrown over the wall" sort of thing.
To be honest, I do this with personal projects, and by "this" I mean I finish the project, try to polish it and "cleanse" it as much as possible, and then git commit add with message "Initial commit", and after that of course I have proper commits for bug fixes, feature additions, etc.
> The commit messages probably mean something to whoever is behind Gliim LLC
To me it just looks like they increment by one with each commit. Some numbers might be skipped simply because of fixup rebases.
https://github.com/gliimly/gliimly/commits/main/
Commit history has to be clean just as much as code has to be clean. That is to say, it doesn't - but it's far nicer working with clean code than tangled uncommented messes.
Most of the commit messages in my personal projects say “Temp” and yet to see any issues with that. I have some repos where I maintain commit messages (by inertia) and it always bugs me as an utterly useless routine.
In the rare case when I have to investigate history, there are actual code changes and all the tools to navigate them. There’s no “read through the log to find a change” in my workflow, just like there’s no “read through code to find an identifier”.
It doesn’t mean that this works for all projects and workflows. People report their day saved by a commit message. But that blanket belief in sacred commit messages is just that. It’s not unusual to see a 1-person repo to contain synthetic messages cause under no peer pressure people act like it’s natural to them.
mystery driven development
magic number driven design
I tried Gliimly. I just had to after some really weird comments below that start like a gossip club and then degenerate into preferences for git commiting (like anyone cares about either). Anyway, Gliimly's simple to write code with, and without being too pedantic about what some people think "web service" or "service-oriented" means, it did what I needed it to do. That is to say, I was able to build a web application for work (insurance) pretty darn quickly, all in a REST-like structure of service calls. I am not a fan of an object oriented paradigm, though the company I work for (still) uses C++. I used to be all over it. But it's gotten so complicated that I am looking to make a 180 and find something so simple it stinks. Gliimly could be it, or not, but I like simpler. Is it safe? I did try some nasty stuff that would overwrite memory, and the program stopped with the appropriate message. I tried SQL injection and couldn't do it. So the fact it's written in C doesn't mean anything, I mean lots and lots of critical software are written in it. I haven't run into any bugs, and compiler error message were pretty descent. The performance was better than C++ for the same legacy app we have, and that's about 12x larger in terms of source code. Overall, Gliimly is something I could work with, assuming it stays, which is a big if. Most projects like this eventually lose steam unless they get some kind of sponsorship from a "consortium" of companies, but hey, some work out without that kind of backing just on their merit. Time will tell.
Instead of .gliim I would have gone with .glm
Does this run on Temple OS? Would be a good fit.
Doesn't seem compatible with Holy C.
TL;DR for people coming from developer friendly web servers like Rails, Go, Node, Python -- this is not it.
https://gliimly.blogspot.com/2024/09/web-service-hello-world...
My first impression is that like with HTMX, it's for a style of web apps that has few uses nowadays.
The benefit of the HTML syntax quickly goes away if it has a JavaScript frontend. The routing doesn't make sense in a non-trivial app. For a non-trivial app, something more flexible like Django's routing system makes sense.
It says it's service-oriented. It doesn't have what I expect from something service-oriented in its big example, though. For instance the entry point to the app is /session/start and it doesn't route based on HTTP methods. https://gliimly.blogspot.com/2024/11/multi-tenant-saas-notes...
>My first impression is that like with HTMX, it's for a style of web apps that has few uses nowadays.
What do you mean? I see nothing common with HTMX. It feels more like old PHP5 projects, where they mixed business logic with controllers, database access and template rendering all in one big soup.
Even PHP had a composable expression syntax (e.g. nested arithmetic/string/array expressions, function calls, etc). I don't think this does; every statement seems to be a unique, standalone thing.
That may be a good thing. I think it's more natural to have it that way. I always wondered why a keyword in a programming language must have this rigid meaning. In English, that's not the case, there's a context.
Gliimly seems much simpler than PHP or other "classic" programming languages out there (C++, Java, Go, whatever). I think there's something to the idea of expressing programming closer to English, in a declarative way.
I'll give it a try, I'd love to type (much) less and just sort of "talk" programming, because that's what this looks like.