10 ms·

Hopefully with people from the dynamic languages camp trying the language they'll clean up the syntax. It's ugly and makes a lot of the example code hard to rea

by Detrus 16y ago

Hopefully with people from the dynamic languages camp trying the language they'll clean up the syntax. It's ugly and makes a lot of the example code hard to read.

supersillyus 16y ago
What do you think needs cleaning up?
- Detrus 16y ago
  Aesthetics for starters. CoffeeScript http://jashkenas.github.com/coffee-script/ http://jashkenas.github.com/coffee-script/ is what modern syntax should look like. White space instead of the bracket mess. Go's public/private difference is capitalization of method names. That's hard to scan. Then you get chains that look.Like().A().Mess(). What the Go team seemed to do was take syntax from other languages they were familiar with, ugly syntax non-dynamic languages. They didn't focus on it, Pike said it wasn't important, semantics are important. So when you don't design syntax first, you get a syntax that's on the opposite end from Ruby. Arguments func([] byte T* blah), who knows what goes where. That needs work. The c-> and <-c is unintuitive, the syntax is so itsy bitsy it's easy to miss the difference. They should have keywords for that. And in general the syntax is itsy bitsy, they feel that shorter words means quicker to read, but it's an overreaction to never ending lines commonly found in Java and C++.
  - Jabbles 16y ago
    IMO: I love capitalised public method names. It means I can immediately tell whether a method is public or private, in any context, e.g. on code pasted on HN. look.Like().A().Mess() looks awful. Don't do it. Or do, it's up to you/ your company's style guide. You could easily avoid chained methods entirely. Go is at the opposite end from Ruby. It's a systems language... The fact that they look different is no surprise. func([] byte T* blah) - that's not Go. send and receive are perfectly intuitive to me. Watch! You put it in the channel<-. You get it out of the <-channel. There is no "->". "in general the syntax is itsy bitsy" - I can only suggest you try it for a bit longer until you get used to it.
    - Detrus 16y ago
      Yea I don't use Go, tried it many moons ago, those were my impressions of the syntax, was going to edit with real code. Rob Pike made an interesting argument about dynamic vs compiled languages. Said that the division between easy of use and performance, dynamic interpreted vs static compiled was not caused by technical problems, just dumb luck. People that made up dynamic languages weren't interested in performance, didn't design around it. Maybe now they're perpetuating the same division in syntax. System language syntax is weird, machine looking, dynamic language syntax reads more like English. Doesn't have to be that way, but it would be the system guy's preference. So I was thinking if the dynamic language camp used to Python's syntax took up Go, maybe it would be changed for their taste. The channel <- syntax is crazy. In and out depends on which side of the operator channel is in. I'm sure they thought it was cute, but "into" "out" keywords are easier to keep track of than which side the channel var name is on.
      - Jabbles 16y ago
        "System language syntax is weird, machine looking" - But if it's your job to program in C/C++/Go, you begin to read the code just like English. Go's syntax, you will admit, is much cleaner than C++'s. Personally I like blocks of code being separated by curly braces, I think it helps keep them separate. Combined with Gofmt, which automatically indents code (like Python), I find Go very readable indeed. I don't understand your objections to the channel syntax; the order of the letters you type matters, obviously. Again, it's a personal preference, and I'm quite used to C's pre/postfix operators.
        Detrus 16y ago
        My objection is aesthetics. It's subjective, a matter of taste. I prefer languages that you don't have to get used to. They're obvious, like a good user interface is obvious. Anyone can read their code, even if they don't work in the language. Go could be a language like that, there are no technical roadblocks for doing that, just a matter of the audience's taste.
        16y ago
