James Gosling, the ‘Father of Java,’ joins Amazon Web Services
siliconangle.com
siliconangle.com
"As to why I left, it's difficult to answer: Just about anything I could say that would be accurate and honest would do more harm than good."
"For the privilege of working for Oracle, they wanted me to take a big pay cut."
"In my job offer, they had me at a fairly significant grade level down."
"Oracle is an extremely micromanaged company. So myself and my peers in the Java area were not allowed to decide anything. All of our authority to decide anything evaporated."
"The word came down that Oracle does not do employee appreciation events. So she forced the thing to be cancelled. But they didn't save any money because the money had been spent - so we ended up giving the tickets to charities. We were forced to give it up because it wasn't the Oracle Way.' On the other hand, Oracle sponsors this sailboat for about $200 million."
Source: http://www.eweek.com/development/java-creator-james-gosling-...
Gosling is complaining about about pay and management oversight.
Has anyone wonder if overpay and no oversight is what contributed to Sun's failure.
Speaking as an insider, I can say with 100% certainty it was.
Sun had this hardware business that was printing money and then the music stopped.
I wonder if Google might suffer a similar fate like Sun. As soon as ad-revenue slows down, will they need to grow up and be managed like a real company by putting restrictions on pay and enforce management oversight.
Can you elaborate on that?
The fact is that they have not grown their top line for five years(1), 70% of their business is in a dying sector and they have opted to cut R&D spending in favor of stock buybacks and dividend payouts for years(2).
I don't see how they can change course; their investors keep asking for dividends while the bulk of their competitors are either privately owned or public with strong founder/owners; point being Oracles competitors are controlled by investors that want R&D spending, Oracle is not, and Oracle sorely needs R&D to build a portfolio that'll keep them from being yet another leveraged buy-out..
(1) https://ycharts.com/companies/ORCL/revenues
(2) http://marketrealist.com/2016/12/oracles-share-buybacks-dividend-trend-will-run-2017/I've been at a couple of larger than Oracle-sized organizations that paid quite well and didn't have a lot of 'management oversight'....which I am taking to mean, roughly, 'top-down, heavy-handed management'.
>Stop checking our code for vulnerabilities
That's not the reaction from a company that's "grown up". It's a sign of a company that still has growing up to do.
And the jury certainly is out on Oracle. Right now Oracle is a company where great software goes to die. All signs point to them eventually ending up like Yahoo. It'll take a while, but the handwriting is already on the wall.
(*within reason)
Even spoofed on a recent Silicon Valley episode.
With all due credit to him, I am not too sure the enormous success of Java was due to language excellence or massive marketing expense by Sun and Oracle.
I don't mind, though. I don't understand why people can't do whiteboard code. It's usually super simple stuff yet people get caught up on things like not remembering that for-loops take three parameters. I mean, yes, the compiler will stop you. But just how long have you been doing this job that you can't do THAT one in your sleep?
What I did mind about Amazon was that clearly they were lying to me about the expectations of overtime, as well as the compensation package was ludicrously bad.
Why can't you program the simple problems that interviewers use for whiteboard coding without Stack Overflow?
It's not even like interviewers are looking for syntax-perfect code (which you wouldn't need Stack Overflow for anyway, the compiler is what catches that for you). I've never had an interviewer that would quibble over a missed semi-colon here or there. Hell, most of the time I end up using "begin/end" style pseudo-code instead of curly-braces, because curly-braces are stupidly hard to draw well on a whiteboard.
And even if you don't know off the top of your head what "invert binary tree" means, every interviewer I've ever had has been more than willing to answer any questions I have about the problem. Ask questions about requirements and you should be able to figure it out. If, once you know what the inputs and outputs of "invert binary tree" should be and you still can't do it, I seriously gotta question what the hell you're doing interviewing for the job of programmer. I once passed an interview for a job I wasn't even applying for, even though I didn't know off the top of my head what "LRU cache" meant, by asking enough questions ("oh, LRU means least-recently used? Well then, something like this?")
I tend to think of whiteboard coding problems as being ineffective for interviewing because the problems are so simple. To me, anybody should be able to solve these problems. I know a lot of people can't, and this serves as a quick filter to winnow them out. But they are so ludicrously easy I just don't get how you can say you need Stack Overflow to solve these problems.
I'm with Jonathan Blow on this one: https://twitter.com/mxcl/status/608682016205344768
Current generation developers don't seem to be able to program without doing "Stack Overflow driven programming".
So when you put them in front of a whiteboard, it is like their knowledge just vanished.
Now, what I am fully against is the complete disregard for the work experience of what one might have and reduce it to Data Structures & Algorithm exercises that many haven't done in several years, eventually decades.
This is the part I don't understand. What is your job that you never do anything related to data structures or algorithms?
I'd like to know so I can stay away from such jobs. I just can't imagine being happy with such a dead-end job that doesn't require me to think of solutions to problems. If these jobs can be done by any monkey with a brute-force approach, then let any monkey do them. I've got better things to do.
Sometimes there are actually cool projects, no issues with licenses for the likes of Oracle servers or Visual Studio Ultimate.
Also I do get to enjoy life outside work with the people that actually matter to me.
Downsides, well there are lots of politics, social skills matter as much as coding skills, sometimes projects go really wrong.
Writing B+ Trees in such scenarios is not something that one does on daily enterprise coding.
Yes, I had that question done to me at Google, on a phone interview.
If you don't know math, you can't argue you don't need it. You obviously never learned to use the tools available to you, so you don't know what you're missing out on.
Just I don't need to use most of it for doing enterprise CRUD applications.
I am speaking in general for others and the current state of the industry, I seldom failed any whiteboard exercise.
Java was badly designed, as a language. The things that made it good came far, far too late in its lifetime. The thing that made it successful was not a good design, but big corporate backing, a free compiler, a batteries-included approach to libraries, good marketing, and good platform support.
But the language itself was bad. No custom copy-by-value objects, static typing without generics or macros to make reusable collections, a GUI library that was widely considered a bad joke, a null hole big enough to drive a truck through, checked exceptions, the frustrating inconsistency between .Equals and ==...
So many bad decisions. Many of these were mitigated over time, but it took a long time to get there. It's hard to say that "designed Java" is really a good feather in the cap.
- Guy Steele, Java spec co-author
Custom collections in a statically-typed language without macros or generics or templates is masochism. I was very disappointed back in 2005 that it took competition from Microsoft with .NET 2.0 to force the Java leadership's hand to finally provide that missing feature.
Why even bother with static typing if coders are constantly having to type-cast and null-check everything?
But if you prefer, advance a few years up to 2004 (1.5), still 5 years before Go was created.
Also HashMap is just one implementation among all of those that are available in the standard library for the Map interface, each one tailored for a specific use case, with regard to performance and memory constraints.
In Go you cannot change the behaviour of that built in hash map.
Go maps are an explicit exception in the type system. They have their own type rule. And in the syntax. They have multiple map-specific syntax rules (and not just literals). And in the semantics (e.g. using range on them).
Go doesn't have maps, as such. Go has an inbuilt language feature of one particular type of map, that I assume is thought to be good enough for everybody.
Java is a great and extremely well designed language. All you mentioned are nothing but natural expansion of the language's use cases.
I love lines that say so much with so little. Well said.
Java was the right language at the right time. That's why it was so successful.
any moderately-usable language with a free, cross-platform compiler and a full batteries-included library for everything and support for every major platform and a major vendor pushing it and the kind of global marketing PR (The Official Programming Language of Canada!) would have seen the same success as Java at the time.
The quality of the language design itself was "passable" at best, but that's all it needed to be with the forces it had pushing it and the market conditions at the time.
I'm mostly seeing Java treated like a legacy or a conservative choice - not something I would describe as great. JVM has a lot of quality engineering but there are better languages to leverage that ecosystem.
To be blunt: this is not hindsight. This is me remembering working with Java in the early 2000s. These were things that jumped out at me as an undergrad student as obvious pain-points in a new language I was learning that were not present in other languages I had used.
It's hard to look at a historical success, and determine which attributes caused that success. I agree that the non-product attributes (tooling, docs, libraries, corporate backing etc) were important. Elsewhere you describe it as "moderately-usable", and I think that implies the key: to compare it with the alternatives, such as C++ and COBOL. That's how market success comes about.
It's similar with google: was it "the algorithm"? Or was it honest results, uncluttered, fast?
Java doesn't represent anywhere near the full depth of what Gosling actually knows about programming languages. You remark about "static typing without generics or macros to make reusable collection". Yet, Gosling made a structural macro system for the C language in 1989. The ideas in that could easily have been further developed in Java.
From Mock Lisp to Java: the really unfortunate thing about Gosling is the cynicism in his designs.
What's the sell, these days for java?
Why does anyone need to sell anything? So we can all go ahead and spend 5 years getting good at clojure and haskell?
Java is pretty modern, has quirks, but you can be pretty productive, not a particularly bad language. Helps you get stuff done. Awesome tools, pretty good concurency support. It is very hish performance. It is a proven tool, just don't buy into the IBM/RedHat enterprise stuff. There are nice microframeworks available. Java is a good choice to start a project in.
What makes Java powerful is that it's good at everything. That's incredibly valuable for Amazon and Google, because they have an insane amount of code. So whether they need concurrency, or tooling, or whatever they can throw any 4-5 engineers at the problem and they'll be able to get it done.
For a startup, they aren't going to need the greatest General Purpose language ever made. They generally have specific problems. And there are simply better languages out there for almost all of them.
If I'm a startup, I generally have ONE thing that I need to excel at. If that's computer vision, why would I use Java when C++ (and arguably Python/OpenCV) is decidedly better at computer vision? If I need a simple REST service for my particular project, why in the world would I use Java over Python, Ruby or Go?
The value of Java is that it does everything well, but the ecosystem is enormous. It's overkill for most projects, unless you happen to have projects that scale across multiple domains that Java does well.
I find it odd that I'm getting so much push back here. There's a massive amount of cognitive overhead in utilizing Java. There's also a huge cost (both cognitive and entry) in using of Java. (The difference between a Java programmer and a generalist? How much the latter has to learn to catch up.)
Well, CIOs tend to think so. I think they are wrong, and that this is one of the reasons enterprise-internal technology is so bad.
You aren't actually going to.move engineers between those tasks very much, because each of them relies on fairly deep domain knowledge, and, in any case, it's unlikely that the size of demand between those tasks shifts enough that it makes sense to shift a lot of people around. And, those you do shift around are going to have a lot of work coming up to speed on domain knowledge (which is going to have a huge impact on how the language is used), which will dwarf any language-transition effects. And, furthermore, the places that do stuff like this aren't the kind of places that attract the kind of talent that could manage to the transition between these divergent domains well; what they almost invariably end up doing to deal with short-term shifts is hiring specialist contractors in the more in-demand area, and for longer-term shifts reducing headcount in one area and hiring new people in the other.
At the same time, you are inhibiting productivity in most or all of the individual domains by not choosing the right tool for the specific job.
I agree, but wanted to specify "big" examples to make it clear what my point was. That said, while they do require domain knowledge, I've seen people move into entirely different domains at the same company. It's not common, but it absolutely happens.
Go is hardly a "modern language" from a language design perspective so you're not gaining much over Java here. It has horrendous package management and the IDEs, debuggers, profilers and live monitoring tools are probably a decade or more behind the tools available for Java and the JVM. It's also much harder to find Go programmers than it is Java programmers.
Python is a very slow dynamically typed language with a horrible deployment and concurrency story. A lot of big companies justifiably won't even consider a dynamically typed language. Again all the tooling from package management to profilers to debuggers is way behind what's available for Java and the JVM.
C# is a real competitor but for the most part it's still tied to Windows. This is slowly changing but the vast majority of C# libraries still require the full .NET runtime on Windows and the open source community around C# is a small fraction of the size of the community around JVM languages.
You're just wrong there. There are plenty of languages that do something better than Java, but none of them do everything better than Java.
> I don't use Java much but out of the languages you named none of them are better at much and with the exception of C# all of them have far, far worse tooling
Now we are traversing into "my opinion is fact here".
> Python is a very slow dynamically typed language with a horrible deployment and concurrency story.
Who the hell uses Python for concurrency? It has a global interpreter lock... if your use case obligates concurrency and you pick Python you just don't understand what you are doing.
> C# is a real competitor but for the most part it's still tied to Windows.
Yes, let's dismiss every other language because Python is bad at concurrency and you don't like Go's package manager... Give me a break.
I agree and I never said otherwise. I specifically addressed three of the languages you named (Python, Go and C#).
> Now we are traversing into "my opinion is fact here".
I'd love to see someone argue that Go or Python have superior tooling to Java and the JVM.
> Yes, let's dismiss every other language
I'm not dismissing every other language, I don't even use Java regularly, I'm dismissing two of the "modern" languages you named.
By pointing out things that they do decidedly worse than Java, which was exactly the opposite of my point.
> I'd love to see someone argue that Go or Python have superior tooling to Java and the JVM.
I never said they did, because they don't, in general. But Python is absolutely superior in some areas (statistical modeling, machine learning) because the tools it uses are, objectively, better.
> I'm not dismissing every other language, I don't even use Java regularly, I'm dismissing two of the "modern" languages you named.
Right, you're dismissing them for decidedly stupid reasons. Literally no one on the planet is going to think Python is a good option for concurrency. And you're opinion on Go is literally just an opinion, that many (myself included) would absolutely disagree with.
Bullshit. Python is often used for early exploration but the people doing serious work in ML almost always end up using C++, Java or Scala.
> you're dismissing them for decidedly stupid reasons
So having relatively poor tooling, poor package management, poor performance and bad concurrency support aren't good reasons for dismissing a language? Go and Python aren't even particularly well designed languages. That's far more than you've given for dismissing Java and claiming that alternatives are "vastly better for a typical startup."
LOL. What? Did you poll every company doing ML work to arrive at that conclusion? C++, sure. Java and Scala? I've literally NEVER seen actual ML work done in either language at either of the 2 companies (both big 4) I've worked at.
> So having relatively poor tooling,
No. Is Java's tooling generally better? Probably. Does that make all other tooling poor? No.
> poor package management
Stop treating your preference as if it's fact.
> poor performance
Which matters sometimes, but not always. If performance were a metric that made a language live or die, nobody would use anything but C/C++.
> bad concurrency support
Only in Python. But that's moot, you don't need concurrency in every application. Do you realize there are ENORMOUS applications, in-use today, that scales dramatically and they are written in a variety of languages, including Python?
> Go and Python aren't even particularly well designed languages.
Your arguments here indicate you have very little understanding of basic language use-cases, so pardon me if I don't hold your opinion on language design to a very high standard.
> aren't good reasons for dismissing a language
They aren't reasons. They are your opinions and a fundamental misunderstanding of basic use-cases. Frankly, based on what you've said so far, your judgement about languages in general is on-par with what I'd expect for a new grad CS major that only used C++ or Java while in college.
> That's far more than you've given for dismissing Java and claiming that alternatives are "vastly better for a typical startup."
And yet I clearly explained why Java is generally not a good choice for a startup. And it seems, most startups agree since the majority don't use Java.
I work at one of the big 4 right now and almost all the serious ML is done in C++ and Java. Python is purely used during exploratory phases and even that is being phased out. Most of the other things I said aren't even controversial so I'm just going to ignore you from now on. Enjoy thinking Python and Go are well designed languages.
Most of the things you said were a straw man and nothing more. Go and Python are good at what they do. I see them as tools in a vast tool box. You think everything is a nail. Enjoy thinking that's a valid viewpoint.
There are also some high profile pieces of technology written in Java, so if you want to leverage them, having JVM expertise is a bonus. You may even get better bindings for JVM languages than others and since many are open source, having Java expertise allows you to work on them.
I find it a little odd you'd buy in to the CLR family (C#, F#, etc), but say the JVM family has nothing to offer. They're not really substantially different in my experience -- both are sort of staid enterprise-y ecosystems. (But maybe I'm missing something really cool in CLR land besides good MS product support -- please let me know! It's one of my language blindspots.)
I just find C# to be a better language. It has its youth to thank for that. I have no issues with JVM. Hell, if I were to start a project today Kotlin and Scala would also be very real possibilities. They are both amazing languages.
C# probably shouldn't have made my list, but I threw it in there to cover OOP where the other languages were decidedly not. At the end of the day, language choices for a start up largely reflect it's goals. If I want to do statistical modeling, I'm going to use R. For ML, probably Python. For a systems program, likely Rust.
The bottom line with Java is that it can do any of those things. But the languages I mentioned do their specific job better. And that's the thing with a startup. You don't need a great general purpose language, you need whatever language suits your niche. But at Amazon/Google scale, Java is an absolute beast, largely because it can do everything.
But java has so many great languages on the JVM. That inter op flawlessly with it. Kotlin is my favorite, and allows both java and kotlin files in the same project.
The language is palpable. But I feel that there are higher level features, that can ease development and improve readability. Yes, yes the IDE can generate boiler plate. But that shouldn't be necessary.
It's not hard to send a Java app to a Windows user and expect them to be able to run it, which is more than I can say for Python.
And Java also has Maven, which is by far the best dependency management system I've used. It's extensible too... aside from managing dependencies, you can also have Maven perform code generation (which is wonderful if you're working with Avro) and other things (such as handling OSGi bundle metadata).
People have a tendency to trash talk it for being verbose, but writing the code is a vanishingly small portion of the engineering effort, and if you're hand wringing about whether it's fun to write then you're optimizing for the wrong things.
It's hard to imagine what kind of career that attitude would lead to. I very much worry about whether things are fun to write. And I've been lucky that, so far, I've had jobs that were very fun. Not necessarily easy, but fun.
And if you do not want to use Java the language, there is always Kotlin (and Scala).
Cons: Oracle's shadow of semi-legitimate FUD, higher memory consumption, ecosystem is rife with over-engineering and the language seems to almost encourage it.
I actually question why anyone would use Node except in a few cases (like backend for front end), but maybe I'm just old school :)
Node is "simple" but today you need 3 package managers to install the dozens of small libraries needed for even a simple project
Really. When I found out express.js needs an extra library to read POST data I was stumped
None.
It's a Flask clone for Java. No XML configuration needed.
As the others mentioned, Spring has not required XML config files in a long time. Spring boot requires nearly zero configuration, although it's a good idea to move out environment specific configurations out of the app. Speaking of, out of the box Spring works with yaml, properties, environment vars, command line vars, and the list goes on.
It really is a nice environment to work in, and if you don't like Java there is Kotlin which has worked fine within the stack IME. So many people only remember Java 5 and Spring where beans had to be wired up through XML configs.
Developing a web application using javascript and having it served by a javascript platform (node js) makes everything so much easier. From simple code re-use, back-end to front-end, to not having to mentally switch contexts if you are developing back and front end at the same time.
In a couple of years, probably they'll be much closer. But that also depends on what the Spring guys and gals have to say :-).
I wonder what they'll have him do.