Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Big Programming, Small Programming – Glow, the language

fendrich.se

Post reply on HN
Print view View original

11–20 of 65 posts

Re: Big Programming, Small Programming – Glow, the language

#11

Post by daivd »

z3phyr wrote: post #3

As far as I know, a language called GlowScript (compiles to js) exists. 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... :)

Dammit.. I checked to see that Glow was not taken :). Almost every name, that is not an outright racial slur is already used. Still, Java and Javascript are completely different languages and that has never lead to much confusion..

Re: Big Programming, Small Programming – Glow, the language

#13

Post by drothlis » 

    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.
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: https://vimeo.com/27850933 ).

    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)
"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".

Re: Big Programming, Small Programming – Glow, the language

#14

Post by quarterto »

daivd wrote: post #11
z3phyr wrote: post #3

As far as I know, a language called GlowScript (compiles to js) exists. 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... :)

Dammit.. I checked to see that Glow was not taken :). Almost every name, that is not an outright racial slur is already used. Still, Java and Javascript are completely different languages and that has never lead to much confusion..

  Still, Java and Javascript are completely different languages and that has never lead to much confusion..
Not within the tech world, sure, but ask say a recruiter and it's a coin toss.

Re: Big Programming, Small Programming – Glow, the language

#15

Post by jamii »

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.

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

Re: Big Programming, Small Programming – Glow, the language

#16

Post by shailesh »

Sounds pretty cool!

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.

Re: Big Programming, Small Programming – Glow, the language

#17

Post by pestaa »

mercurial wrote: post #10
pestaa wrote: post #6

Earlier quoted context omitted.

Names, unless namespaced, collide in every language.

Sure, but having a receiver avoids collisions for accessors. I'll illustrate the point below. 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' whic…

So you write `foo.bar` in Python and `O.bar foo` in Haskell, and you find the former satisfactory but the latter an ugly design mistake? Honestly it doesn't even look that much more typing; and (subjectively!) has a little better semantics, e.g. you can say that bar is a function with the type `Foo -> String`.

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.

Re: Big Programming, Small Programming – Glow, the language

#18

Post by gjm11 »

pestaa wrote: post #17
mercurial wrote: post #10

Earlier quoted context omitted.

Sure, but having a receiver avoids collisions for accessors. I'll illustrate the point below. 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' whic…

So you write `foo.bar` in Python and `O.bar foo` in Haskell, and you find the former satisfactory but the latter an ugly design mistake? Honestly it doesn't even look that much more typing; and (subjectively!) has a little better semantics, e.g. you can say that bar is a function with the type `Foo -> String`. One advantage I'll admit is that in Haskell you have to actively watch out for ambiguities and refactor coll…

Unless you're happy giving all your imports single-letter names (why hello, BASIC circa 1970!) it's more like: foo.bar in Python, OtherModule.bar foo in Haskell. That does seem like quite a lot more typing.

Re: Big Programming, Small Programming – Glow, the language

#20

Post by [deleted] »

pestaa wrote: post #17
mercurial wrote: post #10

Earlier quoted context omitted.

Sure, but having a receiver avoids collisions for accessors. I'll illustrate the point below. 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' whic…

So you write `foo.bar` in Python and `O.bar foo` in Haskell, and you find the former satisfactory but the latter an ugly design mistake? Honestly it doesn't even look that much more typing; and (subjectively!) has a little better semantics, e.g. you can say that bar is a function with the type `Foo -> String`. One advantage I'll admit is that in Haskell you have to actively watch out for ambiguities and refactor coll…

[deleted]
Post reply on HN