8 ms·

> Many of the "old" ways of thinking do not apply to Go Whatever. Just because the language is effectively broken doesn't make practices in other languages irr

by aikah 10y ago

> Many of the "old" ways of thinking do not apply to Go Whatever. Just because the language is effectively broken doesn't make practices in other languages irrelevant. And it's funny when you talk about the "old" ways of thinking in language that basically promotes C styles errors and bad macros through go gen. When I say the language is broken, look at Go type system, then look at how Go reflection makes the language look a dynamically typed one. It would have been smarter to tone down the reflection and make it unnecessary with a smarter type system. If it is there then it is because it was necessary for Go designers. If it had not been, then Go would not need that insane reflection. Now Go back to your Go code and remember all tricks you need to learn when working with arrays : https://github.com/golang/go/wiki/SliceTricks https://github.com/golang/go/wiki/SliceTricks Just because : > A weakness of Go is that any generic-type operations must be provided by the run-time https://blog.golang.org/slices https://blog.golang.org/slices Now what was your point about the "old" ways of thinking again ?

defgeneric 10y ago
While I'd like to have generics in go, one of the upsides of the lack of generics is that your code becomes less idiosyncratic and more idiomatic. Too often in C++ for example, I find myself frustrated reading code where templates are unintentionally over-used because the programmer needlessly introduced an abstraction where the concrete would have sufficed. There is a certain pleasure in moving from the concrete to the abstract and finding the inner connection between things, but this can also get in the way or distract from the immediate problem. The same issue comes up in Common Lisp where you find a codebase with heavy use of macros which effectively build a DSL within the program. Working alone, this can be fun, and can produce elegant code, but it means anyone new to a project needs to first familiarize themselves with the world you've built. When many people work on a project it helps if everyone speaks the Queen's English, as it were. Still, generics would be nice.
- lomnakkus 10y ago
  > While I'd like to have generics in go, one of the upsides of the lack of generics is that your code becomes less idiosyncratic and more idiomatic. That sounds like a deepity[1] if ever I've heard one. Just to add something a little more substantive: It may not be obvious at first sight (esp. in e.g. C++ or Java), but 'generics'/'parametric polymorphism' can actually incredibly powerful at restricting what your program can do and thus actually restrict the set of valid programs which will still satisfy the type checker. This is used to great effect in e.g. ML or Haskell and can be used somewhat effectively in Java/Scala code with subtype bounds. Of course in Haskell, being a language from the 1990s[2], you can use this to effectively restrict the types of effects used by any given function (database I/O, arbitrary I/O, networking, etc.). [1] https://en.wiktionary.org/wiki/deepity#English https://en.wiktionary.org/wiki/deepity#English [2] Ok, this is slightly exaggerated since monads-for-IO were discovered quite a bit after 1990, but still... parametric polymorphism is crucial for this use case.
  - defgeneric 10y ago
    > That sounds like a deepity[1] if ever I've heard one. Your code becomes less peculiar to you and more in line with the peculiarities of the language as it's used by most people. Shallow enough? Don't let an allergy to postmodernism become an allergy to a turned phrase. Not sure what the rest of your comment has to do with my point, which was about, if you like, the pragmatics of programming. Not concerned with the space of programs that type check. Insufferable haskellers...
    - mjburgess 10y ago
      In my experience Haskell-people are not insuffereable, but have a history of a rather academic humility in the same manner that, historically, the ruby community used to. Perhaps this is changing, but my guess is the prior comment was by a person who appeals to Haskell more often than uses it.
      - lomnakkus 10y ago
        > my guess is the prior comment was by a person who appeals to Haskell more often than uses it. Two points: One, I'm not keeping an exact score of how often I mention Haskell vs. use it, but I can assure you that I use Haskell almost every single day. Two, this constant anti-academia thing is really getting tiresome at this point... but just for the record: I've never worked in academia and didn't even encounter Haskell until I was out of university. My interest and praise for Haskell (and Ocaml) is entirely based on practical experience.
    - lomnakkus 10y ago
      > Your code becomes less peculiar to you and more in line with the peculiarities of the language as it's used by most people. Shallow enough? Don't let an allergy to postmodernism become an allergy to a turned phrase. I'm objecting to the attempt at sloganization as if witty/clever phrases mean anything. FTR, I also think this is a bad thing in FP. My "favorite" example being "if it compiles, it works" (or similar). > Not sure what the rest of your comment has to do with my point, which was about, if you like, the pragmatics of programming. My point, though perhaps somewhat obscure, was that eliminating a lot (i.e. "classes") of bugs up front (e.g. by exploiting parametric polymorphism) means that you spend less time fixing bugs... which means that you spend more time getting things done. (Now, the jury is still out on whether static type checking leads to more productivity than dynamic type checking, but given that you're interested in Go, I'm guessing you're probably leaning towards 'static' anyway.) > Not concerned with the space of programs that type check. Insufferable haskellers... I used Haskell (and ML, you'll notice) as an example, but if you're not concerned with the space of programs that type check -- why are you even using a statically checked language? Surely you'd be infinitely more productive in a dynamically checked language? I'm saying you should be concerned and demand concern from the designers of your language.
- coldtea 10y ago
  >While I'd like to have generics in go, one of the upsides of the lack of generics is that your code becomes less idiosyncratic and more idiomatic. Idiomatic is only good if the idioms are good. Historically for lots of languages, and I would include Go there, the prevalent idioms were crap. E.g. Java circa 2000-2007 and the J2EE factory-singleton-factory-proxy-singleton-XML crapfest. Or PHP and the "devil may care" attitude of pre-Composer PHP codebases (including big ones like Wordpress). Or the tons of broken ways of working with Javascript until the community regained some sanity in the last 5-6 years.
stcredzero 10y ago
Whatever. Just because the language is effectively broken doesn't make practices in other languages irrelevant. Classic. All languages stink, somewhere. The classic programmer Dunning-Kruger mistake: evaluating one language without self-awareness of all of the (probably unconscious) cost/benefit optimizations that mostly apply to the other language. This is like Smalltalkers and C++ programmers in the 90's arguing about the design decisions that went into Java. Your definition of "effectively broken" actually means "doesn't fit my preferences." I'd expect "effectively broken" to more usefully mean "basically, very few people want to use it in production." Smalltalk now fits that. (Mostly through bad business/marketing decisions and incompatibility with mainstream programming expectations.) I bet there's many, many languages you might even call "elegant" that fit that as well. basically promotes C styles errors and bad macros through go gen. Funny, but my experience is that Golang basically eliminates my dealing with those. I'm writing an MMO, and my debugging time in that category amounts to literally 2 minutes. (Basically, oh duh, that member function should take a pointer reference. Otherwise, it can't mutate state!) When I say the language is broken, look at Go type system, then look at how Go reflection makes the language look a dynamically typed one. If you're such a poor programmer, that you can't get about the same level of type safety around array code in a Golang environment, as say, in a C++ environment, then just find a different language. On the other hand, if you can show an increase in productivity doing it your way in some kind of A/B quantitative comparison on actual production level code, then go ahead and take that show on the road. Go to conferences, write papers, and get yourself a nice consulting business preaching your gospel, getting paid, and advancing the almost-a-field of programming. Otherwise, just stop making noise and trolling. To be fair, there are some languages with pathologies that are publicly apparent, like PHP with webapp security and C with security exploits. There are problems with programming in the large with C++ -- some involving the very features you probably think are admirable. If you have experience with Golang in production, and you've tried mitigating the type-system weaknesses to get compile-time or test-time warnings out of the tooling, and this incurred your company some cost, then talk about that. Otherwise, you are just making worthless angry programmer noise devoid of grounding in actual practice.
- aikah 10y ago
  > If you're such a poor programmer, No need for personal attacks. > then just find a different language. What a warm an welcoming community the Go community is /s C++ doesn't have reflection, because it doesn't need it. But somehow Go needs it ? Reflection is a cop-out, especially in a language that has a simplistic type system. And don't get me started on struct tags. If you cant see the obvious issue with all these "features", in comparison of the lack of expressiveness of types AT COMPILE TIME then good for you.