masklinn 16y ago
> Hopefully with people from the dynamic languages camp trying the language they'll clean up the syntax. Considering the year elapsed, that's about as likely as them killing the project and admitting that Go is a turd which only gets airwave because it's a project by two extremely famous googlers. The syntax is crap, the type system is garbage, they spend their time reinventing utterly terrible wheels and they've thrown out basically all ideas of safety they could get on fire.
KaeseEs 16y ago
I agree that the Go example code looks ugly, although much of that for me is simply from their ideas on capitalization. Of special note from my perspective is that their biggest attempt to clean up syntax, by adopting a JS-esque automatic insertion of most semicolons, has backfired: it doesn't make anything prettier, it's either a wash or a slight loss with respect to obviousness of code, and it introduces a few opportunities for bugs. Perl of all languages did a better job at this goal by just making the terminator of the last element of a block or list optional. I appreciate their maintenance of an end delimiter to blocks that is vertically aligned with the start of the block, although they could have gotten a bigger win imo by going with the ALGOL/Ruby style 'end' rather than the C style curly brace (and in doing so freed up curly braces to unambiguously be used for something else).
- koenigdavidmj 16y ago
  Yeah, that was likely a big mistake on their part. Arguments on significant whitespace aside, I think that this is one thing that Python got right. (For reference, Python's rules are that ending a line with a backslash will continue a statement, and the same effect will occur automatically if you have a parenthesis, curly, or bracket open.) I might also be convinced that it would be a good idea to have statement continuation happen if the last token on a line was a binary operator, for the benefit of code like: if self.foo() and self.bar() and self.baz(): do stuff (Currently PEP 8 requests that you put parentheses around the test.)
chunkbot 16y ago
Syntax is never really a problem. We do a lot of work in Erlang... Erlang is based originally on Prolog, a logic programming language that was briefly hot in the 80's. Surely you've seen other languages based on Prolog, right? No? Why not? Because Prolog sucks ass for building entire applications. But that hasn't deterred Erlang from stealing it's dynamite syntax. [source: http://damienkatz.net/2008/03/what_sucks_abou.html http://damienkatz.net/2008/03/what_sucks_abou.html What Sucks About Erlang] In reality, syntax just fades away after ~5 minutes of real world usage. As Steve Jobs would say, it's not that big of a deal.
- Detrus 16y ago
  It fades away, but lags there chipping at productivity. The Ruby crowd makes a big fuss about their syntax, talk about how it revitalized their love of programming, makes programming enjoyable and so on. They might be onto something.
- silentbicycle 16y ago
  Erlang's syntax isn't representative of Prolog's. It was originally implemented in SICStus, sure, but Prolog lets you add your own operators, and Erlang added a ton on top of the (rather clean) Prolog syntax. How would Ruby (or whatever syntax you like) look if you made a DSL by adding every operator that wasn't already in use? You know all the problems with the ambiguous ; , . stuff that Katz gripes about in that post? Prolog terminates every clause with a period, and all related rules just occur in sequence. Prolog has a read function, much like read in Lisp - "read the next complete (s-expression|Prolog clause) from stdin". The original Erlang compiler needed to read all of the alternative clauses for a function in one go* , so they strung them together with "," and ";", which are Prolog's and and or operators. (They could have fixed this when they started self-hosting, but probably had other priorities.) In practice, it isn't a problem (and Erlang has many perks to make up for those minor syntactic irritations!), but that can't be blamed on Prolog. It's sort of like if you used Lisp's (read) to load more expressions, but since your compiler needed you to read a whole module at once as an implementation detail, you used [ and { pairs instead of parens. Yuck! In Prolog, that sort of code looks like this: parent(terach, abraham). parent(abraham, isaac). parent(isaac, jacob). parent(jacob, benjamin). Note the conspicuous lack of semicolons. * I'm reading between the lines here, so if Robert Virding swoops in and tells me I'm wrong, Hello Robert! :) If anything, the reason that Prolog isn't good for entire applications is that it's fundamentally a rules/database query language. It's awkward for stateful / procedural code, but if you treat it like (say) a much more sophisticated SQLite, it will be good to you.

by Detrus 16y ago

Hopefully with people from the dynamic languages camp trying the language they'll clean up the syntax. It's ugly and makes a lot of the example code hard to read.

supersillyus 16y ago

What do you think needs cleaning up?

Detrus 16y ago
Aesthetics for starters. CoffeeScript http://jashkenas.github.com/coffee-script/ http://jashkenas.github.com/coffee-script/ is what modern syntax should look like. White space instead of the bracket mess. Go's public/private difference is capitalization of method names. That's hard to scan. Then you get chains that look.Like().A().Mess(). What the Go team seemed to do was take syntax from other languages they were familiar with, ugly syntax non-dynamic languages. They didn't focus on it, Pike said it wasn't important, semantics are important. So when you don't design syntax first, you get a syntax that's on the opposite end from Ruby. Arguments func([] byte T* blah), who knows what goes where. That needs work. The c-> and <-c is unintuitive, the syntax is so itsy bitsy it's easy to miss the difference. They should have keywords for that. And in general the syntax is itsy bitsy, they feel that shorter words means quicker to read, but it's an overreaction to never ending lines commonly found in Java and C++.
- Jabbles 16y ago
  IMO: I love capitalised public method names. It means I can immediately tell whether a method is public or private, in any context, e.g. on code pasted on HN. look.Like().A().Mess() looks awful. Don't do it. Or do, it's up to you/ your company's style guide. You could easily avoid chained methods entirely. Go is at the opposite end from Ruby. It's a systems language... The fact that they look different is no surprise. func([] byte T* blah) - that's not Go. send and receive are perfectly intuitive to me. Watch! You put it in the channel<-. You get it out of the <-channel. There is no "->". "in general the syntax is itsy bitsy" - I can only suggest you try it for a bit longer until you get used to it.
  - Detrus 16y ago
    Yea I don't use Go, tried it many moons ago, those were my impressions of the syntax, was going to edit with real code. Rob Pike made an interesting argument about dynamic vs compiled languages. Said that the division between easy of use and performance, dynamic interpreted vs static compiled was not caused by technical problems, just dumb luck. People that made up dynamic languages weren't interested in performance, didn't design around it. Maybe now they're perpetuating the same division in syntax. System language syntax is weird, machine looking, dynamic language syntax reads more like English. Doesn't have to be that way, but it would be the system guy's preference. So I was thinking if the dynamic language camp used to Python's syntax took up Go, maybe it would be changed for their taste. The channel <- syntax is crazy. In and out depends on which side of the operator channel is in. I'm sure they thought it was cute, but "into" "out" keywords are easier to keep track of than which side the channel var name is on.
    - Jabbles 16y ago
      "System language syntax is weird, machine looking" - But if it's your job to program in C/C++/Go, you begin to read the code just like English. Go's syntax, you will admit, is much cleaner than C++'s. Personally I like blocks of code being separated by curly braces, I think it helps keep them separate. Combined with Gofmt, which automatically indents code (like Python), I find Go very readable indeed. I don't understand your objections to the channel syntax; the order of the letters you type matters, obviously. Again, it's a personal preference, and I'm quite used to C's pre/postfix operators.
      - Detrus 16y ago
        My objection is aesthetics. It's subjective, a matter of taste. I prefer languages that you don't have to get used to. They're obvious, like a good user interface is obvious. Anyone can read their code, even if they don't work in the language. Go could be a language like that, there are no technical roadblocks for doing that, just a matter of the audience's taste.
        16y ago

masklinn 16y ago

> Hopefully with people from the dynamic languages camp trying the language they'll clean up the syntax. Considering the year elapsed, that's about as likely as them killing the project and admitting that Go is a turd which only gets airwave because it's a project by two extremely famous googlers. The syntax is crap, the type system is garbage, they spend their time reinventing utterly terrible wheels and they've thrown out basically all ideas of safety they could get on fire.

KaeseEs 16y ago

I agree that the Go example code looks ugly, although much of that for me is simply from their ideas on capitalization. Of special note from my perspective is that their biggest attempt to clean up syntax, by adopting a JS-esque automatic insertion of most semicolons, has backfired: it doesn't make anything prettier, it's either a wash or a slight loss with respect to obviousness of code, and it introduces a few opportunities for bugs. Perl of all languages did a better job at this goal by just making the terminator of the last element of a block or list optional. I appreciate their maintenance of an end delimiter to blocks that is vertically aligned with the start of the block, although they could have gotten a bigger win imo by going with the ALGOL/Ruby style 'end' rather than the C style curly brace (and in doing so freed up curly braces to unambiguously be used for something else).

koenigdavidmj 16y ago
Yeah, that was likely a big mistake on their part. Arguments on significant whitespace aside, I think that this is one thing that Python got right. (For reference, Python's rules are that ending a line with a backslash will continue a statement, and the same effect will occur automatically if you have a parenthesis, curly, or bracket open.) I might also be convinced that it would be a good idea to have statement continuation happen if the last token on a line was a binary operator, for the benefit of code like: if self.foo() and self.bar() and self.baz(): do stuff (Currently PEP 8 requests that you put parentheses around the test.)

chunkbot 16y ago

Syntax is never really a problem. We do a lot of work in Erlang... Erlang is based originally on Prolog, a logic programming language that was briefly hot in the 80's. Surely you've seen other languages based on Prolog, right? No? Why not? Because Prolog sucks ass for building entire applications. But that hasn't deterred Erlang from stealing it's dynamite syntax. [source: http://damienkatz.net/2008/03/what_sucks_abou.html http://damienkatz.net/2008/03/what_sucks_abou.html What Sucks About Erlang] In reality, syntax just fades away after ~5 minutes of real world usage. As Steve Jobs would say, it's not that big of a deal.

Detrus 16y ago
It fades away, but lags there chipping at productivity. The Ruby crowd makes a big fuss about their syntax, talk about how it revitalized their love of programming, makes programming enjoyable and so on. They might be onto something.
silentbicycle 16y ago
Erlang's syntax isn't representative of Prolog's. It was originally implemented in SICStus, sure, but Prolog lets you add your own operators, and Erlang added a ton on top of the (rather clean) Prolog syntax. How would Ruby (or whatever syntax you like) look if you made a DSL by adding every operator that wasn't already in use? You know all the problems with the ambiguous ; , . stuff that Katz gripes about in that post? Prolog terminates every clause with a period, and all related rules just occur in sequence. Prolog has a read function, much like read in Lisp - "read the next complete (s-expression|Prolog clause) from stdin". The original Erlang compiler needed to read all of the alternative clauses for a function in one go* , so they strung them together with "," and ";", which are Prolog's and and or operators. (They could have fixed this when they started self-hosting, but probably had other priorities.) In practice, it isn't a problem (and Erlang has many perks to make up for those minor syntactic irritations!), but that can't be blamed on Prolog. It's sort of like if you used Lisp's (read) to load more expressions, but since your compiler needed you to read a whole module at once as an implementation detail, you used [ and { pairs instead of parens. Yuck! In Prolog, that sort of code looks like this: parent(terach, abraham). parent(abraham, isaac). parent(isaac, jacob). parent(jacob, benjamin). Note the conspicuous lack of semicolons. * I'm reading between the lines here, so if Robert Virding swoops in and tells me I'm wrong, Hello Robert! :) If anything, the reason that Prolog isn't good for entire applications is that it's fundamentally a rules/database query language. It's awkward for stateful / procedural code, but if you treat it like (say) a much more sophisticated SQLite, it will be good to you.