Compare Windows to a station wagon and Linux to a free tank. People still buy the station wagon despite free tanks being given away, because people do not want to learn how to operate a tank. Also they know that the station wagon dealership has a machine shop that they can take their car to when it breaks down. Because of this attitude, Microsoft is not really a monopoly, as evidenced by the free availability of other choice OSes, but rather has simply accrued enough mindshare among the people to have them coming back. Microsoft not unlike Disney, sells a vision to their customers, who in turn "want to believe" in that vision.
~ Neal Stephenson, In the Beginning... Was the Command Line
~ Neal Stephenson, In the Beginning... Was the Command Line
Forwarded from Ali "AnotherTest" Mohammad Pur
Oh, those are already around
Just in bits and pieces
Just in bits and pieces
Forwarded from Ali "AnotherTest" Mohammad Pur
All I'd have to do is copy paste a bunch of code from my other projects, and glue them together
TODO: make this process less time consuming; too much time and focus is wasted on it.
Symbolic programming
- is a paradigm that describes programs able to manipulate formulas and program components as data. Programs can thus effectively modify themselves, and appear to "learn", making them suited for applications such as artificial intelligence, expert systems, natural-language processing and computer games. Languages that support this paradigm include #Lisp and #Prolog.
- is a paradigm that describes programs able to manipulate formulas and program components as data. Programs can thus effectively modify themselves, and appear to "learn", making them suited for applications such as artificial intelligence, expert systems, natural-language processing and computer games. Languages that support this paradigm include #Lisp and #Prolog.
Dataflow programming
Traditionally, a program is modelled as a series of operations happening in a specific order; this may be referred to as sequential, procedural, control flow, (indicating that the program chooses a specific path), or #imperative programming. The program focuses on commands, in line with the von Neumann vision of sequential programming, where data is normally "at rest".
In contrast, dataflow programming emphasizes the movement of data and models programs as a series of connections. Explicitly defined inputs and outputs connect operations, which function like black boxes. An operation runs as soon as all of its inputs become valid. Thus, dataflow languages are inherently parallel and can work well in large, decentralized systems.
Traditionally, a program is modelled as a series of operations happening in a specific order; this may be referred to as sequential, procedural, control flow, (indicating that the program chooses a specific path), or #imperative programming. The program focuses on commands, in line with the von Neumann vision of sequential programming, where data is normally "at rest".
In contrast, dataflow programming emphasizes the movement of data and models programs as a series of connections. Explicitly defined inputs and outputs connect operations, which function like black boxes. An operation runs as soon as all of its inputs become valid. Thus, dataflow languages are inherently parallel and can work well in large, decentralized systems.
Constraint programming
- is a programming paradigm wherein relations between variables are stated in the form of constraints. Constraints differ from the common primitives of imperative programming languages in that they do not specify a step or sequence of steps to execute, but rather the properties of a solution to be found. This makes constraint programming a form of declarative programming. The constraints used in constraint programming are of various kinds: those used in constraint satisfaction problems (e.g. "A or B is true"), linear inequalities (e.g. "x ≤ 5"), and others. Constraints are usually embedded within a programming language or provided via separate software libraries.
Mostly, constraints are implemented in imperative languages via constraint solving toolkits, which are separate libraries for an existing imperative language.
Constraint (#mathematics)
- is a condition of an optimization problem that the solution must satisfy. There are several types of constraints—primarily equality constraints, inequality constraints, and integer constraints. The set of candidate solutions that satisfy all constraints is called the feasible set.
- is a programming paradigm wherein relations between variables are stated in the form of constraints. Constraints differ from the common primitives of imperative programming languages in that they do not specify a step or sequence of steps to execute, but rather the properties of a solution to be found. This makes constraint programming a form of declarative programming. The constraints used in constraint programming are of various kinds: those used in constraint satisfaction problems (e.g. "A or B is true"), linear inequalities (e.g. "x ≤ 5"), and others. Constraints are usually embedded within a programming language or provided via separate software libraries.
Mostly, constraints are implemented in imperative languages via constraint solving toolkits, which are separate libraries for an existing imperative language.
Constraint (#mathematics)
- is a condition of an optimization problem that the solution must satisfy. There are several types of constraints—primarily equality constraints, inequality constraints, and integer constraints. The set of candidate solutions that satisfy all constraints is called the feasible set.
“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.