eloff 10y ago
Since when is powerful reflection a drawback or a sign of a broken language? In my experience reflection is not used all that often in Go and it's nowhere near as powerful as say .NET or JVM reflection - which means package private stuff stays package private, unlike the JVM where the JIT must assume that any type can change at any time. Go has its quirks, and many design decisions that I find dubious, but so does every language I've used. I'd still much rather tackle a new project in Go than Python or C++ or Java. It's efficient, it's got great tools and a fully-stocked standard library, a fast compiler, static type checking, type inference, and is extremely easy to read other's code because the language is so simple. There aren't a million ways to write cryptic code, unlike say Scala - which appeals to me more on paper but is a disaster to work with in comparison.
- aikah 10y ago
  > Since when is powerful reflection a drawback or a sign of a broken language? When it is not balanced by an expressive type system, it becomes a cop-out where anything goes,including creating adhoc types at runtime ( reflect.StructOf() , reflect.SliceOf() , ... ), because it's the only way to get a little bit of expressiveness of out that language.
  - eloff 10y ago
    If you're doing that all over the place, you're doing it wrong. I've never seen Go code that looks like that in real projects.
    - aikah 10y ago
      > If you're doing that all over the place, you're doing it wrong. I've never seen Go code that looks like that in real projects. Yet it is there in the language. Why is that? how do you justify adding this to a statically typed language?
      - eloff 10y ago
        Your position is that statically typed languages shouldn't have reflection? I think that's a pretty fringe position to take that not many programmers would agree on. The JVM and .NET static typed languages have reflection, C++ will (hopefully) get reflection one of these days soon as it's been talked about for a while. Even rust has reflection. I think statically typed languages without reflection are the exception rather than the norm.

