www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Why I chose D over Ada and Eiffel

On Fri, Aug 23, 2013 at 08:33:55AM +0200, PauloPinto wrote:
 On Thursday, 22 August 2013 at 23:59:59 UTC, H. S. Teoh wrote:
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.


All areas are bad, given the way software projects are managed. The consulting projects I work on, are for Fortune 500 companies, always with at least three development sites and some extent of off-shoring work. GUI, embedded, server, database, it doesn't matter. All code is crap given the amount of time, money and developer quality assigned to the projects.

You're right. All (enterprise) code is bad, 'cos the deadlines force you to use a hack solution and do a slip-shod job, because otherwise you'd be fired for continually failing to meet the deadline. And it's a vicious cycle. The first wave of programmers are forced to write bad code because of the unreasonable timeline, then the unfortunates who inherit that code are put on the same unreasonable timeline and now they have no time to understand the already-badly-written code, and so they can only write worse code on top of that. A few more waves of programmers after that, and the code is in such a sorry state that nobody even cares anymore, 'cos any effort at improvement is futile. Unless you're one of the braves who dare to junk the whole thing (or more realistically, a particularly bad module) and rewrite it from scratch. Of course, the new, better code only remains good for so long, before it starts to deteriorate too. But IME, the worst offender is still the GUI-related component. Why this is so, I can't really say. But there's a definite pattern that anything to do with the GUI component, or anything to do with javascript, tends to devolve into a horrid mess faster than, say, database-related backend code.
 Usually the top developers in the teams try to save the code, but
 there is only so much one can do, when the ratio between both classes
 of developers so big is as a way to make the projects profitable.
 
 So the few heroes that at the beginning of each project try to fix the
 situation, eventually give around the middle of the project.

Yeah, and it doesn't help when upper management shuffles people around with no regard as to which projects they are most familiar with (and therefore most productive in). We're just expendible pawns on their chessboard, and if they see fit to sacrifice us to a sinking project for the sake of winning one last sale before they ditch the project outright, who are we to object? Or, you get the reputation that you're one of the exceptional coders, and suddenly there's the expectation that they can dump any project, no matter how badly written, and you'll be able to fix it up in 2 days and deliver a shining, working product in 3. Which, of course, necessitates last-ditch hacks and workarounds and lots of untested code, 'cos there's no way anyone can physically accomplish such feats in the amount of time given.
 The customers don't care as long as the software works as intended.

Yeah, and that's where it really sucks. People have come to expect that software needs to reboot every other day, and that it's "normal" for a large GUI app to crash every now and then. I wouldn't sit in a car that randomly fails in the middle of the road every other day, much less buy one, yet people would shell out gobs of cash for badly-written software. I mean, yeah they will complain when it does crash, but they'll still willingly shell out more money to pay for fixing what shouldn't have happened in the first place. [...]
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.

Funny, I have a different experience. Before replacing my ZX Spectrum with a PC, I already knew Amiga and Atari ST systems. And IDEs on those environments as well. So I always favored GUI environments over CLI. For me, personally, the CLI is good when doing system administration, or programming related tasks that can benefit from the usual set of tricks with commands and pipes. For everything else nothing like keyboard+mouse and a nice GUI environment. Personal opinion, to each its own.

Yes, to each his own. :) I still heavily prefer CLI-based apps, and I still think many tasks aren't *inherently* graphical and therefore doesn't need to be handled in a graphical way. There are tasks for which GUIs are more appropriate, of course -- image/video editing, data visualization, etc.. But for me, it's CLI by default, and GUI only when necessary, whereas for most people, it's the other way round. *shrug* On Fri, Aug 23, 2013 at 12:34:07PM +0200, Chris wrote:
 On Thursday, 22 August 2013 at 20:10:37 UTC, Ramon wrote:

 It's the "bolt-on" mentality that ruins things, which is partly due
 to deadlines. As one guy once said to me (after I had complained
 about a quick and dirty implementation) "We have the choice between
 doing it right and doing it right NOW!" Ain't no more to say.

Yeah, it's a number of factors that add up essentially to "we don't have enough time to write this ourselves, but library X already kinda does what we want, so let's use it! Besides, it looks cooler, so the customer will like it better! Nevermind the fact that it's not really compatible with the other libraries we're currently using, but who cares? As long as the customer gets to see that we're on top of the latest hype, they'll be more willing to forgive us of inherent bugs we don't know how to fix. We can always just write workarounds to hide the problem anyway -- it's faster than trying to fix the root cause. Just stick those 's in front of every line in the PHP code, and the users won't even see the errors! We'll just insert a while(true) loop in this thread somewhere so it looks like the software is doing something useful afterwards, so they won't even know it crashed!" [...]
 And last but not least, a programmer can work for hours on end
 implementing a clever algorithm, using unit tests, component
 programming etc etc. Nobody will ever notice. If users see a button
 that when they press it the screen says "Hello User!", they are
 forever happy. What goes on under the hood is "boys and their toys".

Yeah, doing it "right" is rarely ever appreciated. I've had people tell me, why do it the right way? I've already written it the wrong way and it *appears* to work and nobody can tell the difference anyway, so who cares? Only once in a rare while, doing things right actually has visible effects... like that one time when I rewrote a shell script that does data analysis (a *shell script* that does data analysis!) in Perl, resulting in a performance improvement from 2+ days to 2 minutes. (It wasn't the language per se that made the huge difference, though it helped -- it was the fact that the shell script used grep and awk in a way that resulting in an O(n^2) algorithm, whereas the Perl script uses an O(n) algorithm.) But such occasions are rare. T -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a. -- Wouter Verhelst
Aug 23 2013