The future of G5's applications

I remember 15 years ago that a friend of mine was using a 68040
for creating somes video with Adobe Premiere (I think this was the
right soft he has used).

It was very hard, due to the limitations of the clock frequency, etc...

Nowadays, this kind of application (iMovie, FinalCut Express) is used
by everyone (on an iMac G4 for example).

So, I'm asking myself which kind of applications would have the
same advance on the hardware technology nowadays and would be used
by everyone in 10-15 years ?

Despite the fact that the G5 and Panther / Tiger are very powerful,
in which applications are they inneficient now ? (I mean too slow)

Many thanks in advance for your help,
Thierry

In article <mcmurtri->,
Kevin McMurtrie <> wrote:

> In article <>,
> Thierry Mella <> wrote:
>
> > I remember 15 years ago that a friend of mine was using a 68040
> > for creating somes video with Adobe Premiere (I think this was the
> > right soft he has used).
> >
> > It was very hard, due to the limitations of the clock frequency, etc...
> >
> > Nowadays, this kind of application (iMovie, FinalCut Express) is used
> > by everyone (on an iMac G4 for example).
> >
> > So, I'm asking myself which kind of applications would have the
> > same advance on the hardware technology nowadays and would be used
> > by everyone in 10-15 years ?
> >
> > Despite the fact that the G5 and Panther / Tiger are very powerful,
> > in which applications are they inneficient now ? (I mean too slow)
> >
> > Many thanks in advance for your help,
> > Thierry
>
> I'm hoping that computer applications eventually move away from software
> development languages based on C. The development time for C, C++, and
> Objective C is very long

The development time for C++ is typically much shorter than that for C,
and the one for Objective-C is shorter still.

> because the environment does very little to
> protect against coding mistakes, and does very little to help with
> complex tasks. Getting multi-threaded C++ to work perfectly can be
> mind-boggling and frustrating at times.

I haven't seen a language yet that makes threading a no-brainer if you
don't already have a clue what you're doing. On the other hand,
libraries _can_ ease the process quite a bit (and there are extant ones
that do).

> That's why so many programs crash constantly or run very slowly. C based languages don't scale to
> handle large programs. Bugs become impossible to manage or even find.

You're describing, I think, weaknesses of engineering practice rather
than of any specific language. C-based languages have no trouble
handling large programs and the difficulty of finding bugs is no
different from any other language I've used. On the other hand, bad
coding practices can kill the maintainability of even a small project in
any language.

G

--
Standard output is like your butt. Everyone has one. When using a bathroom,
they all default to going into a toilet. However, a person can redirect his
"standard output" to somewhere else, if he so chooses. - Jeremy Nixon

In article <mcmurtri->,
Kevin McMurtrie <> wrote:

> I'm hoping that computer applications eventually move away from software
> development languages based on C.

You're welcome to design and write one. OTOH, have you looked at
languages like Eiffel?

--
"...crying in your drink is bad enough; crying into a hot fudge sundae
is disgusting." - Jerry Farnsworth in _Job: A Comedy of Justice_

Thierry Mella <> wrote:

> Despite the fact that the G5 and Panther / Tiger are very powerful,
> in which applications are they inneficient now ? (I mean too slow)

Music. Logic 7 (which came out yesterday) has a facility for spreading
software instruments and effects over multiple machines. That's quite
necessary, given that many people have external DSP board (Powercore
cards and Firewire boxes, ProTools cards and boxes).

Not that *I* have ever managed to bring my G5 to its knees, but I guess
if I put a Space Designer on each of two dozen tracks....

V.
--
email: lastname at cs utk edu
homepage: www cs utk edu tilde lastname

In article <>,
Brian Rost <> wrote:
.......
>
>The fact that C has thrived for decades is testament to it's utility.
>Thank God we're not still coding everything in FORTRAN or COBOL.

Perhaps FORTRAN, but Fortran 90 (and 95...) is quite useful,
particularly for scientfic applications.

--
Daniel Packman
NCAR/ACD

In article <>,
Thierry Mella <> wrote:

> Despite the fact that the G5 and Panther / Tiger are very powerful,
> in which applications are they inneficient now ? (I mean too slow)

File management will be seriously revisited and re-envisioned. Apple is
already stabbing at it in Tiger with Spotlight, but this are already so
bad that in 10 years the whole Finder, as we know it, better be *dead*.
We already have hundreds of thousands of files on hundreds of gigabyte
drives. In a decade, when the count gets into millions (over 7^7), it
will be an interface nightmare.

In article <mcmurtri->,
Kevin McMurtrie <> wrote:

