"Dynamic Layouts" - Uh, yes this is in Visual Studio
The drag-and-drop pixel-positioning of Visual Studio form design? OK, so you can in principle do better, but most don't.
"Cross Platform Support" - Uh, yes, if you are talking about non-x86 support. Of course it doesn't run on non-Windows platforms. I don't think that makes much sense to create a Windows dev environment that RUNS ON OTHER OPERATING SYSTEMS!!!
(no need to shout!) Why not? There are Windows CE development environments that run on Windows 2000.
The fact is, cross-platform and full-featured IDEs were available decades ago.
"Multi-processing" - Er, what? This makes no sense. If you mean support for multiprocessing in the compilers, or the ability to assign seperate compiles to different processors, then this is supported.
No: I mean a full featured multi-processing language and IDE combination that allows launching of several apps and processes at once, with the ability to follow individual processes, interrupt and resume them.
"The ability to break into an app" - Er, yeah. Um, thats in there. Its in the the debug menu: Attach to process.
And then compile and resume.
"re-compile bits and resume" - Er, yeah. Its been in since VS 5.0.
Its not there. If you have ever tried to deal with run-time bugs in VB6, you are regularly presented with a message that if you proceed with further edits, you will terminate the program. That really is not true compile and resume. Its poor a third-rate substitute. Remember, other languages and IDEs have been doing better than this for decades, so why not Visual Studio? It may be better in VS.Net?
"true object-orientation with inheritance" - Um, that would be a feature of the language, not the development environment. Clueless.
Not clueless, as in Smalltalk (which was the example I presented), the language and development system are one. The separation of language and IDE is arbitrary, and unecessary, as any Smalltalker or LISPer will tell you. Its so primitive.
"the ability to extend the IDE" - Er, yeah. You can do this. This is why so many companies sell VS addins to the IDE.
This is one of my real dislikes of Visual Studio. My impression (I could be wrong) was that it was designed partly as a way to set up a component and extension market for the IDE, not to allow developers to easily extend the IDE themselves. It took years before you could even write components in the main target language of Visual Studio itself: VB. In Smalltalk, you can adapt the debugger if you like, add new features to the process management, do all kinds of things, and then use those in your deployed application. There was a thriving market for home-grown extensions to Digitalk (and other) Smalltalk IDEs in the 80s and early 90s. These could be nothing more than the addition of a few useful menu items, but it was easy and trivial to do. Visual Studio (and many other popular IDEs) restrict freedom.
I mean really, why do people bother posting FUD? Is it for the karma, or are they really clueless?
You may disagree with what I say, and that is fine, but I don't see how it can be labelled either Fear, Uncertainty or Doubt. Its simply a critical comparison of IDEs, and as the Smalltalk market is very small, and I'm certainly not going to do Visual Studio sales any harm(!) I really don't see what the problem is.
Is present in Visual C++, and has been for a while.
But it's not a general Visual Studio thing, which was what was being discussed. Using VB6, you often come across situations where a message appears that what you are about to do will interrupt the debugging and stop the program. This is so unnecessary. IDEs and languages have been doing better than this for decades. Why do developers expect so little?
Visual Studio is an adequate development system, but could have been so much better. In the 80s, Gates was introduced to some really powerful IDEs, such as Digital Smalltalk. He even commented "This is the future". Instead of providing an IDE with dynamic layouts, cross-platform support, multi-processing, the ability to break into an app, re-compile bits and resume, true object-orientation with inheritance, and with the full source code of the IDE and the ability to extend the IDE (this is Smalltalk), we got Visual Basic and Visual Studio. It could, and should, have been so much better.
Visual Basic is a quick-fix language, but left in the hand of an inexpert developer can lead to a buggy unsupportable mess (I have had clean up plenty of such messes). Something like Object Pascal would have been far better, with good type safety, yet high speed, and with true object orientation, not the crippled version of VB6.
The question is: semantics to what? The answer is: the semantics of the meta-data; the semantics of the data itself still stays unclear.
I disagree, as XML IS the meta-data.
In your example:
<x><y type="string">radar</y></x>
You say that 'radar' is a string. Yes, it is, but there is also nothing to stop you adding additional attributes to define the meaning:
<y type="string" objectType="technology">
(This may look verbose, but compressed, repeated tag names and attributes don't matter much in terms of space).
This meta-data and semantics discussion is recursive - after all, who defines the definitions? There is an internationally agreed meta-data standard called the Dublin Core, which can be used in schemas and DTD and namespaces to provide an agreed base for all semantics.
A table is not a class A row is not an object A column is not a property
Good Java and C++ coders aren't saying that. What we are saying is...
A table can be used to store instances of a class A row can be used to store an object A column can be used to store a property
There is nothing inefficient about this - it can be a huge code saver. Instead of tens of lines of JDBC, I can, using Java Data Objects, get a row out using a single 'iterator.next()' call, and the JDO system can cache data for me.
EJBs are nothing to do with database bottlenecks - they are to do with clustering and transactional integrity. There is nothing intrinsically slow about EJBs, just bad design by the coder.
No, XML is concerned with representation (i.e. syntax).
No, XML is semantic. Syntax defines that '<' and >' and '</' are used in XML. The tags include words. Those words can have meaning; hence semantic. Get it? words: meaning.
I agree completely. Fractions like 3/4 always confuse me. If only people would write..
This is not what is being discussed. There is a big difference between '3/4' and...
a,1.5,2,x,zxxx etc. What do these mean? Suppose someone supplies you with a file that has data in columns separated by spaces. Are the spaces simply separators, or are they part of the data? What do tabs mean? What about embedded quotes in text strings? XML is a way to remove this ambiguity.
There's no sensible way to seek ahead in the data stream.
You don't need to. XML can easily be handled serially, with apis such as SAX.
Yes, these problems had never been solved before XML came along.
I never said that. These problems had been solved, but in proprietary ways. XML is a common, agreed standard.
Compressed XML is a very efficient way to transmit data.
Ha ha ha ha ha! My God, you're serious.
Yes - what a laugh - I am. Note the word 'compressed'. The use of (tee hee) repeated text tags (giggle) means that it can (chuckle) be easily compressed (titter) and is small.
XML is a screaming hack.
No. XML is a very carefully designed and widely used specification. You seem to have a bias against usefulness. If you want to use arbitrary and non-portable binary formats, do, but don't expect anyone else to be interested in using that format.
The author is actually actually arguing that tags are syntactic, not semantic.
He seems to be not sure what he is arguing, as far as I can tell. After all, XML is fundamentally a semantic markup, using HTML/SGML syntax. He seems to be arguing that sematics can be indicated by position, and that tags are unecessary and Any agree-upon delimited format will do. I strongly disagree with this.
You can use XML as a syntactical markup, but its rather a waste:
or even better <record>
<id>1</id>
<surname>Surname</surname> </record>
If you do something like this, semantics ARE included in the tags. With the appropriate namespaces and schema/DTD, you can mark up pretty clearly what the data means in a way that just about anyone can understand.
Such as? Curious to hear this. Most people I've talked to say the two are about neck and neck.
For example, you are allowed an 'unsafe context' in.Net, so you are back to using raw pointers as in C - same security and crash problems.
Secondly, you can use the Win32 API directly - same crash possibilities.
You can do unsafe stuff in Java, but only if you write a C library and access it using JNI. By default, there is no 'unsafe' equivalent in Java, which allows things like different apps to share the same VM safely.
The author seems to have many serious misunderstandings about XML.
The fact is that in order for any data interchange to work, the parties must first agree on what data will be exchanged - semantics - and once they do that, there is no need to repeat the tags in each and every record/document being transmitted
A major point of XML is that the semantics should be explicit. If you don't repeat the tags, you reply purely on position to indicate meaning. This is a Bad Thing. For example, it does not allow sparse data in which non-default or null values can be excluded.
Inter-system data exchange requires an agreed-on efficient machine-readable delimited file format.
XML was designed to avoid the issue of 'yet another machine-readable format'. XML can be read reasonably efficiently, but always preserves meaning, ignoring the horrors of character sets and byte order. Compressed XML is a very efficient way to transmit data.
An important part of XML design was that it should allow information to be expressed in a way that is independent of the software that uses it. In this way, it has something in common with SQL. The point of 'human reading and writing' is that in the last resort, you still have you data! It also makes data transfer hugely easier to debug.
There is also a lot of confusion about the order of tags in XML. Its possible to specify in a schema or DTD that some tags are required and should be in a certain order, but its also possible to just not care about order. XML is neutral about this.
Uh, not quite. ActiveX was more a response to JavaScript/Flash/et al. Anything that created a lightweight web app.
Uh, yes quite! ActiveX was exactly and precisely a response to Java - Java Applets that is. The idea was to run embedded binaries in a web browser. ActiveX components would run only on Windows, so they could use the Windows APIs, and so not require a plug-in or pre-installed VM, like Java Applet. ActiveX 'security' was by digital authentication, as against Java's sandbox. ActiveX is not related at all to client-side scripting, as with JavaScript. Microsoft's response to JavaScript was - to support JavaScript..NET is their response to Java (and, for all intents and purposes,.NET is miles ahead of anything MS has ever created in terms of security)..Net is what MS developed when they decided not to support Java client-side. Its pretty good in terms of security, but still has weaknesses when compared to Java.
Do you never hire that person because, hey, he was a law breaker?
if he had shown no remorse for what he did, first denying it, then trying to dismiss it as an irrelevance when proof was found.... no, I would not employ him.
The bottom line here is that the people responsible for the misdeed were let go over a decade ago. The company as a whole has been completly overhauled. The management from top to bottom was shaken up.
Ah! That explains why they are still being prosecuted for illegal practices.
I have been using Microsoft products and following their progress for nearly 30 years (I used some of their Assembler products in the 70s). They have not changed at all.
For those who claim that OSS prevents incompatible forks, there are almost certainly examples of where multiple almost-but-not-quite-the-same implementations of some language or API or whatever exist.
You are right. Examples are successive versions of gcc (some of which would compile the Linux kernel, others would not), the Perl 4 -> Perl 5 transition, and current different implementations of Python. (Python, Jython, and Python on.Net)
Actually, C++ can be slow too - even light object orientation, and doing things like using accessor methods as against direct use of instance variables can slow things down significantly. A key part of good Java is to pick the right VM: the latest Sun or IBM VM (IBMs is particularly fast), and use the -server switch to give priority to code optimisation.
Walk into a software store and see how many cross platform applications you see. Not "applications available on more than one platform",
This is absolute rubbish. Why don't you read what you are replying to? I said 'Most software development'. The number of developers working on shrink-wrapped software is negligible, and always has been. Most applications are server-side finance, MIS, CRM or web-based. Just look at IT Job adverts.
I would encourage you to demonstrate how development effort is not impacted by requiring the development of additional 'portable' libraries to re-implement features available on your target platform but not on alternative platforms
I would encourage you to do some research. The libraries already exist. Java, PHP, Perl, Python, C++, Smalltalk all have full-featured cross-platform libraries.
If use C++, the superb Qt toolkit allows you to write common code and compile for Windows, X11, MacOS/X. If you don't like Qt, use wxWidgets. If you use Java, use Swing, which now has OpenGL acceleration. If you don't like Swing, use SWT which has tighter integration, and even allows ActiveX use.
As for re-implemeting things not available on the target platform, toolkits such as Swing and SWT supply supersets of features. For example, SWT typically provides the additional code to emulate missing components (such as a Tree contron) on less-full-featured platforms such as X11/Motif. This means that the work to 'bring all platforms up to a highest common standard' is already done for you.
I know all this from experience - but it should not have taken much for you to find out all this.
The only really good cross platform applications are the ones who depend on the lowest common denominator across all of the platforms.
I give up. You make statements like this, then when I give examples of applications that are cross-platform and 'best-of-breed', such as Apache and Eclipse, all you can say is 'I haven't tried them'. I expect to discuss things with people who are at least prepared to put some effort into the debate. At least a google search for 'Apache Windows'.
I fully accept that cross-platform code does require additional testing, but I don't accept it requires much if any additional code, as (as I have shown) if you pick the write development system and libraries, that additional code has already been developed for you. I completely refute the idea that cross-platform requires 'exponentially' more work. For most applications (NOT games or shrink-wrapped apps - I mean MOST applications) cross-platform comes with little effort, and with the thoroughly mixed hardware and platform environment that is the typical company, cross-platform should be a primary design goal.
Java was 2 decimal orders of magnitude (ie. 100x) slower
I'm sorry if this sounds harsh, but its not Java that is slower, its your code. Modern Java is regularly benchmarked as being around the same as C++ or Fortran for numerical work.
However, I have seen some numeric Java code run a lot slower than C++ code. The usual reason is the way data structured are coded. If you use Collection classes in Java you will get slow access to your data. If you use Arrays and code carefully, there is no reason for Java to be significantly slower than C++, and certainly not 100x!
That has to be the most nieve statement I've ever seen. This is Microsoft we're talking about. "Sure, use products from your self proclaimed arch enemy Sun" and "Include so much code from 3rd parties that your per unit product cost doubles". That leaves them with the option to writing their own cross-platform toolset, which leaves us back at the original point. It's expensive.
This is completely missing the point. There was a general statement being made that cross-platform development is complex. Of course it isn't. However, if for political reasons, you deliberately choose not to use cross-platform tools, then of course cross-platform development is tricky! This is the case for Microsoft, but its certainly not the case for anyone else, and these days the majority of code that is written IS cross-platform. Most new code is server-side applications, and most of that code uses standard APIs, or portable languages, and can use portable test suites.
Portability for applications gives you mediocre software.
Oh come on, there is no evidence for this. What is mediocre about widely used portable applications like Emacs, Eclipse, Apache, PHP or any of a thousand high-quality programs that run on Linux, Mac, Windows etc.?
What I said about Microsoft's approach to cross-platform was not a troll - they have a perfectly good marketing reason not to write portable code. However, the article seemed to contain an attempt to justify not writing portable code for technical reasons, which don't stand up to scrutiny. If the article had said 'as part of company strategy, we tied our code into Windows' that would at least have been honest, or not self-deluding.
This is all completely irrelevant. A point was being made that cross-platform development made software complex. This is simply just not the case, and no evidence has been given to support this statement. Complexity arises
As for naivety, I say what I do based on actual coding experience
The ability to embed spreadsheets in word processor files, presentations etc etc is becoming vital,
In my experience of teaching supporting, teaching and using office software, this kind of thing was very fashionable a few years ago, but most experienced users don't do it.
Why? Because its a memory hog, and it is extremely version and system dependent. Its a very mixed software world, and not everyone runs Office XP. Far more important than embedding applications is the ability to exchange the information that the applications contain. Imagine the problems trying to send such an embedded document as an e-mail attachment to a machine with unknown software.
Check your facts if you tried to run older versions of MS-DOS and PC-DOS you would get the same error message.
They were not functionally equivalent to the versions of DOS that ran Windows 3. DR-DOS was functionally equivalent (many considered it a better DOS, because if its improved memory handling). The only reason that DR-DOS would not run Windows in the situation being discussed was because of Microsoft put in code to check for the competitor's version of DOS.
The difference between this, and not being able to run on simpler versions of DOS is, of course, obvious.
This doesn't refute the main point that cross-platform support is incredibly expensive to implement and test.
This is certainly not true now, and has never really been the case. Now, you use Java: cross-platform support is almost no effort at all. Before Java became fast enough for general use, you could have used C++ (or a variety of other languages) with cross-platform libraries and APIs such as TK.
it increases complexity of a project exponentially, and it increases the number of unknowns in a project appreciably.
Again, this is just not true. You let other people (the suppliers of the cross-platform libraries) do the work. There may be some increase, but its nonsense to say its 'exponential'.
This doesn't mean that you don't write code that CAN be portable, it means it isn't a goal of your project.
Unless you are doing something highly specific (like insisting that something non-portable like COM is involved in your application), its hard to see exactly why non-portability should not be a goal - its a good investment both for the developer and customer. Of course, Microsoft has other motives.
Slashdot Mirror
"Dynamic Layouts" - Uh, yes this is in Visual Studio
The drag-and-drop pixel-positioning of Visual Studio form design? OK, so you can in principle do better, but most don't.
"Cross Platform Support" - Uh, yes, if you are talking about non-x86 support. Of course it doesn't run on non-Windows platforms. I don't think that makes much sense to create a Windows dev environment that RUNS ON OTHER OPERATING SYSTEMS!!!
(no need to shout!) Why not? There are Windows CE development environments that run on Windows 2000.
The fact is, cross-platform and full-featured IDEs were available decades ago.
"Multi-processing" - Er, what? This makes no sense. If you mean support for multiprocessing in the compilers, or the ability to assign seperate compiles to different processors, then this is supported.
No: I mean a full featured multi-processing language and IDE combination that allows launching of several apps and processes at once, with the ability to follow individual processes, interrupt and resume them.
"The ability to break into an app" - Er, yeah. Um, thats in there. Its in the the debug menu: Attach to process.
And then compile and resume.
"re-compile bits and resume" - Er, yeah. Its been in since VS 5.0.
Its not there. If you have ever tried to deal with run-time bugs in VB6, you are regularly presented with a message that if you proceed with further edits, you will terminate the program. That really is not true compile and resume. Its poor a third-rate substitute. Remember, other languages and IDEs have been doing better than this for decades, so why not Visual Studio? It may be better in VS.Net?
"true object-orientation with inheritance" - Um, that would be a feature of the language, not the development environment. Clueless.
Not clueless, as in Smalltalk (which was the example I presented), the language and development system are one. The separation of language and IDE is arbitrary, and unecessary, as any Smalltalker or LISPer will tell you. Its so primitive.
"the ability to extend the IDE" - Er, yeah. You can do this. This is why so many companies sell VS addins to the IDE.
This is one of my real dislikes of Visual Studio. My impression (I could be wrong) was that it was designed partly as a way to set up a component and extension market for the IDE, not to allow developers to easily extend the IDE themselves. It took years before you could even write components in the main target language of Visual Studio itself: VB. In Smalltalk, you can adapt the debugger if you like, add new features to the process management, do all kinds of things, and then use those in your deployed application. There was a thriving market for home-grown extensions to Digitalk (and other) Smalltalk IDEs in the 80s and early 90s. These could be nothing more than the addition of a few useful menu items, but it was easy and trivial to do. Visual Studio (and many other popular IDEs) restrict freedom.
I mean really, why do people bother posting FUD? Is it for the karma, or are they really clueless?
You may disagree with what I say, and that is fine, but I don't see how it can be labelled either Fear, Uncertainty or Doubt. Its simply a critical comparison of IDEs, and as the Smalltalk market is very small, and I'm certainly not going to do Visual Studio sales any harm(!) I really don't see what the problem is.
When someone does gnome libs that miss out the CORBA stuff, so that it flies without taking 128MB to do nothing at all, evolution might be runnable.
Then don't use Gnome, use the Motif version of eclipse.
Is present in Visual C++, and has been for a while.
But it's not a general Visual Studio thing, which was what was being discussed. Using VB6, you often come across situations where a message appears that what you are about to do will interrupt the debugging and stop the program. This is so unnecessary. IDEs and languages have been doing better than this for decades. Why do developers expect so little?
Visual Studio is an adequate development system, but could have been so much better. In the 80s, Gates was introduced to some really powerful IDEs, such as Digital Smalltalk. He even commented "This is the future". Instead of providing an IDE with dynamic layouts, cross-platform support, multi-processing, the ability to break into an app, re-compile bits and resume, true object-orientation with inheritance, and with the full source code of the IDE and the ability to extend the IDE (this is Smalltalk), we got Visual Basic and Visual Studio. It could, and should, have been so much better.
Visual Basic is a quick-fix language, but left in the hand of an inexpert developer can lead to a buggy unsupportable mess (I have had clean up plenty of such messes). Something like Object Pascal would have been far better, with good type safety, yet high speed, and with true object orientation, not the crippled version of VB6.
The question is: semantics to what? The answer is: the semantics of the meta-data; the semantics of the data itself still stays unclear.
I disagree, as XML IS the meta-data.
In your example:
<x><y type="string">radar</y></x>
You say that 'radar' is a string. Yes, it is, but there is also nothing to stop you adding additional attributes to define the meaning:
<y type="string" objectType="technology">
(This may look verbose, but compressed, repeated tag names and attributes don't matter much in terms of space).
This meta-data and semantics discussion is recursive - after all, who defines the definitions? There is an internationally agreed meta-data standard called the Dublin Core, which can be used in schemas and DTD and namespaces to provide an agreed base for all semantics.
A table is not a class
A row is not an object
A column is not a property
Good Java and C++ coders aren't saying that. What we are saying is...
A table can be used to store instances of a class
A row can be used to store an object
A column can be used to store a property
There is nothing inefficient about this - it can be a huge code saver. Instead of tens of lines of JDBC, I can, using Java Data Objects, get a row out using a single 'iterator.next()' call, and the JDO system can cache data for me.
EJBs are nothing to do with database bottlenecks - they are to do with clustering and transactional integrity. There is nothing intrinsically slow about EJBs, just bad design by the coder.
No, XML is concerned with representation (i.e. syntax).
No, XML is semantic. Syntax defines that '<' and >' and '</' are used in XML. The tags include words. Those words can have meaning; hence semantic. Get it? words: meaning.
I agree completely. Fractions like 3/4 always confuse me. If only people would write..
This is not what is being discussed. There is a big difference between '3/4' and...
a,1.5,2,x,zxxx etc. What do these mean? Suppose someone supplies you with a file that has data in columns separated by spaces. Are the spaces simply separators, or are they part of the data? What do tabs mean? What about embedded quotes in text strings? XML is a way to remove this ambiguity.
There's no sensible way to seek ahead in the data stream.
You don't need to. XML can easily be handled serially, with apis such as SAX.
Yes, these problems had never been solved before XML came along.
I never said that. These problems had been solved, but in proprietary ways. XML is a common, agreed standard.
Compressed XML is a very efficient way to transmit data.
Ha ha ha ha ha! My God, you're serious.
Yes - what a laugh - I am. Note the word 'compressed'. The use of (tee hee) repeated text tags (giggle) means that it can (chuckle) be easily compressed (titter) and is small.
XML is a screaming hack.
No. XML is a very carefully designed and widely used specification. You seem to have a bias against usefulness. If you want to use arbitrary and non-portable binary formats, do, but don't expect anyone else to be interested in using that format.
The author is actually actually arguing that tags are syntactic, not semantic.
o rd >
He seems to be not sure what he is arguing, as far as I can tell. After all, XML is fundamentally a semantic markup, using HTML/SGML syntax. He seems to be arguing that sematics can be indicated by position, and that tags are unecessary and Any agree-upon delimited format will do. I strongly disagree with this.
You can use XML as a syntactical markup, but its rather a waste:
<record><data>1</data><data>Surname</data></rec
This is just silly, and is no better than CSV, but seems to be the kind of thing the author is arguing for; positional markup in some format.
Its far better to have an XML schema that includes semantics:
<record>
<data type="int" name="id">1</data>
<data type="String" name="Surname">Surname</data>
</record>
or even better
<record>
<id>1</id>
<surname>Surname</surname>
</record>
If you do something like this, semantics ARE included in the tags. With the appropriate namespaces and schema/DTD, you can mark up pretty clearly what the data means in a way that just about anyone can understand.
And if they self-destructed explosively....
They will supply a DVD with DRM for the sound effects
Such as? Curious to hear this. Most people I've talked to say the two are about neck and neck.
.Net, so you are back to using raw pointers as in C - same security and crash problems.
For example, you are allowed an 'unsafe context' in
Secondly, you can use the Win32 API directly - same crash possibilities.
You can do unsafe stuff in Java, but only if you write a C library and access it using JNI. By default, there is no 'unsafe' equivalent in Java, which allows things like different apps to share the same VM safely.
Use Open Office? unzip that .sxw or .sxc file, and what do you see? XML.
You probably use XML a lot without knowing it.
The author seems to have many serious misunderstandings about XML.
The fact is that in order for any data interchange to work, the parties must first agree on what data will be exchanged - semantics - and once they do that, there is no need to repeat the tags in each and every record/document being transmitted
A major point of XML is that the semantics should be explicit. If you don't repeat the tags, you reply purely on position to indicate meaning. This is a Bad Thing. For example, it does not allow sparse data in which non-default or null values can be excluded.
Inter-system data exchange requires an agreed-on efficient machine-readable delimited file format.
XML was designed to avoid the issue of 'yet another machine-readable format'. XML can be read reasonably efficiently, but always preserves meaning, ignoring the horrors of character sets and byte order. Compressed XML is a very efficient way to transmit data.
An important part of XML design was that it should allow information to be expressed in a way that is independent of the software that uses it. In this way, it has something in common with SQL. The point of 'human reading and writing' is that in the last resort, you still have you data! It also makes data transfer hugely easier to debug.
There is also a lot of confusion about the order of tags in XML. Its possible to specify in a schema or DTD that some tags are required and should be in a certain order, but its also possible to just not care about order. XML is neutral about this.
Uh, not quite. ActiveX was more a response to JavaScript/Flash/et al. Anything that created a lightweight web app.
.NET is their response to Java (and, for all intents and purposes, .NET is miles ahead of anything MS has ever created in terms of security). .Net is what MS developed when they decided not to support Java client-side. Its pretty good in terms of security, but still has weaknesses when compared to Java.
Uh, yes quite! ActiveX was exactly and precisely a response to Java - Java Applets that is. The idea was to run embedded binaries in a web browser. ActiveX components would run only on Windows, so they could use the Windows APIs, and so not require a plug-in or pre-installed VM, like Java Applet. ActiveX 'security' was by digital authentication, as against Java's sandbox. ActiveX is not related at all to client-side scripting, as with JavaScript. Microsoft's response to JavaScript was - to support JavaScript.
He wears a black hat...
Its OK. Its a baseball cap, and he wears it backwards.
The Java HotSpot optimiser should automatically inline accessor methods, but there is no harm in avoiding them where possible.
Do you never hire that person because, hey, he was a law breaker?
if he had shown no remorse for what he did, first denying it, then trying to dismiss it as an irrelevance when proof was found.... no, I would not employ him.
The bottom line here is that the people responsible for the misdeed were let go over a decade ago. The company as a whole has been completly overhauled. The management from top to bottom was shaken up.
Ah! That explains why they are still being prosecuted for illegal practices.
I have been using Microsoft products and following their progress for nearly 30 years (I used some of their Assembler products in the 70s). They have not changed at all.
For those who claim that OSS prevents incompatible forks, there are almost certainly examples of where multiple almost-but-not-quite-the-same implementations of some language or API or whatever exist.
.Net)
You are right. Examples are successive versions of gcc (some of which would compile the Linux kernel, others would not), the Perl 4 -> Perl 5 transition, and current different implementations of Python. (Python, Jython, and Python on
Actually, C++ can be slow too - even light object orientation, and doing things like using accessor methods as against direct use of instance variables can slow things down significantly. A key part of good Java is to pick the right VM: the latest Sun or IBM VM (IBMs is particularly fast), and use the -server switch to give priority to code optimisation.
Walk into a software store and see how many cross platform applications you see. Not "applications available on more than one platform",
This is absolute rubbish. Why don't you read what you are replying to? I said 'Most software development'. The number of developers working on shrink-wrapped software is negligible, and always has been. Most applications are server-side finance, MIS, CRM or web-based. Just look at IT Job adverts.
I would encourage you to demonstrate how development effort is not impacted by requiring the development of additional 'portable' libraries to re-implement features available on your target platform but not on alternative platforms
I would encourage you to do some research. The libraries already exist. Java, PHP, Perl, Python, C++, Smalltalk all have full-featured cross-platform libraries.
If use C++, the superb Qt toolkit allows you to write common code and compile for Windows, X11, MacOS/X. If you don't like Qt, use wxWidgets. If you use Java, use Swing, which now has OpenGL acceleration. If you don't like Swing, use SWT which has tighter integration, and even allows ActiveX use.
As for re-implemeting things not available on the target platform, toolkits such as Swing and SWT supply supersets of features. For example, SWT typically provides the additional code to emulate missing components (such as a Tree contron) on less-full-featured platforms such as X11/Motif. This means that the work to 'bring all platforms up to a highest common standard' is already done for you.
I know all this from experience - but it should not have taken much for you to find out all this.
The only really good cross platform applications are the ones who depend on the lowest common denominator across all of the platforms.
I give up. You make statements like this, then when I give examples of applications that are cross-platform and 'best-of-breed', such as Apache and Eclipse, all you can say is 'I haven't tried them'. I expect to discuss things with people who are at least prepared to put some effort into the debate. At least a google search for 'Apache Windows'.
I fully accept that cross-platform code does require additional testing, but I don't accept it requires much if any additional code, as (as I have shown) if you pick the write development system and libraries, that additional code has already been developed for you. I completely refute the idea that cross-platform requires 'exponentially' more work. For most applications (NOT games or shrink-wrapped apps - I mean MOST applications) cross-platform comes with little effort, and with the thoroughly mixed hardware and platform environment that is the typical company, cross-platform should be a primary design goal.
Java was 2 decimal orders of magnitude (ie. 100x) slower
I'm sorry if this sounds harsh, but its not Java that is slower, its your code. Modern Java is regularly benchmarked as being around the same as C++ or Fortran for numerical work.
However, I have seen some numeric Java code run a lot slower than C++ code. The usual reason is the way data structured are coded. If you use Collection classes in Java you will get slow access to your data. If you use Arrays and code carefully, there is no reason for Java to be significantly slower than C++, and certainly not 100x!
That has to be the most nieve statement I've ever seen. This is Microsoft we're talking about. "Sure, use products from your self proclaimed arch enemy Sun" and "Include so much code from 3rd parties that your per unit product cost doubles". That leaves them with the option to writing their own cross-platform toolset, which leaves us back at the original point. It's expensive.
This is completely missing the point. There was a general statement being made that cross-platform development is complex. Of course it isn't. However, if for political reasons, you deliberately choose not to use cross-platform tools, then of course cross-platform development is tricky! This is the case for Microsoft, but its certainly not the case for anyone else, and these days the majority of code that is written IS cross-platform. Most new code is server-side applications, and most of that code uses standard APIs, or portable languages, and can use portable test suites.
Portability for applications gives you mediocre software.
Oh come on, there is no evidence for this. What is mediocre about widely used portable applications like Emacs, Eclipse, Apache, PHP or any of a thousand high-quality programs that run on Linux, Mac, Windows etc.?
What I said about Microsoft's approach to cross-platform was not a troll - they have a perfectly good marketing reason not to write portable code. However, the article seemed to contain an attempt to justify not writing portable code for technical reasons, which don't stand up to scrutiny. If the article had said 'as part of company strategy, we tied our code into Windows' that would at least have been honest, or not self-deluding.
This is all completely irrelevant. A point was being made that cross-platform development made software complex. This is simply just not the case, and no evidence has been given to support this statement. Complexity arises
As for naivety, I say what I do based on actual coding experience
The ability to embed spreadsheets in word processor files, presentations etc etc is becoming vital,
In my experience of teaching supporting, teaching and using office software, this kind of thing was very fashionable a few years ago, but most experienced users don't do it.
Why? Because its a memory hog, and it is extremely version and system dependent. Its a very mixed software world, and not everyone runs Office XP. Far more important than embedding applications is the ability to exchange the information that the applications contain. Imagine the problems trying to send such an embedded document as an e-mail attachment to a machine with unknown software.
Check your facts if you tried to run older versions of MS-DOS and PC-DOS you would get the same error message.
They were not functionally equivalent to the versions of DOS that ran Windows 3. DR-DOS was functionally equivalent (many considered it a better DOS, because if its improved memory handling). The only reason that DR-DOS would not run Windows in the situation being discussed was because of Microsoft put in code to check for the competitor's version of DOS.
The difference between this, and not being able to run on simpler versions of DOS is, of course, obvious.
This doesn't refute the main point that cross-platform support is incredibly expensive to implement and test.
This is certainly not true now, and has never really been the case. Now, you use Java: cross-platform support is almost no effort at all. Before Java became fast enough for general use, you could have used C++ (or a variety of other languages) with cross-platform libraries and APIs such as TK.
it increases complexity of a project exponentially, and it increases the number of unknowns in a project appreciably.
Again, this is just not true. You let other people (the suppliers of the cross-platform libraries) do the work. There may be some increase, but its nonsense to say its 'exponential'.
This doesn't mean that you don't write code that CAN be portable, it means it isn't a goal of your project.
Unless you are doing something highly specific (like insisting that something non-portable like COM is involved in your application), its hard to see exactly why non-portability should not be a goal - its a good investment both for the developer and customer. Of course, Microsoft has other motives.