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

A road to Lisp: Why Lisp

scotto.me

Post reply on HN
Print view View original

211–220 of 322 posts

Re: A road to Lisp: Why Lisp

#211

Post by pjmlp »

klibertp wrote: post #31

> So why Lisp (or when) > [...] among its extensibility, its interactive environment, the REPL, and a lot of other features we haven’t touched yet. It is the combination of all of them that makes Lisp programming what it is. Agreed. However, although the alternatives are few, they do exist. Today, I'd like to convince you (whether you're OP or a commenter) to give one of them a try. I'm talking about GToolkit[1]: Sma…

All three major programming environments at Xerox PARC, shared similar concepts.

Interlisp-D, Smalltalk, Mesa (XDE) which evolved into Cedar.

If you read Xerox papers about all of them, there are several quotes on how relevant it was to share the same programming experience across environments.

Which is why, given their linage, JVM and CLR are the closest big mindshare ecosystems that somehow still have traces of those features when using their IDEs and runtimes, even without being a proper Smalltalk or Lisp.

Re: A road to Lisp: Why Lisp

#212

Post by iLemming »

gf000 wrote: post #159
iLemming wrote: post #48

Earlier quoted context omitted.

> And it's false. There's nothing special about a REPL You are wrong. You might be correct about the workflow but still wrong about the semantics. Pedantically, your notion is false, because homoiconism gives the REPL a genuine capability (program-as-manipulable-data across the read/eval boundary) that non-homoiconic REPLs lack.

Can you parse code into an in-memory representation and can you eval? If yes, then you can do everything that Lisp repls can. The parser being slightly more complex than parsing s-expressions doesn't materially change anything.

I did not say anything about s-expressions. I said "homoiconicity". S-expressions are not an absolute requirement for homoiconic features. You keep poking me with your "knowledge" as if I'm trying to sell you snake oil and you feel obligated to defend and retaliate. I don't need to prove anything to you, I'm not your ignorant professor attempting to instil you with some defunct truths that exist solely in my head. Do your own research. Or don't, who cares.

Re: A road to Lisp: Why Lisp

#213

Post by lysace »

iLemming wrote: post #205
gf000 wrote: post #158

Earlier quoted context omitted.

Why do you think other people who have fallen in love with, say, Ruby, are less experienced in other languages? They just have less of a cult.

You sweet, summer child, just so you know, I have existed for nearly half a century in this world where the larger part of it I have spent dealing in computing. I have seen and dealt with more programming languages (including Ruby) than you can count with your fingers and toes and that number keeps growing still. I'm not advocating for any particular language, runtime, framework or paradigm - do use whatever your hea…

Please be less of an asshole.

Re: A road to Lisp: Why Lisp

#214

Post by mindslight »

GMoromisato wrote: post #95
frwrfwrfeefwf wrote: post #88

[dead]

Of course you feel this way. You just finished reading SICP or maybe you binged PG essays last weekend. But eventually you'll read Simon Peyton Jones and start screaming about functional programming and algebraic type systems. Then, if you're lucky, you'll get a real job and realize that languages are just a tiny part of software engineering. I'm excited for you to experience that journey.

