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

Just what does “code as data” mean anyway? (2014)

adambard.com

Post reply on HN
Print view View original

71–80 of 178 posts

Re: Just what does “code as data” mean anyway? (2014)

#71

Post by lloeki »

oregontechninja wrote: post #42
taeric wrote: post #37

Earlier quoted context omitted.

Ultimately, I assert the truth is that we don't know why it didn't succeed more. So, speculation is just that. Take mine that is about to follow as more of it. I would be delighted to know of a way to test some of these ideas. Lisp didn't win because it used to cost money to get a good implementation, and there was no company throwing tons of marketing at it. Now, I specifically don't think it is a case of worse ones…

I theorize lisp isn't used more because of the massive amounts of parenthesis. I think the concepts are great, and it's a great language for certain task, but my right pinky finger hurts just looking at it. New programmers and developers look at that and compare it to something like Go, Python, or JavaScript, and all those look easier to write (although deceptively complex in places) and are 1000x easier to read. A p…

Sweet expressions are a bridge too far IMHO. I would be perfectly content with merely getting rid of those dangling ))))) thanks to simple parentheses insertion† based on a single very simple indent/dedent rule:

> if the next line is indented, anything from the beginning of the current line starting at the indent till a dedent matching the current line indent is wrapped in one set of parentheses.

Seriously, what about this?

    defmacro deftag [name]
      list 'defn name ['& 'inner]
           list 'str ""
                '(apply str inner)
                ""
    
    deftag html
    deftag body
    deftag h1
    deftag p
Now what about the DSL that now downright looks like slim-lang?:

    html
      body
        h1 "Hello World"
        p "How's it going?"
