Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CL21: An experimental project redesigning Common Lisp

cl21.org

Post reply on HN
Print view View original

71–80 of 102 posts

Re: CL21: An experimental project redesigning Common Lisp

#71

Post by bmh100 »

Immortalin wrote: post #52
mark_l_watson wrote: post #2

This looks cool enough but it would need a big community to really change the common lisp landscape (in my opinion). I wonder how the lazy sequence support stacks up to Clojure, Haskell, etc. support. One difficulty with promoting a more modern layer to common lisp is that Clojure is already such a productive and practical language. I have written a few common lisp books, and remain a fan of the language, and an upgr…

I can understand the reasons why people prefer to target the CLR/JVM/LLVM/BEAM/Name-your-favorite-vm but I yearn for more compiled-to-native-languages such as Golang. As attractive as partially-compiled/interpretated languages are, I simply do not enjoy creating programs in a language that can be decompiled to source so easily. We need more languages that have decent performance instead of having to drop down to poin…

By functional Fortran, do you mean like a "functional programming language" or "more productive Fortran"? As one who has developed in Fortran before, I would also like to see enhanced functional capabilities, as well as a more productive way to write code. I have spent so much time on declaring variables and function arguments over and over across subroutines that it becomes quite a pain. To avoid writing many subroutine interfaces, I also tend to put everything in a single module. My dream is to combine the expressiveness of Lisp with the numerical performance and memory efficiency of Fortran and C.

Re: CL21: An experimental project redesigning Common Lisp

#72

Post by one-more-minute »

tempodox wrote: post #70
one-more-minute wrote: post #56

Earlier quoted context omitted.

Have you met Julia? I don't know if I'd quite call it a functional Fortran, but it's not that far off, either.

Sadly, Julia will not produce stand-alone executables in the foreseeable future. It's nothing more than a bit of native glue between two Python scripts. The main acceptance group doesn't use it for production, only in the lab.

Stand-alone executables are on the roadmap for Julia 0.4, which is on the horizon (next six months or so).

Re: CL21: An experimental project redesigning Common Lisp

#73

Post by bmh100 »

agentultra wrote: post #64
bane wrote: post #60

Earlier quoted context omitted.

Yeah, lots of this is just swapping out one awkward keyword for another. If I were doing this I'd also get rid of the * around the hash keyword and either just go with the keyword 'hash' or replace it all together with an operator. It's almost like lispers want the opposite of java, long verbose keywords and syntax and then as short as possible variable names. Why not switch the parens to something that's a single ke…

> Yeah, lots of this is just swapping out one awkward keyword for another. Many a well-intentioned Lisper eventually begins to see deficiencies where there are none and attempts to improve their implementation of choice. Common Lisp is one such target because people coming from in-vogue languages are used to the language changing every year or two. Invariably this leads to superficial changes at best which are enable…

> People complain about the lack of run-time support for concurrency and IO in the specification. I don't think they realize, coming from other languages, that Common Lisp doesn't need it. The specification defines the language and a minimal ball of mud for doing practical work with it. Things like concurrency, threading, and IO are implementation issues and have been solved by high-quality open-source implementations for quite some time. We even have good libraries that provide a cross-platform layer to things like threading.

In that case, it would be useful to newcomers to introduce those facilities into the core of the language. The more batteries are included, the easier language adoption becomes.

> But ultimately people bike-shed over "car/cdr" and specialized functions for specific data-types (ie: AREF, GET-HASH, etc). You can write higher-order functions to abstract away sequence access and iteration if you want: people have and there are good libraries for it.

To me, this is not bike shedding, but user experience design. The more learning that is required to accomplish a given goal the first time, the less productive and more difficult that goal becomes. "car" and "cdr" are not intuitive to me. Why not use "first" and "rest" or "head" and "tail" for CL21 instead?

Re: CL21: An experimental project redesigning Common Lisp

#74

Post by gjm11 »

