When we are talking about testing framework, we should ask ourselves - what kind of tests are we talking about. In languges such as Python, Ruby or JavaScript (I don't consider JS to be a language, but this is just a side note) everything should be covered with all kind of tests - unit tests, behaviors testing etc. There are languages like C++ or Java, where some testing is not required, because it is done by the compiler - and I'm talking right now about just type system. Luna incorporates much better type system than C++ or Java. In fact Luna will throw compilation error if you want to access head element of an array if it cannot prove this element would be always there (Luna incorporates a complex type inferencer and dependent type system). You can tweak the compiler and allow for more liberal behavior if you like thought.
To sum this up - I'm not talking that test framework is not necessary. It is, it is curtial and need to be polished to allow a language to be widely used. I wanted to clarify, that a great type syste, like the one in Luna, prevents from making errors so much, that you can write much fewer tests and be sure everything works as it should.
Answering other questions: - there are no global variables in the traditional meaning (in fact there are no global variables in purelly functional languages at all). If you want to have something like a global variable you use monads! "Oh no, monads, I'm running away!" - this is a completely understandable reaction for vast majority of programmers. Because of that Luna incorporates an automatic monad management system. What it does is simple and allows using monads without thinking about it. You just put a "State.run" node and you pass all variables to it, that shoudl be accessible from every palce of its sub netwrok. Then you can put "get" node, that will access these "locally global" variables for you. It's just like a State monad in Haskell (this is explanation for Haskellers), but with visual, easy interface.
And one more thing. Global variables are pure evil. I would call them bilion dollar mistake, such as null pointer references. Monadic states are pure and nice solution for it. (btw. Luna of course doesnt have something like `null`).
- The lines you see represent all data dependencies in a graph. Anything not connected with lines (or monadic lines - like two actions that print something to the screen) can be run side by side. Our compiler understands that and can shedule the nodes to be executed in parallel.
- Exceptions are represented on the bottom of our page. Exceptions in the meaning known from imperative programming are messy, ugly and doesnt fit in the visual environment well. In fact they are hard to deal by developers too - have you ever tracked an exception stack of poorly written code? This is pure nightmare. Luna introduces dataflow exceptions - please look at our website and I will answer any qeuestions that could appear after reading it :)
- We have created a really big graphs with Luna without ending with spagetti - each node is build outo of graph of other nodes. If you've got to many nodes on the stage is justl ike writing a collosal 1k lines long function in textual code. You can then select some nodes and collapse them into one (just like refactoring functions out of such code block).
We are aware of all these things and we do what we can to create a REALLY useful visual programming expirence. We've started this project because nobody ever did it and all the tools currently available (excluding some domain specific ones like Houdini, Labview etc) are just toys and cannot be considered programming tools.
Are you referring to this?
fileAge = open 'age.txt' . to Int
age = age.catch e:
print 'An error occured: ' + e
read 'Provide your age: ' . to Int
First, I think you probably meant to write fileAge.catch there. Second, what would that look like as a graph? Having a visual programming language is not really interesting if you have to go back to text for exception handling. Maybe you should show a side-by-side comparison of the other examples as well.I don't think that's entirely true. For example there is EMC XProc Designer[1]. XProc is a mature W3C standard with several open-source implementations.
With a proper IDE support it's no harder to write than Lisp. So by that definition
> EMC XProc Designer cannot translate graphical representation to code and vice versa.
the answer is yes, it can.
But the most popular tool in this category probably was Yahoo Pipes. They closed Yahoo Pipes.
How can I get my hands on an interesting sample (perhaps a very basic/simple web server that can serve up static html/images?)
If the concept allows, as some have mentioned, to let non-programmers make changes, then a fully-integrated test framework is absolutely required.
Other questions come to mind:
- How are global 'variables' (config, settings, etc.) represented? As more lines, or traditional named variables?
- Although the Category Oriented Programming seems compelling, I'm not seeing how this visual world will address concurrency in any meaningful way (maybe I'm missing something) - although the profiler is nice.
- Visual programming is also extremely messy when dealing with exceptions: not sure how that is addressed here - again more lines?
Before long you end up with spaghetti... but perhaps they've solved that via views / layers or something.
I highly applaud this effort, but it needs to address the complexities of software development /on the development side/... or it won't get much use by professional developers.