[HN Gopher] Gliimly is a programming language for web services
___________________________________________________________________
Gliimly is a programming language for web services
Author : todsacerdoti
Score : 26 points
Date : 2024-11-15 17:15 UTC (5 hours ago)
(HTM) web link (gliimly.github.io)
(TXT) w3m dump (gliimly.github.io)
| not_your_vase wrote:
| I really love the commit messages. This style adds a lot of
| value.
| Alupis wrote:
| 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...
| IshKebab wrote:
| 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.
| derefr wrote:
| > 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.)
| Alupis wrote:
| > 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/956f80
| 01890d85a4d3...
|
| 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.
| kaycebasques wrote:
| > 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/
| leptons wrote:
| >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.
| kgeist wrote:
| 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.
| leptons wrote:
| 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"_
| kgeist wrote:
| 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. I don't find a use for
| squashing, modern tools allow to see several commits as
| one diff.
| dgfitz wrote:
| When I learned about git commit squashing I was sincerely
| disturbed.
| agumonkey wrote:
| mystery driven development
| rapnie wrote:
| magic number driven design
| benatkin wrote:
| 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...
| kgeist wrote:
| >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.
| duskwuff wrote:
| 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.
| OutOfHere wrote:
| 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?
| flockonus wrote:
| 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...
| ks2048 wrote:
| 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
| duskwuff wrote:
| 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.
| hathawsh wrote:
| 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.
| triyambakam wrote:
| Instead of .gliim I would have gone with .glm
___________________________________________________________________
(page generated 2024-11-15 23:00 UTC)