Hacker News Reader

Comment by mercurial | Hacker News Reader

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

View on HN

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.

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

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.

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.

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

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

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"

Reply on news.ycombinator.com