Dubious choice of benchmarks
on
Does C# Measure Up?
·
· Score: 2, Insightful
Since registration is required to read the article, I have not read it. But given the title of the publication I was alert to the possibility of bias, and I think it's quite strongly present in the introduction. Java is the platform against which.Net will be measured for the forseable time and I think that the choice of benchmarks in Part 1 strongly favour.Net.
application invocation (time to load and execute)
It seems likely to me that the CLR will be be preloaded/vigorously cached by a Microsoft OS whereas the JVM is treated like any other application. Startup times will be skewed appropriately
algorithms and recursion (calculating Pi and Eratosthenes's sieve)
One of the small number of additional features of the CLR over the JVM is support for tail-end-recursive algorithms. This test will favour the CLR for the reason.
conversions (int to float, float to int, int to string, string to int)
A valid test but half useless. How much time is spent in an application casting from float to int or vice versa? Conversion between ints and strings is a valuable benchmark (XML based applications have to that often).
Java has a weakness (actually it has had many) with its treatment of String handling. They are slow to manipulate and memory heavy. Further changes are being made in 1.5 (introduction of non-synchronized StringBuilder class). If the.Net libraries can't do better than the Java libraries then I'm appalled.
From the outside, this article just looks like another opportunity has been taken to falsely bash Java with.Net
Whether -2^2 is equal to 4 or -4 completely depends on the specification of the 'arithmetic language'. But without reading any documentation, my expectation would not be -2^2=4 not -4.
The reason is that the '-' in -2 is not -1 * 2 but the unary negation operator. In most languages such operators tend to take precedence over binary operators (like ^).
It is helpful to write the negation operator with a different character (often '~' is used) to disambiguate it from subtraction. Without using an extra character, the best way to make the meaning clear is to use parenthesis (-2)^2.
That Excel claims -2^2=4 cannot be considered 'VERY wrong'.
Your correction is wrong, though more accurate than the comment you are correcting.
To 'beg a question' means to found an argument on an assumption which is at least as uncertain as the thing you are trying to demonstrate. This includes, but is not limited to, circular arguments.
HW Fowler (1858-1933) the great scholar of the English language defined 'begging the question' as "the fallacy of founding a conclusion on a basis that as much needs to be proved as the conclusion itself."
Fowler provides the following non-circular examples of 'question begging': "Fox-hunting is not cruel, since the fox enjoys the fun." and "One must keep servants, since all respectable people do so."
If you are going to be a pedant, at least be pedantic about it.
Nope, in VBScript's syntax Foo("bar") is used to call a default method on an object. In this case Request.QueryString is a built-in object which provides the collection of parameters supplied on the URL (often but not always generated by a GET form submission).
This is an huge security hole in the code and typical of code written by those who have no regard for even basic security. This error is actually worse than it looks since any database which accepts multiple SQL commands speparated by semicolons* can be supplied with a string of SQL which correctly terminates the query, does something really nasty, then correctly starts the remaining SQL string.
In this case, supplying the following text for the id would do something nasty:
0); DROP ALL; SELECT * FROM journal WHERE (id=0
You wouldn't believe how frequently this mistake is made on IIS ASP sites. And it's very easy to exploit, because by default ASP just spits out any SQL error to the client. So first you enter any old junk to try and force an error. Then it shows you some/all of the original query. This is usually enough to deduce a valid query portion. Then you can just inject your SQL poison.
* SQL Server does, I don't know about Access 2000 which seems to be the database in this example.
C# is certain to be a large success, primarily because it offers windows developers a migration route to a platform which is inherently more supportive (in terms of increased type safety, thorough exception handling etc). However, I think that most of the ground it steals will be from developers already using Microsoft's Development tools.
Java, on the other hand, actually seemed to help kickstart a whole new programming ethos when it was released, introducing new techniques to a new generation of programmers. I don't believe C# provides any functionality which will cause history to repeat itself in that way, and Java developers have no reason to change their tools.
There is another significant thing to recognise as distinct between the.Net platform and the Java platform (as opposed to C# and Java the language). Unless you already the know the language well, spend a few hours reading the Java 1.4 API. It is enormous. And most of that code is pure Java..Net appears equally large, but it seems as though most of it is actually a wrapper around existing windows code. What I'm saying is that the amount of C# in.Net is tiny compared to the amount of Java in Java.
Java is designed around (or at least firmly moving to) a specification/provider framework where Sun provide an API in the form of a set of interfaces and base classes together with a reference implementation, for which anyone else can supply an alternative. This encourages lots of Java development which is actually not visible to developers external to the Java development community.
For example, you could probably find a dozen different crypto packages for Java, all written to the same API. I don't think that's how it will work with Microsoft. How often does a developer get to replace a component which Microsoft supplies? Rarely, they're just not encouraged to, or perhaps even allowed to.
Before this rant I have to point out that I have a biased perspective (I'm developing a remote windowing toolkit which works through HTML in a browser see RecipeXperience). Flash as a medium for web applications can only work if a number of its inherent limitations are overcome. but I think these are too firmly entrenched.
Flash evolved as tool which allowed developers 100% control over low level presentation using vector graphics. Flash is inherently low-level. Macromedia seem to be investing large amounts of energy pushing it up-hill.
HTML has proved a successful language partly because it acts as a glue for other content: text, images, movies, audio, applets, flash etc. Like all 'glue' languages, it's not perfect but has a niche because it's useful. Its document centric roots allow for convenient dynamic generation. Far more so than Flash which, as a movie format is ill suited to both content amalgamation and dynamic generation. Including support for scrollbars is dandy, but what advantage does that provide over embedding a flash movie into a scrollable <div>?
Pushing Flash for web applications? Flash would have to become grossly distended to support proper applications - take web email: Think of all the functionality Flash would have to have added to support such a staple web application properly. Printing, displaying HTML content, good support for presenting and controlling lists of data, efficient server-side generation. All this from a file format which was designed to deliver vector graphics?
I can't see how even a company as large as Macromedia could make this happen. Something has gone wrong when a company talks about adding windowing controls to a vector movie format. It's like trying to make jackets by adding leather to zips.
Programmers are need to make magic happen with computers. And if this does come to pass, all that will happen is that graphic designers will become marginalized, and programmers will step in to support the dynamic elements, and ultimately thousands of developers will waste millions of hours trying to solve one problem with tools designed for another.
I'm staggered by the levels absurdity the topic of CLR's polylingual capabilities generates in the Slashdot readership, I'm pulling extracts from various comments here to illustrate my points:
WildBeast wrote: Like Python, Perl, Ada, Eiffel, VB, C#, Cobol, etc.? I don't look at them as skins
I say: The authors analogy is actually excellent. The languages of C# provide nothing more than a semantic gloss over the entrenched runtime characteristics.
nebaz wrote: Hello? How is [skinning] different than compiled languages?
I say: The target language of compilation for such languages is typically assembly/machine code. Thus compiled languages can have no better performance than assembly language allows (obviously). In general it is obvious that no language can perform better than the language into which it is compiled. Thus languages for the CLR can perform no better IN ANY RESPECT than the equivalent C# (which has 1-1 correspondance with the CLR feature set).
mestar wrote: You guys are missing the most important point: there is only one API to program against.
I say: How can there be one API? How can an API for a functional language, such as Haskell, which makes use of closures, monads, higher level functions etc. _possibly_ be represented within the CLR framework without becoming utterly bastardized.
jovlinger wrote: So you see, having several languages implemented for one back end, so that I can write my lexing routines in PERL, write my AST construction routines in Java, and my compiler in Scheme, ammounts basically to choosing the right tool for the job.
I say: Doesn't this make the fallacy obvious to you? This would imply that the lexing routines of PERL.Net could be no better those implemented in Java!
bentini wrote: Just because I can run LISP and C on the same [runtime] doesn't mean that they're similar.... Of course you can have the same underlying structure, you can have different underlying structures too.
I say: No you cannot have different structures, this is why the advantages touted for the CLR are such gross distortions of the truth. Essentially your LISP.Net language is an implementation of LISP in C#. Thus it will share all of the performance characteristics of the C# language. For example, the CLR unifies all primitive types (as does Java) in a way which is inevitably inadequate for some languages. How can those languages (LISP included) be said to be fully supported by a runtimes which cannot even handle their primitive types?
Finally, the Doctor Dobbs artical which Reality Master 101 quotes (http://research.microsoft.com/~emeijer/Papers/Mon drianDDJ.pdf) offers a lovely sleight of hand where the memory resources for a C# implementation of the sieve of Eratosthenes using a growable array are traded for a Mondrian implementation which uses infinite lists (ala Haskell) via recursion which uses up unquantifiable volumes of stack space. The author's tone is suggestive of, though he does does not state explicitly that, Mondrians solution is not possible in C# or VB.Net.
Believe it or not I actually have very little against the CLR. It's the purported (and preposterous) claim of it's language independence which really irks me.
I agree with just about everything above. It's just that what you are describing is less encapsulation (in the interests of useability for developers). I think that ultimately the Swing developers had little choice in the amount of encapsulation they had to use because the Swing API needed to be all things to all people. Whereas the AWT was a subset of all windowing toolkits, Swing tries to be a superset, and largely suceeds at the expense of much complexity. The complications of layering it above the AWT don't help either.
Speaking as one who has architected and implemented a remote windowing system RecipeXperience which is currently just entering beta, I feel that I have some useful advice to contribute.
Primarily I would forewarn you that such API's are inherently DIFFICULT and as they mature become BIG and careful maintanence is required.
Secondly bear in mind that a great many people have already gone through the effort (pain!) of creating stable and functional user interfaces. So you must have a very good idea of why you want to create another windowing API. In our case there are many unique aspects of the API which cannot be replicated within other toolkits.
Specifically be aware that most software exists solely to interact with other software. One good example is a webserver. Lets take the example of writing one. It is by no means a trivial task to write a good webserver. Yet the protocols it must adhere to are not particularly overwhelming and the task generally reduces to two points of low level interaction, the socket and the file system. Both of which are relatively straightforward entities to program with since their possible behaviour at any given time is constrained and typically well documented. Ultimately the 'user' of the server is a browser (or other comparable piece of software) which can interact with the server only via the fairly restrictive means of a socket connection and an well established protocol.
Now try to imagine a windowing system 'in full flow' and in its entirety (not easy unless you have worked a long time on developing one). Specifically try to think of all the actions a user could possibly try to undertake. Within a user's desktop there are literally tens of thousands of possible actions a user can undertake at any instant.
Just try counting up how many buttons you have on screen (meny buttons, form buttons, taskbar buttons), how many ways you can launch each them (clicking, shortcut keys), how many ways you can navigate to each them (keyboard navigation, programmatic selection, mouse), how many ways each button can respond (activated, toggled, selected, dropdown menu, popup menu). And that's just buttons! Think of all the different types of components which developers and users will expect in a modern windowing system.
Then look at applications as 'users' of your API, think of all the things an application could choose to do while the user (or another application) is interfering. And now we are thinking about the broader picture try to imagine not just one user action but tens of thousands and all the possible orders they could occur in, and all the possible mistakes they could contain. And think of all the possible application errors which might occur and which need to be dealt with safely (memory management is a good one to start thinking about).
Now think about implementing all of that correctly, think about how you might test it, think about debugging it, possibly across different platforms and finally think about documenting it all.
Still fancy writing a windowing API? As I said, you need a good reason to write one.
IMHO Swing is not properly encapsulated; they chose getting cute with the design patterns over encapsulation.
Can you explain what you mean by this? The purpose of design patterns is encapsulation. The proliferation of classes that you seem to have difficulty using is an indication of high levels of encapsulation.
Furthermore you say,
I would bet the threading lack is due to the cross-platform requirements.
I would say that it's a very poor bet. The purpose of single threading portions of an API which is as complex as Swing is to protect developers from incidents of deadlocks which can occur when there is a mismatch between the threading model in the API and the code using that API.
Since Swing is a windowing API, having it dictate the threading pattern of your application would certainly leave "the tail wagging the dog".
I said nothing about signing the ML code. I was simply referring to using a crytographic hash to recognize the virus without giving virus-writer's an opportunity to pass-off a variant as the same virus.
The problem with the idea of signing the code is that it is a virus. Presumably an embedded executable. Where is the signature going to go? It would have to be sent in parallel with the code (in an email perhaps) - effectively a big sticker saying 'SENT BY FBI'.
I can't see that working as a mechanism for discreet observation.
This creates an interesting situation. As I understand it, virus detection programs use:
1) signatures -specific byte patterns which are searched for in files, and
2) heuristics - in this case algorithms which seek unlikely looking data to determine whether the user should be alerted to a possible intrusion attempt.
McAfee can of course omit signatures for this 'Magic Lantern' (ML) software from their database. However, in the case of the heuristics, avoiding user notification of ML requires either:
a) a weakening of the heuristic(s), presumably to such an extent that other viruses may penetrate the system or
b) the presence of a special signature in the McAfee software which (on recognizing ML) can 'override' the heuristic
Case (b) is interesting. If McAfee do this with a simple byte pattern search this will immediately provide viruses with a neat little 'binary tag' which permits them to evade McAfee's software
The alternative must be to use a cryptographic hash which can be used to identify ML but which cannot be readily forged by other virus code. Using this checksum technique also demands that the ML 'payload' remain unchanged. Very restrictive for code which needs to be stealthy.
But the most important side-effect of both of these techniques - and any others McAfee might choose to use, would be that it provides an easy route for developers to produce software which can check for ML.
In other words, McAfee cannot both provide useful levels of virus detection and avoid alerting the user to Magic Lantern without giving other developers a blueprint to locate it.
Your example is more involved than it needs to be because you are doing more than an enum requires.
C#
public enum Direction {North, East, West, South};
Java
public class Direction {
private Direction() { }
public final static Direction NORTH = new Direction();
public final static Direction SOUTH = new Direction();
public final static Direction EAST = new Direction();
public final static Direction WEST = new Direction();
}
I think this is the direct translation of the supplied enumeration. C#'s is much nicer to type, but adds more syntax to the language for very little gain. The power in Java's approach is that if, at any later time I wan't to extend the functionality of Direction I can, as demonstrated by your post where each direction is given a human readable name I don't know much about C# but this doesn't look possible for enums.
With the present financial difficulties for airline operators, it seems highly probable to me that severe cost cutting will have swiftly resulted in reduced aeroplane maintenance and fewer safety checks.
Futhermore money diverted into increased security is money diverted from day-to-day operations. The current climate of fear in the US probably makes accidental crashes more likely.
>How can a US court make a decision regarding enforcement of a foreign court decision?
I don't think it can sensibly.
>Likewise, how can a French court expect to decide the practices of a US company that hosts a site in the US?
Yahoo! is a multinational company with offices in France. Of course the French government have the right to restrict the practices of a company which operates within the jurisdiction of its laws.
If Yahoo! was solely a US concern then your point would be valid, but it isn't. Here is an analogy:
I have dual British-French nationality. If I live in France and host a website from England which is legal in England but not in France, would you expect me to be exempt from French law because I'm also English? Of course not.
So should AOL which is a registered company in both the US and France be exempt from a ruling in French law? Of course not.
In a computer game, the interface AND the environment are determined by the authors. This is why incremental disclosure is so effective. Learning how to use MegaGunX in the fifth level is okay because the designers didn't add GruesomeCreatureZ, the first enemy in the game which can only be killed by that weapon, until level 6.
Application designers on the other hand have only control of the interface. They can't choose to make an advanced feature like mail-merge available only after 50 documents, because the user might find themselves in an environment where they need to use any particular feature 'out of the box'.
What I think JC Hertz is observing is that games must generally include some form of tutorial (which may be part of the game) because games UI's are generally quite distinct. And that furthermore, these tutorials are actually structured as part of the game.
So the proper comparison is between the help in say MS Office and early game levels. With this perspective 'Clippy' can be seen as an attempt to introduce the in-situ learning which games so often provide - an incredibly botched attempt though.
Either you misunderstand or it's a subtle troll...
Latency will delay the start of the video stream (and possibly introduce a delay in control data returned from the client) but once the connection is established and data begins to flow bandwidth is the primary limiting factor.
Of course, it is impossible to judge the veracity of this Australian company's claims without further technical details. One's initial reaction is to dismiss it as untrue (or very partially true) because it is so far beyond the envelope of what is widely known to be possible. But it's important not to be completely dismissive.
While modern compression schemes are quite advanced most only seek to remove a small number of redundancies in an image. Typically they coarsen the color space greatly, the luminesence a little and subsequently seek to look for areas in the frame sequence which can be recognised as a transformation of areas in neighbouring frames.
This has proved very successful but it is certainly not the only technique one might attempt. A long while ago (several years) I turned my attention to the problem of compressing video data and considered the following approach of taking video data and deducing the geometry and surface colour of the physical entities which were filmed. This occurred to me as I result of thinking how easily I as a human can remember certain scenes by knowing the objects involved and their positions rather than remembering the scene in it's entirety.
So imagine an algorithm which when applied to video footage attempts to deduce the geometry of scene elements, and their textures and then record how they moved. Playback would involve a basic kind of 3d rendering followed by a correction stage. All sorts of other techiques could be thrown at this scheme including progressive geometric and colour-map refinements, positional interpolation, even kinematics.
I have no expertise in moving image compression and this idea came to me without much effort. A team of computer scientists and mathematicians would surely come up with something better, but with techniques like the one I outlined above I wonder what kind of quality a 28.8 connection could provide.
On an underpowered machine, it is inevitable that the browsers which are designed to be scalable, and to perform well at larger tasks will be precisely those which perform worst.
I think this trend is clearly apparent in the given rendering (not loading) times. I am not suprised at these high figures, most of it will be accounted by virtual memory paging.
> Java passes primitive types (int, double, char) by value, but Objects by reference
No. I have to set the record straight on this one - I see this confusion frequently. Java passes ALL primitives by value. References are a primitive and are passed by value. This uniformity of method invocation which is not seen in most other C derivatives. This subtlety seems to be lost on most Java programmers.
On the wider topic of passing values vs. references, Java's equivalent of pass by value for objects (since objects are never actually passed as arguments) is to call a clone method on the object to be passed thus:
Dog rover = new Dog();//make a dog
Dog rex = rover.clone();//twin dogs
rex.sit();//rex sits, rover stands
Crufts.judge(rover);//rover enters crufts, rex does not
Note how the clone method actually produces a distinct reference value (from that stored in rover) to an identical dog. IFAIK Java rarely duplicates any object by bytewise copy, instead, when an object is cloned a fresh object is constructed and populated (however the implementor sees fit) with corresponding values. This provides flexibility but makes cloning very expensive.
To avoid this overhead I think there is a distinct move towards designs which make more use of immutable objects. Combined with a specialist factory pattern this can provide very fast and robust code. Java programs written largely in this mode start to heavily resemble functional programs (with all their benefits).
Slashdot Mirror
Since registration is required to read the article, I have not read it. But given the title of the publication I was alert to the possibility of bias, and I think it's quite strongly present in the introduction. Java is the platform against which .Net will be measured for the forseable time and I think that the choice of benchmarks in Part 1 strongly favour .Net.
.Net libraries can't do better than the Java libraries then I'm appalled.
.Net
application invocation (time to load and execute)
It seems likely to me that the CLR will be be preloaded/vigorously cached by a Microsoft OS whereas the JVM is treated like any other application. Startup times will be skewed appropriately
algorithms and recursion (calculating Pi and Eratosthenes's sieve)
One of the small number of additional features of the CLR over the JVM is support for tail-end-recursive algorithms. This test will favour the CLR for the reason.
conversions (int to float, float to int, int to string, string to int)
A valid test but half useless. How much time is spent in an application casting from float to int or vice versa? Conversion between ints and strings is a valuable benchmark (XML based applications have to that often).
string comparison, string concatenation, string tokenization
Java has a weakness (actually it has had many) with its treatment of String handling. They are slow to manipulate and memory heavy. Further changes are being made in 1.5 (introduction of non-synchronized StringBuilder class). If the
From the outside, this article just looks like another opportunity has been taken to falsely bash Java with
Whether -2^2 is equal to 4 or -4 completely depends on the specification of the 'arithmetic language'. But without reading any documentation, my expectation would not be -2^2=4 not -4.
The reason is that the '-' in -2 is not -1 * 2 but the unary negation operator. In most languages such operators tend to take precedence over binary operators (like ^).
It is helpful to write the negation operator with a different character (often '~' is used) to disambiguate it from subtraction. Without using an extra character, the best way to make the meaning clear is to use parenthesis (-2)^2.
That Excel claims -2^2=4 cannot be considered 'VERY wrong'.
Your correction is wrong, though more accurate than the comment you are correcting.
To 'beg a question' means to found an argument on an assumption which is at least as uncertain as the thing you are trying to demonstrate. This includes, but is not limited to, circular arguments.
HW Fowler (1858-1933) the great scholar of the English language defined 'begging the question' as "the fallacy of founding a conclusion on a basis that as much needs to be proved as the conclusion itself."
Fowler provides the following non-circular examples of 'question begging': "Fox-hunting is not cruel, since the fox enjoys the fun." and "One must keep servants, since all respectable people do so."
If you are going to be a pedant, at least be pedantic about it.
Nope, in VBScript's syntax Foo("bar") is used to call a default method on an object. In this case Request.QueryString is a built-in object which provides the collection of parameters supplied on the URL (often but not always generated by a GET form submission).
This is an huge security hole in the code and typical of code written by those who have no regard for even basic security. This error is actually worse than it looks since any database which accepts multiple SQL commands speparated by semicolons* can be supplied with a string of SQL which correctly terminates the query, does something really nasty, then correctly starts the remaining SQL string.
In this case, supplying the following text for the id would do something nasty:
0); DROP ALL; SELECT * FROM journal WHERE (id=0
You wouldn't believe how frequently this mistake is made on IIS ASP sites. And it's very easy to exploit, because by default ASP just spits out any SQL error to the client. So first you enter any old junk to try and force an error. Then it shows you some/all of the original query. This is usually enough to deduce a valid query portion. Then you can just inject your SQL poison.
* SQL Server does, I don't know about Access 2000 which seems to be the database in this example.
...that companies like IBM and Microsoft develop these technologies with the sole purpose of generating as much money as possible?
C# is certain to be a large success, primarily because it offers windows developers a migration route to a platform which is inherently more supportive (in terms of increased type safety, thorough exception handling etc). However, I think that most of the ground it steals will be from developers already using Microsoft's Development tools.
.Net platform and the Java platform (as opposed to C# and Java the language). Unless you already the know the language well, spend a few hours reading the Java 1.4 API. It is enormous. And most of that code is pure Java. .Net appears equally large, but it seems as though most of it is actually a wrapper around existing windows code. What I'm saying is that the amount of C# in .Net is tiny compared to the amount of Java in Java.
Java, on the other hand, actually seemed to help kickstart a whole new programming ethos when it was released, introducing new techniques to a new generation of programmers. I don't believe C# provides any functionality which will cause history to repeat itself in that way, and Java developers have no reason to change their tools.
There is another significant thing to recognise as distinct between the
Java is designed around (or at least firmly moving to) a specification/provider framework where Sun provide an API in the form of a set of interfaces and base classes together with a reference implementation, for which anyone else can supply an alternative. This encourages lots of Java development which is actually not visible to developers external to the Java development community.
For example, you could probably find a dozen different crypto packages for Java, all written to the same API. I don't think that's how it will work with Microsoft. How often does a developer get to replace a component which Microsoft supplies? Rarely, they're just not encouraged to, or perhaps even allowed to.
Before this rant I have to point out that I have a biased perspective (I'm developing a remote windowing toolkit which works through HTML in a browser see RecipeXperience). Flash as a medium for web applications can only work if a number of its inherent limitations are overcome. but I think these are too firmly entrenched.
Flash evolved as tool which allowed developers 100% control over low level presentation using vector graphics. Flash is inherently low-level. Macromedia seem to be investing large amounts of energy pushing it up-hill.
HTML has proved a successful language partly because it acts as a glue for other content: text, images, movies, audio, applets, flash etc. Like all 'glue' languages, it's not perfect but has a niche because it's useful. Its document centric roots allow for convenient dynamic generation. Far more so than Flash which, as a movie format is ill suited to both content amalgamation and dynamic generation. Including support for scrollbars is dandy, but what advantage does that provide over embedding a flash movie into a scrollable <div>?
Pushing Flash for web applications? Flash would have to become grossly distended to support proper applications - take web email: Think of all the functionality Flash would have to have added to support such a staple web application properly. Printing, displaying HTML content, good support for presenting and controlling lists of data, efficient server-side generation. All this from a file format which was designed to deliver vector graphics?
I can't see how even a company as large as Macromedia could make this happen. Something has gone wrong when a company talks about adding windowing controls to a vector movie format. It's like trying to make jackets by adding leather to zips.
Programmers are need to make magic happen with computers. And if this does come to pass, all that will happen is that graphic designers will become marginalized, and programmers will step in to support the dynamic elements, and ultimately thousands of developers will waste millions of hours trying to solve one problem with tools designed for another.
I'm staggered by the levels absurdity the topic of CLR's polylingual capabilities generates in the Slashdot readership, I'm pulling extracts from various comments here to illustrate my points:
... Of course you can have the same underlying structure, you can have different underlying structures too.
n drianDDJ.pdf) offers a lovely sleight of hand where the memory resources for a C# implementation of the sieve of Eratosthenes using a growable array are traded for a Mondrian implementation which uses infinite lists (ala Haskell) via recursion which uses up unquantifiable volumes of stack space. The author's tone is suggestive of, though he does does not state explicitly that, Mondrians solution is not possible in C# or VB.Net.
WildBeast wrote: Like Python, Perl, Ada, Eiffel, VB, C#, Cobol, etc.? I don't look at them as skins
I say: The authors analogy is actually excellent. The languages of C# provide nothing more than a semantic gloss over the entrenched runtime characteristics.
nebaz wrote: Hello? How is [skinning] different than compiled languages?
I say: The target language of compilation for such languages is typically assembly/machine code. Thus compiled languages can have no better performance than assembly language allows (obviously). In general it is obvious that no language can perform better than the language into which it is compiled. Thus languages for the CLR can perform no better IN ANY RESPECT than the equivalent C# (which has 1-1 correspondance with the CLR feature set).
mestar wrote: You guys are missing the most important point: there is only one API to program against.
I say: How can there be one API? How can an API for a functional language, such as Haskell, which makes use of closures, monads, higher level functions etc. _possibly_ be represented within the CLR framework without becoming utterly bastardized.
jovlinger wrote: So you see, having several languages implemented for one back end, so that I can write my lexing routines in PERL, write my AST construction routines in Java, and my compiler in Scheme, ammounts basically to choosing the right tool for the job.
I say: Doesn't this make the fallacy obvious to you? This would imply that the lexing routines of PERL.Net could be no better those implemented in Java!
bentini wrote: Just because I can run LISP and C on the same [runtime] doesn't mean that they're similar.
I say: No you cannot have different structures, this is why the advantages touted for the CLR are such gross distortions of the truth. Essentially your LISP.Net language is an implementation of LISP in C#. Thus it will share all of the performance characteristics of the C# language. For example, the CLR unifies all primitive types (as does Java) in a way which is inevitably inadequate for some languages. How can those languages (LISP included) be said to be fully supported by a runtimes which cannot even handle their primitive types?
Finally, the Doctor Dobbs artical which Reality Master 101 quotes (http://research.microsoft.com/~emeijer/Papers/Mo
Believe it or not I actually have very little against the CLR. It's the purported (and preposterous) claim of it's language independence which really irks me.
I agree with just about everything above. It's just that what you are describing is less encapsulation (in the interests of useability for developers). I think that ultimately the Swing developers had little choice in the amount of encapsulation they had to use because the Swing API needed to be all things to all people. Whereas the AWT was a subset of all windowing toolkits, Swing tries to be a superset, and largely suceeds at the expense of much complexity. The complications of layering it above the AWT don't help either.
Speaking as one who has architected and implemented a remote windowing system RecipeXperience which is currently just entering beta, I feel that I have some useful advice to contribute.
Primarily I would forewarn you that such API's are inherently DIFFICULT and as they mature become BIG and careful maintanence is required.
Secondly bear in mind that a great many people have already gone through the effort (pain!) of creating stable and functional user interfaces. So you must have a very good idea of why you want to create another windowing API. In our case there are many unique aspects of the API which cannot be replicated within other toolkits.
Specifically be aware that most software exists solely to interact with other software. One good example is a webserver. Lets take the example of writing one. It is by no means a trivial task to write a good webserver. Yet the protocols it must adhere to are not particularly overwhelming and the task generally reduces to two points of low level interaction, the socket and the file system. Both of which are relatively straightforward entities to program with since their possible behaviour at any given time is constrained and typically well documented. Ultimately the 'user' of the server is a browser (or other comparable piece of software) which can interact with the server only via the fairly restrictive means of a socket connection and an well established protocol.
Now try to imagine a windowing system 'in full flow' and in its entirety (not easy unless you have worked a long time on developing one). Specifically try to think of all the actions a user could possibly try to undertake. Within a user's desktop there are literally tens of thousands of possible actions a user can undertake at any instant.
Just try counting up how many buttons you have on screen (meny buttons, form buttons, taskbar buttons), how many ways you can launch each them (clicking, shortcut keys), how many ways you can navigate to each them (keyboard navigation, programmatic selection, mouse), how many ways each button can respond (activated, toggled, selected, dropdown menu, popup menu). And that's just buttons! Think of all the different types of components which developers and users will expect in a modern windowing system.
Then look at applications as 'users' of your API, think of all the things an application could choose to do while the user (or another application) is interfering. And now we are thinking about the broader picture try to imagine not just one user action but tens of thousands and all the possible orders they could occur in, and all the possible mistakes they could contain. And think of all the possible application errors which might occur and which need to be dealt with safely (memory management is a good one to start thinking about).
Now think about implementing all of that correctly, think about how you might test it, think about debugging it, possibly across different platforms and finally think about documenting it all.
Still fancy writing a windowing API? As I said, you need a good reason to write one.
You write,
Can you explain what you mean by this? The purpose of design patterns is encapsulation. The proliferation of classes that you seem to have difficulty using is an indication of high levels of encapsulation.
Furthermore you say,
I would say that it's a very poor bet. The purpose of single threading portions of an API which is as complex as Swing is to protect developers from incidents of deadlocks which can occur when there is a mismatch between the threading model in the API and the code using that API.
Since Swing is a windowing API, having it dictate the threading pattern of your application would certainly leave "the tail wagging the dog".
What you are describing is:
b) the presence of a special signature in the McAfee software which (on recognizing ML) can 'override' the heuristic
From my original post.
I said nothing about signing the ML code. I was simply referring to using a crytographic hash to recognize the virus without giving virus-writer's an opportunity to pass-off a variant as the same virus.
The problem with the idea of signing the code is that it is a virus. Presumably an embedded executable. Where is the signature going to go? It would have to be sent in parallel with the code (in an email perhaps) - effectively a big sticker saying 'SENT BY FBI'.
I can't see that working as a mechanism for discreet observation.
This creates an interesting situation. As I understand it, virus detection programs use:
1) signatures -specific byte patterns which are searched for in files, and
2) heuristics - in this case algorithms which seek unlikely looking data to determine whether the user should be alerted to a possible intrusion attempt.
McAfee can of course omit signatures for this 'Magic Lantern' (ML) software from their database. However, in the case of the heuristics, avoiding user notification of ML requires either:
a) a weakening of the heuristic(s), presumably to such an extent that other viruses may penetrate the system or
b) the presence of a special signature in the McAfee software which (on recognizing ML) can 'override' the heuristic
Case (b) is interesting. If McAfee do this with a simple byte pattern search this will immediately provide viruses with a neat little 'binary tag' which permits them to evade McAfee's software
The alternative must be to use a cryptographic hash which can be used to identify ML but which cannot be readily forged by other virus code. Using this checksum technique also demands that the ML 'payload' remain unchanged. Very restrictive for code which needs to be stealthy.
But the most important side-effect of both of these techniques - and any others McAfee might choose to use, would be that it provides an easy route for developers to produce software which can check for ML.
In other words, McAfee cannot both provide useful levels of virus detection and avoid alerting the user to Magic Lantern without giving other developers a blueprint to locate it.
But then you lose the type safety which 'defines' the enumeration - and your example can't possibly compile either.
Your example is more involved than it needs to be because you are doing more than an enum requires.
C#
public enum Direction {North, East, West, South};
Java
public class Direction {
private Direction() { }
public final static Direction NORTH = new Direction();
public final static Direction SOUTH = new Direction();
public final static Direction EAST = new Direction();
public final static Direction WEST = new Direction();
}
I think this is the direct translation of the supplied enumeration. C#'s is much nicer to type, but adds more syntax to the language for very little gain. The power in Java's approach is that if, at any later time I wan't to extend the functionality of Direction I can, as demonstrated by your post where each direction is given a human readable name I don't know much about C# but this doesn't look possible for enums.
With the present financial difficulties for airline operators, it seems highly probable to me that severe cost cutting will have swiftly resulted in reduced aeroplane maintenance and fewer safety checks.
Futhermore money diverted into increased security is money diverted from day-to-day operations. The current climate of fear in the US probably makes accidental crashes more likely.
>How can a US court make a decision regarding enforcement of a foreign court decision?
I don't think it can sensibly.
>Likewise, how can a French court expect to decide the practices of a US company that hosts a site in the US?
Yahoo! is a multinational company with offices in France. Of course the French government have the right to restrict the practices of a company which operates within the jurisdiction of its laws.
If Yahoo! was solely a US concern then your point would be valid, but it isn't. Here is an analogy:
I have dual British-French nationality. If I live in France and host a website from England which is legal in England but not in France, would you expect me to be exempt from French law because I'm also English? Of course not.
So should AOL which is a registered company in both the US and France be exempt from a ruling in French law? Of course not.
In a computer game, the interface AND the environment are determined by the authors. This is why incremental disclosure is so effective. Learning how to use MegaGunX in the fifth level is okay because the designers didn't add GruesomeCreatureZ, the first enemy in the game which can only be killed by that weapon, until level 6.
Application designers on the other hand have only control of the interface. They can't choose to make an advanced feature like mail-merge available only after 50 documents, because the user might find themselves in an environment where they need to use any particular feature 'out of the box'.
What I think JC Hertz is observing is that games must generally include some form of tutorial (which may be part of the game) because games UI's are generally quite distinct. And that furthermore, these tutorials are actually structured as part of the game.
So the proper comparison is between the help in say MS Office and early game levels. With this perspective 'Clippy' can be seen as an attempt to introduce the in-situ learning which games so often provide - an incredibly botched attempt though.
I was aware that latency could limit throughput but I always assumed, it would seem wrongly, that it was negligible.
So for TCP/IP, is packet size the main factor which determines the degree to which latency degrades throughput?
Either you misunderstand or it's a subtle troll...
Latency will delay the start of the video stream (and possibly introduce a delay in control data returned from the client) but once the connection is established and data begins to flow bandwidth is the primary limiting factor.
Good link though.
Of course, it is impossible to judge the veracity of this Australian company's claims without further technical details. One's initial reaction is to dismiss it as untrue (or very partially true) because it is so far beyond the envelope of what is widely known to be possible. But it's important not to be completely dismissive.
While modern compression schemes are quite advanced most only seek to remove a small number of redundancies in an image. Typically they coarsen the color space greatly, the luminesence a little and subsequently seek to look for areas in the frame sequence which can be recognised as a transformation of areas in neighbouring frames.
This has proved very successful but it is certainly not the only technique one might attempt. A long while ago (several years) I turned my attention to the problem of compressing video data and considered the following approach of taking video data and deducing the geometry and surface colour of the physical entities which were filmed. This occurred to me as I result of thinking how easily I as a human can remember certain scenes by knowing the objects involved and their positions rather than remembering the scene in it's entirety.
So imagine an algorithm which when applied to video footage attempts to deduce the geometry of scene elements, and their textures and then record how they moved. Playback would involve a basic kind of 3d rendering followed by a correction stage. All sorts of other techiques could be thrown at this scheme including progressive geometric and colour-map refinements, positional interpolation, even kinematics.
I have no expertise in moving image compression and this idea came to me without much effort. A team of computer scientists and mathematicians would surely come up with something better, but with techniques like the one I outlined above I wonder what kind of quality a 28.8 connection could provide.
On an underpowered machine, it is inevitable that the browsers which are designed to be scalable, and to perform well at larger tasks will be precisely those which perform worst.
I think this trend is clearly apparent in the given rendering (not loading) times. I am not suprised at these high figures, most of it will be accounted by virtual memory paging.
> Java passes primitive types (int, double, char) by value, but Objects by reference
No. I have to set the record straight on this one - I see this confusion frequently. Java passes ALL primitives by value. References are a primitive and are passed by value. This uniformity of method invocation which is not seen in most other C derivatives. This subtlety seems to be lost on most Java programmers.
On the wider topic of passing values vs. references, Java's equivalent of pass by value for objects (since objects are never actually passed as arguments) is to call a clone method on the object to be passed thus:
Dog rover = new Dog();Dog rex = rover.clone();
rex.sit();
Crufts.judge(rover);
Note how the clone method actually produces a distinct reference value (from that stored in rover) to an identical dog. IFAIK Java rarely duplicates any object by bytewise copy, instead, when an object is cloned a fresh object is constructed and populated (however the implementor sees fit) with corresponding values. This provides flexibility but makes cloning very expensive.
To avoid this overhead I think there is a distinct move towards designs which make more use of immutable objects. Combined with a specialist factory pattern this can provide very fast and robust code. Java programs written largely in this mode start to heavily resemble functional programs (with all their benefits).