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

I still Lisp (2021)

betterprogramming.pub

Post reply on HN
Print view View original

71–80 of 119 posts

Re: I still Lisp (2021)

#71

Post by AlchemistCamp »

danuker wrote: post #68
throw009 wrote: post #48

Earlier quoted context omitted.

That you think assembly is fundamental rather than an accident of architecture really shows how undereducsted you are in computer science. Lisp isn't great because it's weird, it's great because it lucked into homoiconicity in its birth. It's weird because no other language family can do that. It's not popular because the majority of programmers are mediocre and will never understand the point of homoiconicity.

Show me homoiconicity used "for real". Sure, it's useful in compilers and interpreters, but how often do people need them in a business application? You will most likely use a library, and/or a syntax designed for serialization instead of programming, like JSON. I personally vastly prefer Python's syntax over Lisp's, because the parentheses require two buttons pressed (shift + 9) instead of one (tab). That may sound…

The thing that makes lisp special, IMO, is how simple the syntax is. It makes thinking about certain kinds of problems much easier than in other languages, which can do the same things. As strange as it may sound, the book that most helped me understand Elixir's macros wasn't the book devoted to teaching them, but instead it was this Clojure book: https://pragprog.com/titles/cjclojure/mastering-clojure-macr...

In reality, they work pretty much the same way in the two languages, but due to the syntax, it was easier (at least for me) to grapple with the ideas in a lisp first.

I very rarely write macros, but I sure use them all the time via the web framework and db-wrapper libraries that dominate the Elixir ecosystem and they've been useful for all the "business applications" I've worked on in the past several years.

Re: I still Lisp (2021)

#72

Post by danuker »

throw009 wrote: post #70
danuker wrote: post #68

Earlier quoted context omitted.

Show me homoiconicity used "for real". Sure, it's useful in compilers and interpreters, but how often do people need them in a business application? You will most likely use a library, and/or a syntax designed for serialization instead of programming, like JSON. I personally vastly prefer Python's syntax over Lisp's, because the parentheses require two buttons pressed (shift + 9) instead of one (tab). That may sound…

Running with the json example you don't need a json library in lisp because you'd just dump an s-expression holding the data you want directly. You don't need a library to parse it because it's already in a format that lisp can understand. Hilariously enough the project that made me switch to lisp from python as my scripting language was writing a lightweight parser for ascii delimited files - https://en.wikipedia.or…

Well, I wrote a genetic programming library, and it was fun to parse a Lisp-like representation from Python. You still have recursion and everything (albeit no tail call optimization).

Here, `_from_source` goes from a plain array of tokens to a nested one (tree), depending on their arity:

https://github.com/danuker/symreg/blob/7c6593d3046f6c52dfb92...

S-Exps are almost valid Python. The exception is the single-element tuple which needs a comma: (x,)

But I still preferred to use Python as a programming language, and Lisp as a sort of AST. It's just easier. I am curious what roadblocks you faced in your ASCII delimited parsing.

Do you by any chance still have the two parsers? I'd love to see them. If you are worried about your anonymity, you can find my e-mail on my blog, and my website on my HN profile. I promise not to disclose your identity publicly.

Re: I still Lisp (2021)

#73

Post by throw009 »

danuker wrote: post #72
throw009 wrote: post #70

Earlier quoted context omitted.

Running with the json example you don't need a json library in lisp because you'd just dump an s-expression holding the data you want directly. You don't need a library to parse it because it's already in a format that lisp can understand. Hilariously enough the project that made me switch to lisp from python as my scripting language was writing a lightweight parser for ascii delimited files - https://en.wikipedia.or…

Well, I wrote a genetic programming library, and it was fun to parse a Lisp-like representation from Python. You still have recursion and everything (albeit no tail call optimization). Here, `_from_source` goes from a plain array of tokens to a nested one (tree), depending on their arity: https://github.com/danuker/symreg/blob/7c6593d3046f6c52dfb92... S-Exps are almost valid Python. The exception is the single-elemen…

>Here, `_from_source` goes from a plain array of tokens to a nested one (tree), depending on their arity:

You're 90% there. Lisp notation obviates the need for arity tracking, which is why in lisp + and sum are the same function:

    scheme@(guile-user)> (+)
    $416 = 0
    scheme@(guile-user)> (+ 1)
    $417 = 1
    scheme@(guile-user)> (+ 1 2)
    $418 = 3
    scheme@(guile-user)> (+ 1 2 3)
    $419 = 6
Add higher order functions, e.g. (λ (x) (x x)), and lisp notation is the simplest/only way to deal with the general case where you don't know ahead of time the arity of the function you'd be applying because of partial currying and data persistence.

