Live data from Hacker News

Why I still Lisp

mendhekar.medium.com

211–220 of 240 posts

Re: Why I still Lisp

#211
post #203

Can someone please recommend a situation or common daily task that I can deal with using some version of lisp, in order to learn it little by little without forcing me to learn it all upfront and it is not just emacs? Like a shell replacement? Or some configuration manager? Or how do people actually learn lisp if it is not their job?

Perhaps Babashka[0]? It sounds like the closest thing to what you want =)... Alternatively you could just use cursive[1] or vscode[2] and follow the REPL guide[3]? There's Racket, which has it's own built in environment[4]. Perhaps you'd prefer Common Lisp[5] instead, I don't believe you need to use emacs? There are options =)... - [0]: https://github.com/babashka/babashka - [1]: https://cursive-ide.com/ - [2]: https…

So basically clojure x 5 and racket x 1. But what can I actually do in practice day to day?

Re: Why I still Lisp

#212
post #87

Earlier quoted context omitted.

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…

You might be one of those experienced developers who has gone through their entire career without ever meeting a well designed, beautifully architectured application, and therefore concluded, sensibly, that all real-world applications look like shit if you look inside, and you seem to have come to believe that this is the only possible way. I have a different experience. Code that is well designed makes mistakes look…

As a 20+ year vet, what worries me is when someone starts talking in terms of good or bad.

It's a spectrum, not a binary. There is code that's just egregiously bad. There's code that's just egregiously good (and it's not clear which is more expensive to produce and maintain). But the vast majority falls into the grey area in between those extremes.

The other poster (koonsolo) has just seen enough different codebases to have come to the conclusion that it's not nearly the most important aspect of a projects success. And I agree with them on that point (wholeheartedly in fact).

Developers concentrate on it because it's what they're in all day, the same way that a DBA is going to concentrate on the data model because that's where they're at all day.

But in the grand scheme of things, developers way overblow the value of great code. I also have reservations about the claim that most developers even know what great code _LOOKS_ like, I've seen too many terrible codebases that were claimed to be well designed by their creators.

My point is that if the code isn't actively causing you problems then leave it be, and stop calling it good or bad. Call it what it is, working code that doesn't need to be bikeshedded over.

Re: Why I still Lisp

#213

Earlier quoted context omitted.

> a well designed, beautifully architectured application I've seen everything during my career, bad code with lots of bugs, bad code running stable. Nice code full of bugs, and nice stable code. The reason something was stable was never how the code looked, but how battle tested the product was. You will learn, don't worry. Plus, at a certain point, it's about tradoffs and compromises. I would love to see highly opti…

you assume a little bit to much about your discussion partners. calling them inexperienced etc... this takes away the whole strength of your argument plus lets you sound like a douche. plz fix

I agree with him. It's indicative of more idealism than practical sense, which is indicative of inexperience.

Re: Why I still Lisp

#214

In other words, static typing is pointless. It has, maybe, some documentary value, but it does not substitute documentation on other invariants. For example, your invariant might be something like I’m expecting here a monotonically increasing array of numbers with a mean value of such and such and a standard deviation of such and such. The best any static type checking will let you do is “array[float]”. The rest of y…

Thank you for mentioning that and reminding me about two of my favorite projects, Eiffel and PyContract. (Is part of why DbC is so useful is because it's an extremely concise way to write assertions?) I'd love static typing systems if they allowed for DbC-style type declarations. There are times when the thing I need to use isn't a generic int, or even a short int, but an integer three or more. That's also type infor…

Ada has that. Bounded types and subtyping.

For example, the type system is aware of the ranges of allowed values and can statically enforce this. Runtime checking is used by default but can be disabled.

Re: Why I still Lisp

#215

Earlier quoted context omitted.

> 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.

In full Lisp "compile time" is part of application execution. Now, Clojure is kind of impaired Lisp because it is written for a VM that was not intended to be used this way and so this is not that much pronounced (but you still get REPL, etc.)

Is there anything lacking from the JVM beyond tail-call elimination that Lisp needs? I know Clojure is very slow to start up but my understanding is that this is because it uses the JVM very inefficiently, and they don't seem to care much.

Re: Why I still Lisp

#216
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…

I've read a few times that Java and enterprise languages are so horribly tedious for the purpose of slowing down armies of monkeys to avoid catastrophic design. ps: what kind of clojure projects do you have in mind ?

That's a common meme but there's not much evidence for it.

Java has the syntax it does because it's based on C++. It is verbose because (a) C++ is verbose and (b) it insists on everything being inside a class. The latter is a reasonable choice given that the underlying VM needs some unit of linkage and scope ... sort of like criticising C and C++ for requiring that everything be inside a function, but there are reasons for doing it that way.

It's true that Java's designers are very conservative, and this is partly because there are many users who appreciate that their skills don't get obsoleted all that fast (a lot of whom are in enterprise roles). But that's more of an accident of a commitment to backwards compatibility and historically long release cycles. It's not like they set out to make an 'enterprise language', they didn't. It was originally meant for the embedded TV set top box world.

Re: Why I still Lisp

#217
post #202

Earlier quoted context omitted.

> This underlines the fact that Lisp projects can very easily end in spectacular disasters. This is not specific to Lisp, it happens to all dynamically typed languages. And this is why "holding invariants in my head" doesn't scale. Your objects have a type. Why not put it in the code and ask the compiler to verify it, so that future developers on that code (including yourself) will have an easier time reading it and…

Common Lisp allows to annotate code with type information, which can be checked at runtime. Also it's object system works on classes and thus generic function have arguments for those classes. Something like Common Lisp is a dynamically typed language, but where implementations can use knowledge about types, either at runtime or even sometimes at compile time. SBCL * (defvar *foo*) ; a global variable *FOO* *FOO* We…

That's amazing. I want that.

I like how clear it is about what it's for, which is the sort of thing one does all the time in other languages that lack a vocabulary for it. I'm going to assume you could put any predicate you wanted in there?

Re: Why I still Lisp

#218

Earlier quoted context omitted.

> 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…

It's possible to have 25 years of experience but if they're the same year repeated 25 times, then it's still a year :-)

Yes, but it makes you look like a fool if your argument against theirs is that they must be a newbie, when in fact they are a seasoned developer.

Instead take action to support your statements or opinions and put up some convincing argument.

Re: Why I still Lisp

#219

Earlier quoted context omitted.

> a well designed, beautifully architectured application I've seen everything during my career, bad code with lots of bugs, bad code running stable. Nice code full of bugs, and nice stable code. The reason something was stable was never how the code looked, but how battle tested the product was. You will learn, don't worry. Plus, at a certain point, it's about tradoffs and compromises. I would love to see highly opti…

you assume a little bit to much about your discussion partners. calling them inexperienced etc... this takes away the whole strength of your argument plus lets you sound like a douche. plz fix

[deleted]

Re: Why I still Lisp

#220

> Call-by-value > Mostly Functional > Dynamically Typed Sounds a bit like POSIX shell. Yeah, I know that especially people doing functional programming do not want to be compared to shell scripters, but since I know how horrible shell scripting is, I wonder if there could be a future, where a proper, mostly functional language could be the successor of the very practical bash. I mean, if we aren't doing anything soon…

Maybe have a look at Closh [1], a clojure based shell

[1] https://github.com/dundalek/closh

Post reply on HN