Zugg Software :: View topic

Wizard Joined: 14 Oct 2000 Posts: 1368

quote:
Originally posted by Zugg

While I don't dispute your actual results in the cases you tried, I'm having a hard time figuring out in theory how that could be. If your code is interpreted, or running on a virtual machine (which is essentially an interpreter at the machine code level), then you are executing more instructions than code that has been compiled directly into native machine code.

If you only compile java once, even with the virtual machine compiled in, the java code is still being executed by the virtual machine which is converting java code into machine code.

It's a somewhat different topic, but if anyone knows how Java supposedly performs this magic of being just as efficient as native compiled code, I'd be interested in hearing it.

I think that is what java calls JIT - Just in Time Compilation. The idea is to compile the bytecode to native code and let the processor run it rather than the interpreter. Sun has a small explanation of it at http://wwws.sun.com/software/solaris/jit/

Posted: Tue Jun 29, 2004 8:23 pm

Oh, yet one more post. He also made a good comment about memory management in application development. I agree with him that this is a huge issue and is one of the main reasons I use Delphi. Delphi has handled memory management for a long time now. Perhaps people are not aware of what Delphi really does. Delphi provides a complete object oriented framework for the Win32 API (calls it the VCL). So, I *rarely* access the Win32 API directly. I program using Delphi VCL objects. These objects are coded in native Win32 API, but I don't have to care about that. In a lot of ways the .NET components are the same as the Delphi VCL. So, do I really care about the Win32 API? Not really. As long as my Delphi objects keep working.

I'd use Delphi for .NET but the 3rd party developers have not caught up yet. A lot of the very cool and sophisticated components I'm using in Zeus are not available yet for .NET. That might change in several years. Also, Delphi for .NET takes a step backwards in stability. It's the first version of Delphi for .NET. Give them a few more versions and then I might switch. By then they might have a way for my existing VCL objects to get translated to .NET objects or something. But Borland is mainly waiting to see what happens...whether or not they release another Delphi for Win32 depends a lot on what is talked about in the article that was posted. They were required to release a .NET product to keep up with Microsoft (and did it faster than Microsoft thought they would). Borland needed to show Microsoft that they still couldn't have all the developers to themselves ;)

COM programming also handles memory management for you. I never have to worry about deallocating COM objects. Delphi and Windows together handle that. COM is a *great* system. Like Delphi, it gets ignored because it was so hard to use in Microsoft Tools. I mean *really* hard to use. As the article states, people with COM knowledge are really hard to come by. But in Delphi it has been easy for years. Select File/New/Automation Object and use the Type Library editor to add properties and methods to your object. Poof! a COM object. Even Microsoft Developers have been known to use Delphi just because it make writing COM objects so easy. But for people stuck with Microsoft tools, COM objects were hard and few people really made good use of them.

Finally, I liked the part of the article that talked about the "MSDN Magazine" team and their philosophy of "don't worry about fixing existing stuff, lets give them new stuff". The number one headache I've had with zMUD was my choice of using MDAC/ADO for the database stuff. MDAC/ADO came from the "MSDN Magazine" team and not the Win32 compatibility team. The different versions of MDAC have made zMUD trouble shooting a real pain. Every time Microsoft comes out with a new version it seems to break as many things as it fixes. I didn't have much choice on that decision though. Win32 didn't have it's own database engine. At least ADO has stabilized a bit now on newer systems. But it's an example of the kind of stuff we can expect from the "MSDN" team and what a mess it will be if we go that direction.

So, to *finally* conclude...I'm sticking with the Win32 camp for now. Maybe it will remain stable long enough for me to deliver some nice applications. I'll never be able to market it like Microsoft could, but hopefully Zeus will be a way for people to get Avalon/XAML functionality on all versions of Windows without waiting for Longhorn or future technologies.

Posted: Tue Jun 29, 2004 8:26 pm

Rorso...correct, that is true. When you "run" a Java application, it's essentially compiling it to machine code at the beginning. So, you need to consider the *entire* time in the comparison of speed. That initial startup time while it is compiled counts. For some applications, this startup slowdown is unacceptible. For others (like web-downloaded stuff), you are waiting for the download to finish anyway, so compiling it at the beginning is a good idea.

But even so, my actual experience with a lot of Java apps is not good. Maybe it's just the poor user interface designs or something.

But JIT compilation is a good technology. I had forgotten about that, so thanks for mentioning it. Considering that 300,000+ line zMUD completely recompiles in Delphi in under 10 seconds, JIT compilation is a good way to handle things now that process speeds have increased.

Magician Joined: 09 Oct 2003 Posts: 459 Location: USA

