Hacker News Reader

Comment by sdegutis | Hacker News Reader

Although I'm skeptical about this project (as I usually am with widget platform-native toolkits like this), I'm very interested about how it turns out. It looks like it's in early development, but the author seems to know his stuff. It would have been really cool to see back when I was first trying Go out, but I've since lost interest in Go since they're taking so long to implement generics, and I'm not interested in copy/pasting so much code. When I'm writing OS X apps (I don't use any other platform these days), writing in Swift seems like a much more fun option (too bad it's not open source, yet).

View on HN

Here's the kicker: you don't actually end up copy/pasting much code.

It's a slippery slope ("oh it's fine, I'm only copy/pasting N file(s)" where N slowly increases) which I don't want to go down.

Can you think of 3 specific examples and quantify the fan-out?

1. Float64Slice

2. IntSlice

3. StringSlice

http://golang.org/pkg/sort/

Ah yes, I've run into this. It's certainly not some kind of "rabbit hole." So basically, there's a few lines of boilerplate for each time you want to sort something. So this is O(1) additional typing per sorted type, which is what it would be for generics. You're trying to kill your argument with faint support?

EDIT: Granted, it is an unusual formulation, and far less convenient.

1-A. SearchFloat64s

2-A. SearchInts

3-A. SearchStrings

http://golang.org/pkg/sort/

Ho hum. Same arguments apply. Also O(1) per type, just like generics.

You shouldn't be copy/pasting ANY code in a language created after 2000.

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.

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.

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.

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.

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.

Objective-C doesn't have generics either and is/was the blessed API language on your chosen OS. The horror!

Obj-C is 31 years old. I don't think it's unreasonable to expect new languages/frameworks to have progressed in that time.

Isn't it normal to expect old languages to evolve too, especially when they are pushed forward by companies as huge as Apple? Look at C++ (the same age as Objective-C): C++11 was approved in 2011.

Swift, Apple's days-old intended replacement for Objective-C, does have generics.

Isn't it about time? I mean, they don't really have to make a brand new language to add generics.

As mentioned elsewhere, Objective-C is mostly dynamically typed, and you can just silently cast id to things, so it doesn't need generics as much as a language like Go, although they certainly could be useful. On the other hand, the dynamic typing makes it slow with generics or not, and if you want to put numbers in collections, you have to go through a very cumbersome boxing process - two of the many things only a new language could resolve.

And Objective-C isn't really strongly typed either, so you can send anything any message.

FWIW this is specifically why Objective-C has been able to get by without generics for a while. You don't get solid type-checking like you do with generics in other languages (except C++), but that has never really been an issue because the above statement works even with [...] statements (sure, the compiler will warn you, but).

The only real issue is that the things you shove into Objective-C containers must themselves be Objective-C types, which means using NSNumber and NSValue everywhere for raw C types. The new Objective-C @literal and @(expression) syntax, however, should make such code cleaner in the future...

It's also not statically typed - that's one of the things that generics can really help with.

Because it is dynamically typed, duh!

Surprisingly, people have different expectations between a language from the 80s and a language less than a decade old.

it's really shitty people were downvoting you for a relevant developer experience. You actually used Go, you found you kept duplicating code, and you feel this project might help. Some may theorize that you didn't quite drink the koolaid and are trying to make Java in Go or something, but the speculation is worthless, and the observation is valuable.

Your post is a good post.

I though GTK3 was available for Go. Why yet another library?

Existing GTK+ bindings require very recent versions of GTK+, which, while they provide some useful things, fail backwards-compatibility tests pretty hard, especially on distributions like Ubuntu. That being said, I do have a project in mind that will use jrick's gotk3 and GTK+ 3.10...

GTK+ on Windows doesn't really have a particularly good reputation among myself and some of the people I know, and I didn't know native GTK+ for Mac was a thing until very recently.

Reply on news.ycombinator.com