Alternative Java-based languages

purpleguitar · November 6, 2007, 1:33pm

I fall into the “instanceof is evil” camp. It seems to lead to abstruse coupling and maintenance problems. I have found two ways to avoid using instanceof:

Refactor. Having type-dependent code outside of the dependent class is often an indicator that refactoring is necessary to improve the design. Put the type-dependent logic into the class and call a common method rather than checking the type from outside. Disciples of Alan Kay would argue that this is “True OOP”, focusing first on the messages that are passed between collaborating objects, then on the objects themselves.
Visitor pattern. If I have type-dependent logic that is truly extrinsic to the type, the Visitor pattern solves this problem. It requires a little bit of overhead with respect to interface declarations, but it’s a useful pattern when not abused. One of the biggest advantages, in my opinion, is that you essentially have to freeze your type hierarchy for it to be effective, and doing this forces you to think through the design before further coding. This can reveal other problems in the design, unrelated to this particular problem. The other advantage is that if you do end up changing the visitor-enabled type hierarchy, the compiler will help you find missing cases, where it cannot help with cascading if-instanceof-else blocks.

I hope that’s helpful, and of course, ymmv.

Orangy_Tang · November 6, 2007, 1:52pm

purpleguitar:

I fall into the “instanceof is evil” camp. It seems to lead to abstruse coupling and maintenance problems. I have found two ways to avoid using instanceof:

Refactor. Having type-dependent code outside of the dependent class is often an indicator that refactoring is necessary to improve the design. Put the type-dependent logic into the class and call a common method rather than checking the type from outside. Disciples of Alan Kay would argue that this is “True OOP”, focusing first on the messages that are passed between collaborating objects, then on the objects themselves.

Visitor pattern. If I have type-dependent logic that is truly extrinsic to the type, the Visitor pattern solves this problem. It requires a little bit of overhead with respect to interface declarations, but it’s a useful pattern when not abused. One of the biggest advantages, in my opinion, is that you essentially have to freeze your type hierarchy for it to be effective, and doing this forces you to think through the design before further coding. This can reveal other problems in the design, unrelated to this particular problem. The other advantage is that if you do end up changing the visitor-enabled type hierarchy, the compiler will help you find missing cases, where it cannot help with cascading if-instanceof-else blocks.

I hope that’s helpful, and of course, ymmv.

Usually I go with (1), however when using some frameworks (particularly, while writing an eclipse plugin) instanceof is pretty much a requirement. And because it usually involves interfaces and objects which are part of the framework, you can’t refactor or change things. Since the standard practice doesn’t see instanceof as evil, they’re quite happy to leave things as they are (probably a valid POV, but not one I share).

Riven · November 6, 2007, 11:29pm

Have you ever worked on a text-orientated program?


StringBuilder sb = new StringBuilder();
sb.append("<html>\n");
sb.append("   <head><title>"+myTitle+"</title></head>\n");
sb.append("<body>\n");
sb.append("   <h1>"+myHeader+"</h1>\n");
sb.append("   "+myText+"\n");
sb.append("</body>\n");
sb.append("</html>\n");

Believe me, it gets VERY annoying. Try to write some javascript inthere and you’d cry. Working with templates or external files where variables get search-and-replaced in code, solves only part of the problem, but are very restricting when building truely dynamic pages.

With my knocked up dialect it would become:


String message = """
<html>
   <head><title>"""+myTitle+"""</title></head>
<body>
   <h1>"""+myHeader+"""</h1>
   """+findContent(myPageID)+"""
</body>
</html>
""";

Making the parser slightly more intelligent would allow to turn all “”" into " and keep the functionality.

Further, it makes it easier to mix functionality and layout in 1 file. That’s not really neat, but it’s damn convenient (like PHP)

DzzD · November 7, 2007, 1:12am

fletchergames:

I’m going to buy a book about AspectJ on Amazon.com after I move just because I can get it for a few bucks plus shipping.

Personally, I would like something that’s just a little less verbose than Java but has roughly the same functionality. This would be no good if I couldn’t use libraries of code similar to the ones that come with the JRE. There are things that I can do without. I can even do without the AWT, but I need to have some way to at least create a graphical application window and switch between full-screen exclusive mode and regular mode. And I need to have sound support similar to Java’s.

