for example he dosent make any claim about the python implementation being "far easier to read and maintain" (even by proxy by claiming that CL was hard to read/maintain), and honestly starts out by absolutely singing CL's praises
his reasoning seems to boil more down to the ecosystem surrounding Common Lisps libraries being poorer than pythons:
> If Lisp is so great, why did we stop using it? One of the biggest issues was the lack of widely used and tested libraries. Sure, there is a CL library for basically any task, but there is rarely more than one, and often the libraries are not widely used or well documented. Since we're building a site largely by standing on the shoulders of others, this made things a little tougher. There just aren't as many shoulders on which to stand.
[etc...]
> So why Python?
We were already familiar with Python. It's fast, development in Python is fast, and the code is clear. In most cases, the Lisp code translated very easily into Python. Lots of people have written web applications in Python, and there's plenty of code from which to learn. It's been fun so far, so we'll see where it takes us.
> The alternatives to Lisp Macros like codegen, method annotations, Rust Macros. Are all much less powerful and usually harder to create, but maybe that is a good thing.
I kinda agree that macros can lead to a lot of (bad) abstractions if you overuse them, but when you need a macro a lot of times the alternatives a language provides can somehow feel more magical if you try to get them to do macro-y things (decorators/attributes... languages always seem to mix those two terms) or just cumbersome and in my opinion kinda an ugly hack to paper over the fact that your language is lacking in some way (codegen). I'd much rather read a simple (lisp) macro then understand how your ugly codegen system works.
I dont have enough knowledge to comment on rust macros though.
I'm seriously impressed by the amount of progress this project has made (and its apparently helped with finding issues in the various specs that constitute a modern browser) so I wish him all the best in this new direction
if anything GUI's should be significantly faster (well, I say significantly, but a well optimized GUI app and a well optimized Terminal + TUI app would probably have near imperceptible latency today anyways)
The little timeline comparing it to the Shostakovich's 10th Symphony, Yury Gagarin being the first man in space, and the presentation of the IPhone was a fun touch lol
> bwrap, flatpack, containers... were really talking about software distribution. I dont think any of these solutions "solve" the problem, we're just putting all the bullshit in one bag, not getting rid of it.
I agree, personally I prefer flatpaks more often then not because they "just work" for most programs I use (that aren't on the terminal) but Its far from an elegant solution, still, I do generally like a lot of the work their doing like the various xdg-desktop-portal permissions that are standardising a lot of common "desktop" interactions
Is there anything in specific you can point to in terms of layout? IME Most of the time you can just `display: flex` or `display: grid` (and then tweak the necessary properties on the children) and it generally works well.
Often when non-web based UI frameworks leave out CSS they don't elegantly fold it into their UI markup and/or language, they just don't have the features CSS has to begin with, or force you to declare it in the programming language which imo often looks ugly (especially if they try and make some kind of declarative DSL in an imperative programming language).
My only question is... why?, I understand pretending to be something official when you're really not at all so you can profit off the confusion, that trick is a dime a dozen on the internet... but zsh? Really? Surely there are more profitable ventures wearing the skin of a free shell for Unix operating system?
You can shorten that to oklch(62.8% 0.2576 29.23) and it will still max out the red subpixel on your sRGB monitor, not that this is a particularly serious flaw with okLCH anyway IMO, especially compared to the incomprehensible nonsense that is #RRGGBB unless you're specifically working with sRGB subpixels/pixels and not colour
for example he dosent make any claim about the python implementation being "far easier to read and maintain" (even by proxy by claiming that CL was hard to read/maintain), and honestly starts out by absolutely singing CL's praises
his reasoning seems to boil more down to the ecosystem surrounding Common Lisps libraries being poorer than pythons:
> If Lisp is so great, why did we stop using it? One of the biggest issues was the lack of widely used and tested libraries. Sure, there is a CL library for basically any task, but there is rarely more than one, and often the libraries are not widely used or well documented. Since we're building a site largely by standing on the shoulders of others, this made things a little tougher. There just aren't as many shoulders on which to stand.
[etc...]
> So why Python?
We were already familiar with Python. It's fast, development in Python is fast, and the code is clear. In most cases, the Lisp code translated very easily into Python. Lots of people have written web applications in Python, and there's plenty of code from which to learn. It's been fun so far, so we'll see where it takes us.