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

21–30 of 65 posts

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

#21

Post by tinco »

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…

In reality though, you will end up either defining a namespace (and a separate file!) for every struct you define, or prefixing your accessor functions with the name of the struct. I do the latter, but I'm not happy about it at all...

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

#22

Post by educating »

Going to try to address the whole problem here, not just the trying to invent a new language:

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.

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

#23

Post by beagle3 »

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.

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}
Which looks like line noise, but basically encodes the following operations:

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.

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

#24

Post by TheZenPsycho »

educating wrote: post #22

Going to try to address the whole problem here, not just the trying to invent a new language: 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 complic…

What's wrong with inventing a new language? Nobody has to use it. Do they? Or is he staking some vast amount of his personal reputation on it? some how?

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

#25

Post by vilya »

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…

There's also Orc: http://orc.csres.utexas.edu/

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.

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

#26

Post by jacquesm »

beagle3 wrote: post #23

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. 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} Which looks like line noise, but basically encodes the following operations: x is the input…

Does K have any APL roots by chance?

edit: ignore the question, yes it does:

http://en.wikipedia.org/wiki/K_%28programming_language%29

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

#27

Post by educating »

TheZenPsycho wrote: post #24
educating wrote: post #22

Going to try to address the whole problem here, not just the trying to invent a new language: 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 complic…

What's wrong with inventing a new language? Nobody has to use it. Do they? Or is he staking some vast amount of his personal reputation on it? some how?

I'm suggesting the combination of possible health problems combined with a pattern of trying to reinvent everything. I'm familiar with this pattern myself. I'm suggesting not to go down this road, and instead focus those creative efforts on something with more promise.

I also think that there are problems with all other languages we use, but like I said, this is a very difficult road.

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

#28

Post by mercurial »

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…

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

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

#29

Post by d0m »

beagle3 wrote: post #23

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. 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} Which looks like line noise, but basically encodes the following operations: x is the input…

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

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

#30

Post by TheZenPsycho »

educating wrote: post #27
TheZenPsycho wrote: post #24

Earlier quoted context omitted.

What's wrong with inventing a new language? Nobody has to use it. Do they? Or is he staking some vast amount of his personal reputation on it? some how?

I'm suggesting the combination of possible health problems combined with a pattern of trying to reinvent everything. I'm familiar with this pattern myself. I'm suggesting not to go down this road, and instead focus those creative efforts on something with more promise. I also think that there are problems with all other languages we use, but like I said, this is a very difficult road.

I'm confused. Are you his mom or what? Why shouldn't he go down this road?
Post reply on HN