flavio81
You're making two mistakes here:
1. Confusing "no allocation" with "avoiding the garbage collector". In non-GC languages like Rust or C there are instances you want to avoid allocation too.
2. Being oblivious that in the past many GC'd languages also had mechanisms for circunventing the garbage collector. Since long, long, long ago. Common Lisp for example (1981-). This is not a modern "realization" or "revelation".
This should be a BIG benefit for agent-driven development, but sadly it seems that few people is taking advantage of it.
This doesn't exactly mean immutable data structures are mandatory, but it helps.
In any case, most of the functions that operate on data structures in Lisp (or Common Lisp) do it in an immutable way.
Not exactly. Coalton brings ML-style strong typing to Common Lisp. But Coalton code is also Lisp code.
The backend, thus, is Common Lisp, and it is available at all times, thus leveraging all its power.
All this would not happen if RMS had chosen Common Lisp to implement it...
There have been two open source Lisp Machine OS created in the last 15 or 10 years.
However a big part of the power of the Symbolics/LMI machines was in the software itself (applications), and this is still propietary code.
To reimplement the Lisp Machine applications would take quite a big effort.
This project is nice, however if we don't have a specific, client-side IDE for interactive development, 70% of the power of Smalltalk is gone (one of the criticisms I give to Ruby)
How would one do to push changes to the web frontend (browser) without stopping the program ?
Then it becomes a concrete Lisp implementation and thus not unpredictable anymore.
Good luck with that.
Lisp's killer feature is procedural macros that are extremely easy to write and debug.
Lua doesn't have such a thing, that's why Fennel was created.
Erlang also doesn't have such a thing, that's why LFE was created.
based
One day, one remote day, mankind will attain Reason and will award you a Nobel Prize for speaking out loud against retrograde computing.
I salute you, hero, veteran.
Yes, i have many examples. Two of them I personally fired. One of them, I should have fired much early. I let this engineer basically add negative value by trying to make his peers (other engineers) finish the work it was delegated to him, thus creating negative value by preventing the other, highly productive engineers, to do their tasks.
I warned him not to do this, but he didn't heed. Sadly due to Human Resources the firing process took way too long. I should've acted earlier.
Exactly.
I think i'll never click on an IEEE Spectrum article again.
IEEE has jumped the shark.
Which is completely wrong.
Indeed this is one of the hard problems for a manager.
In the 1980s, complete workstations were written in Lisp down to the lowest level code. With garbage collection of course. Operating system written in Lisp, application software written in Lisp, etc.
Symbolics Lisp Machine
https://www.chai.uni-hamburg.de/~moeller/symbolics-info/fami...
LMI Lambda http://images.computerhistory.org/revonline/images/500004885...
We're talking about commercial, production-quality, expensive machines. These machines had important software like 3D design software, CAD/CAM software, etc. And very, very advanced OS. You could inspect (step into) a function, then into the standard library, and then you could keep stepping into and into until you ended up looking at the operating system code.
The OS code, being dynamically linked, could be changed at runtime.
You mean, something that Lisp does since the early 1980s?
But this is because JSON is an untyped data structure. (And btw, a flawed one...)
You would have this problem in any programming language.
You mean dynamic typing, I understand.
Clojure (and Common Lisp) is strongly typed, so if you expect type A and you give a value of type B, an error will be raised.
On Common Lisp, which is an interactive development language, you just inspect the stack frame where the error was raised, find the problem, correct the code, recompile your function (while the code is running), and "restart" the stack frame, so the execution continues (without having to restart or redeploy everything and try to replicate the bug). Thus, it is no big deal at all.
On Clojure i'm not so sure how extensive is the interactive support. But there is "spec", which can help.
If you already like Common Lisp, ABCL (Armed Bear Common Lisp) is a mature fully ANSI Common Lisp-compliant implementation, that runs on the JVM and can instance or load Java classes or call Java methods without wrappers and in only one line of code.
> the best out-of-the-box concurrency story of any language I know of
Lots of concurrency models also available on Common Lisp, including async, channel-based, etc.
> Only lists are actually functional, concurrency is YOLO-tier, etc.
I'm sad you had that experience, but there is tons of solid concurrency support in Lisp, for example lparallel is awesome.
Clojure is nice as a JVM language alternative, that is, better than Kotlin, Groovy, etc.
However the loss of the great interactive development facilities that Common Lisp has is a major, major downside. Interactive development is what makes CL (and also Smalltalk/Pharo) great.
In the same way, Common Lisp uses Quicklisp, which runs on top of ASDF to automatically retrieve and compile libraries. It works very well.
Absolutely everything mentioned above in this quote is available in Common Lisp as well by just loading the needed libraries.
>Another issue has to do with startup time. The Clojure application bootstrap process is relatively slow, i.e. start-up might take 1 second,
>The main issue with Clojure is probably its tight integration with the various host platforms. When you get a stack trace in Clojure/ClojureScript, you basically get a Java or JavaScript stack trace, so there is some expectation of familiarity with the host platform.
Correct. And there are no such problems in Common Lisp. Except if you want to execute CL in a JVM, in which case the available implementation, ABCL, does take a slow time to start. Otherwise it's a great implementation.
But since you can't arbitrarily inspect and restart any start frame, you don't really get the interactive programming experience.
On CL, for example, when you hit a runtime bug that is uncaught, you get the debugger window which shows not just the "stack trace" but the complete stack FRAMES that you can inspect. So let's say deep down you find where the error originated and the states of the variables.
You can then jump to the definition of the offending function, edit the function, recompile it, (optionally) change any variable on that stackframe, and then continue the execution by restarting specifically at that stack frame.
In this way, the feature of "modify a function while the code is running" becomes way more meaningful. The program evolves as it runs, as if it were a lifeform.