Re: Why There are no Asm Apps
From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 06/17/04
- Next message: Randall Hyde: "Re: Why There are no Asm Apps"
- Previous message: hutch--: "Re: Betov's lies continue"
- In reply to: Jean Charbonneau: "Re: Why There are no Asm Apps"
- Next in thread: The Wannabee: "Re: Why There are no Asm Apps"
- Reply: The Wannabee: "Re: Why There are no Asm Apps"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 17 Jun 2004 03:55:24 +0100
Jean Charbonneau wrote:
> I suspect that the people who talk here about how good and how
great ASM is
> for developping any kind of application, have totally missed
the evolution
> of software development for, let's say, 20 years.
Well, I've been following the "evolution" of software
development for about 20 years (that's around when I started
programming :) and, well, _WHAT EVOLUTION_?
GUIs? Nope, that's from the '70s (Xerox)...
OOP? Nope, that's from the '60s (Simula67, which even
conveniently has the year in its very name ;)...
Virtual machines? Nope, Pascal was doing that with "P-code" a
long while ago...
Interpreted languages? Nope, as, in fact, interpreted BASIC was
usually the "norm" on ROM as the language of the OS itself...
_WHAT_ "evolution"?!?
There are things that have been developed more recently,
granted...but these aren't ever actually used by anyone more
than a handful of developers as often little more than "academic
curiosities"...what about, for instance, "formal methods" of
software development based on mathematical "proving" of software
quality and correctness? Nah, no-one uses it but the army (who
insist on it - at least, the US DoD and the UK MoD certainly
do - because of all that "military precision" you'd expect from
the army, who have a very serious business that can cost lives
when it goes wrong)...what about "aspect-orientated programming"
(an "evolution" of OOP)? Nah, I bet a significant amount here
might not have even _heard_ of it...
_THIS_ is the entire problem here...there has been _NO_
"evolution" of software development for about 20 years (or, at
least, the things that have been developed in this time period
are NOT actually used by anyone at all in practice outside of
"academia" and people writing their PhD thesis ;)...
Indeed, 20 years ago - in 1984 - Apple released their original
"Apple Mac"...it was remarkable for being a "desktop machine"
(then referred to as a "microprocessor"...which, indeed, must be
a source of confusion for people new to this stuff in modern
times, wondering what the "Micro" in "Microsoft"
("Micro(processor)Soft(ware)" would be the "expanded" name ;)
refers to...twice as confusing if they think the "Micro" simply
means "small" because how _inappropriately ironic_ would "small
software" be as a name for "Microsoft"? On many levels...their
software is hardly "small" and the company itself is also the
last thing people would typically consider "small" either
;)...for being a "microprocessor" which had a GUI operating
system...
Around ten years after this (well, actually almost 12
years...though there's "95" in the title, it was released late
and was closer to the start of '96 than '95), Microsoft launched
the largest advertising campaign in history to herald the
arrival of Windows 95...Windows 95 was remarkable in that it was
a GUI _OS_, for once, as opposed to merely a GUI "shell"
application running on top of DOS, a simplistic command line OS
("simplistic" is a fair description, not just an
insult...because it's original name before Sir Bill altered it
to "MS-DOS" was "QDOS" or "Quick and Dirty Operating System"
that its original author - that wasn't Bill Gates or any
Microsoft employee, in fact - would probably think me kind in
calling it only "simplistic" ;)...
Ummm, "Windows 95 = Apple '84"? Sounds more like a _regression_
that an "evolution", wouldn't you say? Especially when, in fact,
the Apples had a 100% GUI _OS_...while Win95 was "mostly" a GUI
OS...
And this is a perfectly fair comparison too, in that the only
further capabilities - better graphics, better sound, etc. -
found under Windows 95 were all due to _HARDWARE ADVANCEMENT_ in
the intervening decade...oh, indeed, it was almost comical to
anyone who'd used an Apple Mac (or a number of other good GUI
OSes for other machines...such as "RISC OS" found on the Acorn
Archimedes, a 32-bit RISC machine (1987) :) to see such a major
fuss - indeed, officially the biggest "fuss" ever made in the
history of advertising, even to this day - made over Microsoft
finally cloning the Apple Mac with a GUI _operating system_
(rather than just a GUI "shell" application for DOS)...that,
indeed, wasn't even really 100% free of DOS...and the comparison
is totally fair from the perspective that Microsoft had used all
manner of bizarre interface designs ("program manager") in their
previous GUI shell applications that it's quite _literal_ that
they finally did what Apple had all along with Windows 95...an
actual _desktop_ where icons could be placed...rather than just
being a "background wallpaper" where only minimised applications
had icons under the horrible-to-use "Program Manager"
abomination in Windows 3.x...
So, doing that decade, "evolution" actually _REGRESSED_ (on the
software side...hardware development, as always, could keep its
head high...well, except maybe for "real mode addressing" on the
8086 chip ;)...that we were seeing the _exact same_ "innovation"
happen all over again (!!)...
[ You know, I _hated_ the PC when I first saw it: "this is the
machine businesses prefer to use? Geez Louise, you can sell
businesses any old crap, can't you?"...my trust in any supposed
"wisdom" in business circles took an immediate hit, looking at
this big, clumsy "neanderthal" of a machine...silent but for a
crap "beep" PC speaker, an OS that immediately felt incredibly
_limiting_ in all its "text mode" glory, not particularly
interesting or impressive graphics, etc....it's only real
"saving graces" were only that they tended to always come with a
"hard drive" (note that I was not looking at an original PC here
but, indeed, a PC _after_ some "evolution" of the system had
happened...this wasn't "usual" right from the start at all) and
that, oh yeah, Intel were starting their "clock speed"
obsessions (A.K.A. the thing that made programmers lazy and
sloppy when a fast CPU "clock speed" (and RAM) could cover all
manner of programming sins)... ]
I've got a computer magazine from 1987 here...I kept it because
in the programming section, it had "Bresenham's Line
Algorithm" - hey, in the pre-internet days, you grabbed whatever
information you could get your hands on! - but, coincidentally,
it's the issue that has a big article on the launch of IBM's
PS/2 with the OS/2 operating system...it's an amusing read,
indeed...
I like, for instance, this part of the article, which also
confirms what I'm mentioning about the crapness of Windows:
"Microsoft has made [ to OS/2 ] one significant change from the
original Windows interface. Windows will now overlap in the same
way they do on the Macintosh or with GEM, rather than being
tiled as on the original Windows" (man, they actually called it
a "Macintosh" rather than just "Mac" ;)...hey, it only took them
3 years to work out how to "overlap windows"...that's pretty
quick learning from Microsoft, actually...it usually takes them
more like 10 years to learn how to program something new...
Speaking of which, that's why I pulled out the
magazine...because, yeah, another "delay" to mention...the
80386 - which provided 32-bit protected mode operation - came
out in 1985...ten years later, with Windows 95, they were
_beginning_ to actually _USE_ that 32-bit capability (hey,
remember the adverts: "It's true 32-bit!!"...wow! ;)...still not
100% or anything but, hey, at least, ten years later, they'd
considered that they might, you know, begin to actually use the
hardware's capabilities rather than continue to run it as a
"faster '286" (or even "faster 8086", often ;)...took _another_
ten years for them to finally complete what they'd started and
make it (as far as we can tell) properly 32-bit...
Microsoft wrote some software for the Apple Mac, you know...a
word-processor and a spread*** (_stolen_ idea, of course, as
usual)...a kind of "proto-MS-Office", I suppose...not
particularly sure it's actually improved in those 20 years...oh,
sure, they've added on great "innovations" like "Clippy" the
annoying paperclip...and then, ummm, subsequently removed
"Clippy" when they finally realised that the whole point of an
"assistant" is to _offload_ work...whereas, "Clippy" wouldn't
fudging shut up...rather than having a useful assistant that
would ease the burden on you while you work (you know, like
having a secretary who could usefully handle the filing and
appointments and that kind of thing :), it was like babysitting
the most annoying brat that hell could spew forth...
Oh, it's your typical case of people thinking "technology"
before thinking "common sense" and "pragmatics"...what's _good_
about an "assistant" is, in fact, that you tell them what to do
and then they go about their job _silently_, taking that burden
off you..."Clippy", on the other hand, was a secretary who'd
barged into a private meeting at the office constantly to ask:
"does anyone want a coffee?" / "No, thank you"...then, ten
seconds later, he'd barge in again: "Anyone changed their mind
and now wants a coffee?" / "No, no-one wants a coffee"...ten
seconds after that: "Are you sure you don't want a
coffee?"...and so on and so forth for the entire duration of the
meeting that, in fact, you don't get anything done in the
meeting, save for telling fudging "Clippy" a million times that
you don't want a coffee...
Hmmm, "you appear to be writing a letter"...ummm, no..."you
appear to be writing a letter"...NO, I'm not..."you appear to be
writing a letter"...SHUT UP! "You appear to be writing a
letter"...right, that's it! I don't know if "paperclip abuse"
breaches the Geneva Convention or not, but I'm perfectly happy
to give it a go and find out ;)...
Yeah, that's another good example of a software "evolution" for
you (something that was actually _new_ - well, the idea is very
old hat of a "robot to do all the work" but it was "new" in the
sense of actually _trying_ to get it to work - that happened in
those 20 years)...the "personal assistant"...which Microsoft not
only scrapped but, in an uncharacteristic display of
self-mockery and having a sense of humour, published a "Clippy
homepage" on their website, entirely devoted to taking the
mickey out of "Clippy" something rotten...for once, a PR move
from Microsoft that I approved of...they had a sense of humour
about it all to make their form of an "apology" for Clippy with
a "homepage" where you could laugh along with them about what a
dreadful, dreadful idea he was (I suppose an actual apology -
literally saying "sorry" - is asking too much of the ego-maniacs
at that company but this was at least a funny next-best-thing,
which as much admitted it without actually saying the words
straight out ;)...
Indeed, the _entire problem_ for the past 20 years has exactly
been that there hasn't been any "evolution" of software
development...or, at least, "evolution" has always been seen in
the wrong terms that creating bigger programs all the time is
"evolution"...and the bigger they get, the harder they are to
develop...and the harder they are to develop, the more
"shortcuts" programmers take...and the more "shortcuts" the
programmers take, the more bloated, slow and sloppy the
resulting code...
In fact, Randy's not gone far enough...but what he's said has
helped me realise what the true problem has been all this time -
20 years - that has lead to this nonsense of a situation
software finds itself in...the problem, indeed, is the "bigger
is better" mentality itself...
Irrespective of the tools or programming languages used, people
don't just write a text editor, they have to write a "fully
integrated office suite"...people don't write Space Invaders or
Asteroids, they write "Final Fantasy 37" which has such a big
map, it _literally_ is bigger than the actual Earth
itself...and, of course, is capable of "100,000 simultaneous
players"...
The problem is that to write things this big and this complex,
it _IS_ increasingly more difficult to do a good job of
things...and it's not linear either, in that doubling the size
and complexity of an application can _more than double_ the
development effort (in terms of having to manage developers and
organise such complexity becoming more and more difficult, _on
top_ of it simply being bigger anyway)...
So, indeed, think of what Randy's suggested _in
reverse_...BECAUSE programs are increasingly bigger and more
complex all the time, then it _does_ become more and more
difficult to develop...and this is true _WHATEVER_ the
development language...assembly language just "suffers it more"
and is more "obvious" in this...BUT, thinking it over, the very
same thing is true _WHATEVER the programming language used_...
Hence, for the last 20 years, the "evolution" has been crap to
non-existent...software is increasingly bloated, slow, sloppy,
etc....but, indeed, the expectations of "bigger is better" is
also increasing...
Therefore, basically - whatever language you're choosing to
use - if you were writing "Notepad" then a single developer in a
reasonable time could do an excellent job...it's a nice and
simple...BUT, the problem is that everyone wants to write "fully
integrated office suites"...and, even in HLLs, that's a tall
order...it takes a lot of time and effort...
And, simply, what's happening, I reckon, is that the size and
complexity of software - driven by the expectations of
continually more complicated "monolithic" software (like,
indeed, the worst example of bloatware: Windows, Word, Office,
etc. that we've got our clear "correlation" here ;) - is
basically _FORCING_ people to "take shortcuts", to code things
in more "sloppy" ways just to get it done on time...and so on
and so forth...
But - aye, here's the rub - the solution is NOT ever more
complicated HLLs...as is clear, this _amplifies_ the problem, in
fact...it's like the ever expanding RAM sizes on our
machines...when you double your RAM, then applications just
lazily take up twice the space rather than for there to be two
applications running happily together in that space...a problem
here could very well be that _because_ these HLLs make things
increasingly "easier" with "pre-defined window libraries" and so
forth then _expectations_ of what software should do simply
rises with it...
That is, if I can knock up an extra dialogue box in five minutes
rather than five hours, then the temptation is to add on tons
and tons of dialogue boxes everywhere...but, ah, though it's
easier to code this in a shorter space of time with all these
HLL "helper" libraries and things, what's being forgotten is
that having hundreds of dialogue boxes takes up RAM and disk
space...the old problem that more RAM just means applications
tend to get more wasteful...and more CPU speed just means the
code gets more lazy and sloppy...
The entire problem, in fact, could very well simply be _exactly_
that people expect "bigger is better"...on the other hand,
perhaps the more sensible way is "many small", NOT "one
big"...in fact, much like how there are all those small "one
purpose" UNIX utilities that _just_ count the amount of
characters or _just_ look for a string inside a bunch of files
or _just_ "make" a program...
Perhaps there needs to be a _change of attitude_ across the
entire industry (whatever langauge you're using)...so, as a
simple example, rather than writing some big "integrated office
suite"...just write a "spell checker"...the text is "piped" in
one side, the output comes out the other end...the "spell
checker" does NOTHING but spell check (no GUI interface or
anything)...this is easy to write and small enough that, indeed,
_effort_ can be put into making it function well in a reasonable
amount of time...and then another program can call the "spell
check" program when it needs that functionality...
The simple change of attitude being not to write some gargantuan
monolithic application all the time (ah, "gargantuan"...such a
cool word, don't you think? Nice to have a sentence in which it
can be said :)...but to write lots of small little _utilities_
but that a method for "piping" them altogether...I suppose the
problem has been _GUIs_ themselves, in fact...DOS and
command-lines always had "redirection" and "pipes" and "stdin"
and "stdout"...but GUIs tend NOT to have any typical
equivalent...
Something like, for example, the "spell checker" program defines
itself an "icon"...but that this "icon" can be dragged and
dropped onto any editor window - as a "button" in its "toolbar",
perhaps - and then "integrates" with that editor...hitting the
button passes the text in the editor to the spell checker's
"stdin" and it passes out the corrected spelling or whatever
through its "stdout" back to the editor...
In fact, though I'm just realising that perhaps it's the lack of
such things that might be the thing most responsible for the
increasingly bad state of software (HLLs are merely the _tool_
by which it happens...the actual thing _responsible_, though, is
increased expectations for evermore "monolithic" applications
that have "bells and whistles" integrated and added :)...I'd
already - perhaps subconsciously - thought in terms of an answer
with, for example, my idea of LuxAsm actually _having_ that
ability to sew together _small utilities_ - assembler, linker,
text editor, make, etc. - together but with a seamless visual
appearance, as if all the utilities ("plug-ins") were actually
part of the IDE itself...yes, the emphasis should, therefore, be
very much on this idea and, indeed, "many small" utilities...
I actually said it - again, must have been subconscious because
only now am I actually thinking _why_ this might be the case -
when I was challenging whether most IDEs actually are
"integrated" or are they, in fact, _aggregated_...Rene's RosAsm,
perhaps, demonstrates the difference well because of Rene's
"philosophy" to do things "monofile"...note that I don't say
this as a criticism but as a legitimate question...is RosAsm an
"integrated development environment" or an "aggregated
development environment"? Again, I stress that I'm NOT saying -
at least, at the moment - that there's anything wrong with
RosAsm being either...it's not "right" or "wrong" but a case of
examining things to try to understand it better...what I'm
thinking is that it's NOT really a case of "integration" because
that implicitly suggests and presumes - at least the Plain
English meaning conveys - that we're talking about "many small"
that are "integrated" to work together...but, actually, RosAsm
has all the features in _one_ "monofile"...I further stress I'm
not attaching any "right" or "wrong" here but just thinking it
through...and, thus, could we instead see RosAsm as actually
being _many_ applications all put into one source file and one
executable file? As I say, an "aggregation" - putting them
altogether into one - rather than an "integration" - many
separate things all working together?
Note that this _isn't_ only RosAsm...I've solely made that
example because, of course, Rene's philosophy _INSISTS_ on the
"monofile"...hence, RosAsm makes, indeed, an excellent example
of that kind of "monofile" programming...monolithic aggregated
programming...but we can see similar in other IDEs which include
project trees and dialogue editors and text editors and tool
integration and a whole bunch of things in _ONE_
program...Windows, Word and Excel - the chief bloatware culprit
examples - tend to take a similar "throw many, many features
into _one_ big program"...
Okay, Frank? C? We've got the right approach, it seems...having
"satellite" utilities that do specific jobs that _integrate_
(not "aggregate" ;) to an IDE base, which itself offers nothing
but, indeed, a _base_ for the GUI (a "server" for the windowing
stuff :)...this has brought it to mind and, thinking it over,
I'm more convinced than ever that we've got the right
approach...so, indeed, C, I _will_ set to work on getting the
idea going...
To borrow from advertiser and marketing ideas, they have a
little acronym that they say to remind themselves of how to
write the best advertisements: K.I.S.S. ("Keep It Simple,
Stupid!" ;)...this is perhaps a mantra that programmers - HLL
coders as well as ASM coders - should also begin to take up too:
"Keep It Simple, Stupid!"...
Which, of course, I've already been suggesting, anyway, with my
method of "integration" and the "unified model" and that kind of
thing...but this conversation has triggered an "Eureaka!"
moment...indeed, I often leaves things unfinished and it's
almost certainly because I wasn't applying "Keep It Simple,
Stupid"...alright, cool...I now have a number of things sorted
out a little better in my mind...excellent...
Umm, yeah, anyway...there's been little to no "evolution" in the
past 20 years, really...and perhaps _exactly because_ everyone's
been a little too much in a hurry to make it all happen in one
go in one "application suite"...a case of "more haste, less
speed"...
Beth :)
- Next message: Randall Hyde: "Re: Why There are no Asm Apps"
- Previous message: hutch--: "Re: Betov's lies continue"
- In reply to: Jean Charbonneau: "Re: Why There are no Asm Apps"
- Next in thread: The Wannabee: "Re: Why There are no Asm Apps"
- Reply: The Wannabee: "Re: Why There are no Asm Apps"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]