Stories
Slash Boxes
Comments

SoylentNews is people

posted by chromas on Wednesday October 03 2018, @09:12PM   Printer-friendly
from the the-future-is-now,-old-man dept.

Nikita Prokopov has written a blog post detailing disenchantment with current software development. He has been writing software for 15 years and now regards the industry’s growing lack of care for efficiency, simplicity, and excellence as a problem to be solved. He addresses the following points one by one:

  • Everything is unbearably slow
  • Everything is too large
  • Bitrot
  • Half-baked products get shipped
  • The same old problems recur again and again
  • Most code has grown too complex to refactor
  • Business is uninterested in improvement

Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by shortscreen on Thursday October 04 2018, @09:21AM (3 children)

    by shortscreen (2252) on Thursday October 04 2018, @09:21AM (#743953) Journal

    The dev time ROI might end up being a bit less than 41 years with a smiley after it. For instance, what if that program has 100,000 users and not just one?

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by MichaelDavidCrawford on Thursday October 04 2018, @11:58AM

    by MichaelDavidCrawford (2339) Subscriber Badge <mdcrawford@gmail.com> on Thursday October 04 2018, @11:58AM (#743999) Homepage Journal

    For years now I've been advocating for the refactoring of source code in such a way that its execution uses less electrical energy.

    For reasons I don't fully understand, many of my fellow Kuro5hin members regarded my idea as ludicrous, despite that I pointed out that surely there is _some_ reason why computers have power cords or batteries.

    "Intel giveth, but Apple taketh away": hardware designers work like slaves to eke little efficiency gains out of their components in the hope that the entire chip will use substantially less power, generate substantially less heat and execute code substantially faster.

    Yet not just apple with its Cocoa and Cocoa Touch but _every_ software vendor - INCLUDING OPEN SOURCE DEVELOPERS - when given a CPU that's twice as fast, write code that's four times as slow.

    A while back I read the source to glibc's qsort(). While well-written and not strictly quicksort but a highly-regarded improvement on quicksort, that code was written for a SPARC 1 in 1990. Surely it could be improved?

    We have CPUs with zillions of cores which work really well for servers with zillions of clients, but all those cores do us no good whatsoever when that CPU has just one user running just one program.

    This because no one can be bothered to learn concurrent algorithm design and coding. Yes, multithreaded code is hard to get right - but it _can_ be done. Concurrent code need not use threads, that's why Apple created - and Open Sourced! - Grand Central Dispatch, which facilitates multicore code _without_ the use of threads or complex locking.

    There are _many_ other ways to do concurrent coding.

    As for qsort(): it's not good enough just to make a concurrent quicksort, because the first pass is inherently single-threaded. While you can make its implementation run faster for a given N, it still won't be any faster than O( n lg n ).

    But parallel computation has been an active area of research SINCE THE NINETEEN FUCKING FORTIES because we have always known that computers will never run so fast that we can't find good reason to make them faster. Consider weather forecasting, or nuclear weapons design.

    Just Read The Damn ACM Proceedings when you wonder about how to replace single-core code with multicore.

    Consider that it's only been since 2000 or so that Linux has been able to do what MULTICS was able to do in the sixties. UNIX was not by any means intended to insult MULTICS or to be better than MULTICS, rather the original UNIX coders wrote UNIX for fun and relaxation after having worked so hard to get MULTICS to work so incredibly well.

    The reason why UNIX won but MULTICS lost was that (I don't really know but expect) that MULTICS was written in Assembler for a very high-end mainframe, whereas of course UNIX was written in C, with the original UNIX kernels being very, very efficiently written in ways that are completely unsuitable for modern uses, for example the inode table was a fixed-size array, so if you want to open more files you had to relink the kernel.

    --
    Yes I Have No Bananas. [gofundme.com]
  • (Score: 2) by darkfeline on Thursday October 04 2018, @07:16PM (1 child)

    by darkfeline (1030) on Thursday October 04 2018, @07:16PM (#744265) Homepage

    What if a small town gets a lot of tourism in the future? Clearly, that is valid justification to spend millions to build a ten lane highway through the town now.

    --
    Join the SDF Public Access UNIX System today!
    • (Score: 2) by shortscreen on Thursday October 04 2018, @08:04PM

      by shortscreen (2252) on Thursday October 04 2018, @08:04PM (#744289) Journal

      So your business plan is to sell a shoddy product, wait for it to become popular despite its shoddiness, and only then consider improving it? (If so, you may not be alone.)