Less is exponentially more (2012) • Hacker News Board

Re: Less is exponentially more (2012)

#61

Post by s17n » Tue, May 12, 2020, 5:44 PM UTC

jahaja wrote: post #13

hyperman1 wrote: post #5

A few years ago I started to play with go. First impression was great. But a month or so in I started to having more and more doubts. As a Java/C++ programmer I was missing especially the generic collections. Slice and map are a good start, but not enough. Then one day I had to implement the swap operation for sorting. Again. And I thought that even C's qsort was better, and WTF am I wasting my time on this half-asse…

> I'm not working with an ecosystem where my human time is less important than the language philosophy. I want to express a repetitive pattern in the language, and then never think about dumb bureaucratics again. Writing code is not where time is spent. Repeating oneself, duplicating code, is fast and easy. Debugging someones code that felt like "expressing" themselves through it however, takes time, and a lot of it.…

Kinda sad that this is getting downvoted, regardless of whether you agree it is certainly a cogent argument.

Re: Less is exponentially more (2012)

#62

Post by DLA » Tue, May 12, 2020, 5:56 PM UTC

dunefox wrote: post #56

DLA wrote: post #26

I'm going to jump in and take a hard Pro-Go stance. Based on experience developing for more than 5 year with Go and deploying systems around the world--in-house hosted and cloud. I have immensely enjoyed the "less is exponentially more" philosophy with Go. In Go there is one or a small number of way to do something. Contrast that with C++ where there are any number of ways to do something and at least as many styles…

> I abhor the Java ecosystem for so many reasons I just don't have the energy to go into. If you can gather some energy, I'd be interested in that.

Like I said there's nothing wrong with the stack. I was ONLY speaking of my personal preferences why I choose not to Java when I can Go: Just personal preferences.

-- Compile times!

-- Operational complexity vs. Go.

-- Built-in tooling vs. Go.

-- Verbose XML configuration files.

-- Lots of libs favor XML vice JSON.

-- Deeply-nested code directories.

-- Class-centric model (only).

-- Verbosity and boilerplate.

-- Factories of factories of factories. :)

-- JVM install and config (many dials = control but also complexity).

-- Impractical / painful to write without an IDE.

-- Concurrency model, as compared to Go.

-- Std lib not matched to work I use Go for.

-- Memory consumption.

-- Performance (for the work I do).

-- Multiple inheritance (allows unnecessary complexity).

-- https://astaxie.gitbooks.io/build-web-application-with-golan... vs. https://medium.com/@ssaurel/create-a-simple-http-web-server-...

-- Oracle.

(edits: reformat pretty; compile times)

Re: Less is exponentially more (2012)

#63

Post by pjmlp » Tue, May 12, 2020, 6:03 PM UTC

sanderjd wrote: post #33

eriktate wrote: post #31

Earlier quoted context omitted.

> And I find it pretty unreadable, it's not nearly as expressive as other languages I enjoy using. I tend to conflate higher expressiveness with being "clever" until you're really proficient in the language. I think Go's main value prop is that it performs well with very little ramp up time compared to languages with more powerful features. If you have a team of people who are really strong with something like OCaml…

The basic set of more expressive operations (like map, filter, and reduce/collect) are not "clever", they exist in lots of "boring" languages, not just languages like OCaml and Scala. It is true that their semantics must be learned, but this is also true of the semantics of for, while, if, switch, function(), object.method(), etc. etc. We don't lament that learning how function calls work is lengthening the ramp-up t…

The irony is that even modern Basic is a clever language, and Python comprehensions are probably a PhD level feature, yet primary school children seem very at ease with those languages.

Re: Less is exponentially more (2012)

#64

Post by pjmlp » Tue, May 12, 2020, 6:04 PM UTC

dhsksndjsb wrote: post #12

ses1984 wrote: post #4

>Programmers who come to Go from C++ and Java miss the idea of programming with types, particularly inheritance and subclassing and all that. Perhaps I'm a philistine about types but I've never found that model particularly expressive. Whoa, hold it there... inheritance and subclassing are OOP, types is a different subject, right?

OOP involves a type hierarchy, which is a prerequisite for giving meaning to the idea of inheritance. You can't talk about classes without actually talking about types, and inheritance creates a type hierarchy. From golang documentation: "Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy. The concept of “interface” in Go provides a different approach that…

Nope, it depends pretty much on the OOP language, there are a couple of CS variants to chose from.

Re: Less is exponentially more (2012)

#65

Post by AnimalMuppet » Tue, May 12, 2020, 6:08 PM UTC

pjmlp wrote: post #60

AnimalMuppet wrote: post #38

Earlier quoted context omitted.

First, combining two successful languages in no way guarantees success. (Imagine combining Lisp with C++ syntax.) There are lots of ways to do it where the whole is less than either of the parts. Second, you seem to have a strange definition of "success". Limbo was a success? Well, some people used it, and some software got written in it, and some people used the software. Not much software and not many people, thoug…

Exactly, that is why it was needed to add the Google branding into the mixing potion. Had Go been created at Bell Labs or ETHZ, and it would have shared the same fate as its influences. You missed the sarcasm on my comment.

Ah, I see. Sarcasm often doesn't come across in a post. But yes, I was surprised by your post, because it didn't sound like your usual position. I should have suspected sarcasm.

