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

91–100 of 102 posts

Re: CL21: An experimental project redesigning Common Lisp

#91

Post by jwmc »

jimbokun wrote: post #78
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…

I think the * 's around * hash* is just a convention indicating a global variable in Common Lisp. (Edit: trying to escape HN formatting conventions.)

Dynamic variable, rather than global, but yes - it's just a convention.

Re: CL21: An experimental project redesigning Common Lisp

#92

Post by jwmc »

pnathan wrote: post #27
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…

Huh. I like the distinction of car/cdr meaning pointers vs first/rest meaning "start of list/rest of list". It weirded me out at first, but I came to really appreciate it.

Yep. It's good to have both - the car is the first of a list, and the cdr is the rest, but a cons isn't always a list. Having first and rest exclusively would be short-changing us conceptually.

Re: CL21: An experimental project redesigning Common Lisp

#93

Post by agumonkey »

dragonwriter wrote: post #75
agumonkey wrote: post #43

Earlier quoted context omitted.

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 wit…

I know car/cdr history, and didn't like it. Only after trying clojure[1], I had a weird sensation that I was missing car/cdr and that writing in scheme felt better.

If I tried to explain deeper, Lisp focus on recursion over cons-lists was so foreign to the mainstream paradigms, that car/cdr, as most used operations, became symbolic axioms in my mind.

[1] which goes all in on the intuitive, human, pragmatic side of things, throwing away some old lisp idioms.

Re: CL21: An experimental project redesigning Common Lisp

#94

Post by lispm »

agentultra wrote: post #90
dragonwriter wrote: post #88

Earlier quoted context omitted.

> There's nothing intuitive about programming. If that was true, than naming constructs in programming languages wouldn't matter at all. > If that's the biggest hurdle to learning Lisp Its not, its just one of many small hurdles that keep Lisp as a fairly niche language, despite its strengths when viewed from a 30,000 foot level. > Try teaching C declaration syntax to someone. C-family languages declaration syntax is…

> If that was true, than naming constructs in programming languages wouldn't matter at all. http://dictionary.reference.com/browse/intuitive I think we're diverging off the track here. Naming is important. Programming has borrowed quite a lot from various places to name the often weird, alien "things" we work with. But a rose by any other name is still a rose. There is no name for which there exists an analog in natu…

>tldr; there were once only commercial implementations of Common Lisp that cost far too much and delivered little. Because money.

Which is complete bullshit.

Re: CL21: An experimental project redesigning Common Lisp

#95

Post by bsummer4 »

Retra wrote: post #33
bad_user wrote: post #18

Earlier quoted context omitted.

I don't know German, but I have a huntch that Romanian, my native language, is more complex than German, except that Romanian has firm roots in latin, therefore more people unfamiliar with both will have an easier time with Romanian, since we have a significant portion of our vocabulary similar to Italian or Spanish, plus we borrowed words from French, along with many neologisms coming straight from English. Just bec…

Familiarity makes it easier to learn, not easy. Just as long as you don't betray anyone's expectations about what they already know. I remember struggling with Haskell because there is a function called 'nub', which wasn't anywhere near what I would have called the function if I had named it. Hoogle says "(The name nub means `essence'.)" In Lisp it is called 'remove-duplicates.' In Python it is list(set(x)). In SQL i…

nub is widely recognized to be a terrible function; it's not indicative of anything

Re: CL21: An experimental project redesigning Common Lisp

#96

Post by agentultra »

lispm wrote: post #94
agentultra wrote: post #90

Earlier quoted context omitted.

> If that was true, than naming constructs in programming languages wouldn't matter at all. http://dictionary.reference.com/browse/intuitive I think we're diverging off the track here. Naming is important. Programming has borrowed quite a lot from various places to name the often weird, alien "things" we work with. But a rose by any other name is still a rose. There is no name for which there exists an analog in natu…

>tldr; there were once only commercial implementations of Common Lisp that cost far too much and delivered little. Because money. Which is complete bullshit.

What is complete bullshit? I'm told the Lisp machines were awesome but I've never had the opportunity to use one. I was only starting programming on an Amiga 500 around 89-90 in BASIC. I wouldn't even know what Lisp was until 2007-2008.

Or is my terribly lazy and misinformed history of the AI winter and the rise of inexpensive Unix mainframes inaccurate as to the reason why Lisp suddenly dropped out of vogue? I've only read accounts of it online. If you have a link to a better source I'd be happy to read it. :)

