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

191–200 of 240 posts

Re: Why I still Lisp

#191

Post by adwn »

lisper wrote: post #113
adwn wrote: post #106

Earlier quoted context omitted.

That didn't answer my question. Let me rephrase it: When would you use (define (self-apply fn) (fn fn)) in an actual, real-life situation (outside of teaching lambda calculus)?

Personally, I consider teaching the lambda calculus to be a real-life situation. Teaching the lambda calculus is no less real to me than any other part of my life. But OK, self-apply is not something you're likely to see in production code, and neither are Church numerals, which is where this problem shows up for real. But MAP, REDUCE, and APPLY are, and they all have the same problem as self-apply: their static type…

> But MAP, REDUCE, and APPLY are, and they all have the same problem as self-apply: their static types are infinite.

Huh? Any semi-decent static type system has no problems modeling higher-order functions, and static types can easily be infinite via parametric polymorphism ("generics").

> Static typing is either constraining, or it is a Turing Tarpit

You're letting the perfect be the enemy of the good. Static type systems can be beneficial even when they don't solve every conceivable problem.

Re: Why I still Lisp

#192

Post by Gibbon1 »

blackrock wrote: post #190
ywei3410 wrote: post #119

Earlier quoted context omitted.

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…

The fascinating thing about Python is the ability to write functions where the parameter can intake multiple data types. I haven’t quite seen another language handle it this elegantly as Python does. Then, inside the function, you can check the parameter’s data type, and handle it appropriately. And error out immediately if the wrong type is passed in. This allows you to operate on the data at a more logical level (w…

C# has an is operator as well. I found it useful with generics.

Re: Why I still Lisp

#193

Post by hota_mazi »

lmilcin wrote: 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…

> 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 evolving it?

Re: Why I still Lisp

#194

Post by lisper »

adwn wrote: post #191
lisper wrote: post #113

Earlier quoted context omitted.

Personally, I consider teaching the lambda calculus to be a real-life situation. Teaching the lambda calculus is no less real to me than any other part of my life. But OK, self-apply is not something you're likely to see in production code, and neither are Church numerals, which is where this problem shows up for real. But MAP, REDUCE, and APPLY are, and they all have the same problem as self-apply: their static type…

> But MAP, REDUCE, and APPLY are, and they all have the same problem as self-apply: their static types are infinite. Huh? Any semi-decent static type system has no problems modeling higher-order functions, and static types can easily be infinite via parametric polymorphism ("generics"). > Static typing is either constraining, or it is a Turing Tarpit You're letting the perfect be the enemy of the good. Static type sy…

> Static type systems can be beneficial

I don't deny that. The problem is not with the idea, it's with the (usual) implementation, which is that if you don't appease the type-checker it won't let you run your program. I'm perfectly fine with a type checker that only gives me warnings but still allows me to run the code even if it isn't satisfied.

Re: Why I still Lisp

#195

Post by koonsolo »

gugagore wrote: post #188
koonsolo wrote: post #104

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…

> I would love to see highly optimized code that is easy to read. That that's a trade-off is [just] a deficiency in our programming languages and tooling around them. As we evolve are young field (and if you've had a long career, then it is even younger to you!) I trust we will find more and more highly-optimized code that is easy to read.

Computer languages are a means of communication between a human and a computer. They clearly evolved closer to human readability and understanding, and away from computer language itself.

When you optimize, your code needs to be closer to computer language again, and therefore further away from human readability.

The only way to have both, is to have a system that can optimize the code automatically. We are getting closer to that, but still sometimes this is not enough.

Re: Why I still Lisp

#196

Post by kazinator »

lmilcin wrote: 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…

> This underlines the fact that Lisp projects can very easily end in spectacular disasters.

I've been following HN since 2014 and haven't seen any submission about such a thing.

The closest was some article or comment from someone who worked at Cycorp, about some horrors of the legacy code base.

Here it is: https://news.ycombinator.com/item?id=21783828

"... the biggest mess I have ever seen by an order of magnitude"

:)

Re: Why I still Lisp

#197

Post by koonsolo »

mpfundstein wrote: post #143
koonsolo wrote: post #104

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

The original argument is what I consider one of the biggest beginner mistakes. So the inexperience argument is very much relevant.

I was young and inexperienced once, and I had the same belief. But after bumping my head against the wall, I learned. In the mean time, I saw plenty of people bumping their head against the same wall. They all learned.

So therefore I assume this person is indeed inexperienced. If I'm talking to some senior developer, then it's up to me to reassess my way of thinking, and looking where I'm missing something. But if not, then it's just the phase we all went through.

Re: Why I still Lisp

#198

Post by bluepoint »

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?

Re: Why I still Lisp

#199

Post by rini17 »

lisper wrote: post #100
rini17 wrote: post #78

Earlier quoted context omitted.

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

> Most implementations of Common Lisp prevent shadowing builtin symbols. So? Make your own package.

What's your point? In CL it is trivial to determine both at compile and at runtime the package of all symbols involved. Same for generic methods, you can query the runtime which methods it is going to use for some concrete combination of parameters. Much easier than to determine how which overload of a C++ operator does the compiler/linker deem to fit in given context.

Re: Why I still Lisp

#200

Post by bjoli »

AQXt wrote: post #48
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"? 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…

I don't think that is necessarily a dynamic language thing: that seems like your regular ad hoc polymorphism. Pascal allows it, IIIRC. So does C#. Being able to use a function on different kinds of arguments is orthogonal to the typing discussion.

Scheme, for example, is dynamic yet very monomorphic. You have length (working only on lists), string-length, vector-length, bytevector-length etc.

Post reply on HN