Reinventing a Large Wheel

  • (2 Pages)
  • +
  • 1
  • 2

29 Replies - 22723 Views - Last Post: 01 January 2013 - 05:36 PM

#1 jon.kiparsky  Icon User is offline

  • Pancakes!
  • member icon


Reputation: 7564
  • View blog
  • Posts: 12,681
  • Joined: 19-March 11

Reinventing a Large Wheel

Post icon  Posted 07 August 2012 - 09:27 PM

Since there isn't a whole lot of "Advanced Java Discussion" going on right now, I'd like to propose a fantasy situation for java heads to chew on.

One fine day, you are called into Larry Ellison's office and told of a top-secret plan to sunset the Java language and replace it with a new language, to be code-named Shiva. Some conditions are laid upon the project:

- it is necessary that it target the JVM, and interoperate smoothly with Java classes, and that it generate classes that Java can use. It should also play nicely with other languages in the jvm ecosystem
- it is not necessary that it resemble the current Java language in any particular, but it should be as easy as possible for a Java developer to use, consistent with inclusion of useful features and simplification of existing features
- it should address what you consider the most important developer pain points in the use of java, while at the same time
- continuing to facilitate large-scale enterprise development which should be assumed to be distributed in space (protoype in Somerville, design in Palo Alto, develop in shops in Peoria, Mumbai, and Lima) and time (ie, programs that will be easier to maintain and develop than to scrap and rewrite).
- it should be easier, safer, and more pleasant to use than Java is today, or than Java can be made tomorrow.

Two points are pretty firm:
Conflicts between preserving existing syntax and fluidity of new and existing features will be resolved in favor of fluidity of new and existing features.
Conflicts between points 3 and 4 will be resolved in favor of long-term safety of enterprise development, not short-term developer convenience.

The questions you will be posed are:

- is this a plausible project? Assuming that Oracle commits to supporting this to completion, is it reasonable to expect this to produce a better language than we'd get by continuing to bolt new features onto Java?
- what changes would you make to the conditions stated above to make this work better, if any?
- what would you most like to change or add to java's capabilities, assuming that the syntax were suddenly fluid enough to do it conveniently?
- what mis-steps would you most like to correct about the current java implementation?
- assuming you were to be one of the architects of Project Shiva, and you could make a good offer to any hireable person (ie, plausibly interested and not currently dead), who would you want to have on the team with you?


SO: if you were given this wheel to reinvent, where would you start?

This post has been edited by jon.kiparsky: 07 August 2012 - 11:25 PM
Reason for edit:: resolved an ambiguity


Is This A Good Question/Topic? 3
  • +

Replies To: Reinventing a Large Wheel

#2 Luckless  Icon User is offline

  • </luck>
  • member icon

Reputation: 292
  • View blog
  • Posts: 1,146
  • Joined: 31-August 09

Re: Reinventing a Large Wheel

Posted 08 August 2012 - 05:44 AM

Well, I would look at existing frameworks and choose Groovy (2004) :sigh: I would then tell my boss that we can save $$$ by using a functional programming language that operates on top of the JVM by compiling code dynamically to bytecode at runtime and that Shiva is a waste of valuable development time. Java functionality works almost completely in Groovy classes and Groovy utilizes many of Java's already existing classes with benefits. It makes using Collections so pleasant. Check out my blog in the future! It's my new favorite language and Java developers can pick it up in a day

EDIT: Then I would probably get a raise for my research findings

This post has been edited by Luckless: 08 August 2012 - 05:45 AM

Was This Post Helpful? 1
  • +
  • -

#3 sepp2k  Icon User is online

  • D.I.C Lover
  • member icon

Reputation: 2087
  • Posts: 3,175
  • Joined: 21-June 11

Re: Reinventing a Large Wheel

Posted 08 August 2012 - 06:41 AM

*
POPULAR

Many of my qualms with Java are type-safety related, so if I had to redesign it, these are some of the things I'd do:

First of all I'd deprecate type-erased generics in favor of proper reified ones that keep type information at runtime.

Pros:
- No type-safety issues anymore when reading generic objects from object streams for example
- Enables further generic-related features.
Cons:
- We'd now have two generic systems since we can't get rid of the old one if we want to interop with Java code that uses it (unless we want to treat all classes that use the old system as non-generic, but that'd just be ugly).


Secondly I'd remove the ability to implicitly cast arrays, so code like the below no longer compiles:

Object[] array = new String[42];
array[0] = new Object(); // Throws ArrayStoreException at runtime



On second thought, I'd just deprecate plain arrays all together in favor of ArrayList and add some syntax to make them as convenient to use as arrays (e.g. ArrayList<int> array = {1,2,3}; - note that using reified generics ArrayList<int> should a) compile just fine and b) not require boxing).

Pros:
- The above horrible code would no longer compile (or at least be deprecated).
- There are very few cases where arrays are superior to ArrayLists anyway - mostly people just use them because they're currently more syntactically convenient (or to avoid the need for boxing, which I've removed)
Cons:
- Dunno


The next step would be operator overloading. I'd design it in such a way that operators are bound to certain interfaces (for example implementing Comparable would give you the comparison operators lile < for free and it'd be the only way to get them - to get the subscript operator [], you'd implement List). Since the + operator would now be tied to some sort of Numeric interface, we'd need a new operator (or other syntax) for string concatenation - certainly String shouldn't implement Numeric.
Pros:
- I've just deprecated arrays and forcing the user to write array.set(i, array.get(i)+1); all the time would just be evil.
- Finally we can use BigIntegers while still writing readable code.
Cons:
- Possibility of abuse - though hopefully I've limited that by tying the operators to interfaces that make it very clear what each operator is supposed to be used for. Case in point: We're no longer abusing + to mean concatenation in some context (which somehow Java managed to do while at the same time refusing to do operator overloading because of the possibility of abuse).

I'd give interfaces the ability to force implementing classes to implement static methods and constructors. Those could then be called from generic methods.
Pros:
- Improves type-safety be removing some use cases of doing reflection by passing around Class<T> objects
- We'd be able to have methods like Enumerable<T>.toList<L extends List<T>>().


Next step would be redesigning the standard library. I think the easiest thing here would be to create our own shiva.* hierarchy and keep java.* unchanged for backwards compatibility. (Note I'm not talking about actually rewriting everything from scratch, we'd start by copying java.* to shiva.* and then start making changes).
Pros:
- Allows us to make changes to the library without worrying about backwards compatibility
- No chance of accidentally making changes that breaks old Java code that we still want to interop with
Cons:
- Doubles the size of the standard library

Some of the changes I'd do to the standard library are as follows (I'll scrap the pro-cons thing now because I've already typed enough):

- Move equals and hashCode from Object into an Equatable<T> interface. This way you no longer need to cast the argument to equals (it will already have type T), you no longer are able to implement equals without implementing hashCode (leading to strange behavior of hashmaps or other methods/classes that rely on hashCode) and you no longer accidentally compare object identity when that was not the intent.

The == operator will be tied to the Equatable interface and thus always compare semantic equality. If you need to compare objects by their identity, there'll be System.identityEquals analogous to the existing System.identityHashCode.

- Add an Equator interface that is to Equatable like Comparator is to Comparable. Add support for that interface to HashMap and other hash-based methods and classes.

- Change TreeMap and other Comparable-based classes, so that the constructor always takes a Comparator. To create a map based on the default comparator, use a static method static <T extends Comparable> TreeMap<T> TreeMap.create(). This way it's not possible to create a TreeMap of a non-comparable type without passing in a Comparator (which currently would lead to a runtime error).

In fact the static method and the Comparator-based constructor should be specified by the SortedMap interface (same for SortedSet).

As an alternative to the static method, we might also come up with a way to say that certain constructors for generic classes should only be applicable if the generic argument implements a given interface.

