I'm sorry about that. I might have been the one who originally suggested the name "Java" inspired by the cup of Peets coffee I had in my hand at the time.
To be fair it would have been Kim Polese and Patrick Naughton and James and Arthur Van Hoff who made the final decision on the name from the suggestions thrown out in that meeting. And furthermore Yahoo search was dominant then, maybe with AltaVista, and the idea of polluting the search space hadn't occurred to anyone.
AWS, like google and like Azure and every other cloud provider already does everything they can to minimize energy consumption because it is in their economic interest to do so.
In fact I would think the best thing industry can do to reduce energy consumption is to move their data to a cloud provider. It takes far less energy to cool one large room with servers from a dozen companies than it does to cool a dozen server rooms with private on-prem servers.
Levandowski still lists his occupation on Linkin as "VP Engineering at Uber ATG".
How the !!@ can that still be true?
Hasn't Uber cut ties with him yet?
Pascal was the programming language we used in college in the late 70s, and although I knew it translated to p-code that was then interpreted, somehow that never became much of a focus. We just used the language like you would any other high-level language, and bitched about the shortcomings or inconsistencies.
I can tell you first hand that when James Gosling was developing Oak/Greentalk which became Java, Pascal never came up. Sure we all knew and had used it, but the focus was much more on C++ and what to keep and what to discard. I think Smalltalk or Self might have even been more of an influence since Dave Ungar was in the Sun research division at the time and was spreading the gospel of generational garbage collection.
Not a chance at our 3-yr old startup. That's less than a summer project, and nobody expects much from summer interns. Maybe you haven't written highly async Go services in containers orchestrated by kubernetes. You would spent those two months just ramping up on our code base and customer issues just to be productive. And if by some miracle you actually produced production code, nobody wants the author of that code to immediately walk out the door. Experienced programmers understand that 80% of the cost is in the maintenance over the lifetime of the code. That is a lot easier to do if the author is still around.
"In this case, Monsanto denied requests by university researchers to study its XtendiMax with VaporGrip for volatility - a measure of its tendency to vaporize and drift across fields.
The researchers interviewed by Reuters - Jason Norsworthy at the University of Arkansas, Kevin Bradley at the University of Missouri and Aaron Hager at the University of Illinois - said Monsanto provided samples of XtendiMax before it was approved by the EPA. However, the samples came with contracts that explicitly forbade volatility testing."
I don't know how hard it will be to land a tech job in general, but for any individuals I know it will be more difficult. It gets much harder in your thirties, and a damn near impossible to get a development job by the time you are fifty. You had better have made you millions and retired by then. I recently landed a job at a startup and couldn't be happier, but it was a helluva struggle to overcome pervasive cultural biases that favor less experienced coders right out of college.
I really like your explanation of diagonalizable matrices! I've always seen explanations of how to determine if a matrix is diagonalizable, but hadn't run across the idea that they are just scaled diagonal matrices for a different basis.
This is sort of a blast from the past. Thirty years ago we were writing entire window systems in PostScript - with object-oriented classes and toolkits. Not very practical but it was fun at the time.
See NeWS. Owen Densmore and James Gosling were the main proponents.
So true. BS, MS in CS, Bell Labs, Sun Microsystems, several SV startups including working for Elon at his first company. But I'm 52 and not a chance I could get in the door at google or any place in the valley now. I'm happily employed but for less than half what I once made.
I'm not sure they are wrong either. I'm not longer willing to work all night or to be the only one to stay over christmas to pump out yet another release. Nor am I willing to release buggy code because some marketing puke promised it would be ready by Wednesday. And yeah I still go to makefiles instead of scons or CMake, and I don't give a shit about Haskell or Scala.
So it makes sense to hire that 26 year old who you can milk for 10 or 15 years before kicking to the curb. And he won't even see it coming. Hopefully he will have saved those options and salary so he can weather the transition to another career.
I hear you. It's so much worse than you can imagine. By the time the code gets out the door, whether through a dump on the net or even worse, through a channel partner and onto a shelf at Fry's, all the engineers are working on new projects. There is sometimes a six-month lag from the time the code is compiled until it shows up on a store. By then the technology has changed no one gives shit about the old stuff. There is no incentive and certainly no corporate push to go fix the bugs that got shipped. I know I always felt like it would be a simple thing to go patch the code, but it was never a priority for the management.
I'll tell you the really screwy thing about BCM43xx development. We sold reference designs to companies like 3Com and Linksys (before and after acquisition by Cisco), Apple, D-Link, etc. All of them got the same reference design, in theory, but if one of those companies reported a bug in our code, that company would be the only one to get the patched code. As a consequence our code was littered with #ifdef (COMS) or #ifdef (LINKSYS) with specific patches enabled. The other companies, those that hadn't yet discovered the bug, would get updates that we knew were broken. It was terrible for the companies, even worse for the customers of those companies.
Plus there were source releases to those companies and they weren't allowed to know about patches that they didn't receive. So we had a step in our build process called the code transmogrifier. That would go through the code and expand certain C preprocessor symbols so the code no longer contained #ifdef (COMS) or #ifdef (LNIKSYS). That way every company got a different source code release as well. We would do separate compiles of the transmogrified code for each customer.
Then we had all the customization because those companies had fired all their own engineers and instead wanted us to produce a product that was branded "Cisco" or "Linksys". We had to take the exact same code an rebrand copyright strings to make it look like it was written by our customers.
Wow, armchair engineer, you sound like you really know what you're talking about.
When this old engineer worked on embedded MIPS cores and 802.11[abgn] at Broadcom, everything was under source code control. This was pre-git, so I think we were using cvs. How the hell do you conclude that releasing a zip file means the engineers don't use source code control?
Certainly doesn't copy tweets from https://nitter.net/RonFilipkowski