by aikah 10y ago

defgeneric 10y ago

While I'd like to have generics in go, one of the upsides of the lack of generics is that your code becomes less idiosyncratic and more idiomatic. Too often in C++ for example, I find myself frustrated reading code where templates are unintentionally over-used because the programmer needlessly introduced an abstraction where the concrete would have sufficed. There is a certain pleasure in moving from the concrete to the abstract and finding the inner connection between things, but this can also get in the way or distract from the immediate problem. The same issue comes up in Common Lisp where you find a codebase with heavy use of macros which effectively build a DSL within the program. Working alone, this can be fun, and can produce elegant code, but it means anyone new to a project needs to first familiarize themselves with the world you've built. When many people work on a project it helps if everyone speaks the Queen's English, as it were. Still, generics would be nice.

lomnakkus 10y ago
> While I'd like to have generics in go, one of the upsides of the lack of generics is that your code becomes less idiosyncratic and more idiomatic. That sounds like a deepity[1] if ever I've heard one. Just to add something a little more substantive: It may not be obvious at first sight (esp. in e.g. C++ or Java), but 'generics'/'parametric polymorphism' can actually incredibly powerful at restricting what your program can do and thus actually restrict the set of valid programs which will still satisfy the type checker. This is used to great effect in e.g. ML or Haskell and can be used somewhat effectively in Java/Scala code with subtype bounds. Of course in Haskell, being a language from the 1990s[2], you can use this to effectively restrict the types of effects used by any given function (database I/O, arbitrary I/O, networking, etc.). [1] https://en.wiktionary.org/wiki/deepity#English https://en.wiktionary.org/wiki/deepity#English [2] Ok, this is slightly exaggerated since monads-for-IO were discovered quite a bit after 1990, but still... parametric polymorphism is crucial for this use case.
- defgeneric 10y ago
  > That sounds like a deepity[1] if ever I've heard one. Your code becomes less peculiar to you and more in line with the peculiarities of the language as it's used by most people. Shallow enough? Don't let an allergy to postmodernism become an allergy to a turned phrase. Not sure what the rest of your comment has to do with my point, which was about, if you like, the pragmatics of programming. Not concerned with the space of programs that type check. Insufferable haskellers...
  - mjburgess 10y ago
    In my experience Haskell-people are not insuffereable, but have a history of a rather academic humility in the same manner that, historically, the ruby community used to. Perhaps this is changing, but my guess is the prior comment was by a person who appeals to Haskell more often than uses it.
    - lomnakkus 10y ago
      > my guess is the prior comment was by a person who appeals to Haskell more often than uses it. Two points: One, I'm not keeping an exact score of how often I mention Haskell vs. use it, but I can assure you that I use Haskell almost every single day. Two, this constant anti-academia thing is really getting tiresome at this point... but just for the record: I've never worked in academia and didn't even encounter Haskell until I was out of university. My interest and praise for Haskell (and Ocaml) is entirely based on practical experience.
  - lomnakkus 10y ago
    > Your code becomes less peculiar to you and more in line with the peculiarities of the language as it's used by most people. Shallow enough? Don't let an allergy to postmodernism become an allergy to a turned phrase. I'm objecting to the attempt at sloganization as if witty/clever phrases mean anything. FTR, I also think this is a bad thing in FP. My "favorite" example being "if it compiles, it works" (or similar). > Not sure what the rest of your comment has to do with my point, which was about, if you like, the pragmatics of programming. My point, though perhaps somewhat obscure, was that eliminating a lot (i.e. "classes") of bugs up front (e.g. by exploiting parametric polymorphism) means that you spend less time fixing bugs... which means that you spend more time getting things done. (Now, the jury is still out on whether static type checking leads to more productivity than dynamic type checking, but given that you're interested in Go, I'm guessing you're probably leaning towards 'static' anyway.) > Not concerned with the space of programs that type check. Insufferable haskellers... I used Haskell (and ML, you'll notice) as an example, but if you're not concerned with the space of programs that type check -- why are you even using a statically checked language? Surely you'd be infinitely more productive in a dynamically checked language? I'm saying you should be concerned and demand concern from the designers of your language.
coldtea 10y ago
>While I'd like to have generics in go, one of the upsides of the lack of generics is that your code becomes less idiosyncratic and more idiomatic. Idiomatic is only good if the idioms are good. Historically for lots of languages, and I would include Go there, the prevalent idioms were crap. E.g. Java circa 2000-2007 and the J2EE factory-singleton-factory-proxy-singleton-XML crapfest. Or PHP and the "devil may care" attitude of pre-Composer PHP codebases (including big ones like Wordpress). Or the tons of broken ways of working with Javascript until the community regained some sanity in the last 5-6 years.

stcredzero 10y ago

Whatever. Just because the language is effectively broken doesn't make practices in other languages irrelevant. Classic. All languages stink, somewhere. The classic programmer Dunning-Kruger mistake: evaluating one language without self-awareness of all of the (probably unconscious) cost/benefit optimizations that mostly apply to the other language. This is like Smalltalkers and C++ programmers in the 90's arguing about the design decisions that went into Java. Your definition of "effectively broken" actually means "doesn't fit my preferences." I'd expect "effectively broken" to more usefully mean "basically, very few people want to use it in production." Smalltalk now fits that. (Mostly through bad business/marketing decisions and incompatibility with mainstream programming expectations.) I bet there's many, many languages you might even call "elegant" that fit that as well. basically promotes C styles errors and bad macros through go gen. Funny, but my experience is that Golang basically eliminates my dealing with those. I'm writing an MMO, and my debugging time in that category amounts to literally 2 minutes. (Basically, oh duh, that member function should take a pointer reference. Otherwise, it can't mutate state!) When I say the language is broken, look at Go type system, then look at how Go reflection makes the language look a dynamically typed one. If you're such a poor programmer, that you can't get about the same level of type safety around array code in a Golang environment, as say, in a C++ environment, then just find a different language. On the other hand, if you can show an increase in productivity doing it your way in some kind of A/B quantitative comparison on actual production level code, then go ahead and take that show on the road. Go to conferences, write papers, and get yourself a nice consulting business preaching your gospel, getting paid, and advancing the almost-a-field of programming. Otherwise, just stop making noise and trolling. To be fair, there are some languages with pathologies that are publicly apparent, like PHP with webapp security and C with security exploits. There are problems with programming in the large with C++ -- some involving the very features you probably think are admirable. If you have experience with Golang in production, and you've tried mitigating the type-system weaknesses to get compile-time or test-time warnings out of the tooling, and this incurred your company some cost, then talk about that. Otherwise, you are just making worthless angry programmer noise devoid of grounding in actual practice.

