21–30 of 117 posts
Earlier quoted context omitted.
Indeed. The guy in Hawaiian shirt writes simple, fast code with the minimum amount of abstractions, and therefore can afford to finish work early and go to the beach. Everyone else is working overtimes untangling a mess of objects, principles and hierarchies.
Larry Wall is that you!?
I haven't loved debugging systems whose primary data structure is a Map.
I think it very much depends on what problems you're trying to solve and whether or not proper data types have been defined. If your primary data structure is Map > we have a huge problem. On the other hand, if your primary data structure is Map > Then I'd rather see that than IPurchaseMappingByCustomerIdAbstractFactory or whatever other abomination OO priests will conjure. Generally speaking, generic structures are…
He also seems to be unaware that you can have generic code with specific types.
Could anything be more confusing with a large code base? Also, lots of nice key not found and invalid cast exception errors to debug with this approach. Sometimes boxing makes a material difference to performance as well.
"Anything"-oriented programming is dumb. Every big problem is a collection of smaller, different problems. Different problems call for different approaches. Sometimes the best approach has data-oriented features, sometimes object, sometimes functional, sometimes piped. For big problems you want a language good at all of them. It is why C++ continues to grow. Some complain about that, but every single feature got ther…
I'm having a hard time thinking of a way code can ever be fully decoupled from data. When we decide it's better to have a name field rather than firstName and lastName does that mean we simplify NameCalculation.fullName to just return data.name? This seems to suggest we still have coupled code to data (the data structure being an object), it's just now a coupled function, but you have decoupled it enough to use NameC…
> Why would I write a separate schema when the object itself knows what it will accept, what is optional, and what range the values should be in? Because data is just data and the meaning to it is given at the time of application. If you want to couple validation to the data itself - how do you decide which N of the meanings to validate against?
If you want to process the data you must use some language to access parts of the data. Data must have a symbolic representation, not juts be 1s and zeros. Or it can be a bit-stream, but even then you need a language that knows the different between 1 and 0.
person.name
extracts the field 'name' from the data. To manipulate the data, the program must know that there is such a field as 'name' it can ask for.
Earlier quoted context omitted.
I think this is also a reason people try to use JavaScript for so many things. As a multi-paradigm language you can do OOP, functional, etc. in it.
People try to use JavaScript for so many things because it's (surface-level) inexpensive, not because it's good at anything.
I'm having a hard time thinking of a way code can ever be fully decoupled from data. When we decide it's better to have a name field rather than firstName and lastName does that mean we simplify NameCalculation.fullName to just return data.name? This seems to suggest we still have coupled code to data (the data structure being an object), it's just now a coupled function, but you have decoupled it enough to use NameC…
"Anything"-oriented programming is dumb. Every big problem is a collection of smaller, different problems. Different problems call for different approaches. Sometimes the best approach has data-oriented features, sometimes object, sometimes functional, sometimes piped. For big problems you want a language good at all of them. It is why C++ continues to grow. Some complain about that, but every single feature got ther…
I wonder if Alan Kay would agree or argue with this sentiment, but it seems to me that the choice of 'oriented' was intentional and that we've consistently fucked it up ever since then. Orientation should have been 'a preference for' not 'a dogmatic adherence to'. A hot-dog based diet still contains bread, ketchup, mustard and pickles, possibly some sort of cheese. A hot dog diet is just hot dogs, which is much, much…
Preference is silly. The problem dictates its solution. The good programmer listens to the problem.
"Anything"-oriented programming is dumb. Every big problem is a collection of smaller, different problems. Different problems call for different approaches. Sometimes the best approach has data-oriented features, sometimes object, sometimes functional, sometimes piped. For big problems you want a language good at all of them. It is why C++ continues to grow. Some complain about that, but every single feature got ther…
Its a good thing that these paradigm exist so you know their value, and eventually understand when they're appropriate. You're right that there may not be a one-size-fits-all.
I'm having a hard time thinking of a way code can ever be fully decoupled from data. When we decide it's better to have a name field rather than firstName and lastName does that mean we simplify NameCalculation.fullName to just return data.name? This seems to suggest we still have coupled code to data (the data structure being an object), it's just now a coupled function, but you have decoupled it enough to use NameC…
As for why see for example Command Query Separation (the data oriented way) vs Tell Don't Ask (the encapsulate everything way).