Wheel-reinvention with Python

[Mike Meyer]

Torsten Bronger <bronger at physik.rwth-aachen.de> writes:
> Hallöchen!
> Mike Meyer <mwm at mired.org> writes:
>> Torsten Bronger <bronger at physik.rwth-aachen.de> writes:
>>> Mike Meyer <mwm at mired.org> writes:
>>>> Torsten Bronger <bronger at physik.rwth-aachen.de> writes:
>>>> [...]
>>>> You didn't answer the question about how you define agile
>>>> project. Please do so if you expect a comment on this.
>>> Projects with a high Sourceforge activity index.
>> That doesn't seem to match the common defintion of "agile" when it
>> comes to programming. Then again, you have a habit of using words
>> to mean whatever you want, without much reference to how they're
>> used by the rest of the industry.
> I'm not part of the industry.

That's no excuse for not learning the terminology, or at least
avoiding using phrases which already have a common meaning.

> Sorry, but now the arguments are getting destructive.  Agile
> programming is a fixed phase, which I've never used.  (And which
> makes no sense in this discussion.)
>> Sorry, but you're wrong. FORTRAN is very much a general purpose
>> language.  [...]
> It's not about the potential use of a language, but its actual use.

Of course it's not about potential uses. All languages are equivalent
at that level. What it's about is the features and facilities of the
language, and how well they support general-purpose
alternatives. FORTRAN has always been a bit behind other alternatives,
but not so far behind that it doesn't get used for real work. That's
as true today as it was in 1955. The difference is ther are a lot of
other choices, so it gets chosen less often. But I note that at least
one of the 155 projects on SourceForge that list FORTRAN as a language
is a GUI application for Windows.

>>>> You can't have it both ways. Either C/C++ is all legacy code, or
>>>> it's not.
>>> ... is wrong in my opinion.  Why should this be?
>> Because any given proposition is either true or false.
> If I say "most people are right-handed", then this means neither
> that all people are right-handed nor that none is.

Right. It means that *some* people are right-handed, and some people
aren't. Just like some C/C++ applications are legacy code, and some
aren't. Which contradicts your earlier assertion that C/C++
applications were all legacy code.

>>>> There are *lots* of applications areas that don't need GUIs, and
>>>> don't run on Windows.
>>> This becomes a discussion about estimates we both don't know
>>> exactly, and weight differently, so I'll leave it here.
>> No, it's not a discussion about estimates. The average household
>> in a G8 country has more computers that don't run Windows - and in
>> fact don't have GUIs at all - than otherwise. [...]
> However, it's about the types of software which is being produced
> today.

Ok, let's talk about the kinds of software being produced, and where
it's coming from?

All those computers need software. The embedded software market is
pretty active - and is hiring a lot of C (specifically C, not C++)
programmers. They may be hiring C++ programmers as well; I don't
examine those ads. Could those people be using VC++? I suspect not,
but can't say for sure.

Earlier, you said you wanted a popular language because they get cool
features faster. You hold up two proprietary VC++ (which is just an
development environment) and VB as "popular" languages. If you've been
watching software development long enough, you'd realize that "cool
things" usually come from open source projects first.

There are a number of reasons for this. One is that most of the
software written isn't written for commercial sale: it's developed to
make some product or employee more effective. Most of that is
developed by or for various governments, which in the US means it's
either PD (though possibly undistributed) or classified. People
working on such software are every bit as likely to come up with "cool
things" as people developing software for sale.

The other reason is that if you want to experiment with some "cool
thing", it's a lot easier to take an open source project and add that
feature than it is to get sources to a proprietary product or write
the thing from scratch. Once you do that, there's an incentive to give
the feature back to the community, in that you dont have to patch
every release of the product to include your feature.

These two things play off of each other. People working on inhouse
products don't have the legal headaches with open source software that
people working on proprietary products do. So they don't have problems
with making their business depend on them - and once they've done
that, they tend to let employees spend time working on those
products. I think this is a lot of open source development comes form
- developers getting paid to fix the software because their employer
needs it, not people working in their spare time.

Hmm. I seem to have gotten on a soapbox. Sorry about that...

     <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.