[...] you complained about imports.
I haven't complained about imports.
I have complained that Java's standard library is dumb as fuck.
The point which you have missed completely. Probably because, I get the feeling, you have never used any other programming language and you simply can't imagine how it can be any different, least better.
You mean auto-complete in Eclipse can write programs for me? It would read my mind and output proper working Java code, with all the boilerplate, configuration and 3rd party libraries includes?? Would it also by chance deploy to customers too? and provide support and updates? What is the keyboard short-cut to all this magic?
The Eclipse seems have made an enormous leaps in functionality - and all that in the 6 hours since I left the office.
You have completely missed the point.
When you program in Python (the language I btw actively hate; Perl guy here) it actually feels like you programming in a high level language. It gives you the tools you need to accomplish the task. Not every tool, not for every task - but the tools cover a lot of ground.
When you program in Java, it sometimes feels like you are programming in assembler: the same level of attention to details, the same microscopic impact of every line you write. And you too need to write a lot of lines to accomplish the same, other languages allow you to do in one or two lines.
I have no idea what "Red Sox" are, but Java's verbosity (and its long/shot term consequences) are universally known among software developers. It's not like Java is the first language of the kind.
Verbosity wouldn't have been so much of a problem, if the standard library was at least OK. But it is not.
Sun (and now Oracle) pretty much openly stated that they do not want to expand standard library. Main reason I heard was the security updates. (As if shifting the responsibility to the 3rd party libraries anyhow alleviates the security concerns.) The end result that Java's standard library manages to be at the same time very bloated and very poor.
For example, there is still no usable String.split(). There is standard one with the regexps, but it is very slow. I work with Java rarely (at most a month per year) and I have already seen at least a dozen of hand-coded String.split() alternatives.
Java's core strength was that it was built to be a practical tool for getting work done.
If only.
I have abandoned Java shortly after Java 2 SDK release precisely because it was NOT anywhere near being a "practical tool for getting work done." Later encounters over the years only reinforced my opinion.
As one Java developer described it, comparing Java to Python at task of using the proverbial "wheel" in your program. In Python, if you need the "wheel", you just "import wheel" and use it. Java too provides you with everything necessary: "import map.ore.iron", "import tools.pickaxe", "import fire.matches", plus a 3rd party class "recipe.smelt" and a measly 1-2K LOC - and voila! you have the "class Wheel" in Java too!
Weird. Works like that 100% of time in Chrome on Win7/x64.
(Which is basically why I keep IE around: the Flash player is by far the least buggy player. I also get least video tearing with the IE.)
Are you sure you can tell the difference between SD and HD video?
I was so happy when I found that HTML5 player finally can auto-switch to high-def mode when going to full-screen.
Sadly, the happy moment was short, as I have realized that Google has "fixed" the caching issue: now part of the video which was loaded in SD mode (for smaller videos on fast connection - the whole video) stays in SD mode and switch to HD mode has no effect.
So yes, HD full-screen mode now works - but is useless.
The QA track record of the Google is as appalling as it ever was. Goes to reinforce the old wisdom that the "star" developers are useless when it comes to dealing with the mundane, real world problems.
Each statement does so little [...]
Also true for the assemblers.
[...] that it is very easy to step through code in a debugger and pinpoint the place that something has gone wrong.
Except that it might take days or weeks to step through all of it.
Except that it theoretically might take even months, if you need to debug problem related to some framework.
[...] Java is exceptionally easy to debug.
It's not. Unless it is relatively small and independent application. But in that case, literally every language is easy to debug. Even C.
Yes. Billing systems.
In a way, the experience is a confirmation of the RTFA. When newhires come, everybody is in the awe of the Java part, and everybody is terrified of the C/C++ part. But the thing is, a year later most change their opinion. Java might look beautiful - but the beauty is skin deep. We have had clients changing project design and architecture because developers were throwing in a white flag: they simply couldn't fix something in the Java part, and the workaround had to be put somewhere else.
With the C/C++, the usual problems tend to keep the development down to the ground. While with the Java, developers very often succumb to the fancy of implementing all the fancy things people on the internet are so fancy about. Like for example the good design practices. No, no, no - only the best design practices! Because that's how it supposed to be!! End result are the huge monstrosities, which are more compliant with the programming books than with the customer requirements.
The saddest part is that good Java pros are acutely aware of the problem. But one can't just swim against the tide.
It is pretty easy to read Java code and figure out what it means.
Many who deal with the "enterprise" software would simply laugh at the statement.
But hey, the same argument was often made about the BASIC. And I always said that Java and BASIC users are very similar.
Intel is lucky that Apple appears to have a barely concealed desire to kill the mac mini, and bootcamp.
Many Intel NUCs also require hacks to install on them anything non-Windows (for example Linux).
My point being: Intel NUCs are also not very friendly to the alternative OSs.
Rust is walking the path of simplification.
Really?
Author apparently hasn't seen the crazy monstrosity the Rust's preprocessor is.
Otherwise, IMO, Rust and this type of languages - "the perfect cage" - to me are dead end.
(A) I want an utilitarian language. I want language which provides me with strict and weak typing, static and dynamic binding, compiled/jitted/interpreted execution with eval() function. At the same time. Probably all that in different scopes - but the scopes should be able to inter-operate. Think Objective-C++ - but with something better than Objective C on the weak side of things, with bits of Perl-ness built-in.
I want a language which gives me choice. Not another language with dozen theoretical papers why I can't do something and I'm better off for it.
(B) For security, I would rather want an language which can be easily validated and proofed. Rust tries to create a perfect cage - for developers - while the main security vulnerability is the user input. Compilers still can't guess whether I have properly validated the input or not. The Rust went in a different direction: annihilating C/C++ bugs. The problem is that all other bugs programmers make - still remain.
People keep bringing up the Swift in context of system programming, but so far I haven't seen any concrete info about features of the language which make it even suitable for the system programming.
The thing is, even C++ was/is used for system programming, but its C++-ness is so castrated that it is hardly can be called C++ anymore.
I personally do not see any reason to replace C with another language, which I can't use to its fullest. On top of it, lots of C extensions are needed to make the system development efficient: code/data section assignment, untyped/unchecked memory access, memory/IO barriers, assembler intrinsic. None of that is part of C standard - all of it are vendor/compiler extensions. While Swift documentation is devoid of the similar features.
P.S. If Apple folks want to push the Swift into the embedded area... Good luck. Even C++ still struggles. Higher-end embedded system require proof of validity and literally all of the solver software is C-only. Most static/dynamic code analyzers - C-only too.
By the looks of it, they are talking about new rail track.
If there is a problem of delays with the current one, that means the rail system doesn't have redundant tracks to route the traffic around a problem.
One more track, less chance of one broken train holding up the whole traffic.
My guess is you will find some way to justify the idea that it isnt a subsidy... just like right here where you found a way to ignore it completely.
I haven't ignored it.
I simply can't understand your condescending tone about it.
It is pretty normal for gov't to jump start industry by helping it one way or another. It happened (and happens) in a lot of important industries.
But you are acting here as if it was something weird and unusual.
The hardest part of climbing the ladder of success is getting through the crowd at the bottom.
