181–190 of 339 posts
I'm pretty sure it's the people.
Lisp is a lone man sports. There's not much community spirit. There's not much github, patches are not accepted.
In general. Of course there are many great people around, of the anti-academic background. Who tried to build communities. But the ecosystem lacks a lot still.
Earlier quoted context omitted.
I disagree. I have no problem with lists obsession in other languages like OCaml. The parentheses are just too much. I get how elegant and unambiguous they are for computers but I am not a computer. It's like RPN. It's elegant and easy for code to parse and unambiguous and all these nice things.... except it isn't easy for me to parse. Compilers are perfectly capable of compiling readable code like Rust so I don't se…
I think it's as much about familiarity than anything else. I've programmed full time in Clojure for the last 6 years, and I find it just as easy to read than other languages I'm familiar with (JavaScript, Java) and way less easy to read than other languages like Haskell or OCaml that have their own syntax lineage. I'm sure if I spent an amount of time becoming familiar with them, I'd find them just as easy as I do Li…
;; common lisp
(defun sum-and-square (a b &aux (sum (+ a b))
(* sum sum))A lot have already been said about it: +Lisp Lost the train of microcomputers. They were "toy machines" that needed low level programming like assembly or forth or later C to do anything remotely similar to what Mainframes could do. +Common Lisp is a mess, a compromise, like Deutsch (a language created to take something out of every variant dialect), designed by committee language. Better (opinionated, created by a p…
???
I recently started learning Common Lisp for fun (and fun it is!) and the ease of accessing C libraries was one of the things that surprised me in a positive way.
Using https://github.com/rpav/cl-autowrap one can simply write (c-include "file.h") and the API defined in "file.h" is accessible from Lisp. I can't think of a simpler way.
Even without cl-autowrap, FFI using https://cffi.common-lisp.dev/ seems simple enough.
Earlier quoted context omitted.
>Perhaps it doesn't occur to them that people try it out and then leave and never come back. Once the code is data is code clicks there’s no going back. When you read other languages you just see a lisp DSL, you can’t unsee it because you’ve changed.
Isn't this the exact "if people only knew" attitude he mentioned?
It's the lists. No, not the prefix notation, parenthesis, what have you, although that doesn't help. The lists themselves. In Lisp, code is data, and data is lists. Yes, of course, there are hashmaps, arrays, strings. But idiomatic Lisp code really does use linked lists extensively, it's an entire style of programming. Even if you'd prefer to use different data structures (and again, Common Lisp does support this ),…
I'm tackling a significant lisp project right now, and the thing that holds me up right now is that the code is difficult to organize. Python, java, rust, go etc have well-defined patterns to figure out where code lives and where you might expect certain behaviors to occur. With lisp you can really shoot yourself in the foot very easily by using abstractions that are difficult to follow and are spread out across many…
Earlier quoted context omitted.
> There is SBCL, which does get some development, but not much I think? Quoth the website*: > New SBCL versions are usually released at the end of each month Also, the only BSD which has even in the single digits of market share, Darwin, is only 1 point release behind. * https://sbcl.org/all-news.html >
Half of the phones in the US run BSD. Good luck getting SBCL on it though.
* a runtime in-memory native code compiler (-> COMPILE)
* a file native code compiler (-> COMPILE-FILE)
* and a runtime native code loader (-> LOAD)
Apple forbids providing compiled languages on (I'm talking about "ON THE DEVICE") iOS. Good luck getting those onto iOS. Their own Javascript runtime JIT is allowed, others are not. Common Lisp runtime native compilers are not. Thus one can't move a development Lisp, which includes (!) a native compiler, onto an iOS device and bring that into the Apple iOS/iPadOS/... Appstore. The Lisps which run on iOS (ECL, LispWorks), are compiled outside of iOS. They may include some kind of interpreter (source or bytecode), without a native code compiler component.
Thus: Other languages are not allowed (by Apple) to compile code to native code on (!) an iOS device. On can compile code outside of iOS and move the code to iOS (as a developer). But one can't use a language which compiles to native code ON the device.
There are other restrictions. LispWorks for example runs on iOS, but provides a special runtime with less capabilities than on macOS, also with a different garbage collector. Without the runtime native code compiler.
There might be some BSD in iOS, but different & less form an actually BSD.
To bring SBCL to iOS one thus would need to remove runtime native code compilation/loading and provide a specialized runtime with a different garbage collector. Then this would be needed to be integrated into some other application as a library, or one would need to implement a new GUI for it...
Another aspect that perhaps has changed in the years since - when I was playing with Common List many moons ago, the community in comp.lang.lisp was the place to go, but also rather easy to bounce off. I mean, amusing flames, but yeah, asking a genuine question, the fucking manual read beforehand to ensure not already answered in Hyperspec, often led to rather unpleasant replies. Erik Naggum was particularly abrasive…
that must be more than 15 years ago...
Earlier quoted context omitted.
> But idiomatic Lisp code really does use linked lists extensively, Idiomatic python code uses lists extensively. In my (somewhat limited) experience, they're the default data structure to use for a lot of algorithms. Slightly more accurately, a lot of stuff in python uses sequences extensively, which are implemented by a number of types - but the default sequence is a list. And strings are lists. Yeah, if a list doe…
> And strings are lists Eh, not really. Lists are mutable, strings are not. Strings are iterable and sliceable, which makes them usable in many similar ways to lists, but they're not lists.
You want to learn programming. Lets get started - how long does that take to bang out 10 exercises? Order the estimated results from quickest to slowest. Here's my estimates (don't like them, show yours! It'll be interesting): - Scratch - python/perl/ruby/javascript - C/Java - Swift/Rust - Anything else running on the jvm - - a whole lot of daylight - - common lisp. And many if not most will fail to get to the first…
You’re biasing yourself to what you already (probably looks like C). There is nothing more difficult about some paren except you didn’t learn it first.
See how long it takes you to set up a Common Lisp implementation from scratch. Eg steel bank. Better yet, watch a kid try it on for size. Land of Lisp isn’t all bad but they can’t limit themselves to just one!
Brackets are beside the point.
None of these "programming language evolutionary fitness retrospective" discussions ever manage to address the real heart(s) of the question: - UNIX is C, so C-family languages won. - The network effect is by far the most dominant force in the matter. All of us would like to believe that we operate in a world where technical merit determines memetic fitness, because our jobs seem to depend on it: after all, if we bui…