Lisp: More is less • Hacker News Board

Re: Lisp: More is less

#111

Post by Confusion » Mon, Jan 20, 2014, 4:55 PM UTC

innguest wrote: post #71

147 wrote: post #70

Earlier quoted context omitted.

How are you liking Racket instead of Rails? I'm assuming you're using it for web development. I was a Rails dev that moved to Clojure and I don't know much about Racket at all, but how is the library situation? Of course in Clojure if I ever need something I can count on being able to find it in Java and interop with it.

To be fair and not to mischaracterize the situation, I have been programming in lisp for at least 5 years in personal projects, so it's not like I had to learn it now and I also did not convert from Ruby to lisp. I never liked Rails. I don't like anything that focuses on files, because in my mind the fact that code needs to be saved in the filesystem is simply incidental, so no code should rely on that fact; but Rail…

I would like to hear more about your reasons for choosing Racket over Clojure.

Re: Lisp: More is less

#112

Post by coldtea » Mon, Jan 20, 2014, 5:44 PM UTC

nickik wrote: post #103

coldtea wrote: post #95

Earlier quoted context omitted.

> In our field, tools get chosen not by merit but by what's the current fad. It's unfortunate, but this fact makes those two questions unhelpful in moving the discussion forward. That's an idealistic and elitist response. Very removed from the empirical and scientific spirit, which would suggest that if people use other languages for large projects (say C/C++) there are reasons for this, besides them being "fashion v…

The idea that the core language is not what drives adoption is clear. There are a ton of other things that go into this kind of thing. Tooling, Library, Schooling, existing base of people that know the language, CPU architecture, Memory constraints and so on. And of course all the nontechnical things like marketing. So saying that there is not as much lisp as c++ code is not a argument that c++ is a better language.

That's true, but the fact that you can somehow seperate the core language from the other factors ("tooling, library, schooling, existing base of people that know the language, CPU architecture, Memory constraints") is a fallacy.

Might be possible for a totally academic or greenfield small time project, but not at all if you do commercial and pragmatic oriented development, with teams, constraints, deliverables etc.

So while I agree that "that there is not as much lisp as c++ code" is not a argument that c++ is a better (core) language, I also think that this fact shows that C++ is a better language+extras for more projects.

Re: Lisp: More is less

#113

Post by mattfenwick » Mon, Jan 20, 2014, 6:45 PM UTC

coldtea wrote: post #33

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…

> This post repeats two memes that float around the programming language space. One is: "it's so powerful that it's bad". Also known as "less is more", which is a well established point in programming, and with a lot of historical examples to showcase it. > The other is: "it's ok, but not for large projects". I don't think I've ever seen any evidence attached to either. Well, were are the sucesfull large projects wri…

I don't get how taking away macros is "less is more".

Since macros provide capabilities that no other feature does, it seems to me that taking them away is "less is less".

As I understand it, the intent behind "less is more" is to boil things down to a minimal number of 'things' (for lack of a better word) without sacrificing capabilities, which in practice involves getting rid of redundancies and overlap while coming up with orthogonal 'things'. Reducing the number of 'things' while also sacrificing capabilities seems to be throwing out the baby with the bathwater.