Some examples of verbosity:

imports:

import java.awt.*;

I would prefer to just type “import java.awt;”

indentation:

public class A extends B implements C {
//indent here
public void method() {
//indent twice here
}
}

Since I usually have one main class per file, there’s no need for indentation within the class. In fact, I would rather have it be LIMITED to one main class per file (though inner classes would still be allowed). The syntax could just be:

public class A extends B implements C;

public void method() {
//indent only once
}

That may sound a little bit pendantic, but I’m indenting most of every file for nothing. If I have 3 nested for loops, my variable names take up all the space I have available after indentation. Some people would call this bad programming practice and tell me that my code is too complicated. I call this “why shouldn’t my code fit on the screen”.

In practice, I actually don’t indent the main class in the file, but Eclipse fights me on this by auto-indenting too far.

access modifiers:

In Java, I type:

public void methodA() {}

public void methodB() {}

…

public void methodZ() {}

In C#, I can type:

public {
void methodA() {}

void methodB() {}

…

void methodZ() {}
}

I would much rather type:

public:

void methodA() {}

void methodB() {}

…

void methodZ() {}

Granted, it’s not immediately obvious upon looking at a method in the middle what it’s access modifier is. In a class, I have all my public methods/classes/variables first, protected second, package third, and private last. I think that makes good sense and allows the access modifier blocks to be adequately descriptive.

no “final” required for parameters:

I have to type:

public void methodA(final int a, final int b, …, final int z)

to make it so I can’t set parameter variables equal to other values. This should just always be the case, no “final” required.

simpler enums:

This isn’t too important (and may be slightly off topic), but enums don’t need to have the capability to define different methods on each element of the enum. I think this kind of breaks enums a bit, but it does make them more powerful. I don’t normally use this capability.

I love enums, but I have a minor objection to them. If you define a static final variable in an enum class definition, you can’t use it in the enum element constructor calls. I define a separate class to store flag constants because of this. I don’t know if this can be fixed though because static variables are probably defined after enum elements so that the enum elements can be used in the variables.

simpler Runnables:

I understand that Runnable is an interface and has to be implemented this way. However, I don’t want to type:

Runnable myRunnable = new Runnable() {
public void run() {
//method here
};

It’s not that big of a deal. I just have to type it alot. There should be some abbreviation, like the following:

Runnable myRunnable = {
//method here
};

Essentially, I want to be able to define code blocks as variables, just like in functional programming languages. It’s basically C# delegates, though less verbose. For methods with parameters, I could type:

ActionListener myListener(ActionEvent event) = {
//method here
};

This would basically be a shortcut for one-method interfaces. The one-method interfaces would just be delegates instead.

there are some good shortcut but it is not really related to Java, I mean it is quite easy to write your own pre-compiler program that convert your shortcut to Java :


public:
void methodA() {}
void methodB() {}

convert to


public void methodA() {}
public void methodB() {}

same for :


public class A extends B implements C;

public void method() {
   //indent only once
}

can be converted by a pre-compiler to:


public class A extends B implements C
{
 public void method() 
 {
   //indent only once
 }
}

most of the shortcut you mention can be threated by a pre-compiler program, or an IDE plug, no ?

fletchergames · November 7, 2007, 5:46am

DzzD:

there are some good shortcut but it is not really related to Java, I mean it is quite easy to write your own pre-compiler program that convert your shortcut to Java :
public:
void methodA() {}
void methodB() {}
convert to
public void methodA() {}
public void methodB() {}
same for :
public class A extends B implements C;

public void method() {
   //indent only once
}
can be converted by a pre-compiler to:
public class A extends B implements C
{
 public void method() 
 {
   //indent only once
 }
}
most of the shortcut you mention can be threated by a pre-compiler program, or an IDE plug, no ?

True. Or, in some cases, by macros or code generators.

The problem is that all these things are little nuisance things, not really worth doing alot of work over. But if I were going to create my own language anyways, I would be sure to include these features.

I guess my original post was a little off topic because I’m talking more about formatting than about actual language features.

EgonOlsen · November 7, 2007, 7:11am

Am i the only one around here who prefers typing a few more characters instead of introducing the next crude syntax extension just to save a few of them? I never understood why programmers argue that typing is a bad thing. If you don’t want to type, get out of programming…

Matzon · November 7, 2007, 7:47am

nope, I totally agree with you - and you can have a lot of IDE stuff to handle all of the syntactic sugar.
The problem arises when you want to introduce new features that can’t be handled by the current language. Stuff like Generics.

This made my skin crawl tho:

public static <T> void foreach(T[] ts,{T,{=>void},{=>void}=>void} block)

generics and closures :-X

kevglass · November 7, 2007, 8:11am

I’ve always thought that the coding bit of the end is the bit that takes the shortest time, and so optimizing how many bits and pieces you have to type seems pretty fruitless. I mean the ideas and design before hand is the everso expensive bit - I’d really like some optimizations that make me think more quickly

That said:

Are all the things I’ve always wanted in the language, not really to decrease verbosity but to improve robustness and help in creating safe and apt code (assuming you use them).

I took this one out:

for standard rant reasons. It’s a great feature but too open to misuse which leads to sloppy coding for my money.

Kev

Orangy_Tang · November 7, 2007, 9:44am

To be fair, I havn’t had a ClassCastException that generics would have prevented in years. Generics are probably the most droppable from that list.

princec · November 7, 2007, 12:23pm

The thing that normally catches me out is NPEs. So I’d really rather like a “not null” modifier for variable declarations. Eclipse already goes some way to detecting that something may be null when referenced but I want to be able to declare that at the interface level. My code is full of comments like


@return a String, or null if the value isn't found

or


@param coords The location of the gidrah (may not be null)

and it’d just be nice to formalize it.

+1 for const.

Dunno what RAII is so probably don’t need it.
Already use generics when I can - very sparingly they work well.
Would love to implement single-method interfaces with a shorthand syntax.
Would also love to block-declare visibility with public {}, but only variable declarations as methods are usually spaced much further apart.
Would like to be able to declare static variable inside methods; thereby restricting scope. Very handy for certain sorts of debugging.
Almost never ever use instanceof as there’s a design pattern to avoid it.
Would like type inference in the language. Never saw the reason to have to type:


String s = (String) someObject;

as it is perfectly obvious that to assign to s you need a String.
Would like to be able to embed any other language I want into Java source code using an annotation:


System.out.println("Blah blah");
ResultSet rs = @sql {
select * from records where wibble="wobble"
}

(and xml, and html, etc, etc)
+1 for multiline strings but why not just simply not terminate each line with the "
And I want BLOODY STRUCTS somehow. Well, mapped objects.

Cas

Orangy_Tang · November 7, 2007, 12:38pm

princec:

The thing that normally catches me out is NPEs. So I’d really rather like a “not null” modifier for variable declarations. Eclipse already goes some way to detecting that something may be null when referenced but I want to be able to declare that at the interface level. My code is full of comments like
@return a String, or null if the value isn't found
or
@param coords The location of the gidrah (may not be null)
and it’d just be nice to formalize it.

Yeah, something like this looks really handy (near the bottom third of the page). At the moment I get by with comments and asserts, but NullPointerException is probably the most common bug I run into.

Matzon · November 7, 2007, 2:58pm

embedding sql in your code is just bade coding practice

erikd · November 7, 2007, 4:04pm

+1 to ‘something like a not null modifier’
+1 to block-declare visibility with public {}
+1 to const
+1 to static variables inside a method

-1 to multiline strings: It solves nothing and obscures syntax.
-99 to embedding any other language using annotations: It solves nothing and encourages bad practice

The code

String s = someObject;

implies that a reference is being assigned to someObject. This is only possible if someObject is in fact a String, so imho it’s correct that (String) is mandatory here.
If your suggestion would make it, than the above code without (String) could do 2 different things depending on the type of someObject (it would either assign a reference to someObject, or call someObject.toString()).

The whole deal with String is messy enough don’t you think? Let’s not making it worse just for the sake of a few keystrokes

princec · November 9, 2007, 2:06pm

Why on earth would it call toString()? I’m only talking about removing explicit casts. There really isn’t any need for them most of the time as the type of the receiver is known already and therefore a cast is implicit.

Cas

erikd · November 10, 2007, 1:53am

Ooooops :-[ you’re right, of course it doesn’t call toString()… My mind must’ve been totally elsewhere, and I must have been confused with the behaviour of System.out.println, and the ‘+’ operator for Strings. Man, I feel stupid now :’( :

Removing explicit casts like you’re saying kind of makes sense on one hand, but on the other hand it also makes it more clear at first sight that there’s casting going on (but of course that comes from someone easily confused like me :)).
I usually don’t mind typing explicit casts anyway, and I usually prefer a bit of verbosity (explicity) over possible vagueness (implicity) in code.

gouessej · November 10, 2007, 10:11am

I agree with you too. On my view, Java mustn’t become a clone of C#. Java should better keep simple, simpler than C++ and if Orangy Tang is fed up with Java, no one forces him to go on using it. I don’t really see the interests of having a “free” function as the garbage collector does its job fine. Even C++ ISO will integrate an optional garbage collector. The use of “free” in C has a higher cost as you do it directly on the OS. The garbage collector tries to do it at the best moment, it is better on my opinion, it doesn’t have the same effect than a “free” call as the JVM handles the memory by itself, it isn’t the same mechanism. Orangy Tang made many suggestions of features already present in C++ and Java is a kind of simplification of C++. Complicating Java to get it closer to C++ would be a huge error. Too many programmers think that handling the memory by themselves would be more efficient than delegating this task to the garbage collector but it is a prejudice as many experts of Sun and IBM (Dr. Holly Cummins) said.

Orangy_Tang · November 10, 2007, 1:24pm

Epic fail.

“Free functions” means functions not associated with a class. Ie. a global main() function, rather than being forced to wrap up all functions inside a class performing the same duties as a namespace. This has nothing to do with the actual free() function, and nothing to do with garbage collection.

princec · November 10, 2007, 1:28pm

Hehe, tiny misunderstanding there

Not sure why free functions are so useful…? Is it just being able to define them when you don’t have the original source? (Ie. bolt ons to a library)?

Cas

Orangy_Tang · November 10, 2007, 1:43pm

Because it’s a simple feature which should be present in the first place, rather than the slightly hacky way of forcing people to use static member functions. On a more practical note, I often find myself writing lots of static functions which don’t actually belong anywhere specifically, and you end up either with lots of FooUtilities classes or bundling them in with an existing class and bloating it up. And when you’ve got a Frobnicate(Foo, Bar) then it’s non-obvious where that should live.

It also gets nicer when you add multimethods and/or templated code over the top so you can just call Frobnicate() and depending on the actual arguments different method implementations get called - possibly even ones outside of your module which other people have bolted on. You can’t do that if you’re forced to specify a class to call the method on every time.

Mr_Light · November 10, 2007, 2:40pm

And makes it equally unmaintainable (like PHP*)

*PHP written badly, like mixing presentation and logic.
if thats really what your thing use PHP + JAVA + Quercus

[quote]“Free functions” means functions not associated with a class. Ie. a global main() function, rather than being forced to wrap up all functions inside a class performing the same duties as a namespace. This has nothing to do with the actual free() function, and nothing to do with garbage collection.
[/quote]
I fail to see the added value here. //edit Perhaps its too alien to me as only parsely write static methods like the ones you outlined. //edit2 Frobnicate seems like something very general and unspecific. perhaps its a bad example

[quote]Would also love to block-declare visibility with public {}, but only variable declarations as methods are usually spaced much further apart.
[/quote]
Write an ide plugin for that?

also the syntax mentioned before with removing the {}, is tbh goddam awefull. If you keep your cyclomatic complexity down as you (inmost cases) should, Indents are hardly any problem next to that any decent ide supports single/double space indentation coupled with widescreen monitors coupled with monitor sizes of these days. sorry It doesn’t make sense to me.

about const there are 2 ‘bugs’ with a lot of votes that are related.

About closesures and the prosposed long hand syntax well yeah it’s ugly.(short hand is nice, and gets my support) I’m not sure what to change the long bit into, I gotta mount a defence to that. Since it’s only needed whenn defining a clossure It can be longer then the long hand syntax is now.