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

Not Lisp again (2009)

funcall.blogspot.com

Post reply on HN
Print view View original

191–200 of 276 posts

Re: Not Lisp again (2009)

#191

Post by int_19h »

Chyzwar wrote: post #156
gedy wrote: post #130

Earlier quoted context omitted.

True, but the issue is that most academic and vast majority of paid coding roughly looks like the JavaScript example (C/C++/Java/JS/etc) - so to most the Lisp style looks odd and hard to parse, not the raw symbol count.

Lisp style is more elegant, almost everything is either data or function. Other languages you mention are massively more complex and difficult to understand. For me C++ is some kind of clusterfuck of symbols/keywords/operators and plain magic. After you learn prefix notation, Lisp is super easy. Unfortunately in the world were "worse is better" we discard beautiful and smart: Smalltalk, Lisp and ML. Instead we build…

I find the argument that Lisp needing fewer symbols means that it's simpler to be suspect. Imagine if we took English, and replaced all punctuation with parentheses. Would it be "simpler"? In some very academic way, probably. I'm not at all confident it would actually be easier to read.

This is really something that needs input from people who professionally deal with the way our brains process visual information, especially text. It might be that there's value in having more varied and fancy punctuation, e.g. because the differences between ( and [ and { serve as anchor points for visual pattern matching.

It would be interesting to have an experiment whereby people not previously exposed to any PL have to analyze a code snippet in, say, Lisp vs JS vs Python side by side, and discover its structure (e.g. by drawing it as a block diagram).

Re: Not Lisp again (2009)

#192

Post by lispm »

hasenj wrote: post #104
pmoriarty wrote: post #6

The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today. Today the objections I hear are more along the lines of: 1 - All those parenthesis. (Still a top objection) 2 - Lisp doesn't look like or work like what I'm used to. 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. 4 - There aren't nearly a…

