Re: sql views for denomalizing

From: Gene Wirchenko <genew_at_ucantrade.com.NOTHERE>
Date: Mon, 01 Aug 2005 10:20:29 -0700
Message-ID: <67lse11oim8jct8f5v2gmoqr38tda04g5l_at_4ax.com>


On 30 Jul 2005 14:46:38 -0700, "Marshall Spight" <marshall.spight_at_gmail.com> wrote:

>David Cressey wrote:
>>
>> Heh, heh... "now we can fire all the programmers!" It's a recurring theme,
>> isn't it?
>
>I understand that it was claimed of Fortran that it would obviate
>the need for programmers. Thankfully I postdate the arrival of
>Fortran, but I've certainly heard of plenty of things that are
>supposed to make programmers obsolete. Apparently UML is going
>to do that as well. As Bullwinkle would say, "This time for sure!"

     "That trick NEVER works!" -- Rocket J. Squirrel

>> There was an article, a long while ago, entitled "the next 700 programing
>> languages". It was about how people keep inventing "data languages" in
>> order to get away from programming, and then turn these "data languages"
>> into programming lanaguages.

     This sure is simple. It sure beats <programming language>. I just need it to do <yet more>. Rinse, later, repeat. Ecce another programming language.

>For sure. As an aside, it's quite clear to me we need a really
>good combined data/programming language. I'll get right on it.
>Writing code in a statically typed language to assemble untyped
>strings which are then passed to a statically type SQL is
>teh suck. I want unified typechecking between my application
>language and my data language!

>> This business of turning data into information has been around for a long,
>> long time. And, IMO, it'll be around for a long time to come.
>
>Absolutely. The only thing that'll make programmers obsolete is an
>artificial intelligence smart enough to write code based solely
>on reading the PM's requirements docs. And even that process will
>have to be iterative, because the PMs will say, "no, that isn't
>what I *meant*."

     Spec? What spec? And if specs do get written to that level of detail, what is the difference between that and a programming language? Some, but not a lot.

>It's clear that much of the complexity of programming is fundamental
>complexity. (Although we shouldn't let this stop us from rooting
>out the non-fundamental complexity.) You can't just solve the problem
>with a new language. As Brooks made clear, there is no silver bullet.

     Yes.
     Yes.
     Yes.
     But there are lots of imitations.  Help!  I am pinned down by
enemy fire.

Sincerely,

Gene Wirchenko Received on Mon Aug 01 2005 - 19:20:29 CEST

Original text of this message