Home Log In or Register Forums

Windows API

Home > Forums > It And Computing > 'Windows API'
'Windows API'
Page: [1] [2] [3]
nelson's user image
nelson
17.06.2004 - 09:58
forum administrator
article

A very interesting read, although a bit long, so make sure you hold your breath before you click.
arar's user image
arar
17.06.2004 - 15:41
Very interesting indeed. Makes me question where Java really fits into all this...
nelson's user image
nelson
18.06.2004 - 07:48
forum administrator
richard's user image
richard
18.06.2004 - 13:50
forum administrator
Tis a very good article. I firmly believe that web is the way to go, although you'll always need rich-clients, unless you fancy writing a javascript spell checker, Nelson? ;)
richard's user image
richard
18.06.2004 - 13:58
forum administrator
...actually Nelson, surely this makes a very good case for Java? If people get fed up of the changing windows APIs, then they may start to stick with the write-once-run-anywhere (lol!) java alternative...?
arar's user image
arar
18.06.2004 - 21:37
Just as long as they can produce a JVM for each operating system...
Plus they could do with some standard optimized libraries, such as DirectX - but for each operating system.
nelson's user image
nelson
19.06.2004 - 09:42
forum administrator
Actually, I believe Java won't be the answer for that. I might be completely wrong, but it just seems too cumbersome a language to do anything quickly - and it evolves too slowly to fix its quirks.

I mean, the crappy GUI and sluggish performance might have been ok for the first 2 years after it was invented, but how long has it been around now? And only recently has Sun finally released a new version that ddresses some of those problems.

Don't get me wrong, my dislike for Java has nothing to do with the fact that I never learnt to use it properly - I think that languages like Python and Perl have more of a chance, and I know less about them than I do about Java. I just find it too convoluted to do small things.

I have some more liking for C#.NET than Java, though - it's clearly a language/framework that learnt from Java.

That said, I believe that neither will take the seat of favourite developer's language for small and medium-size applications. VB lost that seat with VB.NET, so I think that's up for grabs at the moment. Things are a lot more fuzzy now than a few years back - even the likes of Python, Perl, and PHP (!) are contenders now, since the user interface is moving towards HTML/XML models even on desktop apps.
nelson's user image
nelson
19.06.2004 - 09:51
forum administrator
I do think that rich clients will obviously always play a great role, but most of the interesting development is on the web. I suggest you have a quick look at the Web Forms 2 proposal; with some luck the "poor server" will also get an upgrade in the near future.

And if Microsoft doesn't have it's way, we might come to the point where JS-enabled spellcheckers could work - why not? If web clients progress in a sensible manner, I see download-behind-the-scenes, auto-upgrade modules for web applications as the way forward. Just imagine, go to your word processor's "spelling settings" and click all the specialised languages spellcheckers you want and they download and "install" on the spot (by install I mean be placed on a specific repository space for that web application).

That's the kind of functionality I see appearing over the next few years if web standards evolve quickly. Of course, Microsoft has a plan to screw this up and make sure that this sort of functionality only exists on MS Servers interacting with MS Clients all using MS Internet Explorer.

At the present, this still can be averted. Longhorn won't be out for another couple of years, so this could be the all-or-nothing moment for web standards.

(Still no mobile - pop on MSN if you wanna chat)
arar's user image
arar
20.06.2004 - 19:14
uh, that tests things is seriously screwed up.

For example, the whole purpose of Java does not fit the tests he has designed!!

Perhaps if we did some other tests, to see how Python / PERL worked in other ideas, we'd find Java far out in the lead (oops better put some examples in here =p ).

For example, there are tests in their for "the amound of physical characters that are needed to perform particular functions"

Lets compare php, for example, with Java here (because we both like php =) )

Hello World

PHP

Hello World

Java

public class hello_world {
public static void main(String[] args) {
System.out.println("Hello World");
}
}

This is not a comparison!! The amount of work we are doing here doesn't really compare. Lets break it down

1) Everything has to be defined as a class in Java, to be consistent. Consistant is good, standards are good. Therefore we need to declare a class.

2) Technically, the modifier "public" in public class hello_world doesn't need to be there at all - there are defaults.

3) public static void main(String[] args) is the standard form for creating the "main" method. If you wanted to include the "main" method of PHP, you'd have to include the entire PHP interpreter, which I believe would put this test out of PHP's league.

4) System.out.println("Hello World"); - in this case, the main method contains java code, which must contain a command - technically the two words "Hello World" are not PHP code - they are simple
arar's user image
arar
20.06.2004 - 19:23
text that will be interpreted by the PHP interpreter, but in fact if you want PHP to produce you'd have to use <?php echo "Hello World"; ?>

5) The System.out.println() function is part of a far larger class, the System class, which gives a great deal of functionality that PHP doesn't have. Technically, most of the functions built into PHP should have the prefix "System.", for example System.setcookie("variable", "value", expiretime); but because it is assumed all low level functions are the same, no System object is required. This makes it a darn site harder to work with, debug and generally manage in terms of documentation - in Java the System object contains all the system level commands etc - a single collection of commands.

If I went into some of the other criteria, there is complete rubbish in there as well - several points

1) Compilation and execution in one command - you DO realise that this is technically the same as compiling, and then calling the run command? Just because Java didn't decide to bundle the two together, doesn't give it a disadvantage!! Unless of course we are talking about compiling hundreds of projects in a row, in which case Java will require twice as many execution commands! (Incidently, this command is available in most IDEs).

2) Shebang aware? This is so specific it is almost laughable - Java loses points because the beginning of the file does not cooperate with the beginning of PERL / others. Guess what, if there was a special java code
Page: [1] [2] [3]

You must log in to post messages on this board. If you don't have a username and password, you can register quickly to get them!

contact us © 2003, 2004 BurningHorizons.net