6 ms·

> Except that beauty rarely scales. I completely disagree. Beauty scales best. It's almost always deadlines, and not complexity, that uglify code. In a culture

by djacobs 15y ago

> Except that beauty rarely scales. I completely disagree. Beauty scales best. It's almost always deadlines, and not complexity, that uglify code. In a culture that values business value over code extensibility and reason-ability (my word), it is very difficult to keep a codebase clean and elegant (but it's possible). Objects make that 100x harder.

nsxwolf 15y ago
Us OO people see beauty in the object model too, not just the code. I see everything in the world as a collection of objects and their relationships. That may not be the only way of seeing things and may not always be the best way of seeing things, but it is an approach my mind naturally takes to understanding a system. I'm down with OOP.
- djacobs 15y ago
  In my opinion, objects conflate entirely too much and lead to tangled code, especially if there is any data transformation involved. Have you seen Simple Made Easy? [0] [0] http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy
  - palish 15y ago
    For an excellent example of how a clean object model can solve extremely difficult technical problems, check out LMAX's "Disruptor" framework: http://code.google.com/p/disruptor/ http://code.google.com/p/disruptor/ By rigorously separating the concerns into a clean object model, LMAX achieved a level of performance which might correctly be labeled "miraculous". http://screencast.com/t/g67kFj8nRue http://screencast.com/t/g67kFj8nRue It's written in pure Java. Amazingly, I haven't found anything that's achieved better performance thus far. It's very elegant.
    - bengl3rt 15y ago
      That was an incredible read. Thanks for the link.
    - ntoshev 15y ago
      OOP has nothing to do with the Disruptor pattern achieving that performance. I agree the concept is elegant, but I don't think the Java framework implementing it is. You can see a less general benchmark done in far less code in Go and C++: https://gist.github.com/1218360 https://gist.github.com/1218360 (and discussion http://groups.google.com/group/golang-nuts/browse_thread/thread/c47af0b94e5f9539 http://groups.google.com/group/golang-nuts/browse_thread/thr... )
    - silentbicycle 15y ago
      No, the whole point is that they're getting major speed-ups by using arrays and a giant ring buffer to avoid object allocation, reduce garbage collection, and improve cache behavior. They're writing really tightly optimized C. In Java.
    - deleted 15y ago
      [deleted]
  - drostie 15y ago
    I will say this: the reason I keep coming back from Lisp (and PHP) to JavaScript and Python is that I can do lots of functional things in the latter, but I get that gosh-darn useful little dot operator. Here are some of the many ways to silence someone who is shouting in all caps: (string-downcase yelling) ; common lisp strtolower($yelling) // php yelling.toLowerCase() // js lc($yelling) # perl yelling.lower() # python I don't really care about the parens and where they are, but the fact that clisp, php, and perl put this function in the global namespace bugs me to no end. It's a function which only makes sense when you have a string. Other things don't have the sort of "case" such that you could "lowercase" them.
    - mattdeboard 15y ago
      Curious then how you feel about `sorted()` being in the global namespace. Point being I don't understand how `.lower()` et al., being class methods instead of global functions is an argument for the greatness of Python. Ultimately the responsibility is yours for invoking it in the right place with the right type of object, no matter where you put the parens.
      - drostie 15y ago
        In Python that actually makes some amount of sense, because Python ships with something like five different sorts of lists (arrays, lists, tuples, OrderedDicts, generators) and it's a reasonably generic idea. And it helps that for the one 'proper' case of this, lists, Python also supports list.sort(), so that "it is where it's supposed to be" as well. The only problem with list.sort() in Python is that it's void; it returns None. It should either return self (and sort self) or return a sorted copy of self, like sorted() will. On the other hand, in JavaScript, array.sort() is known to be a little broken: > [48, 19, 7, 14, 30, 22, 45].sort() [14, 19, 22, 30, 45, 48, 7] Wat. It's true that I have ultimate responsibility for my code, and it's true that in Python I can write: x = 3 x.lower() ...and unlike Java it will not complain that it has no idea how to "lower" 3. But it still suggests like Java suggests that we're going to narrow down the wildly branching tree of possibilities. When I'm sitting in the Python REPL, and I have an object x, I'll often just call dir(x), to see what I can do with it. What would Common Lisp tell me? It would kindly tell me that it's syntactically valid to call (string-downcase 3), even though that will produce a noisy error. So if I wanted to list all of the things I can do with 3, we would be here for a long time.
  - bwarp 15y ago
    This actually only happens if you don't think first or don't understand ever. Thinking and understanding takes more time than programming in my experience. The same level of fail will accumulate regardless of the language if you don't know what you are doing.