As for the parsers this was 10 years ago at university. I've long since lost the source code. There weren't any problems with python, it's just that once I wrote the lisp version I realized just how useful the brackets actually are. There's a reason why every computer language is more or less context free. Lisp just takes that to its logical conclusion.

Re: I still Lisp (2021)

#74

Post by danuker »

throw009 wrote: post #73
danuker wrote: post #72

Earlier quoted context omitted.

Well, I wrote a genetic programming library, and it was fun to parse a Lisp-like representation from Python. You still have recursion and everything (albeit no tail call optimization). Here, `_from_source` goes from a plain array of tokens to a nested one (tree), depending on their arity: https://github.com/danuker/symreg/blob/7c6593d3046f6c52dfb92... S-Exps are almost valid Python. The exception is the single-elemen…

>Here, `_from_source` goes from a plain array of tokens to a nested one (tree), depending on their arity: You're 90% there. Lisp notation obviates the need for arity tracking, which is why in lisp + and sum are the same function: scheme@(guile-user)> (+) $416 = 0 scheme@(guile-user)> (+ 1) $417 = 1 scheme@(guile-user)> (+ 1 2) $418 = 3 scheme@(guile-user)> (+ 1 2 3) $419 = 6 Add higher order functions, e.g. (λ (x) (x…

Well, thank you for your feedback. I don't know why I bothered with the flat list in the first place. I might rewrite this library in Clojure. And I might blog about my findings.

Cheers!

Re: I still Lisp (2021)

#75

Post by School-Cotton »

User23 wrote: post #41
gaze wrote: post #9

Earlier quoted context omitted.

Every lisp variant is a bit different. Racket, Clojure, and Common Lisp are all excellent. Read a bit about the compromises and dip your toes in one and see if it sticks.

Racket has more didactic origins but I’m given to understand its a good albeit slow general purpose Lisp. Common Lisp is basically the kitchen sink programming language and with a good compiling implementation like SBCL it’s possible to write high performance code. Clojure is the Lisp that you’re most likely to get paid to write. It’s as performant as any JVM hosted language.

> It’s as performant as any JVM hosted language.

Surely not true if you write it idiomatically using the standard “purely functional” collections.

Re: I still Lisp (2021)

#76

Post by butterisgood »

tmtvl wrote: post #69

I vehemently disagree with dynamically typed being a winning point of Lisp. SBCL's strong support for type checking is the main reason I was drawn from Scheme to CL, and Coalton ( https://github.com/coalton-lang/coalton ) is one of the most interesting Lisp projects I have encountered. Type checking can remove an entire class of bugs from even being a consideration. Yes, it could be argued that type mismatches are a…

I think it would help the conversation along a bit if those who are against static type checking could articulate exactly how type checking gets in the way of writing correct programs.

Isn't making sure the types flowing in and out of your functions match, at some point, something you will eventually need to do anyway? Or are we trying to say the type system doesn't allow for perfectly safe things that should be allowed?

I'm not sure I understand it.

Then again, I'm also the person who wonders if the restrictions Rust puts on "valid" code aren't also too restrictive, so maybe we all exist on a gradient?

Re: I still Lisp (2021)

#79

Post by jpe90 »

floren wrote: post #10
gaze wrote: post #2

I have a suspicion that outside of the 10 people writing lisp seriously—shirakumo, stylewarning, lispm, and some others— there’s more characters of prose praising lisp being written than lisp being written. It’s a great language. I really like it and am using it for some projects. I just want people to actually use it rather than talking about using it. Edit: I’m wrong in the present case! Author has some cool projec…

I think Lisp has a sort of cachet to it, "lost secret of the ancients scorned by foolish mortals," that draws a lot of people to talk about it endlessly and speculate about how important it is instead of just... using it. I used to see the same thing in the Plan 9 community where people loved to post on the mailing list about all their grand plans for doing stuff with Plan 9, but they never even installed the goddamn…

I actually just finally tried out plan 9 in a VM and liked it so much that I’ve been using acme for almost all my development on mac via plan9port for a few weeks now.

I never bothered checking it out before because I had always seen it described as unusable so I figured it would be a waste of time.

Re: I still Lisp (2021)

#80

Post by [deleted] »

kazinator wrote: post #57
packetlost wrote: post #51

Earlier quoted context omitted.

Lisp as a great tool for learning FP paradigms for application in other languages. IMO, in practice, the metaprogramming that Lisp encourages isn't very good good for the understandability of a codebase, which is IMO one of if not the most important factors for building an applications in a company .

The objective test for whether Lisp metaprogramming contributes to or detracts from the readability of a codebase is to take a sample of the code base and expand the macros, to see whether that is more or less readable.

[deleted]
Post reply on HN