(Although to be honest, I've been unable to find a definition of "less is more" in the context of programming anywhere.)

Could you clarify what you mean by "less is more"?

Re: Lisp: More is less

#114

Post by roma1n » Mon, Jan 20, 2014, 6:57 PM UTC

innguest wrote: post #71

147 wrote: post #70

Earlier quoted context omitted.

How are you liking Racket instead of Rails? I'm assuming you're using it for web development. I was a Rails dev that moved to Clojure and I don't know much about Racket at all, but how is the library situation? Of course in Clojure if I ever need something I can count on being able to find it in Java and interop with it.

To be fair and not to mischaracterize the situation, I have been programming in lisp for at least 5 years in personal projects, so it's not like I had to learn it now and I also did not convert from Ruby to lisp. I never liked Rails. I don't like anything that focuses on files, because in my mind the fact that code needs to be saved in the filesystem is simply incidental, so no code should rely on that fact; but Rail…

I was under the impression that Clojure has been designed around immutability, and Racket not so much... ?

Re: Lisp: More is less

#115

Post by stchang » Mon, Jan 20, 2014, 7:56 PM UTC

rtpg wrote: post #32

Haskell, by its lazy evaluation, is basically a macro-only language, and people seem to be doing fine in that end of the world. Granted, space leak issues are pretty difficult to analyse, so it makes the language seem hard to use in practice, but that's because all the low-hanging fruit like type errors are solved by how the language is designed, so you only end up with the hard bugs.

> Haskell, by its lazy evaluation, is basically a macro-only language

This is not correct. To understand why, please see Ryan Culpepper's answer to this SO question:

http://stackoverflow.com/questions/7046950/lazy-evaluation-v...

Re: Lisp: More is less

#116

Post by nickik » Mon, Jan 20, 2014, 8:29 PM UTC

Ygg2 wrote: post #104

nickik wrote: post #101

Earlier quoted context omitted.

Two points 1. > But, that doesn't mean that modelling hierarchies is not necessary in some domains. Agree but the addition of full OOP seams overkill to reach this goal. Look at this clojure code: >(derive ::rect ::shape) >(derive ::square ::rect) > (parents ::rect) -> #{:user/shape} (ancestors ::square) -> #{:user/rect :user/shape} (descendants ::shape) -> #{:user/rect :user/square} Clojure gives you hierarchy 'À la…

> however that is a terrible reason to discard the language for 'large scale' production use I think article by `large scale` means something that needs lots of people working on it. I can see how several programming departments might form their own lisp-tribes that can't speak to each other because they disagree over tiny details (or engaged in power play).

The same thing can happen in any language and with any detail. Power play normally is political not really about language.

Also one could easly argue that macros help with this situation because the 'right way' can be encoded in a macro and then you can require everybody to use it. That seams a better solution then long documents that explain in detail how X is done (because the langauge can reduce the code dublication). I remember such things in my (short) C++ experiance.

Re: Lisp: More is less

#117

Post by nickik » Mon, Jan 20, 2014, 9:17 PM UTC

coldtea wrote: post #112

nickik wrote: post #103

Earlier quoted context omitted.

The idea that the core language is not what drives adoption is clear. There are a ton of other things that go into this kind of thing. Tooling, Library, Schooling, existing base of people that know the language, CPU architecture, Memory constraints and so on. And of course all the nontechnical things like marketing. So saying that there is not as much lisp as c++ code is not a argument that c++ is a better language.

That's true, but the fact that you can somehow seperate the core language from the other factors ("tooling, library, schooling, existing base of people that know the language, CPU architecture, Memory constraints") is a fallacy. Might be possible for a totally academic or greenfield small time project, but not at all if you do commercial and pragmatic oriented development, with teams, constraints, deliverables etc. S…

I would say it 'was' not it is. The amount of legacy java does not speak that its better right now. Only that it was better (or persived to be better) in the past. The argument for perseption vs actual 'goodness' is almost impossible to answer.

The intresting thing about java is that is was cleary worse then something and only became better because people used it so much. Java was adopted and developed around the same time that self was around as well. Now self at the time was owned by the same company, self was just as small to send over the wire, self allready very (very, very) performant (compared to java witch was grindingly slow) and had much better tooling.

The reason for all this seam that the people at sun just did not know understand what the technology they had laying around in some reasearch project.

Java was pushed and became what it is now, self was not and became what is now and thus proving that even with everything speaking for you at a point in time, you might not.

(PS, in the end it might have been a good thing that java was picked over self since self might actually have won over in the webspace and we would all be using propritary applets instead of the web we have today.)

Re: Lisp: More is less

#118

Post by slantedview » Tue, Jan 21, 2014, 3:15 AM UTC

Using a Lisp does not necessarily preclude static anlysis.

Re: Lisp: More is less

#119

Post by aufreak3 » Tue, Jan 21, 2014, 6:24 PM UTC

m0skit0 wrote: post #65

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…

By "simplicity" they mostly mean "what I'm used to". Same applies for people calling "Windows simpler than Linux". It's the same argument over and over: illegibility (because you're not used to it), too much power to handle (because you're not used to it)...

Right on. Jeff Raskin's equation is pure gold -

    Intuitive = Familiar

Re: Lisp: More is less

#120

Post by aufreak3 » Tue, Jan 21, 2014, 6:56 PM UTC

I don't find the arguments against macros workable since the emergence of syntax transformation while modeling a problem shows many deep relationships between parts of the domain .. in the cases I've seen. Just want to share some stuff that I haven't seen others write about.

I don't code much lisp these days (though getting into clojurescript a bit now), but when I used to, the cycle went pretty much like this -

1. Express what you want to express as an s-expression, capturing known structures in the simplest way I can think of.

2. Figure out which aspects can be "functions" straight forwardly and which are macros and implement them.

3. Test and iterate a bit till I like the way domain elements are composing and the way the composition looks in code. Try to reduce the required concepts in each iteration.

4. Document the relationships that have emerged from this process so others can understand it.

5. Usually I'm done, but sometimes (the few) users of my "api" come back with questions, based on which I iterate a bit more.

I've mostly followed this in building the "editing style specification language"[1] part of the product "muvee Reveal" (an automatic video editor)[2], built in a custom scheme dialect called "muSE"[3]. (Full disclosure: I've happily worked for muvee Technologies from 2002 to 2011.)

Btw - most discussion on macros and lisp seem to first assume that there two things - a) functions and b) macros. There are more, depending on the kind of lisp system you're working with.

You could form a taxonomy of sorts based on whether argument forms are evaluated and whether the result form is evaluated -

1. Argument forms are evaluated before "apply", result is a value (i.e. not evaluated). => Function

2. Argument forms are unevaluated before "apply", result is code (i.e. is evaluated). => Traditional macro

3. Argument forms are evaluated before "apply", result is code (i.e. is evaluated).

4. Argument forms are unevaluated before "apply", result is a value. => Traditional macro (depending on system)

In the course of using the domain modeling approach above, I've written stuff like functions that create one or more macros, macros that evaluate to function values (not s-expressions) and such stuff that might be considered an "abomination" by the OP ... but in the context of the domain, the concepts are usually clear enough to be used without major issues.

[1]: https://code.google.com/p/muvee-style-authoring/ [2]: http://www.muvee.com/en/products/reveal [3]: https://code.google.com/p/muvee-symbolic-expressions/