5 ms·

Thanks for contributing to the gradual destruction of computer science.

• ecnahc515 12y ago
  Good thing production software deployment and maintenance has a much smaller focus on computer science theory than real world use cases. If all business decisions were based on pure computer science we might very well have much better software, but im inclined to believe we wouldn't have so many different and great products out in the world.
  • pjmlp 12y ago
    No, nowadays business decisions are taken where and what to offshore.
  • emeraldd 12y ago
    These are all considerations that should really be part of computer science in the first place. There's too much focus on the "Spherical Cow" part of writing software and not enough/any focus on how that software actually behaves at a modern scale/style of deployment. (At least in the curriculum I remember).
• eliben 12y ago
  Huh what? Care to elaborate?
  • valarauca1 12y ago
    I'll take a swing. These aren't 'destroy computer science' worthy, but they are a MASSIVE step back in the development of languages. :.:.: Go lacks a lot of basic functionality a lot of other languages take for granted. I.E.: In Rust you can type fn id<T> ( item:T) -> T { return item; } And you assign the type to the function. This is possible in Go by double casting the type. Which is really messy, and what java did in 2004 for generic functions (and was ultimately useless). :.:.: Lets say you want to iterate over a array in say java. for(byte a: bytes[] { x += a; } This also doesn't exist in Go. Yet does in python, java, and several others thanks to iterators. :.:.: Lets say I'm adding vectors and dark magic has told me to use '-' for the dot product. In most languages (Rust, C, C++, Haskell) this is completely possible, as - is just a function. __subtract__() in rust. You can't in Go. :.:.: Now lets talk about pointers. When you want to signify data doesn't exist in Go you pass a null pointer (nil, 0x0). This is wrong on almost every single level. Your not only creating a back door, but your by passing your entire type system. The only thing that stops this from being common practice is that Go has such good message handling, but it still exists! Why?! :.:.: Immutable variables, data structures, etc. are a thing of beauty. In Rust and Haskell all values are immutable by default, but most languages (C, C++, Java) let you delcare variables, data structures, etc. as immutable.... Go doesn't. :.:.: Go has no support for turning off compiler safety features. Much like Rust offers the unsafe{ ... } tag for isolating code that may do strange things, go doesn't. :.:.: TL;DR Go doesn't do anything new. Actually it takes a step back.
    • NateDad 12y ago
      Not sure why you think you can't iterate over an array in go: for _, a := bytes { x += a } No there's no generics. I rarely need generics. Usually I need a specific, and waste time making a genetic. No there's no operator overloading, and thank god. + is numeric add, I never have to wonder if + might be some crazy O(n^2) function. Yes, that makes go bad for Matt and science code. That's ok, go is not for every application. Go has unsafe and reflection, it is just discouraged strongly. Yes, nil exists. Big deal. You know how often I've seen nil pine exceptions in a year of writing go full time? Once. Because go has multiple returns and you never look at the pointer before checking the error. No there's no immutable data structures.... And I've never missed them. You can approximate them with interfaces with only getter methods, but it's rarely worth the effort.
      • valarauca1 12y ago
        >Usually I need a specific, and waste time making a genetic Often times in large code bases you'll have short mathematical expressions used in multiple places. fn error<T:num>(real:<T>, test:<T>)-> <T> { return ((real-test)/real)*100; } Now instead of typing the same thing over and over and over again I call a function (literally what they're designed for), and it works for floats, doubles, AND ints. >no operator overloading, and thank god. + is numeric add, I never have to wonder if + might be some crazy O(n^2) function. Overloading is normally done a per-data type basis to avoid exactly what you state. But yes, it is a big mathematical/scientific point. It can really simplify your life working with some data structures. >Yes, nil exists. Big deal. No that's the problem. Its existence is a bug. And has no use existing, as you said yourself its rare, you never see it, you hardly use it... So why even include it?! >[...] immutable Immutability is more of a programmer hack, not a language hack. Rust and Haskell make me ask myself 'will I actually change this value' when declaring a new variable. And addes an extra mental step and self check of your own code when programming.
        • Laremere 12y ago
          Re nil: He said he rarely sees code fail because of nil dereferences, not that he rarely sees it. "if err != nil {" is probably the most commonly written line of Go code by a large margin. Nil fits well with the language's zero defaultness of values. It may not be theoretically sound, but in practice it fits within Go very well and rarely causes the problems it tends to in other languages with null.
• dscrd 12y ago
  If a theoretically weaker programming language is able to destroy computer science, it deserves to be destroyed. (It isn't of course)