Big Programming, Small Programming – Glow, the language
1–10 of 65 posts
Re: Big Programming, Small Programming – Glow, the language
#2This need to exist. This has to exist.
Re: Big Programming, Small Programming – Glow, the language
#3The 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... :)
Re: Big Programming, Small Programming – Glow, the language
#4Re: Big Programming, Small Programming – Glow, the language
#5Re: Big Programming, Small Programming – Glow, the language
#6This 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).
Re: Big Programming, Small Programming – Glow, the language
#7[2] http://www.scribd.com/doc/167971960/Modeling-Reactive-System...
Re: Big Programming, Small Programming – Glow, the language
#8This 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).
I promise not to make the Haskell struct mistake.
Re: Big Programming, Small Programming – Glow, the language
#9The 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]. [1] http://www.usingcsp.com/ [2] http://www.scribd.com/doc/167971960/Modeling-Reactive-System...
Re: Big Programming, Small Programming – Glow, the language
#10This 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).
Names, unless namespaced, collide in every language.
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
In Haskell: data Foo = Foo { bar :: String }
main = do
let foo = Foo "bar"
-- prints 'bar'
putStrLn (bar foo)
Here, you can see that Haskell generates an accessor 'bar' which is a top-level function. Which means that if you can't have two records with a 'bar' field in the same module. You can have a 'bar' field in a different module, but then you need to a qualified import (import qualified OtherModule as O) in order to work around the conflict (forcing you to type ugly O.bar every time you need the 'bar' accessor from OtherModule). So you end up putting prefixes everywhere, something which in my opinion is a design mistake.