Java is widely perceived among business people
as mainly a Sun product, and Java development
a Sun-aligned (or, in some circles, an
IBM-aligned) activity. The deep problems in Java
runtime environments have always been there, and
technical staff have been pointing them out since
the beginning. The defects have always been
passed off as teething pains, temporary
immaturities. That even Sun has not been able to
produce industrial-grade runtime environments
after all this time is a ringing endorsement of
the language's critics. (There is no reason to
think that C#, which is essentially the same, will
do any better.)
That Free Software has succeeded so spectacularly
at cross-platform portability, without any of the
extraordinarily expensive and risky apparatus
needed to run Java, demonstrates further that
Java and its apparatus are not necessary to get
the benefits the language has been sold on, and
mainly just mean overhead.
Gross overhead is good for hardware sales, but
only when there's no credible competition from
more efficient alternatives.
In C++, any declaration of two variables in the
same definition statement, as described,
char* x, y;
is bad style. The correct code for the example
given would be
char* x = something;
char y = something else;
You see there is no confusion about the type of
x or y, and no possibility of confusion about
whether x or *x is being assigned/initialized.
Combining the definitions tempts you to leave
out the initializations, which would also be
bad style in C++.
This all matters particularly in C++ because,
unlike in C89, the definitions are mixed in with
other statements. C99 allows the mixing, and you
may expect to see similar rules surface for C99.
borgboy writes: " I can see why you consider this a problem - an oversight on the part of the CLI development team, but you fail to follow through and explain just how this issue makes the CLI unsuitable."
It wasn't an oversight, it was a deliberate choice.
It makes the CLI unsuitable as a language-independent platform because it forces a
choice that is the province of the language
designer. It is just the grossest example of
a detail that makes it impossible to export
libraries written in in common languages in a
natural way. Of course there are myriad more
subtle gotchas with the same effect.
To understand how hard this sort of thing really
is, look at what is done in Gcc so that it is
possible to call and throw exceptions between
C++ and Java. Imagine doing that for languages
that are interestingly different from one another
when you don't even know them. Then consider that
you have to specify portable semantics of dozens
of libraries that have to hide platform differences. It's no wonder this sort of thing
doesn't really work.
It's very clever of MS to promote something that
will appear to be portable, making people feel
safe, but can never really be. They have got
those Mono people completely flummoxed, and the
Mono people are unwittingly helping to flummox
everybody else. We can only hope that people's
experience with Java will prepare them to examine
the C#/Mono details carefully enough not to be
burned again.
Platform-independent runtime environments seem
more interesting than they are because the devil
is in the details. Most of the interesting details
that differ between platforms are not, in fact,
standardized by the *VM and its library, so for
interesting, ambitious programs you only get the
appearance of compile-once / run-anywhere without
the fact.
The range of differences may be seen easily when
you run./configure after unpacking a typical
tarball. Given those differences, the differences
induced by the CPU architecture in the semantics
of (e.g.) C++ are not very significant, and are
easily coded around. The result is that our
familiar tarballs provide better portability
than the *VMs, because when you encounter a
problem, you can fix it, where with a bytecode
file you're just stuck.
The advantages of free software are not just
political, they are bone-crushingly practical.
The promises of *VMs tempt us to forget those
advantages, but we keep getting reminded.
One of the problems with CLI is its arbitrary
choice not to allow languages and libraries to
distinguish mixed-case identifiers.
More precisely, it doesn't allow them to export
mixed-case identifiers; they can use them
internally, but not for interoperability.
It's kind of silly, because they could have just
mandated that languages that don't distinguish
case should export lower-case identifiers, and
then note that libraries that one wants callable
from such languages should only export identifiers
they can see.
Oh well, maybe next time somebody'll get it right.
Karel Capek treated this subject back in 1936,
in The War with the Newts (recommended). The
prospects don't look good for the U.S. Of course,
these subcontractors' fortunes are tied to those
of the U.S. in the short term, but they don't
seem to be acting on the fact, predictably.
In the long term they won't need the U.S. any more, and we will have nothing but Hollywood to
export. The rest of the world might well lose
interest in Hollywood when the U.S. itself is no
longer dominant. (I lost interest myself long
ago.)
What's the difference between "currently planning"
and "planning"? I ask merely for information.
Go to beta.itasoftware.com and do your search.
Pick the itinerary you like, and drill down to
get the exact fare codes, then call the airline
and ask for those tickets.
The only things it won't give you are: "web fares" -- special promotional fares limited to
certain (web) travel agents -- and tricks the airlines try not to allow, like buying two
tickets and using half of each at a time to
avoid weekend stay restrictions and the like.
Of course, never buy a one-way ticket, they always
cost more than throwing away the second half of
a round-trip.
Re:XML frees us from Perl
on
XML and Perl
·
· Score: 1
Arien asked, "how does XML [free us from
doing the kinds of things Perl is meant for]
in, let's say, system administration"
When config files are in XML, they can be munged
programmatically without regexp hackery.
He goes on, "... what type of things is XML made
out of? Elements' names, contents, etc, it's all text."
It's not free-form text, it's structured text.
Somebody else pointed out, though, that there
is a distressingly large amount of free-form
text to be parsed in attribute strings, body
text, and (!) comments, that XML structure
extraction tools don't help with.
(I won't answer criticism of Naggum's rant;
he's not known as a net.kook for nothing. Take it
up with him.)
Re:XML frees us from Perl
on
XML and Perl
·
· Score: 1
Slugbait writes: "...one still has the problem
of merging a non-xml document into xml form."
That's true, but the Perl XML-handling modules
are not much help for that.
XML frees us from Perl
on
XML and Perl
·
· Score: 4, Interesting
The whole point of XML is to free us
from having to do the kinds of things Perl is
meant for. Absent free-form text munging, Perl
really has no advantage over other languages.
At the same time, it has real deficits for people
who need to know they have solved a problem
correctly and completely.
(For reference, see
this rant by the brilliant net.kook Erik Naggum. The most quotable bit, for the lazy
among you, is
...[Perl] rewards
idiotic behavior in a way that no other language or tool has ever done,
and on top of it, it punishes conscientiousness and quality craftsmanship
-- put simply: you can commit any dirty hack in a few minutes in perl,
but you can't write an elegant, maintainabale program that becomes an
asset to both you and your employer; you can make something work, but you
can't really figure out its complete set of failure modes and conditions
of failure. (how do you tell when a regexp has a false positive match?)
If it turns out to work, it will be banned
for use on TV during politicians' speeches. (The
first amendment will be found not to apply.)
Expect to see software that can edit out the
facial gestures, in real time. Politicians will
only release footage that has been filtered by it
in their own offices.
Software that detects that filtering will be
banned.
Relax-NG is a Draft ISO Standard
on
DTD vs. XML Schema
·
· Score: 2, Interesting
I gather that Relax-NG is on track to become
an ISO Standard. Regardless of what happens
with W3C, the ISO's XML schema based on Relax-NG
won't go away. Given its natural advantages
-- including the enormously greater ease of
implementing it -- we might expect to see many
more tools built around it.
It would be somewhat unfortunate if both end up
popular, because it will be more work to maintain
both sets of tools than either one alone. That's
probably what will happen, though, at least in
the short term.
The responses to this report are unusually poor,
even by Slashdot standards.
First, nobody said SCO were enforcing patents.
They said they were enforcing copyright on certain
libraries they publish. There's nothing wrong
with that, except it may be stupid if it drives
customers to way-cheaper alternatives.
Second, even if they were enforcing
patents, and even if the patents have
run out, that doesn't keep them from collecting
from anybody who agreed, before the patents
expired, to continue paying afterwards. Such a
provision is very common in patent license
agreements.
Third, BSD didn't re-implement Unix.
Discovery revealed that Bell Labs had stolen
lots of BSD code (deleting the copyright notices),
which terminally weakened AT&T's case. If the
adversaries had been evenly matched, UCB would
probably have got the whole shebang free and
clear, but as it was they had to let the AT&T
lawyers save face by pulling out five of the
thousands of files as uniquely AT&T property.
It's fun to speculate what we would all be running
if the case had been tried more quickly, or if the
five files had been re-written sooner, or if the
BSDs hadn't had their little fratricidal wars
before they finally learned to get along, more or
less.
Why would anyone want to go to Mars?
It's little more than a deep, deep
hole a long ways off.
We should plan missions to the asteroids.
Everything we will need is in the asteroids, and
the asteroids are the place to colonize someday.
(How much energy would it take to move Cruithne
into Earth orbit?)
Planets, pfft. Traps. They'll all still be there
if somebody ever figures out a good use for them.
They don't even make very good nuke-waste dumps.
(Earth excepted, of course.)
michaelggreer wrote: "You would not want the
event updates fighting with the movie playback"
If some events should have higher priority than
others, your GUI thread should schedule them
properly. It would be a grave design error for
the X server to have to know about threads in
the client, and their relative priority. However,
finding yourself implementing a priority scheduler
in user-space is often an indication that you
have made a wrong turn in your architecture.
Scheduling is what OSes are for.
As an alternative, the client is free to open
multiple connections to the X server, and operate
independent UIs through them. As far as the X
server is concerned, it's talking to independent
clients, something it is very good at.
I find it interesting that whenever people
argue against this feature, they always
abbreviate their examples. Verbosity for
verbosity's sake is not a good thing: if
we all know the type, why should we have
to keep saying it? It doesn't make the
code any safer.
devphil's code above is an example of a
workaround. It was my work to
insist on having typedefs all over the
STL classes, for this purpose. They were
necessary clutter because of a weakness
in the language. They will remain as
not-so-necessary clutter, for backward compatibility.
I don't see any evidence from the article
that anybody was "hurt". Everybody is falling
over themselves pointing out that it looks like
a sensible decision. Even JWZ's diatribe looks
more like a jab at the Mozilla team, for having
such a bloated engine that Apple couldn't use it.
I wrote to Darin Adler, BTW, and he says (my
paraphrase!) that the infection of Qt MOC keywords
in the Safari code is well contained. They don't
use Qt underneath.
ISO Standard 14882 C++ is easier to parse than
ARM C++. The biggest difference is that the
committee eliminated "implicit int" declarations,
which eliminated a lot of ambiguities. Requiring
typename in templates helped too.
(OT) Just wait until you see C++0x. It will
(probably) support variable definitions like
auto iter = some_map.begin();
and figure out a type for iter by looking
at the result type from
map<>::begin().
k98sven wrote: "To quote Richard Feynman (a bona-fide, real scientist(TM)... "
You can't quote the best scientists on this. They're the ones least subject to the failing. (That's a good part of why they're the best, Sagan aside.) Furthermore, this is part
of scientists' training; all scientists will
agree with it as expressed, even when their
behavior contradicts it.
That Feynman had to express this at all is
telling.
Whackos don't have a favorite logical fallacy
(they like them all equally), but debunkers do.
It's called the Argument from Ignorance, and in
its simplest form it goes, "Your evidence for A
is unsatisfactory, therefore not A". Another form
is "You didn't prove A, therefore B".
Classic debunker examples include:
Nobody saw that rock fall out of the sky,
therefore your claim that rocks (ice balls,
frogs) fall out of the sky is false.
Your airplane prototype crashed, therefore
men will never fly.
You haven't produced a half-man/half-ape
fossil, therefore Man is a special creation.
The pattern is that incomplete evidence or
faulty reasoning is taken to disprove the
conclusion, instead of the correct result:
that the status of the conclusion is (was) unknown.
Rocks might or might not fall, Man might or
might not fly, humans and modern apes might or
might not have evolved from a common ancestor.
We don't know if life originated "elsewhere",
We don't know if antimatter repels matter
gravitationally, we don't know if some people
can sense the death of relatives from afar.
We might never know.
Scientists are prone to this fallacy, perhaps
because they are temperamentally uncomfortable
with uncertainty. That's why they became
scientists in the first place. That's also why
saying "I don't know" is considered, among
scientists, so virtuous; it's hard to bring
themselves to say it.
Among scientists, the fallacy manifests most
harmfully when the conventional theory for a
phenomenon is no better supported than the
alternatives. Careers are blighted. Recent
examples from biology that suffered "debunking"
for decades include:
Barbara McClintock's work on corn genetics
Nerve cell replacement in mature vertebrates
Effects of weak electromagnetic fields on
living tissue
Slashdot Mirror
That Free Software has succeeded so spectacularly at cross-platform portability, without any of the extraordinarily expensive and risky apparatus needed to run Java, demonstrates further that Java and its apparatus are not necessary to get the benefits the language has been sold on, and mainly just mean overhead.
Gross overhead is good for hardware sales, but only when there's no credible competition from more efficient alternatives.
This all matters particularly in C++ because, unlike in C89, the definitions are mixed in with other statements. C99 allows the mixing, and you may expect to see similar rules surface for C99.
It wasn't an oversight, it was a deliberate choice. It makes the CLI unsuitable as a language-independent platform because it forces a choice that is the province of the language designer. It is just the grossest example of a detail that makes it impossible to export libraries written in in common languages in a natural way. Of course there are myriad more subtle gotchas with the same effect.
To understand how hard this sort of thing really is, look at what is done in Gcc so that it is possible to call and throw exceptions between C++ and Java. Imagine doing that for languages that are interestingly different from one another when you don't even know them. Then consider that you have to specify portable semantics of dozens of libraries that have to hide platform differences. It's no wonder this sort of thing doesn't really work.
It's very clever of MS to promote something that will appear to be portable, making people feel safe, but can never really be. They have got those Mono people completely flummoxed, and the Mono people are unwittingly helping to flummox everybody else. We can only hope that people's experience with Java will prepare them to examine the C#/Mono details carefully enough not to be burned again.
The range of differences may be seen easily when you run ./configure after unpacking a typical
tarball. Given those differences, the differences
induced by the CPU architecture in the semantics
of (e.g.) C++ are not very significant, and are
easily coded around. The result is that our
familiar tarballs provide better portability
than the *VMs, because when you encounter a
problem, you can fix it, where with a bytecode
file you're just stuck.
The advantages of free software are not just political, they are bone-crushingly practical. The promises of *VMs tempt us to forget those advantages, but we keep getting reminded.
It's kind of silly, because they could have just mandated that languages that don't distinguish case should export lower-case identifiers, and then note that libraries that one wants callable from such languages should only export identifiers they can see.
Oh well, maybe next time somebody'll get it right.
In the long term they won't need the U.S. any more, and we will have nothing but Hollywood to export. The rest of the world might well lose interest in Hollywood when the U.S. itself is no longer dominant. (I lost interest myself long ago.)
Go to beta.itasoftware.com and do your search. Pick the itinerary you like, and drill down to get the exact fare codes, then call the airline and ask for those tickets.
The only things it won't give you are: "web fares" -- special promotional fares limited to certain (web) travel agents -- and tricks the airlines try not to allow, like buying two tickets and using half of each at a time to avoid weekend stay restrictions and the like.
Of course, never buy a one-way ticket, they always cost more than throwing away the second half of a round-trip.
When config files are in XML, they can be munged programmatically without regexp hackery.
He goes on, "... what type of things is XML made out of? Elements' names, contents, etc, it's all text."
It's not free-form text, it's structured text. Somebody else pointed out, though, that there is a distressingly large amount of free-form text to be parsed in attribute strings, body text, and (!) comments, that XML structure extraction tools don't help with.
(I won't answer criticism of Naggum's rant; he's not known as a net.kook for nothing. Take it up with him.)
That's true, but the Perl XML-handling modules are not much help for that.
(For reference, see this rant by the brilliant net.kook Erik Naggum. The most quotable bit, for the lazy among you, is
)If it turns out to work, it will be banned for use on TV during politicians' speeches. (The first amendment will be found not to apply.)
Expect to see software that can edit out the facial gestures, in real time. Politicians will only release footage that has been filtered by it in their own offices.
Software that detects that filtering will be banned.
It would be somewhat unfortunate if both end up popular, because it will be more work to maintain both sets of tools than either one alone. That's probably what will happen, though, at least in the short term.
First, nobody said SCO were enforcing patents. They said they were enforcing copyright on certain libraries they publish. There's nothing wrong with that, except it may be stupid if it drives customers to way-cheaper alternatives.
Second, even if they were enforcing patents, and even if the patents have run out, that doesn't keep them from collecting from anybody who agreed, before the patents expired, to continue paying afterwards. Such a provision is very common in patent license agreements.
Third, BSD didn't re-implement Unix. Discovery revealed that Bell Labs had stolen lots of BSD code (deleting the copyright notices), which terminally weakened AT&T's case. If the adversaries had been evenly matched, UCB would probably have got the whole shebang free and clear, but as it was they had to let the AT&T lawyers save face by pulling out five of the thousands of files as uniquely AT&T property.
It's fun to speculate what we would all be running if the case had been tried more quickly, or if the five files had been re-written sooner, or if the BSDs hadn't had their little fratricidal wars before they finally learned to get along, more or less.
We should plan missions to the asteroids. Everything we will need is in the asteroids, and the asteroids are the place to colonize someday. (How much energy would it take to move Cruithne into Earth orbit?)
Planets, pfft. Traps. They'll all still be there if somebody ever figures out a good use for them. They don't even make very good nuke-waste dumps. (Earth excepted, of course.)
Chances are it won't mean anything. Wait until the appeals courts finish before you pay any attention to this.
If some events should have higher priority than others, your GUI thread should schedule them properly. It would be a grave design error for the X server to have to know about threads in the client, and their relative priority. However, finding yourself implementing a priority scheduler in user-space is often an indication that you have made a wrong turn in your architecture. Scheduling is what OSes are for.
As an alternative, the client is free to open multiple connections to the X server, and operate independent UIs through them. As far as the X server is concerned, it's talking to independent clients, something it is very good at.
devphil's code above is an example of a workaround. It was my work to insist on having typedefs all over the STL classes, for this purpose. They were necessary clutter because of a weakness in the language. They will remain as not-so-necessary clutter, for backward compatibility.
I wrote to Darin Adler, BTW, and he says (my paraphrase!) that the infection of Qt MOC keywords in the Safari code is well contained. They don't use Qt underneath.
There's nothing public I know of. Join! Help!
That's there too. It's more useful for library declarations than for straight coding, but both of the declarations suggested will work.
(OT) Just wait until you see C++0x. It will (probably) support variable definitions like
and figure out a type for iter by looking at the result type from map<>::begin().You can't quote the best scientists on this. They're the ones least subject to the failing. (That's a good part of why they're the best, Sagan aside.) Furthermore, this is part of scientists' training; all scientists will agree with it as expressed, even when their behavior contradicts it.
That Feynman had to express this at all is telling.
Classic debunker examples include:
-
Nobody saw that rock fall out of the sky,
therefore your claim that rocks (ice balls,
frogs) fall out of the sky is false.
-
Your airplane prototype crashed, therefore
men will never fly.
-
You haven't produced a half-man/half-ape
fossil, therefore Man is a special creation.
The pattern is that incomplete evidence or faulty reasoning is taken to disprove the conclusion, instead of the correct result: that the status of the conclusion is (was) unknown. Rocks might or might not fall, Man might or might not fly, humans and modern apes might or might not have evolved from a common ancestor. We don't know if life originated "elsewhere", We don't know if antimatter repels matter gravitationally, we don't know if some people can sense the death of relatives from afar. We might never know.Scientists are prone to this fallacy, perhaps because they are temperamentally uncomfortable with uncertainty. That's why they became scientists in the first place. That's also why saying "I don't know" is considered, among scientists, so virtuous; it's hard to bring themselves to say it.
Among scientists, the fallacy manifests most harmfully when the conventional theory for a phenomenon is no better supported than the alternatives. Careers are blighted. Recent examples from biology that suffered "debunking" for decades include:
Sorry, but for a language, it is. When the vendor flops or gets bought and closed, your code turns to dust. I've seen it happen too many times.
With the number of Free tools that are as good as or much better than CF, their days seem numbered.