Re: CL21: An experimental project redesigning Common Lisp

#97

Post by phabian »

agentultra wrote: post #90
dragonwriter wrote: post #88

Earlier quoted context omitted.

> There's nothing intuitive about programming. If that was true, than naming constructs in programming languages wouldn't matter at all. > If that's the biggest hurdle to learning Lisp Its not, its just one of many small hurdles that keep Lisp as a fairly niche language, despite its strengths when viewed from a 30,000 foot level. > Try teaching C declaration syntax to someone. C-family languages declaration syntax is…

> If that was true, than naming constructs in programming languages wouldn't matter at all. http://dictionary.reference.com/browse/intuitive I think we're diverging off the track here. Naming is important. Programming has borrowed quite a lot from various places to name the often weird, alien "things" we work with. But a rose by any other name is still a rose. There is no name for which there exists an analog in natu…

This is a classic: http://www.flownet.com/gat/jpl-lisp.html Also check his open code lisp section! I would like to add as somebody whose first language was lisp, car/cdr never represented a problem. It looks more balanced than first/rest. The thing that got me were emacs, SICP lectures and the whole idea of lisp writing lisp. I don't think changing syntax would help much because lisp attracts certain types of people (I believe).

Re: CL21: An experimental project redesigning Common Lisp

#98

Post by Retra »

bsummer4 wrote: post #95
Retra wrote: post #33

Earlier quoted context omitted.

Familiarity makes it easier to learn, not easy. Just as long as you don't betray anyone's expectations about what they already know. I remember struggling with Haskell because there is a function called 'nub', which wasn't anywhere near what I would have called the function if I had named it. Hoogle says "(The name nub means `essence'.)" In Lisp it is called 'remove-duplicates.' In Python it is list(set(x)). In SQL i…

nub is widely recognized to be a terrible function; it's not indicative of anything

It's not? Then I suppose princ is a fine name for a print function.

Re: CL21: An experimental project redesigning Common Lisp

#99

Post by lispm »

agentultra wrote: post #96
lispm wrote: post #94

Earlier quoted context omitted.

>tldr; there were once only commercial implementations of Common Lisp that cost far too much and delivered little. Because money. Which is complete bullshit.

What is complete bullshit? I'm told the Lisp machines were awesome but I've never had the opportunity to use one. I was only starting programming on an Amiga 500 around 89-90 in BASIC. I wouldn't even know what Lisp was until 2007-2008. Or is my terribly lazy and misinformed history of the AI winter and the rise of inexpensive Unix mainframes inaccurate as to the reason why Lisp suddenly dropped out of vogue? I've on…

You wrote: '>tldr; there were once only commercial implementations of Common Lisp that cost far too much and delivered little. Because money. Which is complete bullshit.'

that's bullshit. Complete bullshit.

Lisp Machines were programmed in ZetaLisp (aka Lisp Machine Lisp) and Interlisp. Not Common Lisp. Common Lisp appeared later on Lisp Machines as an additional Lisp dialect and software was than gradually moved to Common Lisp.

The first version of Common Lisp was initially designed between 1982 and 1984. The defining book was published in 1984.

CMUCL, a free Common Lisp, appeared early. CMUCL was many years forked into SBCL, but CMUCL is still available today. KCL, which then was patched into AKCL, ... Which today is ECl, MKCL, GCL! ... appeared early. CLISP, a free implementation in C, appeared early.

A bunch of mid-priced Common Lisps was available for Windows and Macs.

The commercial ones for Unix were Allegro CL, Lucid CL and LispWorks. They were slightly more expensive and great.

There was always a choice of various Common Lisp implementations...

'Unix mainframes?' What is a Unix mainframe? Unix ran on various types of machines, but there was no rise of a Unix mainframes.

Common Lisp was early available with Lisp. Every major university had a site license for a commercial Common Lisp. I used CL on a SUN cluster. Steve Jobs shipped his first NeXT machine with Allegro CL included.

Common Lisp was never bound to Lisp Machines or only on Lisp Machines. Far from it. The whole idea of Common Lisp was to have the language available on a wide variety of machines: personal workstations, PCs, Unix systems, IBM Mainframes and supercomputers like the Cray.

Re: CL21: An experimental project redesigning Common Lisp

#100

Post by Immortalin »

bmh100 wrote: post #71
Immortalin wrote: post #52

Earlier quoted context omitted.

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 subrou…

Both :D
Post reply on HN