Live data from Hacker News

Didn't see this coming: The Goldman Sachs Github Account

github.com

51–60 of 115 posts

Re: Didn't see this coming: The Goldman Sachs Github Account

#51

I fucking hate goldman sachs. Note because of politics. Not because of any financial action they've done. Because they hired that despicable fuck Ulrich Drepper. Seriously, the amount of nice, young people who were forever turned away from GNU/open source with a bad taste in their mouths because of that scumbag dipshit. I don't care if he was right % percentage of the time. The point of a project is to welcome users,…

Everytime I get a glimpse deep into the programming world, I get more scared. I thought this was good ole computer science/programming, built on logic and math not politics. Anyway, it's hard to judge a guy's character from what he writes. Terseness and bluntness in my opinion seems rude, but sometimes is all a guy has left. An exhausted man doesn't want to waste characters typing out frivolities.

As far as Drepper, I have no idea what he's like. I think he should act with respect towards others. He has written substantial things to help others out though: http://lwn.net/Articles/250967/

Re: Didn't see this coming: The Goldman Sachs Github Account

#52
post #23

Earlier quoted context omitted.

Why? Because Java has good, built-in, worldwide namespacing that always works? Or because Java has IDEs that pull in imports automatically so developers don't have to think useless shit? Or is it because you're fanboi who dislikes Java merely because it's Java and choose any opportunity, not matter how inappropriate, to disparege it. Java is by no means perfect, but let's at least pick on it for the things it actuall…

I hate auto-generated code by IDEs. It always produces stuff like... that.

I never use an IDE to edit Java, and that's pretty much what it looks like. To use a class in Java, you must import it first. To import it, you type "import " and then the fully qualified name of the class. From there, you can use the unqualified name.

It's basically like that in every other programming language, though others are less opaque. In Perl, you get a variable called %:: that holds the symbol table, and you can directly manipulate it. That lets you write something like "use all" and use every CPAN module at once. In C, you can include arbitrary source files at arbitrary places, making it possible to import every library with one statement. But in both languages this is considered terrible practice, with most style guides wanting one use or include statement for each library. Exactly the same as Java.

If you were going to complain about the API, you might complain about the "impl" in every import. That's a silly convention that wastes typing. (Also, Google puts their collection classes in the "collect" namespace, saving a few letters over calling it "collections" like Goldman.)

Re: Didn't see this coming: The Goldman Sachs Github Account

#53
post #12
post #9

... import com.gs.collections.impl.block.factory.Comparators; import com.gs.collections.impl.block.factory.Functions; import com.gs.collections.impl.block.procedure.CollectionAddProcedure; import com.gs.collections.impl.collection.mutable.AbstractCollectionAdapter; ... Gees, I feel sorry for people still stuck using Java.

You don't have to be so explicit: import com.gs.collections.impl.*; Just out of curiosity, how are imports done in your language of choice?

I can't speak for jlarocco, but my concern is not directly the import statements, but rather, what those import statements imply.

That repo has 1,290 files. Excluding file pathnames containing 'test', there are 601 files. Of those, 430 are .java files.

Java is complicit in that crime, but Enterprise Java is the bigger culprit. The library makes doing a map on an array cleaner for me, but behind the scenes it is using a dozen "factories", a bunch of "builders", several "strategies", and a handful of "visitors", "bridges", and "proxies".

And guilt by association is valid here. We bleed over whether semicolons are needed in some languages, but Java is off limits for needing 10-fold more boilerplate code for something most languages handle out of the box?

Re: Didn't see this coming: The Goldman Sachs Github Account

#54

Earlier quoted context omitted.

I believe GPLv2 has a clause against kicking puppies

Douglas Crockford puts an anti-puppy-kicking clause in his OS licenses. www.json.org/license.html

