Why I chose D over Ada and Eiffel

[H. S. Teoh]

On Thu, Aug 22, 2013 at 10:10:36PM +0200, Ramon wrote:
[...]
> Probably making myself new enemies I dare to say that gui, colourful
> and generally graphics is the area of lowest quality code.
> Simplyfying it somewhat and being blunt I'd state: Chances are that
> your server will hum along years without problems. If anything with
> a gui runs some hours without crashing and/or filling up stderr, you
> can consider yourself lucky.
> Not meaning to point fingers. But just these days I happened to fall
> over a new gui project. Guess what? They had a colourful
> presentation with lots of vanity, pipe dreams and, of course,
> colours. That matches quite well what I have experienced.
> Gui/graphical/colour stuff is probably the only area where people
> seriously do design with powerpoint. I guess that's how they tick.

This is also my experience. :) And I don't mean to diss anyone working
with GUI code either, but it's true that in the commercial projects that
I'm involved in, the GUI component is where the code has rather poor
quality. So poor, in fact, that I dread having to look at it at all -- I
try to fix the problem in the low-level modules if at all possible,
rather than spend 5 days trying to follow the spaghetti code in the GUI
module.

(Or rather, lasagna code -- some time ago they ditched the old
spaghetti-code source base, and rewrote the whole thing from ground up
using a class hierarchy -- I suppose in the hope that the code would be
cleaner that way. Well, the spaghetti is gone, but now the code that
does the real work is buried so deeply under who knows how many layers
of abstractions, most of which are not properly designed and very leaky,
that a single method call can literally do *anything*. The only reliable
way to know what it actually does is to set a breakpoint in the
debugger, because it has been overloaded everywhere in the most
non-obvious places and nobody knows where the call will actually end
up.)


> You can as well look at different developers. Guys developing for an
> embedded system are often hesitating to even use a RTOS. Your
> average non-gui, say server developer will use some libraries but he
> will ponder their advantages, size, dependencies and quality. Now
> enter the graphic world. John, creating some app, say, to collect,
> show, and sort photos will happily and very generously user whatever
> library sounds remotely usefull and doesn't run away fast enough.
> 
> Results? An app on a microcontroller that, say, takes care of
> building management in some 10K. A server in some 100K. And the
> funny photo app with 12MB plus another 70MB libraries/dependencies.
> The embedded sytem will run forever and be forgotten, the server
> will be rebooted ever other year and the photo app will crash twice
> a day.

LOL... totally sums up my sentiments w.r.t. GUI-dependent apps. :)

I saw through this façade decades ago when Windows 3.1 first came out,
and I've hated GUI-based OSes ever since. I stuck to DOS as long as I
could through win95 and win98, and then I learned about Linux and I
jumped ship and never looked back. But X11 isn't that much better...
there are some pretty bloated X11 apps that crash twice a day, too.
Sometimes twice an hour. After repeated experiences like that, I decided
that CLI is still the most reliable, and far more expressive to begin
with.  CLI-based apps are generally far more stable, require far less
resources, and are *scriptable* and composable, something that GUI apps
could never do (or if they could, not very well). I concluded that the
only time GUIs are appropriate is when (1) you're working with graphical
data like image editing or visualization, and (2) games. I found that
(1) is actually doable with CLI tools like imagemagick, and I rarely do
(2) anyway. So I dumped my mouse-based window manager for ratpoison, and
use my X11 as a glorified text terminal, and now I'm as happy as can be.
:-P

Or rather, I *will* be happy as can be once I find a suitable
replacement for a browser. Browsers are by far the most ridiculously
resource-consuming beasts ever, given that all they do is to display
some text and graphics and let you click on stuff. On my office PC, the
browser is often the one cause of long compile times when its
memory-hungry resource grabbing clashes with the linker trying to link
(guess what?) the GUI module of the project. RAM-hungry, IO-bound
browser + linker linking gigantic bloated object files of GUI module =
30-minute coffee break while I watch the equally RAM-hungry X server
paint the screen pixel-by-pixel as the hard drive thrashes itself to
death. :-P  This 30 minutes easily turns into 1 hour if I actually dare
to run two browsers simultaneously (y'know, for debugging purposes --
what I would give to be rid of the responsibility of testing different
browsers...).


T

-- 
Always remember that you are unique. Just like everybody else. -- despair.com