I'd hold off on getting too excited about this. Until it:
- Is fully featured and has a conditions and restarts system that works on JS, and has CLOS, multimethods, etc
- Has great interop with the existing JS ecosystem. No painful conversions to and from CL, works/is documented well with existing JS tooling like parcel, webpack, mocha, etc
- Is close to being fully featured and not just implementing <50% (usually <30%) of the features of the language
- Is production ready -- no weird compiler bugs, I can use this with real business
- Has a powerful linting tool -- A linting tool that can blacklist/whitelist a subset of common lisp macros and expressions that can be used in a project. You would need something like this for a real company to prevent the team from shooting themselves in the foot. Could probably be done in CL, sblint comes to mind but it's not well documented (like most lisp libraries) so I'm not sure.
- Culture changes: specifically the community needs to document things much better and be more pro-social instead of living on an island. Backend workflow needs good docs. Ex: I think fukamachi's web frameworks supersede weblocks afaict? not sure, but he has like half a dozen or so web frameworks and it's not obvious which one to choose. Ningle? utopian? caveman? clack + woo? documentation in most CL libraries are really lacking and you need to dig into the source
- Run CL programs without opening a debugger. Modern day workflows have CI pipelines and automation out the wazoo. CL expects you to run the debugger manually. There's a way to run asdf projects like a script but it's not well-documented
- The debugger needs to be more user friendly. Don't get me wrong, the debugger is one of the coolest features of CL, but asking a plain old JS dev to try to understand those low level stack traces is a form of torture. It's roots come from lower level programming, but newer devs want to use it for web app dev (like this to-js compiler posted here). A nicer, easier to understand layer like ReasonML's BetterErrors would be needed or an update to CL itself
- A real package manager. Not quicklisp -- that's a curated package list where you need to talk with a single person who approves it to get your package published
Lisp is probably more popular among those that read HN than the general developer public. It also depends on what you mean by "Lisp" (i.e Common Lisp or "the Lisp-derived languages")
We use it for the core of our AGI and our in-memory graph db in full production - very very fast. The web libraries for lisp are very good as well with Fukamachi libraries, such as [1] caveman and [2] woo (fastest web server), [3] dexador, [4] websockets, also [5] parallel processing, [6] rtg-math incredibly fast math library including quaternion support, etc.
Thanks for the links. I had not noticed dexador before. I have it on my schedule this morning to re-work my network access libraries for an Azure web service, and also access to Wikidata and DBPedia. I have been using old code of mine that needs reworking. I will definitely try dexador.
Thanks, I experimented with dexador yesterday, it looks good. I ended up adding a caching layer for all web service calls and SPARQL requests in my app yesterday - this makes dev and testing much faster, but won’t help much in production.
Personally I also use nginx as reverse proxy a lot, but that's more because there's a ready to use Ingress Controller for kubernetes that uses it internally.
I guess I assumed Stylewarning was representative, although I'm not surprised at the use of python, I probably would've expected that had I not seen Stylewarning's video.
To understand why LISP matters (in theory anyway) is to understand the concept of reification [1]. What you choose to reify (make explicit) in a particular language is a design decision. It's directly related to point 0 in Wadler's law [2] - semantics.
The design of LISP makes eval() and LISP's very syntax as first-class citizens which adheres to the code is data/data is code pragma. It makes LISP homoiconic [3]. It's an interesting and incredibly powerful property. Often too powerful for inexperienced programmers.
Not really, but Paul Graham likes it, and narrowly speaking, he's not wrong about its unique power and flexibility. I think those traits meant a lot more in the late 90s and early 00s, when powerful and flexible programming environments and engineers skilled in their use were much thinner on the ground than today, but I like it too, especially in the form of Emacs.
I think it's more accurate to say a lot of people like it. Especially for personal projects. Double-especially for compiler/interpreter personal projects (one of its key features is being extremely simple to parse).
The R engine began life as a very simple Lisp interpreter.
There is also an R package which gives the Lisp-style representation of an R expression. You can even use it as a R to Lisp Compiler.
I use it every day in the form of Emacs, and I'm slowly learning it because I find it a fascinating language. (I'm a sysadmin/devops by trade/experience, moving into team lead territory, so I'm not a coder by any stretch of the imagination)
Clojure (not Common Lisp, but a lisp) is more prominent than many people think. I use it, and it's a primary language in a R&D area at the fortune 50 company where I work.
Common Lisp also has a good story for application bundling and deployment. It has almost always been my prototyping language (1) but is great for other purposes.
(1) started in around 1986 when I had to write a neural network product in C++ (SAIC ANSim). I did all my prototyping in Coral Common Lisp, and converted to C++ once I had Art2, Hopfield, Boltzmann, backdrop, recurrent networks, etc. figured out.
Not really, but you should learn it anyways. I bought a bunch of lisp books and have been working through them. It is not really objective but I already feel like I'm a better programmer after learning lisp. It has also been a great history lesson in programming languages. I see pieces of lisp in nearly all other languages.
ITA Software, which became Google Flights, was written in Common Lisp. I had heard stories about Google trying to reimplement it in another language, but don't know if that's true or whether it succeeded. Can anyone comment?
Oh yeah! I'm not using Common Lisp but ClojureScript to build the entire frontend for https://bravostudio.app
Basically using Clojure(Script) because it's a way faster way of developing software and frontends in particular. What you see inside of the platform (the frontend), is all built by one person since the start of the project.
do you mean the landing page or also the bravo studio featured on the video? how long did it take? because to create such editors is like a good deal of work and planning.
No, landing page is made in webflow by not-the-frontend-team, talking about the Bravo Studio featured in the video (accessible here: https://projects.bravostudio.app). We're a young startup so been doing less planning and more doing, maybe to a fault, as what we lacked in planning would have to be covered up by spending more time working on it.
But yeah, Bravo Studios frontend had it's initial commit May 27th so coming up to be about a year soon. Bunch of work mixed in on a Figma Plugin that didn't go anywhere as well, so I haven't been 100% focused on the frontend all the time but think we've made good progress so far.
I use Common Lisp and Clojure(Script) for personal projects. Lisp can be a tough sell in a corporate setting, however, some large companies do use Lisp. To my knowledge both Walmart Labs and Cigna use ClojureScript for at least some of their products.
Just mutual admiration society. It's a parentheses hell and good only for self flagellation. It does have a sense of elegance and can be fun but again, the parentheses hell would be enough of a turn off once you start writing long programs.
Use a regular "functional" language, like Haskell or scala and you get the best of all worlds
1. Common Lisp is a fairly big specification for a lisp
2. People doing webdev in lisp have solutions that work "well enough" for them.
3. It's not obvious how to compile a lot of commonly used CL constructs into efficient javascript. Discarded multiple values, for example, are extremely efficient on bare-metal implementations, but will have measurable overhead when not inlined in any javascript implementation.
Fair. I was assuming you could do something at the evaluation layer that was somewhat equivalent. But it makes sense the bare metal ones are doing something at the machine code layer.
I don't think I ever saw it mentioned in HN, but Hop[1] based on Bigloo[2] seems so much more than just a Scheme to Javascript.
If I'm not mistaken, Hop (now hop.js) could even compete in a lot of use cases with Electron.
I accept Clojure as a lisp. Didn't mean to start a holy war. I just don't personally want to deal with it and its ecosystem, which includes Java. I need your average web developer to be able to clone the repo, run yarn, and go.
I understand your point, CLJS is a superset so it's ideal to understand the substrate that it's based on, it's more complex than just JS from that point of view but usability wise:
lein new re-frame myapp
lein run
or
git clone https://github.com/jacekschae/shadow-reagent.git && cd shadow-reagent
yarn install
yarn dev
It is very much fire and go in a way that a typical JavaScript developer might grok
In CL, if you catch an exception, you have the option of trying to fix the problem and then letting the code continue from where it left off. This is only moderately difficult to implement in machine code, but somewhere between problematic and impossible on a high level platform that has already implemented exceptions by stack unwinding.
For the record, CLJS does count. And the tooling although painful is on par with the one found in JS (webpack). Maybe even a little less painful.
But one problem that ClojureScript avoids by virtue of being a 'hosted language' and not having a spec is having to implement its own numeric tower. Numbers can just be floats and move on.
CL mandates integers. Not just fixnums, like WebASM provides, but bignums. As well as rationals. That is a lot of code your run-time will have to provide.
iirc Whalesong (the Racket to JS implementation) bundled a numeric tower that implemented integers using strings).
On the topic of tooling, I found the tooling to be slow as well. However, a lot of my pain points were alleviated when I really embraced using the REPL for developing. Tools like figwheel make developing fairly painless although startup times are still slow.
Whenever I go back to using Common Lisp I'm always surprised how fast the startup time is by comparison.
I completely disagree with that assessment. Disclaimer: I've been doing front-end for a long time. I've tried all sorts of ways to transpile/compile/deal with Javascript. I've tried Coffeescript, Typescript, Babel, Traceur, Fay, Haste, GHCJS, looked into Elm, Purescript and Reason, KotlinJS and ScalaJS. Clojurescript is one of the most stable and better choices for writing production-ready web-apps.
Clojure, currently is the most widely used Lisp dialect in the industry. Lots of people trying it and find it massively productive. Just because some lispers "don't like it", doesn't make it less valuable technological choice.
> Clojurescript is one of the most stable and better choices for writing production-ready web-apps.
Why? TypeScript, for example, is used pretty much everywhere these days; all the other languages are completely niche. I dislike the language (mutability everywhere, no standard lib), but it's dominating the frontend world ATM.
I've been using Scala.js in production apps for around 3 years now. Curious in your experience what advantages Clojurescript has over Scala.js. I ask because you often hear things like "best in class" when Clojure devs talk about the frontend development experience.
The REPL. Just like with any Lisp, true REPL makes a huge difference in the workflow. Anyone who never had honest and heartfelt experience with any Lisp or Smalltalk, would never understand how nice it is to be able to evaluate any expression and sub-expression without any kind of ceremony.
Aficionados of non-homoiconic languages keep saying stuff like:
- "oh, we can probably do this and that and get the same experience...", or
- "give [their favorite language] five to ten years, it'll get the same..."
It's been over six decades. Non-homoiconic languages still don't have "true" REPLs.
Facts do not cease to exist because they are ignored.
- Every PL ranking from RedMonk to TIOBE index indicates that what I'm saying is true;
- Clojure today has more conferences, books, podcasts, jobs and meetups. More than any of other language in its category of languages with strong FP emphasis. It is more popular than Haskell, Elm, Purescript, F#, Elixir, OCaml. Latest JVM survey indicates that it surpassed Scala and has become third most popular JVM language after Java and Kotlin;
- Clojurescript is the most popular alt-js choice (if you don't count Typescript as alt-js). Elm and ReasonML are far less popular;
- If you count by lines of code on Github and Gitlab, Clojure potentially may come second after Emacs Lisp (which is almost four times older than Clojure). Other Lisps wouldn't even be near their numbers.
- And please stop calling it an "improper Lisp." None of the authoritative Lisp scholars have ever indicated this even remotely to be true, in fact many have endorsed Clojure. Clojure can be viewed as a next evolutionary step in development of Lisp. Whether you like it or not, it is slowly spreading wide and beyond JVM (the platform it was initially intended to run on)
It's quite rare to see postings for CL jobs, yet plenty of companies are actively using and hiring for Clojure. It's certainly a far more popular choice for green field development nowadays. Sounds like you're the one who needs to provide citations here and not the other way around.
If you mean Common Lisp, that’s a Lisp-2 (actually Lisp-N), while JS is a -1. That means there’s no universal obviously “correct” way to do JS interop. It’s complicated...
Closure is a Lisp-1, as is Scheme, and (despite it being at least as “academic” as CL) there are lots of Scheme-in-JS implementations.
The latter. Lisp is too academic for anyone to care to do it. Compilers need to be dogfooded, i.e., the people who work on it also write non-compiler programs with the compiler. TypeScript and Emscripten are mature because they are used to create real web applications. No one uses Lisp to write regular applications, much less web applications. Web applications in Lisp are unlikely to be its hidden niche after all these years, so very few people bother altogether.
https://tailrecursion.com/~alan/documents/jacl-els-2020-draf...