But I disagree with you. Bell Labs was adequate branding for C and Unix, but not for Limbo or Plan 9. Sun's branding (and relentless support) was necessary for Java, but who did the same for Python, Perl, or Ruby?

It's not just the branding or the marketing. Sooner or later, how well the language enables you to write programs has an effect on language popularity and uptake.

Programmers aren't just fashion-driven sheep led around by marketing departments. They actually use the languages, and they can in fact tell when the language makes things easier or harder.

Re: Less is exponentially more (2012)

#66

Post by cannabis_sam » Tue, May 12, 2020, 6:13 PM UTC

nshepperd wrote: post #29

> Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark. > ...[rant about 'inheritance' and 'subclassing' and 'hierarchies']... > If C++ and Java are about type hierarchies and the taxonomy of types, Go is about composition. How do you get all the way through designing a programming language with…

The explanation is actually simple:

«Rob Pike doesn’t know what type theory is or why it is useful»

Look at his latest statement on «generics» in Go: https://evrone.com/rob-pike-interview

He acknowledges that parametric polymorphism is a good thing that Go is gonna get, but then repeats his ignorant view on types by conflating type theory with shitty OOP inheritance and class hierarchies.

Re: Less is exponentially more (2012)

#67

Post by AnimalMuppet » Tue, May 12, 2020, 6:20 PM UTC

sl1ck731 wrote: post #58

AnimalMuppet wrote: post #34

Earlier quoted context omitted.

OK, but for Go to succeed in that environment, it had to be better than Python and Java at programming for the cloud. It doesn't matter that Python and Java were "aging" - programming languages don't die from old age. Go had to be better than what was there. And in what ways was it better? Power and simplicity (at least for writing those kinds of programs).

Why did it have to be better? It just had to be created and evangelized to a specific group (and likely because it was by a specific company). I don't think it has anything to do with "better" in one way or the other. Developers are constantly looking for new languages to fiddle with without any objective reasoning.

Sure, they're looking for new languages to play with. They're not looking for new languages to write major projects in, though. You write major projects in languages that you have already fiddled in, and the fiddling has given you confidence that they're up to the task. Nobody (sane) sees a publicity blurb and decides to bet a major project on it.

Don't confuse "they came to a different conclusion than me" with "they're sheep".

Re: Less is exponentially more (2012)

#68

Post by sanderjd » Tue, May 12, 2020, 6:48 PM UTC

nobleach wrote: post #46

sanderjd wrote: post #33

Earlier quoted context omitted.

The basic set of more expressive operations (like map, filter, and reduce/collect) are not "clever", they exist in lots of "boring" languages, not just languages like OCaml and Scala. It is true that their semantics must be learned, but this is also true of the semantics of for, while, if, switch, function(), object.method(), etc. etc. We don't lament that learning how function calls work is lengthening the ramp-up t…

Yeah, I think the charge of "clever" is often thrown out when one uses a different way of thinking. I'm not an FP zealot at all, but I do think learning to think recursively does something to one's programming. (Working through SICP or even The Little Schemer) My own personal take it that I appreciated and enjoyed some of those paradigms far more. What I would NEVER try to do is turn Java or Go into those paradigms t…

It is idiomatic in Java to use the streams api for mapping, filtering, and reducing. It is a perfectly natural fit in the language. The only bummer is that those operations can't be built directly into the collections api due to compatibility concerns. It doesn't require thinking recursively or anything clever or advanced, they are very simple operations.

Re: Less is exponentially more (2012)

#69

Post by sl1ck731 » Tue, May 12, 2020, 6:53 PM UTC

AnimalMuppet wrote: post #67

sl1ck731 wrote: post #58

Earlier quoted context omitted.

Why did it have to be better? It just had to be created and evangelized to a specific group (and likely because it was by a specific company). I don't think it has anything to do with "better" in one way or the other. Developers are constantly looking for new languages to fiddle with without any objective reasoning.

Sure, they're looking for new languages to play with. They're not looking for new languages to write major projects in, though. You write major projects in languages that you have already fiddled in, and the fiddling has given you confidence that they're up to the task. Nobody (sane) sees a publicity blurb and decides to bet a major project on it. Don't confuse "they came to a different conclusion than me" with "they…

I mean cargo culting tech and languages is practically a meme at this point in tech. I'm not sure I can scientifically argue that its widespread but I think it is equally futile to argue that it does not happen frequently.

Re: Less is exponentially more (2012)

#70

Post by AnimalMuppet » Tue, May 12, 2020, 7:16 PM UTC

sl1ck731 wrote: post #69

AnimalMuppet wrote: post #67

Earlier quoted context omitted.

Sure, they're looking for new languages to play with. They're not looking for new languages to write major projects in, though. You write major projects in languages that you have already fiddled in, and the fiddling has given you confidence that they're up to the task. Nobody (sane) sees a publicity blurb and decides to bet a major project on it. Don't confuse "they came to a different conclusion than me" with "they…

I mean cargo culting tech and languages is practically a meme at this point in tech. I'm not sure I can scientifically argue that its widespread but I think it is equally futile to argue that it does not happen frequently.

Does it happen? Sure. More often than it should? Absolutely.

Often enough to account for the popularity of Go? I strongly doubt it. It could have accounted for Go's popularity in the first year or two. But now, Go has been used by too many people to do too many things. Go's popularity now is based on its ability to help you get things done, not on Google's name.