Earlier quoted context omitted.
I had the same thought about conditions a few days ago and discovered this: https://discourse.julialang.org/t/ann-package-conditions-jl/...
Lol. The final domino falls!
Why is Common Lisp not the most popular programming language?
211–220 of 339 posts
Re: Why is Common Lisp not the most popular programming language?
#212Earlier quoted context omitted.
I'm not sure if Rust is a good comparison though. Rust is a lot closer to C, it is a language influenced by C, and current popular programming languages tend to also be influenced by C. So while there is a lot different with Rust, a lot of knowledge from, lets say, a C developer can carry over. Say your a C developer, or C++ developer and I am a Rust developer trying to sell you on Rust. You have to learn a new langu…
I'd argue Lisps are worse today. They encourage a thing that's generally discouraged in C: macro programming and typedefs. You're coding in Lisp, but you're actually coding in your own dialect of Lisp, eventually, with lots of idiosyncratic code that's difficult to reason about. That doesn't scale well in collaborative environments, where many people are touching a vast codebase (which I don't think was really a thin…
sorry but nah, nobody encourages anyone, let alone newcomers, to write macros. You don't even need to. You can chain function calls and get the job done.
BTW you get many static type checks at compilation with SBCL, instantly, and see Coalton for more (Haskell-like on top of CL).
Re: Why is Common Lisp not the most popular programming language?
#213Earlier quoted context omitted.
I'm not saying Python is always crappy. It's just easier to create crappy code in Python, due to dynamic typing, rampant side effects, null values, OO madness, etc. If your team has the discipline not to do that, great.
> dynamic typing, rampant side effects, null values I’m afraid these are also problems in Common Lisp.
much, much, much less than Python. CL compilers (looking at SBCL) get you many type checks, at compile time, instantly (you compile the function at point), or you can send computation to compile time yourself, and the OO is different, etc.
Re: Why is Common Lisp not the most popular programming language?
#214Earlier quoted context omitted.
For my comparative programming class in college, I was the only person who got all the Lisp assignments done on time and correctly (it helped that I was deeply into TeX at the time), so there is definitely a mind-frame to be in, and some sort of hurdle which a fair percentage of folks find difficult. One big problem w/ Lisp is that it is so difficult to distribute programs written using it --- I'd give a lot for the…
SBCL has save-lisp-and-die. The binaries are big though. LispWorks will give you smaller binaries, but it costs money.
My web app with dozens of dependencies is ±35MB, using SBCL core compression. So that's heavier than Rust, lighter than Deno, maybe in par with Go when the application grows. It starts up in 0.4s, without compression it does in 0.01s.
https://lispcookbook.github.io/cl-cookbook/scripting.html#bu...
Re: Why is Common Lisp not the most popular programming language?
#215Package management kind of sucks, the ecosystem sucks, other languages continually improve but nobody will ever advance the CL standard. There is nothing compelling about the language to people who aren't already Lisp people.
For package management, we have:
- Quicklisp, which is pretty handy, since we can install and use a library from the Lisp REPL, without restarting anything.
- Qlot, that installs dependencies locally, and allows to pin them (yeah you can't do that with QL, although cloning a lib and using it is easy).
- ocicl, a new package manager from the world of containers
- CLPM, another new one
- Roswell, if you really really want to install libraries from the terminal (although Qlot does it) or to install implementations, or software.
I bet the ecosystem is bigger than many think: https://github.com/CodyReichert/awesome-cl and anyone would be amazed by its stability.
Re: Why is Common Lisp not the most popular programming language?
#216Popularity is a matter of luck. But suppose that the forces that drive luck somehow aligned themselves with promoting Lisp. There are ways Lisp would sabotage the luck being radiated upon it. Programmers who get into CL will hit various silly obstacles: - No standard way to express special characters in string literals. - No standard Unicode support; no \u1234 notation in the standard. I/O with character encodings is…
- (i don't get the first point)
- unicode: major implementations support it.
- oh yeah. UIOP (shipped-in) and libraries fix pathname handling. https://github.com/Shinmera/pathname-utils - https://github.com/fosskers/filepaths - etc
- agreed, it's a pity for SBCL. See https://github.com/lisp-maintainers/cl-repl (although an editor with Slime-like integration is better)
- yeah, it's a choice to make during development. It could be point-x. Or using with-slots.
- yeah
- but multiple values are very helpful (reminder to the reader: they are not like returning a tuple. Return a list if you want). They allow to not break an existing ABI. You can add a return value and not change all the callers. Awesome.
Re: Why is Common Lisp not the most popular programming language?
#217I've written in Common LISP. Here's my port of the Boyer-Moore theorem prover to CLisp.[1] I've used original INTERLISP. I've used a Symbolics LISP machine. I once did a lot of work in Franz LISP.[2] And I'm partially responsible for AutoCAD going with AutoLISP as a scripting language. I've even taken a class from John McCarthy himself, at Stanford. All that was decades ago. I haven't written a new program in LISP in…
yet no other language gives so many tools to the developer… quantum companies would disagree. https://github.com/azzamsa/awesome-lisp-companies/
(BTW: CL isn't Smalltalk which isn't uniquely that anymore, we do use source files and we can compile single-file binaries. My web app weights 35MB, starts up in 0.4s (or 0.01s without core compression))
Re: Why is Common Lisp not the most popular programming language?
#218Earlier quoted context omitted.
Because I can eliminate drudgery in a way I can understand. I find that no matter what language I use, I eventually want code that writes code. Other languages have bad tools for this. Sometimes I use an editor, or something else like m4, to generate code. Haskell has Template Haskell, which is icky in a variety of ways, and it has other stuff that I have a hard time figuring out because I’m not a math PhD. In Lisp I…
On the strength of your first four paragraphs, I have to plug Julia. It doesn't have the benefit you point to in your fifth paragraph, of having a decades-old standard; stability of the core language is good so long as you aren't comparing it with C or CL. But it has a full-fledged macro system, the kind where you can write an anaphoric if. It doesn't have the Zen of macros in a Lisp, but it has the power, and that's…
These points scare me: https://gist.github.com/vindarel/15f4021baad4d22d334cb5ce2be...
I doubt Julia gives as many image-based tools for the REPL (no conditions and restarts?), no single-file binary? I guess Julia's ecosystem is less rich than CL's outside of science.
Re: Why is Common Lisp not the most popular programming language?
#219Here are so many responses, I begin to wonder whether CL is actually used less today than it was thirty years ago.
Re: Why is Common Lisp not the most popular programming language?
#220Earlier quoted context omitted.
I've written a great deal of Common Lisp and the only "easy things hard" I've encountered are fast matrix multiplications -- because there are many ways to do this and they each have different tradeoffs, and implementing symmetric crypto algorithms that assume 32-bit word sizes. Because Lisp integers automatically grow when necessary, forcing arithmetic to stay within a 32-but limit is hard do do in pure Common Lisp…
I haven't written Lisp professionally, but my impression is that one place Lisp comes short is forcing convention: Every program, every module, is potentially its own DSL, so good luck getting programmers to agree on a convention. At least with more rigid languages like Java or Rust, when you open a file, you'll agree what language it is. Haskell has this problem, too. You need things like "Boring Haskell Manifesto"…
> Every program, every module, is potentially its own DSL
it isn't, don't worry. Problem solved ;)