Hacker News Reader

Comment by felideon | Hacker News Reader

My favorite parts:

  I am currently working in Java to re-implement an algorithm I
  prototyped in lisp. If I replace all of the required curly-braces
  and semicolons in Java with parens it turns out that the Java
  program has more parens than the lisp program. The lisp program
  is 20 lines, the Java program has crossed 100 lines and is still
  growing.

  In Java I need "factory objects", "visitors", and other such pieces
  of "design patterns". In lisp, I have never needed to write a "factory".
  The whole "visitor" pattern becomes a 1-line (map...) call. To a lisper
  "design patterns" are like dress patterns in sewing. If you can't sew
  (program) you can still make something to use by copying a pattern.
  But you can hardly consider yourself a Taylor (programmer).

View on HN

If he has to rewrite the algorithm in Java, instead of a better JVM language, it's because somebody in management has dreams of doing all subsequent work with cheap interchangeable Java programmers, probably contractors. Odds are the algorithm won't work anymore the first time they touch it. But that's a separate issue.

I studied math before getting into programming seriously. When you have the solution to a problem in your head and go to write out a proof, sometimes it goes smoothly, and sometimes you discover complications that you hadn't taken into account. It's either easy or educational. Lisp seems to be the same way. When a Lisp program turns out to be harder than I expected, it's because I didn't completely understand the problem.

Java programs always turn out to be much more complicated than the solution in my head. Even if I nailed it. And Java programmers assume I'm just inexperienced and woefully naive to think that programming could be so simple.

Interesting, but it is very different in my case. Sometimes I think days on a complicated algorithm, if it is a really hard problem. Once I know the algorithm in my head, is is totally trivial to code it in Java (or any other language I know). For me 'hardness' is not on the language level, so it almost does not matter in which language I code in provided that I know the language and preferebly it is higher level than Assembly and preferably has garbage collection.

It's not as much as the language makes it "hard" as much as it is that it makes it tedious. The language can get in your way as far as wanting to express your thoughts or algorithm.

It's the same in natural languages. In English we have the word love, in Greek you have: agápe, éros, philía, and storgē. One could thus argue that Greek is more expressive than English, as Lisp is more expressive than Java, for example.

Yes, Lisp is a more expressive language than Java. But when I have to find out a nontrivial algorithm it does not help if I use a very expressive language.

For example let's have this old interview question: find a loop in a linked list with O(1) memory. Here the used language does not matter. I feel the same with almost all algorithms.

I know that using a less expressive language can get in your way. I programmed a lot in ASM, and later in C. They got in my way sometimes. Java is a far more expressive language than Asm and C. So it is already luxury for me in a sense (although really not as expressive as Lisp)

"For example let's have this old interview question: find a loop in a linked list with O(1) memory. Here the used language does not matter. I feel the same with almost all algorithms."

Sure, it doesn't matter, as long as you don't actually write the code. When you write the code, the language then matters a great deal. I conjecture that the signal/noise ratio for such an algorithm would be much lower in Java than in Lisp.

That first paragraph resonated with me as well. I've been using lisp for just a few months, so I'm hardly the grizzled lisp veteran of stereotype. And yet when I bring up lisp and you-the-person-across-from-me-who-seemed-so-smart-until-now say parentheses are hard to read, I find it's easy to sympathize with lispers. The language has lots wrong with it, no question. But if you're pretending to be knowledgeable about the subject and your critique of lisp includes 'parentheses', you're a moron. (Exhibit A: Quora founder Charlie Cheever http://www.quora.com/Is-Arc-a-useful-language-for-web-progra...)

"I am currently working in Java to re-implement an algorithm I prototyped in lisp."

Maybe this is the problem. If I develop in Java, I think in Java. I don't prototype in other languages. I don't use 'factory objects' and 'visitors' and all such things. The syntax of JAva is a bit verbose, but I just cannot imagine that if you write something in 20 lines in any language I cannot write that in 40 lines in Java. Maybe a concrete example would be nice. Otherwise for me performnce is very important. One of the reasons that I use Java is that it is very fast (and I know how to write fast code in it.)

People do this a good bit for algorithm programming contests. Use dynamic languages to prototype out all of the good ideas you can think of, then rewrite the most promising ones in C for maximum performance.

You're probably not very creative about the language... Have you ever tried J? There are a lot of 1 line programs in J that require 100 lines of Java.

The most concise language I know is Joy.

http://en.wikipedia.org/wiki/Joy_(programming_language)

