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

The Idea of Lisp

dev.to

Post reply on HN
Print view View original

191–200 of 348 posts

Re: The Idea of Lisp

#191

Post by qwertyuiop924 »

pjmlp wrote: post #179
qwertyuiop924 wrote: post #165

Earlier quoted context omitted.

But TCL actually goes beyond that. Most languages of this sort, like Smalltalk, Lisp, and especially slower, more liberal implementations like PicoLisp, allow for compile-time and/or runtime AST transformation, and other sorts of metaprogramming. in TCL, everything is a string. Or at least, everything behaves like a string in the proper context. When you pass code blocks into a command (like if, or while, or whatever…

Smalltalk just like Lisp has very little syntax, almost everything is built on messages, including data type creation, conditionals and loops, among other things. Also you can at any time just completely replace one object by other via the becomes: message. There are also some cool tricks when metaclasses are used, many of each one can see in Python as well.

However, IIRC, unlike Lisp, ST doesn't have any AST transformation or parsing hooks (macros and readtables, in Lisp parlance), so while ST has a lot of the semantic extension capabilities of Lisp (indeed, it's more semantically extensible than some of the less Object Oriented Lisps), it lacks the syntactic capabilities for extension.

However, you know ST better than me. Am I right?

Re: The Idea of Lisp

#192

Post by kbutler »

heywire wrote: post #75
coderzach wrote: post #49

Earlier quoted context omitted.

I see two issues with the ternary operator. One, the syntax is much less readable, and two, the consequent and alternate are both single expressions, so you can't do something like: x = if(something) { a = foo(); baz(a); } else { b = bar(); baz(b); }

I've always read ternary statements to myself as a question. some_condition ? this : that some_condition? then this, otherwise that Typing this, I realize how hard it is to explain without speaking it :)

> some_condition ? this : that

Just read it as:

  IF some_condition THEN this ELSE that

Re: The Idea of Lisp

#193

Post by greggman »

clarkd99 wrote: post #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 t…

As someone that's also written hundreds of thousands of lines of assembly with macros I don't really see the comparison. Lisp macros are written in lisp itself. You can create complicated data structures, interate over loops, do file io, query databaes, access the network, whatever you want at compile time in lisp where as assembly language macros were never much more complicated than then the C preprocessor. I certaibly did tons of creative things with assembly language macros but they aren't remotely similar to lisp macros.

As for perf, 7 very popular and performant games were written in Lisp. Crash Bandicoot 1, 2, 3 as well as Jak and Daxter 1, 2, 3 and Racing.

Re: The Idea of Lisp

#194

Post by pjmlp »

qwertyuiop924 wrote: post #191
pjmlp wrote: post #179

Earlier quoted context omitted.

Smalltalk just like Lisp has very little syntax, almost everything is built on messages, including data type creation, conditionals and loops, among other things. Also you can at any time just completely replace one object by other via the becomes: message. There are also some cool tricks when metaclasses are used, many of each one can see in Python as well.

However, IIRC, unlike Lisp, ST doesn't have any AST transformation or parsing hooks (macros and readtables, in Lisp parlance), so while ST has a lot of the semantic extension capabilities of Lisp (indeed, it's more semantically extensible than some of the less Object Oriented Lisps), it lacks the syntactic capabilities for extension. However, you know ST better than me. Am I right?

As far as I can remember no (Smalltalk was long time ago for me, 1995).

But I think there is already quite a few things possible via messages and metaclasses, even if one cannot do actual AST transformations.

After all, the whole image is accessible, so you can dynamically ask any object for its definition, or even compiled code (bytecode or JIT) and change them.

Re: The Idea of Lisp

#195

Post by rogual »

qwertyuiop924 wrote: post #167
jhbadger wrote: post #63

Earlier quoted context omitted.

Pity that it became so associated with the Tk GUI toolkit -- half the Linux GUI apps in the 1990s were in Tcl/Tk, and when Tk fell out of favor so did Tcl.

...And with TTK, you can finally have easy-to-write cross-platform UIs that actually look native. Seriously. If you want a decent cross-platform UI system with minimal effort, which has bindings in just about every language, TK is really worth your time now.

Tk UIs will never be acceptably native as long as scrollbars remain a separate control from the thing being scrolled. This stops OSes deciding where the scrollbars should go based on input device and locale.

