351 karma · joined October 21, 2014
And just a side question, it's incredible that her advisor would not use their computer (especially since they were in an analytical field, would think computers were essential for statisticians). What were their reasons? One obvious thought was were they just much older and didn't learn how to use them?
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.
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 acquistions, but especially in the earlier half of the company's lifespan, they really did some great one: Youtube, Google docs, Nest...
maybe am biased, but have always thought Google in general does do it better than most tech companies. think it's their focus on the love of interesting ideas vs the love of money (although, that changes more and more as the company ages)
if you’re a software dev/engineer, if you haven’t made a mistake like this (maybe not at this scale though), you’ve probably haven’t been given enough responsibility, or are just incredibly lucky.
… although, agreed, they were on the cutting edge, which is more risky and not the best decision.
And what a great and very subtle example with the fighter jet control sticks. This reminds of a build time issue I once had. Yeah, way back in college, did really poorly on a final programming project, because didn't realize you were supposed to swap out a component they had you write with a mock component that was provided for you - hard to explain, but they wanted you to write this component to show you could, but once you did, you weren't supposed to use it, because it was extremely slow to build. So they also gave you a mock version to use when working on the code of your main system.
Using my full component killed my build time, as it took 10 minutes to build instead of a few seconds, and it was the one school programming project I couldn't finish before the deadline and was super stressful. Was a very painful lesson but ever since have always found ways to shorten my build times.
As you probably know, there is a tendency when new developers join a team to hate the old legacy code - one of the toughest skills is being able to read someone else's code - so they ask their managers to throw it away and rewrite it. This is rarely worth it and often results in a lot of time being spent recreating fixes for old bugs and corner cases. Much better use of time to try refactoring the existing code first.
Although, can see why you mentioned it from the initial example that I gave (on that rewrite of the shopping cart) which is also covered by the "second system effect." Yeah, thinking back, have seen this too. Overdesign can get really out of hand and becomes really annoying to wade through all that unnecessary complexity whenever you need to make a change.
Because rewriting old complex code is way more time consuming that you think it'll be. You have to add not only in the same features, but all the corner cases that your system ran into in the past.
Have seen this myself. A large team spent an entire year of wasted effort on a clean rewrite of an key system (shopping cart at a high-volume website) that never worked... ...although, in the age of AI, wonder if a rewrite would be easier than in the past. Still, guessing even then, it'd be better if the AI refactored it first as a basis for reworking the code, as opposed to the AI doing a clean rewrite of code from the start.
... and not just giving you lip service, but I do find the far left to have gone too far themselves (am a moderate independent myself). They're assuredness that everything they believe is the only correct way to think is frustrating (they are often the least understanding). Yeah, it seems if you step out of line and say anything against their beliefs, you're apart of the far right.
But, feels like things are shifting back to the middle for various reasons. Think this is a good trend
Yeah, don't think most people who support battling climate change are extremists. We just believe it's a big problem, and, to put it in monetary terms, having to deal with major changes in climate could cost the world tens of trillions of dollars by some scientist predictions. Yeah, it's like any problem, doing relatively small fixes now could save enormous amounts of time and money later down the line. Seems like it would probably good usage of our efforts.
And, you may be right, it may not be that big a deal and that we're being alarmists, but it seems like we currently have the tools to slow it down greatly. Why not be on the safe side and use them?
... but to be honest, guessing my opinion won't sway you in any way, still thought I'd try. thanks!
And not saying that dynamic typing doesn't have a place, I really like working in Python, it's just that for more complicated code, prefer statically typed as it leads to less problems with your expressions. To each their own.
We can go back and forth on this, so will just say, in my opinion, Spring autowiring overall doesn't provide enough benefit versus its downsides, which to me are: increased complexity and doesn't work well enough (it should be easier to debug autowiring problems for one).
You seem very knowledgeable about design, and, of course, you're entitled to your opinion, so seems like we'll probably just have to disagree on this:)
At least from my experience, seems like we don't change the objects we use that often, that once a object is set on a reference var, a very, very large majority of them won't change.
And because of this, seems like that for most objects dependencies, we should just new them directly, and if later on we do need to change them, then at that time, we can refactor the code to use more abstraction (like inversion of control) to break the direct dependency, but only for the code that needs it (or if there is a important situation where having a direct dependency could be highly problematic in the future, like to a DB provider).
It's like the performance optimization problem. One guideline that is often quoted is that it's best not to over optimize the performance of your code, until you actually can test it in real-world test cases, because you very often optimize things that aren't the bottleneck. Same with the over usage of inversion of control. Spring makes it so we're using IOC everywhere, but it's just adding unnecessary complexity.
Think that if inversion of control is used, should be used mainly at a higher level, for components instead of on every class like often happens. But even for components, think you should be careful when deciding to do so.
... and agreed, you could just use the factory pattern instead of Spring.
... although, Java have does support some dynamic typing, as you now don't need to have the type when instantiating objects, using the "var" keyword and the compiler will infer the type from the object that is being set to it (although, this is just syntactic sugar).
It isn't great for really strange and odd builds, but in that case, you should probably be breaking your project down into smaller components (each with it's own maven file) anyways.
Yeah, it seems like Maven is designed to build just one project with relatively little build-code (although, figuring out versioning of the libs used in your build can get tricky, but guessing this is how it is in most languages). It's still one of my favorites build tools for many situations.
Spring autowiring makes Java seem as a whole unnecessarily complex. Think it should be highly discouraged in the language (unless it is revamped and made apart of the compiler).
... not sure how this applies to the ObjectMapper, as I haven't programmed in Java in awhile. ... and my gripe doesn't apply to SpringBoot though:)