RPTools.net

Well, after having done a REALLY large amount of enterprise development in Java and plenty of .NET stuff as well I can pretty well say that .NET is nowhere near as portable as Java. Nor does it have any general features which are lacking in Java whatsoever. MS has always been fairly strong in terms of having a complete lock on GUI development tools in .NET which does mean the tools available are more coherent in that area, but not necessarily technically better. If you want to quickly lay out a fancy UI then you'd probably get it done faster and cleaner in .NET. Otherwise there is simply no advantage to .NET and a lot less choice in terms of libraries and such.

Basically converting to .NET would gain you practically nothing, would mandate a total rewrite of a massive code base, and would practically insure the application would never run on anything but Windows or at the very best you'd be restricted to a very cramped subset of .NET to get it working on everything and it still wouldn't work as well outside of Windows.

There are already tons of VTTs written in .NET framework out there. Some of them are fairly nice, though they lack some advanced features of Maptool. If you REALLY want to develop a VTT under .NET then I'd suggest joining one of those projects. I'm sure they could use the help and its always nice to see new and better stuff appearing. I just know our group will never be able to use those tools in the foreseeable future as we have players on Linux, Windows, and OS-X in our group. Mono is unlikely to run a complex .NET app on all three in the near future.

Rumble wrote:

Scubba wrote:...did I stumble upon a classic programming language flame war?

Convert the whole thing to Lisp! And then let the program write itself!

Already did. Then it started converting me to Lisp, but stopped when it realized that I could be replaced by a very small shell script.

LOL . Take a point for the Tron flashes!

Imper1um wrote:I personally like C# because of various ways I can be lazy.

<shudder>

I'm not anything more than a crude hobbyist programmer who doesn't know C# from C++ from Java, but as a service support guy, that statement makes me shudder. I can't tell you how many service issues I've had to deal with because a programmer or hardware engineer did things the "lazy way."

kristof65 has the right of it. You know why drive-by malware installs have been able to get the huge install-base they have? Because 70% of all custom Line-Of-Business apps (the ones companies shell out thousands of dollars for) can't be run without Admin rights, which means every idiot in the company has local admin rights on their computer - including the joker in the warehouse who flunked out of high school and surfs for screensavers on his lunch break.

Yeah, I'm lookin' at you, UPS Worldship!

Actually, programming tools allowing you to be "lazy" can be a good thing. Even the simplest programs are impossibly complex beasts that a human could not possibly fully understand. The only reason we are able to cope with it is all the tools we've come up with to make the programmer's job simpler, especially when it comes to managing the tedious and error-prone aspects of programming. The key is that one should not gain that simplicity by sacrificing correctness.

Laziness, or so I hear, is one of the fundamental required characteristics of a programmer (along with impatience and hubris) - "there's gotta be a better way" is a battle cry.

(acknowledging, of course, that one should be Good Lazy, not Bad Lazy).

Rumble wrote:(acknowledging, of course, that one should be Good Lazy, not Bad Lazy).

got nothing against Good Lazy. It's the Bad Lazy that scares me. Problem is, when a programmer (or engineer) says just "lazy", as a tech guy, I don't know until their work is done if they meant efficient or sloppy.

nimrand wrote:Even the simplest programs are impossibly complex beasts that a human could not possibly fully understand.

I assume you were exaggerating for the effect, not because it's true. While I can't exactly say that it's a virtue, I do consider it possible to fully understand "simple programs". Of course, I was writing assembly language code during my freshman year at high school and I've been writing code ever since (going on 32 years). I've considered my relationship with computers to be not a hobby, not an infatuation, not a love affair -- I consider it an obsession. That is what best describes the time I spend with a computer. Pretty sad, huh?

I agree with Rumble: there's Good Lazy (insists on reusing existing code -- but doesn't use copy/paste) and there's Bad Lazy (names all variables "a", "b", "c" because they're only a single letter and easier/faster to type).

I'm 25, I was taught to program in QBasic when I was 8. Thus, 17 years or 68% of my life. I can not emphasize the difference between good lazy and bad lazy enough. Though... I can't really say that good lazy is necessarily really lazy so much as smart/efficient.

Most of the time if you can accomplish the same procedure through less words, the program gains the same level of efficiency. Less words = less stuff for the computer to do.

Azhrei wrote:

nimrand wrote:Even the simplest programs are impossibly complex beasts that a human could not possibly fully understand.

I assume you were exaggerating for the effect, not because it's true.

Then there is the old joke,
Every program can be simplified
Every program contains at least one bug

Of course if you follow this to its logical end every program can be simplified to a single statement which is a bug.

Actually... by the statement even that could be simplified somehow which means that the only way to create a simple bug-free solution to a problem involves not creating a program.

Personally I like to go with the phrase

"It's not a flaw, its a feature!"

I am a fan of C# as well, and I think it is a great programming language... but even I'm not one to say it would be useful to switch. I think there would be a number of benefits to switching, but as with others, I believe if you're looking for a C# engine, that you head the project to make it, maptool is open source, and it is made so that it works best of any os... which is just another reason its heads above the rest...

One of the main issues I have with java is its horrible html parsing, which C# could do 100 times better very easily, but that would mean using IE, which even I don't wish to do... I think time would be better spent on the same course, also including looking to get mozilla or another, better, browser source to work for us.

loogie wrote:One of the main issues I have with java is its horrible html parsing, which C# could do 100 times better very easily, but that would mean using IE, which even I don't wish to do...

Ah, so it's not C# doing the rendering then, is it?

I think time would be better spent on the same course, also including looking to get mozilla or another, better, browser source to work for us.

The browsers are written in C or C++ (the ones I'm familiar with at least, which isn't all of them). And linking a native C library to a Java application, while possible, puts MapTool back into the category of being platform-dependent. Here's where someone usually speaks up and says, "Yeah, but it would be much better for XYZ platform and other platforms could just use the older/simpler HTML!" Except that then MT macros are not portable, CSS included in a frame may not be portable, and so on.

One of the reasons I brought up JavaFX in a separate thread was the hope that a better interactive rendering engine was involved, even if it's not HTML...

It might be easier to put a better HTML renderer into Map Tool. This one is open source and appears to be better than the one in java. It even renders JavaFX and a Swing class. I've not used it however, so YMMV.

jay wrote:It might be easier to put a better HTML renderer into Map Tool. This one is open source and appears to be better than the one in java. It even renders JavaFX and a Swing class. I've not used it however, so YMMV.

Which one?