Existing applications (of the win32 variety) will still work on Windows Longhorn, however, the operating system is geared towards the .NET framework (and vector based interfaces instead of bitmap based interfaces... however, they've also got some framework to help with those as well).

And, again, the important thing with how .NET works isn't the programming tools. There is a freeware IDE for C# which is just as powerful as VS.NET in many ways. The important thing is how the framework works in conjunction with the programmer.

Instead of you having to write your own MD5 encryption routine or nabbing one from a vendor for your app... you just add in System.Security.Cryptography that the framework already has in place and use that. Want to talk to various network sockets? Well, the old way, you'd need to write your own sockets library or nab one from a vendor. Now? Just add in System.Net.Sockets and System.Net and viola.

Microsoft has taken an API toolbox and just thrown every little tool they can think of in it. Come Longhorn, there will be even more tools in there for any and every programming using .NET to be able to access at no extra fee. You could do all of your programming in C# and use the free IDE and you'd still be getting all of the programming environment features that Visual Studio.NET, Delphi for .NET, or even COBOL.NET has to offer. And the great thing about all of this... components talk back and forth in a more organized and faster manner than COM, your registry doesn't get completely and utterly bogged with COM references, pure .NET apps can be run on any platform with a .NET framework (Common Language Infrastructure) in place, framework level protection against buffer overrun attacks, and a lot of the silly little house keeping chores are done on the framework level instead of having to worry about programming them in as well.

Zugg, you are right that Borland had a programming environment suite that was as good, if not better than that of Visual Studio .NET for years now. But that's like looking at a birthday cake and arguing about the shade of blue on the candles. Dot NET was Microsoft's answer about what to do with the next version of COM. COM was designed to be this neat little protocol that the occasional program would use to talk with another program. Microsoft didn't think that it would become a way to design applications (This is why programming Delphi is easier... most VS programmers think of programming around COM instead of making COM work around their program). So, there was the argument whether to clean up COM or do something new that would also interact with COM... so the went with the latter being that it was more prudent and less crufty to start over and make it backwards compatible than to slap a bandaid on the current system.

Yes, you might have been programming the '.NET way' as far as ease of development and robust IDE tools, but not in the way of architecture holding everything up.

(I appologize for my zealotism, but I'm a iNTp according to the Meyers-Briggs model... those of you who understand that will understand completely)

Wizard Joined: 14 Oct 2000 Posts: 1368

quote:
Originally posted by Zugg

Rorso...correct, that is true. When you "run" a Java application, it's essentially compiling it to machine code at the beginning. So, you need to consider the *entire* time in the comparison of speed. That initial startup time while it is compiled counts. For some applications, this startup slowdown is unacceptible. For others (like web-downloaded stuff), you are waiting for the download to finish anyway, so compiling it at the beginning is a good idea.

But even so, my actual experience with a lot of Java apps is not good. Maybe it's just the poor user interface designs or something.

But JIT compilation is a good technology. I had forgotten about that, so thanks for mentioning it. Considering that 300,000+ line zMUD completely recompiles in Delphi in under 10 seconds, JIT compilation is a good way to handle things now that process speeds have increased.

I don't think it compiles the entire application, but the methods as they are needed. Then the compiled version is stored for later usage.

Edit: A possible issue with the method might be optimization and the quality of the code generator. A real compiler might spend much more time on optimizing and producing nice code for the target CPU.

GURU Joined: 10 Oct 2000 Posts: 867 Location: USA

quote:
Originally posted by Zugg

OK, sorry to post again so soon, but I just got done actually reading the entire article that Darker mentioned. You need to GO READ THAT ARTICLE! Here is the link again just to make it easy: http://www.joelonsoftware.com/articles/APIWar.html

obontopic:
It's nice to be insulated from underlying changes. This is one of the main goals of .NET. That's why some higher level languages are nice: hopefully Zeus will evolve in this direction for end developers/users. The basic services need to be kept up to date, but the program that THEY spent time writing will hopefully survive.
/obontopic

Joel tends to state things in very strong terms.

In reality, it's simply too early to get excited about rumours of Win32 compatability/incompatibility on OS's that won't be released for the foreseeable future. The example of MS's efforts to preserve compatibility that Joel devotes the most column space to is actually a good example of where I would like to see MS NOT spending their money: supporting not just undefined behavior, but actual prohibited behavior that happened to work (freeing memory, then using it). I don't want to have to deal with the possible side effects of MS trying to support not just old features, but old bugs.

Actually, Borland seems to have come much closer to dropping Win32 support than MS has. Judging by Borland announcements reposted in various newsgroups, Delphi 7 wasn't even supposed to include any support for it. :)

As far as Delphi goes, I think a quote from one of your other posts in this thread is enlightening:"So yes, for most of the world (who doesn't know about Delphi),"

That's the same mistake that the Linux folks made for many years: the assumption that people who used Windows simply didn't know any better. When the Linux coders finally stopped to look at why people weren't using Linux, they made some improvements and got many more users as a result.

I just couldn't resist the following quote from Joel's website, especially since is comes in an article in which he answers your implied question about how the larger developer community is approaching .NET [}:)]:

http://www.joelonsoftware.com/articles/Our.NetStrategy.html