Obviously the HashMap class (that now accepts Equator arguments and requires the Equatable interface if no Equator was supplied), should be redesigned in the same way.

- Change things that should be generic to be generic. The argument type of remove should not be Object. When I put in a bunch of MyModels into a JComboBox, I want to get out a bunch of MyModels, not a bunch of Objects. Same for the Observable interface.

- Add an interface for numeric types (tied to the arithmetic operators) that allows me to arithmetic in a generic way. For example I'd like to be able to write this:

// This method can sum a collection of ints, doubles (without boxing even) or even BigIntegers and returns the result in the appropriate type
<T extends Numeric> T sum(Enumerable<T> numbers) {
  // The Numeric interface should require a constructor that takes an int,
  // so that I can create any number from an integer.
  // For primitive types foo = new T(bar); should be equivalent to foo = bar;
  // so primitive numeric types implement that requirement of the interface
  // by being implicitly convertible from int.
  T sum = new T(0);
  for(T num : numbers) {
    sum += num;
  }
  return sum;
}



- I know I've got loads more, but I can't think of anything else right now. Also I've already typed plenty.
Was This Post Helpful? 11
  • +
  • -

#4 xclite  Icon User is offline

  • LIKE A BOSS
  • member icon


Reputation: 894
  • View blog
  • Posts: 3,153
  • Joined: 12-May 09

Re: Reinventing a Large Wheel

Posted 08 August 2012 - 08:36 AM

Some pretty cool ideas. Given Oracle's recent litigiousness and comments about Java, though, I'd be hesitant to invest in anything they come up with.
Was This Post Helpful? 0
  • +
  • -

#5 cfoley  Icon User is offline

  • Cabbage
  • member icon

Reputation: 1939
  • View blog
  • Posts: 4,027
  • Joined: 11-December 07

Re: Reinventing a Large Wheel

Posted 09 August 2012 - 06:12 AM

Without going into too much detail, several aspects of Java's c-style syntax seem geared towards the compiler rather than towards the human code. Best served with an example from current Java:

boolean keepOnLooping = true;
int i = 1;
while (keepOnLooping) {
  if (i % 10 == 0) {
    System.out.pritnln("Stopping");
    keepOnLooping = false;
  } else {
    System.out.println("Looping");
  }
}
System.out.println("We know the loop is over because of the braces.");


I'd like to clean that up to look something like this:

boolean keepOnLooping = true
int i = 1
while keepOnLooping
  if i % 10 == 0
    System.out.pritnln("Stopping")
    keepOnLooping = false
  else
    System.out.println("Looping")
System.out.println("We know the loop is over because of the indentation.");

Was This Post Helpful? 0
  • +
  • -

#6 Jire  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 2
  • Joined: 31-December 12

Re: Reinventing a Large Wheel

Posted 31 December 2012 - 10:54 PM

View Postcfoley, on 09 August 2012 - 06:12 AM, said:

Without going into too much detail, several aspects of Java's c-style syntax seem geared towards the compiler rather than towards the human code. Best served with an example from current Java:

boolean keepOnLooping = true;
int i = 1;
while (keepOnLooping) {
  if (i % 10 == 0) {
    System.out.pritnln("Stopping");
    keepOnLooping = false;
  } else {
    System.out.println("Looping");
  }
}
System.out.println("We know the loop is over because of the braces.");


I'd like to clean that up to look something like this:

boolean keepOnLooping = true
int i = 1
while keepOnLooping
  if i % 10 == 0
    System.out.pritnln("Stopping")
    keepOnLooping = false
  else
    System.out.println("Looping")
System.out.println("We know the loop is over because of the indentation.");
But sometimes you want to use funky syntax. Having an indention-based language is hard. 4 spaces or tab? Can tab be standardized? Who knows?! I think it's a great idea but absolutely impossible to integrate into Java this far into the game.
Was This Post Helpful? 0
  • +
  • -

