4 ms·

That's another thing I can resonate with. I love programming but programming at work can be another kettle of fish. Dealing with other peoples code can be very

That's another thing I can resonate with. I love programming but programming at work can be another kettle of fish. Dealing with other peoples code can be very frustrating. I have fringe opinions on software and programming (that may well be wrong ;)) and it can be frustrating when what you think is so obviously the best way of doing something just seems weird and obfuscated to others.

sqeaky 10y ago
What are some of your opinions, perhaps the most contentious one's?
- lacampbell 10y ago
  That objects are a better abstraction than modules+records, that class hierarchies are better than abstract data types, that multiple dispatch is better than pattern matching, and that a lambda can easily be modelled as an object with one useful method called "apply" without anything being lost. The current FP trend has had a lot of benefits, namely in teaching people about immutability (I write immutable objects 95% of the time). But I am convinced that procedures and data belong together, and that it's an easier way to organise code.
  - sqeaky 10y ago
    Those don't really seem that far off from common OO wisdom which still seems prevalent in the industry, except for the lambda thing. Mostly that seems like you are thinking for yourself and have real reasons for what you think, and it happens to be closer to most OO folks, than most FP folks. On the Lambda thing, you are right that it makes no functional difference. I do think it makes a small readability and maintainability difference. Most languages I use don't allow, or at least it is poor practice, to make classes in line. With C++ passing a lambda to and std function is much nicer and easier to read than creating a functor (a separate class with operator() instead of apply() as you described), because it lets you keep the code being passed in the function that cares.
    - lacampbell 10y ago
      Just to be clear I'm not advocating everyone write their own anonymous function-object every time they want to map over something, just that "x -> x * x" can be short hand for such a function-object with nothing lost. Industry OO doesn't seem much like OO at all. C# constantly adding new and innovative syntax to make getters and setters as simply as possible (much simpler than writing an immutable class with a proper constructor) suggests to me my views are a bit fringe as well.
  - infradig 10y ago
    At age 59 I have come to the opposite view. I assume you are referring in passing to Erlang & Haskell. They are probably OK, never actually used either. I Prefer the real deal, which to me is Prolog. But that's just me.
    - lacampbell 10y ago
      I was very into "ML-style" up until recently. Even had a short contract using F#. I'll happily code in that style if need be - there actually isn't a static OO language that does what I want but I know it could exist. Is prolog considered functional? I should revisit it at some point.

sqeaky 10y ago

What are some of your opinions, perhaps the most contentious one's?

lacampbell 10y ago
That objects are a better abstraction than modules+records, that class hierarchies are better than abstract data types, that multiple dispatch is better than pattern matching, and that a lambda can easily be modelled as an object with one useful method called "apply" without anything being lost. The current FP trend has had a lot of benefits, namely in teaching people about immutability (I write immutable objects 95% of the time). But I am convinced that procedures and data belong together, and that it's an easier way to organise code.
- sqeaky 10y ago
  Those don't really seem that far off from common OO wisdom which still seems prevalent in the industry, except for the lambda thing. Mostly that seems like you are thinking for yourself and have real reasons for what you think, and it happens to be closer to most OO folks, than most FP folks. On the Lambda thing, you are right that it makes no functional difference. I do think it makes a small readability and maintainability difference. Most languages I use don't allow, or at least it is poor practice, to make classes in line. With C++ passing a lambda to and std function is much nicer and easier to read than creating a functor (a separate class with operator() instead of apply() as you described), because it lets you keep the code being passed in the function that cares.
  - lacampbell 10y ago
    Just to be clear I'm not advocating everyone write their own anonymous function-object every time they want to map over something, just that "x -> x * x" can be short hand for such a function-object with nothing lost. Industry OO doesn't seem much like OO at all. C# constantly adding new and innovative syntax to make getters and setters as simply as possible (much simpler than writing an immutable class with a proper constructor) suggests to me my views are a bit fringe as well.
- infradig 10y ago
  At age 59 I have come to the opposite view. I assume you are referring in passing to Erlang & Haskell. They are probably OK, never actually used either. I Prefer the real deal, which to me is Prolog. But that's just me.
  - lacampbell 10y ago
    I was very into "ML-style" up until recently. Even had a short contract using F#. I'll happily code in that style if need be - there actually isn't a static OO language that does what I want but I know it could exist. Is prolog considered functional? I should revisit it at some point.