Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Generics?

blog.golang.org

Post reply on HN
Print view View original

241–250 of 261 posts

Re: Why Generics?

#241

Post by weberc2 »

ernst_klim wrote: post #218
weberc2 wrote: post #196

Earlier quoted context omitted.

This is confusingly phrased. Do you mean "If Go people were ever shown ... ML"? I would totally drop Go for an ML language if any of them had a sane syntax, usable build tooling (including native, static compilation by default), and a (single) decent standard library. A super awesome type system is worthless without the basic requirements for scalable software development.

> a sane syntax Define sane syntax. C-like abomination? At least unlike C it's unambiguous.

Easily visually scanned and parsed with little mental overhead.

Re: Why Generics?

#242

Post by ernst_klim »

weberc2 wrote: post #241
ernst_klim wrote: post #218

Earlier quoted context omitted.

> a sane syntax Define sane syntax. C-like abomination? At least unlike C it's unambiguous.

Easily visually scanned and parsed with little mental overhead.

> Easily visually scanned and parsed with little mental overhead.

Sure, I'm asking for actual traits, which makes something easily or hardly parsed. The only languages that I find more readable than OCaml are Ada, Pascal and SML. What causes mental overhead in OCaml/SML syntax for you?

Do you find

     func test (f func(a int, b int) int, x int) int
more readable than

     val test : (int -> int -> int) -> int
Maybe, you've just got used to it?

Re: Why Generics?

#243

Post by chessturk »

LandR wrote: post #150
aczerepinski wrote: post #124

Earlier quoted context omitted.

My work is a Ruby/JS shop, and we have some Go in production as well. We definitely need a little hand holding to ramp anybody new up on the Go codebases. In many cases our devs haven't used types, pointers or any equivalent of goroutines & channels. I've written just barely enough Rust to say there are even more concepts that would be new to my team. Even with Go being comparitvely simpler, I could go either way on…

> In many cases our devs haven't used types, pointers or any equivalent of goroutines & channels. How do you manage to get a job as a developer without having ever learned this stuff? Are these people that are just self taught straight to javascript / ruby? I mean, are CS course nowadays so bad that students come out of them without understanding things like type-theory, pointers etc

The shop I'm part of is staffed by bootcampers or fully self-taught people. Not a degree in sight. They have to be passionate about code/computer/the web/technology/math/some associated subject to thrive, but when they are, it seems to work out. I'm lead to believe this is the relative norm for web development.

Bootcamps do not teach things like pointers, type-theory, or big-O notation. I'm not sure what they do teach, I'm self-taught and via MIT Open Courseware + other net resources, have learned a lot about those, but I have no idea how that compares to either bootcamps or modern CS courses. Not all of my colleagues know about pointers or type-theory, but the senior ones do.

I don't know if my experience is unusual though.

edit: nicer formatting.

Re: Why Generics?

#244

Post by weberc2 »

ernst_klim wrote: post #242
weberc2 wrote: post #241

Earlier quoted context omitted.

Easily visually scanned and parsed with little mental overhead.

> Easily visually scanned and parsed with little mental overhead. Sure, I'm asking for actual traits, which makes something easily or hardly parsed. The only languages that I find more readable than OCaml are Ada, Pascal and SML. What causes mental overhead in OCaml/SML syntax for you? Do you find func test (f func(a int, b int) int, x int) int more readable than val test : (int -> int -> int) -> int Maybe, you've ju…

Yes, I do. Especially when you start considering multiline examples with flow control. There are probably a couple of factors at play:

1. Familiarity. Like (presumably) most programmers, I'm familiar with languages in the C syntax family. Of course you can protest that this is a subjective criteria, but little good that will do you as you try to convince your colleagues to adopt (what they perceive to be) your pointlessly cryptic language for the next project.

2. Visual structure is important and while OCaml's minimalism makes for elegant parser algorithms, it works against human psychology (or so I strongly suspect).

Look, I want to like OCaml/SML. I think the type system is a step in the right direction, but the type system is just gravy and the practical concerns--the fundamentals--are neglected (as much as you may protest to the contrary).

Re: Why Generics?

#245

Post by dllthomas »

AceJohnny2 wrote: post #172
dllthomas wrote: post #118

Earlier quoted context omitted.

Your presentation seems less directional than the original Blub article, FWIW.

Indeed. I remembered some aspect of directionality, but couldn't remember how to present it in as compelling a way. (Also, I don't really agree with some objective single value gradient for programming languages. As for anything with multiple dimensions of value, it's not sortable)

