Live from Brussels

Story: LXer@FOSDEM 2010: Anyone else going?Total Replies: 81
Author Content
hkwint

Feb 06, 2010
1:25 PM EST
Ok, the first day is over. Saw some interesting talks and lots of people. Tomorrow even more interesting talks, and I have the opportunity to see Mr Icaza and Mr. Hartman in real life!

More to follow later, this Azerty keyboard is a bit of a hassle when you're tired.
KernelShepard

Feb 12, 2010
7:25 PM EST
A bit late I suppose, but yea, I went. Got to meet Mr. De Icaza too, along with a number of the Mono folks. Really a nice bunch. Got to the Mono room a bit late and had to stand as there were so many people. So much for "no one is interested in Mono" FUD ;-)
tracyanne

Feb 13, 2010
7:17 AM EST
Quoting:So much for "no one is interested in Mono" FUD ;-)


I've known that lots of people are very interested, for quite some time. I get the Mono and monodevelop new feeds ad discussion treads.
KernelShepard

Feb 13, 2010
7:31 AM EST
Yea, I'm on the mailing lists for MonoDevelop and one of the Mono lists as well. I also tend to hang out in the IRC channels sometimes which always have a huge mass of people. Saw a comment the other day about how they've had over 600,000 downloads of Moonlight 2.0 since release (around a month ago).

Somehow 600,000 downloads in a month doesn't sound like the "minority" that the anti-Mono folks would like us all to believe.
hkwint

Feb 13, 2010
4:26 PM EST
Interesting, I was outside at the very same talk (Mono Edge, huh?) because the room was 'full'. Nonetheless, I peeked through the 3x3cm looking glass to see if it was actually Miguel talking, and indeed it was. That was one minute after I ran into Mr. Tanenbaum in the hall (who was hanging a vacancy on the wall), so it seems FOSDEM is an interesting place to be.

Today seems like a good day to make an article of the notes I took. However, old fashioned as I am and like said - the notes were taken using a pencil and paper notebook, so it might take some time.
KernelShepard

Feb 13, 2010
5:57 PM EST
I actually went to a couple of the Mono talks (Miguel's, the SIMD talk, the Second Life talk, etc). All pretty interesting.

I'd be interested in reading your article, you likely attended talks I missed, etc. Also I missed Tanenbaum - I'm sure he had interesting things to say.
tuxchick

Feb 13, 2010
7:42 PM EST
Where are the apps? Where are the hordes of happy .Net coders migrating to Mono, where is the shiny happy interop? Nine years has produced, what, Tomboy? F-Spot? Who uses Moonlight? Mono looks a lot like a multi-level marketing deal, where the only people buying it are the people trying to sell it.
hkwint

Feb 13, 2010
8:41 PM EST
KS: Would you be interested in writing some short summary about what they told about Mono? Then I could add that to the FOSDEM article if you wish. Last year we covered some 25 articles because Sander was there as well, this year I was alone. So much talks (over 200?), such a lack of time...

TC: Rhetorical question I believe? I even haven't written the article as of yet, KernelShepard hasn't said anything about Mono yet apart from having been there, and you're already starting the Mono debate. Isn't that a tiny bit early?
tuxchick

Feb 13, 2010
9:09 PM EST
eh? Hans, you and KS have both been talking about Mono this whole thread. Is there an official moment to chime in?
Steven_Rosenber

Feb 13, 2010
9:11 PM EST
Maybe Microsoft could code Office for Linux in Mono. That'd be a way to win some friends, no?
tracyanne

Feb 13, 2010
9:11 PM EST
KS, HK, I'd be interested in that article.
tuxchick

Feb 13, 2010
9:22 PM EST
I'd be interested in a citation for that 600,000 download figure. It seems rather unrealistic, since virtually no Web sites support Silverlight/Moonlight.
jdixon

Feb 13, 2010
10:17 PM EST
> ...since virtually no Web sites support Silverlight/Moonlight.

No public web sites, TC. I'd bet there are a number of corporate web servers at Windows centric businesses which support it for internal use.
KernelShepard

Feb 13, 2010
11:09 PM EST
tuxchick: as jdixon noted, there are likely a lot of internal Silverlight websites - it's one of the main ways Microsoft is pushing it. You probably haven't seen this because you don't work for a Windows shop.

They're basically pushing it for 2 purposes:

- SmoothHD (for which they sell server licenses; also the most common use for Silverlight on the public web)

- internal web apps - Windows developers love it because it makes writing web apps more-or-less the same as writing desktop apps. It's actually a lot more viable than Flash for this purpose (since it's targeted at developers rather than designers). Your C# and VB devs can suddenly easily write web apps and your python and ruby devs can too - with the added bonus of much better performance.

FWIW, another place .NET is starting to take off is in the financial industry (namely with F#). If Microsoft were smart, they'd start really focusing on F# (they currently aren't afaik). Likewise for the Mono guys.

As far as "where are the killer apps?". Let me ask you this: where are "killer apps" for Java, Python, Jython, Perl, etc etc? There are no killer apps. The point of these languages isn't about killer apps, it's about productivity. The "killer apps" argument has always been a strawman.

Python is very popular among Free Software developers because of its productivity advantage over C/C++ which are tedious for writing applications in quickly (low level + memory management).

High level, garbage collected languages are ideal for the weekend-warriors which is what a large portion of the Free Software developer pool are.

From what I've read, Miguel got frustrated with spending countless hours tracking down memory leaks and ref-counting issues in GNOME, saw what Microsoft was doing with C# and .NET, and felt it was the answer to his problems.

Why not Python? Not everyone likes dynamic languages. Some (like myself) prefer statically typed languages.

Why not Java? Well, Java wasn't Free Software at the time (and note that a number of the core Mono devs started what later became the GNU Classpath project - the original name was Japhar iirc, I'll let you google that) and the JVM didn't have some advantages like the .NET runtime had (namely that it was designed specifically to be able to be used by multiple languages). You might notice that this is another focus of the GNOME community - lowering the bar for weekend warriors and allowing them to write software in any language they were most comfortable with. That is why they have Perl, Python, C++, .NET, and Java bindings (and possibly others).

Now, I know you have a hatred for Miguel because he has cloned a number of MS technologies (like COM, which, btw, even KDE cloned - DCOP - and is what KParts is built upon - same with Mozilla and XPCOM and OpenOffice with its UNO). COM was just a IPC API/protocol allowing applications to embed other applications. One might even argue that it follows the "UNIX Philospohy" of using pipes ;-)