#7 cfoley  Icon User is offline

  • Cabbage
  • member icon

Reputation: 1939
  • View blog
  • Posts: 4,027
  • Joined: 11-December 07

Re: Reinventing a Large Wheel

Posted 01 January 2013 - 01:03 PM

Have you ever tried programming in Python? It's indentation based and is pretty easy. I don't know how it deals with tabs/spaces but it's intuitive enough for me to have been using it for a while and never wonder.

Quote

But sometimes you want to use funky syntax.


This is never a good idea. Funky syntax layouts break the reader's expectations. You should follow a standard format even if it takes a few more lines. If you are doing a course in Java, try submitting a "funky layout" for your next assignment. See if it impacts your score or if the marker makes any comments. If you are working in a job make your next commit in a funky layout and see how it stands up to code review.

I know Java won't change. The effects would actually be pretty disastrous. Think of all the lines of code to be rewritten and programmers to retrain! However, the thread was for the hypothetical situation that we could go back to the start and influence the original design of Java.
Was This Post Helpful? 1
  • +
  • -

#8 jon.kiparsky  Icon User is offline

  • Pancakes!
  • member icon


Reputation: 7564
  • View blog
  • Posts: 12,681
  • Joined: 19-March 11

Re: Reinventing a Large Wheel

Posted 01 January 2013 - 01:38 PM

Actually, my original thought was more along the lines of a successor language. It's pretty clear that nothing good can come from trying to modernize java and maintain backwards compatibility. Trying to paste on bits and pieces here and there leads to language bugs, like the allowability of untyped collections and to odd ad-hoc constructions

So the notion in my mind was, what if you get to design a successor language? The requirements would be

a) introduce the new features that we expect we're likely to want in the next ten years, in a java-like way, without worrying about backwards compatibility
B) rationalize the syntax of the existing features, again without worrying about backwards compatibility
but
c) maintain as much as possible the feel of existing Java (ie, we're not going to move to a lisp-type syntax, we're going to keep the parens and the semis)


The reason for the last is partly because I think it's a good idea to preserve the intuitions that programmers have developed, and mostly so it doesn't turn into an exercise of "let's make it more like <my favorite language>!". The changes should not be gratuitous. If you want to write python on the jvm, there's jython. Go to - but that's not what I was asking.


So, if you were designing such a successor language, what would you want it to have, and how would you introduce it?

My list would include first-class functions, real concurrency support, and tail recursion for sure. Probably lots of other stuff that'll come to me later as my mind comes back to this whimsical thought that struck me last summer.
Was This Post Helpful? 0
  • +
  • -

#9 AdamSpeight2008  Icon User is offline

  • MrCupOfT
  • member icon


Reputation: 2240
  • View blog
  • Posts: 9,410
  • Joined: 29-May 08

Re: Reinventing a Large Wheel

Posted 01 January 2013 - 01:49 PM

Non Type-Erasing Generics
Was This Post Helpful? 1
  • +
  • -

#10 smohd  Icon User is offline

  • Critical Section
  • member icon


Reputation: 1817
  • View blog
  • Posts: 4,625
  • Joined: 14-March 10

Re: Reinventing a Large Wheel

Posted 01 January 2013 - 01:51 PM

I sometime like and hate the "offside rule". Since I have been indenting my code even when working with java and .net, it simplified things when I used python. So I think working with indentation is not a big deal for most programmers.

Quote

I don't know how it deals with tabs/spaces but it's intuitive enough for me to have been using it for a while and never wonder.

I think python programmers advice the use of 4 spaces and left the tab all together.
But also I like the braces use in languages like java, to me it makes code much readable that without them. In your two above examples cfoley, i think we will easily know the end of loop with braces rather than indentation. ( and the use of both makes it much clearer).

But the issue here is not the fantasy layout which is to be changed, I think the java code layout is fine. I think the layout design wont matter alot when this opportunity comes.
To me, I will check into EE, I think I will start with that when Oracle ask me to do some changes (ofcourse after taking into consideration to some advices given above). The EE architecture need to be engineered....
Was This Post Helpful? 0
  • +
  • -

