Live data from Hacker News

The Idea of Lisp

dev.to

51–60 of 348 posts

Re: The Idea of Lisp

#51
post #25

Earlier quoted context omitted.

If you like everything being an expression, check out tcl. A lot of ideas from lisp show up in tcl, especially the idea of everything as an expression. Tcl embodies this idea while also having the look of an algol-like language. Funny it can pull this off while having basically no syntax.

Rust also has (almost) everything being an expression - things like this aren't uncommon: let x = if something { foo() } else { bar() } Things which don't have a logical value evaluate to `()` (the empty tuple), I believe.

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.

Re: The Idea of Lisp

#52
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.

That's a good idea.

Although they've been working on TCL perf (and even compilation) and there have been some improvements, especially when you're not doing metaprogramming. But still, using it on heavy loads isn't a great idea...

(I mean, honestly. I'm starting to think picolisp might be faster, and picolisp has 3 types and one data structure. Haven't run the benches yet, though.)

Re: The Idea of Lisp

#53
post #31

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.

Yeah the level of dynamicness (dynamism?) you can get in tcl is unparalleled as far as I can see. Having no types or syntax and access to the entire runtime at any point in the program opens up all kinds of crazy doors. But you're right, that slows it down. But you might be interested to know there is currently an effort to get Tcl to compile to native/near-native code. Here is a paper on the new techniques being dev…

Picolisp can match it in dynamism.

Seriously, Picolisp is absolutely insane.

Re: The Idea of Lisp

#55
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 the complexity of expression evaluation etc (Fortran) with a macro assembler? Obviously any program can be coded in a macro assembler and therefore that would also be true from a syntax like Lisp.

When I was in my 20's, I programmed at least 100,000 lines of Z80 assembler for the first micro computers. One project was at least 40,000 lines and so I know how difficult it is to program larger assembler programs. The biggest problem is that it is hard to see the structure of the loops and conditionals that we normally indent in higher level languages. (You can indent a Lisp program in any way but the language doesn't require any at all.) It is also difficult to recognize expressions. Both of these problems are also there in Lisp (unlike most other high level languages).

One last point about the linked list structure at the heart of Lisp. Linked lists are poorly executed in modern computers that rely heavily on locality of data, to optimize the L1 cache. Lisp was very easy on the compiler/interpreter writer but wasn't very good at optimizing the readability of the code for the programmer. (I don't want a religious war but I will point out that most programmers have never programmed in Lisp even though it was one of the first computer languages created.) Before I get a lot of dissing comments, I think with practice, some programmers developed an eye for the lack of structural clues and made some reasonable size code. You could say the same about some programmers making quite good large scale programs in assembler but that doesn't mean that writing in assembler or Lisp should be encouraged.

Re: The Idea of Lisp

#56
post #6

Does anybody have a few examples of DSLs people make in a lisp (ideally clojure because I have worked with it a tad)? I've seen plenty of cases where people make a pseudo-dsl via optional arguments, but not seen this so-oft mentioned "yeah we just wrote a dsl for it because lisp" sort of deal.

Matthew Butterick (the author of Beautiful Racket linked in another reply) is solving this year's Advent of Code, all as DSLs: https://github.com/mbutterick/aoc-racket

Re: The Idea of Lisp

#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.

Re: The Idea of Lisp

#59

I wonder why lisp isn't as popular as say python for AI, ML, and stuff. I see these fields as having a strong academic tone, and it feels like racket or clojure could be bigger when it comes to that.

[deleted]

Re: The Idea of Lisp

#60
post #14
post #2

The conditional expression or more specifically everything being an expression is my favorite thing about Lisp. I did not know that McCarthy pushed to add it to Algol which apparently today is the ternary operator for most languages. It is annoying that so many languages (C, Java, C#, etc) have both a conditional statement (if-else) and conditional expression (ternary ?:). Really the if-else should be an expression (…

In Rust, if-else is an expression, and there's no separate ternary operator.

My current project is over 90,000 lines of C and I have programmed in C since the 1970's (as well as many other languages). I have never used a ternary operator and I think it reads quite poorly. I just use a few lines of easily read code instead. I also never use a do/while construction with the condition at the bottom of the loop. When I need such a construct I just put in an "if" and "break" where ever needed instead. I don't think C should be dissed because of a few unneeded and probably unused features. In C, you can put more than 1 statement on a line if they are separated by a ';' but I have never done that in hundred's of thousands of lines of C code.
Post reply on HN