Live data from Hacker News

Why I still Lisp

mendhekar.medium.com

161–170 of 240 posts

Re: Why I still Lisp

#161
post #81
post #48

Earlier quoted context omitted.

> What thing that violates a type check would be "perfectly fine to do"? A typical example, in dynamic programming languages, is to treat numbers as strings and vice-versa; evaluate lists in boolean context; and so on. > If value is not a numeric type, square is not going to be happy. And that's the case with most (all?) dynamic code. Some programming languages will be glad to accept a string and treat it as a number…

> A typical example, in dynamic programming languages, is to treat numbers as strings and vice-versa That sounds great until it bites you in the ass really hard. In general, you want to catch unintended behavior as early as possible .

You want to, but they don’t. Those people just want to get stuff done, as opposed to a language like Haskell or stricter where you’ll never be able to get old code to run because newer compilers print errors that take a week to understand. There’s some old Yegge articles about this…

PHP converting between strings and numbers is usually a mistake, but the one data structure doing everything (array and dict) is nice enough.

Re: Why I still Lisp

#162
>"...learning Scheme ..., ...You will, however, be a much better programmer if you do and you will come to appreciate the beauty of these languages...

Sorry but this could be said just about any language as this is very personal opinion.

I for one think that knowledge of any particular language does not define being "much better programmer". Rather it is the good understanding of a general concepts and knowing how computers work.

Author's opinion about performance is also one sided. For some tasks it matters not yet it is never good enough for others.

Re: Why I still Lisp

#163
Everybody says Lisp is dynamic. OK but it's not Python. Don't forget that CL, and in particular the SBCL implementation, does pretty good compile-time type checking. Nice to note is that we get the warnings instantly because during development we can compile the function we are working on with a keystroke. Sure it is not a Hindley-Mindler type system (there's one in development: https://github.com/stylewarning/coalton/) but it is "good enough".

BTW, Atom and VSCode have pretty good plugins this day (https://lispcookbook.github.io/cl-cookbook/editor-support.ht...) and CL might have more libraries than you think (https://github.com/CodyReichert/awesome-cl). A lot is going one.

Re: Why I still Lisp

#164

Earlier quoted context omitted.

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

how about using something like clojure.spec where you need it most to help make that long term payment?

It's an interesting take. e.g. provide specs/types across module boundaries only. Gradual typing is certainly becoming popular. Meanwhile, statically typed languages are adopting type inference. Some people only write the types for the exports in their modules. The two worlds are coming closer. More statically typed languages are adding dynamic type information (like Go). More dynamically typed languages are supporting static type markup (like Python).

Re: Why I still Lisp

#165

Earlier quoted context omitted.

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

OK, now I understand your point. C's static type system is inadequate to prevent C's security issues - that's kind of self-evident, when you put it that way. [Edit: More precisely, C's type system is inadequate to prevent the kinds of security errors common in C code.]

What's your stance on a stronger static type system being able to prevent them?

Re: Why I still Lisp

#166
post #98
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…

> You have to be really incompetent to write a typical Java service in a way where it is no longer possible to develop it at all I've seen multiple Java services reach this state and require complete rewrite as the only path forward. I think you've just had one kind of experience and are making conclusions out of it, but in your case, I don't think the programming language is a factor. You just happened to see some f…

Yeah...or where it's possible to develop, but a feature that -should- be all of a week, is a multi-month effort.

In fact that seems like the norm for any Java project that has been ongoing more than a year.

Re: Why I still Lisp

#168
post #38
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…

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

That's fair, but can you explain the context here? I.e. why are we trying to capitalize all the field names of a record object? This may be an 'XY' problem--you may be trying to accomplish some final goal and 'capitalize all the field names of a map' seems like an obvious intermediate step to you, while to a statically typed language programmer they may take a very different approach.

Re: Why I still Lisp

#169

Earlier quoted context omitted.

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

The auto-completion is purely Python's dynamic-dispatch problem though. Lisp has symbol-based auto-completion which doesn't suffer from the same issue (search is a different story!). This sounds terribly controversial, but I would love to know /when/ the static-typing pays off compared to a looser approach like sound-gradual typing (where you basically export types at a boundary and make sure that you don't violate t…

> I would love to know /when/ the static-typing pays off compared to a looser approach like sound-gradual typing (where you basically export types at a boundary and make sure that you don't violate those).

When you are in a codebase where you don't know which modules have been soundly typed, and which ones are still in the 'gradual' phase.

Re: Why I still Lisp

#170
post #50

Earlier quoted context omitted.

I suspect what he’s referring to is the fact that so many people think that, because they have 100% code coverage in their tests, they have quality software. I’ve seen so many times a team claim that with pride when it’s brutally obvious to anyone who looks that the product is broken. They just don’t seem to be able to reconcile that problem when asked about it. What you test matters every bit as much as how much you…

That's part of what I was talking about, but the original statement in the article was that rigorous testing guarantees software quality, and it also says "there is no other solution", and that is demonstrably false. One example: A telecom product that processed phone calls. I stepped into a role on the team building the call progression handling system, which was based on an ad hoc state machine and some inter-task…

While I agree with you in general, it should be noted that OP was talking about unit tests, not manual or integration tests. Unit tests are always touted by dynamic typing people as their equivalent of the static typing fast feedback loop.
Post reply on HN