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

Lisp as the Maxwell Equations of Software (2012)

michaelnielsen.org

Post reply on HN
Print view View original

91–100 of 131 posts

Re: Lisp as the Maxwell Equations of Software (2012)

#91

Post by wwweston »

Permit wrote: post #68
julienchastang wrote: post #32

Earlier quoted context omitted.

If you give someone Fortran, he has Fortran. If you give someone Lisp, he has any language he pleases. - Guy L. Steele

That seems like a huge disadvantage to me. The bottle neck in any software project (> 1 person) is usually the time it takes to read and understand source code. Some estimates[1] claim that up to 78% of development time is spent just reading code. With that in mind, I would not want to learn a new language for every project I was a part of. I'd even go so far as to say: The majority of programmers cannot design a goo…

> That seems like a huge disadvantage to me. The bottle neck in any software project (> 1 person)

Even single-author projects have the person who wrote the code months ago and the person reading it today. :)

> is usually the time it takes to read and understand source code. Some estimates[1] claim that up to 78% of development time is spent just reading code.

Sure. This is a big deal.

I'm not sure the software-conservative approach of locking down the syntax and flexibility of expression is deeply helpful, though. My experience is that comprehending syntax (while it can be a barrier) isn't the biggest portion of that 78% you're talking about -- maybe 15%. Wrapping your head around the semantics of what a piece of code does is a much bigger portion.

The semantics of what the software does are the true language of the program you're writing, so in a sense the choice isn't whether or not you're going to have a DSL or not, it's just how concisely the syntax of the language will support the expression of it. And I've found that the less flexibility you have in syntax, the more likely it is over time that you'll have to type/read over larger amounts of code in order to capture the expression of a given semantic goal.

Re: Lisp as the Maxwell Equations of Software (2012)

#92

Post by sjolsen »

Permit wrote: post #68
julienchastang wrote: post #32

Earlier quoted context omitted.

If you give someone Fortran, he has Fortran. If you give someone Lisp, he has any language he pleases. - Guy L. Steele

That seems like a huge disadvantage to me. The bottle neck in any software project (> 1 person) is usually the time it takes to read and understand source code. Some estimates[1] claim that up to 78% of development time is spent just reading code. With that in mind, I would not want to learn a new language for every project I was a part of. I'd even go so far as to say: The majority of programmers cannot design a goo…

>With that in mind, I would not want to learn a new language for every project I was a part of

Well, you have to. Every new project comes with its own vocabulary and semantics. You have to learn those whether they're expressed in terms of data/function abstractions or syntactic abstractions. Sometimes—perhaps less often than many Lisp programmers appreciate, but sometimes nonetheless—those new concepts are simply easier to understand when expressed syntactically.

>The majority of programmers cannot design a good language, and if Lisp gives them the opportunity to try then that's a BadThing™

