71–80 of 339 posts
Package 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 example, the Common Lisp ecosystem never converges to a single implementation of any single "thing".
Take Rust. You may not like Serde for serialization, but the ecosystem has converged to it. Similarly, Tokio. You use them until you understand why you need something else and then bite the bullet of going against the tide when you can't make them work anymore.
Okay, so what serialization has Common Lisp converged to? Uh, yeah, about that ...
"Lather, rinse, repeat" this for any value of (serialization, async, objects, concurrency, etc.) and anyone sane quickly reaches the conclusion "Just say no to Common Lisp".
It’s more of a toolbox to build languages than a language. So every commonlisp codebase has a different flavor, and anachronistic semantics. No matter how good you are, this is difficult to deal with. Sure, for config files or writing extensions for your favorite piece of software, you’d make the effort. But most software development is not in that category.
- Scratch
- python/perl/ruby/javascript
- C/Java
- Swift/Rust
- Anything else running on the jvm
-
- a whole lot of daylight
-
- common lisp.
Land of lisp seemed to be the best learn lisp book and it couldn't even manage to limit itself to one implementation of common lisp that you could use for the entire book.
The situation is ridiculous.
Earlier quoted context omitted.
> It's like RPN That's genuinely fascinating for me, because I find postfix notation to be more intuitive and easy to parse than infix notation.
It's definitely easier to parse programatically, but IMO it's a nightmare to read as a human. e.g. compare these expressions: (x+y)^2 = x^2 + 2xy + y^2 x y + 2 ^ = x 2 ^ 2 x y * * y 2 ^ + + I find it nearly impossible to parse this without actually maintaining the stack in my mind.
Common Lisp once had plenty of backing from major companies like Symbolics, Xerox, and Texas Instruments, as well as smaller companies such as Harlequin. Even Apple owned Macintosh Common Lisp at one point, and SK8 (which could be considered a follow-up to HyperCard) was implemented in it. Had Apple not had its problems in the 1990s, one potential alternate version of Apple I could imagine would be some sort of Lisp…
Your order is messed up: work on Dylan commenced years after that AI Winter had begun.
Paraphrasing the point at the end, there is no company that has the financial incentives to promote it. The companies that do have financial interests in CL are ironically not incentivized to promote the free ecosystem around it. For the same reason that commercial C compilers are not really a thing anymore. This is, of course, a simplified view of things. For one, I think Intel still pushes a compiler some. That sai…
Afaik intel compilers are based on llvm nowadays
Earlier quoted context omitted.
A Python list is an ArrayList/vector, not a linked list. CL lists are linked lists of cons cells.
Correct. There's no such thing as a python a-list, or p-list, and they can't share structure. There's overlap between programming in Python with lists, and programming in Lisp with lists, but not as much as it appears. In idiomatic Lisp, it's rather common to search a list for a value, cdr it, and cons that cdr to the collection you're building up. Python has nothing like that, because what I said makes no sense in t…
If you want shared structure of lists in Python, use `itertools.chain`.
If you want key-value mappings, use a dict. Order is preserved by default nowadays, and conversion to/from an iterable of 2-tuples is trivial.
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 ),…
https://discourse.julialang.org/t/ann-package-conditions-jl/...