10 ms·

Full Metal Jacket: A Visual Programming Language Based on Lisp

166 points by vmorgulis 10y ago

Pxtl 10y ago
How does it compare to other wire-up graphical programming languages like LabVIEW's G or Unreal's Kismet? Does it store the underlying data in a textual representation so it's still GIT and Regexp friendly?
- DonaldFisk 10y ago
  Some time soon, I'll get around to adding videos to the tutorials, so that you can see how programs are edited, instead of just showing completed functions. TL;DR: Full Metal Jacket is a general purpose, pure dataflow language, supporting recursion, higher order functions, strong typing, type inference, and macros. It's entirely graphical, but it is possible to call Lisp. It has a very simple, regular, syntax, with only vertices, edges, constants, and enclosures. No special syntax is required for conditions, iteration, or new type definitions. It is homoiconic, though I haven't yet made full use of that. It is an alternative model of computation, potentially enabling different parts of an algorithm to run concurrently. It is still under development. It's implemented in Lisp, so the underlying data are Lisp data structures. Programs are stored as S-expressions, are not particularly easy to read or safe to modify.
  - kyllo 10y ago
    Programs are stored as S-expressions, are not particularly easy to read or safe to modify. What you've built sounds very interesting, but this part is a problem you may need to solve before programmers will embrace it. If I can't use git with it, I can't develop any non-trivial software with it.
    - vmorgulis 10y ago
      Something that could work with git is to use a map. Transform: (a1 a2 (b1 b2)) To: ------------- parent child ------------- root list1 list1 a1 list1 a2 list1 list2 list2 b1 list2 b2 It should work with diff too if the ids are preserved.
      - kyllo 10y ago
        That's exactly how you store a tree in a relational database. Every row has a parent_id column. This language isn't just a tree though, it's a graph, so you would need a row per edge instead of a row per node. It would work with git as long as it's kept in sorted order and doesn't grow extremely large, but it isn't nice to view or edit directly; you would want a graph query language to interact with it.
      - TeMPOraL 10y ago
        That would work as long as the author isn't seriously abusing reader macros in the serialized format :).
    - mpbm 10y ago
      You need version control and diffs, not git. In a visual system I think it makes more sense to use visual diffs, or algorithm generated summaries. Technically, what git shows you is already a visual diff ;) and they like to draw the diff tree instead of describing it textually because it makes a lot more sense.
  - mpbm 10y ago
    You can use gifCam to make quick little animated gifs that are a lot easier to produce and more portable than videos. Here's an example from my project Howstr. The dictionary has a lot more. http://github.howstr.com/quickstart.html http://github.howstr.com/quickstart.html I ended up doing roughly the same thing. The graph is based on text, stored in arrays in memory. I just convert to JSON to store on disk. You wouldn't want to mess with the JSON, but technically you could if you didn't make any mistakes. You can't actually run the programs in parallel though, right? The structure is there but you'd need something on a chip to take advantage of it?
  - segmondy 10y ago
    Do you have any plans in the near future to open up the code to the world?
- crispyambulance 10y ago
  LabVIEW is a marvelous, highly productive programming language. It has been around longer than Java and has been through coherent, well-planned development since the late 80's. The underlying data is all binary, but LabVIEW has built-in diff tools that allow you to compare diagrams (the source code) between two vi's (LabVIEW files). As a result, you can use it with source control and coordinate multiple developers much like any other language. It isn't really necessary for the underlying data to be text. Search is also pretty decent. The beauty of dataflow languages is that it frees the developer to think about what is really important while the runtime handles the nasty concurrency issues. Does this approach work for all problem domains? No, but it works fine for a lot of stuff. Nothing comes close to LabVIEW for making concurrency trivial. Its a pity that LabVIEW and programming languages like it haven't seen much mainstream adoption. In the right hands and in the right problem domain, a good LabVIEW dev can do things that would make other programmers' jaws drop.
  - scottlocklin 10y ago
    LabVIEW is pretty mainstream in scientific instrument construction and control. I just wish more HN type people were exposed to it, because a well designed graphical language is unquestionably more productive than a classical programming language, at least in that problem space.
    - crispyambulance 10y ago
      Yep, and in manufacturing test applications as well. BTW, I remember you from Pitt Physics, Scott, Cheers!
      - scottlocklin 10y ago
        Hey there, mysterious Pitt alum!
  - Pxtl 10y ago
    Yeah, I'm surprised the developer didn't compare their language to LabVIEW. If I were writing about a bare-metal language, I'd compare it to C, or an embedded language to Lua.
