201–210 of 339 posts
i cant even install this program on my system because of common lisp’s insane dependency management so count me as unconvinced
Earlier quoted context omitted.
> If LISP is so fantastic why isn't there a serious effort to make it multicore-friendly? There is. It's called Clojure.
Other commenters say it's nowhere close to what I'm looking for, btw. And let me repeat that I am not looking for the old-school OS threads support. Almost all programming languages have that. It's nowhere nearly good enough.
Earlier quoted context omitted.
Racket is no longer called PLT-Scheme because its not a Scheme, though it includes some and is still closely related.
What about Racket makes it not a Scheme?
https://racket-lang.org/new-name.html
Racket qua Racket (and PLT Scheme before the rename) didn't conform to any of the existing Scheme specs (it was something like R5RS minus some things it didn’t like, plus some things from R6RS, plus a whole bunch of its own stuff.)
Reminder, HN is built/runs-on a dialect of Lisp (Arc). On a single server. On a single core.
Earlier quoted context omitted.
I have pg's list of nine Lisp ideas [1]. What of these are missing in Janet? My guess is that only 9th one but I would like to understand Lisp (any) vs Janet point. [1] www.paulgraham.com/diff.html
LISP originally came in an implementation (LISP I) and LISP is short for List Processor. Janet looks like a really great language&implementation, but it is not similar to that specific List Processor, for example given that it does not use linked lists at its core.
does Clojure?
I can implement a Scheme interpreter that passes most test suites using vectors instead of linked lists, would you not consider it a lisp?
I like lisps syntactically. The only thing stopping me from using it more frequently is the lack of static typing. I wasn't always a stickler for static typing, but I've spent a lot of time working with Scala and TS and the main advantage for me is ease of refactoring and avoiding NPEs. EDIT: What I'm continuously evaluating for myself is Clojure specifically
Clojure is head and shoulders above other lisps. Watch Rich Hickey's Sermons From the Mount in the years following Clojure's release and you may never be the same again. At least that was my experience. David Nolen's Clojurescript videos are similarly riveting. Clojure also has far more reach than any other lisp with implementations for JS, JVM, .Net and recently Dart/Flutter. It also has a library - libpython - for…
The ecosystem? The lack of first class continuations? All the things that can be portably implemented in any language?
Earlier quoted context omitted.
Yes. That's a consequence of language design - unboxed arrays of structs mean no object identity, which means that operators like SETF and EQ no longer have their invariants satisfied when performing assignment to such arrays.
Sure, there may be reasons for it, but it means you can’t really build zero cost abstractions. For example, you can’t make a simple 2D vector object with the standard operations defined over it and then store those vectors in flat arrays. This is something that can trivially be done in C++, Rust, etc.
This week I'm scaling back some abstractions, writing more Fortran-like code on specialized arrays than individual objects, for the sake of zero cost.
I appreciate a little bit of a headwind against inventing new abstractions too casually. But it does remind me of programming in C or Forth. That's not everyone's cup of tea.
Earlier quoted context omitted.
LISP originally came in an implementation (LISP I) and LISP is short for List Processor. Janet looks like a really great language&implementation, but it is not similar to that specific List Processor, for example given that it does not use linked lists at its core.
>> it does not use linked lists at its core does Clojure? I can implement a Scheme interpreter that passes most test suites using vectors instead of linked lists, would you not consider it a lisp?
My Symbolics Lisp Machine has a Lisp implementation where some form of vectors are an optimization of lists (-> CDR coding). But that's an implementation detail. For most purposes the thing behaves as it uses linked lists - and even has primitive operators for linked lists as CPU instructions.
CLISP, another Lisp implementation, has its own virtual machine, written in C. There too, CAR, CDR, CONS are primitive operations in the VM:
[1]> (defun foo (list) (cons (cdr list) (car list)))
FOO
[2]> (disassemble #'foo)
Disassembly of function FOO
1 required argument
0 optional arguments
No rest parameter
No keyword parameters
5 byte-code instructions:
0 (LOAD&CDR&PUSH 1)
2 (LOAD 2)
3 (CAR)
4 (CONS)
5 (SKIP&RET 2)
Then there is this meaning that Lisp is a very diverse group of languages bases on largely undefined criteria. Like C is a member of the ALGOL language family.
That's the "Lisp family": It includes JavaScript/ECMAScript, Dylan, Clojure, Scheme, Racket, R, SKILL... Some have s-expressions, some not. Some use linked lists, some not. Some are object-oriented, some not. And so on.
But for practical purposes it's meaningless: if I want to know about how a particular Scheme construct works, I would look into a Scheme documentation (or its particular implementation), not into a Lisp book.
Scheme, Clojure, .. all have their own language family by now: there are language definitions, a bunch of similar implementations, shared code, books, ...
It's also funny how people claim that language X is a Lisp, as if that would mean something "special" or even "better". There are lots of excellent and useful programming languages out there, which are not Lisp.
Earlier quoted context omitted.
Yes. That's a consequence of language design - unboxed arrays of structs mean no object identity, which means that operators like SETF and EQ no longer have their invariants satisfied when performing assignment to such arrays.
Sure, there may be reasons for it, but it means you can’t really build zero cost abstractions. For example, you can’t make a simple 2D vector object with the standard operations defined over it and then store those vectors in flat arrays. This is something that can trivially be done in C++, Rust, etc.
It means the abstractions produce the same code as having written the same manually without the abstraction, e.g. having a class with virtual methods versus having a struct with function pointers as fields.
the fact that there are repeated statements like "why X" where X = some language, points to rationalization more than reality; if the language is really so good, there won't be any need for a "why" articles on it. I haven't seen a repeated series of "Why C#" or "Why Go" or "Why Swift" articles. I also think Lisp is way overrated. Swift is based on Miranda which is based on Hope which borrows heavily from SML...There'…
Then you aren't long enough on HN.