Live data from Hacker News

It's 2023, so of course I'm learning Common Lisp

log.schemescape.com

341–346 of 346 posts

Re: It's 2023, so of course I'm learning Common Lisp

#341
post #7

Earlier quoted context omitted.

I don't know if you're interested in Sublime Text or not but https://github.com/s-clerc/slyblime is pretty good. VS Code also has Alive which I heard is good although I don't use Electron apps.

Thanks a lot! It does indeed look good. Btw, what made you choose Common Lisp instead of Scheme (Guile, Racket, etc) or Clojure? What made it more business effective? Genuine curiosity :)

I dislike the JVM and the other lisps did not have the code performance and stability I needed.

Re: It's 2023, so of course I'm learning Common Lisp

#342
post #244

Earlier quoted context omitted.

C++ itself never had a marketing budget! The nearest you might find is marketing for implementations back when people paid for programming languages, but the only surviving one of those is really Visual Studio. Lisp has had decades to break out of its niche if it delivered a really advantageous solution, but somehow that never happened.

> Lisp has had decades to break out of its niche if it delivered a really advantageous solution, but somehow that never happened. I think a huge part of it is that it is not immediately obvious that one needs what Lisp offers, and by the time the system has grown to the extent that the need is obvious, it has also grown to the extent that one no longer sees the fores for the trees. One doesn’t think ‘oh man, I need g…

> one no longer sees the forest for the trees

One no longer sees the forest for the fire.

Re: It's 2023, so of course I'm learning Common Lisp

#343
post #4

The scoop: Scheme and Janet are great, but the author wants a more standalone language. What makes the difference is the breakloop, a full-blown REPL that opens when an error in a program occurs. Not a stacktrace, not a debugger; just build from the point where it's currently broken.

This sounds so amazing, why is Common Lisp not the most popular language out there? (asking as someone who almost never writes code)

It's complicated, but there are likely some main contributing points.

1. Computing is extremely blinkered. More than in other professions, people in computing are either unaware of what has been done before. If they learn a little bit about what has come before, they look for reasons to be dismissive of it, so they can turn their attention away. They know a few things (languages, platforms, tools) and just live in that world.

2. At any given time, a small handful of things are popular. This changes over time. The amount of stuff we have produced in computing vastly outnumbers what is popular. It's like a game of musical chairs in a packed sports dome, where there are seven or eight chairs on the floor.

3. The field is still growing; there are probably more people who joined in the last 10-15 years, than those who joined the field before that. Almost every newcomer plunges into whatever is popular at the time, and will never look at anything else unless it is new and popular, which will happen at most some 3-4 times in their career before they are out.

Those are generalities. Then there are Lisp specific historic items.

Lisp specifically had a bit of a heyday in the 1970s and into the 80s. People developing Lisp systems were very ambitious and their work eventually demanded hardware that only big companies and well-funded institutions could afford. They did fantastic things, but Lisp did not scale down to the emerging single-chip microcomputer with a small memory (or not in that fantastic form). Typically, Lisp would have liked a few megabytes of RAM compared to tens or hundreds of kilobytes.

The microcomputer was something new and popular, bringing with it new people who had nothing but microcomputer experience. Most of them didn't know anything about Lisp other than reading about it in books or some magazines like Byte and Creative Computing, which is something that only a curious minority would engage in.

Eventually, consumer microcomputers became powerful enough to run Lisp well, but by that time, the people who remembered Lisp were vastly outnumbered by new people.

(Speaking of memory sizes, GNU's implementation of Lisp, even, GNU Emacs, was absolutely derided for its memory use, well into the 1990's. For instance, one joke interprets its name as an acronym for Eight Megabytes And Constantly Swapping (EMACS). Eight! Not Eight Hundred or Eighty. Eight megabytes is ridiculous today; the resident size of a Bash process can easily be that.)

Another problem with Lisp is academia, which has played a role in actively destroying interest in Lisp.

After the downturn in Lisp popularity, schools continued to teach Lisp dialects, but often badly, leaving students with a bad taste. They used scaled down dialects not suitable for software development work, like certain Scheme implementations, and gave students assignments that focused on doing things with recursion and lists, and other nonsense that is far removed from making a text editor or game or whatever.

