#Nile
Vision
An app should be able to start executing as it is being downloaded similar to how audio or video files are able to start streaming while being downloaded.
This is achievable by storing outer layers of GUI in the beginning of the app file.
Vision
An app should be able to start executing as it is being downloaded similar to how audio or video files are able to start streaming while being downloaded.
This is achievable by storing outer layers of GUI in the beginning of the app file.
“Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.”
— R5RS, #Scheme
— R5RS, #Scheme
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