reubano 10y ago
Is there a github repo?
timthelion 10y ago
Looking at the tutorial now, and it is very intuitive. Nice ;) Edit: Too bad it hasn't been opensourced. Lack of being opensourced is a death sentence for any tool.
- zitterbewegung 10y ago
  Microsoft , wolfram research , mathworks would like to have a word with you .
  - timthelion 10y ago
    Microsoft is currently in the process of opensourcing their TOOLs. Their tools were dying out before they did so. Actually, I didn't always believe this, I saw in the time around longhorn, that visual studio was miles ahead of anything else with its almost bugless, very fast, easy to install tools that had every library preconfigured to provide autocompletion and documentation. I was surprised that the majority of windows programmers I knew were using open source tools origionally developed for linux or the "java ecosystem" on windows. But that's the way it is now adays. And Microsoft knows it too.
    - biocomputation 10y ago
      ORLY
  - DonaldFisk 10y ago
    I could do with some paid work. I have three published papers, six patents, 35 years computing experience in lots of different areas, and no job.
    - timthelion 10y ago
      Patents suck. In 90% of the cases, they cost everyone money, including the inventor. :(
Koshkin 10y ago
Of course, as it has been said, a picture is worth a thousand words, but there must be a reason why diagrammatic languages have not received the acceptance as widespread as text-based languages have. Even in "obvious" cases like microcircuit design engineers prefer text-based "hardware definition languages" over diagrams. One explanation could be that human intellect has evolved in the process of perfecting means of communication and thinking, of which a language based on symbols (words) proved to be most efficient, particularly in conveying abtractions, which is exactly where pictures, being concrete,fell short.
- timthelion 10y ago
  Personally, I think that drag and drop is a really bad UI for doing this sort of thing. I think that the lack of an effective means of editing graph based information has been a big reason. I think that the seccond reason, is that all of these tools have used their own, complicated serialization format, rather than using something more unixy that you could build a real ecosystem around. I'm trying to solve these problems with textgraph: http://thobbs.cz/tg/tg.html http://thobbs.cz/tg/tg.html and while the ecosystem is still in daipers, I am finding that using a simple and LIMITED file format, that can do nothing more than use text based edge lables and text based vertex contents, makes development of the ecosystem much faster than if I were to go crazy with having ecosystem features like edge collors, box vertex and arrow shapes ect.
- joemi 10y ago
  Max/MSP has been very successful, though it's specialized for the music/visuals world. Given the text-based alternatives in that realm (csound, supercollider), it's not surprising.
- empath75 10y ago
  I suspect that VR is going to open new ground here.
- Pamar 10y ago
  I have some experience with a visual language (webMethods, currently owned by Software AG). Guess what I miss the most when I use it? diff -c And all the rest you get with text (versioning, global search&replace, static analysys...)
analognoise 10y ago
This has popped up several times iirc, and there is nothing available to try out.
- DonaldFisk 10y ago
  Yet. Before I release it, I want it to be a polished product which runs reliably, and has good documentation, so that people will continue to use it after downloading it. I'm working alone, without any backing.
  - empath75 10y ago
    Have you considered what a full 3D version with touch controls might look like?
  - relyks 10y ago
    Full Metal Jacket seems really promising. Thanks for working on this. Have you seen Clarity? Yours looks more interesting, but it's another visual programming language: http://www.clarity-support.co.uk/products/clarity/ http://www.clarity-support.co.uk/products/clarity/ There's a book on it too: https://www.amazon.com/Drawing-Programs-Schematic-Functional-Programming/dp/1848826176/ https://www.amazon.com/Drawing-Programs-Schematic-Functional... There might some aspects that could be useful to your work.
  - analognoise 10y ago
    Do you accept donations?
    - DonaldFisk 10y ago
      Donations would be very helpful of course, but I don't yet have any mechanism set up to receive them. If you or anyone wishes to make them, please first get in touch by email (my email address is on http://web.onetel.com/~hibou/index.html http://web.onetel.com/~hibou/index.html). Then, I could arrange to receive donations, perhaps via Paypal.
bgribble 10y ago
Really interesting! Much of the active "prior art" in data flow languages is in audio and music, where systems like Max/MSP [1] and Pure Data [2] have made several generations of musicians into programmers without even telling them they were programming! My long-running personal project MFP [3] looks at basically the same problem as FMJ -- visually representing data flow programs with a "real" language under the hood -- but using Python as the underlying language runtime and adopting the graphical conventions of Pure Data. Great to see interest in dataflow programming. It really is a good way to turn your programming mind inside out. [1] https://en.wikipedia.org/Max_(software) https://en.wikipedia.org/Max_(software) [2] http://puredata.info/ http://puredata.info/ [3] https://github.com/bgribble/MFP https://github.com/bgribble/MFP
- deleted 10y ago
  [deleted]
- junke 10y ago
  See also OpenMusic[1], also based on Lisp. Also related, because of the data flow approach: Faust[2]. [1] http://forumnet.ircam.fr/product/openmusic-en/ http://forumnet.ircam.fr/product/openmusic-en/ [2] http://faust.grame.fr/examples/2015/07/29/simple-faust-example.html http://faust.grame.fr/examples/2015/07/29/simple-faust-examp...
the_duke 10y ago
I would have liked to try it out, but the page has neither a download link nor a link to any source code. Not available, apparently.
- timthelion 10y ago
  I like sites that look like its the 90ies. What is wrong with a simple site that contains information and nothing more? Information is what we came for, not some stupid theme that someone downloaded somewhere and serves only to distract, slow down, and hinder accessability. I'm not blind or visually impaired, but I still like to use the tools built into my browser, such as the ability to enlarge text, without having a bunch of irrelevant div elements overlap eachother.
  - the_duke 10y ago
    I guess http://motherfuckingwebsite.com/ http://motherfuckingwebsite.com/ applies. ;)
cs702 10y ago
This is an interesting, worthwhile project, but the headline, "text-based languages are so 20th century," struck me as naively arrogant. There are a TON of interesting '21st century' things being done with the "text-based languages" this website dismisses. BTW, that website is so 20th century.
- white-flame 10y ago
  And to be honest, the visual programming language fad for "actual" use was so 20th century as well. Visual programming has found a bit of a home with "programming for non-programmers" around kids'/intro stuff and some game tools.
- mpbm 10y ago
  I'm working on something similar and I agree with him. Writing is literally stone-age technology. It's adequate for many things, but it's only got one feature. We need something with more dimensions. There were a lot of attempts at touch-based interfaces before someone finally got it right and everyone went "Oh, that's how that's supposed to work."
akkartik 10y ago
Here's how iteration works (http://web.onetel.com/~hibou/fmj/tutorials/Iteration.html http://web.onetel.com/~hibou/fmj/tutorials/Iteration.html): "Iteration uses two special linked vertices called start+ and repeat+. The start+ vertex has an equal number of inputs and outputs. When a value is received on every input of start+, each value is output on the corresponding output. The repeat+ vertex has the same number of inputs as start+, each of which has the same type. An edge connected to an input on repeat+ really sends its values to the corresponding input on start+. So repeat+ is just an extension of start+, and has no independent existence. Its inputs can be treated as the inputs of the start+ vertex to which it is linked." Reading this, I was curious how we disambiguate nests with multiple loops. For example, at http://web.onetel.com/~hibou/fmj/tutorials/DampedHarmonicOscillator.html http://web.onetel.com/~hibou/fmj/tutorials/DampedHarmonicOsc... the repeat+ on the right is connected to data from both start+ vertices. The types too are the same for both loops. How does the software decide which one to send data to? It must be using some information that isn't visible in the figure.
- DonaldFisk 10y ago
  That's correct. The start+ and repeat+ vertices are linked to each other, so there's no possibility data will be sent to the wrong start+ after it is sent to a repeat+. If you hover over one, the other it's linked to is highlighted.
  - nialo 10y ago
    It seems like there must be some way to indicate that a particular start+/repeat+ pair are connected, even just an edge in a different color seems like it'd be a big help.
    - DonaldFisk 10y ago
      Thanks. I decided that layout, along with being able to hover over the vertex to see the one it's connected to would be sufficient, but I'm open-minded and may indicate it some other way as well if it becomes an issue. Edge colors are a crude indication of data type, e.g. Lists are red whatever their subtype, Booleans are green, and Integers blue.
qwertyuiop924 10y ago
Fascinating, but there is a reason text-based languages have endured as long as they have. Text is universally understood: everybody knows at least how to type, and the essentials of how to read. Those constraints mean that one language can only be so different from another, making it easier to pick up multiple languages. Most importantly, text has endured. ASCII was readable 20 years ago, and it will probably be readable in some form 20 years from now. There are many standard programs that can read and write the format. Just try reading an FMJ program if you don't have the code on hand, and the repo goes 404. Have fun reverse engineering.
- timthelion 10y ago
  I agree. I've created an ecosystem called textgraph to address this problem: http://thobbs.cz/tg/tg.html http://thobbs.cz/tg/tg.html
- SixSigma 10y ago
  APL is text based. You can't represent some older programs even with Unicode. Most of the characters are now in Unicode but some have been deprecated in modern implementations because of the missing representations. https://en.wikipedia.org/wiki/APL_(codepage) https://en.wikipedia.org/wiki/APL_(codepage)
  - qwertyuiop924 10y ago
    APL isn't recognizably text. Not ASCII, or really any encoding save its own. Besides, the creator of APL has solved that problem. Take a look at J & co, to see how to do APL in ASCII.
    - SixSigma 10y ago
      The point being that the singling out ASCII is survivor bias. ^ ~ | @ # * are not characters to generally be found in handwriting and not just natural inclusions in a character set.
      - 10y ago
greenspot 10y ago
> Programs are composed almost entirely with the mouse rather than keyboard Then this is not my cup of tea. I think the keyboard is still the best and most versatile interface to a computer.
- WalterSear 10y ago
  https://www.youtube.com/watch?v=v9kTVZiJ3Uc https://www.youtube.com/watch?v=v9kTVZiJ3Uc
  - DonaldFisk 10y ago
    http://web.onetel.com/~hibou/fmj/interpreter.pdf http://web.onetel.com/~hibou/fmj/interpreter.pdf ;-)
- nwrviybewir 10y ago
  totally agree. Even if a good graph representation of code existed (trees diagrams of ASTs or S-Exprs) the keyboard would still be the most efficient way to navigate & edit them. Drag & drop is a rubbish system, too slow.
  - DonaldFisk 10y ago
    In Full Metal Jacket, mouse gestures are minimized. It's often just right-click on an output, which opens a canvas containing methods with an input of the output's type (or moves it to the front if it's already open), drag over the vertex you want, drop it, and its input is automatically connected to the output of the vertex you right-clicked on. In any case, most programming time is spent thinking. In comparison, very little is spent typing. If that's not the case, it's a sign the language is too verbose.
kilon 10y ago
Praise text programming languages all you want and you will be correct. Programming languages used by coders are by far text based. However when you leave the coder land and when you jump to user land this turns on its head. Overwhelming rejection of text based programming languages and overwhelming embrace of visual programming languages. Every software that integrates a easy to learn scripting language like Python and Lua and later implements a visual programming language , users will pick the visual language in the vast majority of cases. A very powerful visual programming language is Unreal's Blueprints which can completely replace the C++ Api for creating games of any sophistication. As a matter of fact as I have discovered it's easier to find documentation how to implement something with blueprints than C++. It's a just a matter of time till visual programming languages overtake , text based languages because more and more apps prefer the visual coding route because this is why what the users ask. Why ? Because it's easier to learn It's easier to write, because there are no syntax or compiler errors. But mostly it's easier to have fun with. So if for an experience coder text based language is all he wants, for the user the choice is visual programming languages any day.
- torkable 10y ago
  [citation needed]
- justinmk 10y ago
  > Blueprints which can completely replace the C++ Api C++ is a rather low bar. > It's a just a matter of time ... That sets the upper limit to infinity, so it's a non-statement. > Because it's easier to learn It's easier to write, because there are no syntax or compiler errors. AST-constrained editing (e.g. lamdu[1]) will be very useful. But the lowest-common denominator cannot be "overtaken". That is why stdio is a binary stream, webapps are compiled to javascript, and programming is represented as text. Any advanced programming language that can't be represented and manipulated by ubiquitous tools will lose to one that does, so text will never--yes, never--be replaced as the common vernacular, for better or worse. To paraphrase Stephen Kell[2], Smalltalk lost because for whatever reason the people who hadn't yet "seen the light" continued to communicate and interoperate with each other. 1: http://www.lamdu.org/ http://www.lamdu.org/ 2: https://www.cl.cam.ac.uk/~srk31/research/papers/kell13operating.pdf https://www.cl.cam.ac.uk/~srk31/research/papers/kell13operat...
pipio21 10y ago
Some people say there is a reason for text being used in programming, of course there is a reason: the terminal, that evolved from the teletype, that evolved from the typing machine and morse codes. For someone to make a new system you need two things: 1- Completely rethink and redesign how things are done. 2- Modify all the tools in use today. This is the biggest part by far. The amount of work you have to do is so much that most people will just choose to continue evolving over the current system. E.g for making your own visual language you not only have to develop the language itself, but make the compiler also visual, and the debugger also visual, but the tools you could modify, like llvm are text based and terminal based. Modifying llvm for it is hell. And consider yourself lucky if you have to modify llvm, because in the past it was gdb with monolithic design and no libraries. An example of a redesign was Xerox PARC GUI. Instead of one input-one output development system in the terminal they added 20 or 30 inputs and 20 or 30 outputs. For this they had to use a new programming concept, so they had to use object oriented programming(without it handling 20 inputs-outputs at the same time becomes so hard it is in practice impossible), that at the same time forced them to develop their own tools in order to see object oriented data structures and methods. Any modern UI development inherits from Xerox design. Another paradigm change was the Iphone: it forced every smartphone to have hardware acceleration video and touchscreen and used it as input methods. People like Bret Victor and MathBox creator are trying to redesign the whole concept using new tools like GPU programming and video displays. I agree with them. The current system is so wrong , even when it is the only thing we have.
- bunderbunder 10y ago
  It's not just about VT100s. It's that text is far and away the go-to format for recording any information that's abstract or has narrative structure. It has been for a very long time. There are graphical techniques, but they all work in very specific and limited domains. In the wild, even flowcharts that aren't meant to represent a process that has dynamic state are frequently tagged with annotations for explaining important details that are difficult or impossible to convey within the strictures of a flowchart's graphical language. That's not to say that the idea of a visual programming language is not intriguing, or that it's a waste of time to explore them. But the reasons why it's an uphill battle go far beyond mere inertia.
gavinpc 10y ago
Where's the data? A "data flow language" that only visualizes functions isn't. IMHO. I agree with most of the perennial discussion that takes place here for all of these projects: text is good, but not for everything and everyone, yet graphical programming has never taken off... why? Because if people want a data flow, they care more about the data than the flow. Spreadsheets have secured a rock-solid place in the "lingua franca" of userland, without ever visualizing the "connections," which are seldom enlightening. I would not criticize something for failing to achieve what it doesn't attempt, and FMJ may be fantastic for developing logic. But it calls itself a "visual dataflow language," and I'm not seeing any data. (Yes, code is data in lisp, that's not what I mean.) To visualize code is to focus on the means to the end. I would respectfully disagree that "21st-century" programming will resemble the static modelling of systems represented by code in whatever form. Systems will be "live" as a rule. And that is what will improve the lives of programmers. Remember that "interactive computing" was once a radical idea, the realization of which required people to spend their lives and resources fighting for it (Licklider, Englebart, and Bob Taylor et al, to name a few). Well, if you feel any resistance to the idea of relinquishing your rinse-and-repeat development cycle, I have two words for you: punch cards. I hope I am not trolling here. Just this month I've been "sniped" by a data flow side-project that has me thinking about these things, and I'm extremely interested in how other people approach the subject (and their discussions here). edit grammar, wording
- DonaldFisk 10y ago
  You certainly aren't trolling, and your point is valid. Directed graphs are the most general data structure, and the language is homoiconic. So data definitely will be represented graphically: not just directed graphs, but other structures such as arrays. But there's only one of me, and if I'd done this already, something else wouldn't have got done. However, it is high on my agenda, and will be done soon.
- rjurney 10y ago
  PigPen had this right... it visualized syntax that you typed. You could technically code with the mouse but that wasn't the intention of the tool. It made it easier to get a gestalt view of things, without hiding the essential details of operations. It was just another window into your code in Eclipse. I think Microsoft's IDE has similar stuff for OO code? But I've never used it. https://wiki.apache.org/pig/PigPen https://wiki.apache.org/pig/PigPen I tried to commercialize this technology in 2010, with Cloud Stenography (a joke name): https://github.com/rjurney/Cloud-Stenography https://github.com/rjurney/Cloud-Stenography https://vimeo.com/6032078 https://vimeo.com/6032078 More recently, a company has done some similar stuff, albeit for Spark, in Seahorse: http://seahorse.deepsense.io/ http://seahorse.deepsense.io/
happyslobro 10y ago
Visual languages have been superseded by abstract symbolic languages time and again throughout history. I don't really feel qualified to determine whether or not visual general purpose programming languages could work or not, but I do think that anyone who is pursuing that goal needs to start by figuring out why natural languages progressed from visual to symbolic. Demonstrating that programming languages could progress in the other direction would probably be the primary goal of their endeavour, and when they present their work, it should probably focus on examples of idioms that are easy to express visually, but difficult to express in text form. I am not convinced that those idioms even exist; but then, since I have never used a visual programming language. It could be that I am simply incapable of contemplating them, in my current frame of mind.
jrapdx3 10y ago
This is vaguely reminiscent of Drakon, which has been around a long time, but AFAIK hasn't made much of a dent in the programming world, at least outside of Russia. A couple of years ago I was trying to do something with the visual language but can't say I successfully mastered it. Interesting to me is that the Drakon editor was implemented in Tcl/Tk, a language I'm quite familiar with. I regard Tcl as a dialect of Lisp, which I've also used a fair amount, at least in the guise of Scheme. As I'm not at all familiar with this new language can't say too much about it, though implementation in Lisp might be a plus. One issue with it, as with other efforts in this domain, may be that it's not as intuitive or obvious as its authors believe. IOW, in my admittedly limited experience with visual programming, there's more of a learning curve than advertised. Visual "syntax" is sufficiently different from conventional text-based forms that people have learned to use, often at the cost of great effort and time. Translating the thought process to a visual metaphor isn't intuitive or easy as I've attempted to learn it. What's odd is that I have ability and a fair amount of success in the visual art of printmaking, which one could say is an expression of a visual language itself, but one that doesn't map well at all to the visual coding of computer programs. No reason to think it necessarily would, but the observation points to an apparent multiplicity of "visual modes" embedded in our brains.
jiyinyiyong 10y ago
Similar idea here but I think we can not do that before VR is poopular. But a text-look form fits the first decades of 21th centry better https://www.youtube.com/playlist?list=PLyvBXLgHYHy1AIK6i5uw3_H5BIUP4CQx6 https://www.youtube.com/playlist?list=PLyvBXLgHYHy1AIK6i5uw3...
jiyinyiyong 10y ago
Similar idea here but I think we can not do that before VR is poopular. But a text-look form fits the first decades of 21th centry better https://www.youtube.com/playlist?list=PLyvBXLgHYHy1AIK6i5uw3_H5BIUP4CQx6 https://www.youtube.com/playlist?list=PLyvBXLgHYHy1AIK6i5uw3...
jiyinyiyong 10y ago
Similar idea here but I think we can not do that before VR is poopular. But a text-look form fits the first decades of 21th centry better https://www.youtube.com/playlist?list=PLyvBXLgHYHy1AIK6i5uw3_H5BIUP4CQx6 https://www.youtube.com/playlist?list=PLyvBXLgHYHy1AIK6i5uw3...
OrthoMetaPara 10y ago
A couple of suggestions: 1. It reminds me of the graphical view that is present in the IDA disassembler in which functions are broken into "boxes" wherever there is a jump in control flow. If you're disassembling a C function, for example, this generally means that a box corresponds to some block of code that is delimited by curly braces. The point here is that you don't have a box for every single assembly instruction, because that would be ridiculous. Rather, the function is broken down into several "clauses" that express complex ideas, and then each clause is described textually by several lines of code. For example, if I want to express something like: (lambda (x y) (/ (* 2 x) (+ x y))) then it would be nice if I could draw a box with input terminals for x and y and then type in the expression, rather than having to create three boxes for each arithmetic operation. It would be faster to program this way, and the result would easier to read. 2. Also, drawing inspiration from IDA's visual mode (as well as electronic circuit diagrams), lines should all travel at right angles. There should also be an auto layout mode which attempts to layout the graph so that there are a minimum number of edge crossings.

166 points by vmorgulis 10y ago

Pxtl 10y ago

How does it compare to other wire-up graphical programming languages like LabVIEW's G or Unreal's Kismet? Does it store the underlying data in a textual representation so it's still GIT and Regexp friendly?

DonaldFisk 10y ago
Some time soon, I'll get around to adding videos to the tutorials, so that you can see how programs are edited, instead of just showing completed functions. TL;DR: Full Metal Jacket is a general purpose, pure dataflow language, supporting recursion, higher order functions, strong typing, type inference, and macros. It's entirely graphical, but it is possible to call Lisp. It has a very simple, regular, syntax, with only vertices, edges, constants, and enclosures. No special syntax is required for conditions, iteration, or new type definitions. It is homoiconic, though I haven't yet made full use of that. It is an alternative model of computation, potentially enabling different parts of an algorithm to run concurrently. It is still under development. It's implemented in Lisp, so the underlying data are Lisp data structures. Programs are stored as S-expressions, are not particularly easy to read or safe to modify.
- kyllo 10y ago
  Programs are stored as S-expressions, are not particularly easy to read or safe to modify. What you've built sounds very interesting, but this part is a problem you may need to solve before programmers will embrace it. If I can't use git with it, I can't develop any non-trivial software with it.
  - vmorgulis 10y ago
    Something that could work with git is to use a map. Transform: (a1 a2 (b1 b2)) To: ------------- parent child ------------- root list1 list1 a1 list1 a2 list1 list2 list2 b1 list2 b2 It should work with diff too if the ids are preserved.
    - kyllo 10y ago
      That's exactly how you store a tree in a relational database. Every row has a parent_id column. This language isn't just a tree though, it's a graph, so you would need a row per edge instead of a row per node. It would work with git as long as it's kept in sorted order and doesn't grow extremely large, but it isn't nice to view or edit directly; you would want a graph query language to interact with it.
    - TeMPOraL 10y ago
      That would work as long as the author isn't seriously abusing reader macros in the serialized format :).
  - mpbm 10y ago
    You need version control and diffs, not git. In a visual system I think it makes more sense to use visual diffs, or algorithm generated summaries. Technically, what git shows you is already a visual diff ;) and they like to draw the diff tree instead of describing it textually because it makes a lot more sense.
- mpbm 10y ago
  You can use gifCam to make quick little animated gifs that are a lot easier to produce and more portable than videos. Here's an example from my project Howstr. The dictionary has a lot more. http://github.howstr.com/quickstart.html http://github.howstr.com/quickstart.html I ended up doing roughly the same thing. The graph is based on text, stored in arrays in memory. I just convert to JSON to store on disk. You wouldn't want to mess with the JSON, but technically you could if you didn't make any mistakes. You can't actually run the programs in parallel though, right? The structure is there but you'd need something on a chip to take advantage of it?
- segmondy 10y ago
  Do you have any plans in the near future to open up the code to the world?
crispyambulance 10y ago
LabVIEW is a marvelous, highly productive programming language. It has been around longer than Java and has been through coherent, well-planned development since the late 80's. The underlying data is all binary, but LabVIEW has built-in diff tools that allow you to compare diagrams (the source code) between two vi's (LabVIEW files). As a result, you can use it with source control and coordinate multiple developers much like any other language. It isn't really necessary for the underlying data to be text. Search is also pretty decent. The beauty of dataflow languages is that it frees the developer to think about what is really important while the runtime handles the nasty concurrency issues. Does this approach work for all problem domains? No, but it works fine for a lot of stuff. Nothing comes close to LabVIEW for making concurrency trivial. Its a pity that LabVIEW and programming languages like it haven't seen much mainstream adoption. In the right hands and in the right problem domain, a good LabVIEW dev can do things that would make other programmers' jaws drop.
- scottlocklin 10y ago
  LabVIEW is pretty mainstream in scientific instrument construction and control. I just wish more HN type people were exposed to it, because a well designed graphical language is unquestionably more productive than a classical programming language, at least in that problem space.
  - crispyambulance 10y ago
    Yep, and in manufacturing test applications as well. BTW, I remember you from Pitt Physics, Scott, Cheers!
    - scottlocklin 10y ago
      Hey there, mysterious Pitt alum!
- Pxtl 10y ago
  Yeah, I'm surprised the developer didn't compare their language to LabVIEW. If I were writing about a bare-metal language, I'd compare it to C, or an embedded language to Lua.

reubano 10y ago

Is there a github repo?

timthelion 10y ago

Looking at the tutorial now, and it is very intuitive. Nice ;) Edit: Too bad it hasn't been opensourced. Lack of being opensourced is a death sentence for any tool.

zitterbewegung 10y ago
Microsoft , wolfram research , mathworks would like to have a word with you .
- timthelion 10y ago
  Microsoft is currently in the process of opensourcing their TOOLs. Their tools were dying out before they did so. Actually, I didn't always believe this, I saw in the time around longhorn, that visual studio was miles ahead of anything else with its almost bugless, very fast, easy to install tools that had every library preconfigured to provide autocompletion and documentation. I was surprised that the majority of windows programmers I knew were using open source tools origionally developed for linux or the "java ecosystem" on windows. But that's the way it is now adays. And Microsoft knows it too.
  - biocomputation 10y ago
    ORLY
- DonaldFisk 10y ago
  I could do with some paid work. I have three published papers, six patents, 35 years computing experience in lots of different areas, and no job.
  - timthelion 10y ago
    Patents suck. In 90% of the cases, they cost everyone money, including the inventor. :(

Koshkin 10y ago

Of course, as it has been said, a picture is worth a thousand words, but there must be a reason why diagrammatic languages have not received the acceptance as widespread as text-based languages have. Even in "obvious" cases like microcircuit design engineers prefer text-based "hardware definition languages" over diagrams. One explanation could be that human intellect has evolved in the process of perfecting means of communication and thinking, of which a language based on symbols (words) proved to be most efficient, particularly in conveying abtractions, which is exactly where pictures, being concrete,fell short.

timthelion 10y ago
Personally, I think that drag and drop is a really bad UI for doing this sort of thing. I think that the lack of an effective means of editing graph based information has been a big reason. I think that the seccond reason, is that all of these tools have used their own, complicated serialization format, rather than using something more unixy that you could build a real ecosystem around. I'm trying to solve these problems with textgraph: http://thobbs.cz/tg/tg.html http://thobbs.cz/tg/tg.html and while the ecosystem is still in daipers, I am finding that using a simple and LIMITED file format, that can do nothing more than use text based edge lables and text based vertex contents, makes development of the ecosystem much faster than if I were to go crazy with having ecosystem features like edge collors, box vertex and arrow shapes ect.
joemi 10y ago
Max/MSP has been very successful, though it's specialized for the music/visuals world. Given the text-based alternatives in that realm (csound, supercollider), it's not surprising.
empath75 10y ago
I suspect that VR is going to open new ground here.
Pamar 10y ago
I have some experience with a visual language (webMethods, currently owned by Software AG). Guess what I miss the most when I use it? diff -c And all the rest you get with text (versioning, global search&replace, static analysys...)

analognoise 10y ago

This has popped up several times iirc, and there is nothing available to try out.

DonaldFisk 10y ago
Yet. Before I release it, I want it to be a polished product which runs reliably, and has good documentation, so that people will continue to use it after downloading it. I'm working alone, without any backing.
- empath75 10y ago
  Have you considered what a full 3D version with touch controls might look like?
- relyks 10y ago
  Full Metal Jacket seems really promising. Thanks for working on this. Have you seen Clarity? Yours looks more interesting, but it's another visual programming language: http://www.clarity-support.co.uk/products/clarity/ http://www.clarity-support.co.uk/products/clarity/ There's a book on it too: https://www.amazon.com/Drawing-Programs-Schematic-Functional-Programming/dp/1848826176/ https://www.amazon.com/Drawing-Programs-Schematic-Functional... There might some aspects that could be useful to your work.
- analognoise 10y ago
  Do you accept donations?
  - DonaldFisk 10y ago
    Donations would be very helpful of course, but I don't yet have any mechanism set up to receive them. If you or anyone wishes to make them, please first get in touch by email (my email address is on http://web.onetel.com/~hibou/index.html http://web.onetel.com/~hibou/index.html). Then, I could arrange to receive donations, perhaps via Paypal.

bgribble 10y ago

Really interesting! Much of the active "prior art" in data flow languages is in audio and music, where systems like Max/MSP [1] and Pure Data [2] have made several generations of musicians into programmers without even telling them they were programming! My long-running personal project MFP [3] looks at basically the same problem as FMJ -- visually representing data flow programs with a "real" language under the hood -- but using Python as the underlying language runtime and adopting the graphical conventions of Pure Data. Great to see interest in dataflow programming. It really is a good way to turn your programming mind inside out. [1] https://en.wikipedia.org/Max_(software) https://en.wikipedia.org/Max_(software) [2] http://puredata.info/ http://puredata.info/ [3] https://github.com/bgribble/MFP https://github.com/bgribble/MFP

deleted 10y ago
[deleted]
junke 10y ago
See also OpenMusic[1], also based on Lisp. Also related, because of the data flow approach: Faust[2]. [1] http://forumnet.ircam.fr/product/openmusic-en/ http://forumnet.ircam.fr/product/openmusic-en/ [2] http://faust.grame.fr/examples/2015/07/29/simple-faust-example.html http://faust.grame.fr/examples/2015/07/29/simple-faust-examp...

the_duke 10y ago

I would have liked to try it out, but the page has neither a download link nor a link to any source code. Not available, apparently.

timthelion 10y ago
I like sites that look like its the 90ies. What is wrong with a simple site that contains information and nothing more? Information is what we came for, not some stupid theme that someone downloaded somewhere and serves only to distract, slow down, and hinder accessability. I'm not blind or visually impaired, but I still like to use the tools built into my browser, such as the ability to enlarge text, without having a bunch of irrelevant div elements overlap eachother.
- the_duke 10y ago
  I guess http://motherfuckingwebsite.com/ http://motherfuckingwebsite.com/ applies. ;)

cs702 10y ago

This is an interesting, worthwhile project, but the headline, "text-based languages are so 20th century," struck me as naively arrogant. There are a TON of interesting '21st century' things being done with the "text-based languages" this website dismisses. BTW, that website is so 20th century.

white-flame 10y ago
And to be honest, the visual programming language fad for "actual" use was so 20th century as well. Visual programming has found a bit of a home with "programming for non-programmers" around kids'/intro stuff and some game tools.
mpbm 10y ago
I'm working on something similar and I agree with him. Writing is literally stone-age technology. It's adequate for many things, but it's only got one feature. We need something with more dimensions. There were a lot of attempts at touch-based interfaces before someone finally got it right and everyone went "Oh, that's how that's supposed to work."

akkartik 10y ago

Here's how iteration works (http://web.onetel.com/~hibou/fmj/tutorials/Iteration.html http://web.onetel.com/~hibou/fmj/tutorials/Iteration.html): "Iteration uses two special linked vertices called start+ and repeat+. The start+ vertex has an equal number of inputs and outputs. When a value is received on every input of start+, each value is output on the corresponding output. The repeat+ vertex has the same number of inputs as start+, each of which has the same type. An edge connected to an input on repeat+ really sends its values to the corresponding input on start+. So repeat+ is just an extension of start+, and has no independent existence. Its inputs can be treated as the inputs of the start+ vertex to which it is linked." Reading this, I was curious how we disambiguate nests with multiple loops. For example, at http://web.onetel.com/~hibou/fmj/tutorials/DampedHarmonicOscillator.html http://web.onetel.com/~hibou/fmj/tutorials/DampedHarmonicOsc... the repeat+ on the right is connected to data from both start+ vertices. The types too are the same for both loops. How does the software decide which one to send data to? It must be using some information that isn't visible in the figure.

DonaldFisk 10y ago
That's correct. The start+ and repeat+ vertices are linked to each other, so there's no possibility data will be sent to the wrong start+ after it is sent to a repeat+. If you hover over one, the other it's linked to is highlighted.
- nialo 10y ago
  It seems like there must be some way to indicate that a particular start+/repeat+ pair are connected, even just an edge in a different color seems like it'd be a big help.
  - DonaldFisk 10y ago
    Thanks. I decided that layout, along with being able to hover over the vertex to see the one it's connected to would be sufficient, but I'm open-minded and may indicate it some other way as well if it becomes an issue. Edge colors are a crude indication of data type, e.g. Lists are red whatever their subtype, Booleans are green, and Integers blue.

qwertyuiop924 10y ago

Fascinating, but there is a reason text-based languages have endured as long as they have. Text is universally understood: everybody knows at least how to type, and the essentials of how to read. Those constraints mean that one language can only be so different from another, making it easier to pick up multiple languages. Most importantly, text has endured. ASCII was readable 20 years ago, and it will probably be readable in some form 20 years from now. There are many standard programs that can read and write the format. Just try reading an FMJ program if you don't have the code on hand, and the repo goes 404. Have fun reverse engineering.

timthelion 10y ago
I agree. I've created an ecosystem called textgraph to address this problem: http://thobbs.cz/tg/tg.html http://thobbs.cz/tg/tg.html
SixSigma 10y ago
APL is text based. You can't represent some older programs even with Unicode. Most of the characters are now in Unicode but some have been deprecated in modern implementations because of the missing representations. https://en.wikipedia.org/wiki/APL_(codepage) https://en.wikipedia.org/wiki/APL_(codepage)
- qwertyuiop924 10y ago
  APL isn't recognizably text. Not ASCII, or really any encoding save its own. Besides, the creator of APL has solved that problem. Take a look at J & co, to see how to do APL in ASCII.
  - SixSigma 10y ago
    The point being that the singling out ASCII is survivor bias. ^ ~ | @ # * are not characters to generally be found in handwriting and not just natural inclusions in a character set.
    - 10y ago

greenspot 10y ago

> Programs are composed almost entirely with the mouse rather than keyboard Then this is not my cup of tea. I think the keyboard is still the best and most versatile interface to a computer.

WalterSear 10y ago
https://www.youtube.com/watch?v=v9kTVZiJ3Uc https://www.youtube.com/watch?v=v9kTVZiJ3Uc
- DonaldFisk 10y ago
  http://web.onetel.com/~hibou/fmj/interpreter.pdf http://web.onetel.com/~hibou/fmj/interpreter.pdf ;-)
nwrviybewir 10y ago
totally agree. Even if a good graph representation of code existed (trees diagrams of ASTs or S-Exprs) the keyboard would still be the most efficient way to navigate & edit them. Drag & drop is a rubbish system, too slow.
- DonaldFisk 10y ago
  In Full Metal Jacket, mouse gestures are minimized. It's often just right-click on an output, which opens a canvas containing methods with an input of the output's type (or moves it to the front if it's already open), drag over the vertex you want, drop it, and its input is automatically connected to the output of the vertex you right-clicked on. In any case, most programming time is spent thinking. In comparison, very little is spent typing. If that's not the case, it's a sign the language is too verbose.

kilon 10y ago

Praise text programming languages all you want and you will be correct. Programming languages used by coders are by far text based. However when you leave the coder land and when you jump to user land this turns on its head. Overwhelming rejection of text based programming languages and overwhelming embrace of visual programming languages. Every software that integrates a easy to learn scripting language like Python and Lua and later implements a visual programming language , users will pick the visual language in the vast majority of cases. A very powerful visual programming language is Unreal's Blueprints which can completely replace the C++ Api for creating games of any sophistication. As a matter of fact as I have discovered it's easier to find documentation how to implement something with blueprints than C++. It's a just a matter of time till visual programming languages overtake , text based languages because more and more apps prefer the visual coding route because this is why what the users ask. Why ? Because it's easier to learn It's easier to write, because there are no syntax or compiler errors. But mostly it's easier to have fun with. So if for an experience coder text based language is all he wants, for the user the choice is visual programming languages any day.

torkable 10y ago
[citation needed]
justinmk 10y ago
> Blueprints which can completely replace the C++ Api C++ is a rather low bar. > It's a just a matter of time ... That sets the upper limit to infinity, so it's a non-statement. > Because it's easier to learn It's easier to write, because there are no syntax or compiler errors. AST-constrained editing (e.g. lamdu[1]) will be very useful. But the lowest-common denominator cannot be "overtaken". That is why stdio is a binary stream, webapps are compiled to javascript, and programming is represented as text. Any advanced programming language that can't be represented and manipulated by ubiquitous tools will lose to one that does, so text will never--yes, never--be replaced as the common vernacular, for better or worse. To paraphrase Stephen Kell[2], Smalltalk lost because for whatever reason the people who hadn't yet "seen the light" continued to communicate and interoperate with each other. 1: http://www.lamdu.org/ http://www.lamdu.org/ 2: https://www.cl.cam.ac.uk/~srk31/research/papers/kell13operating.pdf https://www.cl.cam.ac.uk/~srk31/research/papers/kell13operat...

pipio21 10y ago

Some people say there is a reason for text being used in programming, of course there is a reason: the terminal, that evolved from the teletype, that evolved from the typing machine and morse codes. For someone to make a new system you need two things: 1- Completely rethink and redesign how things are done. 2- Modify all the tools in use today. This is the biggest part by far. The amount of work you have to do is so much that most people will just choose to continue evolving over the current system. E.g for making your own visual language you not only have to develop the language itself, but make the compiler also visual, and the debugger also visual, but the tools you could modify, like llvm are text based and terminal based. Modifying llvm for it is hell. And consider yourself lucky if you have to modify llvm, because in the past it was gdb with monolithic design and no libraries. An example of a redesign was Xerox PARC GUI. Instead of one input-one output development system in the terminal they added 20 or 30 inputs and 20 or 30 outputs. For this they had to use a new programming concept, so they had to use object oriented programming(without it handling 20 inputs-outputs at the same time becomes so hard it is in practice impossible), that at the same time forced them to develop their own tools in order to see object oriented data structures and methods. Any modern UI development inherits from Xerox design. Another paradigm change was the Iphone: it forced every smartphone to have hardware acceleration video and touchscreen and used it as input methods. People like Bret Victor and MathBox creator are trying to redesign the whole concept using new tools like GPU programming and video displays. I agree with them. The current system is so wrong , even when it is the only thing we have.

bunderbunder 10y ago
It's not just about VT100s. It's that text is far and away the go-to format for recording any information that's abstract or has narrative structure. It has been for a very long time. There are graphical techniques, but they all work in very specific and limited domains. In the wild, even flowcharts that aren't meant to represent a process that has dynamic state are frequently tagged with annotations for explaining important details that are difficult or impossible to convey within the strictures of a flowchart's graphical language. That's not to say that the idea of a visual programming language is not intriguing, or that it's a waste of time to explore them. But the reasons why it's an uphill battle go far beyond mere inertia.

gavinpc 10y ago

Where's the data? A "data flow language" that only visualizes functions isn't. IMHO. I agree with most of the perennial discussion that takes place here for all of these projects: text is good, but not for everything and everyone, yet graphical programming has never taken off... why? Because if people want a data flow, they care more about the data than the flow. Spreadsheets have secured a rock-solid place in the "lingua franca" of userland, without ever visualizing the "connections," which are seldom enlightening. I would not criticize something for failing to achieve what it doesn't attempt, and FMJ may be fantastic for developing logic. But it calls itself a "visual dataflow language," and I'm not seeing any data. (Yes, code is data in lisp, that's not what I mean.) To visualize code is to focus on the means to the end. I would respectfully disagree that "21st-century" programming will resemble the static modelling of systems represented by code in whatever form. Systems will be "live" as a rule. And that is what will improve the lives of programmers. Remember that "interactive computing" was once a radical idea, the realization of which required people to spend their lives and resources fighting for it (Licklider, Englebart, and Bob Taylor et al, to name a few). Well, if you feel any resistance to the idea of relinquishing your rinse-and-repeat development cycle, I have two words for you: punch cards. I hope I am not trolling here. Just this month I've been "sniped" by a data flow side-project that has me thinking about these things, and I'm extremely interested in how other people approach the subject (and their discussions here). edit grammar, wording

DonaldFisk 10y ago
You certainly aren't trolling, and your point is valid. Directed graphs are the most general data structure, and the language is homoiconic. So data definitely will be represented graphically: not just directed graphs, but other structures such as arrays. But there's only one of me, and if I'd done this already, something else wouldn't have got done. However, it is high on my agenda, and will be done soon.
rjurney 10y ago
PigPen had this right... it visualized syntax that you typed. You could technically code with the mouse but that wasn't the intention of the tool. It made it easier to get a gestalt view of things, without hiding the essential details of operations. It was just another window into your code in Eclipse. I think Microsoft's IDE has similar stuff for OO code? But I've never used it. https://wiki.apache.org/pig/PigPen https://wiki.apache.org/pig/PigPen I tried to commercialize this technology in 2010, with Cloud Stenography (a joke name): https://github.com/rjurney/Cloud-Stenography https://github.com/rjurney/Cloud-Stenography https://vimeo.com/6032078 https://vimeo.com/6032078 More recently, a company has done some similar stuff, albeit for Spark, in Seahorse: http://seahorse.deepsense.io/ http://seahorse.deepsense.io/

happyslobro 10y ago

Visual languages have been superseded by abstract symbolic languages time and again throughout history. I don't really feel qualified to determine whether or not visual general purpose programming languages could work or not, but I do think that anyone who is pursuing that goal needs to start by figuring out why natural languages progressed from visual to symbolic. Demonstrating that programming languages could progress in the other direction would probably be the primary goal of their endeavour, and when they present their work, it should probably focus on examples of idioms that are easy to express visually, but difficult to express in text form. I am not convinced that those idioms even exist; but then, since I have never used a visual programming language. It could be that I am simply incapable of contemplating them, in my current frame of mind.

jrapdx3 10y ago

This is vaguely reminiscent of Drakon, which has been around a long time, but AFAIK hasn't made much of a dent in the programming world, at least outside of Russia. A couple of years ago I was trying to do something with the visual language but can't say I successfully mastered it. Interesting to me is that the Drakon editor was implemented in Tcl/Tk, a language I'm quite familiar with. I regard Tcl as a dialect of Lisp, which I've also used a fair amount, at least in the guise of Scheme. As I'm not at all familiar with this new language can't say too much about it, though implementation in Lisp might be a plus. One issue with it, as with other efforts in this domain, may be that it's not as intuitive or obvious as its authors believe. IOW, in my admittedly limited experience with visual programming, there's more of a learning curve than advertised. Visual "syntax" is sufficiently different from conventional text-based forms that people have learned to use, often at the cost of great effort and time. Translating the thought process to a visual metaphor isn't intuitive or easy as I've attempted to learn it. What's odd is that I have ability and a fair amount of success in the visual art of printmaking, which one could say is an expression of a visual language itself, but one that doesn't map well at all to the visual coding of computer programs. No reason to think it necessarily would, but the observation points to an apparent multiplicity of "visual modes" embedded in our brains.

jiyinyiyong 10y ago

Similar idea here but I think we can not do that before VR is poopular. But a text-look form fits the first decades of 21th centry better https://www.youtube.com/playlist?list=PLyvBXLgHYHy1AIK6i5uw3_H5BIUP4CQx6 https://www.youtube.com/playlist?list=PLyvBXLgHYHy1AIK6i5uw3...

jiyinyiyong 10y ago

OrthoMetaPara 10y ago

A couple of suggestions: 1. It reminds me of the graphical view that is present in the IDA disassembler in which functions are broken into "boxes" wherever there is a jump in control flow. If you're disassembling a C function, for example, this generally means that a box corresponds to some block of code that is delimited by curly braces. The point here is that you don't have a box for every single assembly instruction, because that would be ridiculous. Rather, the function is broken down into several "clauses" that express complex ideas, and then each clause is described textually by several lines of code. For example, if I want to express something like: (lambda (x y) (/ (* 2 x) (+ x y))) then it would be nice if I could draw a box with input terminals for x and y and then type in the expression, rather than having to create three boxes for each arithmetic operation. It would be faster to program this way, and the result would easier to read. 2. Also, drawing inspiration from IDA's visual mode (as well as electronic circuit diagrams), lines should all travel at right angles. There should also be an auto layout mode which attempts to layout the graph so that there are a minimum number of edge crossings.