On Mon, 2005-01-10 at 07:20 +1100, Sam Watkins wrote:
> On Sun, 2005-01-09 at 03:47 +1100, Sam Watkins wrote:
> > I think we would end up with much better software if all developers
> > were forced to use old, slow computers :) I remember how good and
> > fast the software was on my old RISC OS Acorn with 4MB RAM
> > (Impression, Sibelius, Artworks). Something is seriously wrong with
> > the way people write software these days!
>
> On Sat, Jan 08, 2005 at 04:12:14PM -0600, Ron Johnson wrote:
> > I have to somewhat disagree. Much modern software just *does
> > more*(1) than, and is more integrated with the DE, than old(2)
> > software.
>
> The RISC OS software I mentioned is better than similar modern software,
> I have not seen any equivalent modern software which I would prefer.
>
> Sibelius, for example, is an absolutely top-notch music scorewriting
> program. Artworks is a vector-drawing program which is better than
> anything else I have seen. Impression was a very good, easy to use
[snip]
> and play with an old RISC OS box, so they can stop imitating microsoft
> and playing creeping-featuretris, and learn the right way to do it!
Read this about what Andy Hertzfeld says were some of the big
mistakes in designing the Macintosh.
http://www.folklore.org/StoryView.py?project=Macintosh&story=Mea_Culpa.txt&topic=Software%20Design&sortOrder=Sort%20by%20Date
They did *amazing* work, but there were many memory-saving short-
cuts that came back to bite them.
I bet the people implementing RISC OS and it's apps were written
the same way.
> > And don't forget that s/w written in C++ is larger and slower
> > than C programs.
>
> All of that software I mentioned was written in ARM code, not C.
> Kind of sucks if you want to port it to a different CPU,
> but the ARM is the best CPU anyway, who needs the others ;)
The VAX is the best CPU. Who needs traditional HLLs when you've
got MACRO-32?
> Better stop reminiscing about the good old days...
>
> > But yes, VM can make people sloppy. OTOH, it can allow them to
> > write easier-to-read s/w, because of the lack of need to write
> > dense, hard to debug, code that wrings the last bit of speed out
> > of the box.
>
> True, but contemporary code is next to unreadable anyway, due to poor
> languages and libraries.
>
> C, C++, java, perl are definitely not "easy to read". I would say they
> are gratuitously difficult to read, especially perl. Python can be
They are made unreadable by clever programmers. I *hate* clever
programming. Especially by mediocre programmers. And I knew I
was vindicated in that heretical thought when I found this quote:
"Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible,
you are, by definition, not smart enough to debug it."
Brian W. Kernighan
You can be clever in any language, even COBOL and Ada.
Of course, C just begs for clever programming, and hands you an
AK-47 aimed straight at your feet.
> almost easy to read. I understand pliant and haskell are pretty good,
> but I don't know them very well. ARM code isn't all that readable ;)
>
> I'm working on an "easy to read" language, similar to C / C++
> (it translates into C / C++). Currently I'm implementing macros and
> efficient co-routines, which latter are fairly hairy to implement in C,
> so no one uses them. Co-routines are the best :)
>
>
--
-----------------------------------------------------------------
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.
"Bad artists always admire each other's work."
Oscar Wilde
Attachment:
signature.asc
Description: This is a digitally signed message part