4 ms·

I thought I knew C.

by nathell 14y ago

I thought I knew C.

niggler 14y ago
What makes me wary of using these uncommon constructs is that someone editing code later may make a change based on a superficial understanding (and break the build)
- ambrop7 14y ago
  Much less likely than someone editing code later using his superficial understanding of C++ :)
  - zxcdw 14y ago
    Or Ruby. Or C. Or Scala. Or Haskell. Or JavaScript. Or Go. You get the point I hope.
    - klibertp 14y ago
      It's not that easy, I'm afraid. Languages do differ in many areas and one of them is how easy it is to make a mistake in one. I think Go was designed with this in mind? Also, Haskell's type system guards against this. On the other hand C does nothing to prevent you from shooting yourself in the foot and C++, while improving some things, makes it overall worse because of sheer amount of constructs in the language. Ruby and JS are better in that they run on VMs and so won't segfault (that often), but other than that they do very little to help avoid making mistakes (implicit undefineds passed to functions in JS...). Anyway, languages are not created equal and one thing a language designer can optimize for is to reduce the probability of programmer making mistake. That's only one of the variables however and sometimes it's the other goals that are more important and then we get languages like C++. That's not to say it's bad, it's just optimized for different things.
  - niggler 14y ago
    After the fifth time dealing with subordinates misunderstanding template constructs I decided to throw out all of the C++ code and reimplement in "simple" C and x64 assembly -- at least now people don't mess with the assembly
shurcooL 14y ago
This is one of the things that attracts me to Go (and developing tools for working with it, which requires parsing the language, etc.). It's much easier to keep the entire language spec in your working memory, because it all fits in http://golang.org/ref/spec http://golang.org/ref/spec.
- frou_dh 14y ago
  I agree that it's a pretty clean language, but it still has oddities. For example, where in your linked spec does it address why the following trips a compile error? func foo(b bool) { if b { return } else { return } } func bar(b bool) int { if b { return 100 } else { return 200 } } func baz(b bool) int { if b { return 100 } return 200 } func qux(b bool) int { if b { return 100 } else { return 200 } panic("?") } // Error: function [bar] ends without a return statement
  - dchest 14y ago
    https://code.google.com/p/go/issues/detail?id=65 https://code.google.com/p/go/issues/detail?id=65
    - Dylan16807 14y ago
      Don't just link that with no comment. I thought you were disagreeing, not just showing that the go people have refused to fix it for two years.
      - frou_dh 14y ago
        To be fair, they have executed the overall project very well from what I've seen. A few things falling through the cracks is probably inevitable. That issue's not closed so there's hope for it yet.
      - dchest 14y ago
deleted 14y ago
[deleted]

I thought I knew C.

by nathell 14y ago

I thought I knew C.

What makes me wary of using these uncommon constructs is that someone editing code later may make a change based on a superficial understanding (and break the build)

ambrop7 14y ago
Much less likely than someone editing code later using his superficial understanding of C++ :)
- zxcdw 14y ago
  Or Ruby. Or C. Or Scala. Or Haskell. Or JavaScript. Or Go. You get the point I hope.
  - klibertp 14y ago
    It's not that easy, I'm afraid. Languages do differ in many areas and one of them is how easy it is to make a mistake in one. I think Go was designed with this in mind? Also, Haskell's type system guards against this. On the other hand C does nothing to prevent you from shooting yourself in the foot and C++, while improving some things, makes it overall worse because of sheer amount of constructs in the language. Ruby and JS are better in that they run on VMs and so won't segfault (that often), but other than that they do very little to help avoid making mistakes (implicit undefineds passed to functions in JS...). Anyway, languages are not created equal and one thing a language designer can optimize for is to reduce the probability of programmer making mistake. That's only one of the variables however and sometimes it's the other goals that are more important and then we get languages like C++. That's not to say it's bad, it's just optimized for different things.
- niggler 14y ago
  After the fifth time dealing with subordinates misunderstanding template constructs I decided to throw out all of the C++ code and reimplement in "simple" C and x64 assembly -- at least now people don't mess with the assembly

shurcooL 14y ago

This is one of the things that attracts me to Go (and developing tools for working with it, which requires parsing the language, etc.). It's much easier to keep the entire language spec in your working memory, because it all fits in http://golang.org/ref/spec http://golang.org/ref/spec.

frou_dh 14y ago
I agree that it's a pretty clean language, but it still has oddities. For example, where in your linked spec does it address why the following trips a compile error? func foo(b bool) { if b { return } else { return } } func bar(b bool) int { if b { return 100 } else { return 200 } } func baz(b bool) int { if b { return 100 } return 200 } func qux(b bool) int { if b { return 100 } else { return 200 } panic("?") } // Error: function [bar] ends without a return statement
- dchest 14y ago
  https://code.google.com/p/go/issues/detail?id=65 https://code.google.com/p/go/issues/detail?id=65
  - Dylan16807 14y ago
    Don't just link that with no comment. I thought you were disagreeing, not just showing that the go people have refused to fix it for two years.
    - frou_dh 14y ago
      To be fair, they have executed the overall project very well from what I've seen. A few things falling through the cracks is probably inevitable. That issue's not closed so there's hope for it yet.
    - dchest 14y ago

deleted 14y ago

[deleted]