flavio81

Coalton strives to implement Haskell or ML-adjacent semantics (in the type system, for example) with Lisp syntax. "With" here meaning that it is both implemented in and written with Lisp syntax.

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.

No multithreading, I/O locks under GNUs/eww, glacial slow

All this would not happen if RMS had chosen Common Lisp to implement it...

It’s really interesting reading about LISP machines but no-one’s building a new one

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.

SmallJS is file based, not image based, so you can develop in your favorite IDE

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 ?

One could easily implement an Emacs (SLIME) plugin to "macroexpand" the (pseudo) expresion to real (concrete) Lisp code, and even to try again until the implementation satisfies you.

Then it becomes a concrete Lisp implementation and thus not unpredictable anymore.

I want C++ do exactly and only what the programmer specifies

Good luck with that.

Add Common Lisp to the list. And even Scala has fast compile times today.

Lisp killer features were GC, good data representation, first class functions.

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.

To whoever down-voted me, please do explain how HMRs are comparable to Erlang's true hot code swapping or even Lisp's live redefinition.

based

Exactly. A post full of bollocks.

As one of the authors of the Unix Haters Handbook

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.

Correct. The Unix philosophy is based on hagiography.

Easy to prove, can you think of an engineer that adds negative value?

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.

When did IEEE become host to clickbait nonsense? This whole take feels like an editorial by a junior engineer going off vibes.

Exactly.

I think i'll never click on an IEEE Spectrum article again.

IEEE has jumped the shark.

So, you think productivity or even quality can be measured in "amount of lines of code produced".

Which is completely wrong.

100% based.

Indeed this is one of the hard problems for a manager.

+1, it is my go-to language whenever I have no idea how complex the task will get

You´d be surprised.

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.

The concept of compile-time programming having the same appearance as runtime programming is very cool in my opinion.

You mean, something that Lisp does since the early 1980s?

That means that a field called "date" can be either a string, integer days since the epoch or a Java Date, and (because this codebase isn't great) there's no way of knowing without tracing the call stack.

But this is because JSON is an untyped data structure. (And btw, a flawed one...)

You would have this problem in any programming language.

How did they adapt to dynamic types?

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.

runs on the JVM, access to any Java or Python library within Clojure without wrappers

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.

Clojure uses Leiningen which runs on top of Maven to automatically retrieve libraries, it works very well.

In the same way, Common Lisp uses Quicklisp, which runs on top of ASDF to automatically retrieve and compile libraries. It works very well.

Otherwise, Clojure is an excellent language which both modernises Lisp syntax significantly and implements a very well thought out standard library for doing functional programming. There are many great features, but the standout ones are probably the persistent data structures (which syntactically act both as data structures and functions) and parallelism/concurrency support. It's also very natural to do interop with the host platforms (Java

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.

I do this all the time with Clojure at work. I will have my application running (web app) with two repls in emacs. One is connected to the ClojureScript repl and one to the Clojure repl. I am able to make changes to both front end code and back end code on the fly by changing a function and then evaluating the function into the repl

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.

See my reply above: https://news.ycombinator.com/item?id=25451321

See my reply: https://news.ycombinator.com/item?id=25451321

What i'm talking is about the following:

- Able to easily modify (and recompile) a function while your code is running

- Able to redefine a class and then change existing instances so they use the new class definition

- Able to sabe the complete running state of the system (the "image" of the system, including state of all variables, data, loaded libraries, compiled functions, etc) into a file so it can be restarted later, just like Smalltalk does.

- Able to inspect any stack frame at will and to restart execution from any chosen stack frame

These are just a few of the feature that Common Lisp has and that are part of what an "interactive language" is. Common Lisp brings all these features, they work seamlessly, without any sweat, working reliably and efficiently.

Yes, "Why do you want to learn Lisp?" is a good question.

If the author wants to use Lisp because he/she thinks metaprogramming is interesting, or has read about the benefits of interactive programming, Common Lisp is the choice here.

If the author wants to use Lisp as a way to get a deeper understanding of important computer science topics, I think Scheme is the best choice and with this, following the SICP book.

If the author is interested specifically in functional programming and wants to get easy employment doing it, he/she should take a look at Clojure, Ocaml, and F#.

Yes, "Why do you want to learn Lisp?" is a good question.

If the author wants to use Lisp because he/she thinks metaprogramming is interesting, or has read about interact