Live data from Hacker News

Why I still Lisp

mendhekar.medium.com

151–160 of 240 posts

Re: Why I still Lisp

#151
post #89

Earlier quoted context omitted.

If one uses a Lisp interpreter, macro expansion may happen at runtime. CLISP example: [2]> (defmacro add2 (place) (print 'add2) `(incf ,place 2)) ADD2 [3]> (let ((a 1)) (dotimes (i 4) (add2 a))) ADD2 ADD2 ADD2 ADD2 NIL [4]> As one can see the macro form is expanded four times at runtime.

This is a confusing example, because in a REPL steps of compilation and evaluation are interleaved. Indeed, can you write a program for CLISP that works like this: - takes one command line argument (a file name) - reads in the given file, interprets it as Common Lisp code, expecting it to deliver a definition for the add2 macro - then runs (let ((a 1)) (dotimes (i 4) (add2 a)))

> This is a confusing example, because in a REPL steps of compilation and evaluation are interleaved.

The CLISP REPL does not compile, thus it can't be interleaved.

> then runs

It will still be interpreted and the macro will still be expanded at runtime.

Re: Why I still Lisp

#152
post #8

I think Lisp is going to live forever as a niche tool for people who "get" it. I use Clojure on a daily basis. Not necessarily because it is best Lisp, but rather because I am working with Java applications and being able to reuse the same Java code I have already developed is a huge boon to me. If I was able to choose, I would be using Common Lisp. The way I use it is to quickly develop adhoc tools and PoCs and more…

How do you find REPL integration in Common Lisp compares with Clojure? I find myself blissfully productive in Clojure, and I wonder if it's the same for all Lisps

Yeah the REPL in your typical Common Lisp is much more integrated than nrepl/cider in Clojure. Things like restarts and the debugger are built with the REPL in mind.

Re: Why I still Lisp

#153
post #71

Earlier quoted context omitted.

I 100% agree that disastrous codebases are every bit as likely in other languages. But it somehow hurts more in a lisp. I think that the syntax really is the culprit. In a language like Java, the Byzantine syntax and semantics enforce some minimum level of structure on the code. It's not much, but it's something, just enough to give an experienced programmer a few extra heuristics they can use to make sense of what t…

I spent a lot of time thinking about this. What makes Perl or Clojure such fun languages to work with is they don't impose structure on you. You can do whatever the hell you want. On the other hand result of this is the code represents basically how you think about the problem. Which would be very different for every person. Languages with frameworks like Java+Spring, Ruby+Rails etc. are less "fun" to work with becau…

> What makes Perl or Clojure such fun languages to work with

... while you're writing a small program by yourself ...

> is they don't impose structure on you. You can do whatever the hell you want.

You mean, there is nothing _preventing you_ from doing whatever the hell you want. That's not the same thing.

Re: Why I still Lisp

#154
post #38

Earlier quoted context omitted.

> What thing that violates a type check would be "perfectly fine to do"? One good example is where you might treat records or "product types" as maps Let's say you want to write a function that can capitalize all the string fields in the object passed in. In a dynamic language, you could map over the values and apply capitalization trivially. It would be a one-liner. In a static language, you'd have a few options, bu…

There is no limit on the number of problems easier to solve using dynamically typed languages. For an individual hacker, dynamically typed languages make a lot of sense. I don't forget what types my functions accept as I am writing a program. All static typing can accomplish is slow me down when I'm trying to bang out something. This is why Python (for instance) is loved by data scientists, researchers, and startups.…

Coming back to even your own ~+1KLOC project after 3 months of working on other things, compiler enforced types can help you jump right in

Re: Why I still Lisp

#155
post #49

Earlier quoted context omitted.

Agree with him. Coming from an OO background I always cringed at the 15,000 line classes with 2000 line methods. Side effects everywhere. In my naivety I thought functional programs with their emphasis on lack of side effects could help. I then encountered a project that was totally functional but written entirely by people with no functional experience. The entire application was unmaintainable even in the most basi…

> Macros modify code structure at runtime so obviously that is fraught with danger. You may have inadvertently misspoke, but macros operate at compile time, at least in the Lisps I have used.

Macro's are evaluated inside of 'defun, however, 'defun is evaluated during runtime (when the .lisp file is being loaded into the implementation) so base698 is technically correct.

Excepting that it is not really "fraught with danger" unless you are redefining macro's that have already been expanded and cached in function definitions.

Re: Why I still Lisp

#156
Every time I try out a dynamic language, I miss static types. I just love them so much for refactoring and the ability to more fully describe how components should interact with one another.

Then when I factor in the incredible performance and efficiency of a language like Rust, thinking about all the extremely difficult performance problems I’ve had to diagnose in even fast JIT languages like C# or modern JavaScript runtimes, I just can’t stomach the idea of choosing a language like that if I have another choice.

So maybe Lisp would be a revelation, but I just can’t bring myself to care.

Re: Why I still Lisp

#157

> What improves (and guarantees) software quality is rigorous testing. To deliver high quality software, there is no other solution. This is 100% false. You can’t inject quality into a bad design via testing. You can’t guarantee quality or correctness through testing. Testing is the second worst place to find errors. You get a MUCH higher roi by producing thoughtful written designs and getting them peer reviewed. And…

I wonder how much experience you have in the real world. All of us developers had this thought at some point. I've seen terrible code with plenty of quick hacks on top of that, which was running very stable, because it was battle tested for years in production. What do you think will happen when you refactor such code to a better design? All juniors would think this is the best way to get a stable codebase. Reality i…

> I've seen terrible code with plenty of quick hacks on top of that, which was running very stable, because it was battle tested for years in production.

"Battle tested" is not what is meant by testing here, though. And I've seen software that was "battle tested" and rock-solid despite barely being _actively_ tested at all. Mind you, it was at least part of the economics of the software itself - "battle" (i.e. "in production") testing was perfectly viable in its case.

Re: Why I still Lisp

#158
post #136
post #17

> I have never had a static type checker (regardless of how sophisticated it is) help me prevent anything more than an obvious error (which should be caught in testing anyway). Obvious in retrospect is not the same as obvious. And such errors happen all the time, the same way without syntax checks typos happen all the time. And "caught in testing" is 2 extra steps removed from caught immediately by the syntax checker…

> What thing that violates a type check would be "perfectly fine to do"? Here is an example limitation of typescript's type system that I routinely run into while developing real code [1]. I look at it like this. If you consider all possible programs, some are invalid, some are valid, and some are valid and useful. A type system's job is to reject as many invalid programs as possible while accepting as many valid pro…

[deleted]

Re: Why I still Lisp

#159

When I look at languages I use regularly (largely Emacs), Lisp is the one I'd love to try to build something large with. It feels quite powerful and the syntax is pretty easy to understand. It could just be my personal lack of experience with Lisp, but there seems to be little standard in naming conventions and code formatting. This may be where a lot of developers look at Lisp code and declare it an unmaintainable m…

Emacs is a bit special; a significant number of practitioners are hobbyists in ELisp and not professional programmers (which is a great thing!). I don't judge the quality of C# code by looking at amateur Unity scripts for example.

Depending on your flavour of Lisp, there are a /ton/ of naming conventions. Here's a good reference for Scheme/Racket [1], under the section "Names".

[1] https://docs.racket-lang.org/style/Textual_Matters.html

Re: Why I still Lisp

#160

> As a programmer, I carry around invariants (which is a fancy name for properties about things in my program) in my head all the time. The author has probably not worked on large code bases or even in teams. I often forget even my own code's purpose six months after having written it, let alone code written by teams of hundreds of people and millions of lines of code. Dynamically types will kill you in such (common)…

> I started serious programming in my teens in BASIC on a ZX Spectrum+, although I had previously dabbled in (hand-) writing Fortran programs > I ended up studying Programming Languages at Indiana University with Dan Friedman (of The Little Lisper / The Little Schemer fame). It was my introduction to Scheme (and the world of Lisp.) I finally knew that I had found the perfect medium to express my programs in. And it h…

> Author seems to have over 25 years of experience.

That doesn't mean much. The author has been a researcher, and then moved into management, now working on a relatively simple e-commerce project with one of the most hilarious mission statements I've ever read.

It's the kind of guy that makes me _shudder_ when he shows up in a workplace - because I already know I'm going to have to clean up after them. His dismissal of the documentation value of type systems really tells you how much experience he _actually_ has - my comeback to static typing, as is for nearly every programmer I know, specifically because of how reliable things like "look up the source/documentation/whatever" can be in statically typed code. Not everyone cares, and that's fine, but such a dismissal tells me he's very sheltered, and vastly overestimates the real complexity of his own projext.

Also apparently he worked on AspectJ, which to me tells me everything I need to know, and also probably explains why he hates the JVM even more than I do.

Post reply on HN