New blog post: "Fifty Shades of OOP." Put in a surprising amount of research for this one!
New blog post: "Fifty Shades of OOP." Put in a surprising amount of research for this one!
@nanjizal Haxe looks really cool! Though I am not familiar with it.
For languages to learn, I am not sure what kind of suggestions I can give you since there are so many options. From an intellectual curiosity perspective, probably learn something drastically different from what you know? Though if you want to focus on creating art/graphics/music, then maybe JS/TS is a good fit (if you don't already know them) because of how easy to set up and to generate graphics and sounds
@lesley @aartaka One thought I've had for a while is that programming languages and the rhetoric around it focus too much on tangible things like member variables and methods.
David Parnas was the first to point out [1] that each piece of a system -- whether you call it a function or method or object or class -- should exist to "protect" a single coherent invariant. That's the thing we need to ensure we preserve in the course of extension, not any particular member or method.
[1] David Parnas, "On the Criteria To Be Used in Decomposing Systems into Modules," 1972
@lesley Hmm, I think this is more about pragmatics. I want the syntax of a programming language to guide you to think more clearly about the problem. Should a member variable be public or private? It's irrelevant. What matters is whether an invariant is violated at some point in a program. Languages should better emphasize invariants.
Hmm, I wonder what Eiffel did? No, https://en.wikipedia.org/wiki/Eiffel_(programming_language)#Scoping also seems weird. So I'm suggesting some speculative new research direction.
@akkartik Ahh. I misunderstood what you said.
D also supports an `invariant` keyword. I wonder whether this has a performance implication (do they assert the invariant all the time?) It is kind of interesting, but I don't see many languages following Eiffel's footsteps.