Didn't see this coming: The Goldman Sachs Github Account • Hacker News Board

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

#111

Post by mkramlich » Mon, May 21, 2012, 12:46 AM UTC

arcdrag wrote: post #97

mkramlich wrote: post #61

Earlier quoted context omitted.

Yep. Don't forget Aspects! "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 th…

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.

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

#112

Post by jrockway » Mon, May 21, 2012, 2:11 AM UTC

arcdrag wrote: post #110

jrockway wrote: post #70

Earlier quoted context omitted.

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 -…

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 ut…

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.

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

#113

Post by hermanhermitage » Mon, May 21, 2012, 2:36 AM UTC

DanBC wrote: post #103

arcdrag wrote: post #102

Earlier quoted context omitted.

Do you think that 100 years from now, anyone other than programming language researchers will have heard of any programming language used today?

Do you think 40 years ago people would have thought that people would still be using C (and derivatives)?

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.

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

#114

Post by nicholassmith » Mon, May 21, 2012, 11:54 AM UTC

jrockway wrote: post #67

user23409 wrote: post #64

We currently do all development in an internal Subversion repository and are not prepared to take external contributions. It's a PR and recruiting tool.

How is that statement good PR or good for recruiting?

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.

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

#115

Post by bradleyjg » Mon, May 21, 2012, 8:37 PM UTC

jrockway wrote: post #112

arcdrag wrote: post #110

Earlier quoted context omitted.

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 ut…

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 use…

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.