We've already figured out how to manage software projects. We've understood what works and what doesn't for at least a couple of decades. The field is fairly well researched
Once software size exceeds a single person's
mental capabilities (probably between one to
five thousand lines of code), the overall quality
drops significantly. With what we know today,
a good programmer and a team of testers can
probably produce a literally bug-free 1,000
line program given enough time. However, that
hasn't scaled well at all. Commercial software
will routinely ship with dozens, hundreds, or
even thousands of bugs unfixed.
Another major area is scheduling. We have not
figured out how to predict how long a development
task (particularly the debugging activities)
will take. Once you realize that the
construction industry can often estimate tasks
to the hour, you'll understand how far we have
to go. A software manager is lucky if he can
nail the month.
3) plus they could embed all sort of copy protection into it as any physical disk publisher can do.
This would be a real pain, and would be one strong
reason for me to demand a pressed CD. CD-Rs are
significantly less reliable, and not being able
to back it up can cause real inconveniences.
And you missed one: it's much easier to keep
a kiosk updated with the most recent versions
of software, than to restock shelves. Today,
the first thing you should do after installing
shrinkwrap software is to apply patches, and
this concept eliminates that.
Yes, Linux distro vendors usually bundle as many
browsers as they legally can, to increase user
choice. The point was, however, that Microsoft
bundling only IE is not nearly as harmful as
preventing OEMs from pre-installing Netscape as
well.
I support Microsoft's right to bundle anything
into their OS*. It's not the job of a court to
determine what belongs and what doesn't belong
in an OS, especially when competing desktop
environments like MacOS X and KDE (and maybe
Gnome as well) eventually include reusable HTML
components. Not arguing this also removes
Microsoft's annoying right-to-innovate defense.
What should rightly be illegal is when they use
their Windows monopoly to pressure OEMs into
precluding competition to them. An OEM who
pre-installs additional software is clearly
giving consumers more choice, and any action
to counter that clearly deprives consumers,
which is exactly what anti-trust laws are
about.
* In fact, for a hypothetical Microsoft brand
computer, I think I might even support their
right to ship it only with Microsoft software.
Actually, it's both the bundling and the
bullying of the OEMs.
Obviously, Microsoft did both, so any effects
we see today are due to both.
However, at the time, Netscape had a 70%
market share, and if Netscape was available
in pre-installed form as prominently as IE
was, I argue that it would not have declined
nearly as quickly.
In that alternate universe, Netscape would
probably still lose in the end, but due
mostly to dropping the 4.x code base to do
a rewrite. This is why I say it's not the
IE bundling, but the bullying that changed
the reason why Netscape died.
The Linux distributions, for example, bundle to increase user choice. Microsoft bundles applications to decrease user choice.
How can the same action result in two opposite
outcomes?
Because what actually reduced user choice in
Microsoft's case is not bundling (which in fact
increases choice), but its other actions,
such as preventing OEMs from also bundling
Netscape.
In fact, if Microsoft had allowed Netscape to
ship with OEM PCs, provided a start-up option
to choose Netscape or IE as the default
browser, and actually respected that setting
even in its own software (when launching a
HTTP link from email, for example), then I
don't think many people will disagree that
it'd be a rather fair fight. A monopoly is
required to bend over backwards like that for
a competitor.
It's not the "bundling" at all, and I'm only
explaining all this because you were
wondering:
Why is this do difficult for many people to understand?
There are still places that hire based on demonstrable skills
Where? I'm sure a good answer to this question
will be moderated +50 if possible. Or are you
just presuming that there must be such places?
people don't know how to apply and demonstrate how their skills are relevant to the job at hand.
When was the last time you looked for a job
in the computer industry, without a degree,
and got one? Today, every job (in the SF bay
area, at least) gets a thousand related and
unrelated resumes, and employers simply resort
to hiring people they know. Failing that, a
quick way to discard many of them is to
exclude non CS majors.
From personal experience, I'd be lucky to get
an autoresponse from even jobs that are I've
been doing. I have a job now, but the first
contact came from someone I knew, not a
resume drop.
Have you actually tried what you propose,
and succeeded? If so, I'm sure it'd be
helpful if you can relate how your new
employer picked your resume out of a thousand
essentially random ones.
Although I've taken a bunch of programming courses over the years (mostly after I graduated from college and was already a professional programmer) and appreciate what I learned from them, it is most assuredly NOT critical to have a degree in computer science to be a professional programmer.
As a professional engineer with two computer
science degrees, I cannot agree more. However,
that's not what I said. What I said was that
you'd have difficulty getting job interviews if
you didn't have a closely related degree. If
you somehow get the job, you don't need the
degree to be a productive contributor.
It's a comment on the state of the job market,
not the relevance of CS education on software
engineer careers.
he can't believe he wasted so much time studying CS in school. Now he's got a skillset limited to computers
Programming is a highly specialized skill. As
with any specialized skills, it requires...
specialists.
he could have studied basket weaving in
college and still learned enough to be a good
programmer from on-the-job experience.
I seriously doubt he'd even get an interview
today, much less on-the-job experience, without an
engineering major of some sort.
Everything you say makes great sense in theory,
and I wish I lived in a world where talent and
drive alone gets you jobs.
"Study what you want" is great if you can afford
it.
I wrote in C before the ANSI and ISO
standards. Is my code not C now?
Using my rigid definition [that plain "C" should
refer to ANSI/ISO C], prior to 1989, it was C.
After 1989, it's "K&R C".
Obviously, this distinction isn't generally
important, and K&R C is in fact largely similar
to ANSI/ISO C. However, the context of this
thread refers to "C compilers" with no floating
point and recursion. This makes the distinction
more important, because many C programmers have
never worked in such environments, and most C
programs will not work on them.
nobody [...] demands that minor language deviations (i.e. K&R and others) must be termed "C-like" in the course of informal discussions
One last time.
We're not talking about K&R C, which is already
significantly different from ANSI/ISO C
(prototypes, argument declarations). We're
talking about dialects that remove fundamental
data types and most or all of the standard
library.
When it is easier to convert an ANSI/ISO C
program into C++ than into one of these 8-bit
dialects, I think it qualifies as a separate
language. If not, then certainly C++ should
also be considered "C"!
semantic rigidity on your part isn't going
to win you this argument.
How exactly does one "win" a Slashdot
argument anyway? Especially when your
opponent resorts to proof by repeated
assertions, and simply claims that accuracy
is unimportant? Well, yes, if accuracy isn't
important, C++, Java, and C# are all just
C.
You remain as wrong as ever; C is perfectly
suited to 8-bit development.
So is C++, once you strip out exceptions,
templates, virtual functions, floating point,
recursion, and so on. How is that a useful
statement?
A compiler that takes code which is
recognizably C is C. Period. Not ANSI C or
even standards compliant, granted, but C
nonetheless.
This definition is both logically inconsistent
and subjective.
Using it, you don't know if "valid C code"
will even compile under a "C compiler", when
it should in fact be at least generally true.
In fact, you have no basis to say what is
"valid C code" at all.
It also requires a human to "recognize" the
language. Different people will yield
different answers, and you'll get this sort
of silly "is too C, is not C" arguments.
Why not just use plain "C" to refer to the ISO
standard, and "C-like" or "a dialect of C" to
refer to the others? This definition does not
suffer either drawback.
Use W3c's validator [to test CSS2 pages
without standards-compliant browsers].
Are you serious? The Validator checks for
standard compliance. A browser actually shows
you what you've created. You really don't
think that little detail (actually seeing your
web page rendered) is important?
I highly doubt anyone gives a rat's ass about
selling their souls if they get to live the
American Dream.
First of all, there are other ways to achieve
the American Dream. Secondly, there are people
who stick to their principles, despite not
achieving it. I don't know how you base your
extrapolation, but perhaps you're overreaching.
Want to talk price fixing, go buy some
gas.
Ahh, so shoplifting is okay because it's not
really murder?
It's not really C that you're referring to, it's the way most compilers use the stack. [...] All of this requires call-tree analysis, which precludes recursion.
If it precludes recursion, then it's not C.
Don't change the definition to suit your
argument, because C is an international
standard.
C is, in fact, a poor match for an 8-bit
machine with minimal memory. C requires an
'int' type of at least 16 bits, a 'long'
type of at least 32 bits, and a couple of
floating point types - all royal pains to
implement on an 8-bit CPU. Furthermore, a
"hosted implementation" of C (which is
really the minimum if you are planning any
sort of porting) requires a sizable standard
library, in which printf() probably will
take up 4 KB of code space all by itself.
In fact, it's those stripped down dialects of
C that really fit the "it's not really C that
you're referring to" comment.
And it has this sexy brushed-metal look that most OSX application created by Apple have.
Actually, that's where Apple is being stupid.
Apple violated its own user interface guidelines,
which restricted the brushed metal look to
interfaces that mimicked real world devices,
like a VCR or stereo.
Having started the trend, it won't be long
before more and more third party tools pick
it up (to be cool, you know), and the look
gets diluted.
Unless web designers get a clue and stop designing only for IE, and until IE is standards compliant too, making your browser W3c compliant doesn't help much.
Your excuses are rather flimsy.
How exactly would web designers test these
CSS2 pages, unless at least some browsers are
standards compliant?
As for IE, if market minority browsers that
benefit most from standardization can't be
bothered to fully support CSS2/DOM, why do
you even expect the market leader to move?
There is no chicken and egg problem, and
there is no choice. Minority browsers
must support standards first. The
best way to get web designers to support
any other browser at all is if they can
support most or all non-IE browsers with
a single effort.
Each different browser can have a different
document object model (lowercase). Document
Object Model (uppercase), on the other hand,
is a W3C standard API that allows you to access
different document object models in the same
way.
The creator does not need to be tied to the creation, they can exist, and succeed or fail independently.
That doesn't change the fact that artistic merit
alone does not determine its Darwinian success.
Invaders have frequently destroyed the artworks
of the losing nation, regardless of merit. Many
extremely successful works of art receive a
disproportionate amount of attention due to
other qualities. Today, basically any Picasso
painting would be worth a lot, whether or not
Picasso himself even liked that work.
So yes, I can in fact discuss the merits of a
CPU design independently of its market success.
the x86 is in many ways a better architecture than RISC. [...]
Your arguments might have been convincing if
you hadn't defeated it yourself in the end:
I think the 68k architecture would be amenable to similar success
Exactly. In fact, that chip would still be
more pleasant to program than the x86,
because of its orthogonality.
Your real conclusion is that a hybrid, where
CISCy instruction sets are used to save memory
and bus bandwidth, and a RISCy core actually
executes mini-instructions, achieves the best
performance today. That's not a matter of
discussion or dispute, but hindsight.
Unfortunately, it also doesn't excuse Intel's
initial architectural choices.
You see, the x86 instruction set is really
just a compression scheme [...]
You don't seriously think that Intel had much
of an idea how they were going to implement
the P6 when they were designing the 8086,
do you? What you describe is an afterthought.
Whether or not x86 instructions had that
effect, Intel was stuck with it because of
Microsoft operating systems and existing x86
applications.
More importantly, the triumph of the x86 does
not reflect the triumph of CISC as a philosophy.
In fact, implementing frequently used
instructions in silicon, and uncommon ones in
microcode is a step towards RISC (the next
step is removing them altogether). Going to
a RISC core is another. Basically, if the
CISC philosophy was extended to its logical
conclusion, today we'd probably have a
single instruction to encode a song into MP3
format. Yet, the last major revision to
the instruction set is probably the MMX
(around 1997), and before that the 80386
(around 1985).
No, the triumph of the x86 reflects the
flexibility of Intel engineers. Although
their chip represented many of what was wrong
with CISC, they borrowed ideas where they
could, and invented where they could not
borrow. They weren't tied down by which
ideas were RISCy and which were CISCy, and
the market rewarded them handsomely.
None of these, however, support your thesis that the
x86 is a "better" architecture, as the word
is commonly used by students of computer
architecture.
I don't know of any other sense [other than
Darwinian] you should be using.
Many of our greatest artists lived and died
without money, fame, or sometimes even children.
In just about every Darwinian sense, they are
failures. The extent to which they enriched
our collective cultural heritage did little
for them.
Similarly, I don't automatically consider
people who make more money or have more
children than I do as better people.
Slashdot Mirror
You should almost never need to cast to (void *) in C. For example,
will always work, no matter what type of pointer q is. If you want to assign q to a type other than void *, then you'll need to cast:C++ has different rules regarding void *.Once software size exceeds a single person's mental capabilities (probably between one to five thousand lines of code), the overall quality drops significantly. With what we know today, a good programmer and a team of testers can probably produce a literally bug-free 1,000 line program given enough time. However, that hasn't scaled well at all. Commercial software will routinely ship with dozens, hundreds, or even thousands of bugs unfixed.
Another major area is scheduling. We have not figured out how to predict how long a development task (particularly the debugging activities) will take. Once you realize that the construction industry can often estimate tasks to the hour, you'll understand how far we have to go. A software manager is lucky if he can nail the month.
Not yet. The $999 iBook and all CRT iMacs still ship with CD-ROM drives. More importantly, I don't have a DVD-ROM drive yet.
This would be a real pain, and would be one strong reason for me to demand a pressed CD. CD-Rs are significantly less reliable, and not being able to back it up can cause real inconveniences.
And you missed one: it's much easier to keep a kiosk updated with the most recent versions of software, than to restock shelves. Today, the first thing you should do after installing shrinkwrap software is to apply patches, and this concept eliminates that.
Yes, Linux distro vendors usually bundle as many browsers as they legally can, to increase user choice. The point was, however, that Microsoft bundling only IE is not nearly as harmful as preventing OEMs from pre-installing Netscape as well.
I support Microsoft's right to bundle anything into their OS*. It's not the job of a court to determine what belongs and what doesn't belong in an OS, especially when competing desktop environments like MacOS X and KDE (and maybe Gnome as well) eventually include reusable HTML components. Not arguing this also removes Microsoft's annoying right-to-innovate defense.
What should rightly be illegal is when they use their Windows monopoly to pressure OEMs into precluding competition to them. An OEM who pre-installs additional software is clearly giving consumers more choice, and any action to counter that clearly deprives consumers, which is exactly what anti-trust laws are about.
* In fact, for a hypothetical Microsoft brand computer, I think I might even support their right to ship it only with Microsoft software.
Obviously, Microsoft did both, so any effects we see today are due to both.
However, at the time, Netscape had a 70% market share, and if Netscape was available in pre-installed form as prominently as IE was, I argue that it would not have declined nearly as quickly.
In that alternate universe, Netscape would probably still lose in the end, but due mostly to dropping the 4.x code base to do a rewrite. This is why I say it's not the IE bundling, but the bullying that changed the reason why Netscape died.
How can the same action result in two opposite outcomes?
Because what actually reduced user choice in Microsoft's case is not bundling (which in fact increases choice), but its other actions, such as preventing OEMs from also bundling Netscape.
In fact, if Microsoft had allowed Netscape to ship with OEM PCs, provided a start-up option to choose Netscape or IE as the default browser, and actually respected that setting even in its own software (when launching a HTTP link from email, for example), then I don't think many people will disagree that it'd be a rather fair fight. A monopoly is required to bend over backwards like that for a competitor.
It's not the "bundling" at all, and I'm only explaining all this because you were wondering:
Why is this do difficult for many people to understand?
Where? I'm sure a good answer to this question will be moderated +50 if possible. Or are you just presuming that there must be such places?
people don't know how to apply and demonstrate how their skills are relevant to the job at hand.
When was the last time you looked for a job in the computer industry, without a degree, and got one? Today, every job (in the SF bay area, at least) gets a thousand related and unrelated resumes, and employers simply resort to hiring people they know. Failing that, a quick way to discard many of them is to exclude non CS majors.
From personal experience, I'd be lucky to get an autoresponse from even jobs that are I've been doing. I have a job now, but the first contact came from someone I knew, not a resume drop.
Have you actually tried what you propose, and succeeded? If so, I'm sure it'd be helpful if you can relate how your new employer picked your resume out of a thousand essentially random ones.
As a professional engineer with two computer science degrees, I cannot agree more. However, that's not what I said. What I said was that you'd have difficulty getting job interviews if you didn't have a closely related degree. If you somehow get the job, you don't need the degree to be a productive contributor.
It's a comment on the state of the job market, not the relevance of CS education on software engineer careers.
Programming is a highly specialized skill. As with any specialized skills, it requires... specialists.
he could have studied basket weaving in college and still learned enough to be a good programmer from on-the-job experience.
I seriously doubt he'd even get an interview today, much less on-the-job experience, without an engineering major of some sort. Everything you say makes great sense in theory, and I wish I lived in a world where talent and drive alone gets you jobs.
"Study what you want" is great if you can afford it.
Okay, you win. ;)
Using my rigid definition [that plain "C" should refer to ANSI/ISO C], prior to 1989, it was C. After 1989, it's "K&R C".
Obviously, this distinction isn't generally important, and K&R C is in fact largely similar to ANSI/ISO C. However, the context of this thread refers to "C compilers" with no floating point and recursion. This makes the distinction more important, because many C programmers have never worked in such environments, and most C programs will not work on them.
One last time.
We're not talking about K&R C, which is already significantly different from ANSI/ISO C (prototypes, argument declarations). We're talking about dialects that remove fundamental data types and most or all of the standard library.
When it is easier to convert an ANSI/ISO C program into C++ than into one of these 8-bit dialects, I think it qualifies as a separate language. If not, then certainly C++ should also be considered "C"!
semantic rigidity on your part isn't going to win you this argument.
How exactly does one "win" a Slashdot argument anyway? Especially when your opponent resorts to proof by repeated assertions, and simply claims that accuracy is unimportant? Well, yes, if accuracy isn't important, C++, Java, and C# are all just C.
You remain as wrong as ever; C is perfectly suited to 8-bit development.
So is C++, once you strip out exceptions, templates, virtual functions, floating point, recursion, and so on. How is that a useful statement?
This definition is both logically inconsistent and subjective.
Using it, you don't know if "valid C code" will even compile under a "C compiler", when it should in fact be at least generally true. In fact, you have no basis to say what is "valid C code" at all.
It also requires a human to "recognize" the language. Different people will yield different answers, and you'll get this sort of silly "is too C, is not C" arguments.
Why not just use plain "C" to refer to the ISO standard, and "C-like" or "a dialect of C" to refer to the others? This definition does not suffer either drawback.
Are you serious? The Validator checks for standard compliance. A browser actually shows you what you've created. You really don't think that little detail (actually seeing your web page rendered) is important?
First of all, there are other ways to achieve the American Dream. Secondly, there are people who stick to their principles, despite not achieving it. I don't know how you base your extrapolation, but perhaps you're overreaching.
Want to talk price fixing, go buy some gas.
Ahh, so shoplifting is okay because it's not really murder?
If it precludes recursion, then it's not C. Don't change the definition to suit your argument, because C is an international standard.
C is, in fact, a poor match for an 8-bit machine with minimal memory. C requires an 'int' type of at least 16 bits, a 'long' type of at least 32 bits, and a couple of floating point types - all royal pains to implement on an 8-bit CPU. Furthermore, a "hosted implementation" of C (which is really the minimum if you are planning any sort of porting) requires a sizable standard library, in which printf() probably will take up 4 KB of code space all by itself.
In fact, it's those stripped down dialects of C that really fit the "it's not really C that you're referring to" comment.
Actually, that's where Apple is being stupid. Apple violated its own user interface guidelines, which restricted the brushed metal look to interfaces that mimicked real world devices, like a VCR or stereo.
Having started the trend, it won't be long before more and more third party tools pick it up (to be cool, you know), and the look gets diluted.
Your excuses are rather flimsy.
How exactly would web designers test these CSS2 pages, unless at least some browsers are standards compliant?
As for IE, if market minority browsers that benefit most from standardization can't be bothered to fully support CSS2/DOM, why do you even expect the market leader to move?
There is no chicken and egg problem, and there is no choice. Minority browsers must support standards first. The best way to get web designers to support any other browser at all is if they can support most or all non-IE browsers with a single effort.
Certainly Columbus would've known that the English ships were the best at sea, not on land.
Each different browser can have a different document object model (lowercase). Document Object Model (uppercase), on the other hand, is a W3C standard API that allows you to access different document object models in the same way.
That doesn't change the fact that artistic merit alone does not determine its Darwinian success. Invaders have frequently destroyed the artworks of the losing nation, regardless of merit. Many extremely successful works of art receive a disproportionate amount of attention due to other qualities. Today, basically any Picasso painting would be worth a lot, whether or not Picasso himself even liked that work.
So yes, I can in fact discuss the merits of a CPU design independently of its market success.
Your arguments might have been convincing if you hadn't defeated it yourself in the end:
I think the 68k architecture would be amenable to similar success
Exactly. In fact, that chip would still be more pleasant to program than the x86, because of its orthogonality.
Your real conclusion is that a hybrid, where CISCy instruction sets are used to save memory and bus bandwidth, and a RISCy core actually executes mini-instructions, achieves the best performance today. That's not a matter of discussion or dispute, but hindsight.
Unfortunately, it also doesn't excuse Intel's initial architectural choices.
You see, the x86 instruction set is really just a compression scheme [...]
You don't seriously think that Intel had much of an idea how they were going to implement the P6 when they were designing the 8086, do you? What you describe is an afterthought. Whether or not x86 instructions had that effect, Intel was stuck with it because of Microsoft operating systems and existing x86 applications.
More importantly, the triumph of the x86 does not reflect the triumph of CISC as a philosophy. In fact, implementing frequently used instructions in silicon, and uncommon ones in microcode is a step towards RISC (the next step is removing them altogether). Going to a RISC core is another. Basically, if the CISC philosophy was extended to its logical conclusion, today we'd probably have a single instruction to encode a song into MP3 format. Yet, the last major revision to the instruction set is probably the MMX (around 1997), and before that the 80386 (around 1985).
No, the triumph of the x86 reflects the flexibility of Intel engineers. Although their chip represented many of what was wrong with CISC, they borrowed ideas where they could, and invented where they could not borrow. They weren't tied down by which ideas were RISCy and which were CISCy, and the market rewarded them handsomely.
None of these, however, support your thesis that the x86 is a "better" architecture, as the word is commonly used by students of computer architecture.
Many of our greatest artists lived and died without money, fame, or sometimes even children. In just about every Darwinian sense, they are failures. The extent to which they enriched our collective cultural heritage did little for them.
Similarly, I don't automatically consider people who make more money or have more children than I do as better people.
Scramble? I think the idea is to keep a laser platform airborne at all times, similar to the way AWACS aircraft work.