This practice is still continuing. If you follow the [Lisp] tag on StackOverflow, you will notice that from time to time, students post Lisp homework questions. E.g. "we are required to write a recursive function that removes matching items from a list". The comments will say, there is a built-in function remove, why don't you use that. The student will reply, oh, is that right? But, in any case, we are only allowed to these five functions: cons, car, atom, ... and we can't use loops, only recursion.

Never in a programming course that used C, or Modula-2 or whatever have I had homework forbidding me to use any language statement type, operator, or library function! This is purely a Lisp teaching problem, and it leaves students with wrong ideas and impressions. They might misremember things and spread misinformation like "Lisp has only linked lists and nothing more, and everything must be done with recursion; it is useless".

Re: It's 2023, so of course I'm learning Common Lisp

#344
post #322

Earlier quoted context omitted.

my question specifically was which languages/runtimes allow you to actually make changes to the code in a live process without restarting it.

Your question moved the goalposts. Making change to a running system wasn't part of db48x's claim to which dleslie responded. It was explicitly excluded, in fact.

ok, fair, but what i am asking about is a feature of common lisp (and smalltalk or pike), so i didn't pay attention to the exclusion. that was not deliberate. my bad. (maybe you could say i moved the goalpost back to the original topic)

Re: It's 2023, so of course I'm learning Common Lisp

#345
post #324

Earlier quoted context omitted.

Before QL, you looked at the .asd and searched cliki for each name. You can still do that if you like (and can use Google as well). Sometimes the readme had better instructions, but often they didn't work. In fact, each project in the QL repository includes a link to upstream, so you can use that to find your sources if you like I literally once rewrote the 20% of a library that I personally needed because it was fas…

> Before QL, you looked at the .asd and searched cliki for each name. Only very few libraries are on Cliki, and the links "upstream" just link to the repo that almost always says to just use Quicklisp for installation. Quicklisp has a quicklisp-projects repo where the project sources are all in one place, but it's not very helpful for what I've been talking about. > Your original comment reads like there used to be a…

> If you really think I'm wrong, do a writeup and share it on HN with everyone. You can go to the awesome-cl repo to find the most popular libraries in the ecosystem, and show how easy it is to avoid using Quicklisp to install/build/find the deps/run tests for all those repos. It would really help and I think it would save a lot of people time. For something like the Nodejs ecosystem, for example, such a writeup would probably only take like an hour tops because of the maturity of the npm package manager.

I picked dexador because Fukamachi likes lots of small projects, so it's going to have lots of deps; it took me about 50 minutes while watching baseball and chatting with family:

https://gist.github.com/jasom/474ba02bf3d4e0c02d8fc10feacd3b...

I should also note that, should you want to avoid reading the .asd file, you can skip steps 2-4 and just download dependencies as-needed.

This is literally what my workflow was for using 3rd party Lisp projects the day before QL came out. Prior to my discovery of Google it was even more of a pain.

I've never successfully gotten a Nodejs project working without NPM, but NPM vies with pypi for my second least favorite packaging ecosystem (haskell cabal "wins" this contest).

Re: It's 2023, so of course I'm learning Common Lisp

#346

Earlier quoted context omitted.

I've mentioned this in a sibling thread, but it's interesting to compare this to Ruby. Ruby does support the sort of redefinition you're talking about. And yet REPL-centric development isn't primary there, either. Yes, there are very good REPL implementations, but I don't know of anyone who develops at the Ruby REPL the same way you would in a Lisp REPL. Maybe it's a performance thing? Maybe it's the lack of images?

BTW, you mentioned that classes can be redefined in Ruby. How does this work for existing class instances? Anonymous pieces of code, methods, etc? Even lisp itself does not save from all the corner cases, it's the dev culture that makes all these wonderful things possible.

Existing instances get the new capabilities.

The first time you do `class A....end` you're defining the class. Instances when they are created keep a reference to that class - which itself is just another object, an instance of the class `Class` which just so happens to be assigned to the constant `A`. If you later say `class A... end` and redefine a method, or add something new, what you're actually doing is reopening the same class object to add or change its contents, so the reference to that class doesn't change and all the instances will get the new behaviour. If you redefine a method, calls to that method name will go to the new implementation.

So in that sense it works like you'd expect, I think. As I said, Ruby is very lispy - Matz lists Lisp as one of the inspirations, and I think I'm right in saying he even cribbed some implementation details from elisp early on.

Post reply on HN