agumonkey wrote: post #69
gjm11 wrote: post #65

Earlier quoted context omitted.

Neat, but unfortunately the equivalent of CADR (second item in list: first-of-rest) is then FRST, which I think would just be too easy to misinterpret as meaning "first" when reading or writing code in a hurry.

I don't know if c r shortcuts are still used often nowadays (SICP advocates for abstraction layers, accessor functions, CL has destruct-bind, and ml uses pattern matching to dig into data).

Nor do I -- but I'm pretty sure that those shortcuts are pretty much the only good reason for caring much about having names that resemble CAR/CDR in the way FST/RST do. (For any other purpose, I think FIRST/REST are obviously better than FST/RST.)

Re: CL21: An experimental project redesigning Common Lisp

#75

Post by dragonwriter »

agumonkey wrote: post #43
jerf wrote: post #22

Earlier quoted context omitted.

As a non-Lisper, I can assure you beyond a shadow of a doubt that having "car" & "cdr" show up in the first few sections of a tutorial is not something that wins people over to Lisp. I don't mean that I don't understand it. I even know they come from assembler instruction names. And they still look weird to me and still have no meaning despite having read what the abbreviation expands to three or four times. You'd be…

I know and agree, but they have some weird syntactic/linguistic quality: - both 3 letters each - only differ by 1 letter a|d None of the alternatives have these symmetry, and it (very subjectively) shows in the code.

Its not hard to think of things that meet both of those features that are still better mnemonics for things that are common-language descriptions of what the function yields (e.g., cfc/csc or c1c/c2c for "cons first cell, cons second cell")

car and cdr are mnemonics related to the particular instruction set of the first computer on which Lisp happened to be implemented, which is great for people with a background with system programming on that system, but not so good for anyone else.

They're entrenched enough in the language that they are worth changing unless you are intentionally building a new Lisp-like language from scratch with some other main motivation and the change is just a side issue -- and it is clear that having something that doesn't imply list semantics for cons cells like first/rest does is good -- but car/cdr aren't a particularly good pair.

Re: CL21: An experimental project redesigning Common Lisp

#76

Post by agentultra »

bmh100 wrote: post #73
agentultra wrote: post #64

Earlier quoted context omitted.

> Yeah, lots of this is just swapping out one awkward keyword for another. Many a well-intentioned Lisper eventually begins to see deficiencies where there are none and attempts to improve their implementation of choice. Common Lisp is one such target because people coming from in-vogue languages are used to the language changing every year or two. Invariably this leads to superficial changes at best which are enable…

> People complain about the lack of run-time support for concurrency and IO in the specification. I don't think they realize, coming from other languages, that Common Lisp doesn't need it. The specification defines the language and a minimal ball of mud for doing practical work with it. Things like concurrency, threading, and IO are implementation issues and have been solved by high-quality open-source implementation…

> "car" and "cdr" are not intuitive to me. Why not use "first" and "rest" or "head" and "tail" for CL21 instead?

Nothing about programming is intuitive.

The problem here is that you've adopted ideas and notions from another language and are bringing that baggage to Common Lisp. If you learned Common Lisp first you might not have this very issue you describe.

For historical reasons, "car" and "cdr" are the names of special pointers to the elements of a cons cell. There's nothing about them that have anything to do with lists. You just happen to be able to construct lists by linking together cons cells. CAR and CDR simply deference the pointers in the cons cell:

    (atom . atom)
Where atom can be a value or a another cons cell. In this visualization it's useful to think of CAR as referring to the "atom on the left" and CDR referring to the "atom on the right." One or both of those atoms could be a cons cell... so there's nothing about CAR or CDR that has anything to do with notions of "first", "last", "head", or "tail."

Those are higher-order functions for operating on linked list and are in the Common Lisp specification anyway.

Suggesting that Common Lisp should remove them is like saying you should remove pointers from C.

Re: CL21: An experimental project redesigning Common Lisp

#77

Post by jimbokun »

