Sorry, but I live here in NYC, and if Giuliani
was harassed by Microsoft to the point where the
school board was forced to announce a major
switch...those apologetic helicopters would be
swiftly met with a giant surface-to-air toilet
plunger.
What about the flip side of this coin, on which
the above-mentioned students have no inkling that
anything other than Microsoft and Windows even
exists at all?
Or: are you saying that using a Unix machine will
not give the student any marketable skills? I
would be surprised to find a HS graduate with
real knowledge and some school credentials of
Unix not being able to get an entry-level NOC
monkey or Jr. Sys Admin type of job. In fact I
was working as a Jr Sysadmin when I was 15 and
still *IN* high school.
I believe the correct approach is to keep such
proprietary stuff as Microsoft in schools to a
minimum. Not out, but to a minimum. Certainly
there might need to be Windows workstations in
a school lab. But heck, even if *all* the
workstations are Windows, just one monstrous
FreeBSD server for everyone to log into and
run Exceed on their windows desktops -- that's
progress.
Of course, my school wouldn't listen to me when
I suggested the above and offered to implement it
for free. Oh well - their loss.
Which brings us to the real issue: nothing is
going to change until people in charge start
giving a fuck *and* having a clue.
What in the name of god gives a company the right
to dictate what platform can or cannot be used
to run its software?!
Imagine opening a new book one day and reading
"Doubleday grants you the license to read, peruse
or skim the enclosed material, provided you
do so in a SomeBrand(tm)-manufactured reclining
chair, not a couch, a bed, or a reclining chair
made by anone other than SomeBrand."
It's fortunate that no one gives a fuck about
issues like this, so that we don't actually have
to legislate anything and just let big companies
rule the planet, huh? Thank god for Democracy!
The fact of the matter remains that languages
like C++ allow you to overload functions and
other languages like Eiffel do not.
How would *you* go about getting them working
together in the manner that.NET claims/attempts?
If your_lang knows only about subroutine names,
what do you do to make it understand that
foo(int) and foo(char *) are two distinct
functions?
I don't see your point as a score against the
architecture. Sure, it might be a pain in the
ass to call mangled functions sometimes. The
authors of the standard class libraries are
going to exercise proper programming care and
not use function overloading spuriously and
without justification, right?
Well, my understanding anyway: you can use _any_
language - as long as you have a.NET compiler
for it. Said compiler generates code for their
VM - think of it as if you had compilers for
languages other than Java that generated JVM-runnable code. Now you add that there is a
common class format that these compilers can
adhere to. Now you can "write a class in langA,
derive it in langB, and instantiate it in C."
Personally, I am not familiar enough with it to
say whether or not I like it. At first glance
however, it sounds to me like a step in the
right direction.
Sorry, but I live here in NYC, and if Giuliani
was harassed by Microsoft to the point where the
school board was forced to announce a major
switch...those apologetic helicopters would be
swiftly met with a giant surface-to-air toilet
plunger.
What about the flip side of this coin, on which
the above-mentioned students have no inkling that
anything other than Microsoft and Windows even
exists at all?
Or: are you saying that using a Unix machine will
not give the student any marketable skills? I
would be surprised to find a HS graduate with
real knowledge and some school credentials of
Unix not being able to get an entry-level NOC
monkey or Jr. Sys Admin type of job. In fact I
was working as a Jr Sysadmin when I was 15 and
still *IN* high school.
I believe the correct approach is to keep such
proprietary stuff as Microsoft in schools to a
minimum. Not out, but to a minimum. Certainly
there might need to be Windows workstations in
a school lab. But heck, even if *all* the
workstations are Windows, just one monstrous
FreeBSD server for everyone to log into and
run Exceed on their windows desktops -- that's
progress.
Of course, my school wouldn't listen to me when
I suggested the above and offered to implement it
for free. Oh well - their loss.
Which brings us to the real issue: nothing is
going to change until people in charge start
giving a fuck *and* having a clue.
What in the name of god gives a company the right to dictate what platform can or cannot be used to run its software?! Imagine opening a new book one day and reading "Doubleday grants you the license to read, peruse or skim the enclosed material, provided you do so in a SomeBrand(tm)-manufactured reclining chair, not a couch, a bed, or a reclining chair made by anone other than SomeBrand." It's fortunate that no one gives a fuck about issues like this, so that we don't actually have to legislate anything and just let big companies rule the planet, huh? Thank god for Democracy!
The fact of the matter remains that languages like C++ allow you to overload functions and other languages like Eiffel do not. How would *you* go about getting them working together in the manner that .NET claims/attempts?
If your_lang knows only about subroutine names,
what do you do to make it understand that
foo(int) and foo(char *) are two distinct
functions?
I don't see your point as a score against the
architecture. Sure, it might be a pain in the
ass to call mangled functions sometimes. The
authors of the standard class libraries are
going to exercise proper programming care and
not use function overloading spuriously and
without justification, right?
Well, my understanding anyway: you can use _any_ language - as long as you have a .NET compiler
for it. Said compiler generates code for their
VM - think of it as if you had compilers for
languages other than Java that generated JVM-runnable code. Now you add that there is a
common class format that these compilers can
adhere to. Now you can "write a class in langA,
derive it in langB, and instantiate it in C."
Personally, I am not familiar enough with it to
say whether or not I like it. At first glance
however, it sounds to me like a step in the
right direction.
The point is that this was fixed in OpenBSD before the advisory was released.