Rebuilding Racket on Chez Scheme Experience Report [pdf]
cs.utah.edu
cs.utah.edu
For context, cloc says that Chez Scheme has ~100k lines of scheme code and 16k of C (plus 15k of C headers.) I didn't know Chez was that much smaller than racket/base; that's pretty cool. 16k instead of 200k is a huge difference.
Normally engineers search for tools to solve their problems. Somehow, when it comes to programming languages, software engineers start a search for problems for their cute tools. Please don't get me wrong, I'm not making a snarky comment against lisp. I'm very much in love with lisp, but I do understand how people see us lisp people like bunch of gray wizards in some remote castle. What needs to be shown is a set of problems that can adequately be solved by racket that cannot be solved as well with competing languages. We should really stop treating programming languages anything other than tools. I use GNU grep for 20 years, one day I realize ripgrep is better, I switch.
Again, I want to underscore that I'm not saying that particularly disagrees with you. I just don't think this rhetoric is helpful. We should be thinking about what makes racket that puts a smile on our face, and discuss whether we can use these tools in other languages. Not that this is not being discussed, of course.
I thought the piece "Why Language-Oriented Programming? Why Racket?" covered that question pretty well.
https://news.ycombinator.com/item?id=19232068
Perhaps there's another modern programming language that can do these things as easily as Racket. I haven't come across it, however.
This generates the hypothesis that a developer's desired planning horizon may be "the rest of my career", which is likely to be longer than the planning horizon of whatever project the developer is being paid to work on.
Most of the tools I now use to do my work (devops) I found just playing around with them out of curiosity.
Yes, when doing work you should start with the problem and then search for the right tool, but it's a lot better to have wide arrays of tools in your belt than starting to tour the shops after the deadlines are set.
I don't want to be condescending but I find it hard not to given the obvious catch-22 in your line of reasoning. Even more so as this trope is posted quite often.
I mean, someone must be building stuff with all these lisps that gets used, but compared to, say, Javascript or Java, it seems most lisp developers develop new dialects of lisp. I guess this isn't unexpected as it was originally a language for developing interpreters (aka "AI v1" expert system shells).
There is also the issue where are a lot of areas like UX and tooling requires boring engineering work that no wants to put in. Dependency management, language servers, static analysis etc.
Scheme is stuck in academia; its creators are more interested in forcing language constructs like Continuation Passing Style onto end users rather than fixing ecosystem problems. Despite having a multitude of standards, every Scheme has to roll its own dependency manager. Chicken libraries aren't directly compatible with Gambit and good luck with Racket's licensing.
Quicklisp is relatively recent and a lot of books that are considered "standard reading" are so old that they don't mention it. Simple things like exporting a binary using save-image-and-die etc. don't work properly, easy Rust/Go style cross platform compilation support is almost non-existent and the whole process is extremely flaky in general. Stuff like Roswell improves the UI a bit but the underlying foundation is extremely barebones. Now most of these problems would go away with proper funding. But the major users of Lisp tend to be small niche companies in areas like natural language processing and quantum computing. They are not Sun, they are not Google. They never had to onboard a tremendous amount of new people in a short time. They have their pick of a community with too much supply and not enough demand. The people in charge of using them are happy to stay within the safe walls of Emacs and tradition, expecting all newcomers to do the same. They are not gonna drop a couple million of investment to fund tooling and infrastructure. Even with Clojure where you have new editors and tooling the language authors are infamous for being reluctant to address user needs and concerns at a core level. Forget about a language whose ANSI standard has never seen an update for 2 decades and whose improvements are fueled by a hodgepodge of mildly incompatible language extensions and macros. Sure there are two new compiler projects in CL that are coming along nicely, but they are not dedicating the attention to UX that languages like Elixir do. The CL21 project looks nice on paper but never caught on, and everyone is happy to push for more compiler implementations instead. A lot of the compilation and ecosystem stuff that are really important such as mobile, Web, GUIs etc. are tied to proprietary software. Sure the situation is improving with electron and I heard that the Qt binding is slightly better these days but the language situation resembles more to closed sourced relics like Embarcadero Delphi than the highly vaulted insane-productivity-startup-secret-weapon that HN seem to give the impression of.
Is the LGPL particularly challenging to deal with?
https://docs.racket-lang.org/license/index.html
https://github.com/racket/racket/blob/master/racket/src/COPY...
Racket is currently being relicensed as MIT / Apache 2.
https://github.com/racket/racket/issues/1570
It's a slow process though. Not because people object to relicensing, but some people are no longer in contact with the Racket community and they can be difficult to find.
I'm sure lispworks, corman and the rest of the proprietary lisps have some cool GUI tooling and other useful practical bits nobody in open source common lisp land wants to build (instead preferring to fuck around with yet another compiler). Of course, so does Delphi or any other proprietary language. The real key to developer productivity is someone did the shit work for you and wrapped it in a useful way.
what's worse, when i find an alternative better tool, i often discover that it too is already 20 years old and i could have been using it for a long time!