aikah 10y ago
> If you're such a poor programmer, No need for personal attacks. > then just find a different language. What a warm an welcoming community the Go community is /s C++ doesn't have reflection, because it doesn't need it. But somehow Go needs it ? Reflection is a cop-out, especially in a language that has a simplistic type system. And don't get me started on struct tags. If you cant see the obvious issue with all these "features", in comparison of the lack of expressiveness of types AT COMPILE TIME then good for you.

eloff 10y ago

Since when is powerful reflection a drawback or a sign of a broken language? In my experience reflection is not used all that often in Go and it's nowhere near as powerful as say .NET or JVM reflection - which means package private stuff stays package private, unlike the JVM where the JIT must assume that any type can change at any time. Go has its quirks, and many design decisions that I find dubious, but so does every language I've used. I'd still much rather tackle a new project in Go than Python or C++ or Java. It's efficient, it's got great tools and a fully-stocked standard library, a fast compiler, static type checking, type inference, and is extremely easy to read other's code because the language is so simple. There aren't a million ways to write cryptic code, unlike say Scala - which appeals to me more on paper but is a disaster to work with in comparison.

aikah 10y ago
> Since when is powerful reflection a drawback or a sign of a broken language? When it is not balanced by an expressive type system, it becomes a cop-out where anything goes,including creating adhoc types at runtime ( reflect.StructOf() , reflect.SliceOf() , ... ), because it's the only way to get a little bit of expressiveness of out that language.
- eloff 10y ago
  If you're doing that all over the place, you're doing it wrong. I've never seen Go code that looks like that in real projects.
  - aikah 10y ago
    > If you're doing that all over the place, you're doing it wrong. I've never seen Go code that looks like that in real projects. Yet it is there in the language. Why is that? how do you justify adding this to a statically typed language?
    - eloff 10y ago
      Your position is that statically typed languages shouldn't have reflection? I think that's a pretty fringe position to take that not many programmers would agree on. The JVM and .NET static typed languages have reflection, C++ will (hopefully) get reflection one of these days soon as it's been talked about for a while. Even rust has reflection. I think statically typed languages without reflection are the exception rather than the norm.