Which brings me to another solution to problems that Miguel was facing - Bonobo was a PITA to code for. Instead of designing his own IPC protocol/API (like KDE did, and like GNOME is doing now with DBus), he built upon CORBA which was a nightmare to use from C which is why there were only ever 2 (or maybe 3?) applications in GNOME that ever used Bonobo (or, at least, heavily). Those were Nautilus and Evolution. They also happened to be the only 2 applications that were being developed almost fully by full-time GNOME hackers. Weekend-warriors just couldn't wrap their heads around such a difficult API to use. Not to mention the design problems (such as what happens if the app on one end of the CORBA connection disconnects leaving refs unaccounted for? Or worse: crashes?).

Core .NET comes with a much simpler COM-like API/protocol referred to as "Remoting".

So I think all of these issues are what made Miguel decide to implement Mono.

(PS. sorry for the longish history lesson)
KernelShepard

Feb 13, 2010
11:14 PM EST
Quoting:I'd be interested in a citation for that 600,000 download figure. It seems rather unrealistic, since virtually no Web sites support Silverlight/Moonlight.


It was an offhand comment on the #mono IRC channel iirc. I've since logged out of IRC (although even if I hadn't, it'd likely be long scrolled out of my backbuffer).

Also, it wouldn't surprise me if a lot of those are from people wanting to view the NBC Olympics footage.
tuxchick

Feb 13, 2010
11:56 PM EST
Quoting: Now, I know you have a hatred for Miguel


Dopey comments like that that are why you have so little credibility with me. The history lesson is nice, but I have no idea which parts of it are believable, or come from the same fountain of unsupported Mono hyperbole.

Quoting: The "killer apps" argument has always been a strawman.


A strawman trotted out with tiresome regularity by Mono proponents who claim that Mono needs to be in the default Ubuntu image, and someday an integral part of Gnome, because of 'Killer Best of Breed' apps like F-spot, Tomboy, Banshee, Beagle etc. (Which are killer, but not in a good way.)

Y'all enjoy your FOSDEM convo, I'm outa here, I've rained enough on this parade. (well there does come a point where it's bad manners.) And like Hans said there is material for a good LXer feature or two here, don't fritter it all away in the comments.

KernelShepard

Feb 14, 2010
6:54 AM EST
Quoting:Dopey comments like that that are why you have so little credibility with me. The history lesson is nice, but I have no idea which parts of it are believable, or come from the same fountain of unsupported Mono hyperbole.


No, I've "lost credibility" with you because you hate to admit that you are making judgments about Mono from sound-bites you've read over at BoycottNovell and Slashdot from people with a similar lack of historical context. It's clearly about ego for you - you've dug yourself into a trench and you'll never allow yourself to admit that, just maybe, you were wrong on this issue.

FWIW, the history lesson is provably accurate as it is all on the public record (isn't the internet great?). The fact that you seem unwilling to even google the information I've given you goes a long way toward supporting my claim of your stubbornness. You are hiding your head in the sand and singing "la la la la! I'm not listening!"

Quoting:A strawman trotted out with tiresome regularity by Mono proponents who claim that Mono needs to be in the default Ubuntu image, and someday an integral part of Gnome


So because there are people independent of the Mono developers/project that you disagree with, you attack Mono developers and their project?

How mature of you.
KernelShepard

Feb 14, 2010
7:29 AM EST
Since you aren't willing to do the 5 minute job of searching the internet to verify my history lesson, allow me to aid you in this quest:

Since I'm not sure which of my historical facts you are having trouble swallowing, I'll start with "why not java?" (since the "why not python?" answer is purely one of personal preference).

Mono was started in April 2001. Java was proprietary until November 2006.

http://en.wikipedia.org/wiki/Mono_(software) http://news.cnet.com/Sun-promises-to-open-source-Java/2100-7... http://en.wikipedia.org/wiki/Java_(programming_language)

Google search results for "Japhar", first link:

http://www.hungry.com/old-hungry/products/japhar/

Other links of interest (pertaining to Japhar):

http://en.wikipedia.org/wiki/Chris_Toshok

"With the Hungry Programmers he launched one of the early efforts in the 1990s to create an open source Java Virtual Machine called Japhar. Japhar's main contribution was the open source implementation of the class libraries, these class libraries would eventually become part of GNU Classpath."

http://en.wikipedia.org/wiki/GNU_Classpath

"GNU Classpath development started in 1998 with five developers.[citation needed] During the history, it merged several times with other projects having similar goals (Kaffe, libgcj). In the past, GNU Classpath supplied its own virtual machine (Japhar)."

Regarding Bonobo:

Explanation of what Miguel saw in COM (and the reasons for Bonobo):

http://primates.ximian.com/~miguel/bongo-bong.html

A GNOME dev's point of view about why Bonobo was so hard to use:

http://live.gnome.org/Bonobo

The "2 or 3 programs ever used Bonobo" thing is my own recollection, however I'm pretty confidant that I'm right (or at least not far from the mark). I know Evolution used it. I know Nautilus used it.

One of the reasons this is in my head is because back in 2001 or 2002, I looked into Bonobo out of curiosity and found it to be extremely cumbersome and in the process looked for other programs that used it to help me get a better feel for how to use it myself. I concluded that it was an interesting concept, but gave up on it for my own personal use in my "weekend warrioring".

Hopefully that provides the necessary proof that you need to trust my history lesson. Or, if not, hopefully it has at least gotten you interested in reading up more on the history of these things in an effort to find yourself a little "trump card" to use against me ;-)
jdixon

Feb 14, 2010
8:51 AM EST
KernelShepard, you're wasting your time. Most of the people who don't like Mono simply don't like Microsoft's involvement in the project, as they don't trust Microsoft. If you're willing to trust Microsoft, if you believe that the Mono licensing renders their ill will impotent, or if you find the Mono apps attractive enough to overcome any reservations you might have, then use Mono. But don't bother arguing the technical reasons why Mono exists or why it's a good thing, as they're beside the point. The key issue has always been and always will be Microsoft.
KernelShepard

Feb 14, 2010
9:26 AM EST
jdixon: While I understand that people hate Mono because they associate "Microsoft" with it, it's not a justifiable reason to badmouth the developers (who are good people with good Free Software intentions) nor their project. It also means that she is making a stand based on emotion rather than logic.

It doesn't serve any purpose but to weaken the Free Software community. Even if Carla's worst fears about Mono inclusion came true - what's the worst that could happen? Realistically? Every distro that shipped that software (including Novell's SUSE) would have to swap in alternative apps written in some other language. Big deal - it's not a problem that is insurmountable.