josephcooney 15y ago
The real world makes code ugly. Network connections that fail part-way through sending. Other people's code that you have to integrate with that block for long periods under certain circumstances. Special cases in business logic that spoil the beautiful abstractions you'd created. Customers with funny characters in their names. Hard drives that fail. 'needs to provide business value' is another one of those pesky real-world requirements that just keeps popping up. Complaining that this gets in the way of beautiful software is akin to transit system operators complaining about passengers interfering with the running of their trains/buses/whatever.
- adeelk 15y ago
  “Real-world requirements” don’t make code ugly. They just make the problem harder. Hard problems still have elegant solutions.
aufreak3 15y ago
I find code that does more with less to be beautiful and valuable. Note that I'm not including code that does the same with less. As with all things beautiful, this is tough to illustrate, so I'll use an analogy here from Physics. Page "xv" of the book "A course in mathematics for students of physics" (volume 2) by Paul Bamberg and Shlomo Sternberg contains a table (do a "look inside" on Amazon) that shows four forms of Maxwell's equations as they evolved over the course of history. Each change expresses what the previous one did, but contributes something more that wasn't possible or was very difficult to express with the earlier form. The first form explicitly uses cartesian coordinates. The second form is the vector notation, which helps conceptualize and work with the equations in any coordinate system appropriate to the problem (circular, cylindrical, etc.). The third is the relativistic "four-vector" formulation, which, though it says the same thing as the vector form, allows extension to curved spacetime. The fourth exterior calculus formulation (which just reads "dF = 0, and 𝛿F = J"!) covers all of the preceding ones, and also takes exactly the same form when applied to circuits (the kirchoff laws, etc.) which is not something you can say for the preceding forms, while allowing generalization to higher dimensions. The mathematical machinery invented for that simple looking expression is incredibly beautiful (and that book does a great job of its exposition, imo). This kind of beauty in software is very desirable in my opinion and we do have examples like MapReduce to show for it. Yes the machinery to do a distributed MapReduce is complex, but the concept is simple and flexible and has a bit of the "exterior calculus" fragrance to it. Another is continuations in Scheme - which not only can replace any "mundane" control transfer (break, continue, throw, catch, and ilk) but can do much more than just those and lets you roll your own too. I believe that is the kind of beauty we should be striving for in software, not just the "pretty code" kind. (minor edits)

by djacobs 15y ago

nsxwolf 15y ago

Us OO people see beauty in the object model too, not just the code. I see everything in the world as a collection of objects and their relationships. That may not be the only way of seeing things and may not always be the best way of seeing things, but it is an approach my mind naturally takes to understanding a system. I'm down with OOP.

djacobs 15y ago
In my opinion, objects conflate entirely too much and lead to tangled code, especially if there is any data transformation involved. Have you seen Simple Made Easy? [0] [0] http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy
- palish 15y ago
  For an excellent example of how a clean object model can solve extremely difficult technical problems, check out LMAX's "Disruptor" framework: http://code.google.com/p/disruptor/ http://code.google.com/p/disruptor/ By rigorously separating the concerns into a clean object model, LMAX achieved a level of performance which might correctly be labeled "miraculous". http://screencast.com/t/g67kFj8nRue http://screencast.com/t/g67kFj8nRue It's written in pure Java. Amazingly, I haven't found anything that's achieved better performance thus far. It's very elegant.
  - bengl3rt 15y ago
    That was an incredible read. Thanks for the link.
  - ntoshev 15y ago
    OOP has nothing to do with the Disruptor pattern achieving that performance. I agree the concept is elegant, but I don't think the Java framework implementing it is. You can see a less general benchmark done in far less code in Go and C++: https://gist.github.com/1218360 https://gist.github.com/1218360 (and discussion http://groups.google.com/group/golang-nuts/browse_thread/thread/c47af0b94e5f9539 http://groups.google.com/group/golang-nuts/browse_thread/thr... )
  - silentbicycle 15y ago
    No, the whole point is that they're getting major speed-ups by using arrays and a giant ring buffer to avoid object allocation, reduce garbage collection, and improve cache behavior. They're writing really tightly optimized C. In Java.
  - deleted 15y ago
    [deleted]
