Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Comment: Re:That again? (Score 1) 304

by ThePhilips (#49751235) Attached to: How Java Changed Programming Forever

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.

Comment: That again? (Score 2) 304

by ThePhilips (#49750117) Attached to: How Java Changed Programming Forever

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!

Comment: HTML5 is still largely broken (Score 1) 51

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.

Comment: Re:debugging (Score 1) 390

by ThePhilips (#49749409) Attached to: The Reason For Java's Staying Power: It's Easy To Read

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.

Comment: Re:Seen enterprise software? (Score 1) 390

by ThePhilips (#49745499) Attached to: The Reason For Java's Staying Power: It's Easy To Read

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.

Comment: Re: Pass because the price point is too high (Score 1) 80

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.

Comment: Simplification? (Score 1) 386

by ThePhilips (#49679617) Attached to: Criticizing the Rust Language, and Why C/C++ Will Never Die

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.

Comment: Swift for the system programming? (Score 2) 270

by ThePhilips (#49671701) Attached to: Swift Vs. Objective-C: Why the Future Favors Swift

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.

Comment: Re:Of course, there's this (Score 1) 176

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.

Comment: Re:Of course, there's this (Score 1) 176

R&D gets money from the sales. Subsidies help lower the entry barrier and grow the market. Larger the market - more money gets into the R&D.

Lots of things were not viable initially without gov't help. Public transportation, metallurgy, telecommunications, energy - are all the industries gov't helped to jump start by giving subsidies and tax breaks. Because there is no single party - or group of parties - large enough to finance the whole thing till it becomes, as you put it, "compelling economic option".

Comment: Re:Of course, there's this (Score 1) 176

In other words, it presently is not a compelling economic option.

You need to read about economies of scale.

It's pretty stupid to compare economic viability of 50+ year old industry (covering 90+% of market) with 10+ year old industry (striving to gain a percent or two).

I like how pragmatically Germans went after the solar: it makes sense in long term, thus it makes sense to start R&D sooner than later. And apparently it is going well enough that they are even planning to repel the subsidies (to much chagrin of some).

One good suit is worth a thousand resumes.

Working...