-
Notifications
You must be signed in to change notification settings - Fork 10
Principles behind Skov
Lisp represents code as nested s-expressions. Other languages use a combination of flat and nested constructs. In Skov, everything is flat: you don't have to keep track of what is inside what. Things are displayed on top of each other, not inside one another.
Code in Skov is represented with data flowing the top to bottom. Other visual languages represent data flowing from left to right, but any left-right or right-left convention is arbitrary. Different cultures interpret left and right differently. Top and bottom are different because of a universal property: gravity. In Skov you can think of data naturally falling down by gravity. Another reason for this orientation is that if you have a word that computes one result from several different inputs, the code will naturally look like a real tree.
You shouldn't need to look elsewhere to find the libraries you want. The Skov image you already have should cover all your needs. This goal is impossible to realise but the principle should be followed as far as possible.
The Skov image contains a lot of vocabularies and words but you don't need everything (especially the words that make the system work). You can activate the vocabularies you want and ignore the rest. The day you need a word that isn't active, you can just activate it.
Skov code is represented as a hierarchy of objects. When code is compiled, it is turned into different successive representations as objects, but it is never converted into textual code.
Textual programming languages force you to format the code manually. You can change the layout of the code independently of its meaning. Other graph-based visual languages require you to arrange the nodes yourself to make a pretty graph. Skov doesn't give you any control over code layout.