Do you like Apple ]['s?

You've got a good point. Code generally needs to be read more than it is written. At the very least, you realize this as you try to revisit something you had done previously and are left scratching your head. Encapsulating the complexity in a custom DSL can be great for simplifying all the code you write in the DSL. But it also raises the stakes - if you ever have to revisit the DSL implementation the complexity is there lurking.

Re: A road to Lisp: Why Lisp

#215

Post by zelphirkalt »

gf000 wrote: post #178
bsaul wrote: post #175

Earlier quoted context omitted.

never understood why people say that: the syntax for defining code seems quite different from the syntax defining data structure. There's no homoiconicity in javascript..

And that's just syntax, it doesn't give you a programming language at all. JS is a dynamically typed language with prototypical inheritance objects that work like universal key-value maps for the most part. It is also mutable. Clojure is a dynamically typed language with key-value maps. It is also immutable. You can surely see where I'm going , the underlying semantic model is the meaningful part. Homoiconicity doesn…

> Homoiconicity doesn't give you anything special if your language can parse itself and can eval code. It just makes these completely abstract implementations simpler.

Well, in a way it does give you something: By making expression of things like macros simpler, it makes them sometimes worthwhile, and makes it a reasonable request to have this kind of meta programming in your language at all. Without homoiconicity such things become even more difficult endeavors and often unjustifiable for the language design and its implementation.

Re: A road to Lisp: Why Lisp

#216

Post by nourr »

lysace wrote: post #213
iLemming wrote: post #205

Earlier quoted context omitted.

You sweet, summer child, just so you know, I have existed for nearly half a century in this world where the larger part of it I have spent dealing in computing. I have seen and dealt with more programming languages (including Ruby) than you can count with your fingers and toes and that number keeps growing still. I'm not advocating for any particular language, runtime, framework or paradigm - do use whatever your hea…

Please be less of an asshole.

You’re an asshole too for talking like that.

I am not an asshole for pointing it out though, I’m likable.

Re: A road to Lisp: Why Lisp

#217

Post by gf000 »

sdfsfdsdfs3d wrote: post #200
gf000 wrote: post #186

Earlier quoted context omitted.

My issue is that a language is just as much about what it disallows , as much as about what it allows. It's absolutely trivial to allow everything , you just have to make a Turing-complete extension either by design or accidentally. It's much much harder to carefully choose more limiting primitives that only allow you to build stuff that keep certain important properties about them. You can't subtract stuff after the…

I agree. Restrictions are core to software development. In fact without them I don't think there is development in the first place. As you know I see software development as going from the general (the full bandwidth of the computational substrate available to you) to the specific (the absolute minimum - if any - computational structure you need to get what you're after). Rust is more restrictive than Lisp. These res…

Thank you for the reply, and I definitely agree with you on many points. I absolutely don't want to take away from Lisp that it is somehow uniquely elegant, and does have a mathematical beauty to it, this is certain.

I just feel this (and its practical ramifications) are often overexaggerated.

Re: A road to Lisp: Why Lisp

#218

Post by iLemming »

gf000 wrote: post #156
iLemming wrote: post #94

Earlier quoted context omitted.

> programming has matured quite a bit Your wording sounds like it implies that Lisp "got stuck" somewhere in the past, no? Clojure, Clojurescript, Clojure-Dart, Fennel, Jade, Jank, Jolt, Coalton - these are relatively recent (and still developing) languages, and this is just off the top of my head, there are so many more. Lisp is not a programming language (in a sense), it's an idea. It influenced pretty much every s…

What idea? S-expressions? Because that's all these languages share. What's common in CL and Clojure? They are as dissimilar as C and Scala.

> What's common in CL and Clojure?

homoiconicity, macros, functional bias, REPL - to count just a few.

Re: A road to Lisp: Why Lisp

#219

Post by yogsototh »

GMoromisato wrote: post #22

Programming is in tension between the Light Side and the Dark Side. The Light Side is about preventing the programmer from making mistakes: Get rid of go-tos! Add static types! Do not allow a bug to be expressible. The Dark Side is about giving power to the programmer: Macros? Obviously. Operator overloading? Self-modifying code? Multi-line reg-exps? Go to town! The Light Side knows programmers are flawed and imposes…

I wonder what side you would put Malbolge,

What side for python? Haskell? Idris? Clean? C? K?...

white/dark side is too much of a simplification to me.

Programming language equilibrium is a very complex subject and fascinating one.

After years of experimenting with many of them, it is all a matter of context of usage, personal preferences, objectives, etc.. there is no such thing as "the best programming language ever", neither "best for light side programming" nor "best for dark side programming".

Similarly, there is no such things as: Light side/Dark side in artistic painting. There are tons of paints some are clearly greater than others, but there is no such thing as "the best painting most beautiful for everyone seeing this paint comparatively to any pain".

[^Malbolge]: https://en.wikipedia.org/wiki/Malbolge

[^Clean]: https://en.wikipedia.org/wiki/Clean_(programming_language)

[^K]: https://en.wikipedia.org/wiki/K_(programming_language)

Re: A road to Lisp: Why Lisp

#220

Post by nmdev »

Panzerschrek wrote: post #142

Can I write a game using OpenGL in Lisp?

Yes. Kandria [1] is a great example of someone doing exactly this. There's a bunch of information on the development here [2] and the code is open source [3].

[1] https://kandria.com/

[2] https://reader.tymoon.eu/article/413

[3] https://codeberg.org/shirakumo/kandria

Post reply on HN