On 03/02/2015 01:57 AM, KatolaZ wrote:
> So the problem is not the language.
>
While I cited Perl and Python in particular, the gist of my rant was
about sloppy coding practices. I singled a few things out because I
personally feel that their communities can be regarded as some of the
worst offenders in that regard.

Others disagree, and that's just fine. We aren't going to change things
by talking about it, so this is mainly an academic exercise.
>
>
> The truth is that in the last 30 years we have started doing millions
> new things with computers, and these new needs have unavoidably
> brought new software and new libraries. Despite I like to keep my
> programs small, simple and reliable, I believe that it is not possible
> to set limits to the creativity of coders: let them use all the
> freedom they need.
>
The freedom you describe has always been present. It was here long
before I ever showed up and will be here long after I am not. I just
don't think that sloppy, shoddy work should be classified as anything
other than what it is, and not described as "freedom."

Again, that's just an opinion. I'm old school.


> Unless they use this freedom to break my toys apart, in which case I
> get nervous ;) I personally don't see the massive usage of Perl or
> Python *per se* as a threat to the reliability of the OS.
>
>
Danger to the OS, no, not in a strict sense - because the portions of
the OS we would be concerned about are not written in them. I was
referring to code that is used far more often: user applications - which
deals with the majority of time spent.

The number of interpreted user applications are a performance concern,
and the poor design practices that the languages actually force on or
encourage neophyte and more advanced programmers to use is a concern.

> I think that bad programming habits in C or C++ are even more
> dangerous than good Perlisms, as the SSH heartbleed saga has recently
> shown.

I'd shoot that argument down almost immediately. What you are actually
contrasting is poor maintenance of a codebase, not what language that
was used.

Contrary to what most "modern" programmers would like to promote, I do
not believe for one second that mandatorily garbage collected, bounded
languages create better code design. I would subscribe to precisely the
reverse, actually. If there is a flaw in the collector or the bound
check, you have an extremely hard to fix problem that affects virtually
everything. You are also continuously wasting resources on overhead
for features that can fail without warning. Even if you set that aside,
the reality is that you are investing in all of that wasted overhead for
vanishing returns. At no time are those features a 100% effective
solution to the problems they were intended to solve, and they create
entirely new ones. So what good are they, really?

Any code that does not work reliably isn't worth much.

I'd much rather do everything manually. At least, I know that it is
done correctly, and I can perform the appropriate testing to prove it.
In my opinion, that is why C will probably never be replaced in my lifetime.

There are differing views on this, naturally. I can only speak from my
own experience and say that every single "modern" language I have used
has been a PITA, without exception.


t.j.