This idea - having locally unrestricted components connected by a restricted, declarative system - seems to keep popping up and never quite taking off. Hopefully sooner or later someone will spin it just right.<p>Some related projects:<p>Opis - <a href="http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.167.5260" rel="nofollow">http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.167....</a> - pure functions connected by dataflow combinators (with time travel debugging and model checking at the dataflow level)<p>Bloom - <a href="http://www.bloom-lang.net/" rel="nofollow">http://www.bloom-lang.net/</a> - temporal logic for coordination, message passing for communication with stateful endpoints<p>Flask - <a href="http://dash.harvard.edu/handle/1/2797447" rel="nofollow">http://dash.harvard.edu/handle/1/2797447</a> - a c-like language for local sensor computations with a haskell dsl for specifying communication patterns across the sensor network<p>Then of course there is all the FRP work (eg <a href="http://www.haskell.org/haskellwiki/Functional_Reactive_Programming" rel="nofollow">http://www.haskell.org/haskellwiki/Functional_Reactive_Progr...</a> <a href="http://docs.racket-lang.org/frtime/" rel="nofollow">http://docs.racket-lang.org/frtime/</a>)<p>Despite all the interest, overlog (the predecessor to bloom) is the only language I've seen so far that has any convincing demos (hdfs and hadoop in 8kloc). I'd love to know if anyone is actually using this sort of stuff in production or, if not, why not? What goes wrong when you try to scale this up?<p>EDIT: I forgot to mention Mozart/Oz, one of the most interesting dataflow languages and one that explicitly talks about layering progressively less and less deterministic systems of concurrency - <a href="http://www.mozart-oz.org/features.html" rel="nofollow">http://www.mozart-oz.org/features.html</a>
It's a nice idea, but the run-length example is kind-of-misguided, even though that's how everyone would implement it on first try.<p>A language should push you towards a more robust/faster/simpler solution by making it the simple, elegant thing to do. In K, a run length encoder would be something like:<p><pre><code> {(x@&~m),'(+/m)@&~m:~':x}
</code></pre>
Which looks like line noise, but basically encodes the following operations:<p>x is the input<p>m gets 1 where a position in x is the same as the previous position, 0 where it isn't. (apply ': "each-pair" to ~ "match")<p>Then take the sum of match (+/m) at where (@&) there is no match (~m).<p>Finally, add that to x where there is no match (x@&~m, literally, "x at where no m"), and zip it (,' meaning concat each). And the curly brances make it into a function of x.<p>Now, I understand most people would think that this is unreasonable. However, in K it is easier to produce a vectorized solution than an itertive one - and as an added bonus, the bugs tend to be either of the "wrong spec" or the "off by one" error, eliminating whole classes of potential bugs.<p>And .. the result is usually quick, thanks to vectorizing (and can go on a GPU easily).<p>A language that promotes item-at-a-time processing is missing a lot.
Sounds pretty cool!<p>Since you're pretty much at design stage, two ideas are worth exploring:<p>1. Uniqueness typing (re: linear typing for mutable data) is a neat addition. The paper by John van Groningen et al seems the most appropriate: "Exchanging Sources Between Clean and Haskell: A Double-Edged Front End for the Clean Compiler."<p>2. The Shen lanaguage
<a href="http://shenlanguage.org/" rel="nofollow">http://shenlanguage.org/</a><p>Clearly, these may not map directly to the features in the final design, but the ideas they cross-pollinate will be very useful.
This looks absolutely fantastic. Well, the whole visual programming thing leaves me cold, but the rest looks great. I'd be curious to see how data structures are supposed to look like. I assume they're some kind of structs (hopefully not featuring ridiculous name collisions like Haskell).
<p><pre><code> In the big picture, visual programming is very natural. It is, in fact,
so natural that we often make flowcharts of how systems work. It would
be better if these flowcharts would actually be the system, rather than
an incomplete, possibly outdated description.
In the details, visual programming is just an inconvenient gimmick.
IMHO. It may change one day.
</code></pre>
Not exactly the same, but it reminds me of Smalltalk environments, which
give you a "browser" to view classes, inheritance relationships, etc
etc. while giving you a code editor for the actual method
implementations (example: <a href="https://vimeo.com/27850933" rel="nofollow">https://vimeo.com/27850933</a> ).<p><pre><code> We use two types of files to program Glow. The detail files, which can
contain anything, and the overview files, which may only contain
constants and how components are connected to each other. An overview
file may not use macros.
Both are editable with any text editor, but the overview file can also
be edited visually as a vectorized flowchart (vectorized to zoom in on
details)
</code></pre>
"Both are editable with any text editor" sounds much better (to me with
my admittedly limited experience with Smalltalk) than Smalltalk's
file-less model where everything is a change to the whole system
"image".
This looks great, and I encourage you to keep working on it and make this a reality. I've thought along the same lines and I think a language like this has real potential.<p>I'm pretty surprised I haven't seen J. Paul Morrison's "Flow-Based Programming" mentioned anywhere in the post or these comments. I first read this book years ago as a undergrad and it made a big impact on me. It discusses ideas very similar to the ones proposed for Glow. You can read it free online here:<p><a href="http://www.jpaulmorrison.com/fbp/" rel="nofollow">http://www.jpaulmorrison.com/fbp/</a><p>You can find links to several existing implementations of flow-based programming on Wikipedia:<p><a href="http://en.wikipedia.org/wiki/Flow-based_programming" rel="nofollow">http://en.wikipedia.org/wiki/Flow-based_programming</a>
The syntax looks very pretty, but why the colons at the end of block header statements? Python does this too, but I see no reason for it. In my opinion that makes it look a bit cluttered, contrast it for example with the (excellent) coffeescript syntax.
If the syntax ends up being a great match for your ideas, I've got a lot to look forward to! Syntax is a big aspect of how much or little I enjoy working with a language. I'm hoping for something Python-ish in terms of simplicity and readability, but I think there's room to improve upon even that.<p>I'm very happy to not see much redundant punctuation where formatting makes meaning clear, and to not see keywords where punctuation makes meaning clear. But since mutability is being deemphasized, maybe we can even get a single equals for equality, and give assignment the longer symbol?
The concurrency features strike me as being influenced strongly by Hoare's CSP[1]. The flowchart like interface seems akin to Harel's reactive diagramming formalisms[2].<p>[1] <a href="http://www.usingcsp.com/" rel="nofollow">http://www.usingcsp.com/</a><p>[2] <a href="http://www.scribd.com/doc/167971960/Modeling-Reactive-Systems-With-Statecharts" rel="nofollow">http://www.scribd.com/doc/167971960/Modeling-Reactive-System...</a>
Going to try to address the whole problem here, not just the trying to invent a new language:<p>from: <a href="http://fendrich.se/blog/2013/01/24/pre-programming-mental-silence-meditation-with-entrainment/" rel="nofollow">http://fendrich.se/blog/2013/01/24/pre-programming-mental-si...</a><p>> I am, in fact, a grumpy, skeptical, philosophically materialist atheist.<p>from: <a href="http://fendrich.se/blog/2013/04/09/a-better-soylent-good/" rel="nofollow">http://fendrich.se/blog/2013/04/09/a-better-soylent-good/</a><p>> Adding nootropics and stimulants, like the original Soylent guy did, is also interesting. However, to avoid complicating things, I will add this later. I don’t really know which substances, but at least ginkgo biloba.<p>I think you are taking on too much risk in order to get attention. Your grumpyness might be a result of some other health condition like sleep apnea that you need to take care of before taking on a radical diet that will leave you sick and more overweight. Take the time you would have spent working on Glow instead working on an existing up-and-coming language like Go. And, good luck. I know what its like to feel like you will try anything to fix your life and get relevant. But inventing a new language is not where its at. Tom Hickey who is one of the smartest people I know and one of the best presenters I've seen can't even convince most to use Clojure. It isn't easy.
As far as I know, a language called GlowScript (compiles to js) exists.<p>The language author might consider changing its name to something unique, like 'StarLight' or something so as to avoid name controversy, and achieve maximum popularity :)<p>BTW, this project looks great. I'll keep an eye on it... :)
This looks awesome! I will be interested to see how well you can make the features fit together. I have been really interested in languages that give you tools for reasoning at multiple levels of abstraction.<p>Have you tried seeing how a full dependent type system could be used in your design?
So yet another flow-based language/framework? NoFlo is another recent one. Component-based is a very common modern game programming approach BTW. Google for "component entity system". It's a very cool hobby project but will not get wide traction I'm afraid...