Native GUI library for Go

Re:Native GUI library for Go by stcredzero on Friday June 06, 2014 @12:30PM (#7858880)

I'm skeptical about the urgent need for generics. In over 3 decades of coding in some big corporate code bases, I've only seen situations where generics could have defended against really terrible coding practices. (This collection only ever has Portfolios in it. Why don't I stick a line item in there for my convenience?) But in that case, the shop has something more critical to worry about than choice of programming language.

Granted, there are some quite complex systems out there where generics could deliver truly valuable type safety. I doubt all the systems that are that complicated really need to be.

The likelihood that a programming language feature will be over/mis-used is directly proportional to how nifty it is.

[ Parent | on HN ]

Re:Native GUI library for Go by sdegutis on Friday June 06, 2014 @01:00PM (#7859057)

I just know that generics are helpful. Not just a convenience, but genuinely helpful. And it gives a kind of help that can't easily be replaced by a new library or third party tools. Which, to me, makes generics a very welcome language addition. You could very well code big and small projects without them (and I have too). But that doesn't negate their utility.

[ Parent | on HN ]

Re:Native GUI library for Go by stcredzero on Friday June 06, 2014 @01:44PM (#7859310)

Not just a convenience, but genuinely helpful.

Specifically, how?

EDIT: Surprisingly, programmers do a lot of this "just knowing." You'd think that a supposedly quantifiable field would have more, quantification. Going by "guts" is particularly bad in big enterprises, where decisions are often more about politics than about quantifiable results.

[ Parent | on HN ]

Re:Native GUI library for Go by Someone on Friday June 06, 2014 @04:16PM (#7860071)

I can guess what he hints at. If you don't have generics, you either copy-paste-replace common data structures, or you implement them for the equivalent of void .
The former means more code. That can be hidden out of view, but it means more work when fixing bugs in that code, introduces subtle bugs when one forgets to apply a bug fix to a 'copy', and slows down compiles.
The latter means adding casts to your code that make it harder to read and (more code is buggier code) also runs the risk of introducing bugs.
The two-and-halfth option is to use some preprocessor to generate code variants for you. IMO, that is just a bad implementation of generics.

Yes, that is not quantified, but I think it covers the how* part.

[ Parent | on HN ]

Re:Native GUI library for Go by AlisdairO on Saturday June 07, 2014 @03:24AM (#7861552)

Casting (for example) is a pain, but to me the best aspect of generics is the documentation they provide of the types involved with a given piece of code.

[ Parent | on HN ]