LXer@FOSDEM 2010: Anyone else going?
Tonight FOSDEM 2010 starts with the beer event, and tomorrow the main conference starts. It's held again at the University 'ULB' in Brussels south-east (near the embassies) in Belgium. Just like last year, LXer will be there. I will try to go both days to cover some talks for you. The schedule promises some interesting talks like that of Greg Koah Hartman, another talk about the RepRap 'cheap' 3D printer that prints its own parts. There's also a Mozilla-room, a distro-room, an embedded room. a KDE and a Gnome room, the Drupal room, the 20-minute Lightning talks which could be about anything and many more. Like last year, I'll be wearing my LXer badge. And because I'm pretty out of money, I'll be covering the event using a paper notepad and pencil again. If you're also going there, let me know, maybe we could meet. If not, I hope you'll enjoy our covering. Stay tuned, the article will arrive somewhere next week. |
|
|
Comments (82)
62 earlier comments in the full thread.
i gave you something which backed it up. The fact that the Microsoft developer suites have been marketed in exactly such a manner for years. If there wasn't a degree of truth in that assertion, the marketing wouldn't work. Yes, the statement was hyperbole, but we're all prone to that from time to time.
> And it was silly because of a non-developer commenting on lazy programmers when little is expected to be known from her about such.
Little expected to be known about such? How would you know how much TC knows about programmers? And even if she doesn't know much, her conclusion may still be correct. Sometimes an outsider is in the best position to point out problems.
For someone who considers TC's comments about Mono denigrating to the developers, you're awfully quick to denigrate her, as have other Mono supporters. Is it any surprise she tends to respond in kind?
No, you missed the point. Here it is again: "Depends on the scenario. It may be bloaty for embedded space, kernel space, or even some desktop scenarios due to larger footprint but a general comment like this mostly hints that you have little clue" i.e. different tools for different scenarios. Saying something like "inherently flawed platform like Java or .NET" means you have little clue. And then you missed the second point of my example: in many, many cases using a platform like java will save you lots of precious time that others have spent in providing with a ready made platform -- in fact, if one is not really good then will likely end up writing something that is slower than that already provided by platforms like java.
edit: > when I run the programs using these platforms they are slow So this is how you come to the conclusion that java and .NET are inherently flawed platforms?
@jdixon > i gave you something which backed it up
Really, so what have you provided to show that developers who choose languages like C# for programming are lazy, incompetent ...?
edit: > For someone who considers TC's comments about Mono denigrating to the developers, you're awfully quick to denigrate her, as have other Mono supporters.
Don't know about denigrating but the comments were surely silly to me. Then again I responded about the comment as being silly (unlike Carla who was commenting about the devs) and stand by it as it is factual for me. Even one or few instances of non-lazy devs, for example, would be enough to disprove it and I have known plenty of incredible java devs and some C# ones too.
As I said both times previously, the fact the tools are marketed as such. If there wasn't a degree of truth in the marketing, they marketing campaign wouldn't be successful.
> ...and stand by it as it is factual for me.
And why should anyone else care if it's factual for you? You stating it that way implies that it may not be factual of them.
> Even one or few instances of non-lazy devs, for example, would be enough to disprove it.
Only if she claimed that it was true for every developer, instead of being a generalization; which she didn't. Most people don't expect a generalization to be true in every case. But given the way this conversation has gone, I don't expect you to agree.
Quoting:> when I run the programs using these platforms they are slow So this is how you come to the conclusion that java and .NET are inherently flawed platforms?
Yes.
Do you not understand that as an end user I want programs that are fast (and not bloaty preferably)? .NET and Mono simply can't provide that, therefore, from a user's point of view, they are flawed.
Anyway, fortunately, we have alternatives to the slow bloatware and we're not forced to use these programs.
Again, which marketing campaign says that these tools are for lazy, unskilled developers. Of course, these claim to make the life of developers easier which would be true of the marketing of nearly all software tools for developers. Probably you have not read my earlier comments carefully: there is nothing to suggest that competence of developer is dependent on (or reflects from) the platform chosen.
> Most people don't expect a generalization to be true in every case.
Huh, I expect a generalization to be claimed as being true for nearly all cases. Lets see: do ten counter-examples work for you?
> .NET and Mono simply can't provide that, therefore, from a user's point of view, they are flawed.
This is simply incorrect. I have not benchmarked Mono enough to be certain but definitely java, for example, provides more than enough performance for many scenarios and there is nothing which should prevent Mono from having good performance. Some other languages including python, ruby are way behind in most scenarios while are better in other scenarios where smaller footprint is crucial. Besides as is evident you have no idea of what "inherently flawed" means even though you seem to be taking an offence when this is being pointed out.
To be useful, a generalization must be true in the majority of cases. Say, at least 60%, preferably 70% or more. The higher the percentage, the more useful the generalization.
> ...do ten counter-examples work for you?
Using the above metric (>70%), not unless there are less than 143 developers. Even if we assume a 99% accuracy, that's still only 1000 developers to get 10 counter examples.
Look, you disagree with the characterization of .Net (and by extension. Mono) as being for lazy/incompetent programmers. I get that, and everyone realizes that it's not true in every case. But the rest of the world assumed that stereotype as a given a long time ago. You're not going to dispel it by yourself. The best way to disprove it is for Mono developers to develop great, must have apps; and that simply hasn't been happening.
As far as I can see, the issues making .NET and Java slow is that they are virtual machines and therefore will be slower than native code.
What I can categorically say is that in my real world experience they produce rubbish, big, slow programs. To me, this is the crux of the matter. I'm repeating myself, but seriously, Eclipse and Code Composer Studio compared to Crossworks? Even compared to Qt designer! NX2 compared to GIMP? Honestly, do you not see the same thing in VM based programs compared to native programs? Can you not see that sending something through a VM rather than running it natively is inherently going to slow things down? These are genuine questions, I am not being provocative.
I know exactly what inherently flawed means, by the way, it would just seem that we disagree on whether platforms are and are not. I took offence at being accused of having little clue. I have no issue with someone disagreeing with me, just do it like KS does - without having to resort to insults!
> To be useful, a generalization must be true in the majority of cases.
Where does Carla say that it is meant to apply only for majority of cases? And then you are missing that the onus is on yourself to provide evidence for this i.e. platform (and not field of work, for example) determines the competence of programmer.
> Look, you disagree with the characterization of .Net (and by extension. Mono) as being for lazy/incompetent programmers.
Precisely and the reason is that as a non-developer she (or yourself) would not be expected to know about this. Its like an MS guy saying "Linux is for not for desktops". Besides the statement was not meant to express any facts, rather just to raise flames and one that has been repeated by her many times before.
In my experience the competence of a developer is mostly determined by the fields he/she has worked in. For example, in the hundreds of CVs I have seen and interviews done, developers whose experience has been limited to web-side services kind of stuff are more likely to be incompetent particularly for other software fields be it in C++, java or C#. On the other hand server side backend programmers working for product companies or system programmers using any platform are more likely to be competent for any other fields and in general are likely to be "good" programmers. Similarly devs having good experience of variety of fields are likely to be much better than those who have worked in a single field like medical software. In my company, for example, there is not much to choose between the java/C++/C# teams working on the core product. But when it comes to the tools teams (C++ and java) it is a different level altogether.
@DiBosco
> I guess people wouldn't use Python to make IDEs for writing code or photo editors There are plenty available in python.
> Can you not see that sending something through a VM rather than running it natively is inherently going to slow things down?
No it does not. There is ample evidence and research to prove that it does not slow down with modern day JITs like hotspot. Yes, it has a larger memory requirement due to the big runtime, so is mostly not suitable for embedded space. Yes, it has a longer "warmup" time whereby JIT will kick in for frequently executed code, so startup will be slow -- .NET tries to avoid it by providing for pre-compilation, but that loses out on some runtime processor specific optimizations that modern JITs can do. In fact for many number crunching apps, java is faster than gcc right up there with the ICC compiler using advanced optimizations.
> Eclipse and Code Composer Studio compared to Crossworks?
In my experience, eclipse runs pretty well once started up. In addition it provides for multitudes of features not available in most other IDEs. Yes startup is slow but it has been getting better. Remember OpenOffice till 2.x?
> I took offence at being accused of having little clue.
I do not see how you take it as an insult, or you are just overreacting. I still say the same, you have no idea of what "inherently flawed" platform means, or how it can apply to VM based languages.
Some pretty deep thoughts you're writing out there. This is quite a gem:
Quoting:for many number crunching apps, java is faster than gcc
Unless you have an 'interesting' definition of many, WTF are you talking about? Aside from the fact that gcc is a compiler, when you should be talking about languages, the claim that Java is faster than C for numerical computing is one of the most insanely uninformed things I've ever read.
Don't bother responding with one of your "well what I said was actually..."
in krisum's defense...
Though I would never choose java for serious number crunching, I'm not sure I would choose a java developer to write a number crunching app, either.
The thing with C is that you need to write it well, and that includes taking the time to think about it --- and debug/test it.
Don't know if today's spoiled and lazy developers could properly wrap themselves around writing good tight number crunching code. In that case, they might will get better results in java than in C. They would actually be relying on java code written by developers more talented than they are, and the end result, even filtered through all of that java abomination, might be faster than the C those clowns could muster.
To calculate the first 10,000,000 Collatz counts:
Java class: 8.4s ("-Xbatch" made no difference) Java compiled to native: 7.7s C: 5.2s
The actual calculation of the Collatz value uses identical code in each.
Where does she say all? If all is not stated, the general case is assumed. This is simple logic 101, and I don't see any point in debating the matter any further. The thread's already gotten too long.
> ...as a non-developer she (or yourself)
While I am not currently a developer, I have written code before.
> Its like an MS guy saying "Linux is for not for desktops".
Which is exactly what I'd expect an MS guy, based on his frame of reference, to say. And you know something, within his frame of reference, he may even be correct. Linux doesn't yet have the universe of specialized apps to cover every need that Windows does. That doesn't mean it's not a better general purpose OS and can't meet the needs of most people.
> Besides the statement was not meant to express any facts, rather just to raise flames and one that has been repeated by her many times before.
Of course it was. Because she knows the type of people she's dealing with from previous experience and doesn't see any point in wasting time. So she goes straight to the point the conversation's going to devolve to anyway. While I, being less experienced in such matters, waste my time.
And you still haven't demonstrated that her remark was silly. Can you really demonstrate that >40% of .Net/Mono developers aren't lazy or incompetent. Of course not, and neither she nor I can prove that they are. So it comes down to an opinion shaped by historic stereotypes. As such, it's best just to point out that her comment is an opinion, agree to disagree, and be done with the matter. And if you had done so, instead of calling her remark silly, we wouldn't be having this discussion.
> Unless you have an 'interesting' definition of many, WTF are you talking about? Aside from the fact that gcc is a compiler, when you should be talking about languages,
Ya, the statement is technically incorrect; it should rather have been something like "Sun's/... JVM for java is faster than gcc's implementation for C". I don't know how one can compare languages for performance rather than their implementations. If you mean theoretically, then as per theory not much comes to mind to choose between the two as far as perf is concerned -- one that comes to mind is better use of stack for value types in C/C++.
> the claim that Java is faster than C for numerical computing is one of the most insanely uninformed things I've ever read.
Well if I point you to some benchmarks you can very well point to others that show opposite, and this game will not be much fun. Even so I will point to one: http://www.stefankrause.net/wp/?p=4 which leaves out JVM "warmup" times to get more realistic numbers. Suffice to say, in my company we have benchmarked extensively and it turns out that for many scenarios the performance of JVMs is right up there with ICC (again leaving out first few runs which are not interesting for our scenarios). The reason is simply this: modern day JITs can generate optimized code for that particular processor taking advantage of all the processor optimized instructions. GCC will normally optimize for one particular processor and have hints for another processor (at least until recently), while ICC can generate optimized code for multiple architectures and choose the best one at runtime. In a realistic scenario one would ship a C++ program optimized for something like P2 rather than the processor being used.
@dino
> Don't know if today's spoiled and lazy developers could properly wrap themselves around writing good tight number crunching code.
For something like multi-threaded programs things go to another level. Its hard to get multi-threaded programs correct in the first place leave alone performant. I have seen even many experienced and good devs falter on something seemingly as simple as a producer-consumer queue, or a read-write lock or even a singleton class. Then, as I mentioned, my experience has been that its more likely to get incompetent developers from certain fields rather than language experience.
@gus3
Would it be possible for you to send me the code (sumwale at fastmail dot fm)? Thanks.
edit: corrected email address
@DiBosco
> Eclipse isn't only slow to start up, it even has a really annoying delay when switching perspectives. We can only agree to disagree, but I think you're deluding yourself.
Well I do not disagree on this, but why would slowness in switching perspectives be an issue at all? I hardly do it once in a few days, or when switching to debugging perspective, so this doesn't matter to me being a very infrequent operation unless, of course, your use is of an entirely different nature.
@jdixon
> This is simple logic 101 Really, I don't know what to make of this. Maybe you mean this: http://en.wikipedia.org/wiki/Generalization_(logic) ?
> Of course not, and neither she nor I can prove that they are. The claim is her's so should be the evidence.
I agree with that. I find C to be too difficult for my brain, so I use Fortran (and probably get better performance anyway). Number crunching code is not the place to learn to program.
"And it's based on a REAL compiled language not some slow Java-ripoff that requires a runtime download and that's designed specifically to lock you into one platform."
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Sign up and post (it is free) or Log in and post


Lousy .NET apps for small business is what actually got me doing rails. I saw what people were trying to foist off on a friend in the HVAC biz and cringed.
BTW -- I see no reason to prefer java over .NET. Without reference to my few forays into java coding (is it even possible to write a real-world java program without having to fully and completely learn some hideous framework?) my years of working in java shops (not on java, fortunately) have convinced me that it remains a promise unfulfilled. Java is the new COBOL, except for being less wordy and less efficient.
Come to think of it -- That's much too flattering to java. Much of the Y2K scare centered on COBOL code that was still running in major applications after 30 years. Quite a testimony.