5 ms·

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 se

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

dan00 16y ago
"The whole "visitor" pattern becomes a 1-line (map...) call." That doesn't make sense. It's 'visitor pattern' -> defmethod.
- LaPingvino 16y ago
  closures in datastructures ;)
- lispm 16y ago
  You may want to reread the Visitor Pattern.
dkarl 16y ago
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.
- nadam 16y ago
  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.
  - felideon 16y ago
    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.
    - nadam 16y ago
      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)
      - numeromancer 16y ago
        "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.
nadam 16y ago
"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.)
- dpritchett 16y ago
  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.
- coliveira 16y ago
  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.
  - nadam 16y ago
    The most concise language I know is Joy. http://en.wikipedia.org/wiki/Joy_(programming_language) 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)); }
    - sanderjd 16y ago
      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.
kunley 16y ago
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 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.
- jpr 16y ago
  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.
  - kunley 16y ago
    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.
- prospero 16y ago
  In Clojure you can rewrite the second example as (-> data transform1 transform2 ... transformN). Macros are a hell of a thing.
  - kunley 16y ago
    Yeah that's true and my Clojure code contained a hell lot of -> and ->> constructs. They're very useful.
akkartik 16y ago
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-programming http://www.quora.com/Is-Arc-a-useful-language-for-web-progra...)

dan00 16y ago

"The whole "visitor" pattern becomes a 1-line (map...) call." That doesn't make sense. It's 'visitor pattern' -> defmethod.

LaPingvino 16y ago
closures in datastructures ;)
lispm 16y ago
You may want to reread the Visitor Pattern.

dkarl 16y ago

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.

nadam 16y ago
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.
- felideon 16y ago
  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.
  - nadam 16y ago
    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)
    - numeromancer 16y ago
      "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.

nadam 16y ago

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

dpritchett 16y ago
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.
coliveira 16y ago
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.
- nadam 16y ago
  The most concise language I know is Joy. http://en.wikipedia.org/wiki/Joy_(programming_language) 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)); }
  - sanderjd 16y ago
    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.

kunley 16y ago

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

jpr 16y ago
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.
- kunley 16y ago
  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.
prospero 16y ago
In Clojure you can rewrite the second example as (-> data transform1 transform2 ... transformN). Macros are a hell of a thing.
- kunley 16y ago
  Yeah that's true and my Clojure code contained a hell lot of -> and ->> constructs. They're very useful.

akkartik 16y ago

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-programming http://www.quora.com/Is-Arc-a-useful-language-for-web-progra...)