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

Why I still Lisp

mendhekar.medium.com

Post reply on HN
Print view View original

71–80 of 240 posts

Re: Why I still Lisp

#71

Post by lmilcin »

mumblemumble wrote: post #53
cle wrote: post #43

Earlier quoted context omitted.

Honestly I’ve seen just as many disastrous codebases written in highly structured, statically typed languages. Any language with intrinsically interesting features tends to attract inexperienced (or just bad) developers who don’t appreciate the tradeoffs of their tools and design decisions, and think the tool is a panacea. This leads to disastrous codebases, and is not at all limited to lisps or dynamically typed lan…

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 because you are not given so much freedom and likely have to fill in a lot of stupid, mundane boilerplate, but are easier to maintain in team setting because developers know more or less what to expect from the code. Very likely developers come with that knowledge and if you know one Spring application you know how to move around almost any Spring application.

Re: Why I still Lisp

#72

Post by carapace »

> Now wait a minute, I’m sure you’re thinking. I’ve never proved sh*t about my functions. I’m betting that you have. And that you do all the time. You’re always convincing yourself that your function is doing the right thing. Yours may not be a formal proof (which may be what leads to some bugs), but reasoning about code is something that software developers do all the time. They’re playing the code back in their head to see how it behaves.

I sometimes try to point this out when arguing in favor of Formal Methods. You're already using informal Formal Methods anyway. Just write your reasoning down and make the computer double-check it.

"Oh the expense!" I hear them cry. But where's the spreadsheet comparing that with the expense of the faulty reasoning? Where is the Manhattan Project to lower the cost of logic?

And don't get me started on (what Guy Steele Jr. calls) Computer Science Meta-notation, which has no official standard, and isn't a runnable language. ( https://groups.csail.mit.edu/mac/users/gjs/6.945/readings/St... )

Re: Why I still Lisp

#73

Post by koonsolo »

bstpierre wrote: post #3

> 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 is that you will introduce bugs by refactoring, not get rid of it. Writing code means writing bugs, no matter how pretty your code is.

This reminds me of some quote that "Junior developers write 1 bug per 10 lines of code, experienced coders know they write 1 bug per 10 lines of code"

Re: Why I still Lisp

#74

Post by smlckz »

Currently, lisp is not a single language, but a family of similiar languages that originate from the LISP.

The languages' inherent flexibility gives you too much freedom of expression to handle, especially for those who come with experience of strict languages. The minimalism of syntax and the ability to create in-effect a (sub-)language of your own also adds to that expressivity.

But we need guards to protect us from the freedom of too much expressivity, see for example defmacro vs. syntax-rules/syntax-case etc.

From my perspective, I want a language which gives me freedom when I want that, protection (''guardrails'') when I want that too, both if possible at the same time.

On invariants, what dependent typing and property testing are giving us now? How is the room of improvement on that matter?

Re: Why I still Lisp

#75

Post by taeric »

zokier wrote: post #25

> 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]”. Isn't this just plainly false? With dependent type system wouldn't you be able to encode all such invariants into the types? Curry-Howard isomorphism and so…

I suspect the problem is the types begin to get fairly heavy weight. It can also start requiring you to make many atomic operations so that your invariant holds across larger chunks of code. And, that often isn't easy or really necessary.

Re: Why I still Lisp

#76

Post by adwn »

lisper wrote: post #61
coldtea wrote: 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…

> If value is not a numeric type, square is not going to be happy. That is not necessarily true. In Common Lisp, with its generic-function based object system, you can extend the operation of any function at any time to cover new types. So, for example, one could define a method for SQUARE that operates on matrices. > What thing that violates a type check would be "perfectly fine to do"? (define (self-apply fn) (fn f…

> (define (self-apply fn) (fn fn))

Out of curiousity, what would be a practical application of this?

Re: Why I still Lisp

#77

Post by adwn »

dack wrote: post #38
coldtea wrote: 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"? 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…

As a proponent of static typing (at least for larger programs): thank you, that was a very enlightening example for when dynamic typing can be superior to static typing.

Re: Why I still Lisp

#78

Post by rini17 »

lisper wrote: post #61
coldtea wrote: 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…

> If value is not a numeric type, square is not going to be happy. That is not necessarily true. In Common Lisp, with its generic-function based object system, you can extend the operation of any function at any time to cover new types. So, for example, one could define a method for SQUARE that operates on matrices. > What thing that violates a type check would be "perfectly fine to do"? (define (self-apply fn) (fn f…

Most implementations of Common Lisp prevent shadowing builtin symbols. You get compile/runtime error like "lock on COMMON-LISP package violated". So, unless author went to extra lengths to work around it, you can rely on the standard stuff like * when you read the code.

Even for user-defined functions, it's not an usual practice to extend operation of any function (although again, it's kind of possible). There are CLOS generic functions for that.

Re: Why I still Lisp

#79

Post by mikewarot »

smabie wrote: post #64
mikewarot wrote: post #47

I've installed portacle, and ended up in a nest of errors I didn't understand. Can anyone here recommend a non-editor based version of lisp?

what is a editor based version of Lisp? fwiw, I really like Racket. It's definitely the most clean/elegant Lisp around.

Thank you!

Racket gives me error messages, which I can learn to understand, and doesn't take me into Emacs like portacle does.

The tutorial helps too... more thanks!

Re: Why I still Lisp

#80

Post by pfdietz »

johnisgood wrote: post #32
HerrMonnezza wrote: post #26

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…

That is funny, Ada/SPARK is not mentioned at all! How strange. https://en.wikibooks.org/wiki/Ada_Programming/Contract_Based... http://www.ada-auth.org/standards/12rat/html/Rat12-2-3.html https://docs.adacore.com/spark2014-docs/html/ug/en/source/ho... https://blog.adacore.com/contracts-of-functions-in-spark-201... Plus, I do not believe that static typing is pointless. Even if it were ONLY for documentation, that woul…

And then if you don't test that Ada code, you blow up your Ariane 5.
Post reply on HN