CL21: An experimental project redesigning Common Lisp • Hacker News Board

Re: CL21: An experimental project redesigning Common Lisp

#31

Post by chaoky » Fri, Feb 20, 2015, 1:29 AM UTC

bad_user wrote: post #18

chrisduesing wrote: post #8

Earlier quoted context omitted.

I do. There is a reason for the success of Ruby and Python, and why Elixir is dragging Erlang in to the present. It turns out you don't just have to write your language in the shape of the machine/vm but it can be a tool conformed to the mind of the programmer. "princ" is not easy to remember, read or associate to other things one already knows. The point of a project like this should not be to save old school progra…

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…

This. Arguing that Common Lisp sucks because the names of functions are not sufficiently python/C/Algol-like is like arguing Chinese languages are never going to become widely accepted because they aren't sufficiently like European languages. People who argue against car/cdr are the same people who will blindly accept printf, strlen, scanf (wtf?), __le__, zip. They accept those names because they actually learned the language and discovered those were trivial details and don't judge something so superficially. (also, ~95% of common lisp names are more like with-open-file, or define-setf-expansion, or make-load-form, or most-positive-float, or standard-input, instead of, what mkStr, , isalnum, fprintf, ? :, and the like)

Re: CL21: An experimental project redesigning Common Lisp

#32

Post by rudiger » Fri, Feb 20, 2015, 1:30 AM UTC

chrisduesing wrote: post #8

TeMPOraL wrote: post #7

Earlier quoted context omitted.

Honestly? Mostly because Lisp conventions predate "the rest of the programming world". As for while-let1, it's a while-let with just one variable binding (I guess I'd prefer them to stick with just while-let). There's usually a very good reason behind all those "unusual names" of Common Lisp. I don't think that dumbing things up so that they look more similar to everything else in a language that is already different…

I do. There is a reason for the success of Ruby and Python, and why Elixir is dragging Erlang in to the present. It turns out you don't just have to write your language in the shape of the machine/vm but it can be a tool conformed to the mind of the programmer. "princ" is not easy to remember, read or associate to other things one already knows. The point of a project like this should not be to save old school progra…

Erlang, despite its fusty syntax, already feels like the future for anyone using it.

Re: CL21: An experimental project redesigning Common Lisp

#33

Post by Retra » Fri, Feb 20, 2015, 1:42 AM UTC

bad_user wrote: post #18

chrisduesing wrote: post #8

Earlier quoted context omitted.

I do. There is a reason for the success of Ruby and Python, and why Elixir is dragging Erlang in to the present. It turns out you don't just have to write your language in the shape of the machine/vm but it can be a tool conformed to the mind of the programmer. "princ" is not easy to remember, read or associate to other things one already knows. The point of a project like this should not be to save old school progra…

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 it is 'select distinct.'

So what advantage does nub pose? Not one of clarity, but of convenience for those "in the know." (Which is not those who are learning the language.)

Re: CL21: An experimental project redesigning Common Lisp

#34

Post by arturventura » Fri, Feb 20, 2015, 1:46 AM UTC

I've been thinking about this for a while. I've wrote some thoughts I had over the years about modernising Lisp.

https://news.ycombinator.com/item?id=9078444

Re: CL21: An experimental project redesigning Common Lisp

#35

Post by agentultra » Fri, Feb 20, 2015, 1:49 AM UTC

jwr wrote: post #14

As a former common lisper, I don't see the point. Clojure is better in pretty much every respect and incorporates many fresh ideas (such as excellent concurrency support). Syntax is the least of CL's limitations. I didn't switch to Clojure because it was "easy" (quite the contrary). And no, I do not miss reader macros. Perhaps more surprisingly, I don't miss CLOS at all, much as I always admired its design. It's just…

Clojure is nice and all but I wouldn't suggest it's even close to being better in many respects, let alone every respect.

When I was working with it on a non-trivial project I despised the JVM stack traces, image-less environment, and lack of access to the reader. I assume that eventually Clojure will steal these ideas and adopt it in its own way... but these old, un-modern ideas of conditions and restarts, images, and reader macros are actually really useful. I hope they do take a hint.

Re: CL21: An experimental project redesigning Common Lisp

#36

Post by omaranto » Fri, Feb 20, 2015, 1:52 AM UTC

