“you make prototype objects, and then … make new instances. Objects are mutable in JavaScript, so we can augment the new instances, giving them new fields and methods. These can then act as prototypes for even newer objects. We don't need classes to make lots of similar objects… Objects inherit from objects. What could be more object oriented than that?”
— Prototypal inheritance in JavaScript, Douglas Crockford (#JavaScript)
— Prototypal inheritance in JavaScript, Douglas Crockford (#JavaScript)
Object-oriented programming in Lua
Although Lua does not have a built-in concept of classes, object-oriented programming can be achieved using two language features: first-class functions and tables. By placing functions and related data into a table, an object is formed. Inheritance (both single and multiple) can be implemented using the metatable mechanism, telling the object to look up nonexistent methods and fields in parent object(s).
There is no such concept as "class" with these techniques; rather, prototypes are used, similar to Self or #JavaScript. New objects are created either with a factory method (that constructs new objects from scratch) or by cloning an existing object.
Lua provides some syntactic sugar to facilitate object orientation. To declare member functions inside a prototype table, one can use function
#Lua
Although Lua does not have a built-in concept of classes, object-oriented programming can be achieved using two language features: first-class functions and tables. By placing functions and related data into a table, an object is formed. Inheritance (both single and multiple) can be implemented using the metatable mechanism, telling the object to look up nonexistent methods and fields in parent object(s).
There is no such concept as "class" with these techniques; rather, prototypes are used, similar to Self or #JavaScript. New objects are created either with a factory method (that constructs new objects from scratch) or by cloning an existing object.
Lua provides some syntactic sugar to facilitate object orientation. To declare member functions inside a prototype table, one can use function
table:func(args), which is equivalent to function table.func(self, args). Calling class methods also makes use of the colon: object:func(args) is equivalent to object.func(object, args). #Lua
Prototype-based programming in Self
Traditional class-based OO languages are based on a deep-rooted duality:
• Classes — define the basic qualities and behaviours of objects.
• Object instances — are particular manifestations of a class.
For example, suppose objects of the Vehicle class have a name and the ability to perform various actions, such as drive to work and deliver construction materials. Bob's car is a particular object (instance) of the class Vehicle, with the name "Bob's car". In theory one can then send a message to Bob's car, telling it to deliver construction materials.
This example shows one of the problems with this approach: Bob's car, which happens to be a sports car, is not able to carry and deliver construction materials (in any meaningful sense), but this is a capability that Vehicles are modelled to have. A more useful model arises from the use of subclassing to create specializations of Vehicle; for example Sports Car and Flatbed Truck. Only objects of the class Flatbed Truck need provide a mechanism to deliver construction materials; sports cars, which are ill-suited to that sort of work, need only drive fast. However, this deeper model requires more insight during design, insight that may only come to light as problems arise.
This issue is one of the motivating factors behind prototypes. Unless one can predict with certainty what qualities a set of objects and classes will have in the distant future, one cannot design a class hierarchy properly. All too often the program would eventually need added behaviours, and sections of the system would need to be re-designed (or refactored) to break out the objects in a different way.[citation needed] Experience with early OO languages like Smalltalk showed that this sort of issue came up again and again. Systems would tend to grow to a point and then become very rigid, as the basic classes deep below the programmer's code grew to be simply "wrong". Without some way to easily change the original class, serious problems could arise.
Dynamic languages such as Smalltalk allowed for this sort of change via well-known methods in the classes; by changing the class, the objects based on it would change their behaviour. However, such changes had to be done very carefully, as other objects based on the same class might be expecting this "wrong" behavior: "wrong" is often dependent on the context. (This is one form of the fragile base class problem.) Further, in languages like C++, where subclasses can be compiled separately from superclasses, a change to a superclass can actually break precompiled subclass methods. (This is another form of the fragile base class problem, and also one form of the fragile binary interface problem.)
In Self, and other prototype-based languages, the duality between classes and object instances is eliminated.
Instead of having an "instance" of an object that is based on some "class", in Self one makes a copy of an existing object, and changes it. So Bob's car would be created by making a copy of an existing "Vehicle" object, and then adding the drive fast method, modelling the fact that it happens to be a Porsche 911. Basic objects that are used primarily to make copies are known as prototypes. This technique is claimed to greatly simplify dynamism. If an existing object (or set of objects) proves to be an inadequate model, a programmer may simply create a modified object with the correct behavior, and use that instead. Code which uses the existing objects is not changed.
#Self
Traditional class-based OO languages are based on a deep-rooted duality:
• Classes — define the basic qualities and behaviours of objects.
• Object instances — are particular manifestations of a class.
For example, suppose objects of the Vehicle class have a name and the ability to perform various actions, such as drive to work and deliver construction materials. Bob's car is a particular object (instance) of the class Vehicle, with the name "Bob's car". In theory one can then send a message to Bob's car, telling it to deliver construction materials.
This example shows one of the problems with this approach: Bob's car, which happens to be a sports car, is not able to carry and deliver construction materials (in any meaningful sense), but this is a capability that Vehicles are modelled to have. A more useful model arises from the use of subclassing to create specializations of Vehicle; for example Sports Car and Flatbed Truck. Only objects of the class Flatbed Truck need provide a mechanism to deliver construction materials; sports cars, which are ill-suited to that sort of work, need only drive fast. However, this deeper model requires more insight during design, insight that may only come to light as problems arise.
This issue is one of the motivating factors behind prototypes. Unless one can predict with certainty what qualities a set of objects and classes will have in the distant future, one cannot design a class hierarchy properly. All too often the program would eventually need added behaviours, and sections of the system would need to be re-designed (or refactored) to break out the objects in a different way.[citation needed] Experience with early OO languages like Smalltalk showed that this sort of issue came up again and again. Systems would tend to grow to a point and then become very rigid, as the basic classes deep below the programmer's code grew to be simply "wrong". Without some way to easily change the original class, serious problems could arise.
Dynamic languages such as Smalltalk allowed for this sort of change via well-known methods in the classes; by changing the class, the objects based on it would change their behaviour. However, such changes had to be done very carefully, as other objects based on the same class might be expecting this "wrong" behavior: "wrong" is often dependent on the context. (This is one form of the fragile base class problem.) Further, in languages like C++, where subclasses can be compiled separately from superclasses, a change to a superclass can actually break precompiled subclass methods. (This is another form of the fragile base class problem, and also one form of the fragile binary interface problem.)
In Self, and other prototype-based languages, the duality between classes and object instances is eliminated.
Instead of having an "instance" of an object that is based on some "class", in Self one makes a copy of an existing object, and changes it. So Bob's car would be created by making a copy of an existing "Vehicle" object, and then adding the drive fast method, modelling the fact that it happens to be a Porsche 911. Basic objects that are used primarily to make copies are known as prototypes. This technique is claimed to greatly simplify dynamism. If an existing object (or set of objects) proves to be an inadequate model, a programmer may simply create a modified object with the correct behavior, and use that instead. Code which uses the existing objects is not changed.
#Self
Interpolation in Julia
Constructing strings using concatenation can become a bit cumbersome ... Julia allows interpolation into string literals using $, as in Perl:
This is more readable and convenient and equivalent to the above string concatenation – the system rewrites this apparent single string literal into a concatenation of string literals with variables.
The shortest complete expression after the $ is taken as the expression whose value is to be interpolated into the string. Thus, you can interpolate any expression into a string using parentheses:
#Julia
Constructing strings using concatenation can become a bit cumbersome ... Julia allows interpolation into string literals using $, as in Perl:
julia> "$greet, $whom.\n"
"Hello, world.\n"
This is more readable and convenient and equivalent to the above string concatenation – the system rewrites this apparent single string literal into a concatenation of string literals with variables.
The shortest complete expression after the $ is taken as the expression whose value is to be interpolated into the string. Thus, you can interpolate any expression into a string using parentheses:
julia> "1 + 2 = $(1 + 2)"
"1 + 2 = 3"
#Julia
Mixin
- is a class that contains methods for use by other classes without having to be the parent class of those other classes. A mixin can also be viewed as an interface with implemented methods.
• are "included" rather than "inherited"
• encourage code reuse
• are used to avoid the inheritance ambiguity that multiple inheritance can cause (e.g. The diamond problem)
- is a class that contains methods for use by other classes without having to be the parent class of those other classes. A mixin can also be viewed as an interface with implemented methods.
• are "included" rather than "inherited"
• encourage code reuse
• are used to avoid the inheritance ambiguity that multiple inheritance can cause (e.g. The diamond problem)
The diamond problem
- is an ambiguity that arises when two classes B and C inherit from A, and class D inherits from both B and C. If there is a method in A that B and C have overridden, and D does not override it, then which version of the method does D inherit: that of B, or that of C?
For example, in the context of GUI software development, a class Button may inherit from both classes Rectangle (for appearance) and Clickable (for functionality/input handling), and classes Rectangle and Clickable both inherit from the Object class. Now if the equals method is called for a Button object and there is no such method in the Button class but there is an overridden equals method in Rectangle or Clickable (or both), which method should be eventually called?
How different languages deal with it:
• Common #Lisp: by order "...in the order in which parent classes are named in the subclass definition"
• Curl: "and the secondary constructor will be invoked for all other subclasses."
• Eiffel: "Eiffel will automatically join features together, if they have the same name and implementation."
• Go: compile-time error
• #Java: compile-time error
• #OCaml: by order "...are inherited in the same order, with each newly inherited method overriding any existing methods."
• #Perl: by order "...from as an ordered list. The compiler uses the first method it finds..."
• #Python: by order
• #Ruby: by order "...as rightmost depth first resolution."
• #Scala: by order "allows multiple instantiation of traits, which allows for multiple inheritance by adding a distinction between the class hierarchy and the trait hierarchy. A class can only inherit from a single class, but can mix-in as many traits as desired." This approach is the most similar to #Nile's; traits being qualifications.
• Tcl: by order "the order of specification in the class declaration affects the name resolution for members..."
Languages that allow only single inheritance, where a class can only derive from one base class, do not have the diamond problem.
Moreover, languages such as #Ada, Objective-C, #CSharp, #Delphi/Free #Pascal, Java, #Swift and PHP allow multiple-inheritance of interfaces (called protocols in Objective-C and Swift). Interfaces are like abstract base classes that specify method signatures without implementing any behavior.
When several interfaces declare the same method signature, as soon as that method is implemented (defined) anywhere in the inheritance chain, it overrides any implementation of that method in the chain above it (in its superclasses). Hence, at any given level in the inheritance chain, there can be at most one implementation of any method. Thus, single-inheritance method implementation does not exhibit the Diamond Problem even with multiple-inheritance of interfaces.
- is an ambiguity that arises when two classes B and C inherit from A, and class D inherits from both B and C. If there is a method in A that B and C have overridden, and D does not override it, then which version of the method does D inherit: that of B, or that of C?
For example, in the context of GUI software development, a class Button may inherit from both classes Rectangle (for appearance) and Clickable (for functionality/input handling), and classes Rectangle and Clickable both inherit from the Object class. Now if the equals method is called for a Button object and there is no such method in the Button class but there is an overridden equals method in Rectangle or Clickable (or both), which method should be eventually called?
How different languages deal with it:
• Common #Lisp: by order "...in the order in which parent classes are named in the subclass definition"
• Curl: "and the secondary constructor will be invoked for all other subclasses."
• Eiffel: "Eiffel will automatically join features together, if they have the same name and implementation."
• Go: compile-time error
• #Java: compile-time error
• #OCaml: by order "...are inherited in the same order, with each newly inherited method overriding any existing methods."
• #Perl: by order "...from as an ordered list. The compiler uses the first method it finds..."
• #Python: by order
• #Ruby: by order "...as rightmost depth first resolution."
• #Scala: by order "allows multiple instantiation of traits, which allows for multiple inheritance by adding a distinction between the class hierarchy and the trait hierarchy. A class can only inherit from a single class, but can mix-in as many traits as desired." This approach is the most similar to #Nile's; traits being qualifications.
• Tcl: by order "the order of specification in the class declaration affects the name resolution for members..."
Languages that allow only single inheritance, where a class can only derive from one base class, do not have the diamond problem.
Moreover, languages such as #Ada, Objective-C, #CSharp, #Delphi/Free #Pascal, Java, #Swift and PHP allow multiple-inheritance of interfaces (called protocols in Objective-C and Swift). Interfaces are like abstract base classes that specify method signatures without implementing any behavior.
When several interfaces declare the same method signature, as soon as that method is implemented (defined) anywhere in the inheritance chain, it overrides any implementation of that method in the chain above it (in its superclasses). Hence, at any given level in the inheritance chain, there can be at most one implementation of any method. Thus, single-inheritance method implementation does not exhibit the Diamond Problem even with multiple-inheritance of interfaces.
Language design tips
It should be either so versatile or so feature-rich that it does not need inline code execution of another language.
It should be either so versatile or so feature-rich that it does not need inline code execution of another language.
ComputerScientist
Language design tips Keep it DRY
Sex life tips
Keep it WET
Keep it WET
Do you ever look at your past projects and realize just how much they suck?
#Citron is 92.5% C and 0.6% C++ “There is one single C++ module!”
— #TheSemicolon, according to Github
— #TheSemicolon, according to Github
#TalkingSemicolon
To use all/any, you need to construct a new iterator. You can override their behavior:
#Python
To use all/any, you need to construct a new iterator. You can override their behavior:
def __and__(self, other): return Falsewhich also affects
all.#Python
#TalkingSemicolon
Tools for natural language generation
Either Keras/TensorFlow if going with #Python or TorchNN if going with #Lua.
Nothing else really works.
Tools for natural language generation
Either Keras/TensorFlow if going with #Python or TorchNN if going with #Lua.
Nothing else really works.
#TalkingSemicolon
How to insert GUI
One first makes a core logic, then connects a GUI to it, not the other way around.
GUIs are only methods for displaying things; if your GUI controls your logic, your program model is plain wrong.
Your core has to have support for actions made possible in the GUI, if you make the core based on the UI, it will be pure shit.
How to insert GUI
One first makes a core logic, then connects a GUI to it, not the other way around.
GUIs are only methods for displaying things; if your GUI controls your logic, your program model is plain wrong.
Your core has to have support for actions made possible in the GUI, if you make the core based on the UI, it will be pure shit.
#TalkingSemicolon
Was Smalltalk an inspiration for Citron's syntax?
Yes, it was.
Was it more?
It was much more than the syntax. The idea of a dynamic dispatch system with pure OO, came from Smalltalk
Have you reinvented or refined Smalltalk?
Not really, Citron is quite different, it has different thoughts behind it, it tried to do things very differently.
#Citron #Smalltalk
Was Smalltalk an inspiration for Citron's syntax?
Yes, it was.
Was it more?
It was much more than the syntax. The idea of a dynamic dispatch system with pure OO, came from Smalltalk
Have you reinvented or refined Smalltalk?
Not really, Citron is quite different, it has different thoughts behind it, it tried to do things very differently.
#Citron #Smalltalk
#TalkingSemicolon
#Citron
condition ifTrue: consequence
There's also an ifFalse:, because why waste time not'ing a boolean?#Citron
Nile's object-oriented philosophy is a combination of class-based and prototype-based programming; it is both and neither.
Class-based
There are classes but there is no inter-class inheritance.
Prototype-based
Classes are themselves objects, but there is no delegation; overriding behavior is done explicitly upon qualifications.
Class-based
There are classes but there is no inter-class inheritance.
Prototype-based
Classes are themselves objects, but there is no delegation; overriding behavior is done explicitly upon qualifications.
“You don't have to make a functionality for every nice terminology.”
— #TheSemicolon
— #TheSemicolon