Re: Critique on my solution for an exercise. (check if a date is valid)

On Oct 15, 11:15 am, Bernd Paysan <bernd.pay...@xxxxxx> wrote:
Scalability goes up *and* down.  The overgeneralized solution does not scale
down, it has a fixed overhead per invocation.  If I implement a 3D graphics
library, I need some specialized matrix multiplications to transform the
view matrix (a 4 by 4 matrix, of which only a 3 by 4 subset is actively
used), BLAS is large overkill.  Therefore, e.g. my 3D turtle graphics uses
special-cased operators for this single view matrix, and I know it won't
ever scale.  It doesn't need to.  The problem space of 3D graphics is never
going to require more than three dimensions.  But I'm not paying the price
for having a generalized matrix library.

One thing that strikes me as I read Bernd's conversation with Aleksej
is an all-too-familiar pattern in comp.lang.forth-- both make
arguments against grotesque caricatures of programmers. Bernd's
arguments are against programmers who waste space and time with over-
generalized solutions and libraries, while Aleksej goes after his
perception of Forth programmers who waste time and effort forever
reinventing the same wheels over and over. Or in other words, both
like to create dragons that they then fearlessly slay.

Yes, there are indeed programmers that match both Bernd's and
Aleksej's worst stereotypes. But those programmers tend to work in
domains where those stereotypes are beneficial. The engineer who is
just looking for a fast answer to a numerical problem may certainly
use some horrifically generalized library routine to ram his dataset
through to get an answer. The toy designer who has an address space
of 512 bytes of code may certainly hand-craft every byte. The web
application guy may choose power over performance and use a framework
that let's him get out and test several iterations far quickly than a
custom solution. The programmer coding a fly-by-wire system may (and
should!) agonize over every last detail in a program, writing
everything from scratch.

The reality is that most programmers-- and most systems-- don't hit
the boolean extremes Bernd and Aleksej describe. Instead, it's a
matter of degree, with different aspects of a program exhibiting those
extremes. Take the project I'm working on right now. It's an
embedded digital audio system with a pretty GUI. You can look at the
GUI as an example of an over-generalized solution in that we're using
the massive Qt library which gives us far more than we need, is slower
than we would ideally like (but plenty fast enough), and consuming
more memory than necessary for what it does. That same project has
some highly-optimized custom real-time code, handling multiple
channels of digital audio, meeting some very stringent quality
requirements. One system with both extremes that Bernd and Aleksej
rail against, and with other aspects of the code varying between those
extremes.

And for this project, the variance between over-generalized code and
highly-custom code was simply a matter of knowing where to put the
effort. In this product, we had two primary constraints. First, the
unit needed to have excellent audio quality (which meant hitting some
critical real-time constraints) and second, we had very stringent time-
to-market requirements. Namely, if the product didn't hit store
shelves by a specific date, the client could stand to lose millions of
dollars in sales. So with those two constraints, we focused our time
and effort on the real-time aspects of the system and taking a more
relaxed approach for the GUI.

So the extremes described by Bernd and Aleksej aren't interesting to
me. Both are offering idealized notions of how a programmer should
prioritize time and effort without saying when their advice fails.
Lots of people in this newsgroup offer similar advice that ends up
somewhere between koan and aphorism, but really has little of value
for pragmatists who have to meet real-world and sometimes conflicting
constraints.

So Bernd, don't tell me that I'm paying a price when I take a
generalized approach, since when I take that approach, it's with
consideration towards putting time and effort where it matters.
Honest-- I know my designs and know my constraints better than you
do. So instead, tell me when your notion of a Forth approach doesn't
work. Show me the edges. Tell me where not to step when taking your
advice.

And likewise Aleksej, don't tell me that I'm wasting my time squeezing
out a millisecond here or wasting effort by hand-crafting custom code,
since when I take that approach it's also a thoughtful decision to put
time and effort where it matters. Instead, admit to an entire class
of problems where that approach makes sense. Show me you understand
that.
.

Relevant Pages

  • Re: Writing bulletproof code
    ... Good software design requires that you put error ... > the 'C' language and the libraries. ... It doesn't actually solve the problem that programmers are ... very few know when the cost will be negligible ...
    (comp.programming)
  • Re: <ctype.h> toLower()
    ... I konow several real world programmers, ... >> And portability is in most cases a very low priority as in most cases ... > the past 10 years I only wrote some specific platform specific software. ... > libraries did their job well). ...
    (alt.comp.lang.learn.c-cpp)
  • Re: How does Require deal with multiple files of the same name in different directories
    ... This meant that programmers developed their own ... libraries had almost the same functionality they have been merged into ... specific implementation details; hopefully that will be improved as ... to add pre-emptive multi-tasking, to have a separate code ...
    (comp.lang.forth)
  • Re: Writing bulletproof code
    ... >> Efficiency is part of good coding. ... the 'C' language and the libraries. ... >> where most programmers seem to go wrong, ... >> triple checking is more important than efficiency. ...
    (comp.programming)