Re: sql views for denomalizing
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 byenemy fire.
Sincerely,
Gene Wirchenko Received on Mon Aug 01 2005 - 19:20:29 CEST