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

91–100 of 240 posts

Re: Why I still Lisp

#91

Post by moocowtruck »

madmax96 wrote: post #66
dack wrote: post #38

Earlier quoted context omitted.

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

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?

Re: Why I still Lisp

#92

Post by vram22 »

lmilcin wrote: post #71
mumblemumble wrote: post #53

Earlier quoted context omitted.

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

It is the frameworks that give more rigidity and boilerplate, not so much those languages themselves (although Java does have more boilerplate than Ruby). You have a lot of freedom when you program in plain Java and Ruby vs. using frameworks in those languages. And that is at least partly by design. See the Template Method design pattern, which is the basis of frameworks that use Inversion of Control (IoC).

Re: Why I still Lisp

#93

Post by vram22 »

jimmyvalmer wrote: post #36
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…

> 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, Disagree. Anything can be made write-only. > but in Clojure it is just enough to get couple of people that are intelligent enough to write macros but not experienced enough to understand the dangers of lack framework forcing the structure of your application. Sentence doesn't parse on mult…

Yes, same thing noticed here. Incoherent sentences above, in your parent's comment.

Re: Why I still Lisp

#94

Post by didibus »

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.

An anecdote at this point is at least better than a baseless claim as you're making.

Also keep in mind the article is in the context of Lisp, so it would be static types on top of a garbage collected memory managed runtime with runtime type checks.

Re: Why I still Lisp

#96

Post by piercebot »

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…

How do you find REPL integration in Common Lisp compares with Clojure? I find myself blissfully productive in Clojure, and I wonder if it's the same for all Lisps

Re: Why I still Lisp

#97

Post by vram22 »

SomeHacker44 wrote: post #60
base698 wrote: post #49

Earlier quoted context omitted.

Agree with him. Coming from an OO background I always cringed at the 15,000 line classes with 2000 line methods. Side effects everywhere. In my naivety I thought functional programs with their emphasis on lack of side effects could help. I then encountered a project that was totally functional but written entirely by people with no functional experience. The entire application was unmaintainable even in the most basi…

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

I don't know Lisp well, but I remember PG saying in one of his books or essays, that Lisp is a language in which you can compile and run at read time, and the other two possibilities, too.

Re: Why I still Lisp

#98

Post by didibus »

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…

> 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 failed Clojure projects, as I happen to have seen failed Java projects.

Re: Why I still Lisp

#99

Post by lmilcin »

lispm wrote: post #86
mumblemumble wrote: post #53

Earlier quoted context omitted.

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 may take a while to see the visual clues: indentation, formatting, structure patterns. Beyond simple lists, Lisp uses a variety of list structure patterns for language constructs. It's a bit like learning to ride a bike: initially it looks not possible to balance, steer and move forward at the same time. One thing that's not that usual is that authors can implement new language constructs themselves. Thus one may…

I think it is important distinguish the necessary from accidental complexity.

Macros are typically more difficult to understand but if done well that would be because they are sinking complexity from a bunch of code.

For example, if a macro implements variations of repeating construct, you are removing those variations from your entire codebase and putting complexity of dealing with that into a single macro.

Now, the issue is when you start creating accidental complexity.

For example, there are various techniques that reduce overall complexity just by being consistent in how you do things. Using only hygienic macros or writing macros consistently in a way that allows the reader predicting what they do reduces a lot of perceived complexity.

If the reader of the code does not have to understand the macro to be able to more or less predict what it does and what are basic guarantees it provides, it reduces a huge amount of complexity when you try to read and understand.

If writing a macro can be compared to writing an operator in a language then all other language design rules apply. It would be a bad language that constantly surprises the user.

Unfortunately, Lisp code tends to be much more abstract with lots of complex, custom operators (macros) as building blocks. If these building blocks are not clear and cannot be relied upon (ie. you don't understand how they work and can't predict what they will do) then this is much more damaging to trying to understand how the codebase works than writing unclear functions.

Re: Why I still Lisp

#100

Post by lisper »

rini17 wrote: post #78
lisper wrote: post #61

Earlier quoted context omitted.

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

> Most implementations of Common Lisp prevent shadowing builtin symbols.

So? Make your own package.

Post reply on HN