jwr wrote: post #14

As a former common lisper, I don't see the point. Clojure is better in pretty much every respect and incorporates many fresh ideas (such as excellent concurrency support). Syntax is the least of CL's limitations. I didn't switch to Clojure because it was "easy" (quite the contrary). And no, I do not miss reader macros. Perhaps more surprisingly, I don't miss CLOS at all, much as I always admired its design. It's just…

I guess performance might still be a reason to prefer Common Lisp to Clojure.

Re: CL21: An experimental project redesigning Common Lisp

#37

Post by chrisduesing » Fri, Feb 20, 2015, 2:20 AM UTC

chaoky wrote: post #31

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…

This. Arguing that Common Lisp sucks because the names of functions are not sufficiently python/C/Algol-like is like arguing Chinese languages are never going to become widely accepted because they aren't sufficiently like European languages. People who argue against car/cdr are the same people who will blindly accept printf, strlen, scanf (wtf?), __le__, zip. They accept those names because they actually learned the…

No one is arguing that CL sucks, but that if you are going to re-skin the whole thing with learnings from modern languages, with features like string interpolation, then you might as well make the function names more intuitive while you are at it.

The specific example is talking about doing away with the format function in favor of the princ function. What is the argument against calling it print? No one is suggesting fprintf by the way.

You and the parent are also citing spoken languages, and certainly if you are a Chinese speaker then the difference between princ and print is going to be nominal to you. However, if you are a native English speaker, not so much. Really though, once you learn one programming language with standard library function names in English, then the second will be easier to learn if it uses similar names.

Back to the subject at hand, the case being made here is that most modern languages choose things a bit easier for the brain to parse; they aren't overly shortened, they aren't Hungarian notation, etc.. The reason for that is that it requires enough brain power to learn a new language, its structure, libraries and quirks without also having to memorize strange sequences of consonants.

Here is some code I wrote yesterday. Even if you never saw Ruby before in your life, don't know what blocks are, and have no idea what the array/enum functions are, you can probably figure out what this code is doing.

invoices = @organization.subscriptions.collect{|s| s.invoices}.flatten

current_invoices = invoices.select {|i| i.invoice_period_begin_date Date.today }

current_paid_invoices, current_unpaid_invoices = current_invoices.partition {|i| i.paid?}

and THAT is why if you are designing a new language from scratch, you should strongly consider using intuitive function names.

Re: CL21: An experimental project redesigning Common Lisp

#38

Post by gongador » Fri, Feb 20, 2015, 2:24 AM UTC

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…

Because PRINT also exists, and doesn't do the same thing PRINC does.

http://www.lispworks.com/documentation/lw61/CLHS/Body/f_wr_p...

Re: CL21: An experimental project redesigning Common Lisp

#39

Post by latiera » Fri, Feb 20, 2015, 2:24 AM UTC

arh68 wrote: post #20

I think this is an okay idea, but the comparison to Clojure is really lacking. Why build on CL when you can build on Clojure? I get the inter-operability, but when Multi-Threading and Multi-Processing is listed under Deferred , Clojure could provide so much of that for free. On Clojure, etc.

Because clojure is garbage?

Also, Java/JVM suck ass, why would anyone willingly work with that whole mess?

Re: CL21: An experimental project redesigning Common Lisp

#40

Post by Guthur » Fri, Feb 20, 2015, 2:31 AM UTC

In the examples I see nothing overly compelling which would justify fragmenting the mind share.

Some of them could possible be considered for alexandria https://common-lisp.net/project/alexandria/. Admittedly I am not sure how alive development is but it certainly would be worth breathing new life into as it is probably the most heavily used CL library.

As things like STM and lazy which Clojure has, they have been implemented at the library level for CL.

https://common-lisp.net/project/cl-stm/

The beauty about a Lisp is that you can easily add so much on top of the language that will feel as if it was always there. CLOS is a good example of this.

In the case of JVM with CLojure, and of course others will disagree, I don't think accessing the Java ecosystem is a good thing. The mindset there is monolith "Enterprise Solutions" "Inversion of Control frameworks" which invariable mean systems that are so complex the authors don't even understand them and lets write XML above all else.

Also if you want CL->Javascript; Parenscript.