bachmeier wrote: post #4

One of the things I don't like about Common Lisp is the unusual names. Just on the basis of the linked page, CL21 doesn't fix that. Take princ #"Hello, ${name}\n". Why not just use print like the rest of the programming world. Okay, some languages use writeln, etc. But princ? Why not print? A little further down, we see while-let1. Why the number? If you want to call it "Common Lisp in the 21st Century" you need to c…

"In spite of this, it has not had much success (at least in Japan)."

From this and the author's name (Eitaro Fukamachi), I wonder if he is not a native English speaker.

This could shed light on differences in aesthetic choices about function names. Difference between "princ" and "print", or awkwardness of "while-let1" may not resonate as much for a non-native speaker.

Re: CL21: An experimental project redesigning Common Lisp

#78

Post by jimbokun »

bane wrote: post #60
bachmeier wrote: post #4

One of the things I don't like about Common Lisp is the unusual names. Just on the basis of the linked page, CL21 doesn't fix that. Take princ #"Hello, ${name}\n". Why not just use print like the rest of the programming world. Okay, some languages use writeln, etc. But princ? Why not print? A little further down, we see while-let1. Why the number? If you want to call it "Common Lisp in the 21st Century" you need to c…

Yeah, lots of this is just swapping out one awkward keyword for another. If I were doing this I'd also get rid of the * around the hash keyword and either just go with the keyword 'hash' or replace it all together with an operator. It's almost like lispers want the opposite of java, long verbose keywords and syntax and then as short as possible variable names. Why not switch the parens to something that's a single ke…

I think the * 's around * hash* is just a convention indicating a global variable in Common Lisp.

(Edit: trying to escape HN formatting conventions.)

Re: CL21: An experimental project redesigning Common Lisp

#79

Post by GregBuchholz »

beeworker wrote: post #29
jerf wrote: post #22

Earlier quoted context omitted.

As a non-Lisper, I can assure you beyond a shadow of a doubt that having "car" & "cdr" show up in the first few sections of a tutorial is not something that wins people over to Lisp. I don't mean that I don't understand it. I even know they come from assembler instruction names. And they still look weird to me and still have no meaning despite having read what the abbreviation expands to three or four times. You'd be…

Ah, but how would you easily access the number 6 out of the nested list '((((5 4 3 2 1) 6) 7) 8 9) without one of the cute compositions of "car" and "cdr"? In this case, "cadaar". (Rhetorical question. "car" and "cdr" are neat for their cute composition, but I would never inflict that on someone first learning the language.)

For the heck of it, I though I'd try it in scheme with pattern matching...

  (let ((x '((((5 4 3 2 1) 6) 7) 8 9)))
    (syntax->datum
     (syntax-case x ()
       ((((_ p) _) _ ...) #'p))))

Re: CL21: An experimental project redesigning Common Lisp

#80

Post by dragonwriter »

agentultra wrote: post #76
bmh100 wrote: post #73

Earlier quoted context omitted.

> People complain about the lack of run-time support for concurrency and IO in the specification. I don't think they realize, coming from other languages, that Common Lisp doesn't need it. The specification defines the language and a minimal ball of mud for doing practical work with it. Things like concurrency, threading, and IO are implementation issues and have been solved by high-quality open-source implementation…

> "car" and "cdr" are not intuitive to me. Why not use "first" and "rest" or "head" and "tail" for CL21 instead? Nothing about programming is intuitive. The problem here is that you've adopted ideas and notions from another language and are bringing that baggage to Common Lisp. If you learned Common Lisp first you might not have this very issue you describe. For historical reasons, "car" and "cdr" are the names of sp…

> Where atom can be a value or a another cons cell. In this visualization it's useful to think of CAR as referring to the "atom on the left" and CDR referring to the "atom on the right."

Then names like "left" and "right" rather than mnemonics for "contents of address part of register" and "contents of decrement part of register" would make sense.

Post reply on HN