(Edit: or they'd have to port those Mono-based apps to C/C++ - which can obviously be done, see Gnote for example)

And that's only assuming that the developers (of Mono and/or the project(s) itself) were unable to find prior art or work around the patent.

As far as trusting of Microsoft - I don't trust Microsoft out of a belief that they are "Good Citizens", but rather:

1. that the Mono developers will do their best to work around any patent they are accused of infringing (and, because Mono is Free Software, it means other developers could step in and assist them - including myself - because FOSS is empowering)

2. it would be political suicide (Mono is gaining popularity even in the Windows developer community - especially in the gaming industry where Mono is replacing Lua as the AI scripting platform).

3. that Microsoft really doesn't have any legal grounds to sue. a) they've issued a Community Promise b) there is tons of prior art on their BCL (borrowed heavily from Java and C++'s STL/Boost) c) there is tons of prior art on VMs (.NET's VM is not rocket science - it borrows from the JVM, Smalltalk, etc)

While a, b, and c might not cover things like Windows.Forms, it's not the UI toolkit that the Mono developers are pushing anyway. They seem to have made it only as a temporary solution for people looking to port their existing apps to Linux.

As far as ADO.NET, it's nothing more than a rebranding of the same sort of APIs that every other language/platform has for database abstraction (ODBC).

It's just an abstraction layer. Kinda hard to patent that. Worst case scenario is that any Mono apps that use ADO.NET would be forced to use an ODBC API (which I believe there are already available for .NET anyway).

I guess the difference between us is that I'm a glass-half-full kind of guy and you/Carla are glass-half-empty.

I just have faith that Free/OpenSource Software will always overcome.
jdixon

Feb 14, 2010
9:45 AM EST
> While I understand that people hate Mono because they associate "Microsoft" with it...

Hate isn't the correct word, but that's not worth arguing.

> it's not a justifiable reason to badmouth the developers (who are good people with good Free Software intentions) nor their project.

Actually, it's a very good reason to badmouth their project. It's also a good reason to question the developer's judgment and/or motives.

> 2. that Microsoft really doesn't have any legal grounds to sue.

Which is essentially reason number two, you think the licensing renders them impotent. I've seen Microsoft break licenses before (Java is one example) and dare the other party to sue them.

> I'm a glass-half-full kind of guy and you/Carla are glass-half-empty.

I'm a "the drink is probably poisoned" kind of guy.

> I just have faith that Free/OpenSource Software will always overcome.

I hope you are correct, but I see no reason to take unnecessary risks. Mono is (IMO) an unnecessary risk.
KernelShepard

Feb 14, 2010
9:58 AM EST
> I'm a "the drink is probably poisoned" kind of guy.

Heh. Okay ;-)

> I hope you are correct, but I see no reason to take unnecessary risks. Mono is (IMO) an unnecessary risk.

I respect your opinion that to you, it is an unnecessary risk. Hopefully you respect that other people feel differently. I think from our conversations in the past, you do - you simply remove Mono apps that may be pre-installed by your distro and move on with life.

I think that's fine and I think that's the healthy approach.

I don't, however, feel that it is healthy to go on a rampage attacking anyone who works on Mono or likes Mono. And that's what upsets me about the anti-Mono trolls and Carla herself. Especially since I presume that Carla is an intelligent person, it frustrates me that she "shoots from the hip" without knowing the facts (as I clearly demonstrated above).

We can respectfully disagree all day long on the risks, but it's important for Carla to know the facts - because, let's face it, until you know the facts - you can't make an informed risk analysis. Carla is basing her risk analysis on emotion (which is, in turn, based on sound bites) as opposed to facts.

(Edit: okay, I'm gonna follow jdixon's approach to quoting because clearly I keep fudging the quote tag)
gus3

Feb 14, 2010
10:21 AM EST
Quoting:what's the worst that could happen? Realistically? Every distro that shipped that software (including Novell's SUSE) would have to swap in alternative apps written in some other language. Big deal - it's not a problem that is insurmountable.

