Big Programming, Small Programming – Glow, the language • Hacker News Board

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

#41

Post by d0m » Tue, Sep 17, 2013, 12:36 PM UTC

beagle3 wrote: post #31

d0m wrote: post #29

Earlier quoted context omitted.

As intriguing as it looks, I certainly wouldn't want to look at that kind of code all they long.

I can understand the sentiment, and the only thing I can say is: 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'…

Well, after writing my comment, I went online looking for some quick introduction to the language. I'll admit that there are certainly very interesting facets to that language.

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

It's very concise but very hard to grasp quickly. The equivalent, in even 10 lines of code, might be way easier /and/ faster to read and understand.

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.

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

#42

Post by josephlord » Tue, Sep 17, 2013, 12:41 PM UTC

jamii wrote: post #15

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 l…

Also http://www.kamaelia.org/Home.html developed by BBC R&D using Python. It seems to have been quiet for a while now though.

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

#43

Post by ajanuary » Tue, Sep 17, 2013, 12:42 PM UTC

d0m wrote: post #41

beagle3 wrote: post #31

Earlier quoted context omitted.

I can understand the sentiment, and the only thing I can say is: 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'…

Well, after writing my comment, I went online looking for some quick introduction to the language. I'll admit that there are certainly very interesting facets to that language. 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 It's very concise but very hard to grasp quickly. The equivalent, in even 10 lines of code, mig…

My understanding of the idea behind most APL style languages is that it's an expert language, in that you need to take the time to invest in it just like a musician would musical notation.

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.

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

#44

Post by daivd » Tue, Sep 17, 2013, 1:04 PM UTC

jamii wrote: post #15

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 l…

Thanks for the list of related projects!

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

#45

Post by mercurial » Tue, Sep 17, 2013, 1:07 PM UTC

pestaa wrote: post #39

mercurial wrote: post #28

Earlier quoted context omitted.

> 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`. O.bar foo doesn't look that bad, does it? Sure. Except when you have nested data structures. And you very…

This is a very fair criticism, and I believe lenses are the solution to this problem, although I'm not advanced enough in Haskell to provide a round counterargument.

Lenses are amazing. However, they don't solve this issue. What they do is let you pack a getter and a setter in a single "data type" and do operation on them. Say you have a School record with a students field (a list of Student records). You can write a one-liner which, given a School, lets you access only those students with a name starting by 'a'. Or even better, lets you return a copy of School where only those aforementioned students get their grades doubled.

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

Now you have a 'bar' lens:

  -- prints 'bar'
  putStrLn (foo^.bar)
  -- creates a copy of 'foo' with 'bar' set to 'barbar'
  let foo' = foo & bar .~ "barbar"

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

#46

Post by mercurial » Tue, Sep 17, 2013, 1:12 PM UTC

pestaa wrote: post #40

gjm11 wrote: post #18

Earlier quoted context omitted.

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.

I usually see Data.Map to imported as M, Text.ByteString as BS, etc. If you need more than a couple of these, I'd say it is a red flag and that the code needs to be split up.

It's in my experience much easier to avoid accidental namespace clashes with functions than with accessors (though some modules are intended to be imported qualified). If you need to model a real-world problem, you run into record namespace clashes very easily.

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

#47

Post by wslh » Tue, Sep 17, 2013, 1:16 PM UTC

jamii wrote: post #15

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 l…

Weird that nobody mentioned spreadsheets until now... spreadsheets are one of the possible data flow implementations.

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/

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

#48

Post by mercurial » Tue, Sep 17, 2013, 1:41 PM UTC

daivd wrote: post #8

mercurial wrote: post #5

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

Visual programming used to leave me completely cold, but with the emergence of tablets and the promise not to make _everything_ visual, I hope to convince people otherwise. If you have not seen Bret Victor's brilliant "Future of programming" http://vimeo.com/71278954 and "Inventing on principle" http://vimeo.com/36579366 , I highly recommend it. I promise not to make the Haskell struct mistake.

I'll try and find time for it. Thanks for the recommendation.

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

#49

Post by mej10 » Tue, Sep 17, 2013, 1:52 PM UTC

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.

Have you tried seeing how a full dependent type system could be used in your design?

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

#50

Post by CmonDev » Tue, Sep 17, 2013, 2:00 PM UTC

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