Learning From History

[nqafield]

This initial comment is too long and has been edited too much. Apologies! I need to decide what to do about that.

Might there be some benefit in collecting together some resources relating to language development so that we can learn from history, so to speak. Maybe other people's war stories will be useful to us.

Obviously we will not all agree that these stories, or the opinions of the people telling them, are "right" or 100% relevant to what is being aimed at here. But maybe there could be some benefits:

• We can learn from the "good" bits.
• We can learn from others' mistakes.
• We can use the things that we don't agree with as fodder for deeper thought, for clarifying shared understanding, or for provoking discussions.

I'll start with the following two videos as suggestions:

• We're Doing It All Wrong - Paul Phillips
  • There is some good stuff here...
  • "I think that people that use a langauge end up unconsciously modelling the people that make it. So if you have issues at one level they're going to make themselves felt at the next level as well."
  • "The Scala compiler is so rediculously difficult to modify... The most trivial modification is a tremendous undertaking."
  • "Modification is undesirable, but modifiability is paramount."
  • Being able to do everything in a language makes doing anything at all more difficult. (Restrictions matter!)
  • "I don't need a programming language. I need a coherent set of tools for creating software. A language is incidental." (I think this is very much on point.)
  • (Just don't tell Yegor that this guy disses XML!) ;)
• Growing a Language - Guy Steele

(If anyone else has suggestions for videos or resources I'd certainly be interested to hear about them, and will add them here...)

• Object-based vs. Class-based Languages - Luca Cardelli (slides)
• Nothing is Something - Sandi Metz (video)
  • What if there were no if statements?
  • Be condition averse, message centric, abstraction seeking.
  • Nice example of how inheritance of implementation goes horribly wrong.

[yegor256]

@pa9ey perfect idea. how about we create a section in README.md called "Lessons Learned" and list there things that we're aware about. We can say there, as a preface, that "We know about all this, we've seen these videos, don't think that we're re-inventing the wheel..." And then the list of things we've seen will go. What do you think?

[nqafield]

Ha! Maybe I've bitten off more than I can chew. :) I guess I was thinking of people, first, adding suggestions for a list of resources. (Then maybe I watch them all and try and catch up with you guys!!) (^;

But okay, I'll try and write something in the comments here about what I got from those videos and then see what people think.

(As I mention above, the edits are starting to get out of hand...)

[nqafield]

If anyone else has suggestions for videos or resources I'd certainly be interested to see them.

(This also seems very relevant to what we're trying to do, but I can't pretend I understand it all yet.)

[pchmielowski]

Nothing is Something - Sandi Metz

First few minutes is about what is the alternative to if statements in OOP world (or: how to implement Smalltalk style Boolean objects in Ruby).

[nqafield]

@pchmielowski Thanks for that! I've seen a couple of her videos (including that one I think) and I remember being impressed.

[mdbs99]

Nothing is Something - Sandi Metz

Very good this video!

[OneWingedShark]

@pa9ey -- These are extremely good points:

• Being able to do everything in a language makes doing anything at all more difficult. (Restrictions matter!)
• "I don't need a programming language. I need a coherent set of tools for creating software. A language is incidental." (I think this is very much on point.)

With respect to the latter, there was a very interesting project/technology tied to a compiler compiler project called PQCC: IDL (Interface Description Language, here's the specification) -- had PQCC realized its goals a huge chunk of those tools would be available. (I suspect PQCC's failure was more technical limitations of the time than the problem being unsolvable.)

I found out about IDL when researching Ada for a compiler project and stumbled on DIANA (here's DIANA RM revision 3, and revision 4 draft, if you're interested), which is an application of IDL. -- Anyway the reason to bring up IDL is that along with being germane to this wish to have tools rather than languages it has an interesting and unique (to my knowledge) concept of inheritance: a method to exclude items from being inherited.

The syntax/method they used was a keyword named without -- see IDL spec PDF's page 24 (marked as page 18) -- where you can exclude a portion of the inherited structure.

This is eminently relevant for language-design because the standard definition for a type is "a set of values and a set of operations", this can be modeled directly in an OOP-language by an object having two fields: a set of values, and two a set of operations... and any language with subtypes, which are merely the addition of constraints upon the values, like Positive is a subtype of Integer with constraint X > 0 imposed upon the values.

So using Integer and Positive again, we could conceptually describe the types as something like:

Integer = (values: -2**(machine.word_length-1)..2**(machine.word_length-1)-1, operations: Arithmetic_ops)
and
Positive = Integer without values x such that x < 0
Or whatever. (The textual representation and syntax here don't matter, it's the concept that's important; though there is the implicit assumption here that we're dealing with a 2's complement machine here.)

---

Now, with respect to the former point ("Restrictions matter!"), this is self-evident to anyone who's used subtypes, but it's also the key realization for Ada's generic system which has the interesting property of static polymorphism.

(I'll move what I was going to say about Ada's generics to #1 where it's more directly on-topic.)

The power of being able to add constraints (that is, subtyping) can simplify things immensely, as well as enhance correctness; an example:

  Type Window is tagged private;       -- Whatever, it's just a stub.
  Type Pointer is access Window'Class; -- A pointer to Window, or anything deriving from it.
  Subtype Handle is not null Pointer;  -- A pointer with NULL excluded.

  Procedure Set_Title ( Window : Handle; Text : String ); -- Function header/declaration.

Within the body of Set_Title, the checking of parameter "Window" being null is completely unneeded because it's ensured non-null by the parameter, because the restriction is on/in the definition of Handle.

---

Things like the "if operator" being an object reminds me of "parselets" from Nystrom's "Pratt Parsers: Expression Parsing Made Easy" article and his example on github and how these "parslets" essentially construct the objects for the parse-tree.

The idea of having an "if operator"-object also beings to mind Forth which owes a lot of its flexibility and simplicity to it's definition of "word" --the Forth equivalent of a subprogram-- which is: either a list of words, or a chunk of machine code. (This definition also forms the basis for other interesting properties.)

On the other hand of the high-/low-level language scale we have Lisp, which similarly deals with lists at the fundamental level, but owes its flexibility to its homoiconicity: the representation of the program itself as data. (Lisp's macros are quite impressive when it comes to meta-programming, as shown by this stackoverflow answer, and the heart of the macro is homoiconicity: "_Before I go further: I should explain a little bit of what a macro is. It is a transform of code by code to code. That is a piece of code read by the interpreter (or compiler) which takes in code as an argument does a manipulation and the returns the result which is then run in place. _")

All of these tie together: we can have a system where everything is represented by objects, where we have objects [well, methods] to operate on objects and treat programs like objects.

[nqafield]

@OneWingedShark Thanks! This is all fascinating stuff. Although I'm running to catch up a bit. I think I have a lot of reading to do! :)

[nqafield]

Still not really sure what the outcome of this issue should be (I'm quickly getting out of my depth), but I think I'll keep it open for now because there are some interesting things here.

[OneWingedShark]

@pa9ey
The links for PQCC, IDL, and DIANA are just to their wikipedia pages, and the stackoverflow link isn't terribly bad either.

The Pratt Parsers post takes more time to mull over (and possibly play with) than it does to read.

It's the IDL spec and DIANA RM that are of any appreciable length, and you can safely ignore DIANA's 4th revision draft.

[maxinovi]

I would propose my object-oriented modeling project. The key ideas of the project are the following:

• Object-modeling core. Totally declarative decomposition: collaborating objects, template messages, and nothing else. Only high abstractions and pure problem domain terms. Adjusted object-oriented concepts.
• Escalating the role of aspects. Cross-cutting concerns via alternative naming and projections.
• Explicit data model. Associations as an abstract way to define data relations.
• Unification and explicit applying of resources. Separation of object modeling and resource programming. Resources are memory and code (algorithms). All resources are assigned to model abstractions via productions. Separation resources to managed and unmanaged is incidental.
• Meta features for manipulating modeling and code elements. Generating output code from transformed models. Open object modeling semantic via transformations.
• Powerful tools via IDE. Alternative source code presentation via hybrid trees instead of plain text. Plain text is incident. Real-time weaving and meta processing. Transpilation into readable and debuggable output code.

Maybe it can be used in eolang in some manners.

[0crat]

Job gh:yegor256/eo#5 is not assigned, can't get performer

[0crat]

This job is not in scope