(Edit: or they'd have to port those Mono-based apps to C/C++ - which can obviously be done, see Gnote for example)
After six years of legal fees, lawyer salaries, and diverted resources, IBM and Red Hat can tell you that's merely the tip of the iceberg. And that's without a strong court case.

As for Java being proprietary, that is correct on its own, but Sun did have coders working on GPL-based projects for general distribution. They were working on the Gnome Accessibility as far back as 2000; I was privileged to see an early demo on Solaris.

Microsoft, on the other hand, are convicted monopolists. Unrepentant, unreformed. The history (EDIT: unsealed evidence, not history) of the Comes v. Microsoft is undergoing transcription right now at Groklaw. Oh, and don't forget the Halloween Documents.

http://www.kmfms.com/whatsbad.html?no_custom_colors=true

More recently: the patent-encumbered Office Open XML, which M$ strong-armed the ISO into accepting. This, despite legitimate objections from all over the populated world, about both the standard itself and the committee's mis-handling of the process.

As an exercise for the reader: Compare/contrast the difficulties faced by Blackdown's Java reimplementation project, with the difficulties faced by the Samba project.

(Sorry about the misstatement, discovered after a single gulp of coffee.)
KernelShepard

Feb 14, 2010
11:16 AM EST
> After six years of legal fees, lawyer salaries, and diverted resources, IBM and Red Hat can tell you that's merely the tip of the iceberg. And that's > without a strong court case.

Yes, what SCO did was despicable. But as you've pointed out, anyone can sue anyone else without a case and it'll cost both parties huge legal fees. Generally it's not what either party wants, though. In SCO's particular case, they did it as a last-ditch effort to make money before they died out. To them it was a do-or-die (not trying to say what they did was right, it wasn't).

Microsoft isn't in that situation. So you are comparing apples to oranges.

If Microsoft were in that situation, I'd likely feel that the risk of developing in Mono was higher. But they aren't, nor are they likely to be anytime soon.

> As for Java being proprietary, that is correct on its own, but Sun did have coders working on GPL-based projects for general distribution. They > were working on the Gnome Accessibility as far back as 2000; I was privileged to see an early demo on Solaris.

Never said otherwise. I think, for the most part (there are exceptions), that Sun was a much more FOSS-friendly company than Microsoft was/is. But keep in mind that Sun wasn't always FOSS-friendly, they changed... gradually. It seems to me that Microsoft is also changing... gradually. Only time will tell for sure.

Back in 2000, Sun did contribute to GNOME - but they didn't do it out of the goodness of their hearts. They did it because CDE was aged and their customers wanted GNOME. They worked on a11y because their customers included government agencies that required a11y certification.

Likewise, Microsoft is contributing to FOSS today - not out of the goodness of their hearts, but because of customer demand.

Customer demand is a very powerful thing.

Remember how I said one of the reasons I find the risk of developing in Mono acceptable is because I think it'd be political suicide for Microsoft to attack? That's customer demand.

> Microsoft, on the other hand, are convicted monopolists. Unrepentant, unreformed. The history of the Comes v. Microsoft is undergoing > transcription right now at Groklaw. Oh, and don't forget the Halloween Documents.

Exactly. And because of this, their hands are much more restricted in their ability to attack their competitors without the fear of government / EU intervention.

Another thing that reduces risk.

> More recently: the patent-encumbered Office Open XML, which M$ strong-armed the ISO into accepting. This, despite legitimate objections from > all over the populated world, about both the standard itself and the committee's mis-handling of the process.

I agree, it was pretty shady. But at the same time, it was always likely that ISO would have accepted the standard anyway eventually. Remember that ISO isn't about enforcing one way of doing things - their job is just to publish specifications after they certify that they are implementable.

Since OpenOffice and some other office applications have been able to implement the specification, it is clearly implementable. Now, these implementations might not be compatible with Microsoft's Office due to Microsoft not following the spec exactly is outside of the scope of ISO. They are not enforcers.

(on the same token, ODF has been criticized for not defining spreadsheet formulas which makes it impossible to implement)

From what I can tell, there was some shady dealings on both sides. I'm in support of truly open document formats (which I don't believe OOXML is) because, I believe, it is important for all office suites to be able to read/write to a common document format, but it's pretty clear to me that neither specification is without its own share of problems.

I don't know which specification is better technically, because I haven't read either of them. But politically, I side with ODF. But siding with ODF doesn't mean that I believe that OOXML shouldn't be allowed to be accepted by ISO. In fact, I believe it to be a Good Thing(tm) because it forced Microsoft to document their format. While the specification may not be 100% accurate, it's still a lot better than no documentation. Whether we like it or not, Free Software office applications will need to be interop with Microsoft. This goes back to customer demand (luckily that demand is probably also being directed at Microsoft as well).

> As an exercise for the reader: Compare/contrast the difficulties faced by Blackdown's Java reimplementation project, with the difficulties faced by > the Samba project.

No doubt. But let's also note that Microsoft never sued the Samba project ;-)
hkwint

Feb 14, 2010
12:05 PM EST
Quoting:Is there an official moment to chime in?


Of course not, it's jut that I was trying to discuss FOSDEM. And yet another thread turned into pro/anti Microsoft and Mono. Such a waste! I could better title every thread 'Mono flamefest' in the future I guess, no matter what I have to say.
TxtEdMacs

Feb 14, 2010
5:10 PM EST
Hey Hans,

It's your buddy, KS that has the flame thrower. Please catch him before s/he does more harm. Presently, appears to be the contra boycott Novell voice and image. You know when we see wild, long postings where most others are silent it never ends well.

Hey was it you that opened a PayPal account for me? Just send cash with the usual contraband package. Saves on postage and taxation.

YBT
DiBosco

Feb 14, 2010
7:58 PM EST
One of the things that people never seem to focus on with Mono, .NET (and indeed Java) is that they seem to produce slow and/or bloaty programs. I've installed a few .NET programs and they've all been dire, slow, big horrible affairs. Same with things like the Java based Eclipse. From what I understand, (I could be wrong) these things are virtual machines which are bound to be slower than native code. I have had a couple of Mono based program run on Mandriva and been horrified how slow they were, so always make sure Mono is uninstalled now.
gus3

Feb 14, 2010
11:13 PM EST
@DiBosco:

Correct on the VM thing.

As for bloaty, well, I have my favorite Collatz sequence calculator, done in both C and Java (and some others). The C and Java codes are very similar, but the C version compiles (with -O3) to 9300 bytes, while the Java version compiles to a Java class in 1170 bytes. So, at least on my machine, that makes the Java version less bloaty, but slower.

(EDIT: 9300 bytes, including debug info. Stripping the binary takes it down to 4744 bytes.)
KernelShepard

Feb 15, 2010
8:01 AM EST
DiBosco: Programmers targeting VMs (JVM, Mono, .NET, Python, etc) are fully aware of the performance overhead of doing so. Or, at least, I know I am ;-)

It sounds like you've got an older desktop machine as I don't notice any slowness at all in Mono-based apps and barely notice any slowness in Eclipse (other than taking a long time to start up - I'm on a Core2 duo 2.4GHz machine for comparison). That said, it's not always appropriate to target VMs depending on what your customer's needs are (if they require the software to run on low-powered machines, then you probably don't want to drag in a VM).

One of the nice things about .NET is that it makes it trivial to call into native C code for your performance-critical sections, allowing you to take advantage of RAD and still get performance where you need it most. With Mono, you can also fully AOT (ahead-of-time compile) your programs and make them into native binaries.

Even still, using C#, Java, or Python instead of a low level language is a trade-off. No doubt about it.

gus3: The reason for this is because the VMs do the optimizations at run-time (unrolling loops, inlining methods, etc) whereas gcc is doing it at compile-time. If you compile that same C program with -Os, you'll likely find it to be massively smaller. With -O3, gcc attempts to inline as much as it can which generates a lot of binary code bloat. Using -O2 should also make a noticeably smaller binary and likely not lose much in terms of performance - the problem with inlining a lot of things is that sometimes the compiler guesses wrong and you just end up causing a lot of cache misses which just stall the CPU pipelines.
TxtEdMacs

Feb 15, 2010
10:48 AM EST
[serious] Just read two commuter trains collided [B.B.C.], this morning. Are our guys OK? Did not see any numbers on casualties.

[Edit] States side reporting well over ten killed.
TxtEdMacs

Feb 15, 2010
11:14 AM EST
victimsoflefty

Do you work for Fox News?

YBT

P.S. [serious] At least 18 confirmed dead. Moreover, most probably never heard of mono or even Mononucleosis. Since years ago I missed being a casualty in a commuter train wreck when I switched campuses, I find no joy in contemplating the wrecked lives of those that survived and those left behind. So cool it. You are making KS looked like a reasonable individual.
gus3

Feb 15, 2010
11:55 AM EST
@KS:

$ gcc -Os -o collatz-Os collatz-nothread.c $ strip collatz-Os $ ls -l collatz-Os -rwxr-xr-x 1 gus3 gus3 4752 2010-02-15 11:48 collatz-Os $

Also, I blundered on the earlier size; I left in the debug info.

But both are still larger than the Java class.

As the dictum says, all programs contain at least one bug and one unnecessary instruction. So, by logical extension, all programs can be reduced to one opcode that doesn't work. (If Intel keeps on this path, we might see that within my lifetime!)
DiBosco

Feb 15, 2010
1:38 PM EST
Quoting:It sounds like you've got an older desktop machine as I don't notice any slowness at all in Mono-based apps and barely notice any slowness in Eclipse (other than taking a long time to start up - I'm on a Core2 duo 2.4GHz machine for comparison). That said, it's not always appropriate to target VMs depending on what your customer's needs are (if they require the software to run on low-powered machines, then you probably don't want to drag in a VM).


