351–360 of 396 posts
Earlier quoted context omitted.
I have basically no experience with Java. But in C# I think the above is whats behind stuff like fooobj.events += my_eventhandler;
It is, but those languages did it about 6 years before C# came into existence. Which isn't surprising, given that Delphi took the idea from Eiffel, which share the same Pascal influence, and was designed by Anders.
Earlier quoted context omitted.
One of the many difference is that there is no inheritance, and implementations of traits can be added for types long after they are defined. Traits in rust are not like java interfaces.
How are traits specific to being a functional language rather than an OO language though? I mean, I don't see anything horribly functional-language-specific about your trait example.
Traits are not functional-language specific except in that they are often used in FP to solve problems similar to those one might use inheritance to solve in OOP.
Earlier quoted context omitted.
Upvoted because it's well-articulated, even though I disagree. > Well, in my experience, in every almost every code-base (either from functional, or imperative programing), we end up with modules, witch are a set of function taking the same type as a parameter. This is very close to binding the functions and the types... There is a key distinction: If I have two subsystems that use the same data in different ways, I…
> Upvoted because it's well-articulated, even though I disagree. Appreciate it :) > There is a key distinction: If I have two subsystems that use the same data in different ways, I can keep those concerns separate by putting the functions for each concern into a different module. Binding all the functions to the type mixes the concerns together and creates objects with way too much surface area. This is where composi…
FWIW, I think that this is what distinguishes object-oriented programming as a language paradigm from object-oriented programming as a design paradigm: If you're going to say that all data types should have the operations you can perform on them bound up together into a single class (or class cluster), then that would imply that small, cheap data storage types are expected to be few in number.
If, OTOH, it's more about modularity, and you're not so concerned about how things happen on the sub-module level, then that gives more ideological space for code that's, for example, functional in the small scale and object-oriented in the large scale, like Erlang. Or procedural in the small scale and object-oriented in the large scale, like some C++ code.
Earlier quoted context omitted.
Link at [0]. I'm a little skeptical. That user certainly writes in a similar style to how I've seen Alan Kay write online, but I wouldn't be opposed to seeing some more proof. A one-day-old HN account claiming to belong to one of the most important people in CS from the past 50 years seems a little suspicious haha. [0] https://news.ycombinator.com/item?id=19717640
An interesting and unfortunately true commentary on the lack of civilized behavior using technology that actually required a fair amount of effort -- and civilized behavior -- to invent in the first place.
Also, I walk by your face a few times a week whenever I head into my lab. MEB has redecorated a few times over the years, but they always have a section of pictures of notable alumni and (of course) you're up there. Thanks for giving us a good name in the field and for all you've done!
Earlier quoted context omitted.
> I doubt any language can prevent this kind of 'exposing guts' malpractice Actually, true OOP languages do prevent this. Internal state is completely private and cannot be exposed externally. The only way to interact with an object's state is through its methods — which means the object itself is responsible for knowing how to manipulate its internal state. Languages like Java are not "true" OOP in this sense, becau…
> Internal state should be kept internal. I'm not sure that's a proven model. It's a proposed model, for sure. Since you can't protect memory from runtime access, you can't really protect state, so it's a matter of convention which Python cleverly baked in (_privatevar access).
Earlier quoted context omitted.
> At other times the important thing is to provide a flexible, fluent public interface that can be used in ways you didn't intend. That scares me. How do you maintain and extend software used in ways you didn't intend? Quality assurance should be challenging.
> That scares me. It scares you because you're making some assumptions: 1. You assume that I'm writing software that I expect to use for a long period of time. 2. Even if I plan to use my software for an extended period of time, you're assuming that I want future updates from you. Let me give you an example of my present experience where neither of these things are true. I'm writing some code to create visual effects…
You get into the same issue with eg making your interface be that you return an array, instead of a higher-level sequence abstraction like "something that responds to #each". By keeping a minimal interface that clearly expresses your intent, you can easily hook into modules specialised on providing functionality around that intent, and get power and flexibility right now in a way that doesn't hamstring you later. Other code can use that broad interface with your minimal implementation. Think about what you actually mean by the code you write, and try to be aware when you write code that says more than that.
I think it's interesting that you associate that interface-conscious viewpoint with bondage and discipline languages. I mostly think of it in terms of Lisp and Python and languages like that where interfaces are mostly conceptual and access control is mostly conventional. If anything, I think stricter type systems let you be more lax with exposing implementations. In a highly dynamic language, you don't have that guard rail protecting you from changing implementations falling out of sync with interfaces they used to provide, so writing good interfaces and being aware of what implementation details you're exposing becomes even more crucial to writing maintainable code, even if you don't have clients you care about breaking.
Of course all this stuff goes out the window if you're planning to ditch the codebase in a week.
Earlier quoted context omitted.
> You could also make a class of global functions and use that I'm not sure I understand your issue with doing this. You need to put your global (i.e. public static) functions in classes not because Java is forcing OO practices into everything, but because classes effectively serve as Java's translation units. I think they serve this purpose pretty well in practice.
Classes being Java's only translation units are one of the downsides that I'm mentioning. Really my objection is more that it doesn't allow use of the right tool for the job (which is not always an object).
Earlier quoted context omitted.
I don't think that's what happened. Joe Armstrong was criticizing C++-style OOP when he wrote his critique. After he learned more about Alan Kay's view on OOP, he decided that Erlang is closer to Alan Kay's OOP and he approves that specific flavor of OOP. He didn't change his stance based on popularity. He changed his stance because in the 80s/90s the term "OOP" was synonymous with C++-style-OOP, but that changed in…
He doesn't even mention C++ in his essay [1], but regardless, the C++ OOP is pretty much the mainstream OOP, which we still use today in Java, Kotlin, C#, etc... And... no, the change in mindset about OOP never happened. Kay and Armstrong's view of OOP never took on. Today, OOP is still not seen as message passing and mostly seen as polymorphism, parametric typing, classes/traits/interfaces, and encapsulation. The co…
It may be better to define specific flavors or aspects of OOP or OOP-ish things and discuss them in isolation with specific scenarios. That way the messy issue of canonical definition(s) doesn't come into play as often.
It would then be more of "hey, here's a cool feature of Language X or System X! Look what it can do...". Whether it's canonical or not is then moot.
Earlier quoted context omitted.
You're always using a getter. It's just a question of what syntax your language provides for different ways of getting values, and how much they say about your implementation. Most people don't have a problem with getters and setters, they have a problem with writing pure boilerplate by hand. Languages like Python and Lisp save you from the boilerplate and don't provide a nicer syntax for the implementation-exposing…
You misunderstood my post. I said I haven’t seen a useful getter abstraction. Not all data access is via a method nor is it always abstract. I specifically object to the useless abstraction, not the boilerplate (boilerplate is cheap).
I don't view it as a useless abstraction, because I view it as the natural way of things. I view specifying that your get/set implementation is and always will be implemented as slot access to be uselessly sharing implementation details that does nothing but freeze your current implementation strategy.
I think a better question is when that abstraction gets in your way. When does it bother you that nullary functions aren't reading memory locations? Why do you feel that's an essential thing to specify in your public interface, as a default? There's nothing stopping you from writing code in Python and mentally modelling o.x as slot access, because it follows the interface you want from it.
If you only care because it's something extra you have to do, then that's what I meant by boilerplate. I think it's a misfeature of Java's that it presents a model where that's something extra you have to do.
Earlier quoted context omitted.
In what way is Scala not pragmatic?
It's a language that's aimed more at research, producing papers for conferences, and financing the EPFL and its PhD students than at users in the real world. There's absolutely nothing wrong with that, by the way, I love studying all the advanced concepts that Scala has pioneered over the years. But it's also the reason why it's largely in decline and why Kotlin has taken the industrial world by storm: because it is…
Kotlin doesn't have typeclasses (something you get as a side effect of Scala implicits), ADTs, or true pattern matching (along with exhaustivity checks). In combination, all of those allow for expressive, easy-to-read code that, in my experience, tends to have few bugs. Kotlin is a step backwards from that. It's still a significant step up from Java, however.
F# is the only other language I've used that I've found comes close. However it lacks typeclasses, and the large Java ecosystem.