I really dislike the title and the article. You are basically stating that AI is not a bubble, but everything around AI is a bubble, which people obviously mean when they say AI is a bubble. Same was the case with dot com crash, where people didn't LITERALLY mean .com domains would crash, but everything around the domains (& Internet) would crash.
Does not help that the author is overinvested into the AI space.
You're conflating git with git forges. Most popular forges use a centralized model. Git was built as distributed from the start and it's original mode of collaboration was through a federated protocol.
Yeah, like asking for trouble. Even when building a basic image upload system in my project I was considering using some AI model to make sure content is at least somewhat moderated.
If you buy a painting, yes, you own the canvas. You can put it wherever you like, rent it out to others, destroy it, dismantle it and cut up the pieces to make your own collage artwork, whatever you like.
The copyright in the work belongs to the artist though. Your physical ownership of the painting doesn’t stop the artist making another work just like it or licensing the right to do so to someone else.
Museums and galleries sometimes claim copyright on images of works they possess, but that’s generally claiming a copyright over that particular photograph of the work, not the work itself. In order to do things like sell prints they will have to license the work from the artist or the current rights holder (for distributing prints of that work in that territory, which might not be the same as the rights holder for other uses).
Ownership of ‘what the painting represents’ isn’t really something the law takes much of a position on.
What's the primary reason you set out to build this? I like the look and feel of the language but I'm on the fence whether the drawbacks of using something different than bash are outweighed by the benefits of elvish.
I believe shells have the potential to be much more than what they are today, and traditional shells are held back by their rather weak languages.
Re the cost of switching: on the one hand, I'd say that "switching" is really the wrong mentality, because you can always still use bash! You can "switch" to Elvish as your interactive shell and still use bash for scripting. Or you can "switch" to Elvish for some new scripts and still use bash as your interactive shell (and your existing scripts). If you want to give Elvish a try, you can just do it without giving up everything you do with bash today, and reap the incremental benefits of using a better shell.
On the other hand, the mental barrier of adopting "a new thing" is definitely real, even after you overcome the more irrational fears. We only want so much software in our lives anyway. To that I'd say Elvish needs to be more compelling than what it is today. Elvish today, with its nice interactive features and a real programming language, is perhaps 2x to 4x better than traditional shells on its own (if we ignore the whole ecosystem issue), but it needs to be more than that to stand out to people as something radically better. I'm still trying to figure out how to do that, but two ideas I'm exploring are:
- Make it super easy to build TUIs in Elvish - we've had a "renaissance" of TUI tools in recently years, but if you want to build a TUI from scratch it's still surprisingly complicated. Much simpler than building GUIs, but still much more complex than just building a CLI. I feel Elvish as a shell language is a really good place to have a nice TUI framework in.
- Make it super easy to manage a simple homelab or build farm in Elvish - this is traditionally a strength of shells and people still cobble together shell scripts for this purpose, but traditional shell languages are clumsy and you can't easily expose a nice UI from shell scripts. It would be very nice if you can compose some Elvish scripts together and have a nice TUI or a web UI for management at a very low extra cost.
I personally don’t find the TUI idea compelling. I’d rather use a general purpose language like Rust or Python. Many powerful and mature frameworks are already available to build TUIs there. You want to optimise the average one-off hacked-up script writing experience. Most scripts are written in a hurry to accomplish some boring task or automation.
I would spend time building a top notch LSP for Elvish. Shell scripting languages tend to be highly untyped and flexible so building a good LSP will be tough here. But if you were able to build one that works really well you would have another really compelling reason to use Elvish.
P.S. I am aware that Elvish has a built in LSP. It’s somewhat basic though IIRC.
> I personally don’t find the TUI idea compelling. I’d rather use a general purpose language like Rust or Python. Many powerful and mature frameworks are already available to build TUIs there. You want to optimise the average one-off hacked-up script writing experience. Most scripts are written in a hurry to accomplish some boring task or automation.
That's interesting, because I have the same starting point as you (optimise hacked-up script experience) but a lot of the time as my script grows I really wish there's a nice little TUI for it. For example, rather than finding my invocation of the script from my command history and edit the CLI arguments, can I just have a little "pop-up menu" for my workflows, where I can probably add some string argument? Or allow me to see the outputs of the script in a slightly more fancy way than a stream of text - like a Miller column view, which Elvish already has implemented in its file manager? Ideally, these should be "ready-made" UI components that you can take advantage of from your hacked-up script with just one or two lines of code.
I'm also coming from the viewpoint of implementation - I've built Elvish's TUI using some very generic building blocks but they are only used for very specialized builtin features of Elvish, so I'm really keen on exposing the capability for shell scripts to use.
I guess we're thinking of different things when we say "TUI" - perhaps you are thinking of full blown TUI applications, like an editor? I'd agree that a more [1] general-purpose language is more suitable and Elvish is not in the business of being a good language to implement the next TUI editor :) Maybe I should coin a new term for what I have in mind, which should be something you can hack up as easily as a CLI. "TUIlet" maybe?
> I would spend time building a top notch LSP for Elvish. Shell scripting languages tend to be highly untyped and flexible so building a good LSP will be tough here. But if you were able to build one that works really well you would have another really compelling reason to use Elvish.
Definitely! It's not what I'm working on in the immediate future, but good editor integration is a must to make the experience of writing scripts much better than more traditional shells.
1. Emphasis on "more", because Elvish is a general-purpose language itself, just not the most general-purpose :)
Bash reigns supreme indeed. If you’re writing software for yourself or a small team the benefits of Elvish are higher productivity. Try it out — I was really satisfied at the power and cleanliness of the scripting language.
Bash will be dethroned some day. As general purpose languages like Rust, Julia, Python etc have risen, Fortran, pascal etc have declined. And so that will eventually happen with bash. Not “if” but “when” !
I've been using it for weeks, but recently it was so gutted that it barely understands TypeScript. I do my own coding again because sifting through all the possible bugs is more work than just writing it yourself. A true shame, because before it got "faster" it was capable of creating entire apps.