"A few dozen people will now proceed to compose angry emails praising some other development environment, or asking why we don't just use Java and get Write Once Run Anywhere (giggle), or Delphi (the talent has left the building. .NET is Delphi 7.0, and 8.0, and 9.0), or Lisp, or whatever."

-Tarn

Posted: Wed Jun 30, 2004 5:11 am

Yep, I agree that it's too early to tell. But from what I heard, Microsoft already released an update to .NET that broke some compatibility with the first version, so it sounds like they are *still* learning how to update the underlying system without disturbing the stuff at the application layer. I'm betting that for a while .NET isn't going to quite deliver the "protection" that it promises, but like everything, will improve with time.

Your comments about Delphi hit very close to home. The quote "the talent has left the building" is very true and very scary. While they have not absolutely ruled out a new Win32 version of Delphi, everyone is pretty much assuming that Delphi for Win32 has reached it's end. We've been waiting over 2 years for the service pack for Delphi 7 that continues to be promised and never delivered. And the fact is, Delphi 8 for .NET (should be Delphi 1 for .NET, but whatever) is not up to normal Borland quality. It was obviously rushed to get into the .NET market early. But I'm sure it will improve. By the time I need to worry about .NET, it might be fine. Then again, by then I might be using C#...who knows. But I haven't been to a Borland conference in over 3 years, and the Delphi Informant magazine has been all ".NET" stuff for many months now, making me think I should end my long time subscription. After all, if I want .NET stuff, there are much better magazines.

On the other hand, Delphi 7 is the most stable version of Delphi I have used and is working quite nicely. It fully supports Windows XP and themes, which is the main thing I was missing in Delphi 5 (I had to kludge XP support in zMUD). So, other than the service pack, I'm not sure I *need* a new version of Delphi for Win32.

The fact that I don't have any plans to upgrade Delphi 7 for a *long* time is actually rather freeing in a way. For example, as you might have seen in Zeus, I wanted you to be able to modify a set in VBscript without specifying every member of the set. As an example, the Font.Style property allows you to set bold, italic, underline, etc. Instead of doing the normal:

Font.Style = "Bold,Underline"

which would have the side effect of turning *off* Italic if it was already on, I implemented the syntax:

Font.Style = "+bold,+underline"

which turns on bold and turns on underline without disturbing any of the other existing styles.

In order to add the + and - syntax to the string-to-set conversion routine, I actually had to go modify the TYPINFO.PAS source file in Delphi. Normally I wouldn't do something like this because my changes would get overwritten by any Delphi update. But since I don't plan to update Delphi 7, I'm now free to make whatever changes to the source code that I need.

If Microsoft breaks something in Win32 in Longhorn...no problem, I'll just modify the Delphi source code to fix the problem. Now, not *all* of the source code is included, so I can't actually recompile everything...but I can do most of it. I also always make sure I have source code for any 3rd party components. So now I really have full control over the entire project. And that's nice.

What this discussion *has* done is told me that I do need to learn more about .NET, just in terms of making it easier to talk about what Zeus is and how it compares. And if some of my component interfaces mimic some of the .NET stuff, that might make it easier for developers. Since .NET and Zeus are for completely different audiences (Zeus is all about end-user customizeability and scriptable applications) some overlap in at least terminology might help if there will be more and more people who understand the .NET approach. Right now I tend to use Delphi terminology and fewer people are going to relate to that over time.

(edited to say: Woohoo, we made page 2! I love threads like this. They really get me thinking about future directions and where Zuggsoft fits and energizes me to add more cool stuff to eMobius and Zeus)

(also added to say that this thread sparked an interesting conversation over lunch today with Chiara where we agreed that Microsoft can have all of the casual users and business users and we'll just stick with the non-casual users for our customers :)

Posted: Wed Jun 30, 2004 9:29 am

Btw, it's now official...we can all blame Darker Wink

That's right...he just *had* to post that link. Silly me...I spend all my time programming and never have time to explorer the 'net. Then, every now and then, someone posts a link in one of these forums.

The first time it happened was with slashdot. Yes, it's true, I had actually never heard of slashdot until then. Now it's on my daily "read" list on my PDA (at least the PDA summary version).

Now Darker introduces me to the Joel on Software site. Then I made the mistake of clicking on the "Archive" link on that site. Wow, there is a ton of interesting and useful stuff on that site for someone like me. Some good technical stuff, some excellent programming philosophy, small business management, etc. Back when I was in management I did a lot more of that kind of reading, but haven't had time to browse through all the normal crap since I started programming again. Finally, here is a site whose "crap factor" (I apologize) is very low.

So, I didn't get *any* programming done today. And it's all Darker's fault.

Of course, the stuff spinning around in the back of my brain because of some of the stuff I read is going to end up paying off in many better ways than a couple of hours of coding. So, not only can you blame Darker for taking away a few hours of programming, but you can also thank him for some of the stuff that will happen in the future.

Not to mention that improving my mood and feeding my enthusiasm and optimistic look on the future is a great way to dramatically improve future products.

Darker...thanks! [8D]

(now, it's 2am, so I guess I should go to bed)