Live data from Hacker News

The Idea of Lisp

dev.to

91–100 of 348 posts

Re: The Idea of Lisp

#91
post #33

Earlier quoted context omitted.

TCL, while it has its warts, is a really cool language. I mean, it even basically has fexprs, something most Lisps put by the wayside years ago. When you don't actually care about speed, you can do some pretty cool stuff.

Yes, I worked on a startup that did pretty much something like Ruby on Rails, but with TCL, inspired by AOLServer. The speed critical parts were written in C and loaded as TCL extensions. Back in the first .com wave. It also taught me to never again use a programming language without JIT/AOT compiler on their standard toolchain for heavy loads.

Interesting. There was this company called Vignette (in the same period). They too were doing .com projects for clients, and, IIRC, using AOLServer which I read was in Tcl. Tcl was used for the projects.

Re: The Idea of Lisp

#92
post #57
post #54

Question: what would a LISP dialect with static typing look like? EDIT: Found an answer: http://stackoverflow.com/questions/3323549/is-a-statically-t...

Common Lisp, Racket, and Clojure all have optional static typing.

They have gradual typing but I believe they're still enforced as runtime contracts, making them not static types.

Re: The Idea of Lisp

#93
post #51

Earlier quoted context omitted.

This example of "everything as an expression" doesn't take it as far as Tcl, though. In the above code snippet, the conditional body is surrounded by braces, which are syntax. In Tcl, the second argument to the 'if' command is also an expression, which only uses braces as a quoting mechanism, if it needs to.

I'm not sure I understand why it matters if the syntax requires braces or not. The things inside the braces are still expressions.

It matters because if the braces are not syntax, you can decide what code to execute as the condition body at runtime.

    set condition-body {puts "Hello, world"}
    if { $condition } $condition-body
To get this to run, you need to splice in the condition-body like so,

    if { $condition } {*}$condition-body
But you get the point.

Re: The Idea of Lisp

#94
post #33

Earlier quoted context omitted.

TCL, while it has its warts, is a really cool language. I mean, it even basically has fexprs, something most Lisps put by the wayside years ago. When you don't actually care about speed, you can do some pretty cool stuff.

Yes, I worked on a startup that did pretty much something like Ruby on Rails, but with TCL, inspired by AOLServer. The speed critical parts were written in C and loaded as TCL extensions. Back in the first .com wave. It also taught me to never again use a programming language without JIT/AOT compiler on their standard toolchain for heavy loads.

Hmm, was that the one headed by Phil Greenspun? Arsdigita or something like that...?

Back in the day, aolserver w/ TCL + (open)acs + pgsql/oracle was teh awesomeness compared to LAMP that everyone else was doing. Oh well... :(

Re: The Idea of Lisp

#95
post #19

Earlier quoted context omitted.

If there's one thing I've learned from programming it's that to build anything good you have to be driven by real use cases.

It's not clear if your comment approves or disapproves the one you've commented.

It's not clear to me whether the comment I replied to viewed this as a good or a bad thing (all it said was "funny how..."), so I can't say whether I approve or disapprove. Hopefully it's clear where I stand though.

Re: The Idea of Lisp

#96

This great idea of Lisp (the simple syntax of function calls in round brackets) isn't much different than a good macro assembler even back in the 1960's. The only major difference was that more than 1 function could be defined in 1 source code line. (I think that machine code is nothing but a sequence of function calls where the function is the logic encoded in the CPU itself for each opcode.) Is it fair to compare t…

Code readability depends mostly on giving variables and functions meaningful names, and function size/number of variables. That applies to all languages.

Code layout/indentation is also an issue, but there's a single standard for Lisp, which Emacs is aware of.

Re: The Idea of Lisp

#97
I know their is an active community around Lisp and it's still used for development, but I apparently have not dug deep enough to appreciate when it's the best choice for a new project.

Can someone mantion a few features or scenarios that make it the best choice for starting a new project?

Re: The Idea of Lisp

#98

Earlier quoted context omitted.

Agreed about linked lists; that virtually all functional languages make them the default/literal data structure is IMO a poor practical design choice (no matter how theoretically elegant) and is the primary culprit for their reputation for slowness. And the tendency for functional compile-to-JS langs to emulate linked lists in Javascript and keep them the default data structure is downright laughable.

(Singly linked) lists are a functional data structure. You can manipulate them efficiently without modifying the lists you started with. You can't do that easily with arrays. So if you base your language around arrays, you're better off making it imperative. Lisp predated level 1 caches. I think it's better to design hardware around the software that runs on it (the Burroughs mainframe/Lisp machine approach), than de…

I can 'efficiently modify the lists you started with' with a dynamic multi-type array and I have cache locality and random access. I have a single data structure with an 8 byte overhead, 2 byte overhead per node that can be used as a tuple array with direct lookup, a single linked list, double linked list, a queue, a stack, and a balanced binary search tree. This whole structure is allocated in a single contiguous memory chunk and is cache friendly. It can be serialized and un-serialized without any processing which would be required by a Lisp style linked list even if the list was just moved in memory, saved/restored to/from disk or transmitted to another computer.

Lisp DOES predate level 1 cache but we DO have level 1 cache now and it dwarfs all other optimizations on modern computers. Wouldn't it be nice if the hardware was designed to optimize our languages instead of the other way around but I live in this universe rather than an alternate one.

What matters is now, not decades ago.

Re: The Idea of Lisp

#99
post #43

I'm working on a Lisp-based introductory programming book: https://github.com/rongarret/BWFP Still very much a work in progress. Feedback appreciated.

You may be interested in checking this out for inspiration: http://www.ccs.neu.edu/home/matthias/HtDP2e/ (It's the Intro to CS book used at my alma mater, teaching programming in Racket)

Tried doing some of that with High School kids -- I have to admit, at the beginning it was very difficult for them to wrap their head around the basic concepts in functional programming. The other issue was that the few syntactical rules and prefix notation, while great in the long term, required the kids to do a bit more of mental gymnastics for even basic things at the beginning, so that didn't help either.

But man after the initial hump, I was convinced that this is the route to go through in order to introduce someone to programming with very solid first principles.

Re: The Idea of Lisp

#100
post #43

I'm working on a Lisp-based introductory programming book: https://github.com/rongarret/BWFP Still very much a work in progress. Feedback appreciated.

You may be interested in checking this out for inspiration: http://www.ccs.neu.edu/home/matthias/HtDP2e/ (It's the Intro to CS book used at my alma mater, teaching programming in Racket)

[deleted]
Post reply on HN