On OSX in particular, Tk UIs always stick out like a sore thumb for this reason, even with TTK.

Re: The Idea of Lisp

#196

Post by tlack »

clarkd99 wrote: post #87
hindenburg wrote: post #67

Earlier quoted context omitted.

You make some specific claims here that sound a little odd to this LISP and assembly language hacker. Assembly language doesn't provide any datatypes. LISP does. Assembly language doesn't provide any type checking. LISP does. Assembly language doesn't provide automatic storage reclamation. LISP does. Assembly language doesn't provide naming. LISP does. You also make a claim about L1 caches and locality of reference.…

I was only talking about the 'list of function calls' aspect of assembler and Lisp, not the type system. I agree that Lisp has a type system and assembler doesn't. Forth is another language that also has very simple syntax that approximates the 'list of function calls' style that I would say isn't unlike a macro assembler either. I am writing a new language with built-in garbage collection that I think is quite super…

Big time array fan here. I'd love to check out your language when you publish it. Sooner the better.. we need new ideas! Email in profile if you'd like to chat about it.

Re: The Idea of Lisp

#197

Post by sedachv »

bpicolo wrote: 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.

Here is an example of a DSL I made in Common Lisp for doing compile-time URL checking in a web application: http://carcaddar.blogspot.com/2008/11/compile-time-inter-app...

Common Lisp makes it easy to compose DSLs so it was trivial to apply the URL checking DSL to the JavaScript generating DSL (Parenscript) and have the browser-side code checked at compile time as well.

Another good example is CLiki2: https://github.com/vsedach/cliki2/blob/master/src/readtable....

The HTML template system is a small DSL on top of a string interpolation library (vs a 10,000 line templating library that can't even get HTML attributes right). It was also trivial to make it use streams to eliminate string allocation/copying.

Re: The Idea of Lisp

#198

Post by sbov »

clarkd99 wrote: post #185
sbov wrote: post #154

Earlier quoted context omitted.

There's a lot here, but this one jumped out at me: > You can indent a Lisp program in any way but the language doesn't require any at all. Off the top of my head, isn't this true of basically all languages? Except one, and it got a lot of criticism for it (Python).

After I wrote that statement I started thinking that C programs can be formatted so that they don't read very well also. In C, an 'if' is always an 'if' (unless you use the pre-processor to screw it up) but in Lisp an 'if' could be anything. I do like the idea of Lisp macros where you can run a Lisp program at compile time to generate the code that is then compiled inline. What I should have said was that Lisp has no…

I haven't worked on a program that hijacked the core language functions in the Lisp I use (Clojure). So your concern seems odd to me, especially since you admit you can do the same thing in C. That said, I only use it in my spare time and not for work, so my exposure is limited.

Beyond that, your objections seem to be based upon familiarity. I had similar ones before I started using Clojure more often. I think the notation is just fine - it's not much different from imperative languages except they place the parenthesis in a different spot - I think it's more the nesting than the notation, which isn't a common tactic in imperative languages.

I still use imperative languages during my day job so I can decipher imperative code easier, but I am much better at deciphering functional code than I used to be.

Re: The Idea of Lisp

#199

Post by cicero »

goatlover wrote: post #150
mbrock wrote: post #128

Earlier quoted context omitted.

I don't think actual Lisp programmers share this obsession with purity and ideal forms. It's more something that shows up in blog posts about Lisp by people who probably don't actually use it. The title of this one is telling: it's about "the idea of Lisp." On the other hand, if you look at, say, ANSI Common Lisp, it's not at all some kind of perfectionistic attempt at divine elegance. It's a pragmatic compromise res…

But then again, there's Scheme ...

Even Schemes can take a practical turn, e.g. Racket.

Re: The Idea of Lisp

#200

Post by virtualwhys »

dllthomas wrote: post #177
virtualwhys wrote: post #135

Earlier quoted context omitted.

It's not the same thing, a value of type Unit can only produce a side effect (or do nothing at all).

How is that different from a value of type "empty tuple"?

True, neither are useful as values, though Unit typically conveys programmer intent (to produce a side effect), whereas the empty tuple is, in Scala at any rate, quite rare.

The empty tuple:

    scala> val empty = Tuple1(())
    empty: (Unit,) = ((),)
vs. Unit:

    scala> val empty = ()
    empty: Unit = ()
Post reply on HN