For example, in Java you don't need to remember whether the method to add an object to an ArrayList is called "add" or "insert" because your IDE can tell you what methods an ArrayList object has. Here's an example from Eclipse:
You can see that it's called "add". If you weren't sure if the method to return the number of items was "size" or "length" you can easily find that out too. In DM projects you can't do this. To know the types of arguments and the type of return value for a given proc you need to either have them memorized or dig through code to find it out. When you come back to a DM project after a while it takes time to get used to working on it again because you don't have this information memorized anymore.
The Idea
This gave me an idea: Create a program that converts Java code to DM and provide a Java project that defines BYOND's built-in vars and procs. You get the benefits of using a Java IDE (code completion) and Java's features (type safety). For example:
public class mob
{
public void Login()
{
loc = locate(3,4,5);
}
}
Would be converted to:
mob
Login()
loc = locate(3,4,5)
This is not a proper translator. The goal is not to convert a working Java program to a working DM program. The purpose is to leverage Java's strong typing and feature-rich IDEs. The development would be done entirely in Java, you'd only convert the code to DM to execute it.
In the example above you'd see this:
You would also get argument lists and return types for functions that you've defined.
The Java code would compile but not execute. To execute the code you'd need to convert the Java code to DM code then compile that (this process would be automated). You can use Java's compile-time errors to check for potential problems in your code. For example:
// Java
mob m = get_dist(a,b)
System.out.println(m.name);
// DM equivalent
var/mob/m = get_dist(a,b)
world << m.name
The DM compiler won't complain about that code but it will have a runtime error. The Java compiler would catch this because it knows that get_dist returns an integer, not a mob.
Problems
The biggest problems occur where Java's syntax differs from DM's. These issues are major when the feature is necessary. For example, Java has no global variables or methods but these are necessary in DM (if for nothing else than to reference the built-in global procs). Having no global variables or methods means that to access the locate proc like I did in these examples, the locate proc would need to be a member of the datum class. I'm not sure if there's a way to have a class contain all global vars/procs and be able to reference it without an identifier (global.locate(x,y,z) is not ideal).
Type safety might be an issue for some parts of DM that aren't well defined themselves. DM doesn't have much of a concept of an "overlay" object but we'd need to establish one. This seems possible but there might be some issues hidden in there.
Some DM tricks that use ..() might not be doable. This isn't a huge problem because there's a way to write equivalent code without using ..() but DM users might be used to it.
