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

A History of IDEs at Google

laurent.le-brun.eu

Post reply on HN
Print view View original

241–250 of 333 posts

Re: A History of IDEs at Google

#241

Post by paul_h »

cletus wrote: post #40

There's more history than this. Disclaimer: Xoogler (2010-2017). When I first started the environment you used depended entirely on language. In the C++ and Python space, there was the vim and emacs divide. With Java it was more complicated. Some still used vim/emacs but a lot of people used Eclipse. Now Eclipse was a real problem at Google because of the source control system. Java IDEs are primarily built to import…

I recall a couple of JetBrains staff visiting in 2008 to see IntelliJ's struggle with the size of checkout for AdWords. Soon after the reindexing front/center dialog moved from blocking and center of window, to a status line message that was non-bloking of edits at the bottom of the window. It may have been due anyway but was shown as problematic in the same moment.

Re: A History of IDEs at Google

#244

Post by computerdork »

InfiniteRand wrote: post #175
computerdork wrote: post #106

Earlier quoted context omitted.

haha, that's a great way to put it! And I get the overall gist of it, but why monkeys? :)

Because it's international waters

This is a very confusing but enlightened response. Will have to ponder on its true wisdom:)

Re: A History of IDEs at Google

#246

Post by barrkel »

Analemma_ wrote: post #228
barrkel wrote: post #35

Earlier quoted context omitted.

You want bazel. Once you've internalized the bazel (blaze) system, you want all builds and tests to work that way.

Maybe, but I feel like an article I’ve read many, many times is “we hired one or more Xooglers for our startup and this turned out to be a catastrophe because they insisted on trying to bring blaze/bazel with them and it nearly destroyed the company.” It’s always bazel specifically in these articles, never any of the other internal Google stuff like Spanner.

I mean, bazel is great and I would use it when building a codebase from scratch, but the win from switching from one build system to another is, at best, some efficiency, and you need a lot of aggregate efficiency gains to pay for effort.

Re: A History of IDEs at Google

#247

Post by bruckie »

spwa4 wrote: post #202
hcnews wrote: post #163

Earlier quoted context omitted.

There was a code reviewer starting with M before Critique iirc (Mondrian I wanna say?). The M code reviewer was completely written in Python iirc.

No I mean that in code search you could click "edit" and just change something, which would then post a CL immediately, which you could set to auto-approve, for quick changes. I believe it was part of cider (the first non-vscode version)

The first version was part of Code Search proper, and wasn't super useful for much more than just typo fixes, since it was essentially just a textarea edit box. That was eventually deprecated and replaced with a button that did the same thing, but opened in Cider instead.

Re: A History of IDEs at Google

#248

Post by computerdork »

taeric wrote: post #133
computerdork wrote: post #110

Earlier quoted context omitted.

Think for a large tech company, they did a really good job with success in software. For exammple, they were probably the first large tech company to realize AI was actually working, and made it their focus: https://www.businessinsider.com/sundar-pichai-wants-to-build... And yeah, they did/do a lot through acquistions, but seems like most major companies screw up acquistions. Google has it's fair share of failed acqu…

My point on the acquisitions was that a surprising amount of their successful software was not made in house. Again, I don't mean it as a knock against them, necessarily. AI is an odd example. For one, a lot of the research there is from acquisitions. Somewhat feeding back to my first point. They also were seen as tripping up on a lot of the current AI race, no?

Referring to DeepMind in the UK? Ah yes, that’s definitely through acquisition.

But even though their AI models aren’t the absolute leaders in every field, all their models are near the top, across the board. Yeah, their recognition of this current dominant trend before any other major company has given them a big advantage in the number of fields they’ve applied AI to. For example, by putting their full weight behind DeepMind early on, they had a bunch of models before anyone else dealing with topics from protein folding to playing games. Think for them, this might be the right strategy. Explore as much in AI as you can, and figure out the ways it is truly revolutionary. Don’t focus so much on creating products that will make money today or even in near future. Take the long view… hmm, actually, a good example of this is Waymo, it seemed stalled out a few years ago, but is the clearly the best self-driving cars currently out there and finally growing market share.

Also, it was their researchers who kicked off the LLM race with their seminal paper on transformers in 2017 (yeah, they should have released an LLM first, but think they have made up for it since then).

Yeah, am trying not to be overly enthusiastic, but still, despite a couple of big mistakes in AI, they seem to have made mostly correct calls for the past ~10 years. It’s an impressive track record at least to me.

Re: A History of IDEs at Google

#249

Post by dmoy »

materielle wrote: post #128
cletus wrote: post #40

There's more history than this. Disclaimer: Xoogler (2010-2017). When I first started the environment you used depended entirely on language. In the C++ and Python space, there was the vim and emacs divide. With Java it was more complicated. Some still used vim/emacs but a lot of people used Eclipse. Now Eclipse was a real problem at Google because of the source control system. Java IDEs are primarily built to import…

One important piece of context that might make all these stories less confusing for non-googlers: Code references are less important inside Google editors, because we have a code viewer tool inside the web browser. Most people read, explore, follow references, and share permalinks to the view-only tool. It’s a lot better than viewing code in GitHub. It’s super fast, is connected to language servers and can actually t…

> It’s super fast, is connected to language servers and can actually trace referenced

Nit: not connected to language servers, it's connected to Kythe. LSP doesn't have the same kind of functionality.

Re: A History of IDEs at Google

#250

Post by saltmate »

rossjudson wrote: post #214
squirrellous wrote: post #185

Something that amazed me around the time Cider V was first introduced is that some folks have been at Google for so long, they have never used VSCode, and didn’t recognize the UI at all.

100% up-to-date VSCode is still pretty trashy, IMO. It's a mixed bag of plugins without cohesion, no awareness of code other than what that mixed bag attempts to provide (poorly). It is and always has been little more than a progressively more complicated mobius loop of autocompletion-oriented UI experimentation. Ah, I feel so much better now. ;) VSCode never made it past the first 10% of what Eclipse did (does). VSC…

Do you have an example of what eclipse can do that VScode can't?
Post reply on HN