Live data from Hacker News

Why Lisp? (2015)

blog.rongarret.info

61–70 of 174 posts

Re: Why Lisp? (2015)

#61
post #3

Better question: why not Lisp?

I cut my teeth on Lisp, but I've found that happiness comes from compile time guarantees. Maybe those two things aren't mutually exclusive, but a thoroughly robust type system seems like a big ask in such a dynamic language. None of the solutions I've encountered have satisfied me, but in fairness I haven't looked that hard.

I've been here before

I came to Clojure from F#/ReasonML/C#/PHP/JavaScript so I understand the comfort in specifying something with a type system and what it's like to not have one and what it's like to have a weak/strong one

Compile time for Clojure is when you inject new code into your running program

Imagine you have a large codebase with lots of interconnected types and then you tasked the computer with checking all those types everytime you injected

Would that slow down the code injections for you and every other developer? Yes maybe, what about checking for probable errors? Again yes but slower, the feedback loop in lisps are what make them feel magic so this would be a problem

What could we do to maintain dev speed and confidence?

This is my current approach:

First is clojure-lsp (clj-kondo) this will check for silly Monday morning mistakes and do it in a separate process so I can code inject unhindered but still spot errors via my editor

Second is a new library called hyperfiddle/rcf they are inline tests that run on code injection so any static assertion I want to write about data or functions I can

They will run under "compile"/code injection time and can be solidified into "real" tests at any time and maybe more importantly serve as great communication for how to use functions and what kind of data you can expect to flow through them close to the original definitions

For me those things combined with TDD, the repl and the static analysis from intellji and writing real tests every now and again is enough confidence for me and I'm in control of the "compile" time cost not the language

So when it comes to green/red cycles in TDD the repl (code injection) is great for creating code/solutions and hyperfiddle/RCF is great for creating the safety harness required to fearlessly refactor all triggered from inside the editor it's really addictive

Re: Why Lisp? (2015)

#62
I started my programming in the more "traditional" way i.e., C/C++ and then later python. When I started doing python, I was flabbergasted to find that I could just do 100**100 and get a complete number without using any additional libraries. Similarly, reversing string was trivial using the [::-1] notation. Heterogeneity of Lists, Dictionaries and the resulting versatility blew my mind. I now understand that I was discovering, at that time, what dynamic language had to offer over static languages.

I say all this because I would really like some great examples and use cases which would sort of highlight what LISP has to offer over the, for the lack of a better word, non-LISP languages. All of the articles that pop up in hacker news or other portals only seem to highlight the fact that LISP presents a new paradigm (?), enhances intuition (?), and that LISP macros are the best-thing ever. I would like to share the sentiment but ideally via a few digestible examples in lieu of a serious commitment required to basically learn an entire language. I would appreciate a few concrete examples (very much like [::-1] and 100**100) that would allow me to get what LISP really is about.

Re: Why Lisp? (2015)

#63

Earlier quoted context omitted.

Could you elaborate a few specific points on this? Curious because I'm on the same boat. I was annoyed for a while how ruby convention uses '?' characters at the end of method names that return a boolean. I'm not even that old and I still want to yell `[a-zA-Z0-9_]+` identifier names or get off my lawn.

Why would you want to limit yourself so drastically in what you can express with function and variable names?

I don't think this is drastically limiting, it's a sane subset that gets you 99% of what you need from a function name.

Re: Why Lisp? (2015)

#64
post #26

What's a good Lisp dialect to write small programs in? I have some Emacs Lisp experience but I wouldn't use it to automate small tasks. For that, I typically use Python.

I haven't tried it, but there is Janet (https://janet-lang.org/) that seems pretty well suited for building small scripts. It was submitted a few times recently here on HN.

Re: Why Lisp? (2015)

#65
post #63

Earlier quoted context omitted.

Why would you want to limit yourself so drastically in what you can express with function and variable names?

I don't think this is drastically limiting, it's a sane subset that gets you 99% of what you need from a function name.

We use punctuation and symbols in typography and writing to provide clarity. Why not use it in our programs?

Re: Why Lisp? (2015)

#66
post #63

Earlier quoted context omitted.

I don't think this is drastically limiting, it's a sane subset that gets you 99% of what you need from a function name.

We use punctuation and symbols in typography and writing to provide clarity. Why not use it in our programs?

Programs? Aren't we talking about variable and function names?

But for the general case, Lisp does use puncuation and symbols. It just tends to use less. The other side of the balance is operators like ~+#>. Most languages are in the middle ground. All of these options are fine and have their uses. I wouldn't like to see stuff like ~+#> every day, but I like being able to implement <.

Re: Why Lisp? (2015)

#67
post #3

Better question: why not Lisp?

I cut my teeth on Lisp, but I've found that happiness comes from compile time guarantees. Maybe those two things aren't mutually exclusive, but a thoroughly robust type system seems like a big ask in such a dynamic language. None of the solutions I've encountered have satisfied me, but in fairness I haven't looked that hard.

I'm fairly new to lisp programming, but there's a language called Coalton that provides static type checking to Common Lisp. I believe both languages are one and the same, but Coalton provides some type guarantees while still being able to have all of the interactiveness CL devs are used to.

https://github.com/coalton-lang/coalton

Re: Why Lisp? (2015)

#68
post #66

Earlier quoted context omitted.

We use punctuation and symbols in typography and writing to provide clarity. Why not use it in our programs?

Programs? Aren't we talking about variable and function names? But for the general case, Lisp does use puncuation and symbols. It just tends to use less. The other side of the balance is operators like ~+#>. Most languages are in the middle ground. All of these options are fine and have their uses. I wouldn't like to see stuff like ~+#> every day, but I like being able to implement <.

Programs are composed of those things.

Re: Why Lisp? (2015)

#69
Why does it feel like there’s more prose about lisp being written than lisp code? I swear there’s like 15 people writing Common Lisp — Nikodemus, Shirakumo, Stylewarning, Christian Schafmeister, Borodust, the ITA folks, and maybe 2 startups.

Re: Why Lisp? (2015)

#70
post #62

I started my programming in the more "traditional" way i.e., C/C++ and then later python. When I started doing python, I was flabbergasted to find that I could just do 100**100 and get a complete number without using any additional libraries. Similarly, reversing string was trivial using the [::-1] notation. Heterogeneity of Lists, Dictionaries and the resulting versatility blew my mind. I now understand that I was d…

Simple digestable examples that show off power is kind of a cart before horse situation. However, I will try to feed your curiosity.

One simple example I can describe is from the book Practical Common Lisp and it is talked about to some degree in the SICP videos. The idea of the environment being captured as well as what it points to is a big idea. At the risk of not getting it explained 100% to everyone's satisfaction I would suggest reading about it.

I also would suggest the problem of the N queens board. It is a pretty good starting point into how this problem can be solved in lisp. I suggest the MIT SICP lecture on it because it is well paced and interesting. Also it shows off some, for the time, advanced language features.

Another good read is Norvig's PAIP book that you can read on Github. Lots of problems you can jump to with pretty good explanation in my opinion.

I'm sure there are more interesting things I could point to. However, I still consider a read of Practical Common Lisp a good starting point. The book is fairly well paced and not bogged down with learn all the language first-isms. Also, the SICP videos are pretty good to watch. I hope these points are helpful to you.

Post reply on HN