3 ms·

I don't know that you'll be able to sell a programmer that has stuck with C on Haskell. The ability to look at code and have a rough idea of what the assembly

I don't know that you'll be able to sell a programmer that has stuck with C on Haskell. The ability to look at code and have a rough idea of what the assembly will look like is, in my opinion, fairly high up on the list of desired features. Haskell does ... not really provide that. And as for greppability, it has become very common now to use keywords, which were very common once upon a time but went out of favor with Algol, so that you get declarations like "fn isValidPass(...)" to make grepping even easier. And easy grepping also means easy parsing, which works both for machines and for humans when you're trying to digest unfamiliar code.

jolmg 8y ago
> I don't know that you'll be able to sell a programmer that has stuck with C on Haskell. The ability to look at code and have a rough idea of what the assembly will look like is, in my opinion, fairly high up on the list of desired features. Haskell does ... not really provide that. I'm not trying to sell Haskell to C developers, though, I was just replying to the GP's disbelief at a syntax preference for having types on the right. Also, I don't think the ability you mention has anything to do with the choice of syntax of having types on the left or the right. I do very much wonder if there are any benefits, at all, of having the types on the left. EDIT: On re-reading my above comment, I guess I was selling it a little, but I only meant to justify having complex looking types. :P
- andrewla 8y ago
  The notion of types as type assertions is relatively new to C, and its syntax reflects that. Types in C are more storage specifications than they are type assertions. When you declare an “int”, you’re not declaring a variable of type int per se; you’re declaring and int-sized hole where you can put values. So the declaration on the left [ed: Was right] makes a certain amount of sense - you’re declaring an int, so that’s what you lead with. When you declare a “string” you have to think about how the string is stored; and that implementation detail bleeds into the syntax. A C has matured the notion of incompatible types has seeped into the language to the point where now it becomes a little annoying that I can just go ahead and pass an int into a function that expects a typedef’d “type”; libraries often wrap them in very lightweight structs just to get an additional bit of typechecking. The expectations for what kind of errors the compiler can catch have grown over time but the language has only made small concessions.
  - jolmg 8y ago
    > the declaration on the right makes a certain amount of sense - you’re declaring an int, so that’s what you lead with. I'm sorry, but that doesn't make sense to me. You say it as if it's the only sensible way to design a declaration syntax, but Haskell (and other languages) did it the other way just fine. I don't see how the differences in semantics between the 2 type systems give rise to a benefit in having the type expressed on the left. If the design came to be decided like that, it seems it's simply not something that was put much thought over. That's fine too, since the limitations of the type system do not give rise to cases where this syntax choice becomes too big of an inconvenience. Still, no benefits as far as I can see. Maybe it simply appealed to the designer's intuition more. Choosing because of that indicates that the choice was pretty arbitrary, though.
    - andrewla 8y ago
      Sorry -- I edited my reply above; the quoted sentence should be "the declaration on the _left_ makes a certain amount of sense". > You say it as if it's the only sensible way to design a declaration syntax I don't say that -- in fact, I'm replying to my own post saying that the declaration on the left was a mistake. My only point is that it is a design decision that has some historical grounding.

jolmg 8y ago

> I don't know that you'll be able to sell a programmer that has stuck with C on Haskell. The ability to look at code and have a rough idea of what the assembly will look like is, in my opinion, fairly high up on the list of desired features. Haskell does ... not really provide that. I'm not trying to sell Haskell to C developers, though, I was just replying to the GP's disbelief at a syntax preference for having types on the right. Also, I don't think the ability you mention has anything to do with the choice of syntax of having types on the left or the right. I do very much wonder if there are any benefits, at all, of having the types on the left. EDIT: On re-reading my above comment, I guess I was selling it a little, but I only meant to justify having complex looking types. :P

andrewla 8y ago
The notion of types as type assertions is relatively new to C, and its syntax reflects that. Types in C are more storage specifications than they are type assertions. When you declare an “int”, you’re not declaring a variable of type int per se; you’re declaring and int-sized hole where you can put values. So the declaration on the left [ed: Was right] makes a certain amount of sense - you’re declaring an int, so that’s what you lead with. When you declare a “string” you have to think about how the string is stored; and that implementation detail bleeds into the syntax. A C has matured the notion of incompatible types has seeped into the language to the point where now it becomes a little annoying that I can just go ahead and pass an int into a function that expects a typedef’d “type”; libraries often wrap them in very lightweight structs just to get an additional bit of typechecking. The expectations for what kind of errors the compiler can catch have grown over time but the language has only made small concessions.
- jolmg 8y ago
  > the declaration on the right makes a certain amount of sense - you’re declaring an int, so that’s what you lead with. I'm sorry, but that doesn't make sense to me. You say it as if it's the only sensible way to design a declaration syntax, but Haskell (and other languages) did it the other way just fine. I don't see how the differences in semantics between the 2 type systems give rise to a benefit in having the type expressed on the left. If the design came to be decided like that, it seems it's simply not something that was put much thought over. That's fine too, since the limitations of the type system do not give rise to cases where this syntax choice becomes too big of an inconvenience. Still, no benefits as far as I can see. Maybe it simply appealed to the designer's intuition more. Choosing because of that indicates that the choice was pretty arbitrary, though.
  - andrewla 8y ago
    Sorry -- I edited my reply above; the quoted sentence should be "the declaration on the _left_ makes a certain amount of sense". > You say it as if it's the only sensible way to design a declaration syntax I don't say that -- in fact, I'm replying to my own post saying that the declaration on the left was a mistake. My only point is that it is a design decision that has some historical grounding.