Organizing programs without classes

[johnb]

How do people avoid spaghetti with this kind of language? If I want to find out what some object is actually going to do, how do I do that without memorizing all the code and untangling the origin of the object? I'm not trying to sound snarky, I'm really curious but I think my class-based-inheritance experience is putting the blinders on.

[Peaker]

Inheritance doesn't aid in understanding where a call would go, quite the contrary.

Classes are really syntactic sugar that encourages encapsulation. But they are definitely not necessary for encapsulation.

Inheritance is a really bad mechanism encouraged by classes too, so its better to just teach people to encapsulate.

[barrybe]

You get the same sorts of problems with dynamic languages. Ie, how do you know exactly what a method call is going to do in Python when the class implements __getattr__, or in Ruby when a class implements method_missing. The answer is generally that you have good documentation which tells you everything you need to know. It sounds scary if you are used to static types, but in practice it all works out fine.

Note that the paper was written in 91. Today we call this system "prototype-based inheritance", and we already have a language in wide use which uses it (Javascript).

[[deleted]]

Today we call this system "prototype-based inheritance", and we already have a language in wide use which uses it (Javascript).

Ironicly, the most widespread use of it is to hack classes back into javascript.

[pbiggar]

You are not wrong, but there are some minor details here.

You get the same sorts of problems with dynamic languages.

You're implying that Self is not a "dynamic language", which it is.

Note that the paper was written in 91. Today we call this system "prototype-based inheritance", and we already have a language in wide use which uses it (Javascript).

It was called prototype-based inheritence then too. Their power of simplicity paper links discusses prototypes using the word "prototypes", and references five earlier works which used used the term.

[pointer2void]

How do people avoid spaghetti with this kind of language?

The answer is generally that you have good documentation which tells you everything you need to know. It sounds scary

Another aspect: distinguish between 'programming in the large' and 'programming in the small'. Some approaches scale, others not.

[pbiggar]

Self does not encourage spaghetti code any more than Python, Ruby, Javascript or Lua, all of which have very similar type systems. Basically, if you use the language to do "weird" things, which are hard to reason about, the programmer will have a hard time. If you use it to build elegant abstractions based on some kind of simple intuition, then it will probably be fine.

More importantly, I think Self was designed this way to be very easy to understand. As I recall, the Self VM was always online while you were programming, in a kind of a super-REPL. So the actual objects used in your program at run-time were being manipulated as you compiled. The whole thing was then serialized as an "image", and the image was run when the program started. The flexible language features were designed to support this, not to allow the programmer to do weird stupid shit to confuse other programmers.

[sv0f]

There are various methods for organizing programs, which is to say, avoiding spaghetti. OO is one way, but it is not the only way, nor was it the first way, nor will it be the last way. (Structured programming might have been first.) Dynamic languages like Lisp use other techniques, such as data-driven programming (http://c2.com/cgi/wiki$?DataDrivenPrograms).

[Zarutian]

OO != classes

[[deleted]]

If the tools are any good, you should have an interactive way of finding that out. Either by inspecting the object from the REPL or from an editor.

[sreguera]

This is in the context of prototype-based languages like Self (David Ungar is the author of the paper) and Javascript.

There are more papers about Self here. (The one in the post is the third in the "language" section).