Yeah, I think the less directional presentation is probably better. While we can certainly fit things to various hierarchies (approximately or exactly), enough of programming extends beyond pure expressivity (especially into tooling, social, workflows) that it's easy to not get how useful something can be without the relevant context. (This is something that I'm trying to remember, working in JS now after a few years of professional Haskell.)

From a psychological perspective, the non-directional presentation is also more likely to leave people less defensive and more receptive to the thesis.

Re: Why Generics?

#246

Post by Vendan »

mixedCase wrote: post #112
Vendan wrote: post #95

Earlier quoted context omitted.

What is it when you know about the power of features of the "higher level" languages, like generics, but still chose the "blub language" because of other reasons, like ease of hiring devs?

"Worse is better"

or just "Better has multiple dimensions", and not all of them are "Theoretically purer" or "look how succinct I can write this code". "How hard is it to hire devs?" is just one of those dimensions.

Re: Why Generics?

#247

Post by mcphage »

baby wrote: post #157
filleduchaos wrote: post #145

Earlier quoted context omitted.

Pretty much all syntax is unreadable if you don't know the lingo. For example, try presenting the ubiquitous for (int i = 0; i to ten random people without prior programming experience and see how many of them can correctly tell you what all that means. Similarly, { a, b in a > b } is probably not very clear to people who don't write Swift and perfectly lovely closure syntax to people who do. There's language syntax…

You’re missing my point. While other syntactic elements can be learned, generics can be abused to make the code unreadable.

> While other syntactic elements can be learned, generics can be abused to make the code unreadable.

Substitute "generics" for pretty much any bit of programming syntax, and this statement is still true.

Re: Why Generics?

#248

Post by ernst_klim »

weberc2 wrote: post #244
ernst_klim wrote: post #242

Earlier quoted context omitted.

> Easily visually scanned and parsed with little mental overhead. Sure, I'm asking for actual traits, which makes something easily or hardly parsed. The only languages that I find more readable than OCaml are Ada, Pascal and SML. What causes mental overhead in OCaml/SML syntax for you? Do you find func test (f func(a int, b int) int, x int) int more readable than val test : (int -> int -> int) -> int Maybe, you've ju…

Yes, I do. Especially when you start considering multiline examples with flow control. There are probably a couple of factors at play: 1. Familiarity. Like (presumably) most programmers, I'm familiar with languages in the C syntax family. Of course you can protest that this is a subjective criteria, but little good that will do you as you try to convince your colleagues to adopt (what they perceive to be) your pointl…

> Yes, I do. Especially when you start considering multiline examples with flow control.

Could you show an example?

> it works against human psychology

What minimalism are you talking about? It uses nearly the same notations as mathematicians used for decades. Most of the constructs are very like to those in Python.

Re: Why Generics?

#249

Post by btilly »

majewsky wrote: post #235
btilly wrote: post #190

Earlier quoted context omitted.

It is a hack. The article lists a whole series of things that are standard in other languages that you can't do in go. Here are some examples: Find smallest/largest element in slice Find average/standard deviation of slice Compute union/intersection of maps Find shortest path in node/edge graph Apply transformation function to slice/map, returning new slice/map And here are data structures that other languages have b…

> Multimaps, with multiple instances of a key Isn't this just map[Key][]Value? The standard library uses these in several places, e.g. url.Values and http.Header, with assorted utility functions.

You should send that feedback to the author of the article. I literally just cut and pasted those lists.

Re: Why Generics?

#250

Post by reificator »

mlevental wrote: post #33
reificator wrote: post #14

Earlier quoted context omitted.

> Of course it doesn't help that the go community is convinced that ORMs are evil (which is just posthoc rationalization for being unable to write one). Yep. I held this opinion before Go came out, only because I couldn't write an ORM in Go.

i said the go community - not the developer community. you couldn't have had that opinion as a go user before go came out.

But I do still hold that opinion now as a go user. I'm saying I didn't develop it as a result of not being able to write/use an ORM.

Your wholesale dismissal of all go users that don't use ORMs is what I object to. There are a laundry list of reasons to not use them, simplicity being the largest in my eyes. If you're working with simple queries on a small number of tables/views/etc, there's really no reason to bring in a big heavy ORM.

As your usage scales that choice might change, but until then just do the simplest thing that has correct behavior and minimal magic involved.

Post reply on HN