#11 macosxnerd101  Icon User is online

  • Self-Trained Economist
  • member icon




Reputation: 10364
  • View blog
  • Posts: 38,384
  • Joined: 27-December 08

Re: Reinventing a Large Wheel

Posted 01 January 2013 - 01:55 PM

View PostAdamSpeight2008, on 01 January 2013 - 03:49 PM, said:

Non Type-Erasing Generics

I don't really see the big deal for this at the bytecode level. The generics don't disappear entirely, either. They are actually written into the bytecode, as Reflection can still recover them.
Was This Post Helpful? 0
  • +
  • -

#12 jon.kiparsky  Icon User is offline

  • Pancakes!
  • member icon


Reputation: 7564
  • View blog
  • Posts: 12,681
  • Joined: 19-March 11

Re: Reinventing a Large Wheel

Posted 01 January 2013 - 01:56 PM

View Postsmohd, on 01 January 2013 - 03:51 PM, said:

But the issue here is not the fantasy layout which is to be changed, I think the java code layout is fine. I think the layout design wont matter alot when this opportunity comes.


Exactly. We're frying bigger fish here.
Was This Post Helpful? 0
  • +
  • -

#13 AdamSpeight2008  Icon User is offline

  • MrCupOfT
  • member icon


Reputation: 2240
  • View blog
  • Posts: 9,410
  • Joined: 29-May 08

Re: Reinventing a Large Wheel

Posted 01 January 2013 - 02:04 PM

View Postmacosxnerd101, on 01 January 2013 - 09:55 PM, said:

View PostAdamSpeight2008, on 01 January 2013 - 03:49 PM, said:

Non Type-Erasing Generics

I don't really see the big deal for this at the bytecode level.

What about RunTime Type Safety?
 var carlist = new List<Cars>;


In Java you can only tell it's a list<object> not that it can only accept object of type Car (or inherits from Car)

Imagine trying to implement LINQ in Java.

This post has been edited by AdamSpeight2008: 01 January 2013 - 02:08 PM

Was This Post Helpful? 1
  • +
  • -

#14 sepp2k  Icon User is online

  • D.I.C Lover
  • member icon

Reputation: 2087
  • Posts: 3,175
  • Joined: 21-June 11

Re: Reinventing a Large Wheel

Posted 01 January 2013 - 02:12 PM

View Postmacosxnerd101, on 01 January 2013 - 09:55 PM, said:

The generics don't disappear entirely, either. They are actually written into the bytecode, as Reflection can still recover them.


What do you mean by that? Are you saying that it's possible to reflect on a List<String> to determine that it's actually a List<String> and not, say, a List<Foobar>? If so, you're wrong. That's definitely not possible.

Regarding what's the big deal: In addition to type safety (eliminating type erasure will also eliminate unsafe casts), most of the type system features I mentioned in my initial wish list in this thread (like being able to instantiate type arguments or calling static methods on them) wouldn't be possible with type erasure.
Was This Post Helpful? 0
  • +
  • -

#15 macosxnerd101  Icon User is online

  • Self-Trained Economist
  • member icon




Reputation: 10364
  • View blog
  • Posts: 38,384
  • Joined: 27-December 08

Re: Reinventing a Large Wheel

Posted 01 January 2013 - 02:15 PM

I see what you're saying. The following snippet allows a String to be inserted into what should be an ArrayList<Integer>. At the very least, it does produce a nasty deprecation warning to say that this is poor practice. So that should be a good indicator to the programmer not to attempt it.

class Test{
    public static void main(String[] args){
        ArrayList list = new ArrayList<Integer>();
        list.add("test");
        System.out.println(list);

    }
}


Was This Post Helpful? 0
  • +
  • -

  • (2 Pages)
  • +
  • 1
  • 2