Re: Am I the only one with doubts about .NET for commercial apps?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Steve McLellan (sjm.NOSPAM)
Date: 05/19/04 

Date: Thu, 20 May 2004 00:42:40 +0100

"Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message
news:MPG.1b107c61d3ef116998a90a@msnews.microsoft.com...
> Niki Estner <niki.estner@cube.net> wrote:
> > What kind of applications do YOU write???
> > I spent a few years developing signal processing/image processing
> > applications, and I can tell you: finding out how an algorithm works
isn't
> > half as easy as you seem to think. But getting good hints e.g. from
> > un-obfuscated mathod names (like "Fourier" or "Median") can really make
this
> > too easy.
> > I guess the same would apply to highly optimized graphics engines as
they
> > are found in computer games (if they were written in managed code) or
> > proprietary communication standards or high-speed-databases...
>
> There are certainly a *few* cases where the algorithm itself is most of
> the work. I don't think it covers what most developers write, however.
>

True, but it IS the bit that you're selling - anyone can slap a UI on
something. The only IP we have is the algorithm, and unless it's patented,
nothing stops someone decompiling it and incorporating it into their
product. With an algorithm it's relatively easy (once you understand it) to
rewrite it, so copyright doesn't apply. Of course, given an expert in any
algorithmic field, you can generally work out the methods used in a given
piece of software through experimentation and a feel for how different
methods work. A sort of mental decompilation, if you will.

> > - virtually every piece of code that required thought when it was
written.
>
> I spend relatively little time thinking about coding. Coding is
> relatively easy. Designing the system in the first place - what object
> should have what responsibility, etc - is the more demanding part, in
> my experience.
>

For some applications that's true. But commercially that stuff isn't
important to any company producing any cutting edge scientific
applications - the blood and guts (and the bit you pay your people for) is
the algorithm. As it happens at the moment, using managed code for any
number crunching isn't really practical in terms of performance (not to
mention cross platform compatibility) but it will become more of a problem.

Just, sa they say, my two.

Steve

Relevant Pages

  • Re: Am I the only one with doubts about .NET for commercial apps?
    ... > What kind of applications do YOU write??? ... > I spent a few years developing signal processing/image processing ... I spend relatively little time thinking about coding. ... relatively easy. ...
    (microsoft.public.dotnet.general)
  • Re: Reviving StrongBS
    ... In article, Harriet Bazley ... applications. ... variable names when coding and compacting therefore gives a good ...
    (comp.sys.acorn.apps)
  • Re: 3DES Number of security bits
    ... My question is about the strength of 3DES algorithm. ... The parity bits do not become part of the expanded key. ... The thinking is that because of the small block size, the work required to break three-key 3DES is less than its 168-bit key would imply and is much closer to the 112-bits associated with two-key 3DES. ... The main issue at this point is that 128-bit AES is faster and is likely to be more robust than 3DES, so dragging 3DES into new applications seems pointless unless the new applications must interoperate with legacy applications. ...
    (sci.crypt)
  • Re: Experience with the Sliding DFT, anyone?
    ... It is somewhat similar to the Goertzel algorithm. ... applications, but I have been using it for musical applications, ... would get from a regular DFT or FFT. ...
    (comp.dsp)
  • Re: Alternative for Mentors HDL Designer
    ... For certain applications, a detailed docu ... no matter how fast text based coding had ...
    (comp.arch.fpga)