5 ms·

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 ar

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

pestaa 13y ago
Names, unless namespaced, collide in every language.
- mercurial 13y ago
  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.
  - pestaa 13y ago
    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.
    - gjm11 13y ago
      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.
      - pestaa 13y ago
        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.
        mercurial 13y ago
        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.
    - deleted 13y ago
      [deleted]
    - tinco 13y ago
      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...
    - mercurial 13y ago
      > 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.
daivd 13y ago
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 http://vimeo.com/71278954 and "Inventing on principle" http://vimeo.com/36579366 http://vimeo.com/36579366, I highly recommend it. I promise not to make the Haskell struct mistake.
- mercurial 13y ago
  I'll try and find time for it. Thanks for the recommendation.

pestaa 13y ago

Names, unless namespaced, collide in every language.

mercurial 13y ago
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.
- pestaa 13y ago
  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.
  - gjm11 13y ago
    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.
    - pestaa 13y ago
      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.
      - mercurial 13y ago
        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.
  - deleted 13y ago
    [deleted]
  - tinco 13y ago
    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...
  - mercurial 13y ago
    > 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.

daivd 13y ago

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 http://vimeo.com/71278954 and "Inventing on principle" http://vimeo.com/36579366 http://vimeo.com/36579366, I highly recommend it. I promise not to make the Haskell struct mistake.

mercurial 13y ago
I'll try and find time for it. Thanks for the recommendation.