>Seems like your problem is with bad idioms, you seem to be a fan of the Play style -- both are just idioms, a simple way to improve communication.
No, my problem, is with the pre-supposed and agreed upon set of idioms ("idiomatic Go", "idiomatic Java", "idiomatic Python").
I'm not even against what those idioms contain per se, as individual items.
>"different but convenient" can to be looked at in two different ways. The first is for you, the original developer. It is more convenient for you... but what about the next 5 (or 50) developers who are unfamiliar with the idioms in play, it will radically slow them down as they lack the shorthand to quickly understand it.
Well, the reverse can be true.
Java programmers familiar with the circa-2004 idiomatic BS over-reliance of GoF patterns and deep class hierarchies created code that was "idiomatc Java EE" but difficult to undertand, overengineered, and inflexible.
Someone coding unidiomatic Java (e.g. Play) and giving the project to them, they'd instantly understand what its going on -- even better than someone giving them an "idiomatic Java EE" monstrocity.
>Go is about programming at scale (in terms of people) and something that benefits one while slowing down all others is going to be looked down on
People keep saying that, but most Go projects I've seen are made by only few of people, maybe even a couple. Plus, people complain about even single-developer Go projects being "unidiomatic".
Programming at scale, like big 3D games, Photoshop, the Linux Kernel, Webkit etc, is still done in C/C++, with no sign of this changing.
> No, my problem, is with the pre-supposed and agreed upon set of idioms ("idiomatic Go", "idiomatic Java", "idiomatic Python").
Idioms have to be agreed upon (by the community) else they have no value at all. Shorthand only works if both people in the conversation understand what it means.
It seems like you are upset that the idioms came from the standard libraries (which is where I believe the initial idioms for Go, Java, and Python stemmed from), but you also have to give time.
Play was released in 2007 -- Java was released 1995. So it took a number of years for that change to take place. During the between time, idioms helped move java forward, make it understandable, make developers able to communicate via code.
Go was released in 2012 (v1), so of course a lot of the idioms are going to stem from the standard library -- we don't have two decades of Gophers moving the ball forward and agreeing as a community what the idioms are, they gotta start somewhere.
> Java programmers familiar with the circa-2004 idiomatic BS over-reliance of GoF patterns and deep class hierarchies created code that was "idiomatc Java EE" but difficult to undertand, overengineered, and inflexible.
Idioms are not static. Please stop using that as a strawman to tear down. Idioms rot. If they are not what the community currently uses, they are not idiomatic.
> People keep saying that, but most Go projects I've seen are made by only few of people, maybe even a couple. Plus, people complain about even single-developer Go projects being "unidiomatic".
Current use and design goals are not the same. Google developed Go to be used at (many-people) scale, even if it currently isn't (which I don't agree with: https://code.google.com/p/go-wiki/wiki/GoUsers). It isn't like Go can stop individuals from using it.
"""Idioms are not static. Please stop using that as a strawman to tear down. Idioms rot. If they are not what the community currently uses, they are not idiomatic."""
I'm not annoyed by idioms because they don't ever change -- but because while they exist in a certain form, they inhibit experimenting with different approaches.
Or to be more presize, I'm not annoyed by idioms themselves (as I also wrote above), as individual practices. I'm annoyed by people insisting on them, and criticizing everything diverting (unidiomatic) as something that's bad.
Nothing is static, except change. But for a specific period of time (which can be like aeons in the software industry) idioms are for all intends and purposes static.
E.g Java EE land, from say, 2000-ish to 2007. The idioms were fixed and agreed upon, and most people and groups, from Apache Struts to Java engineers and IBM played by them, but they neither helped the community "communicate via code" nor helped "make programs understandable".
Instead, they hindered both communication and understanding. Almost everybody agrees now that the adopted idioms at the time were bad, and inhibited progress and even slowed down projects.
It's not even like "it was good for it's time, but we eventually came up with something better". We always had the option to do the better thing (it doesn't take unique new research to not use a 20-levels deep hierarchy or to not think GoF patterns should be applied everywhere). And since we moved on, everybody seems to agree it wasn't "good for the time" either.
Dude, just be a rebel and go off and program go however you like. All of your railing is pointless. Things change over time at different rates for different reasons. Clearly you personally feel insulted because you like to think of yourself as being an outside-the-box type of thinker who comes up with new clever ways of doing things. Good for you. Keep it up and don't forget to teach us along the way, but remember that simply railing against a communities standard approach is rather pointless. With your better way, lead on :)
I see you all the time in these go threads, by the way. You would better spend your time forgetting about go and doing something else since you so clearly detest it for not having generics (obviously less convenient than a functional language, but clearly not required to do programming).
No, my problem, is with the pre-supposed and agreed upon set of idioms ("idiomatic Go", "idiomatic Java", "idiomatic Python").
I'm not even against what those idioms contain per se, as individual items.
>"different but convenient" can to be looked at in two different ways. The first is for you, the original developer. It is more convenient for you... but what about the next 5 (or 50) developers who are unfamiliar with the idioms in play, it will radically slow them down as they lack the shorthand to quickly understand it.
Well, the reverse can be true.
Java programmers familiar with the circa-2004 idiomatic BS over-reliance of GoF patterns and deep class hierarchies created code that was "idiomatc Java EE" but difficult to undertand, overengineered, and inflexible.
Someone coding unidiomatic Java (e.g. Play) and giving the project to them, they'd instantly understand what its going on -- even better than someone giving them an "idiomatic Java EE" monstrocity.
>Go is about programming at scale (in terms of people) and something that benefits one while slowing down all others is going to be looked down on
People keep saying that, but most Go projects I've seen are made by only few of people, maybe even a couple. Plus, people complain about even single-developer Go projects being "unidiomatic".
Programming at scale, like big 3D games, Photoshop, the Linux Kernel, Webkit etc, is still done in C/C++, with no sign of this changing.