3 ms·

The move from mainstream OO, cast in a mediocre language like C++ or Java, to having some way to talk about higher level combinations [which the language cannot

by gord 17y ago

The move from mainstream OO, cast in a mediocre language like C++ or Java, to having some way to talk about higher level combinations [which the language cannot express] is quite an improvement. After a positive experience with GoF patterns its hard to convince people that these patterns are just a natural part of working in lisp [or clojure] : Not only can you talk in patterns, but your code can be written in patterns in a direct way. The same of UML and other formal diagramming systems - you get more expressive power much more directly via a 'domain specific language' in lisp. All the big fads are subsumed with a wave of the hand. Unfortunately some universities take what they think is a pragmatic path of least resistance and teach popular languages such as Java in place of a much more subtle and powerful language. I wonder at the sheer human waste in leagues of emasculated coders churning out verbose Java/XML/SQL 'business' apps in cubicles, forced by convention to work in an ugly way - those businesses would be much better served in terms of efficiency, quality and innovation by using a good language, and their staff much happier. Thank Gods and the lords of Kobol for giving us Python, Ruby and Clojure that they might seep through the cracks and weaken the stranglehold of obfuscation and verbosity!

Confusion 17y ago
Not only can you talk in patterns, but your code can be written in patterns in a direct way. I have never bought this argument. What does it even mean? In every language, an implementation of a design pattern can be clearly distinguished as such. This is a good thing: it allows you to easily describe parts of of your application. This part produces objects, that part provides an interface to a bunch of other code, the other part determines which algorithm should currently be used, etc.
- gord 17y ago
  Sure, it is a matter of degree - we could ask, how much extra crud is needed? I think lisp like languages have less crud, and so the idea is clearer. This is partly because lisps can act on their own expressions, transform them. This follows from extremely uniform or consistent grammar. Now you could say C++ can do that, but look at the amount of machinery needed in Boost to add something like a lambda or an accumulator 'pattern' to the language. Its a matter of degree - sure you can write a DSL in C++ [recursive descent, lex/yac, boost, macros etc] but in lisp this really is just a natural part of the language - syntactic sugar can be manufactured. Lets take the idea of a callback - this is an excellent design pattern that gives you a great deal of power. You could implement using function pointers in C, or say functor objects with operator() in C++... either way, I contend there is a lot more crud and boilerplate than there is in lisp where a lambda is a fundamental construct of the language. The more surrounding crud or machinery, the less clear the concept. In other words, patterns in lisp can be _more_ clearly distinguished as such, because there is less cruft. Often the name of the concept or pattern actually occurs in the code as a function name, for example.
  - axod 17y ago
    >> "I think lisp like languages have less crud, and so the idea is clearer." Part of being a good programmer is being able to see through crud. Personally, I don't really care about crud. It doesn't bother me. I think it's a good skill to learn to be able to recognize and understand code that's within a bowl of crud.
    - asciilifeform 17y ago
      > I don't really care about crud. It doesn't bother me. Then you won't mind when a garbage truck unloads its multi-ton cargo into your home.
      - axod 17y ago
        I don't equate crud with garbage. Crud is stuff you ignore after a while.
axod 17y ago
>> "I wonder at the sheer human waste in leagues of emasculated coders churning out verbose Java/XML/SQL 'business' apps in cubicles, forced by convention to work in an ugly way - those businesses would be much better served in terms of efficiency, quality and innovation by using a good language, and their staff much happier." Surely the whole point of that setup is that they can get some productivity from mediocre programmers. Big businesses would rather have 10 mediocre programmers than 1 superstar programmer, and things like Java allow you to do that easily. It's a good balance between power and not letting programmers make stupid mistakes. That's why it's so successful.

by gord 17y ago

Confusion 17y ago

Not only can you talk in patterns, but your code can be written in patterns in a direct way. I have never bought this argument. What does it even mean? In every language, an implementation of a design pattern can be clearly distinguished as such. This is a good thing: it allows you to easily describe parts of of your application. This part produces objects, that part provides an interface to a bunch of other code, the other part determines which algorithm should currently be used, etc.

gord 17y ago
Sure, it is a matter of degree - we could ask, how much extra crud is needed? I think lisp like languages have less crud, and so the idea is clearer. This is partly because lisps can act on their own expressions, transform them. This follows from extremely uniform or consistent grammar. Now you could say C++ can do that, but look at the amount of machinery needed in Boost to add something like a lambda or an accumulator 'pattern' to the language. Its a matter of degree - sure you can write a DSL in C++ [recursive descent, lex/yac, boost, macros etc] but in lisp this really is just a natural part of the language - syntactic sugar can be manufactured. Lets take the idea of a callback - this is an excellent design pattern that gives you a great deal of power. You could implement using function pointers in C, or say functor objects with operator() in C++... either way, I contend there is a lot more crud and boilerplate than there is in lisp where a lambda is a fundamental construct of the language. The more surrounding crud or machinery, the less clear the concept. In other words, patterns in lisp can be _more_ clearly distinguished as such, because there is less cruft. Often the name of the concept or pattern actually occurs in the code as a function name, for example.
- axod 17y ago
  >> "I think lisp like languages have less crud, and so the idea is clearer." Part of being a good programmer is being able to see through crud. Personally, I don't really care about crud. It doesn't bother me. I think it's a good skill to learn to be able to recognize and understand code that's within a bowl of crud.
  - asciilifeform 17y ago
    > I don't really care about crud. It doesn't bother me. Then you won't mind when a garbage truck unloads its multi-ton cargo into your home.
    - axod 17y ago
      I don't equate crud with garbage. Crud is stuff you ignore after a while.

axod 17y ago

>> "I wonder at the sheer human waste in leagues of emasculated coders churning out verbose Java/XML/SQL 'business' apps in cubicles, forced by convention to work in an ugly way - those businesses would be much better served in terms of efficiency, quality and innovation by using a good language, and their staff much happier." Surely the whole point of that setup is that they can get some productivity from mediocre programmers. Big businesses would rather have 10 mediocre programmers than 1 superstar programmer, and things like Java allow you to do that easily. It's a good balance between power and not letting programmers make stupid mistakes. That's why it's so successful.