I actually looked, there is no such clause :(

Well, to be specific, there is no clause that prevents you from kicking the puppy yourself just for the hell of it. There is a clause that prevents you from using 'the software' to kick a puppy, assuming 'kick a puppy' qualifies as evil.

Also gullible is not written on my ceiling.

Re: Didn't see this coming: The Goldman Sachs Github Account

#55
post #33

Earlier quoted context omitted.

You realize that any modern language is nothing more than an abstraction layer to automatically generate code in a lower level language right? The only difference here is that if you view the .java file in a plain text editor, you'll actually see that block. You won't see it in modern IDE's though. It gets automatically collapsed, as it is an aid to the compiler more than the developer.

One viewpoint is such noise doesn't scale - both for tooling or human consumption. Java and C# are both heading into a territory where it is getting less reasonable for a human to write them without tooling support - is this what people really want? If we have such sophisticated tooling why bother dropping to low level text? Wouldn't it make more sense to manipulate and compose more expressive objects than text? The…

I disagree. It's the concise model that can't scale without tool support. Imagine you import foo.∗, bar.∗, and baz.∗. How does someone reading the code know where the Quux class comes from? They can't, without checking all of the namespaces that were imported. But if you just "import foo.bar.baz.Quux", then you know exactly where Quux comes from.

This whole thread sounds like a lot of non-java-programmers complaining about Java.

(Note: incorrect * used above because HN's parser sucks.)

Re: Didn't see this coming: The Goldman Sachs Github Account

#56
post #9

... import com.gs.collections.impl.block.factory.Comparators; import com.gs.collections.impl.block.factory.Functions; import com.gs.collections.impl.block.procedure.CollectionAddProcedure; import com.gs.collections.impl.collection.mutable.AbstractCollectionAdapter; ... Gees, I feel sorry for people still stuck using Java.

Why? Because Java has good, built-in, worldwide namespacing that always works? Or because Java has IDEs that pull in imports automatically so developers don't have to think useless shit? Or is it because you're fanboi who dislikes Java merely because it's Java and choose any opportunity, not matter how inappropriate, to disparege it. Java is by no means perfect, but let's at least pick on it for the things it actuall…

I can't speak for jlarocco, but my concern is not directly the import statements, but rather, what those import statements imply.

That repo has 1,290 files. Excluding file pathnames containing 'test', there are 601 files. Of those, 430 are .java files.

Java is complicit in that crime, but Enterprise Java is the bigger culprit. The library makes doing a map on an array cleaner for me, but behind the scenes it is using a dozen "factories", a bunch of "builders", several "strategies", and a handful of "visitors", "bridges", and "proxies".

And guilt by association is valid here. We bleed over whether semicolons are needed in some languages, but Java is off limits for needing 10-fold more (auto-generated?) boilerplate code for something most languages handle out of the box?

Re: Didn't see this coming: The Goldman Sachs Github Account

#57
post #53
post #12

Earlier quoted context omitted.

You don't have to be so explicit: import com.gs.collections.impl.*; Just out of curiosity, how are imports done in your language of choice?

I can't speak for jlarocco, but my concern is not directly the import statements, but rather, what those import statements imply. That repo has 1,290 files. Excluding file pathnames containing 'test', there are 601 files. Of those, 430 are .java files. Java is complicit in that crime, but Enterprise Java is the bigger culprit. The library makes doing a map on an array cleaner for me, but behind the scenes it is using…

This has nothing to do with Java. I thought the same thing until I started working for Google. There, I saw correctly designed APIs that are pleasant to use, all while still being standard Java.

As an example, with Google's collection library (Guava), you might create a set like:

   import com.google.common.collect.ImmutableSet;
   ImmutableSet foos = ImmutableSet.of(bar, baz, quux);
This is simple syntax for a simple operation, which is the point of libraries.

(Goldman also has a lot of mutable data structures. I don't think I've used or created a mutable data structure at Google ever :)

Re: Didn't see this coming: The Goldman Sachs Github Account

#58
post #33

Earlier quoted context omitted.

You realize that any modern language is nothing more than an abstraction layer to automatically generate code in a lower level language right? The only difference here is that if you view the .java file in a plain text editor, you'll actually see that block. You won't see it in modern IDE's though. It gets automatically collapsed, as it is an aid to the compiler more than the developer.

One viewpoint is such noise doesn't scale - both for tooling or human consumption. Java and C# are both heading into a territory where it is getting less reasonable for a human to write them without tooling support - is this what people really want? If we have such sophisticated tooling why bother dropping to low level text? Wouldn't it make more sense to manipulate and compose more expressive objects than text? The…

The very best chess teams consist of a computers and a humans cooperating with each. The computer insures perfect tactically play while the human concentrates on overall strategy.

Why should programming be any different? The very best IDEs in the hands of a skilled programmer should produce code better than a similarly skilled programmer who insists on using a dumb text editor. If the resulting code can only effectively be modified by a similar computer/human team - well that's a small price to pay.

Re: Didn't see this coming: The Goldman Sachs Github Account

#59
post #23

Earlier quoted context omitted.

I hate auto-generated code by IDEs. It always produces stuff like... that.

I never use an IDE to edit Java, and that's pretty much what it looks like. To use a class in Java, you must import it first. To import it, you type "import " and then the fully qualified name of the class. From there, you can use the unqualified name. It's basically like that in every other programming language, though others are less opaque. In Perl, you get a variable called %:: that holds the symbol table, and yo…

But, if you're using a modern IDE, removing impl or going from "collections" to "collect" isn't saving anyone any time. Or, at least, it shouldn't be.

Re: Didn't see this coming: The Goldman Sachs Github Account

#60

Earlier quoted context omitted.

One viewpoint is such noise doesn't scale - both for tooling or human consumption. Java and C# are both heading into a territory where it is getting less reasonable for a human to write them without tooling support - is this what people really want? If we have such sophisticated tooling why bother dropping to low level text? Wouldn't it make more sense to manipulate and compose more expressive objects than text? The…

I disagree. It's the concise model that can't scale without tool support. Imagine you import foo.∗, bar.∗, and baz.∗. How does someone reading the code know where the Quux class comes from? They can't, without checking all of the namespaces that were imported. But if you just "import foo.bar.baz.Quux", then you know exactly where Quux comes from. This whole thread sounds like a lot of non-java-programmers complaining…

I'm not too fussed with the namespaces - I dont think you will find anyone arguing against that.

What is at issue is the over specialization of class or framework components because of language limitations.

A language that leads to degenerate boilerplate or mounds of endless repetition (but in user land code and libraries/frameworks) can be viewed as having a serious abstraction problem.

Do you really think java will be looked at in 100 years as the pinacle of language evolution or some horrible dead end? Like cobol or basic?

Post reply on HN