Some related projects:
Opis - http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.167.... - pure functions connected by dataflow combinators (with time travel debugging and model checking at the dataflow level)
Bloom - http://www.bloom-lang.net/ - temporal logic for coordination, message passing for communication with stateful endpoints
Flask - http://dash.harvard.edu/handle/1/2797447 - a c-like language for local sensor computations with a haskell dsl for specifying communication patterns across the sensor network
Then of course there is all the FRP work (eg http://www.haskell.org/haskellwiki/Functional_Reactive_Progr... http://docs.racket-lang.org/frtime/)
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?
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 - http://www.mozart-oz.org/features.html
Regarding "not taking off": this model is actually very common in the vfx industry. Most high-end content creation tools (Nuke, Maya, Houdini, etc) have a node graph which you assemble in the tool, where the nodes define processing operations & are usually plugins written in c++ or something like it. It's not a language per-se and the semantics are tightly bound to the individual tools rather than being independently specified, but the underlying idea is the same.
Probably few people know but Microsoft Excel has some optimizations like "multithreaded recalculation" http://msdn.microsoft.com/en-us/library/office/bb687899.aspx and "high-performance Excel based applications in financial services" http://msdn.microsoft.com/en-us/library/bb887539.aspx
I included extra resources at the end of my articles on the subject: http://blog.databigbang.com/category/egont/
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:
{(x@&~m),'(+/m)@&~m:~':x}
x is the input
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")
Then take the sum of match (+/m) at where (@&) there is no match (~m).
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.
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.
And .. the result is usually quick, thanks to vectorizing (and can go on a GPU easily).
A language that promotes item-at-a-time processing is missing a lot.
edit: ignore the question, yes it does:
Since you're pretty much at design stage, two ideas are worth exploring:
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."
2. The Shen lanaguage http://shenlanguage.org/
Clearly, these may not map directly to the features in the final design, but the ideas they cross-pollinate will be very useful.
This need to exist. This has to exist.
I promise not to make the Haskell struct mistake.
In a typical OO language, eg, Python, you'd do:
class Foo(object):
def __init__(self, bar):
self.bar = bar
foo = Foo("bar")
# prints 'bar'
print foo.bar
data Foo = Foo { bar :: String }
main = do
let foo = Foo "bar"
-- prints 'bar'
putStrLn (bar foo)
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.
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)
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:
http://www.jpaulmorrison.com/fbp/
You can find links to several existing implementations of flow-based programming on Wikipedia:
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?
I think switching the usual meaning of = and == will be confusing. O'Caml uses = and == for deep and shallow comparison respectively and <- for assignment. That is a possibility.
[2] http://www.scribd.com/doc/167971960/Modeling-Reactive-System...
from: http://fendrich.se/blog/2013/01/24/pre-programming-mental-si...
> I am, in fact, a grumpy, skeptical, philosophically materialist atheist.
from: http://fendrich.se/blog/2013/04/09/a-better-soylent-good/
> 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.
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.
I also think that there are problems with all other languages we use, but like I said, this is a very difficult road.
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 :)
BTW, this project looks great. I'll keep an eye on it... :)
Still, Java and Javascript are completely different languages and that has never lead to much confusion..
Have you tried seeing how a full dependent type system could be used in your design?
Not exactly dependent types, but practical, I think.
There's a learning curve; it's steep, but it is well worth it - much like Math notation (give me "x^n" any day over "repeat multiplying x by itself n times") or Music notation, once you're used to it, any notation that is less concise seems arbitrarily and needlessly verbose.
(That's actually a reason not to learn K / APL: When you actually grok it, it's hard to take modern software engineering seriously. A reason to grok them is that -- for some problems -- you're going to become much more productive).
i.e. if you want it to go away from altruistic concern, you're probably better off addressing the flaws in the concept or ignoring it. ^_^;
What I can say however is that there's a difference between conciseness in writing and productivity in reading.
For instance,
(!R)@&{&/x!/:2_!x}'!R
That being said, I really like the functional aspect of it where most of common operations on list were shortened. (I.e. map, reduce, etc.)
Personally, I think the Arc language strikes a really fine balance of verbose versus concise. It's just unfortunate that there's not a more active community and that it lacks the battery to be productive with it.
Once you've done that, the theory is that it is actually quicker and easier to grasp than reading "verbose" lines of code.
That said, I've never taken the time to invest in an APL style language, so I can't speak to whether it is actually true or not.
One advantage I'll admit is that in Haskell you have to actively watch out for ambiguities and refactor colliding types to import as qualified.
O.bar foo doesn't look that bad, does it? Sure. Except when you have nested data structures. And you very often have nested data structures. Not to mention that I'm not about to split my data definitions into 50 different modules when working with a database. You know, these pesky things things which so often have a field called "id"...
So instead of the language doing for you, you get to do "namespacing" yourself by prefixing your fields by an abbreviated version of your data type name.
Take it from someone who has seen both sides: the concision is a good, good thing.
However, you still run into the same namespacing issue we talked about, because at the end of the day, lenses are a bit of wonderful magic on top of the existing, crummy record system.
You'd create a Lens like so (with Control.Lens):
-- You're supposed to prefix by _ due to Template Haskell magic following, but it's still a plain record, namespacing issues and all
data Foo = Foo { _bar :: String }
-- TH magic making lenses for all fields
makeLenses ''Foo
-- prints 'bar'
putStrLn (foo^.bar)
-- creates a copy of 'foo' with 'bar' set to 'barbar'
let foo' = foo & bar .~ "barbar"