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-handlerThere'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.
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.
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.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?
I really love the commit messages. This style adds a lot of value.
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.
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.
> 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.
>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.
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.
When I learned about git commit squashing I was sincerely disturbed.
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.
mystery driven development
magic number driven design
Instead of .gliim I would have gone with .glm
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.