digitalmars.D - Re: Why I chose D over Ada and Eiffel
- "H. S. Teoh" <hsteoh quickfur.ath.cx> Aug 23 2013
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.
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