101–110 of 312 posts
Also, I didn't even read TFA. However, I think it's only fair since it's a medium post that requires login.
The author is right about ORMs. They are ridiculously over engineered solutions. (My experience is largely with Django and SQLAlchemy ORMs) As soon as you want to do something that's not already perfectly built in, everything becomes a mess of impenetrable hacks. Autogenerated Django migrations are unstable and often need to be edited to to be correct or make any damn sense. It also encourages to people to blur or ju…
Use the ORM for perfectly built in things, but also use raw SQL when it's not.
Earlier quoted context omitted.
I'm not sure "code is data" necessarily means "homoiconicity", but it could mean "first-class functions" (or at least that's what I think of when I hear the phrase; maybe I'm wrong); however, I'm not familiar with anyone who argues that these are fundamental OOP features (perhaps Smalltalk had first class functions, but for a very long time the most popular flavors of OOP did not).
yes, Homoiconicity is about having the same syntax for both structure and data. First class functions means there is no conversion, again at syntax level, between a function and a value. Mainstream languages all have a way to see code as data, it's function pointer in C, delegate and lambda in C# and first class functions in Python or JavaScript.
This doesn't speak to what I consider some of the most dangerous parts of OOP, which include the assumptions that tightly binding data and code is helpful, and that statefulness is fine to freely sprinkle throughout your program.
Objects are essentially structs with namespaces and methods with implicit this params. If you can't have state then you throw structs out too. If you're going this far, you're essentially throwing away typing as well. Are you actually just opposed to private fields?
This doesn't speak to what I consider some of the most dangerous parts of OOP, which include the assumptions that tightly binding data and code is helpful, and that statefulness is fine to freely sprinkle throughout your program.
Earlier quoted context omitted.
Objects are essentially structs with namespaces and methods with implicit this params. If you can't have state then you throw structs out too. If you're going this far, you're essentially throwing away typing as well. Are you actually just opposed to private fields?
I think the key differentiater is that OOP (in some versions) wants to hide the data and not just implementation details. For example, a hash map data structure hides the details of how the hash map is implemented, but it doesn't hide the data. In some versions of OO, the object should not only hide the implementation details but also the data. Any function that needs that data MUST be a method of that object. That's…
This doesn't speak to what I consider some of the most dangerous parts of OOP, which include the assumptions that tightly binding data and code is helpful, and that statefulness is fine to freely sprinkle throughout your program.
Also, as an aside, I wouldn't call DRY a 'rock solid foundation' of programming. People do some weird contortions to make code DRY that end up causing my harm then good. Separations of Concerns is far more important. DRY is fine when applied within the scope of a feature, but not cross features. Otherwise you end up playing wack-a-mole when you fix a bug in one place only to make a new one somewhere else.
Earlier quoted context omitted.
I think the key differentiater is that OOP (in some versions) wants to hide the data and not just implementation details. For example, a hash map data structure hides the details of how the hash map is implemented, but it doesn't hide the data. In some versions of OO, the object should not only hide the implementation details but also the data. Any function that needs that data MUST be a method of that object. That's…
Hash maps hide lots of internal state though. I think the difference is hash maps have a clear, battle tested API and its obvious what should be promised by the interface and what should be internal implementation. Devs aren't clairvoyant so when we're making a new type we might sometimes get this wrong. But this is a fundamental issue with type systems in general and not OOP, is it not?
There arent many hash map methods that will actually modify the data.
Standard OOP, on the other hand, seems to encourage such behavior. So, for example, a Company object could contain a bunch of Department objects, each of which contained a bunch of Employee objects.
These people objects could also be referenced in areas outside of the company object.
If I called a company.giveFinanceDepartmentARaiseInDollars(10000) function on the Company object, it would have an unpredictable impact on the Department/Employee objects. It may also have cascading effects in other parts of the application that may not be clear.
On the other hand, if you represented this as a company hashmap, with the keys the department structs, you would have to do something like the following instead:
company["finance"].employees.forEach(x => x.salary = x.salary + 10000); company["finance"].base_salary = company["finance"].base_salary 10000
This contrived example shows some of the pros/cons. OOP allows us to hide a lot of behavior/changes, which may mean less repetitive code. OTOH, it hides a lot of behavior/changes.
Including key use cases such as being able to use the provided components "out of the box" and also being able to customize them, i.e. "like this component, but with these differences".
[1] https://docs.oracle.com/javase/8/javafx/api/javafx/scene/con...
[2] https://developer.apple.com/documentation/appkit/nsbutton
[3] https://ci.apache.org/projects/wicket/apidocs/org/apache/wic...