There are many programmers (I say "many" because I haven't actually met most programmers, but "most" might be true, too) who cannot design good data abstractions. Would you consider that [your favorite "OO" language here] allows one to form data abstractions to be a "bad thing?"

Re: Lisp as the Maxwell Equations of Software (2012)

#93

Post by tromp »

one-more-minute wrote: post #61
[deleted] wrote: post #59

Earlier quoted context omitted.

[deleted]

I think you've missed the point of OPs question - he's not trying to argue that lisp isn't useful over Lambda Calculus from a practical perspective, but asking how both relate to the "fundamentals of computing" perspective. So to answer your question, nothing (in this context), because the Turing machine is a more useful model for thinking about computation itself. Perhaps the same might apply to lisp / lambda calcul…

> it's just a lot harder to right a self-interpreter in lambda calc.

Here's one for the http://en.wikipedia.org/wiki/Binary_lambda_calculus, all of 29 bytes long, including parsing:

    0101000110100000000101011000000000011110000101111110011110
    0001011100111100000011110000101101101110011111000011111000
    0101111010011101001011001110000110110000101111100001111100
    0011100110111101111100111101110110000110010001101000011010

Re: Lisp as the Maxwell Equations of Software (2012)

#94

Post by lisper »

keithgabryelski wrote: post #71

for what it is worth, here is a version of a lisp interpreter I wrote in python: https://github.com/keithgabryelski/plisp I used _Interpreting_LISP_ by Gary D. Knott as a guide.

Lisp in Python in 137 LOC:

http://www.flownet.com/ron/l.py

Re: Lisp as the Maxwell Equations of Software (2012)

#95

Post by TeMPOraL »

coldtea wrote: post #26
RodgerTheGreat wrote: post #17

Earlier quoted context omitted.

Lisp gets a great deal of undue credit as being some kind of timeless enlightened wisdom, which I see as ignorant of the history of the language's development. It took years to develop approaches to garbage collection (the earliest prototypes used bump allocators and crashed when they exhausted a heap), years to finalize the syntax of the language (you'll notice that the "maxwell's equations" are written using M-Expr…

> Modern Lisps are substantially different in syntax and semantics from these earliest ideas; we're just still calling them Lisp. An interesting take on "modern", meaning "the last 3 decades or so", which is like millenia in the IT industry...

I understand that by "IT industry" you mean the Web, which is the industry's equivalent of a fashion show.

Work clothes, suits and hazmat wear also don't change their design every three months.

Re: Lisp as the Maxwell Equations of Software (2012)

#96

Post by brudgers »

Permit wrote: post #68
julienchastang wrote: post #32

Earlier quoted context omitted.

If you give someone Fortran, he has Fortran. If you give someone Lisp, he has any language he pleases. - Guy L. Steele

That seems like a huge disadvantage to me. The bottle neck in any software project (> 1 person) is usually the time it takes to read and understand source code. Some estimates[1] claim that up to 78% of development time is spent just reading code. With that in mind, I would not want to learn a new language for every project I was a part of. I'd even go so far as to say: The majority of programmers cannot design a goo…

It's not so much a huge disadvantage as a huge trade-off.

The risk is that Lisp is used to create a lousy language ill-suited for the task at hand. The benefits come when it is used to capture the ubiquitous language of a domain and used at the appropriate level of abstraction.

If it makes the code harder to reason about, then it's not the right level of abstraction. But poor code can be written in any language.

Re: Lisp as the Maxwell Equations of Software (2012)

#98

Post by GregBuchholz »

hga wrote: post #90
GregBuchholz wrote: post #88

Earlier quoted context omitted.

Modern high-end FPGAs can have upwards of 5-10 megabytes of on die memory: http://www.xilinx.com/products/silicon-devices/fpga/virtex-u... http://www.altera.com/devices/fpga/stratix-fpgas/stratix-v/o...

What do they cost in single unit quantities, or rather, what does a development board that I can stick GiBs of hopefully ECC DRAM cost? And the development tools? I know I can do this with small scale ones, including some of the tools, on sub-$100/$200 boards with not a lot of memory (the research lowRISC has prompted me to do has been fascinating). If the answer to the above is 6 figures, the intersection of those w…

I'm not saying it is economically competitive. (It is possible pay over $25k for a really high end FPGA) And if you are just synthesizing a general purpose synchronous CPU you definitely not going to get a lot of bang-for-the-buck, because you are going against the grain of what an FPGA can provide. In that instance you're just vetting your design until you convert it over to a mask-programmable "equivalent", or do a full-custom design. The interesting things about an FPGA would be to use its inherent parallelism, fine grain programmability, and the reprogramability to run circles around something constrained by a von Neumann bottleneck in the cache hierarchy.

As to clock speeds, here's part of the abstract to a white paper that might interest you:

"A clock rate higher than 500 MHz can be supported on a mid-speed grade 7 series device with almost 100% of the logic slices, more than 90% of the DSP48 slices, and 70% of the block RAMs utilized. This requires the designer to follow some rather simple design rules that cover both algorithmic and implementation aspects. These rules are reviewed in the paper."

http://www.xilinx.com/support/documentation/white_papers/wp4...

...but clock speed isn't necessarily a super interesting factor if your data bus is 2048 bits wide, with a pipline 100 stages deep, comparing to say 64 bits wide and 10 stages deep on a CPU. Again, this is not to say that anyone should try implementing a Lisp machine on an FPGA to try to take market share away from Intel.

Re: Lisp as the Maxwell Equations of Software (2012)

#99

Post by cousin_it »

hga wrote: post #87
cousin_it wrote: post #85

Earlier quoted context omitted.

There's a spectrum of near vs. far from the machine, but there's no spectrum of computability, all Turing complete languages are equally Turing complete. There's no difference between Lisp and assembly in this regard. In fact if you take into account the big-O time complexity, then assembly is better than the version of Lisp described in the OP, because the latter suffers a logarithmic penalty due to immutability. Mo…

Please correct me if I'm wrong, since this is very much not my field, but as I understand it, there are at least 4-5 mathematically equivalent fundamental models of computation, and in practice the Turning machine and the lambda calculus (developed by Turing's thesis adviser ... I gather that was a small world back then) are useful. E.g. does the additional math you're talking about stand on top of either of those? I…

Yeah, you understand correctly. The thing is, I don't know any mathematical insight that singles out lambda calculus as a basis for computation among other possible bases, or any mathematical insight that singles out Lisp as an approach to writing self-interpreters. In other words, there's no theorem saying Lisp lies at the extreme end of any spectrum.

To many people, Lisp is simply the most advanced language they know, so they view other languages as "Lisp plus some features that you could implement with macros". They might as well view other languages as "assembly plus some features that you could implement with assembly". It's just the blub paradox all over again.

To add insult to injury, many of today's advanced languages aren't even built on Lisp. They throw away the key idea of Lisp (easy equivalence between code and data) in order to achieve other things which are not achievable in Lisp (provability of certain classes of statements about all valid programs). To put it in an exaggerated but not entirely untrue way, these days Lisp seems like a dead end in terms of research. Most of the interesting stuff is coming from ML-like languages instead.

Re: Lisp as the Maxwell Equations of Software (2012)

#100

Post by coldtea »

TeMPOraL wrote: post #95
coldtea wrote: post #26

Earlier quoted context omitted.

> Modern Lisps are substantially different in syntax and semantics from these earliest ideas; we're just still calling them Lisp. An interesting take on "modern", meaning "the last 3 decades or so", which is like millenia in the IT industry...

I understand that by "IT industry" you mean the Web, which is the industry's equivalent of a fashion show. Work clothes, suits and hazmat wear also don't change their design every three months.

No, I mean the IT industry. I have been following it since the mid-eighties...
Post reply on HN