The 100 factor must be an exaggeration for most problems. In 100 lines I can put lots of information or quite complex algorithm even in Java. Some things are quite concise even in Java. See the greatest common denominator code:

int gcd(int a, int b) { return a==b ? a : gcd(Math.abs(a-b), Math.min(a,b)); }

Yeah but gcd is very simple (and also your version of it stack overflows around 7 digits, depending on how quickly a gcd is found, so it isn't really "correct") - most simple tasks will have similarly sized simple representations in nearly any language. The argument levied against Java is that it's code size does not scale linearly in relation to other languages as the complexity of the problem increases.

It's not really fair since J has a built-in function, but in J the gcd function is +.

   15 +. 10

The near-canonical example is the mean, which is not built in:

   mean =: +/%#
   mean 2 3 4 5

3.5

Other code is similarly terse. On http://projecteuler.net/ it's not uncommon to see one-line J solutions to problems where other languages have solutions from 20 to 50 or more lines of code.

> I just cannot imagine that if you write something in 20 lines in any language I cannot write that in 40 lines in Java

Try lisp. Hell, try Python or Ruby. You may be surprised.

That being said, if you are determined to write Java-esque code in other languages, I'm certain you won't reduce the number of lines greatly.

I know that it is possible to write shorter code in the above mentioned languages than in Java, but my experience is that it is rarely more than a 2 times factor. Some Java haters make exaggerations. Java (the language) does not equal J2EE, EJBs and all the buroctratic frameworks which I also don' like. Java is a simple (a bit primitive) and a bit verbose strongly typed and _fast_ language. You can even do closures in Java with anonymous inner classes. It is verbose, but it is hard to imagine that it is more verbose than 2 times.

Here is how I calculate greatest common denominator in Java:

int gcd(int a, int b) { return a==b ? a : gcd(Math.abs(a-b), Math.min(a,b)); }

Maybe the issue is I don't code in Java 'Java-esque' enough.:)

(defun gcd (a b) (if (= a b) a (gcd (abs (- a b)) (min a b))))

Declaring types makes it longer. There is not much an advantage for that type of code. Unless you go to specific languages like J, where even the math code gets quite a bit shorter. But my personal goal is not to write the small stuff even smaller. My goal is to get rid of the larger structures and hide them.

The big win comes when one uses higher-order functions and macros in any non-trivial piece of software.

Imagine all the boilerplate code that one writes for class definitions can be hidden behind some macros. If one creates the code from domain data, you can get very dense code. Then all kinds of combinations of control structures can be hidden behind macros.

In large software systems Java developers were/are doing the same using XML files to describe the code and generate code from there.

I definitely don't want to code in Java all my life. I am in the middle of a project, and I don't want to change language until it is finished. Fortunatelly there are languages which compile to the JVM, and I can use existing Java libraries from them. The only thing I want to figure out is performance. I need a language which is almost as fast as Java. I am planning to learn Scala, Clojure or something like that. If the performance will also be ok, I will probably change.

I find Ruby really close to CL/Clojure with regard to happily not using design patterns. I usually write pure code and use long method chains -- it mimics the Unix paradigm with small tools connected with pipes. I rarely write proper classes actually and I'm happy with it.

If anobody is interested, I described this style of coding here http://inthephase.org/partial-function-application-in-ruby

I also think that the oo-like call chain:

data.transform1.transform2...transformN

is better readable than:

transformN ...(transform2(transform1(data)))

because the order is transformations is not reversed, so one sees what's going on with the data in the first pass as he reads, there's no need to mentally reverse the chain. The expressiveness is the same, but the readability of the former wins IMO.

I think the oo-like call chain is nicer when you don't have any arguments and stuff doesn't nest. The difference of static vs. instance methods also makes it slighly more complicated to comprehend. I think overall the simplicity of Lisp-style nesting wins when the expressions get more complicated.

Good point -- instance methods make it all a bit dirty. I usually use some meta trickery to turn toplevel methods, which can be mentally eq to defuns, into oo-chainable stuff. Well I suppose I just should clean this code and put an example on a blog.

In Clojure you can rewrite the second example as (-> data transform1 transform2 ... transformN). Macros are a hell of a thing.

Yeah that's true and my Clojure code contained a hell lot of -> and ->> constructs. They're very useful.

"The whole "visitor" pattern becomes a 1-line (map...) call."

That doesn't make sense. It's 'visitor pattern' -> defmethod.

closures in datastructures ;)

You may want to reread the Visitor Pattern.

Reply on news.ycombinator.com