Re: sql views for denomalizing

On 30 Jul 2005 14:46:38 -0700, "Marshall Spight"
<marshall.spight@xxxxxxxxx> 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

.

Relevant Pages

  • Re: A petition to J3 apropos FORTRANs future
    ... >> web programming, GUI development, and text analysis. ... >> may partially explain the small market share of Fortran. ... almost NO new code would be written in the language. ... time on the types of codes that scientists and engineers want and need to ...
    (comp.lang.fortran)
  • Re: interpretive vs. compiled
    ... for specific needs in FORTRAN. ... Nowadays, workstations are also available to engineers, and there's no ... Excel/VBA and much less exposure to programming. ... colleges are wondering what language to use in classes. ...
    (comp.programming)
  • Re: object system...
    ... for that you need machine language. ... isn't even as fast as other systems programming languages. ... Stroustrup's stated design goal was to enable ... all manner of elegance or abstraction can be sacrificed for speed, ...
    (comp.object)
  • Re: Why C Is Not My Favourite Programming Language
    ... "introduces" classes problems when compared against programming ... | - Fortran 66, Fortran G, Fortran H ... An interesting language, but I will need to refer to my dusty manual ... | - APL ...
    (comp.lang.c)
  • Re: Why C Is Not My Favourite Programming Language
    ... "introduces" classes problems when compared against programming ... | - Fortran 66, Fortran G, Fortran H ... An interesting language, but I will need to refer to my dusty manual ... | - APL ...
    (comp.lang.cpp)