Or look at that:

    defn qsort [coll]
      if (empty? coll)
        coll
        let [pivot (first coll)
             remainder (rest coll)]
          concat
            (qsort (filter (partial > pivot) remainder))
            [pivot]
            (qsort (filter (partial
(even the qsort ones could be removed, but they balance [pivot] somehow)

I'm perfectly happy with writing (+ 1 2 3) or whatever, the only parentheses that bother me are those that are perfectly delineated by indentation already, just as newlines perform the same duty as semicolons. They're just duplicated noise††.

† Other languages perform similar semicolon insertion, with varying degrees of success and ambiguities (JS==terrible, Go==terrific).

†† I know, you're supposed to get used to it and "unsee" them. I know, "paredit!". But seriously if you have to write a tool solely to produce noise, and you have to get accustomed to ignore said noise, well, somehow, something's off.

Re: Just what does “code as data” mean anyway? (2014)

#72

Post by kamaal »

oregontechninja wrote: post #42
taeric wrote: post #37

Earlier quoted context omitted.

Ultimately, I assert the truth is that we don't know why it didn't succeed more. So, speculation is just that. Take mine that is about to follow as more of it. I would be delighted to know of a way to test some of these ideas. Lisp didn't win because it used to cost money to get a good implementation, and there was no company throwing tons of marketing at it. Now, I specifically don't think it is a case of worse ones…

I theorize lisp isn't used more because of the massive amounts of parenthesis. I think the concepts are great, and it's a great language for certain task, but my right pinky finger hurts just looking at it. New programmers and developers look at that and compare it to something like Go, Python, or JavaScript, and all those look easier to write (although deceptively complex in places) and are 1000x easier to read. A p…

This is not true for many reasons. Firstly every time you begin a block of code in any language you add parentheses, So the parentheses count comes out same in all languages.

Secondly, parentheses are a non-issue in lisp. Its almost like reading english text with spaces. After a while(quite quickly in-fact) they are a total non issue.

>>New programmers and developers look at that and compare it to something like Go, Python, or JavaScript, and all those look easier to write

Arguably the biggest problem today is programmers who are stuck at early intermediate level all life.

Re: Just what does “code as data” mean anyway? (2014)

#74

Post by dmitriid »

kazinator wrote: post #23
dmitriid wrote: post #19

One of the greatest lies that Lispers have is: "Lisp has no syntax". Syntax is defined as "the structure of statements in a computer language." What Lisp has, and is, is a syntax to describe an AST. If you get the syntax wrong, your program won't run. And even that syntax isn't uniform across the various Lisps (some will throw in weird chars and constructs here and there to make dealing with common structures easier…

That particular select instance could indeed just be an ordinary function, whereby the (where ...) and (order ...) are just evaluated argument expressions, also calling ordinary constructors for objects that influence the query. It doesn't really demonstrate the ability to manipulate syntax. Things start to get more interesting when some of the inputs need to be lambdas. Still, the sugaring of those can be in the arg…

Unless I’m missing something everything you said applies to jOOQ code.

Re: Just what does “code as data” mean anyway? (2014)

#75

Post by nickpsecurity »

peatmoss wrote: post #14
jstimpfle wrote: post #11

Earlier quoted context omitted.

I really value C syntax. I'm convinced it's much easier to navigate with the eyes than "oatmeal with fingerclips mixed in" (quoting Larry Wall). And >90% of the time the relevant syntactic unit is on its own line or ranges of lines, and that's really super easy to handle in vim. I don't think there is much to improve by building more complex abstractions on top. If you use vim as a C programmer, you should know the b…

I find C syntax awkward, bloated, inconsistent, and gross compared to lisp syntax, but that’s an aesthetic preference. Beyond the personal preferences of individuals (individuals who probably started with one kind of syntax or another) there are characteristics that have some objective utility. I appreciate that a lot of people start with C-ish syntax, and a similarly large number of people prefer that syntax, but I’…

"I appreciate that a lot of people start with C-ish syntax, and a similarly large number of people prefer that syntax, but I’ve never heard anything that demonstrated an intrinsic benefit of C syntax."

Short stuff is easier to type and maybe to read. There's that. Far as its "design," it was made by tweaking BCPL to make it run on a PDP-7 and then PDP-11. The assignment change was admitted as personal preference. BCPL itself was an ALGOL with LISP features that had every feature for safety, maintainability, etc chopped off to compile on a terrible piece of hardware they were stuck with. There was little to no design: can't overemphasize they literally just kept what that one machine could compile. Far as C, even structs originally weren't in it but got added after their failed attempts to port UNIX from assembly. Presentation below has proof from historical papers written by BCPL and C inventors.

https://vimeo.com/132192250

People just assume there was sensible design because of all the C code out there (argument from popularity). The brain then starts rationalizing attributes about it that were designed or hacked in for totally different reasons in a past of constrained hardware lacking knowledge or tools of modern, language design. That context no longer applies to most users of C. It's just myth-making by users reinforcing use of it.

Re: Just what does “code as data” mean anyway? (2014)

#76

Post by taeric »

oregontechninja wrote: post #42
taeric wrote: post #37

Earlier quoted context omitted.

Ultimately, I assert the truth is that we don't know why it didn't succeed more. So, speculation is just that. Take mine that is about to follow as more of it. I would be delighted to know of a way to test some of these ideas. Lisp didn't win because it used to cost money to get a good implementation, and there was no company throwing tons of marketing at it. Now, I specifically don't think it is a case of worse ones…

I theorize lisp isn't used more because of the massive amounts of parenthesis. I think the concepts are great, and it's a great language for certain task, but my right pinky finger hurts just looking at it. New programmers and developers look at that and compare it to something like Go, Python, or JavaScript, and all those look easier to write (although deceptively complex in places) and are 1000x easier to read. A p…

I find this the least compelling reason, to be honest. Especially when I check how many brackets and other decorations I have in a typical java file. The majority of the code, actually, has a similar number of brackets, and way more commas. :) (Specifically, most java could be a lisp if you just move the function name into its paren and remove all of the commas.)

Granted, the bike shedding that goes on in our industry is hilarious. I think many people blame semicolons as one of the major hurdles to learning c nowadays. The things we fixate on...

Re: Just what does “code as data” mean anyway? (2014)

#77

Post by mamon »

flavio81 wrote: post #43
taeric wrote: post #37

Earlier quoted context omitted.

Ultimately, I assert the truth is that we don't know why it didn't succeed more. So, speculation is just that. Take mine that is about to follow as more of it. I would be delighted to know of a way to test some of these ideas. Lisp didn't win because it used to cost money to get a good implementation, and there was no company throwing tons of marketing at it. Now, I specifically don't think it is a case of worse ones…

>Lisp didn't win because it used to cost money to get a good implementation, and there was no company throwing tons of marketing at it. This was one of the reasons. In the late 70s, cheap computers (IMSAI, Altair) were almost unable to run Lisp for useful purposes. Too little memory. Minicomputers (DEC PDP /etc) were able to run full Lisp implementations but it worked slower than using other languages. Lisp Machines…

Also, metaprogramming is no longer exclusive to Lisp, other languages are adding advanced features all the time, so there's fewer reasons to move to Lisp.

Re: Just what does “code as data” mean anyway? (2014)

#78

Post by flavio81 »

oregontechninja wrote: post #42
taeric wrote: post #37

Earlier quoted context omitted.

Ultimately, I assert the truth is that we don't know why it didn't succeed more. So, speculation is just that. Take mine that is about to follow as more of it. I would be delighted to know of a way to test some of these ideas. Lisp didn't win because it used to cost money to get a good implementation, and there was no company throwing tons of marketing at it. Now, I specifically don't think it is a case of worse ones…

I theorize lisp isn't used more because of the massive amounts of parenthesis. I think the concepts are great, and it's a great language for certain task, but my right pinky finger hurts just looking at it. New programmers and developers look at that and compare it to something like Go, Python, or JavaScript, and all those look easier to write (although deceptively complex in places) and are 1000x easier to read. A p…

>New programmers and developers look at that and compare it to something like Go, Python, or JavaScript, and all those look easier to write (although deceptively complex in places) and are 1000x easier to read.

Are you sure?

Reading a file in Go

    func read(f) {
        
        var text string
        var scanner *bufio.Scanner
        var err error
 
        file, err := os.Open(f)
        if err != nil {
            log.Fatal(err)
        }
        scanner = bufio.NewScanner(file)
        for scanner.Scan() {
            text += scanner.Text()
        }
        err = scanner.Err()
        if err != nil {
            log.Fatal(err)
        }
        fmt.Println(text)
    }
in Common Lisp

    (defun read (filename) 
        (with-open-file (input filename)
           (loop for line = (read-line input nil)
              while line do (print line))))
Now tell me which one is easier to read. And the lisp example you can understand what it does without even knowing any kind of Lisp language; it is almost english.

Re: Just what does “code as data” mean anyway? (2014)

#79

Post by quadcore »

skybrian wrote: post #49
quadcore wrote: post #29

Earlier quoted context omitted.

I agree, OO is ultimately good enough. Problem is, coding using OOP is like printing ideas on paper: you dont wanna do that because it's hard to discard ideas that's been printed on paper. You wanna use post-its instead because post-its are easy to discard. Refactoring is hard using OO and refactoring is the key difference between waterfall and good software development. Refactoring is easier, even fun, using functio…

You'll have to substantiate that, because refactoring Java is pretty easy if you have a good IDE. In many other languages, you're lucky if you can reliably rename a function without having to manually check for false positives, let alone something complicated like change signature or extract superclass . Also, in any statically typed language, you can fall back on changing the function and using compile errors to tel…

refactoring Java is pretty easy if you have a good IDE

rename a function

Refactoring in software development is not the same as refactoring in IDEs. Refactoring in software development is changing existing code. Specially the architectural parts.

Re: Just what does “code as data” mean anyway? (2014)

#80

Post by taeric »

flavio81 wrote: post #43
taeric wrote: post #37

Earlier quoted context omitted.

Ultimately, I assert the truth is that we don't know why it didn't succeed more. So, speculation is just that. Take mine that is about to follow as more of it. I would be delighted to know of a way to test some of these ideas. Lisp didn't win because it used to cost money to get a good implementation, and there was no company throwing tons of marketing at it. Now, I specifically don't think it is a case of worse ones…

>Lisp didn't win because it used to cost money to get a good implementation, and there was no company throwing tons of marketing at it. This was one of the reasons. In the late 70s, cheap computers (IMSAI, Altair) were almost unable to run Lisp for useful purposes. Too little memory. Minicomputers (DEC PDP /etc) were able to run full Lisp implementations but it worked slower than using other languages. Lisp Machines…

This is a thorough version of what I was saying, thanks for expanding. It would actually be neat to see an even more expanded version of the history. If you have a solid link, I'd love to read it.

And I agree that things are different nowadays. My main point is that this seems pretty compelling evidence to me. But, what it isn't, is a testable hypothesis. (Is it?)

Post reply on HN