_My_ main objection to lisp is that it's confusing. I don't mean the syntax is hard to grasp. I mean the way it looks. It becomes very confusing when the program grows in size. This is not unique to Lisp. It applies to all dynamic languages that don't have strong tooling support (IDE's with intellisense). (Maybe I am wrong about Lisp being dynamic; my only experience has been with "arc"; and I have had someone tell m…

> When I need to change the inputs or outputs of a function, I have no idea if I've done it correctly or not; due to the lack of type checking.

Well, the good news is Common Lisp has runtime types and some implementations even support limited forms of compile time checking.

The Common Lisp Object System allows you to use classes. One then gets nice runtime errors.

    CL-USER> (defmethod add ((a number) (b number)) (+ a b))
    #

    CL-USER> (defmethod add ((a string) (b string)) (concatenate 'string a b))
    #

    This works then:

    CL-USER> (add 1 2)
    3

    Now this will get a runtime error, because there is no method for these arguments:

    CL-USER> (add "1" 2)
One can also declare types. For example that something is an integer or a subset of integers...

    CL-USER> (defun baz (a)
               (flet ((foo (a b)
                        (declare (integer a b))
                        (+ a b)))
                 (foo a "b")))
The SBCL compiler then complains, that above code has a type error:

    ; in: DEFUN BAZ
    ;     (FOO A "b")
    ; 
    ; caught WARNING:
    ;   Constant "b" conflicts with its asserted type INTEGER.
    ;   See also:
    ;     The SBCL Manual, Node "Handling of Types"

Re: Not Lisp again (2009)

#193

Post by int_19h »

groby_b wrote: post #82
jlongster wrote: post #52

Earlier quoted context omitted.

That's not really the same thing at all. What's missing is the ability to close over values, which is a key part of first-class functions. You could not re-create the original example in C, which is to return a new function. You'd have to return some sort of object that keeps a reference to the function pointer, and provides a special mechanism for calling it, i.e. a poor man's closure.

Sigh. How soon they forgot. You create a thunk that provides the closure. Which used to be a common thing to do when you wrote C code. Note: I'm not saying that C could express closures and first-class function objects anywhere near as neatly as Lisp. But the idea that only Lisp allowed you to use them, and C was the land of straightforward procedural code... does not represent what I saw back then. Just as you can w…

There's no way to create a thunk in portable C even today, much less back then. You had to do some form of machine code generation on the fly, which instantly limited it to some particular architecture / calling convention at the very least.

Re: Not Lisp again (2009)

#194

Post by int_19h »

brlewis wrote: post #73
Will_Parker wrote: post #44

Earlier quoted context omitted.

Indeed, posts like this are of historical interest, but today, take Python: dx = 0.0001 def deriv(f): return lambda x: (f(x + dx) - f(x)) / dx This works just the same as the author's example and looks even more like the calculus formula people are used to.

f(x + dx) does look more conventional than (f (+ x dx)), but (/ numerator denominator) looks more like the conventional fraction syntax than putting a / somewhere in the middle of a line.

I don't know, things like 1/2 are pretty conventional fraction syntax.

But if you really wanted to, you could always do the same thing in Python, since newlines are basically just ignored inside parentheses:

   (numerator /
    denominator)
Or even place / on its own line if so desired.

Re: Not Lisp again (2009)

#195

Post by Frondo »

brianberns wrote: post #152
lisper wrote: post #138

Earlier quoted context omitted.

> 1 - All those parenthesis. (Still a top objection) If you actually count parens fairly you will find that Lisp has no more than any other language, it's just that other languages use a mix of parens, square brackets and curly braces whereas Lisp only uses parens. Also, if you really don't like parens, you can get rid of a lot of them using macros. See e.g.: https://github.com/rongarret/ergolib and in particular the…

>> 1 - All those parenthesis. (Still a top objection) > If you actually count parens fairly you will find that Lisp has no more than any other language Bull. For example, compare the Lisp factorial function from the article: (define (fact x) (if (zero? x) 1 (* x (fact (- x 1))))) with the corresponding F# implementation: let rec fact x = if x = 0 then 1 else x * fact (x - 1) That's 7 vs. 1 pair of parens. Also, the p…

Yeah, you know what else I'm realizing? All the different kinds of punctuation let my eyes skim over different parts of code so easily, and lisp doesn't give me that.

You know how, when you're reading natural language, you don't actually read individual letters, not once you have any reading fluency? That's how I read code, too, I'm realizing. When I see the parentheses in C#, my brain just goes "oh that's a method/function call" and I can either skip over the contents of the parens or read them if I need to. Reading comprehension is pretty quick.

Looking at all the parens of even that simple lisp factorial, and I realize that I'm feeling a lot of cognitive load that would simply never go away, because the punctuation doesn't let me filter any of it out. I'd have to read everything more carefully.

Re: Not Lisp again (2009)

#196

Post by int_19h »

archgoon wrote: post #106
klibertp wrote: post #101

Earlier quoted context omitted.

Are you sure random people are going to recognize "3/4" notation? It could be different for "3 ÷ 4", but I think "3/4" is not widely used outside of programming?

Have you ever looked at a cookbook? http://www.tasteofhome.com/recipes/how-to-cook/how-to-cut-do... Taken a drive? https://c1.staticflickr.com/5/4149/5174138836_6603010a7d_b.j...

It is a country-specific convention. What's written as e.g. ½ in US would be more commonly written with a horizontal dividing line in many other places, or simply as 0.5. Similarly, 2.5 instead of 2½ etc.

Re: Not Lisp again (2009)

#197

Post by lacampbell »

jacquesm wrote: post #121
pmoriarty wrote: post #6

The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today. Today the objections I hear are more along the lines of: 1 - All those parenthesis. (Still a top objection) 2 - Lisp doesn't look like or work like what I'm used to. 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. 4 - There aren't nearly a…

To me the hard part about lisp is that every programmer that uses lisp tailors it so to their own taste that it can become quite hard to read the 'top level' of a lisp program without first having gone through all the lower layers. It is as if every project in lisp somehow magically develops its own DSL. That's a high hurdle for newbies to clear.

Does the other way really scale though?

I mean, the "state of the art" is to have readable code everywhere. What readable really means is "have each component defined in terms of the standard library". This involves a lot of repetition and a lot more code, with the advantage that any part of the program can be understood by a new programmer.

The Lispy/Bottom Up way is to write a language, then solve your problem in terms of the language you just wrote. Only at the very low levels are you really dealing with standard library stuff. The advantages are obvious, but the disadvantage of this is you have to learn the DSL as well.

Have you experienced both approaches?

Re: Not Lisp again (2009)

#198

Post by int_19h »

Questron wrote: post #143
Sharlin wrote: post #137

Earlier quoted context omitted.

Passing function addresses as parameters is easy. It's more difficult to return a nested function that closes over the outer function's variables.

Not really in machine language or even BASIC (see below).

Your BASIC example doesn't have any local variables to close over. It just references a global. That defeats the whole point of closures.

Passing or returning first-class functions aren't a problem. First-class closures (function pointer + state) are.

Re: Not Lisp again (2009)

#199

Post by lacampbell »

Jach wrote: post #168
gizmo385 wrote: post #157

Earlier quoted context omitted.

I feel like there should be a "No True LISP" fallacy in CS... It expresses pretty much all of the core principals of a LISP. If it looks like a LISP, thinks like a LISP, behaves like a LISP; then do you really gain anything by trying to separate from other LISPs?

Is Python a LISP? Is JavaScript a LISP? Is Java a LISP? What do you mean by LISP, by its core principles? What does a different set of core principles look like that lends itself to a different family? I threw in my vague classification above: sexps and macros. But you can have macros without sexps, and sexps without macros (lots of "toy lisp interpreters" do that), are they LISPs? Lastly one wonders why we don't go…

Lastly one wonders why we don't go calling all these C-like languages ALGOLs.

We sometimes do though, don't we? Not that terminology, but I often see the people talking about "curly brace languages" or "C/C++/Java/C#".

Re: Not Lisp again (2009)

#200

Post by lacampbell »

marcosdumay wrote: post #13
pmoriarty wrote: post #6

The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today. Today the objections I hear are more along the lines of: 1 - All those parenthesis. (Still a top objection) 2 - Lisp doesn't look like or work like what I'm used to. 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. 4 - There aren't nearly a…

To be fair, the one time I decided to do something biggish and kinda important in Lisp, I stopped at #3. Not exactly because "it does not have many libraries", but because "library for X, Y and Z are not there and I don't want to write them". Oddly, Haskell has a similar problem, but going through C code by the FFI does not feel like a problem. I don't think why it does in Lisp, it may be just a matter of better docu…

I can vouch for rackets FFI, for what it's worth.
Post reply on HN