I can understand the reaction on this community to the news, and I'm sure that there are elements of PR and recruitment strategy here, but I happen to know that the primary driver is pretty sound; job satisfaction for top employees.
Goldmans has its share of top programmers and, like any company, is keen to retain them. One of these people made contributing to Open Source a major goal for last year.
Well done to him, and well done to GS for supporting him. The company (rightly) gets a ton of bad press, but that doesn't mean it can't do good things as well.
Disclaimer: I'm an ex GS employee, but have nothing to gain.
When I interviewed at GS last year, I was explicitly told that I would not be able to go on working on open source (they had checked out both my blog and my Github). This despite none of the technologies in my main project being in use in the group I was interviewing with...
I guess it probably depends on the position/team. I wouldn't expect GS to open source anything they consider a competitive advantage, but then I don't see Google open sourcing their search algos either :-)
I agree. I can't say I like standard practise of employers owning everything their employees do whether in or out of work, or requiring that you stop anything they don't own.
However, this is hardly something that is limited to Goldmans or financial services. I'm pretty sure that Apple require you not to work on side projects, for example.
We had a discussion regarding this at my company - Future Workshops - last week, and decided that what people work on in their own time is their own business, with the caveats that a) people don't work in conflict with any clients, b) the IP is clearly separate, and c) it doesn't affect their day job in a negative way.
Let's not call this a "standard" practice. In my experience, most companies do no make claims to your off-the-hours projects. And that is how it should be. Unless you're doing some cutting edge AI research or something of that sort, this kind of legal claim is just paranoid stupidity. Even if you do cutting edge AI research, it shouldn't entitle your employer to own a phpBB patch you've done in your free time.
It's a recruiting tool, that's all. They want to be a bit open sourcey to attract top talent. The broken unit test battery that comes with it is a job interview tool.
I would guess this was initiated by IT employees (open sourcing the library might make life easier for them, assuming someone outside the company contributes) and approved by top managers (because it's good for recruitment and makes their IT staff happier).
However I would doubt this will make a big difference when attracting top talent. One important reason for that being (IMO) that the best IT people prefer innovative technologies and GS uses a proprietary in-house programming language and db for everything that's important. Some say their tech was perhaps innovative 25 years ago http://stackoverflow.com/questions/3392636/slang-goldman-sac... .
Not to mention that if you work for GS you lock yourself in those in-house techs. When I went to a job interview at GS and asked what the advantages of using an in-house language and db were, I was told that it's very hard to hack their systems, because no one else uses them (Not sure how valid this argument actually is though).
Why not? It's a large corporation with many branches and technical needs, some of which are harmless to open-source. Despite its reputation, I don't think they go through their day thinking "hmm... we could open-source this, or we could go kick a puppy instead! Muahahaha!"
It might be nice to have a chuckle about "do no evil" in a copyright licence, but that's a massive loophole that the original author could use to stop almost anyone from using their software.
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.
It might be written on the bottom of your shoe, have you checked? :)
Sometimes I think I'd like to release under a "you cannot use software patents in anger" license that restricts behavior outside of the software usage. But that's probably too restrictive to catch on.
Not to troll here, but in all honesty I thought GS was the kind of company which would prefer to spend money kicking puppies, than open sourcing a library they wrote. ;)
This will surely earn them some cred from the programming community.
In the industry, they've actually got a formidable reputation for IT systems that actually work. I've worked with a few ex-GS people at various different firms, and none of them miss the hours, but all of them miss the IT.
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 actually does poorly rather then just picking on it because it's no longer considered cool.
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?
Many people find those patterns help them understand the code. I often see terrible bespoke code, where half the problems could fixed using a design pattern where those problems have already been considered.
It works both way, there are many acceptable times to use a design pattern, and many non-acceptable times.
"But, but... a good IDE can make all this boilerplate be less painful!"
Of course, you could just not have the boilerplate, abstraction and over-complexity to begin with, use a simpler language & ecosystem like Python, and just code in vi.
"I don't want to learn how to use an IDE" is the same argument as "I don't want to learn how to use vi". There are a lot of reasons to hate Java...I don't want to use a bloated IDE is a pretty weak one in an age of 8 core processors and 32 GB of ram.
Also, many Java shops do so because few other languages are an option when you need 200+ trained developers, as few cities even have 200 experienced Python devs. Then there's performance, as Java performs an order of magnitude faster than Python for many operations.
The vast majority of dev workstations in the real world have far less than 8 cores and 32 GB of memory. Also it's not about "bloat" in some abstrance sense, I've found, but rather about the noticeably slower interactivity, the mysterious delays, the mysterious crashes, and the overwhelming surplus of unnecessary visual/cognitive vomit occupying the screen real estate at any time. Oh and Byzantine IDE configuration option panels. And the always-harder-to-automate nature of GUI interfaces. And the local drive bias. And every other "feature" they add that you're supposed to appreciate as some new gift from the gods turns out to be something you could already do, for free, on the command-line or with a vi/emacs-style terminal-friendly UI. I have a lot of experience working in both paradigms and I know which one I've found to be better. I think the last fast/simple/non-crashy/non-visual-vomit IDE I experienced was TurboC in the early 90's. It's been mostly downhill ever since.
I think a lot of shops that think they need 200 developers, and thus it's easier to get Java than Python developers and thus should use Java, etc., may have made a base assumption after which all following deductions are dependent. If instead of starting with assumption you need 200 developers you instead think we only want a few smart/elite developers, then you can have a smaller total headcount, a less enterprisey tech stack, and less mindless process and makework. I've seen and heard of small teams that run circles around large bloated enterprise shops for just these kinds of factors.
Also I guarantee you that in the vast majority of real world programming situations needed by large companies the software is mostly not CPU-bound but rather IO-bound, and any greenfield or maintenance development is mostly bug-bound or developer-hour-and-quality-availability-bound and bureaucracy-bound. CPU time is cheap and lots of ways to parallelize, defer and cache. Software developers are not cheap. Well, worse software developers can be "cheaper" superficially but end up being more expensive due to being slower, dumber or less knowledgable of implementation options, and needing much more of them. CEO salaries and their royal court are extremely NOT cheap.
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.)
What do you use? I find it extremely painful to write Java in Vim, even though I have been using Vim for quite some time and am very comfortable using it. Text based completions and re-factoring doesn't cut it for Java/C#, so I use eclim to use what eclipse is good at which comprises of smart auto-complete, auto-imports, generating getters and setters, implementing interface, auto-correct code for trivial cases etc.
> 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.
That's similar in Python. I think the parent post wasn't complaining about namespacing but the way project is structured and named(impl, factory).
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 end game is you obsolete the languages and they become targets of more expressive languages.
It highlights a potential design flaw in the composition model of the language and/or the libraries.
Should for example C/C++ include the generated assembler in pragmas to guide compilation? Always? Visible to the programmer?
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.)
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?
(I just wrote a long rant about this, but on my internal blog, so I'll summarize here. They have 12 classes implementing immutable lists. A class for an empty list. A class for a list with one element. A class for a list with two elements. That continues to 10 (!!!!) elements. Then there's a class for lists greater than size 10. This pattern is repeated for all the other types. That's going to be messy in any language. Google seems to survive with 0-, 1-, and n-element classes.)
Yes a very interesting point. You could even replace C in that sentence with Algol and it rings fairly true.
In C it always feels like the pillars were speed of implementation and speed of execution on low cost hardware and without sophisticated compilation technology.
Ignoring syntactic issues there are only a few things I wish it had as part of the specification (when viewing it as a (if used in a certain manner) portable minimum viable language where assembly language meets high level languages):
1. A better implementation of Landin's J operator than setjmp
2. Compile, Link, and Load time reflection
3. Portable dynamic code generation (at runtime) operators (to allow late binding and JIT style optimization).
Java can be also viewed as a reworking of Algol but this time with design pillars centred on working in a VM, modularity for large code bases and simplification principles.
It always feels to me like the simplification was intended to reduce complexity (originally: signed ints, no function pointers, no lambda, no manually managed memory objects) but unfortunately this has just pushed huge complexity into code bases. Whilst I can accept this in C (minimum viable human readable and writable portable code), for some reason because Java sits on a huge stack of runtime code and tooling I dont like it. What Java did really bring to the mainstream is the whole VM thing (although some of us will remember BCPL or UCSD p-code), but I think the VM brings too much Java-ism into it and a smaller and better VM lies within.
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.
I made a vow to myself to never reply to a comment that used both "tactics" and "strategy" in the same sentence, but here goes...
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.
That's true, but show me an IDE that lets someone write better code than someone without the IDE. The reality is that IDEs provide very superficial features that help beginners be more productive, but don't help experienced programmers much. (The most cited feature, symbol completion with docstrings, is available in pretty much every text editor. It's nice confirmation that your mental model matches the tags table, but hardly essential.)
All I can say is: Java got a lot easier for me when I stopped trying to make Eclipse useful. It turns out that Eclipse doesn't really do anything except sleep(5) after every keystroke.
The speed and manner in which the full version of Visual Studio allows you to debug container objects and jump JIT to the code currently executing to look at the call stack and inspect variable values, is not superficial. As a text editor, code writing tool, sure it's not much better than a standard editor. As an IDE with a debugger it allows an experienced developer to debug faster and write better code more quickly. Even experienced developers have to debug their code, and it is time consuming even for them.
Eclipse is not Visual Studio though I've heard good things about IntelliJ IDEA.
The refactoring tools in IntelliJ make it possible to catch a lot of things that would be very difficult to do with emacs of vim. For example, I know a certain utility method exists in several different classes, so I want to extract that method and utilize it throughout my project. The IDE will search the project for any block of code that meets this pattern and will ask you if you want to replace it with this new utility class instead. For smaller projects (<25k LOC) this isn't a big deal, as any major dev will have seen every line of code. For very large projects, I can't imagine going back.
Also, if you're basing your IDE experience solely on Eclipse and Netbeans, give IntelliJ a try. Both Eclipse and Netbeans pretty much seem unusable after you use IntelliJ for a while.
I don't think "very large" means what you think it means :) I work on a codebase that recently passed commit number 30,000,000. I don't know how many lines of code that ends up being, but it's a lot :)
Basically, my experience with IDEs at Google is that none of them can handle our repository. Even managing the transitive closure of a single project, Eclipse randomly freezes while typing. I don't know anyone that uses Eclipse anymore. Most of my team uses IntelliJ, but even then, the codebase is just too big for it. People type something like com.google.commons.collect.L and see no results (when the right answer is "Lists"). I haven't debugged this, since I don't have any interest in using IntelliJ, but the number of times a day I'm brought to someone's desk to "watch this", I don't think it would work for me. I'd rather have consistent limitations than random failures. Emacs won't iterate over every Java file in Google's repository to complete "Lists" as above, but if I've used it in another file, it will.
The good news is, we have an internal code indexing system that provides an RPC API for many of the IDE features, including completion and duplicate code detection. (But most of the Java chores that people love their IDEs for are handled in other ways at Google. I don't think I've ever written a getter or setter, for example, because every class I've written has been immutable with private internal state. When your objects aren't dumping grounds for other objects, you don't need to get or set anything! :)
Like I've said in other comments, I would never do Java outside of Google. But since I'm here, I have nice tools available to me and using Emacs for Java is no problem at all.
The great-grand parent's original point was that a language that needs tools to be written effectively is a flawed language. If I diverted that into a meaningless argument about what type of tools are best, then I apologize.
I stand by my original point though. I wouldn't want to write in any programming language without tooling and the availability of sophisticated tooling (of many different styles) for a given language is a strength not a weakness.
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.
Except, we're using computers to help assist us with a terrible codebase that is unnecessary complex and verbose.
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.
Vim and emacs not "dumb text editors". They are very powerful tools in the hand of a skilled programmer.
> 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.
The very best IDEs produce code at the skill level of dumbest programmers - generating getter-setter, or importing, or wrapping something in try-catch...From the top of my head, I can't think of a single instance where the code produced by IDE can be considered semi-intelligent, let alone at par with code produced by skilled programmer.
And code produced by a skilled programmer using a dumb text editor? A skilled programmer using notepad, eclipse and vim produces different code in all 3?
>The skilled programmer can still improve the unintelligent code.
In my experience, fixing a crap piece of code (Usually called refactoring.) takes longer than just writing a correct implementation from scratch. In most cases.
I think you missed the "computer" part in "computer programming language". It's there because it needs to be for the JVM. It resolves naming conflicts so that having two "component.java" files in the same project don't end up blowing the whole thing apart.
No Java devs actually type any of that. Java IDE's are very good at generating this sort of code...for this very reason. No one would still be using Java if they actually had to remember full package names.
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?
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:
Took a quick look, GS Collection seems to be a similar library like Google Guava; a nice functional library helper to perform operation against Java collection.
GS Collections also seems to have new implementations of the basic Java collections (implementations of List<T>, Set<T>, etc.). I haven't studied them sufficiently to say whether I like them better, though.
At first glance I think I dig Guava's API a little more, but I haven't looked closely enough to really have an opinion.
The examples they give seem to be pretty much standard functionality of the Guava Collections2 class. With Guava quickly becoming one of those standard libraries that just gets automatically added to virtually every new project, I don't see much reason to use this.
Not to take away from the act of open sourcing it, but I think Google's guava library is a lot more polished. But I expect Google has spent a heck of a lot more manhours on their library.
It's not good for either, but if this was an attempt at open source 'out reach' then they're kind of failing at delivering by not taking pull requests. That leaves it being a weak attempt at PR/recruitment.
Have you ever used it or any other APL? I'm currently getting familiar with K, which is the language Whitney and the company he founded (Kx Systems) after he left Morgan Stanley made, but from an open source implementation called Kona by Kevin Lawler and Scott Vokes: https://github.com/kevinlawler/kona
Reminds me of the completely Open Source financial analytics company Open Gamma (http://www.opengamma.com). They also have a GitHub account with (in their own words) functional java code https://github.com/OpenGamma.
This Java paradigm of "private final static" all over the place and its ugliness is one of the prime reasons Rich Hickey considered creating Clojure.
Software is eating the world. But I really shouldn't be surprised as I am at this one, since trading is well-known to be the most algorithmic math-geek industry at present.
This does not seem to be new. According to their profile they have had an account since Dec 16, 2011. This might be the first time they have open sourced anything though.
Why simulate Lambda? Couldn't they just have waited on Java 8? Or maybe just used JRuby, if Java was a requirement? Still- it's great that they shared this.
Java 8 is still probably a minimum of a year or 2 off. After that, it will go through another year or two of testing before any big corporation will dare even bother touching it. After that, it might start being used for new apps, but it will be another 2-3 years before it has widespread adoption.
On the flipside, what they've done isn't exactly groundbreaking, and could be used with Java 6.
They don't want lambda just because they want lambda. They want function collections with filters and transformations, and you can't have that without lambda. When Java 8 lambda syntax arrives, it will be compatible with this and Guava.
They also likely have no interest in using JRuby because it isn't statically type safe and therefore adds another category of things that can go wrong at run time that is completely unnecessary to test for when using Java with Generics.
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, and if you can't do that, why the fuck are you maintaining it?
I mean fuck, how many projects switched their libc implementation because of that fuck? Fuck. Fuck that guy.
The worst part? I didn't even get something rejected by him. I've just read enough of the communications with that guy to have his name seared into my brain next to the part that produces bile.
Tennyson once defended Thomas Carlyle and Jane Welsh's notoriously tempestuous marriage by noting that "By any other arrangement, four people would have been unhappy instead of two".
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/
Search "ulrich drepper arrogant" Seems he's has a bit of an attitude problem or something (or as LWN put it, "his blunt manner".) http://lwn.net/Articles/333755/
Based on your comment, I'd say you're letting him win.
Doesn't the world have enough issues without jumping on the "fuck Ulrich Drepper" bandwagon? Keep a mental note that you'd rather avoid him in your career and personal life, then move on. You're heading for an ulcer.
People like to name-drop to show that they're "in" a certain community. If you know and hate Ulrich Drepper, you're cool, because you hang out in the glibc community. Even better if you know where he works, that means you probably know him in real life, tripling your coolness.
Of course, when explained, it doesn't quite sound as cool... but I assure, the OP is very cool indeed...
Goldmans has its share of top programmers and, like any company, is keen to retain them. One of these people made contributing to Open Source a major goal for last year.
Well done to him, and well done to GS for supporting him. The company (rightly) gets a ton of bad press, but that doesn't mean it can't do good things as well.
Disclaimer: I'm an ex GS employee, but have nothing to gain.