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

Lisp: More is less

jameso.be

Post reply on HN
Print view View original

51–60 of 125 posts

Re: Lisp: More is less

#51

Post by innguest »

codygman wrote: post #46
innguest wrote: post #34

The author of the blogpost is pretending to be "one of us" (people that get lisp) - in "Lisp devotees (myself once included)" - but apparently they never understood it if they're still thinking that lisps' advantages "make Lisp into an unweidly, conceptual sledgehammer that’s often out of scale with the problem being solved.". The word "often" there also makes me think they're making a point without experience or pro…

Is your team hiring?

We're a team of 6 programmers, 3 of which code Typed Racket. We all started here as Rails devs and got tired of it. I'm always pushing to invest time in research for better solutions and our team seems to be open to that (after weeks of discussion, though - we're no heaven). Typed Racket is the solution we found after surveying the field. Our management has recently told us they believe we're now a good-sized team given the projects we have to maintain. If it gets out of hand I'll be glad to know that there are people we can hire to work with these technologies. We're based in NYC.

Re: Lisp: More is less

#52

Post by lispm »

pjmlp wrote: post #43
lispm wrote: post #29

Earlier quoted context omitted.

I hear a lot of bad things about large Java code bases.

I can imagine, but the strong typing does help keeping a bit of order.

How does static typing help you to tame the use of classes, reflection, configurations, rest interfaces, db interfaces, ...?

Just on friday I was talking to someone, where he said that his developers don't like the code and feel the constant urge to rewrite it... with the core functionality being a huge mess.

Re: Lisp: More is less

#53

Post by swannodette »

Starting with "Goodbye, static analysis" it was pretty hard for me to take this article seriously. Macros desugar into primitive forms - this means most macro language extensions are amenable to static analysis! Clojure has Kibit, Eastwood, and Typed Clojure (a whole type system via ... macros!) for static analysis. In addition Clojure and ClojureScript now both have fairly powerful analyzers that catch bad style and errors today and can be extended to do even more.

Re: Lisp: More is less

#54

Post by philh »

innguest wrote: post #42
philh wrote: post #24

Earlier quoted context omitted.

I'm not sure how well that specific example works. Are contracts built in to the language on a fundamental level, or are they just part of the standard library? Given that they're not included in racket/base, and given how flexible racket's core is, I would guess the latter, but I'm not sure.

"Are contracts built in to the language on a fundamental level, or are they just part of the standard library? " One of the points of Lisp is that that difference doesn't matter. But besides that, in this case it couldn't possibly matter. You write contracts for your functions. If they're violated at runtime you'll get a clear error that stops execution to contain damage, and assigns blame to the contract violator. A…

To be clear, I'm not suggesting it's an important question per se.

_delerium presented an argument that the things people do with macros should be implemented as language facilities instead. Ve used racket contracts as an example.

I was saying that if racket contracts are not implemented as language facilities, it's not a very good example.

Re: Lisp: More is less

#55

Post by lispm »

pjmlp wrote: post #45
lispm wrote: post #38

Earlier quoted context omitted.

Still Lisp was on Unix on day two and was always a very popular platform for Lisp developers. You could even get Lisp Machines from TI with embedded Unix and Lisp Machines from TI and Symbolics which were embedded in Unix. Several Lisp companies made their entire business from Unix: Lucid, early Franz, early Harlequin/LispWorks, ...

It might be, but I imagine having an OS where Lisp is the systems programming language is way different from a system where it is just another language.

Yeah, but that does not make it 'better' or more useful.

Lisp-based operating systems are no longer used, because they were quite complex (coming out of a research environment) and provided LESS functionality in some crucial areas (for example they were not multi-user - they were one-person, one machine, one 'world'). Additionally they were expensive.

The Xerox Lisp and Xerox Smalltalk workstations one could buy were severely underpowered (RAM, speed, ...).

Re: Lisp: More is less

#56

Post by rtpg »

coolsunglasses wrote: post #47
coldtea wrote: post #35

Earlier quoted context omitted.

> Haskell, by its lazy evaluation, is basically a macro-only language, and people seem to be doing fine in that end of the world. They aren't that many to begin with, so it could just be (self-)selection bias. Forth people do fine using Forth too, but I don't see that as a point that it's an appropriate language for most projects and/or people.

There are more people in the #haskell channel on Freenode IRC than #clojure, #scala, #lisp, #racket, or #ruby.

didn't even know that.

BTW the people on #haskell are quite active, and nice :)

(maybe a pointless counter-example, I once went onto #ruby, and asked about an easy way to make a function name refer to a function( to be able to do things like list map f easily, without the superflous do |x| f x end ), and I got yelled at because I was trying to write "non-ruby code".

Re: Lisp: More is less

#57

Post by innguest »

gleenn wrote: post #23
gruseom wrote: post #3

This post repeats two memes that float around the programming language space. One is: "it's so powerful that it's bad". The other is: "it's ok, but not for large projects". I don't think I've ever seen any evidence attached to either. (If the OP contains any, I missed it.) But they're the sort of things that sound plausible and have more gravitas than "Here are my current preferences", so they get repeated, and no do…

> it's so powerful that it's bad I had the pleasure of using Cascalog in production at work, which is written in Clojure. While it was in fact written by some very smart people, we had a very difficult time using some of its constructs that were very cleverly abstracted away behind macros. The problem was that it felt nearly impossible to debug problems we had because of the long, impossible stack traces. Further, tr…

Racket is a lisp that has a specialized macro debugger to help in that very task. The point is that instead of throwing away a potentially good tool, there are people working on making that tool more reliable.

Re: Lisp: More is less

#58

Post by weavejester »

Macros are used quite rarely in Clojure. In general they swing between two extremes, either as a means of providing some simple syntax sugar, or as what effectively amounts to a language extension.

The author cites Korma as an example of a library that uses macros, but Korma only uses macros to provide a small degree of syntax sugar. So instead of writing:

    (exec (where* (select* people) `(> :age 18)))
One can instead write:

    (select people (where (> :age 18)))
It's an extremely simple transformation, and can be expressed in a few lines of code.

There are some libraries, such as core.async or core.logic, that make more extensive use of macros, but these libraries are relatively rare, and take a lot of work to get right. It's something I'd expect to see in a dedicated library, not as part of a solution in a large software project.

Worrying about overuse of macros in Clojure is a bit like worrying about overuse of FFIs in Python. Sure, it's possible to abuse in theory, but it's not really a problem in practise.

Re: Lisp: More is less

#59

Post by Myk267 »

d0m wrote: post #26
mildtrepidation wrote: post #2

[edit: While I was typing this the title was changed. It was previously Why Lisp isn't (and shouldn't be) widely used in industry , which colors my comment.] This points out some very real potential dangers of large-scale collaboration with Clojure (and presumably some or many other Lisps/Lisp-likes). However, I think the conclusion is overstated. Yes, based on what's provided, it may take more discipline and better,…

Although I love lisps, I'd rather jump in a very large Python project than a lisp one. Jumping into someone else Lisp code feels like a jungle to me. Jumping into someone else's Python code feels like my old good slipper. Part of it is due to the very strict Python standard of coding. But I think it's primarily because of the "One good way to do it" mentality. On the other hand, I feel telling a lisp programmer " Thi…

"Part of it is due to the very strict Python standard of coding."

I don't know about that. Good code is good code. It's sort of one of those, "I'll know it when I see it" things.

The ease of which you can code classes for the sake of classes in Python can make some really hairy code out of what should be simple programs. Was that necessarily the 'one right way to do it'? Who's to say. And all the static analysis tools and syntactic aren't going to undo those hairballs anytime soon.

You might just feel more comfortable with languages with lower code density. 'brandonbloom made a good blog about that[1]. I think it can be doubly applied to any situation where meta-programming is employed.

1: http://www.brandonbloom.name/blog/2013/06/24/code-density/

Re: Lisp: More is less

#60

Post by innguest »

rtpg wrote: post #56
coolsunglasses wrote: post #47

Earlier quoted context omitted.

There are more people in the #haskell channel on Freenode IRC than #clojure, #scala, #lisp, #racket, or #ruby.

didn't even know that. BTW the people on #haskell are quite active, and nice :) (maybe a pointless counter-example, I once went onto #ruby, and asked about an easy way to make a function name refer to a function( to be able to do things like list map f easily, without the superflous do |x| f x end ), and I got yelled at because I was trying to write "non-ruby code".

The Ruby community is very close-minded. I've been a victim of that behavior in #ruby as well. If you asked an equivalent question on #ror (the Rails channel) you'd get more than yelled at - no one would take you seriously from that point on.

To answer your question, because methods aren't first-class in Ruby, you can't pass them around the way you want to. I've decided I don't want my languages telling me what I can or can't do when I know what I want to do is a simple matter of making more types of pointers first-class.

Post reply on HN