Live data from Hacker News

Big Programming, Small Programming – Glow, the language

fendrich.se

31–40 of 65 posts

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

#31
post #29
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.

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

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

#32
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…

Quartz Composer?

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

#33

Earlier quoted context omitted.

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?

If you want me to be blunt, I think he is incapable of it, and he is wasting all of our time with a "what if" post about a language that will never exist. Happy now?

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

#34
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…

From ancient history (although explicitly based on Hoare's CSP) there was Occam for the Transputer.

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

#35
post #11
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..

When faced with a JS problem in a SPA - around 6 years ago - I had a representative from a client say me "wait, I will install the latest JAVA and see if that fixes it". He even chose the jdk to be safe.

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

#36
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…

I do like an expressive high-level encoding like that, but 1) I just needed a silly example to show what pipes are. In practice you would probably use higher-order library functions (or components) like group for the same thing. 2) In my experience, very compressed expressions can be hard to modify in certain directions. Practical stuff like printing, logging or storing progress every X seconds, which is a small modification in a for-loop, can be a hassle.

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

#37

Earlier quoted context omitted.

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

If you want me to be blunt, I think he is incapable of it, and he is wasting all of our time with a "what if" post about a language that will never exist. Happy now?

That's already a sunk cost to everyone in the thread. Further criticism - that doesn't address the reasons people are enthused, serves as a time-sink for no return in value.

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. ^_^;

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

#38

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…

1. Yes, the linear typing for mutable data is inspired by Clean. 2. I look at Shen from time to time. It looks nice, but I have never gotten around to play with it.

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

#39
post #17

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

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.

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

#40
post #18
post #17

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

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.
Post reply on HN