> > I haven't seen a language yet that makes threading a no-brainer if you
> > don't already have a clue what you're doing. On the other hand,
> > libraries _can_ ease the process quite a bit (and there are extant ones
> > that do).
>
> Threading is quite easy in Java. The big deal is in sharing complex
> dynamic data across multiple threads. C++ requires reference counting
> so that deleting data happens at the right time. If that's not hard
> enough, all of that reference counting needs carefully planned semaphore
> access rules to make deadlocking impossible. It's a real drag to code
> it all correctly. After a few months of 75 hour work weeks and missing
> a few deadlines, a coder might decide that writing good code isn't worth
> the effort.

A coder might decide to brush up more on threads so such techniques
become second nature. Threading is "quite easy" in general. I've done it
in Java. Not really easier there than anywhere else.

> Think about how much computers got done with a 30MHz CPU and 16MB of
> memory back when everything was optimized down to the tiniest detail.

Started programming on a 1MHz machine with 128k (but only usable in 64k
banks).

> Now a 1800MHz CPU with 1GB of memory struggles to display a Finder
> window. It's crappy code.

It's also exaggeration on your part. Or a serious problem with your
system. My iBook 600 with 640MB has no trouble displaying Finder
windows. Neither does the iMac 600 with 256MB at work.

But you're certainly correct that there's been a drift toward less
efficient code and as a programmer it bugs the heck out of me that in
many ways we have to upgrade hardware to stand still. But seriously
that's because the pressures on software developers in 2004 are _much_
different than they were in 1982 and the market has been quite clear and
consistent in reinforcing the reality that optimization and correctness
are not as big issues for them as frequent, flashy releases.

> > > That's why so many programs crash constantly or run very slowly. C based
> > > languages don't scale to
> > > handle large programs. Bugs become impossible to manage or even find.
> >
> > You're describing, I think, weaknesses of engineering practice rather
> > than of any specific language. C-based languages have no trouble
> > handling large programs and the difficulty of finding bugs is no
> > different from any other language I've used. On the other hand, bad
> > coding practices can kill the maintainability of even a small project in
> > any language.
>
> C++ bugs can take days to track down.

Find me a language where it's not possible for a bug to take days to
track down. I'll reiterate: you're describing methodology issues and not
an inherent problem of any language (except Intercal).

G

--
Standard output is like your butt. Everyone has one. When using a bathroom,
they all default to going into a toilet. However, a person can redirect his
"standard output" to somewhere else, if he so chooses. - Jeremy Nixon

In article <gwestonREMOVE->,
Gregory Weston <> wrote:

> In article <mcmurtri->,
> Kevin McMurtrie <> wrote:
> > C++ bugs can take days to track down.
>
> Find me a language where it's not possible for a bug to take days to
> track down. I'll reiterate: you're describing methodology issues and not
> an inherent problem of any language (except Intercal).

Oh, sure, blame the language, eh? I prefer Whenever
(http://www.dangermouse.net/esoteric/whenever.html) to Intercal myself.
Although that's mostly a theoretical distinction, because so far there's
no interpreter that fully supports the language.

--
Tom "Tom" Harrington
Macaroni, Automated System Maintenance for Mac OS X.
Version 2.0: Delocalize, Repair Permissions, lots more.
See http://www.atomicbird.com/

In article <gwestonREMOVE->,
Gregory Weston <> wrote:

> In article <mcmurtri->,
> Kevin McMurtrie <> wrote:
>
> > Now a 1800MHz CPU with 1GB of memory struggles to display a Finder
> > window. It's crappy code.
>
> It's also exaggeration on your part. Or a serious problem with your
> system. My iBook 600 with 640MB has no trouble displaying Finder
> windows. Neither does the iMac 600 with 256MB at work.

my ibook 600 also has little trouble displaying finder windows.
however, i also have a 33mhz 68040 i use for lightweight tasks, and
finder on *that* is noticably faster in several areas (such as moving
and displaying large numbers of files) than the ibook and even faster
g4 machines.

and that is with the osx finder *not* doing things such as tracking
file sizes and available disk space as they change because doing that
would 'slow it down.'

> But you're certainly correct that there's been a drift toward less
> efficient code and as a programmer it bugs the heck out of me that in
> many ways we have to upgrade hardware to stand still. But seriously
> that's because the pressures on software developers in 2004 are _much_
> different than they were in 1982 and the market has been quite clear and
> consistent in reinforcing the reality that optimization and correctness
> are not as big issues for them as frequent, flashy releases.

i agree with that. unfortunately, eye candy sells.

Thierry Mella wrote

> So, I'm asking myself which kind of applications would have the
> same advance on the hardware technology nowadays and would be used
> by everyone in 10-15 years ?
>
> Despite the fact that the G5 and Panther / Tiger are very powerful,
> in which applications are they inneficient now ? (I mean too slow)

I have an example to illustrate my question :

With the adressing capacity of the G5, it's possible to import
huge databases in memory instead of working with the datas
on hard disks.

This will obiously improves the processing of the datas.

I think this was not possible with the G3 and (?) the G4.
But now, it is ...

Any other ideas ?...

Thanx in advance,
Thierry