- drostie 15y ago
  I will say this: the reason I keep coming back from Lisp (and PHP) to JavaScript and Python is that I can do lots of functional things in the latter, but I get that gosh-darn useful little dot operator. Here are some of the many ways to silence someone who is shouting in all caps: (string-downcase yelling) ; common lisp strtolower($yelling) // php yelling.toLowerCase() // js lc($yelling) # perl yelling.lower() # python I don't really care about the parens and where they are, but the fact that clisp, php, and perl put this function in the global namespace bugs me to no end. It's a function which only makes sense when you have a string. Other things don't have the sort of "case" such that you could "lowercase" them.
  - mattdeboard 15y ago
    Curious then how you feel about `sorted()` being in the global namespace. Point being I don't understand how `.lower()` et al., being class methods instead of global functions is an argument for the greatness of Python. Ultimately the responsibility is yours for invoking it in the right place with the right type of object, no matter where you put the parens.
    - drostie 15y ago
      In Python that actually makes some amount of sense, because Python ships with something like five different sorts of lists (arrays, lists, tuples, OrderedDicts, generators) and it's a reasonably generic idea. And it helps that for the one 'proper' case of this, lists, Python also supports list.sort(), so that "it is where it's supposed to be" as well. The only problem with list.sort() in Python is that it's void; it returns None. It should either return self (and sort self) or return a sorted copy of self, like sorted() will. On the other hand, in JavaScript, array.sort() is known to be a little broken: > [48, 19, 7, 14, 30, 22, 45].sort() [14, 19, 22, 30, 45, 48, 7] Wat. It's true that I have ultimate responsibility for my code, and it's true that in Python I can write: x = 3 x.lower() ...and unlike Java it will not complain that it has no idea how to "lower" 3. But it still suggests like Java suggests that we're going to narrow down the wildly branching tree of possibilities. When I'm sitting in the Python REPL, and I have an object x, I'll often just call dir(x), to see what I can do with it. What would Common Lisp tell me? It would kindly tell me that it's syntactically valid to call (string-downcase 3), even though that will produce a noisy error. So if I wanted to list all of the things I can do with 3, we would be here for a long time.
- bwarp 15y ago
  This actually only happens if you don't think first or don't understand ever. Thinking and understanding takes more time than programming in my experience. The same level of fail will accumulate regardless of the language if you don't know what you are doing.

josephcooney 15y ago

The real world makes code ugly. Network connections that fail part-way through sending. Other people's code that you have to integrate with that block for long periods under certain circumstances. Special cases in business logic that spoil the beautiful abstractions you'd created. Customers with funny characters in their names. Hard drives that fail. 'needs to provide business value' is another one of those pesky real-world requirements that just keeps popping up. Complaining that this gets in the way of beautiful software is akin to transit system operators complaining about passengers interfering with the running of their trains/buses/whatever.

adeelk 15y ago
“Real-world requirements” don’t make code ugly. They just make the problem harder. Hard problems still have elegant solutions.

aufreak3 15y ago

I find code that does more with less to be beautiful and valuable. Note that I'm not including code that does the same with less. As with all things beautiful, this is tough to illustrate, so I'll use an analogy here from Physics. Page "xv" of the book "A course in mathematics for students of physics" (volume 2) by Paul Bamberg and Shlomo Sternberg contains a table (do a "look inside" on Amazon) that shows four forms of Maxwell's equations as they evolved over the course of history. Each change expresses what the previous one did, but contributes something more that wasn't possible or was very difficult to express with the earlier form. The first form explicitly uses cartesian coordinates. The second form is the vector notation, which helps conceptualize and work with the equations in any coordinate system appropriate to the problem (circular, cylindrical, etc.). The third is the relativistic "four-vector" formulation, which, though it says the same thing as the vector form, allows extension to curved spacetime. The fourth exterior calculus formulation (which just reads "dF = 0, and 𝛿F = J"!) covers all of the preceding ones, and also takes exactly the same form when applied to circuits (the kirchoff laws, etc.) which is not something you can say for the preceding forms, while allowing generalization to higher dimensions. The mathematical machinery invented for that simple looking expression is incredibly beautiful (and that book does a great job of its exposition, imo). This kind of beauty in software is very desirable in my opinion and we do have examples like MapReduce to show for it. Yes the machinery to do a distributed MapReduce is complex, but the concept is simple and flexible and has a bit of the "exterior calculus" fragrance to it. Another is continuations in Scheme - which not only can replace any "mundane" control transfer (break, continue, throw, catch, and ilk) but can do much more than just those and lets you roll your own too. I believe that is the kind of beauty we should be striving for in software, not just the "pretty code" kind. (minor edits)