Good Ideas, Through the Looking Glass (PDF) "Enough has been said and written about this non-feature [goto] to convince almost everyone that it is a primary example of a bad idea. The designer of Pascal retained the goto statement (as well as the if statement without closing end symbol). Apparently he lacked the courage to break with convention and made wrong concessions to traditionalists. But that was in 1968. By now, almost everybody has understood the problem, but apparently not the designers of the latest commercial programming languages, such as C#."
"To postulate a state-less model of computation on top of a machinery whose most eminent characteristic is state, seems to be an odd idea, to say the least. The gap between model and machinery is wide, and therefore costly to bridge. No hardware support feature can wash this fact aside: It remains a bad idea for practice. This has in due time also been recognized by the protagonists of functional languages. They have introduced state (and variables) in various tricky ways. The purely functional character has thereby been compromised and sacrificed. The old terminology has become deceiving."
"...this writer believes that a more effective way to let a system make good use of parallelism is provided by object-orientation, each object representing its own behaviour in the form of a “private” process."
And on Object Oriented Programming: "Objects are records, classes are types, methods are procedures, and sending a method is equivalent to calling a procedure...Was this change of terminology expressing an essential paradigm shift, or was it a vehicle for gaining attention, a “sales trick”? "
1 comment:
OO is not a trick for one and only one simple reason:
Large dev teams need encapsulation.
Without encapsulation more upfront planning is needed to prevent conflicts. This hurts innovation by limiting the amount of RAD work that can be done.
Separating "classes" (if you decided to attempt OO in C) basically involves writing each class in it's own file. This helps to decrease maintainance however OO in non-OO languages, in *large* teams is not effective at preventing bugs such as variables or functions using the same name.
Using OO in non-OO results in a lot of external tooling and development processes that are aimed at the environment instead of the language itself (i.e. using a database that maintains a list of function names and plugs into the IDE.)
Post a Comment