The latest release of the GNOME Journal is available. This edition includes stories on Google’s Summer of Code, GOCollab, the Banshee music player, and more.
The latest release of the GNOME Journal is available. This edition includes stories on Google’s Summer of Code, GOCollab, the Banshee music player, and more.
Banshee, sounds like yet another good looking mono-app out there. I never really liked the concept of mono but i suppose i will have to deal with it sooner or later. Hopefully the fear of legal problems will never materialise.
/Raskolnikov
> the fear of legal problems
do you really believe that Microsft will sue you because you are using Banshee?
what matter with you poeple? is that kind of “psycho”?
stop reading trolls
in other hand… I don’t understand why red hat pushing gcj instead of some cli to native binary compiler
because there is far more resources available for the open java developer then the mono developer. both in the official api, and in terms of libraries. the majority of cool stuff (like the lucerne search engine that beagle uses) are ports from java projects.
why would redhat push mono? the reason novell does is because its their baby, not for practical reasons.
That’s really not the fear people have. The fear people have is that a lot of effort will be expended building GNOME on top of Mono, and then Microsoft will come and say “Mono violates these patents, and will have to shut down.” Building up a platform, then being forced to ditch it, is well, painful.
Now, the possibility of that happening is debatable. One one hand, C# is an ECMA standard, so Mono is safe there, on the other hand, there are patents on .NET, and Mono doesn’t implement just C#, but large parts of the .NET framework. Certainly, it wouldn’t be an unprecedented move (*cough* SCO). Linux users are particularly sensitive to license and patent issues, with good reason. The only reason Linux is as popular as it is today was because FreeBSD was held up for years in a license dispute with AT&T. It was years before Linux users could legally view their own DVDs on their Linux computer. Patent issues arose with GIF and MP3 that turned out to be quite painful. So being afraid of possible patent litigation isn’t paranoia, its prudence.
Microsoft doesn’t typically use patents offensively. I’m actually not certain why, because let’s be honest, they certainly engage in every other strong-arm tactic they can in order to maintain their market position. So if we’re looking strictly at Microsoft’s behavior to predict Microsoft’s future behavior, then it does not seem likely that Microsoft will bother suing Mono out of existence. If I had to guess, I’d say that they would probably rely on marketing to depict Mono as a second-tier “freeware” implementation of Mono, that no sane business would rely upon for their critical web services. Since Mono has had little interest in any serious SWF implementation, and because dotGNU is seriously labor-starved, basically all (what little there is, really) desktop programs aren’t really portable. Mono validates the CLR as a portable runtime to compete with Java, while Microsoft can with the other hand make it seem like the product of a bunch of part-time basement dwellers.
There are a lot of reasons not to bother building GNOME on top of Mono. The fear of Microsoft suddenly changing its mind is one of them, I suppose. Personally I just don’t see much technical reason to use it to begin with.
“of Mono” should read “of .NET”
Er what legal issues?
If you like mono or dont mind the huge footprint of mono and have a modern system with plenty of RAM then by all means have fun with mono cause no one has a right to tell you you cant use or develop in it.
Isn’t the huge footprint associated with mono also a myth?
I dont think it’s a myth… Look right next to the title, “GNOME Journal”. All I see is a huge footprint!
All this time has passed since Monos became useful and even more since the Mono Project began. With one big exception Microsoft always said (nonofficial of course) that they don’t care one way or the other. The one big exception was when they wanted money from Novel for trying to support a project wanting to implement Indigo (if I remember correctly).
If you ask me, people have been pissing their pants for nothing all these years. RedHat insists that there is a problem and they can’t ship Mono or anything build on it. OK, so they cant other apparently can so the problems might be RedHat specific, nobody knows since they apparently can’t tell us about it.
Besides all that, netdur is correct in saying that any potential threat is not towards end-users. So if you want to use Mono-apps as end-user just do it. They will be around for some time to come; no developer is switching back off of Mono.
ECMA doesnt mean that they are unable to charge a reasonable royalty for their product. all it would take is to charge 0.0001$ to invalidate it under the gpl. all miguel has to answer this is is a non official email from a mono dev on a mailing list.
it would be borderline retarded for ms to do this now. public-relations wise it would be a disaster, and gnome is FAR from being a threat to them at this point. but ms has explicitly said they will use their patents as their weapon against open source.
but what if gnome becomes popular? and our favorite dm is riddled with code that microsoft can make illegal at any time they choose? redhat not using mono isnt too hard to understand. novell using it for so much is.
from a technology point of view, mono is sorely needed. there is an extremely high barrier to entry for gnome apps, C isnt exactly a popular language amoung the young developers nowadays, and managed languages are definately the way of the future. mono as a platform is quite nice, not quite as complete as java, but definately goes head to head with open java efforts such as classpath. having novell 100% behind it means it has gained quite the momentum, and we’re finally seeing gnome apps developed at the speed that comes from using a modern language.
do some reading, seth explained this quite clearly. there isnt a threat to the end user, but there is a threat to the dm if it allows mono code in core apps.
i dont think anyone has a problem with third partys using mono/gtk# as a platform.
You sort of make my point for me, If there are some possible repercussions (not for the end-user) that could possible make things difficult if 3 other conditions that are unlikely to happen in the near future and so on and so forth. There is no good reason for an end-user not to install a Mono app now. Lets see if Gnome gets so popular that Microsoft feels threatened, I don’t think that’s going to happen for a long long time.
yes, but there are reasons beyond the political, not to use it (as a developer). miguel does his best to pass off any and all opposition to mono (including core gnome apps) as zealotous and not worth paying attention to. it is that kind of attitude that prompted the last post.
to be clear, there is no real reason not to use mono apps, as long as you realise that down the line they may disappear. theres no real reason not to develop mono apps, other then that you may have quite the porting job on your hands somewhere in the far future.
at this point in time, a gnome user who totally refuses to use mono apps is going to be missing out on some of the coolest things happening on the platform.
“from a technology point of view, mono is sorely needed. there is an extremely high barrier to entry for gnome apps, C isnt exactly a popular language amoung the young developers nowadays, and managed languages are definately the way of the future. mono as a platform is quite nice, not quite as complete as java, but definately goes head to head with open java efforts such as classpath. having novell 100% behind it means it has gained quite the momentum, and we’re finally seeing gnome apps developed at the speed that comes from using a modern language.”
What’s strange is that Python is nowhere to be found in this comment. Python is an open source language, with the most up to data and modern of all the GTK bindings. Python applications can be written even quicker than corresponding C# ones. Python’s best features correspond very well with concepts out of computer science, and so comp. sci. students find it a natural choice. Python already has a whole slew of libraries that provide additional functionality, while only recently are these libraries getting ported to “.NET” or Mono.
And, more important than anything else perhaps, Python is cross-platform _now_ (not tomorrow, not in three years), with full implementations on Windows, Mac and Linux, and even other more alternative OSes.
Mono’s situation is much more complicated, I believe. Yes, Mono may be cross platform, but Microsoft’s .NET implementation already exists and is the reference implementation on Windows. So no matter what, we’re starting with two competing runtimes despite it being one runtime system.
You know what I think? That Python got left out in this whole shuffle because open source hackers are really stubborn to part ways with their braces and semicolons. I was a C hacker and became a Python convert, and I can see the sentiment, but they really need to get over it and use what works.
dont get me wrong, python rocks in a serious way. the more i use it, the more it is becomming my language of choice, especially for gnome apps. but you cant compare python to java, .net, or cpp. all three are geared towards larger app development, python is kinda like a structured perl that scales up significantly further. i wouldnt want to, for example, write an office suite in python. just as i wouldnt want to write a panel applet in java.
The scalability argument is bogus. Python scales up better than Java or C#. It has the same scalability features (namely, modules and classes), but isn’t hampered by a ridiculously overbearing type system that makes a magical refactoring editor almost mandatory for routine code maintainance…
Static typing is one of Java or C#’s “scalability features.” The strict declaration of members and methods is also a “scalability feature.” The JIT compilation used by the VMs is probably a “scalability feature.” It’s also possible that the relative stagnation of Java the language is a “scalability feature,” since it’s yet to introduce a new type of class.
What you consider “overbearing” others consider “scalability features.”
Also refactoring is part of any codebase maintenance. If you have tools that make it easier for you, all the better. This is as true in Python world as it was in the Smalltalk world, and then later the Java world.
1) Static typing is a “scalability feature” is a crutch that the people behind C# and Java tell you you need because they assume you need to be protected from yourself.
2) How is JIT compilation a “scalability feature”, and why doesn’t Python’s interpreter qualify? We’re talking about codebase-size scalability here, not performance scalability.
3) Yes, refactoring is part of codebase maintainence. That’s why a typesystem that makes refactoring a pain in the ass and requires a tool to do it for you is fundamentally broken.
The C#/Java folks have this mantra: “Redundant boiler-plate code is good for scalability. Design patterns, which require redundant boiler-plate code is good for scalability. Making it difficult to quickly develop code is good for scalability.” It’s all bullshit. Scalability comes from three things: small code, clean code, and elegant code. Java/C# fail on all three counts. Their reliance on baroque class hierarchies and “design patterns” (read: boiler-plate code) means that you need far more lines of Java/C# than Python to do the same thing. Their typesystems make refactoring a pain, which means that the programmer is far less likely to clean up ugly but working code. Their lack of powerful features leads to the proverbial guy with only a hammer: all problems must be solved the same way, because the programmer is given so few tools to work with. Instead of being able to build proper abstractions, which lead to elegant code, you’re forced to build up baroque class hierarchies, because that’s the only tool they give you.
Static typing catches various type errors. It’s not a “crutch” to “protect you from yourself.” Down with garbage collection! It’s a crutch that protects me from myself!
The JIT compilation of the VMs with Java and C# are “scalability features” in that performance-critical code doesn’t need to be kicked to a C extensions.
Static typing doesn’t make refactoring a pain in the ass. There are aspects to ad-hoc type systems like C# and Java that make the languages obnoxious, but that rater orthogonal to whether they’re scalable. Various design choices in code bases can certainly make refactoring annoying.
Further, design patterns have nothing to do with Java or C#. I don’t know where you got that idea.
Scalability comes from the ability to manage complexity and preserve correctness. Java, despite being a rather unimpressive language, manages that quite competently on projects orders of magnitude more complicated than anything you’ve worked on as a student. Threading monads through a small, very clean, very elegant codebase of one of my favorite languages on the other hand can be a monotonous pain in the ass.
Static typing catches various type errors. It’s not a “crutch” to “protect you from yourself.” Down with garbage collection! It’s a crutch that protects me from myself!
Don’t even try to compare garbage collection to static typing. They are clearly two different things and shows that you’re having a hard time coming up with an argument.
The big myth that everybody is running into type errors is quickly being dismantled because people are realizing that it just doesn’t happen that much. The only real use I see for static type checking is code completion and maybe some performance benefits. There are lots of drawbacks to static typing in languages like C# and Java though, mostly related to inflexibility. Inheritance isn’t all that it’s cracked up to be and things like duck-typing solve part of that problem.
The JIT compilation of the VMs with Java and C# are “scalability features” in that performance-critical code doesn’t need to be kicked to a C extensions.
Ruby will get a VM in 2.0
Further, design patterns have nothing to do with Java or C#. I don’t know where you got that idea.
Yeah, but some languages don’t need a visitor pattern because they have things like multi-methods built in.
Java, despite being a rather unimpressive language, manages that quite competently on projects orders of magnitude more complicated than anything you’ve worked on as a student
Not buying that whatsoever. Just look at the J2EE and other framework messes coming from Java. Part of the problem is the inflexibility of a language like Java. Part of the reason of why Ruby on Rails is the ruby language itself and the ability to make a DSL.
> Don’t even try to compare garbage collection to
> static typing. They are clearly two different things
> and shows that you’re having a hard time coming up
> with an argument.
No, static typing and garbage collection are clearly identical. In some alternate universe.
> The big myth that everybody is running into type
> errors is quickly being dismantled
No it isn’t. What proof-carrying code research is being conducted in your universe?
> The only real use I see for static type checking is
> code completion and maybe some performance benefits
The only good use for static typing is correctness. Performance is a secondary concern.
> Ruby will get a VM in 2.0
You’re thoroughly confused. I specifically referred to the JIT compilation; Python already has a virtual machine. It even has Psyco, but it’s not portable.
> Yeah, but some languages don’t need a visitor pattern
> because they have things like multi-methods built in.
Would you care to respond to any of my other comments with completely irrelevant commentary?
> Not buying that whatsoever.
You don’t have to buy anything. There are absolutely massive codebases written in Java, and if you don’t want to buy it then that’s between you and your deity.
> Part of the reason of why Ruby on Rails is the ruby
> language itself and the ability to make a DSL.
Ruby is a pretty mediocre platform for developing domain-specific languages. Common Lisp, ML, Haskell. Those are excellent platforms for constructing DSLs, but that’s hardly the matter of discussion. Personally I hate Java. That doesn’t detract one bit from the “scalability features” it has that people want and use it for. You can tell someone that wants static typing that they don’t want static typing until fire falls from the sky; they want static typing. It helps them write their software. Deal with it.
No, static typing and garbage collection are clearly identical. In some alternate universe.
Analogies aren’t your strong suit, because trying to insinuate that GC isn’t a crutch therefore static isn’t either failed.
No it isn’t. What proof-carrying code research is being conducted in your universe?
Where’s the proof that static typing (as in C#/Java) helps more than it hurts? All I see is a bunch of hand-waving java sycophants trying to justify their massive source bloat. You better check out what Bruce Eckel (a known java expert) has to say about dynamic typing vs static typing.
You’re thoroughly confused. I specifically referred to the JIT compilation; Python already has a virtual machine. It even has Psyco, but it’s not portable.
YARV http://www.atdot.net/yarv/RubyConf2004_YARV_pub.pdf will have a JIT and a AOT. But I thought you would be able to figure out that it wasn’t going to be just another intrepreter.
Would you care to respond to any of my other comments with completely irrelevant commentary?
What’s irrelevant are some of these design patterns (that you brought up) in languages that don’t need them, e.g multimethods that eliminate a Visitor pattern
You don’t have to buy anything. There are absolutely massive codebases written in Java, and if you don’t want to buy it then that’s between you and your deity.
Haha, massive is the keyword. There’s never been a bigger clusterfuck of massive, bloated, useless frameworks revolving around a language more than Java. But that’s not surprising coming from a dumbed down language like Java.
That doesn’t detract one bit from the “scalability features” it has that people want and use it for.
Hilarious – just more handwaving and shouting of buzzwords like scalability with absolutely no meaning. Are you in marketing by chance?
You can tell someone that wants static typing that they don’t want static typing until fire falls from the sky;
I could care less if someone wants static typing. I’m saying that the benefits of it are severly overblown as regular programmers in the field have already figured out….well at least those that don’t need Eclipse or IDEA to do their work
The only good use for static typing is correctness. Performance is a secondary concern.
Correctness? If you’re relying on static typing for correctness then you need to get out of the programming profession.
> Analogies aren’t your strong suit, because trying to
> insinuate that GC isn’t a crutch therefore static isn’t
> either failed.
Logic…is…not…hard…honest.
1. That which protects you from yourself is an unnecessary crutch
2. Static typing protects you from yourself
3. Therefore static checking is an unnecessary crutch
1. That which protects you from yourself is an unnecessary crutch
2. Garbage collection protect you from yourself
3. Therefore garbage collection is an unnecessary crutch
Which of course to you implies equality (garbage collection is the same as static typing)
> Where’s the proof that static typing (as in C#/Java)
> helps more than it hurts?
Despite that logically flows from our conversation like brick, I can’t help but say that I neither have nor particularly care to have such proof. It’s the subject of much mediocre discussion on the Internet. However interestingly enough, I am interested in what methodology you propose for determining it. You’re obviously not accepting self-selection, or even presuming that the people that want and use static type checking select so because it makes them more productive.
So let’s see 1. a proposal 2. proof of the contrary
> All I see is a bunch of hand-waving java sycophants
> trying to justify their massive source bloat.
That’s funny, because I hate Java. I guess you must be referring to someone else.
> You better check out what Bruce Eckel (a known java
> expert) has to say about dynamic typing vs static
> typing.
Nice logical fallacy, sport-o. I’m a regular on LtU, do you think perhaps I’m familiar?
> http://www.atdot.net/yarv/RubyConf2004_YARV_pub.pdf
> will have a JIT and a AOT. But I thought you would be
> able to figure out that it wasn’t going to be just
> another intrepreter.
Using my psychic powers, I shall determine that your seemingly irrelevant aside (Ruby is Python? Really?) has any bearing to what I’ve said.
> Haha, massive is the keyword. There’s never been a
> bigger clusterfuck of massive, bloated, useless
> frameworks revolving around a language more than
> Java.
Yeah massive was the keyword.
> I could care less if someone wants static typing. I’m
> saying that the benefits of it are severly overblown
> as regular programmers in the field have already
> figured out….well at least those that don’t need
> Eclipse or IDEA to do their work
Regular programmers? Statically typed languages are the norm for “regular programmers.”
> Correctness? If you’re relying on static typing for
> correctness then you need to get out of the
> programming profession.
Maybe you should have studied CS before becoming a web monkey. Yes, static typing of course constructs correct software. That’s precisely it. Much like structured programming provided perfectly-correct software for all, and what all software is perfect.
1. That which protects you from yourself is an unnecessary crutch
2. Static typing protects you from yourself
3. Therefore static checking is an unnecessary crutch
1. That which protects you from yourself is an unnecessary crutch
2. Garbage collection protect you from yourself
3. Therefore garbage collection is an unnecessary crutch
Which of course to you implies equality (garbage collection is the same as static typing)
Do you have a concentration problem? You are the one equating GC to static typing. I pointed out that it’s insane to compare the two. In a rational manner, please explain to me the GC/static typing comparison. If it’s something about a crutch then just give up.
Despite that logically flows from our conversation like brick, I can’t help but say that I neither have nor particularly care to have such proof.
If you can’t back up what you claim then you’ve lost the argument.
I am interested in what methodology you propose for determining it. You’re obviously not accepting self-selection, or even presuming that the people that want and use static type checking select so because it makes them more productive.
So let’s see 1. a proposal 2. proof of the contrary
You claimed that static typing was saving programmers from all sorts of headaches. It’s up to you to back up your assertions. As far as productivity, obviously millions of programmers use Python and Ruby because it is more productive because they sure aren’t runtime speed demons.
That’s funny, because I hate Java. I guess you must be referring to someone else.
I wasn’t referring to you
Using my psychic powers, I shall determine that your seemingly irrelevant aside (Ruby is Python? Really?) has any bearing to what I’ve said.
Maybe you forgot that you were talking about the “scalability” of a language like Java because it has a JIT. That’s a joke
Regular programmers? Statically typed languages are the norm for “regular programmers.”
I never claimed it wasn’t. I’m saying that the myth that static type checking is saving programmers from disaster is going away – well, except for Java programmers who need all the help they can get in defending their language.
Nice logical fallacy, sport-o. I’m a regular on LtU, do you think perhaps I’m familiar?
Haha, that explains a lot. You lurk on LtU and now you consider yourself an expert.
Maybe you should have studied CS before becoming a web monkey
Hah, I wish I was a web monkey doing something fun like RoR instead of bit-twiddling in C++ for too many years.
Yes, static typing of course constructs correct software.
Your sarcasm is so weak I almost missed it. But you are the one that needs static type checking as a crutch.
> Do you have a concentration problem? You are the one
> equating GC to static typing.
Your reading comprehension is not impressing me. The argument is retarded. Do you get it now? The first premise is stupid. Get it?
Please demonstrate where garbage collection is equated to static typing.
> If you can’t back up what you claim then you’ve lost
> the argument.
What have I claimed that is contrary to what is prima facie true? Static typing results permit mechanically-verified type checking which checks type errors. Java’s static typing provides type safety that its users find valuable. Am I missing something?
Now please prove your assertion:
The big myth that everybody is running into type errors is quickly being dismantled because people are realizing that it just doesn’t happen that much.
And further provide your proposal for demonstrating your previous query.
> You claimed that static typing was saving programmers
> from all sorts of headaches.
Really? You’ll be sure to show that, right?
> Maybe you forgot that you were talking about the
> “scalability” of a language like Java because it has
> a JIT.
Maybe you forgot that I was talking about Python and Java. Reading isn’t exactly your forte.
> I never claimed it wasn’t. I’m saying that the myth
> that static type checking is saving programmers from
> disaster is going away
You’ve stated that regular programmers have seen that static typing is “overblown” (without evidence) only to cede that they continue to use statically-typed languages (rather than dynamically typed ones). Ok.
> Haha, that explains a lot. You lurk on LtU and now
> you consider yourself an expert.
You’re not very good at logic, are you? I’ve read Bruce Eckel’s babble because it was discussed there. Which incidentally makes me an expert one what, exactly? Who knows? All the while you attempt to appeal to an authority that isn’t. Excellent work.
> Your sarcasm is so weak I almost missed it. But you
> are the one that needs static type checking as a
> crutch.
Let me know when you learn how to read. It’s a useful skill, which will result in fewer embarrassing displays of assumption.
Your reading comprehension is not impressing me. The argument is retarded. Do you get it now? The first premise is stupid. Get it?
Please demonstrate where garbage collection is equated to static typing.
Are you trying to weasel out of what you originally posted. Just in case you are, here’s what you wrote:
“Static typing catches various type errors. It’s not a “crutch” to “protect you from yourself.” Down with garbage collection! It’s a crutch that protects me from myself!”
So unless you have some bizarro-world sense of sarcasm, you were clearly trying to say if you consider static-typing a crutch then you must also consider GC a crutch.
What have I claimed that is contrary to what is prima facie true? Static typing results permit mechanically-verified type checking which checks type errors. Java’s static typing provides type safety that its users find valuable. Am I missing something?
Yes, Java programmers have mechanically-verified type checking….sort of (it doesn’t save them from type errors since there’s a lot of casting from object going on anyway. knowing that java is huge in the corporate, server world it’s probably (a) management that thinks static type checking is going to help them and (b) the programmer probably appreciates the fancy, schmancy “intellisense” features that static typing provides rather than some sense of “safety”.
The big myth that everybody is running into type errors is quickly being dismantled because people are realizing that it just doesn’t happen that much.
And further provide your proposal for demonstrating your previous query.
Let’s go back to the tape Jim:
“The only good use for static typing is correctness. Performance is a secondary concern. ”
Correctness? A compiler catching a type error (which might only be a type error in something like Java) has very little to do with a program being “correct”
Maybe you forgot that I was talking about Python and Java. Reading isn’t exactly your forte.
And maybe you forget that having a JIT/VM has nothing to do with “scalability” as you put it. You’re confusing scalability with performance.
You’ve stated that regular programmers have seen that static typing is “overblown” (without evidence) only to cede that they continue to use statically-typed languages (rather than dynamically typed ones). Ok.
Bruce Eckel and others that have since moved on to “scripting” language, aren’t buying the static-typing equal “correctness” bullshit. I didn’t cede shit. You’ll have to cede that dynamic languages like Python and Ruby have many advantages over Java.
You’re not very good at logic, are you? I’ve read Bruce Eckel’s babble because it was discussed there. Which incidentally makes me an expert one what, exactly? Who knows? All the while you attempt to appeal to an authority that isn’t. Excellent work.
Now this is hilarious. Bruce Eckel is now working on his 4th edition of his “Thinking in Java” books, IS considered an expert on Java, and has basically stated that he’s sick of the crap in the Java world and would rather program in Python any day – as have countless other programmers that don’t need the static typing crutch, and would rather just get things done rather than hand wave about some false “correctness”.
Seriously, go google up his talk at Berkley where he just trashes Java 5. For all this talk of type “correctness” Sun didn’t even bother preserve types in their version of generics
But yeah, you calling Eckel’s talks babble is so telling? Who are you again? What books have you written? How much are you getting paid to consult on various programming topics? Yeah, I thought so
I’m not claiming that Eckel has all the answers, but clearly he’s been around the Java world long enough to know that a lot of this type-safety hype is a bunch of bullshit.
I wonder how many java programmers that oh-so value static typing (as you put it) wouldn’t be blowing their brains out if they were forced to program Java in something like Vi instead of something like IDEA or Eclipse.
Rayiner is exactly correct when he states that all the boiler-plate code and various support classes that have to be written, as well as unatural class hierarchies nullify any advantages that java static typing gives you.
Once again, just look at the clusterfuck that J2EE and all the other umpteem frameworks in the java world.
Static typing catches various type errors. It’s not a “crutch” to “protect you from yourself.”
In a language like Java/C#, static typing catches obvious type errors. It cannot, for example, statically catch type errors arising from an object of the wrong type being in a hetrogenous container. The question, however, is whether catching obvious type errors is worth the very significant overhead C#/Java-style static typing entails. Let’s consider both parts of that statement:
1) I’d argue that C#/Java do not catch many useful type errors. Consider the case of a homogenous container. C#/Java will prevent you from inserting a Bar into a templated container containing Foo. Is that useful? In a properly-designed program, homogenaity of the container is a feature intrinsic to the container. The programmer knows the container is homogenous, not because its declared as such in the code, but because he knows what the container contains (presumably, as he’s inserting something into it), and it should be obvious whether those contents constitute a homogenous set. Similar arguments can be applied to things like the return type of a function, or the parameters of a function. In each of these cases, the programmer must know the semantic significance of an object (because he’s using it in some way), so it is not hard to believe that he’s also aware of the type of the object. In situations where type-checking would truely help, such as when dealing with hetrogenous containers, C#/Java are unable to provide any static checking!
2) I’d argue that static typing, as implemented in C#/Java do impose significant overhead, on multiple levels. At the most basic level, type declarations add more code, and bigger code is less maintainable code. At the next level, type declarations tend to require elaborate class hierarchies to deal with all the necessary contingencies. Class hierarchies tend to be overdesigned, because the pain of changing the hierarchy later is too great. Again, this works against code size, and I’d argue also makes type errors more likely in the first place! Look at your average C#/Java program. The class hierarchy is usually far more elaborate than it needs to be, and more importantly, so elaborate that it no longer naturally models the problem domain. Classes get added to the hierarchy not because they are a natural part of the problem space, but because they are necessary to satisfy the type system in some way. When your class hierarchy no longer corresponds to your problem domain, the programmer can no longer have an intuitive understanding of the types of the objects with which he is dealing. Static typing often catches the resulting errors, but without the overhead of static typing, they would not have been made in the first place.
Now, to be fair, both static and dynamic typing impose some overhead on the programmer. The question is, which brand of overhead is more bearable? With dynamic typing, the overhead is the necessity of being aware of the types of the objects. I’ve argued that since the types of objects (in a properly-designed system) should naturally correspond to the problem domain, whenever the programmer is using those objects, he’s generally already aware of their types. With static typing, the overhead is the necessity of significant extra code to satisfy the type-checker, along with the necessity of modifying all that code whenever you want to refactor. This latter overhead is very different in nature. This requires the programmer to step away from thinking about the problem space, to thinking about the code. The requisite cognitive shift is a much more intrusive and overbearing form of overhead than required for dynamic typing.
The JIT compilation of the VMs with Java and C# are “scalability features” in that performance-critical code doesn’t need to be kicked to a C extensions.
As I said, I’m talking about codebase scalability, not performance scalability.
Static typing doesn’t make refactoring a pain in the ass.
It does, for multiple reasons, at least as it is implemented in C#/Java. The most fundamental problem is that a type declaration is a contract, and C#/Java forces you to litter your code with contracts even when you don’t necessarily want to make a contract. As in real life, contracts are a pain to change, and in many (most?) cases, the safety gained through the contract is not worth the loss in malleability created by it. Lots of code doesn’t want to make a contract regarding types. Library code often doesn’t, prototype code doesn’t, vast swaths of “infrastructure” code doesn’t. Usually, only the logic portions of the program care about the types of objects, and use them enough to warrent the safety of contracts. Most other code must handle those objects, but generally don’t care about their types. The problem with static typing as implemented in C#/Java is that the extra code required to appease the type checker is necessary in even these components that don’t care about types, and this extra code has to be modified during refactoring, even though it makes no semantic difference to these pieces of code. That’s the whole reason “refactoring” plugins are so popular for C#/Java. They are a crutch to help the programmer propagate type changes to pieces of code that don’t care about types. It’s interesting to note that if this procedure wasn’t irrelevent busy work, there would be no way a plugin less powerful than an AI would be able to do it!
Further, design patterns have nothing to do with Java or C#.
Note I said “design patterns”, not design patterns. I’m referring not to best practices in general, but the fad of “design patterns” specifically. You know, the ‘interpreter’, ‘facade’, etc, bullshit. The very idea of having “patterns” in code works against the principle of having small code. A code pattern is nothing more than a signal saying “this should really be an abstraction, but my language is not expressive enough to create such an abstraction”.
As for the student bit, its irrelevant. It doesn’t take a Picasso to realize what is and is not art. Moreover, lots of projects likely larger than anything you’ve worked on have been implemented just fine in dynamic languages, and my experience with a fairly-large software project in the real world suggests to me that static typing isn’t nearly useful enough to carry its own weight.
Well I wrote a reply but it was too large for the forum. I could edit it, but that would take time I really should spend being productive, and I’m reluctant to post large crap messages here anyway for the sake of other users.
You can read the reply here:
http://japail.blogspot.com/2005/09/cjava-will-prevent-you-from-inse…
That only exists to provide a location to store such text while providing faux anonymity, so if you’d reply here that would be be excellent.
You’re basically arguing that the programmer should know, and therefore there’s no value, and therefore it serves no function.
No, I’m arguing that the programmer generally does know, and is therefore unlikely to make such a type-related error. If I call “getPurchasingOrders”, I’m unlikely to accidentally assign the result to a list of InsuranceClaim’s. It’s just the result of thinking in the problem domain.
You think that code with type annotations is inherently less maintainable? What is the basis for this?
Type annotations are code. Type annotations lead to larger class hierarchies, which is more code. Type annotations tend to prevent certain dynamic techniques, which necessitate still more code. Larger code is harder-to-maintain code.
Provide evidence.
Easy. Any “Listener” class, or “Vistor” class. Java/C# code is full of classes that have no counterparts in the problem domain. By the precepts of OOP, that’s bad design, but Java/C# necessitate such designs.
The average C#/Java program is rife with type errors? Please, show evidence.
Not at all, since the compiler tends to catch such errors. However, I would argue that your average Java/C# programmer tends to make more type errors (that must be caught by the compiler), because he must deal with baroque class hierarchies well-removed from the problem domain.
If they are explicit (static typing) various properties can be proven mechanically.
We’re arguing Java and C# here, not ML or Haskell.
With dynamic typing you have these contracts littered everywhere
On the contrary. It’s static typing that litters your code with contracts. Dynamic typing only creates dependencies where they naturally arise — when objects are being used. With a properly designed hierarchy, the very problem domain will make the type requirements of such dependencies obvious, and programmers will be unlikely to make errors regarding type. Meanwhile, with static typing, you’re forced to make a contract for something as simple as passing a parameter, or storing a datum to hand to some other component. Even if you don’t care about the type of the object, you’re forced to.
Having tools to assist refactoring is just plain smart; wasting time unnecessarily changing code by hand is stupid.
The very fact that refactoring requires changing lots of code by hand is stupid! In dynamically typed languages, if you change A, you only change whatever uses A. In statically typed languages, when you change A, you have to change not only anything that uses A, but anything that remotely deals with A. Even anything that simply passes A along to some other component.
For some reason I can’t help but feel you think that these tools are used for purely superfluous purposes.
The tools are limited to only mechanical changes, and all such mechanical changes are superfluous. Now, to be fair, refactoring in many dynamic languages does still require mechanical changes. Eg, changing the name of a function or changing to order of parameters. However, that’s a matter of limited power of expression in those languages (in this example, limited by the textual medium of code). It should be noted that some languages (eg: Simulink models) do not suffer from these specific flaws. For this specific example, I consider Simulink models to be superior to any textual language with regards to refactoring.
It isn’t irrelevant. You don’t have the experience necessary to comment about the usefulness of static typing to C#/Java programmers a priori.
One needs only one run-in with a hot stove to realize that it is a disagreeable experience. That said, I’m not a complete programming neophyte. Certainly, I’ve worked on more complex software in the real world than many C#/Java programmers whose code consists of connecting database A to processing backend B.
jobs consist of doing this work that they don’t know what they need to do it.
Very possibly, but honestly, how many C#/Java programmers have enough experience to know what they need and do not need? I have at least a decent amount of experience with both static and dynamically typed languages, while many C#/Java programmers were last exposed to dynamic typing when they were forced to learn Scheme in college. Further, its hardly a matter of just my own experience. I’ve met many people online who say “I started as a C++/Java programmer, now I use Python/Ruby/Lisp and love it!” I’ve met very few people who have made the opposite transition. I’ve seen many programmers rave about how much more productive they are in dynamically-typed languages — I’m merely trying to offer some theoretical reasons as to why that might be.
It helps them write large, complex systems.
Now this isn’t a supportable statement. You could say, “people are writing complex systems in statically typed languages”, but this does not suggest that it is static typing allowing for that complexity, and I could also counter that “many such complex systems are fragile and hard to maintain”. You accuse me of handwaving, but that’s all the hype behind C#/Java’s static typing is! I have yet to see conclusive studies supporting that claim, and certainly nothing that would lead me to doubt my emperical observations to the contrary.
The fact that statically typed software dominates the software industry should suggest to you that it’s useful-enough to carry its own weight.
Britney Spears dominates that music industry, and that should lead me to conclude… what?
It’s carrying an awful lot of weight. In the field of aeronautics (one of your favorites), it carries virtually all of the weight.
A great deal of engineering software is very poorly written (from a programmer’s perspective — engineers can’t tell bad software from a hole in the ground). Some mainstays are quite good (CATIA, for example), but the company-specific and problem-specific “codes” are often pretty horrible. Even venerated software like NEPP is pretty cranky, and don’t get me started on how crap-tastic MATLAB is (though, it is dynamically typed!) What exactly am I supposed to conclude from this? That the aerospace industry has used statically typed languages to good effect in creating a lot of crappy software?
What “concepts out of computer science” does Python correspond with?
What, the mainstream herd ignoring superior languages because they don’t have the required hype factor? Shocking!
I’m not surprised a Python developer feels that way. I always suspected Python was too good of a language to become popular in C#/Java circles. Although, I must give kudos to RedHat for using it in their GUI tools. At least somebody understand rapid GUI app development…
I’ve been using Python for close to nine years now, and I find the idea of proposing it as an alternative to Java or Mono for the base of GNOME to be absolutely ridiculous. Maybe that’s just because I find the idea of using Java or C# for the same silly on its own. It’s not in itself especially interoperable with other languages, and its performance-properties are not especially impressive either. Writing applications in it is an entirely different story.
It’s all bullshit. Nobody (except the nutcases) really is worried about any legal issues. It’s just that RedHat has their own agenda with GCJ and doesn’t want to give Novell any leverage if possible. At the end of the day it doesn’t really matter if Gnome officially ships Mono or not.
as i mentioned, seth gave very compelling reasons why to not ship mono with gnome. i would like to hear redhats gcj agenda. they are more in direct competition with sun then with microsoft, what would they gain in a political sense by promoting sun technology?
as was mentioned in seths blog, the problem isnt what happens at the end of the day, we are talking 5-10 years from now (and alot of “ifs”), when microsoft needs to start looking for a weapon to attack the platform. looking at microsofts history of “competition”, i dont think being hesitant about adopting their standards would make you a nutjob. but thats just me, and ive been called far worse before 😉
Are you even aware that Seth works for RedHat?
of course im aware he works for redhat. what difference does that make in what he is saying? i find it very clear, and have yet to see anyone, including miguel, fully address most of the issues he brought up. miguels response is typically that its zealotry, but he offers no compelling counter arguments. that leads me to believe he has none. like i said, redhats seeming “alligence” to sun technology doesnt make much sense as anything but on technical merits, sun being more of a direct competitor then microsoft in their core market. unless its just “not novell”, which while possible, i would consider much more improbable.
Seth is just spewing typical RedHat FUD. It’s the typical “I hate Microsoft, so it doesn’t matter what kind of interesting stuff they have going on”. That’s not to say that I think that Gnome should have mono as dependency.
The more interesting blog was Havoc’s or maybe it was Owen Taylor’s (I can’t find it right now – no search on his blog) where he goes on to say something to the effect, “there are issues that I know about, but I can’t discuss, and I also don’t know all the issues” in regards to Mono. It was quite bizarre….Ok, I found the link http://galaxy.osnews.com/email.php?blog_id=973
But what’s more interesting is that GnomeJava is basically dead while Mono has a somewhat vibrant development community around it. It seems that a lot of the people in the open source desktop ecosphere just don’t care for Java. And while RedHat toils away at the never-ending battle of catching up with Sun with GCJ/Classpath people just don’t care anymore. They’d rather just use the real thing. Personally, I think not requiring a runtime is a good thing, but that’s another story.
Basically, RedHat has lost and it doesn’t matter if Mon o is a part of Gnome or not because nobody cares about JavaGnome. Java isn’t part of Gnome either. Python is semi-officially I guess.
Well banshee certainly is a nice app (at least if you don’t hate mono
), but it lacks the ability to play streams and reading in large music collections takes ages. Even rhythmbox is faster and that can play streams too.
So for now I don’t see any reason to switch to banshee and it definately doesn’t rock the competiton.
“do you really believe that Microsft will sue you because you are using Banshee? ”
If mono infringes on patents, using the software is illegal and end users could be sued in the current legal framework
“in other hand… I don’t understand why red hat pushing gcj instead of some cli to native binary compiler”
GCJ is a native binary compiler. GIJ is the JVM. All Java programs in Fedora is compiled into native binaries using gcj bypassing the need of a JVM which adds unnecessary overheadmo
No software patents in Europe…
And besides, C# (and the other M$ languages) + the CIL bytecode format are all open ECMA standards. Implementing them in your own runtime shouldn’t be illegal in any way, Microsoft has actually somewhat encouraged it.
Furthermore, there currently exists no ECMA Java standard, the open source implementations of Java can’t even (legally) say they interpreting/compiling Java AFAIK.
yes they can. javas liscence says anyone can do a no strings attached implementation, but sun has the right to say its not java, and force them to stop using the name. this is in contrast to ecma, which allows companys to still retain ownership over the ip. if ms had made it an ANSI standard, that would be quite different. but you can have an ecma standard become gpl incompatible quite easily.
Mono doesn’t implement C#, though. It implements .NET. It’s merely based on C# — most of the functionality is outside of the ECMA standard.
seth explains all this far more eloquently then i ever could here
http://www.gnome.org/~seth/blog/mono
OK, so some people have a problem with mono. Others don’t. Lets not turn this discussion about Gnome Journal into a mono flame war – see previous threads for examples of mono discussion.
http://www.osnews.com/topic.php?icon=64
The Google Summer of Code has really brought about some interesting developments – I’m particularly interested in finding other people streaming music on my network. This sort of functionality is ideal in a desktop pc vs. media center in the living room situation. Nothing complicated to set up, just fire up the app and use it. Great work to all the students
“Lack of a robust music player is something that has been a serious deficency of the Linux Desktop”. The license issues are one thing, but the claims made in the article are weird. What void is filled here? Has the author of the article used anything else than XMMS? I was getting excited, but when I see stuff like “Here you can do a variety of things, including playback. Select a song and hit the play button” and so many overly obvious _requirements_ littered all over the article, I was really dissapointed. The iPod syncing seems quite nice (Even though an option for generic mass storage should be available), but… Tag editing? Replay gain? Musicbrainz? Audioscrobbler? Lyrics retrieval? Album covers? Uhm, no, none of that, but look at the fancy “About” dialog. Rhytmbox is not THAT different, at least not enough to claim Banshee is some kind of paradigm shift.
Actually it does do tag editing and is quite good at it. Granted, only simple stuff is doable but you can always use EasyTAG if you need fancier features.
Overall the app strikes a very nice balance between features and simplicity. Adding audioscrobbler would be nice, just give them some time, the app has been around for less than six months I think.
Considering the lack of progress on the rhythmbox side in the last year, I say this new player is great news indeed.
at this point, quodLibot/ex falsa seems to be well ahead of rhythmbox in everything except for simplicity. what im looking for and have yet to find, is a real itunes replacement (as a frontend to my ipod, ripper, and jukebox). rhythmbox has looked like its had the most potential for the last while… up until i read this article of course 😉 hopefully being left in the dust by virtually everyone else will be the kick in the pants rhythmbox needs for some of the features its lacking.
Too anyone else having problems with Google not finding what he is talking about: It is spelled “Quod Libet” and “Ex Falso”. http://www.sacredchao.net/quodlibet
Take your damn programming debates to the forum. They’re utterly and completely off-topic and destroying any possible discussion on the actual NEWS item here, which (remember?!) was the GNOME journal.
If admins can still mod posts down unilaterally, please mod the entire language debate to -5 so we can talk about the journal.
The language debate is entirely on-topic. The GNOME Journal article, in pointing out new Mono apps for GNOME, brings to mind a very fundamental issue facing GNOME: where does the platform go from here? I’m probably one of the few posters on this thread who use GNOME as their primary desktop. The wave of Mono applications coming out for GNOME makes this question quite an important one for me. The debate over static/dynamic typing, the merits of C# versus Java versus Python or Ruby are thus completely relevant. The direction the GNOME folks choose to go with this is ultimately going to shape what the GNOME desktop will look like, and what content will be in future GNOME Journal articles.
For people observing from the sidelines, I can see why this would seem less than critical. For concerned users, well, let’s just say that you have to see it from our perspective.
I’m disappointed about the discussion. The GNOME Journal was not just covering an interesting audio player that happens to be written in C#.
The importance of C# for GNOME is over-estimated: From over 1000 packages within and for the GNOME platform, just a tiny part is written in C#; probably less then 50 with maybe 20 end user apps. None of them is in the core desktop, and will probably never be.
Additionally, the technical merits of a language are completely irrelevant for its adoption in the market. The collaboration among its users (ie. application developers) and what they choose to develop is the important factor. This determines if there’s a cool app that is presented in a GNOME Journal article.
However, even if the GNOME Journal would have included an review about a C++ or a Python or a Perl application, nobody would have started a discussion about its technical and political pro’s and con’s. The last edition featured, for example, K-3D which happens to be written in C++ with GTKmm. Did you noticed any discussion about C++ becoming a major part of GNOME and if that’s important?
It would have been justified: In the last year, quite a few new applications appeared that use GTKmm; nearly as much as C# applications. But it started no discussion about C++ and its merits.
AdamW is thus correct: The discussion is off-topic! And, as noted above, irrelevant for a wider adoption of C# or any of the presented alternatives.
1. It is not illegal to use mono or to develop mono.
2. C#/.net libraries are ECMA standards
However,
1. Microsoft has the right to charge a RAND (reasonable and non-descriminatory) fee at any time for the use of these standards.
2. They have never, ever, stated in any binding way that they would not do so in the future.
3. *any* fee, even minimal would result in the instant death of any OSS project dependent on those standards.
4. RAND can (and frequently does in the proprietary software world) mean several dollars per download! Or requiring build licenses for all developers producing binaries (every end user of gentoo for example!) that are in the hundreds of $ range. These are all reasonable and non-descriminatory in that context!
Miguel De Icasa and Ximian/Mono people *know* this full well but don’t want to admit how dangerous mono adoption is for the gnome community. They cite a BS casual mailing list post from the head engineer of .net as their claim that MS will never sue.
See how much crap this is for yourself (from official Mono faq):
http://web.archive.org/web/20030609164123/http://www.go-mono.com/faq.html#patents
Jim Miller’s off hand email is the *only* assurance anyone has every received that MS would never charge a RAND fee! If this were truly MS’s commitment then they could release a statement or legally commit themselves to that! This email is not not not legally binding people! Until MS makes a legally binding agreement to never charge for use of these standards, it is not ok to use mono!
See also Seth Nickels’ blog on this subject “Why Mono is currently an unnacceptable risk”:
http://www.gnome.org/~seth/blog/2004/May
The two main arguments against what I’m saying are realy crap also:
1. Java is also proprietary: Yes but Sun has licensed Java in such a way that they are legally prohibited from charging *any* royalties at all for existing releases of Java. We know with 100% certainty that Sun will never try and collect any RAND fee. Ever. The situation with Java is totally different for this reason.
2. You are always infringing somewhere, worrying about this is wasting your time: True, there is always a danger of unknowingly infringing. However, in this case mono is knowingly using patented software. If MS decided to collect or sue, mono and gnome would have absolutely zero defense! Furthermore, MS is well known for destroying threatening companies when it suits them to do so! They have done this many times in the past. Remeber how they *lost* an anti-trust lawsuit? It is because they are agressive, unscrupulous and incredibly rich. They can and will crush gnome if gnome threatens MS! Mono is the ultimate submarine. We build it, integrate it so gnome can’t live without it, then they kill gnome by charging for builds. Bam. Gnome is dead on that day.
Take Away: Mono is cool but way too dangerous. Smart people and companies are staying away from it (which turns out to be *most* companies bye the way. That is why Redhat and others are pushing Java as an alternative). People who back mono either have motive (ximian), are misinformed (most of the people on this forum), or just dumb (people who are really drooling over the potential of mono so they are ignoring the risk, probably ximian and some gnome developers again)
Miguel De Icasa and Ximian/Mono people *know* this full well but don’t want to admit how dangerous mono adoption is for the gnome community.
As a dependency possibly, but not some distros shipping mono and its apps.
See also Seth Nickels’ blog on this subject “Why Mono is currently an unnacceptable risk”:
Another RedHat troll who likes to fling his shit and see if anything sticks.
Java is also proprietary: Yes but Sun has licensed Java in such a way that they are legally prohibited from charging *any* royalties at all for existing releases of Java. We know with 100% certainty that Sun will never try and collect any RAND fee. Ever. The situation with Java is totally different for this reason.
Prove it
2. You are always infringing somewhere, worrying about this is wasting your time: True, there is always a danger of unknowingly infringing. However, in this case mono is knowingly using patented software. If MS decided to collect or sue, mono and gnome would have absolutely zero defense! Furthermore, MS is well known for destroying threatening companies when it suits them to do so! They have done this many times in the past. Remeber how they *lost* an anti-trust lawsuit? It is because they are agressive, unscrupulous and incredibly rich. They can and will crush gnome if gnome threatens MS! Mono is the ultimate submarine. We build it, integrate it so gnome can’t live without it, then they kill gnome by charging for builds. Bam. Gnome is dead on that day.
Just more little bitch drama queen hand waving. Get a life. Most people aren’t pussies like you
Take Away: Mono is cool but way too dangerous. Smart people and companies are staying away from it (which turns out to be *most* companies bye the way.
Yeah, like you would know. hilarious
That is why Redhat and others are pushing Java as an alternative).
Nobody cares about Java in the gnome world. RedHat is wasting their times. Seriously, there is next to 0 interest. That is fact. Most people would rather use a better language like Python
People who back mono either have motive (ximian), are misinformed (most of the people on this forum), or just dumb (people who are really drooling over the potential of mono so they are ignoring the risk, probably ximian and some gnome developers again)
Seek psychological help. Nobody cares about your drama queer theatrics