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

131–140 of 240 posts

Re: Why I still Lisp

#131

Post by AnimalMuppet »

kazinator wrote: post #118
Blikkentrekker wrote: post #84

> But it has now taken a new interpretation in the last couple of decades: Static typing is a form of compile-time error checking, so it will help you produce better quality code. It is as if static typing is a magical theorem prover that will verify some deep properties of your program. This is where I call bullsh*t . [ sic ] I have never had a static type checker (regardless of how sophisticated it is) help me prev…

> That's an anecdote; facts are that serious critical bugs that lead to privilege escalation and loss of data have existed in codebases that would surely have been caught by various static type systems. Do you have any non-strawman examples of this (e.g. C security holes are strawman).

Given who you are, I'm going to give you the benefit of the doubt, but... What? C security holes are strawman? What is your basis for saying so?

Re: Why I still Lisp

#132

Post by ywei3410 »

iso8859-1 wrote: post #129
ywei3410 wrote: post #116

Earlier quoted context omitted.

An example: > y = [1] ++ [2] ;; Assume types List[Int], List[Int] > y[0] ;; This should return Union[Int, None] > y[0] + 3 ;; This should fail type-checking You /know/ the list isn't empty. Sure you can argue that /maybe/ we should be using NonEmptyList, but now imagine this code. > y = [1, 2] ;; NonEmptyList[Int] > y = (filter (lambda x: x % 2 == 1) y) ;; Has to return List[Int] > y[0] ;; Union[Int, None] Again, we…

The type system is a proof system. In your examples, the types do not imply the invariants that you want. Does this mean that the type system is faulty? No! It just means that you need to e.g. get a more expressive type system, document code properly, use smart constructors. There are many tools. Nobody said you can trivially prove everything using type systems. So what are your examples showing? I see your code, but…

Sure - but the point is that there are /diminishing returns/ on type-systems. The question is then, /where/ should one draw the line when trying to prove certain properties of code; which properties are worthwhile proving?

Are you /seriously/ suggesting that one should use Agda or Coq for most code?

EDIT. The original comment was suggesting as though dynamic and static type-systems are a dichotomy. I was pointing out that it is a sliding scale from nominally-typed ala Go, all the way to dependently-typed languages; and that's not even including model-checkers!

Re: Why I still Lisp

#134

Post by pjmlp »

arendtio wrote: post #108

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

POSIX shells are not as powerful as Lisp REPLs and Smalltalk transcript windows.

Re: Why I still Lisp

#135

Post by jedimastert »

> next cool feature being dropped into Python or Scala, or whatever their flavor of the month is

I might be off-base here, but I feel like Python is at leasta little mature enough to not really justify calling it "flavor of the month"

Re: Why I still Lisp

#136

Post by seepel »

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"?

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 programs as possible and trying to optimize for useful valid programs. Due to the halting problem this is impossible to do perfectly, so any given type system will likely accept some invalid programs and reject some useful valid programs. If the type system happens to reject your useful valid program, you'll likely have a bad day :)

[1] https://www.typescriptlang.org/play?#code/PTAEHUFNQCwQwG7TgO...

Re: Why I still Lisp

#137

Post by lmilcin »

didibus wrote: post #115
lmilcin wrote: post #71

Earlier quoted context omitted.

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…

Yes, frameworks are kind of like a smarter programmer starting you off with a code base already, so if you don't really know what you're doing you can't mess it up as much. I've still seen people mess it up, and generally it's when the developers begin to "play" with things they don't understand, like bringing in Aspect J, writing custom annotations, slowly moving logic to configuration files, starting to dynamically…

There are two more points.

If you are tech lead or manager, these frameworks are really great value because they "give" (or more like let developer find) guidance on a lot of aspects of the application.

If you created your own perfect framework, you would be responsible for providing a huge amount of that kind of guidance, but if you are using Spring your every developer can just google the answer to most (or even almost all) of the problems.

And the second point is, again, if you are tech lead or manager, these frameworks are great help preventing your "highly intelligent" developers from making a mistake and developing their own framework. I put quotes intentionally, because some developers just think themselves to be very good developers but dismiss the risks and costs of developing software that is not core part of the project (aka NIH).

With Spring regulating most aspects of the application any damage from those kinds of actions is also limited.

Re: Why I still Lisp

#138

Post by csb6 »

carapace wrote: post #59

Lisp is too complicated. For years I used to say, "I'm keeping a bank of brain cells free for learning Lisp one day." I knew it was important, I knew one day I would sit down and learn Lisp. Eventually, that day came. As it happened, I chose PG's book to start with, and (as is my wont) I began with the Table of Contents. That's as far as I got. Somehow, in the years leading up to that moment, I had acquired the neces…

> Somehow, in the years leading up to that moment, I had acquired the necessary background information to be able to "get" Lisp just from reading that ToC.

Damn, you are a genius! As for myself, I can only gain this level of understanding by skimming the index (or maybe the appendices). ;)

Re: Why I still Lisp

#139

Post by kazinator »

AnimalMuppet wrote: post #131
kazinator wrote: post #118

Earlier quoted context omitted.

> That's an anecdote; facts are that serious critical bugs that lead to privilege escalation and loss of data have existed in codebases that would surely have been caught by various static type systems. Do you have any non-strawman examples of this (e.g. C security holes are strawman).

Given who you are, I'm going to give you the benefit of the doubt, but... What? C security holes are strawman? What is your basis for saying so?

Firstly, C is statically typed, so if you're arguing for static typing as the cure for security holes, citing C examples of security hoes won't speak well for your argument Secondly, C has an incomplete static system, which has no run-time safety net to compensate for it.

Many properties of C programs go unchecked. What is checked is easily defeated with type casts. Even the numeric conversions lack safety; e.g. floating point to integer conversion is silently implicit, with undefined behavior if the value is out of range.

All of that is a straw man example if we are arguing against incomplete static type systems, because the iron man is incomplete static with strong dynamic checks.

C also doesn't provide access to the language at compile time; we cannot execute test cases for the code in the same breath as compiling it. If code is cross-compiled, it needs unit tests compiled into individual executable programs, and an emulator like QEMU to run them.

Because C doesn't have run-time safety, unit tests do not reliably flush out type errors; programs with type errors can pass unit tests by fluke due to undefined behavior. E.g. a string that is not properly null terminated can have a zero byte in the right place anyway during the execution of a test case, and so on.

C security holes are not a good example to invoke in a static/dynamic debate as something that could be prevented with static, so I'm asking that: if those are the examples, please spare the debate.

Re: Why I still Lisp

#140

Post by admax88q »

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…

It feels like Lisp scales vertically and Java scales horizontally.

Java scales for number of developers, its idioms and ecosystem make it easier to have tons of developers on a single project.

Lisp scales on the size of problem that a small close knit team can solve.

Things like the macro system in Lisp encourage defining your own problem specific DSL, which is great for individual developer productivity, but bad for involving lots of developers.

Post reply on HN