Possreps, Objects, Mutability, Immutability, and Developing Non-database Applications.
Quote from dandl on June 25, 2019, 5:07 pmI'm less sure [closures with mutable variables] provide a usable substitute for the encapsulation (information hiding) inherent in OO. Maybe it's just a matter of coming up with some syntactic sugar, maybe it's more.
In the Lisps (which includes Python for this purpose), we get to add our own syntactic sugar, of course. Other languages have "user friendly" syntax, which I would describe as "advanced user hostile" syntax. In Java and Ada, non-extensibility was actually a design goal.
Try adding a completely new construct to your favorite compiler (that you didn't write) that can be defined in terms of existing constructs, even if you have the source of the compiler. (It's true, we are called "smug Lisp weenies" for a reason.)
I'm reasonably sure that TTM's compound scalars plus destructive assignment can do what OO does. Having operators that are not bundled (OO VSS 2) implies having multiple dispatch, which OO typically does not.
I think that's a historical accident. Smalltalk didn't allow it, and so neither do most others, except perhaps statically. Languages with just static overloading (which includes TTM) typically make compile-time decisions based on the declared types of all arguments.
But in TTM everything is public, and that's not good, especially for larger systems. It may be that a relatively simple feature to control visibility is all that is needed, but I can't tell. The only one that comes to mind is the import/export of JS ES6.
I think that the ES6 design is the simplest thing that could possibly work. I would leave out default exports, though, which make module names part of the language (other than in import statements). There are arguments for and against (a) one big export list at the top of the file vs. (b) labeling each private (in the TTM sense of "non-database") relvar and function with a keyword like exported to make it visible to modules that import this module.
Quote from dandl on June 25, 2019, 5:07 pmBut in TTM everything is public, and that's not good, especially for larger systems.
If you expose something to one external user (no matter how "close" or how "far" he is from you), you have a certain level of obligation to keep supporting it. Neither the size of the audience you exposed your something to nor the size of the systems that get built using that exposed something matter one tiny bit.
Method visibility is an artefact of code-centric thinking (and of programmers who mis-believe that they continue "owning" the code even after it got shipped). TTM is not code-centric.
Quote from Erwin on June 25, 2019, 7:56 pm
If you expose something to one external user (no matter how "close" or how "far" he is from you), you have a certain level of obligation to keep supporting it.
When bosses expose themselves to their employees, however, it's usually considered insupportable.
Neither the size of the audience you exposed your something to nor the size of the systems that get built using that exposed something matter one tiny bit.
Compilation is generally a very strong form of information hiding, which is one reason why people ship compiled code.
Quote from Erwin on June 25, 2019, 7:56 pmQuote from dandl on June 25, 2019, 5:07 pmBut in TTM everything is public, and that's not good, especially for larger systems.
If you expose something to one external user (no matter how "close" or how "far" he is from you), you have a certain level of obligation to keep supporting it. Neither the size of the audience you exposed your something to nor the size of the systems that get built using that exposed something matter one tiny bit.
Method visibility is an artefact of code-centric thinking (and of programmers who mis-believe that they continue "owning" the code even after it got shipped). TTM is not code-centric.
Indeed.
And lest it be forgotten, TTM isn't a language specification, it's a series of requirements that can inform creating a language specification. The languages you define based on TTM may (or may not) have all manner of mechanisms for hiding state or controlling access or anything else, but all are outside the scope of TTM.
Quote from johnwcowan on June 25, 2019, 5:56 pm
Try adding a completely new construct to your favorite compiler (that you didn't write) that can be defined in terms of existing constructs, even if you have the source of the compiler. (It's true, we are called "smug Lisp weenies" for a reason.)
Forth of course. And you can do a fair job in C, even better if the macro system is better. That includes a compiler I did write.
But adding new constructs is not something you often want to do. I looked into strongly typed languages to see if any could have TTM relational types added, and so far I haven't found one. Language extension capability tends to kick in after type definition.
I think that's a historical accident. Smalltalk didn't allow it, and so neither do most others, except perhaps statically. Languages with just static overloading (which includes TTM) typically make compile-time decisions based on the declared types of all arguments.
It's no accident. Typical OO does the equivalent of Smalltalk sending a message to a receiver, which sends unknown requests to its parent. I know, I've written one of those too and it's relatively easy. Multiple dispatch means a lot more work at compile time.
I think that the ES6 design is the simplest thing that could possibly work. I would leave out efault exports, though, which make module names part of the language (other than in import statements). There are arguments for and against (a) one big export list at the top of the file vs. (b) labeling each private (in the TTM sense of "non-database") relvar and function with a keyword like
exportedto make it visible to modules that import this module.
Seems reasonable.
Quote from Erwin on June 25, 2019, 7:56 pmQuote from dandl on June 25, 2019, 5:07 pmBut in TTM everything is public, and that's not good, especially for larger systems.
If you expose something to one external user (no matter how "close" or how "far" he is from you), you have a certain level of obligation to keep supporting it. Neither the size of the audience you exposed your something to nor the size of the systems that get built using that exposed something matter one tiny bit.
That's called a dependency, and I learned early how badly they can bite you. If you spend any time working with NodeJS you'll soon find that breaking changes are an art form.
Method visibility is an artefact of code-centric thinking (and of programmers who mis-believe that they continue "owning" the code even after it got shipped). TTM is not code-centric.
So what's your point?