I have had a similar discussion on a different website on this topic. I have a Core 2 duo 2.13GMHz (and my old P4 3GHz). On both of those, things like Rowley Crossworks (which is an IDE for writing code for things like ARMs, Atmel AVRs and TI's MSP430s) absolutely fly along. I once looked at using Codesourcery for developing come code for a Freescale Coldfire part, but that was Eclipse based and, even on my faster machine, just to switch between perspectives there is a really annoying delay. (I have come to the conclusion, this delay annoys some people more than others.) Compare that with Crossworks which written using the Qt toolkit, so you get native code on all three OSes, and Crossworks is instantaneous when switching between debug and coding. Also, Crossworks is a fraction of the size of Eclipse.

I've also had to use the truly dreadful TI Code Composer Studio on Windows which is .NET and again, it's just massively big and slow compared to Crossworks running on the same machine, so I don't really buy it being a thing about machine speed. Then there's Nikon's utterly awful NX2 bloatfest with is .NET and other smaller programs I've had to install in previous jobs. All been horrid in my experience.

I'm doing some GUI stuff at the moment and although it can be a little slow to initially boot I am pretty impressed with Qt Creator. It's snappy when booted and actually really quite nice to use. Again, it's a native application for all three OSes. Not only that, it seems pretty good for rapid development. Now, you have to bear in mind I haven't touched C# because I don't touch anything but Linux these days, so I don't know whether C# would enable you to develop a product faster. However, even if it does, I just don't see it being a good thing, because to me, in my experience, the user experience is horrid! :~)

Quoting:One of the nice things about .NET is that it makes it trivial to call into native C code for your performance-critical sections, allowing you to take advantage of RAD and still get performance where you need it most. With Mono, you can also fully AOT (ahead-of-time compile) your programs and make them into native binaries.


Again, I really don't know how it compares to something like Qt creator - or even Delphi which wasn't _too_ bad (other than the confusion between switching from Pascal to C!).

Quoting:Even still, using C#, Java, or Python instead of a low level language is a trade-off. No doubt about it.


As a matter of interest, what do you call low level in this case?

As an aside, I love Python for certain things like text file parsing. It is a very cool language in certain cases.
gus3

Feb 15, 2010
2:13 PM EST
Quoting:As an aside, I love Python for certain things like text file parsing. It is a very cool language in certain cases.
Concur Yr Analysis. Python is the only language I've encountered so far, that has multi-threaded, iterative function-calling over an array in its standard library. Too cool.
KernelShepard

Feb 15, 2010
3:36 PM EST
> As a matter of interest, what do you call low level in this case?

C or C++ (you wouldn't generally write applications in asm these days, but it'd count too)

At one point, C and C++ were considered "high-level" and a lot of the same performance arguments were used against them because it was felt that a compiler could never optimize code as well as a human. However, times have changed: C compilers have improved a lot since the early days, machines have gotten so much faster and software has gotten so complex that it's generally not worth getting down into asm except for taking advantage of SIMD in most applications.

I suspect the trend will continue and we'll see C#/Java (or similar) being the next "low level" languages ;-)

Given a competent programmer, the native programs written in C/C++ will likely always be faster than those written in even higher level languages (similarly, asm programs will always be faster than the C programs). The problem is that as the complexity of applications increases, the cost of writing/maintaining that software increases exponentially and the only way to mitigate that is improved developer tools (of which language choice is one option).

In a way, it's like physical products as well. Things that were once hand-made with care are now machine made on a robotic assembly line with less QA.

It's good and it's bad - there's a trade-off. Costs less money to produce, thus allowing more people to be able to afford it, but it's also not quite as high a quality.

In the case of software, using higher level languages cuts cost by cutting development time, but hardware demands are higher. However, computer hardware is also advancing really fast right now and cost of hardware is really low.
DiBosco

Feb 15, 2010
3:53 PM EST
My first experience of programming was Z80 assembly language and I did my first serious commercial programming on the 8051 family. When I look at the Qt C++ I'm doing at the moment it seems quite amusing to think of it as low level. ;~)

I actually only really started programming in C on microcontrollers and really getting away from asm in 2001, even then it took quite some time to think in terms of using C's power rather than just using C in an assembler style! It's now quite hard trying to use OO programming properly when you come from a run-to-complete background. So, point I'm trying to make in a round about way is that I understand what you mean about the trade offs and how hardware is becoming more powerful and cheaper. The really high level languages still really impact on things like Netbooks I think, where you have less powerful processors to consume less power. So, maybe it's still important to try and be neat and lower level about coding. It may not be practical with some apps I suppose, but in a way I think I'd rather progress to new apps was slower, but the programs lighter and faster.
hkwint

Feb 15, 2010
5:10 PM EST
TxtEd: Yes, OK, I don't live in Belgium BTW, and I always stay out of Brussels unless I really have to go there (only FOSDEM it seems).
KernelShepard

Feb 15, 2010
6:54 PM EST
> When I look at the Qt C++ I'm doing at the moment it seems quite amusing to think of it as low level. ;~)

I was actually just playing around with QtCreator since you mentioned it earlier. It seems very nice (but I've already run into a couple of bugs wrt smart indent). I'm a lot more impressed with it than I was with KDevelop (the early versions were very impressive back in the late 90's but it seems like it hasn't kept up?).

Lately I've been using MonoDevelop a lot as it can import Microsoft Visual Studio projects (I write software on whatever platform the customer wants, and sometimes they want it on multiple platforms). In Windows, we've used Visual Studio and so it's nice to have an IDE on Linux that is able to work with their project files. It's come a long way in the past 2 years since I first looked at it and we may start using it in Windows soon as well (since they've been working on making it work on Windows too).

> I actually only really started programming in C on microcontrollers and really getting away from asm in 2001, even then it took quite some time to > think in terms of using C's power rather than just using C in an assembler style!

I know what you mean!

> The really high level languages still really impact on things like Netbooks I think, where you have less powerful processors to consume less power.

Agreed. Definitely C/C++ are not going away anytime soon (especially in the hand-held/netbook devices).

We still write most of our customer's software in C++, but most of our internal software tools are written in Mono these days.

Personally, I'd love to write everything in Mono because C# is a lot more pleasant for me ;-)

(this is also why I'm very interested in progress they are making on performance, their new GC, and SIMD, etc)
DiBosco

Feb 16, 2010
4:39 AM EST
Quoting: was actually just playing around with QtCreator since you mentioned it earlier. It seems very nice (but I've already run into a couple of bugs wrt smart indent). I'm a lot more impressed with it than I was with KDevelop (the early versions were very impressive back in the late 90's but it seems like it hasn't kept up?).


I played around with the smart tabs and changed the options. I like Whitesmiths style of coding and it was screwing that up until I played with the options. No idea whether it would help you, but maybe worth a try? Nokia seem very open to bug reports and feedback, so if you can't solve it, it's worth reporting. I have been using it for a few months and I'm already on third versions, so updates come fairly quickly.

KDevelop was ok on KDE3.5 and almost non existent on KDE4, I only started using it a couple of years ago, so I can't really comment on what it was like in the late '90s! I would say Qt creator is *way* better, much more intuitive and Nokia seem to be putting a whole load of effort into it. Install Qt Designer too, it'll be in repositories probably (it is on Mandriva) and right click on the .ui file to open it in Qt Designer. This is especially useful if you have two screens.

I do know what you mean about Cross Platform development and what customers want. This is a big reason for liking Qt Creator, because I can do all the design on Linux and then just recompile for other OSes with minimal or no tweaking. I understand the attraction of Mono therefore. :~)
KernelShepard

Feb 16, 2010
8:40 AM EST
Ah, thanks for the info. Good to know that Nokia is good about fixing bugs (I had a feeling they were). I'll submit bug reports after playing around with the options, maybe that'll even solve the bug I was seeing.

I think the most impressive part about KDevelop back in the KDE 1.0 days was that it was kinda the first IDE for Linux that I ever saw that had a way to build UI's built right in. I had seen some others (codeforge or something like that?) that were basically just an editor that didn't fit into my desktop (I was on KDE back in those days and whatever other IDE's I tried seemed to use motif or something).

Reminiscing about KDE 1.0. What a beautiful desktop that was at the time, especially compared to what I had been using (xfm, fvwm / windowmaker, xterm).
tuxchick

Feb 16, 2010
10:27 AM EST
Huh. So much for Fosdem.

So, in a nutshell, C# and Mono are for lazy, not-very-skilled developers who value their own convenience more than the user's experience or releasing a quality product, who want to replicate the Microsoft experience on Linux, and who have the Microsoft philosophy of "ship it lardy and sloppy, them users can just go out and upgrade again."

Did I miss anything?
krisum

Feb 16, 2010
3:47 PM EST
> Did I miss anything?

Yes, coming from someone who is not a developer this is a pretty silly summary.
tuxchick

Feb 16, 2010
10:58 PM EST
--
jdixon

Feb 17, 2010
9:09 AM EST
> ...Yes, coming from someone who is not a developer this is a pretty silly summary.

Ah. The "You're not a developer, so your views don't count." response. Taking lessons from the KDE4 team?

Since C# is a Microsoft invention, and Mono is a reimplementation of .Net (yes, that's a synopsis, not the complete story, but it'll do for this discussion), and Microsoft development suites have historically been exactly "for lazy, not-very-skilled developers who value their own convenience more than the user's experience"; what exactly is so silly about the summary?

The main selling point of the Microsoft development suites has always been that they allow any half competent code monkey to churn out usable code quickly. It's never been about the quality of the code produced.
bigg

Feb 17, 2010
9:28 AM EST
> they allow any half competent code monkey to churn out usable code quickly

I'd change that to

they allow any not completely incompetent code monkey to churn out code that runs without giving it much thought

That's not to say that all the code ever written in a Microsoft environment is bad, or even that most of it is bad, the point is that the advantage is that Microsoft lowers the barrier to entry.
jdixon

Feb 17, 2010
10:09 AM EST
> I'd change that to...

Equally valid, yes. And yes, a good programmer can produce good code using the Microsoft tools.
krisum

Feb 17, 2010
1:08 PM EST
> what exactly is so silly about the summary?

Probably you may consider reading better. The comment "C# and Mono are for lazy, not-very-skilled developers who value their own convenience more than the user's experience or releasing a quality product" would have been stupid if it would have come from a developer.
tuxchick

Feb 17, 2010
1:09 PM EST
It sounds to me that KS is promoting churning out bloaty, inefficient, less-than-competent code as a matter of policy. Not because beginners have a lot to learn and should improve their skills, and will learn better coding practices and better tools, but because churning out junk in a hurry is OK, because it is more pleasant for developers and because it shifts substantial costs downstream, such as poor user experience and forced hardware upgrades, and someone else cleans up the mess. If it ever gets cleaned up. If that is what Mono brings to Linux, that is hardly a recommendation. It is the Microsoft way, and I am at a loss to understand why the FOSS world should want that.

Though I don't believe it is more pleasant for developers who take pride in their work and have skill and professionalism.
tuxchick

Feb 17, 2010
1:11 PM EST
Krisum, I think I summarized accurately what KS said, who claims to be a developer. You're welcome to demonstrate otherwise.
krisum

Feb 17, 2010
2:26 PM EST
> KS is promoting churning out bloaty, inefficient, less-than-competent code as a matter of policy

Where is that? All I noticed was his remarks about high-level/low-level and speed (which are inaccurate in any case), though I may have missed it having skipped much of his long diatribes.

Interestingly, some of the best code I have seen yet has been written in ... java, the elder brother of C# -- not C/C++, haskell, scheme, prolog or any of the other "low" or "high" level languages. I consider it to be the best not because it was the smartest piece of code, or because it was the most efficient or terse, but because it was one the best engineered code. Decent programmers can engineer and churn out wonderful code in most languages. Even so efficiency of coding in a particular language is a separate issue, and those who confuse the two do not understand the guts of programming.
jdixon

Feb 17, 2010
5:30 PM EST
> Probably you may consider reading better.

I think most of the people here will agree that there's nothing wrong with my reading comprehension.

> The comment ... would have been stupid if it would have come from a developer.

So, you contend that coming from a developer it would be stupid, while coming from a non-developer it's silly. OK, so, I repeat: What's silly about it?
dinotrac

Feb 17, 2010
5:39 PM EST
jdixon -

Ummm....It hurts me to say this, but I have to agree with krisum here, at least somewhat.

It really was a stupid comment for a developer to make on several counts.

Leaving out the "Microsoft experience" part of the comment, it's a rant that could be leveled at just about any language/development system at any time if you set the context. Certainly it could be leveled at Java which goes so far as to create its own Java look and feel that doesn't fit properly anywhere...

or all those lazy and not-very-skilled guys who develop web-based apps instead of custom-crafting well-honed user interfaces so that users can have the web experience (not to mention the familiarity with using web browsers and idioms)

TC don't like Mono. I get that. There are good reasons not to like mono, just like there are good reasons to hate java (did you pick up the stronger feelings about java than mono?).

Doesn't make goofy rants any less goofy.

DiBosco

Feb 17, 2010
5:59 PM EST
I do think the Kernel made interesting points about C# (much as I disagree with them). krisum, I don't think it matters how efficient code might be if it is written on an inherently flawed platform like Java or .NET.

On the flips side, I know for a fact that there are some C# developers who take great pride in their work - my best friend makes a living from it currently. I often take the **** because he used to write code using kdevelop, but I know he is a *very* conscientious programmer.

The problem, in my opinion, is that it doesn't matter how brilliant a programmer might be, if they use the wrong toolkit, his or her code will be slow and bloaty for the end user. Where I think the problem lies often is that it's not the developer who makes this decision, but the manager of the team who doesn't give a **** what the end user experiences, it's more important how fast a program is released.

I think it's a reflection on society about wanting things too quickly.

dinotrac

Feb 17, 2010
6:09 PM EST
DiBosco --

Yuuuuup.

I often get a blank look from management types who try to lecture me on time to market when I ask a simple question, in an exchange that goes sort of like this:

PHB: Time to market is everything. We can't miss the window of opportunity. Me: So -- we do whatever it takes to get this done as quickly as possible. PHB: Yes. Me: Make that first day of business as early as possible, right? PHB: Yup. Me: Planning on a second day of business?

If I'm feeling really catty I'll go into the search engine digression on how smart all of those search engine folks like Yahoo!, Alta Vista, AskJeeves, MSN, Excite, Lycos, and many more got into the market quickly so they could prevent Google from getting a foothold.

KernelShepard

Feb 17, 2010
6:40 PM EST
DiBosco: my personal feeling is that C# is a bit of an improvement over Java in that it allows pointers (which allows you to bypass bounds checking - although, as with C and C++, one must be careful as this is where most exploits tend to turn up) and easily allows P/Invoking into native libraries with something as simple as:

[DllImport ("libc.so")] int dup (int fd);

That's all that's needed. (You can invoke native code in Java as well, but you need to either write a wrapper library that contains the glue code necessary to invoke the underlying native function or else you have to write your native library functions specifically to be invoked by the Java runtime).

http://java.sun.com/docs/books/performance/1st_edition/html/...

And yes, there are definitely a lot of us C# (and likewise, Java) developers who take a tremendous amount of pride in our work and I would say that if the program was done right, the user should be unable to tell that the application is not a native application. I say this because the developers of these applications will have taken the time and energy that they saved by using a higher-level language and put that into fixing bugs, perfecting the UI and optimizing the slower areas of the code (offloading the performance-critical code segments to native routines if needed).

I'd argue that by using a higher level language (such as C#) and given the same amount of time for development, it should often be possible to write an application that is faster performing, uses less memory, is less buggy (it helps that C#/Java help to prevent the most common crasher bugs), and/or looks better visually than if you had written the same program in a lower-level language like C.

Comparing to C++ can be a different story due to the fantastic class libraries (and smart pointers) that C++ has available these days via Boost/Qt which alleviate many of the problems that the GNOME developers seem to face (and why I suspect a number of them have been attracted to C#).

DiBosco/dinotrac: ouch, I guess I'm lucky that I've never worked for a management type that came down from on-high and told me what language to use.
jdixon

Feb 17, 2010
9:54 PM EST
> It really was a stupid comment for a developer to make on several counts.

I didn't disagree with the developer comment, Dino. Only the non-developer comment. Not that I couldn't have, but I didn't.

And yes, produce quickly and don't worry about code quality is ubiquitous in the field, not just with Microsoft developer tools. Microsoft is the primary offender at selling it as a feature though, at least in my experience.

> Where I think the problem lies often is that it's not the developer who makes this decision, but the manager of the team who doesn't give a **** what the end user experiences, it's more important how fast a program is released.

Absolutely. You'll notice that Microsoft doesn't aim their sales pitches at the code monkeys.

> ...my personal feeling is that C# is a bit of an improvement over Java...

From a technical perspective, you are undoubtedly correct. Microsoft had years of Java development to look over and pick out what worked versus what didn't. However, Sun made a serious effort to ensure that Java actually was write once run anywhere. While they weren't completely successful, Java has a far broader reach than C#. Microsoft has never been overly concerned with cross platform development.

> ...uses less memory...

Counting the ancillary code needed (interpreter or runtime compiler)? Doubtful. If you're counting only the program itself, then yes, it should be possible. It doesn't seem to be the usual case, but it's possible.

> I guess I'm lucky that I've never worked for a management type that came down from on-high and told me what language to use.

Yes, you are. Being told what tools to use is a fact of life for most workers. :(
gus3

Feb 17, 2010
10:30 PM EST
Quoting:Being told what tools to use is a fact of life for most workers. :(
If one needs to challenge management's orders, one needs an alternative, or at least a supplementary suggestion.

CluelessMgr: "Have we analyzed this with gprof yet?"

Me: "Not yet, and we could, but the compile-time instrumentation isn't what the customers will get. May I suggest we also give OProfile a spin on it? At least the user-space code paths will be more in line with the retail product."

CluelessMgr: "It probably couldn't hurt..."

The above conversation is fictional, but I've had more conversations like it than my bosses care to admit.

I've also had a couple of them fire me for calling out their ignorance, on hardcopy. I was vindicated both times, and the CluelessMgrs were no longer managers shortly after. Both orgs bordered on deranged. Neither org exists today as a separate business entity.

Bitter? No, not me. Just smug with schadenfreude.
DiBosco

Feb 18, 2010
3:43 AM EST
Quoting:Yes, you are. Being told what tools to use is a fact of life for most workers. :(


Yep, which is, in all seriousness, one of the big reasons for the decision I made to set up on my own. People come to me to design electronics and write embedded code and I tell them how I'm going to do it with no interference! If they are wanting me to use tools I don't like I politely decline their offer.

I have had similar experiences to gus and it got to the stage where I'd had enough of it!
KernelShepard

Feb 18, 2010
10:00 AM EST
tuxchick:

> I'd be interested in a citation for that 600,000 download figure. It seems rather unrealistic, since virtually no Web sites support Silverlight/Moonlight.

Your wish has been granted ;-)

http://tirania.org/blog/archive/2010/Feb-17.html

Quoting:By the first week of Feburary there had been 610,000 downloads of Moonlight 2.0 for Linux. This is only counting the downloads since the official release on December.
krisum

Feb 18, 2010
11:16 PM EST
@jdixon

> What's silly about it? Most of the comment was a pointless rant about Mono we have seen from Carla n'th time in these forums. It is silly because it was just designed to raise tempers with nothing to back it up. And it was silly because of a non-developer commenting on lazy programmers when little is expected to be known from her about such.

@DiBosco

> if they use the wrong toolkit, his or her code will be slow and bloaty for the end user 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.

So for all those programmers here who claim that Java or C# is slow and bloated, here is a "simple" exercise:

Let's try and test a simple standalone utility to insert and search for a large number of key/value pairs in a hash map using multiple threads to get best performance on a multi-core/CPU machine as is the norm today. Let's do it in Java and then in C/C++. So for java, the code goes pretty straightforward:

// use a ConcurrentHashMap to store keys and values // create multiple threads to read the keys, values from a file or just some fixed set of keys/values and load the map; lets say 10 million entries or even 100 million depending on the memory available on your machine // use multiple threads to search from the map with each thread servicing a different set of keys possibly with overlaps // time the above steps; add a few warmup runs that are not timed of say 100 inserts/searches to prime the hash map and java JIT in general

For C/C++, we are a little stuck for the choice of data structure. Maybe gcc's or STLPort's hash_map but that's not designed for concurrent access -- in addition gcc's one will not work on other UNIX platforms like Solaris so maybe stick with STLPort.Or probably go to something like ACE that will provide a good hash map and threading constructs, but again its not designed for concurrent access. If lucky maybe we can find something ready made on the net with acceptable license. But we are not lazy after all and will like to roll our own that is optimized to get the best performance. So let's start with a segmented hash map with hand-rolled assembly code for spin-locks on each segment so that each segment can be worked on concurrently. Something like:

// make a segmented hash map out of ACE or gcc's/STLPort's hash_map // add a spin-lock implementation in assembly that will lock each segment to get optimized behaviour; the spin will be after some processor no-op's so that multiple threads do not eat out the CPU unnecessarily // repeat the steps as for java (excluding the ConcurrentHashMap step of course)

If you complete this successfully then you will be surprised by the results. Then some may realize that the design of a general concurrent hash map above has one flaw: for most key/values we need to make copies before loading into the map since loading pointers will leave the map with no control over how/when data is freed. So we should be able to get more performance using a good smart pointer implementation. So maybe we will go over to boost for a good smart pointer implementation, and tune it with hand-rolled assembly code for thread-safe atomic integer operations for reference counting. Then we need to add COW for strings to get proper behaviour or maybe continue to use std::string which might have that already (STLPort's one does not due to problems with the design) but then it will not utilize our optimized hand-rolled atomic reference counting. After tuning everything and running the tests again we might reach the same performance as java's one or if we are very smart then even exceed it. So to really show the real performance of C/C++ maybe go towards a wait-free design for concurrent hash map -- then we will approach java's ConcurrentHashMap design.

Or, maybe start with something really simple: create and remove a large number of smart pointers in C++ and compare with java. You will struggle to beat java even here. And then need to think of memory fragmentation which is a big issue with large data, not a problem with Java. Java has its infamous GC pause issue though.

If you want I can send code for most of above already complete and you can try and optimize it to heart's content. Hint: I have done the above exercise long time back and was surprised by the results, and that was just the beginning ...

edit: The point above is not that java is better than C/C++. In my opinion, C++ is a much more powerful language which can do anything that can be done in java and better but not vice-versa. But one size does not fit all, and there are plenty of scenarios where it just makes more sense to use something like java to optimize development in every way. In particular, java is a very good fit for something like server side backend programming.
DiBosco

Feb 19, 2010
5:09 AM EST
krisum, it seems like an academic argument and it doesn't really matter, to me anyhow, whether your example comes out with surprisingly good results. All I need is my real world experience of terrible programs that are based on .NET and Mono that are universally slow and.or bloaty. In most cases it's both. You have "little clue" of what I have experienced. You can argue 'til you're blue in the face about hash tables, but when I run the programs using these platforms they are slow and that's what matters to me as an end user.

bigg

Feb 19, 2010
7:11 AM EST
@krisum

Thanks for your presence. It's good that we mere mortals have you around to teach us.
dinotrac

Feb 19, 2010
7:48 AM EST
DiBosco --

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.



jdixon

Feb 19, 2010
8:04 AM EST
> It is silly because it was just designed to raise tempers with nothing to back it up.

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?
krisum

Feb 20, 2010
1:28 PM EST
@DiBosco > krisum, it seems like an academic argument and it doesn't really matter, to me anyhow, whether your example comes out with surprisingly good results

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.
jdixon

Feb 20, 2010
3:18 PM EST
> ...so what have you provided to show that developers who choose languages like C# for programming are lazy, incompetent

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.
DiBosco

Feb 20, 2010
3:52 PM EST
krisum, if anyone is missing the point, it's you. You're talking about saved time. Saved time for the developer. I'm not talking about it from the developer's point of view, but the user's. Save a little time for a handful of developers, waste a whole heap of time for a massive amount of users. Nice one!

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.

krisum

Feb 20, 2010
4:02 PM EST
> 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.

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?
krisum

Feb 20, 2010
4:12 PM EST
@DiBosco

> .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.
jdixon

Feb 20, 2010
5:13 PM EST
> I expect a generalization to be claimed as being true for nearly all cases.

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.
DiBosco

Feb 20, 2010
5:32 PM EST
krisum, I suspect the point with languages like Python and Ruby are is they are used for different types apps to Mono and .NET. I guess people wouldn't use Python to make IDEs for writing code or photo editors, but they would (and sadly do) with .NET, Mono and Java.

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!
krisum

Feb 21, 2010
6:27 AM EST
@jdixon

> 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.
bigg

Feb 21, 2010
6:55 AM EST
@krisum

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..."
dinotrac

Feb 21, 2010
7:16 AM EST
bigg --

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.
gus3

Feb 21, 2010
8:26 AM EST
Number-crunching, eh?

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.
DiBosco

Feb 21, 2010
9:54 AM EST
krisum, my experience gives me vastly different experience to yours. 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.
jdixon

Feb 21, 2010
11:18 AM EST
> Where does Carla say that it is meant to apply only for majority of cases?

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.
krisum

Feb 21, 2010
2:06 PM EST
@bigg

> 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.
gus3

Feb 21, 2010
3:18 PM EST
(Deleted; no longer applicable.)
mortenalver

Feb 22, 2010
3:16 AM EST
This discussion is stupid. Krisum is right that Java can show very good performance in certain situations. The others are right that it often doesn't. For many applications performance is not really important. There are also lots of non-Java applications that are slow.
bigg

Feb 22, 2010
7:11 AM EST
> 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.

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.
DiBosco

Feb 26, 2010
6:29 AM EST
This made me grin and recall this thread. On the Qt mailing list someone just posted this about Qt in response to a .NET claim:

"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."

Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]

Becoming a member of LXer is easy and free. Join Us!