> "The main Racket distribution now consists of roughly 1.2M lines of Racket (including 270k lines of documentation source), but that code is still supported by roughly 200k lines of C. Large parts of Racket’s implementation remain in C only because the original interpreter was in C, and all of that C code is relatively difficult to maintain."
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.
I've been hearing nothing but good things about Racket for the last few years. I finally downloaded it last month. It really just puts a silly smile on your face. The language-oriented programming is terrific too. I really want to find ways to integrate Racket into my work.
> I really want to find ways to integrate Racket into my work.
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.
What do you think of this line of thought: This tool is not currently the best, but because of its design, it has the potential to become the best tool with some refinement (which may consist of improving the tool itself, your own understanding of it, or its integration into your development processes)—specifically, there exists some cutoff period T where, if you're using the tool for shorter than T, then the "current best practice" tool is better, but if you're using it for longer than T, then the payoffs from your favored tool exceed the costs of the refinement. Then it's a matter of (a) one's estimate of T and (b) one's planning horizon.
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.
One of the things that boggles me about Lisp is there seem to be more lisps and schemes out there than significant applications built in them. I say this as a former lisp weenie (and present day J bum). It's certainly more fun to develop in Lisp than Javascript, but ... for all these tales of power its achievements since Macsyma seem lacking.
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).
(I am referring to Lisp here as mostly the Common Lisp and the Scheme variety)
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.
Everyone wants an excalibur sword for their tool at work; I think most lisps are more like hitachi vibrators precisely for the reasons you say.
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.
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.
Have you ever heard the expression "When all you have is a hammer, every problem looks like a nail"? The phenomenon you're describing is definitely not a unique characteristic of developers. It's a general trait of people that when they learn something cool, they look for opportunities to use it.
> 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
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.
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!
Isn't it the history of computing? We started trying to do some number crunching and here we are a bunch of strangers maintaining a conversation across the globe.
You can look at the biggest DSLs in Racket for tools that solve specific problems (sort of responding to sibling here). I think Racket is probably the best tool for writing static sites for example (using pollen).
Very cool to see that this is getting ready for prime time. It seems they succeeded in achieving the primary goal of making the implementation more maintainable and easier to work with. But the lesser goal (or perhaps non goal, but something some people might have secretly hoped for) of inheriting some of Chez's speed hasn't really panned out (yet).
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.