4 ms·

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 repres

by 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.

by Pxtl 10y ago

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.