>>39
You are correct: there is very very little chance of me producing anything meaningful in the near future, unfortunately.
Yes, I am not speaking of library dependencies, though ultimately that will need to be looked at sometime too.
I mean the dependencies between sections of code. Apparently (from reading various articles) one of the major sources of bugs is that when a piece of code is changed, the dependent pieces of code are not updated and a bug is introduced. This is the reason for encapsulation in OOP, for example.
When you look at code, you can see that each operation in an expression is a dependency of the next operation in the expression and that each expression is a dependency to the next expression in a statement and so on for functions/procedures, classes/objects, modules and whatever other abstractions you may use.
My little toy language works by specifyung that "X depends on Y" and "Y depends on Z" and so on, building up expressions, functions, objects and modules (in reality, each of these work in the same way - I simply call them
functions for convenience).So you can build up functions from other functions (just as you do in other languages).
Because of the way this works, I guess it's a graphical "functional" programming language.
The language contains a single statement: Function X depends on function Y (where Y could be a list of functions). Thats it.
There would, of course, be a number of primitive functions (add, subtract, whatever) and all others would be built up of these.
The way the code is executed is that if a function has no dependencies (or it's dependencies have been met) then the function is evaluated. This may, in turn, meet another functions dependencies and the cycle continues.
Very very simple example:
integer
a initialized to
10
integer
b initialized to
20
integer
c depends on
addition1
addition operation
addition1 depends on integers [a] and
[b]
addition1 is evaluated because both of it's dependencies can be met. c can be set to 30 because it's dependency, addition1, has now been met.
It's a little more complicated than that, but thats more or less it.
While I don't really know if this does indeed eliminate dependency based bugs, it does have a certain charm to it, IMHO. Namely, that a language could be built up of a SINGLE statement and still be able to do everything. In reality more statements would exist, but they would sit around the single statement core.
PS: I wrote a class in Python which could evaluate code as described above. I know it works, what I don't know yet is how well - I wont know until the editor is complete - and I'm not quite decided what the "syntax" should be... real life is getting in the way :-/
RE:
purely graphical programming is only worthwhile if...
That is true. My first approach was to create a textual programming language, but then I realised that it wastoo awkward and tedious to code in, yet using diagrams (on paper) to write an algorithm was quite easy (and converting the diagram to text code was also straightforward). this is why I chose to use a graphical language instead of a textual one.
I suppose that ultimately it would require both.. Perhaps with correctly designed keyboard shortcuts, I could eliminate the use of the mouse and have a hybrid graphical/textual language without too much tedium. I don't know..
One thing I was thinking of recently was to have each element of the graphical language annotated with a textual expression (for example, a mathematical formula), but I need to play with this idea some more.
All in all, even though I came up with this idea a year ago, it is still in extremely early stages. I don't see myself getting anywhere meaningful in the near future... :-(
Sorry for tl;dr post. Comments appreciated.