Linked by Thom Holwerda on Wed 4th May 2011 20:41 UTC, submitted by lemur2
SuSE, openSUSE The first major effect of Attachmate buying Novell (and thus, SUSE) has come into, uh, effect. Novell, of course, is the birth place of Mono, the open source implementation of Microsoft's .NET framework. Reports indicate Mono developers have been fired as part of the streamlining process, but according to Attachmate's CEO, they weren't fired because of Mono.
Thread beginning with comment 472072
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Let Mono transform
by pantheraleo on Fri 6th May 2011 19:58 UTC in reply to "Let Mono transform"
pantheraleo
Member since:
2007-03-07

In my opinion, Attachmate now should get rid of all patent-infested code, drop all compatibility with .NET, take different laguage - Go, Python or Scala or... and create fully open sourced competitor for Java and .NET platforms. Also making it primary programming platform for Linux systems.


Scala isn't a competitor to Java. It's a language written for the Java virtual machine. So it basically runs on Java.

Any why should they reinvent the wheel? They should just adopt Java, which is fully open source now as it is licensed under the GPL. There are also open source implementations of Java EE licensed under the GPL (Glassfish) and some under the Apache licenses (Geronimo).

Adopting Java has worked well for Red Hat after all.

Edited 2011-05-06 19:59 UTC

Reply Parent Score: 2

RE[2]: Let Mono transform
by kalcytriol on Fri 6th May 2011 22:03 in reply to "RE: Let Mono transform"
kalcytriol Member since:
2011-04-23

You misunderstood me. I meant Scala as a boilerplate-free language compared to Java language, not a platform. Java is bad and ugly programming language. Its the new old C++.

Reply Parent Score: 1

RE[3]: Let Mono transform
by pantheraleo on Sat 7th May 2011 01:50 in reply to "RE[2]: Let Mono transform"
pantheraleo Member since:
2007-03-07

Java is bad and ugly programming language. Its the new old C++.


I disagree with that. And here is why. It's true that Java is verbose, but that verbosity is why Java IDEs are so incredibly powerful. Java IDEs can do things that IDEs for dynamic languages can't even dream of doing because there just isn't enough information in the code to figure out what to do. If you really take the time to learn the features of your Java IDE, it can save you enormous amounts of typing, and enormous amounts of time because you don't have to break your flow to stop and look things up.

Let me give you a few examples of things I typically do in my Java IDE, in this case, IntelliJ IDEA.

Let's say I want to add an action listener to a component that I have:

addAc [Ctrl + Space - Enter] The IDE automatically finishes the method name addActionListener for me.

Now lets say I want to create an anonymous inner class as my action listener:

new A [Enter]

The IDE automatically completes the class name, automatically imports the required classes, and automatically generates a method stub for the method I have to implement. So basically, when I type new A [Enter], the IDE generates all of the following code for me:

import java.awt.event.ActionListener;
import java.awt.event.ActionEvent;

new ActionListener() {
    public void actionPerformed(ActionEvent e) {
      // Insert code here
   }
});

I get all of that, just for typing "new A [Enter]"

Let's say I want to create a new RequestDispatcher object:

RequestD [Ctrl + Space - Enter] [Ctrl + Space - Enter] = new R [Enter]

Again, that will automatically complete the class name, and automatically import the required class. The second [Ctrl + Space - Enter] will automatically create a variable with a reasonable name (in this case it will create a variable named "dispatcher"), and finally, the new R [Enter] will automatically complete the class again.

Later, lets say I want to pass that request dispatcher object to another method of another object that accepts a request dispatcher as a parameter.

someObject.foo([Ctrl + Space - Enter]);

In this case, IDEA is smart enough to know that the only variable I have in scope that matches the type expected by someObject.foo, is the dispatcher object. So it will automatically complete the code with the correct variable. This works even if dispatcher is a subclass of the type that someObject.foo expects (or implements a compatible interface). IDEA is smart enough to recognize that as well, and so recognize that dispatcher meets the type requirements of the parameter that someObject.foo expects.

Whether you use [Ctrl + Space - Enter], or just [Enter] depends on whether a popup code completion has already displayed automatically or not.

If you really learn how to use your IDE (especially if it is IntelliJ IDEA), you'll be amazed at how often you can use auto-completion and have the IDE know what you want. That saves enormous amounts of typing, as well as reduces the risk of repetitive stress injury to your fingers.

Granted, Java is not much fun to write in a plain text editor that doesn't "understand" the Java language. Bur when you write Java in a decent IDE, you'd be amazed at how productive you can be. And of course, since the IDE recognizes and flags all of the same errors that the compiler does, there's no excuse for ever having a compile time error when working in an IDE.

Edited 2011-05-07 02:06 UTC

Reply Parent Score: 2