On 03/02/2015 05:33 PM, Tor Myklebust wrote:
>
> This is indeed true, but it seems like a social problem rather than a
> technical problem. People can, and will, write garbage software no
> matter what tools they have. It might pay to let them do this with as
> little pain as possible so they can go back to working on the thing
> they were actually interested in doing.
>
> It sounds here like you don't like that your X application is running
> scripts, probably incorrectly, to do basic stuff. And how running a
> script can fail, with error codes like "too many open files" or "too
> many processes" or "not enough memory" when the task in question
> doesn't obviously involve allocating memory or spinning up a process.
> If you're in the mood to lay blame in a situation like this, I sugges
> directing it at the X application's author rather than the author of
> the script the application calls.
>
I'm not pointing fingers at any particular author, just the prevailing
wisdom of the day.

>
> I think the answer to this question is more complicated than can be
> described by a "tipping point" in a cost-benefit analysis. I think
> it's context-dependent and I think it can change over the lifetime of
> the software.
>
> Performance concerns, for instance, often crop up later in the
> lifetime of a project once it has a sizable userbase (or once somebody
> asks for the resource-intensive feature enough times). Should we code
> everything in C from the start just so we don't have to handle the
> performance problems in the unlikely event that the project succeeds?
> Maybe, but what if that constraint makes the project take quite a bit
> longer? And what if that reduces its chances of success?
>
If programming were that "black and white" I would agree with you.
However, C in general is the language in which other languages are
written. The ease with which you can link C object code to whatever
language you happen to using pretty much renders that concern moot.
>
> Performance concerns can cut the other way, too, under the name
> "scalability." Because it's easier to write really fast C code, you
> can get a lot farther with your really fast C code before hitting a
> performance wall. That sounds good, but it means your code can evolve
> into a bigger mess by the time you have to address your choice of data
> structures, or parallelisation, or distribution.
I've seen plenty of scaling arguments, and some of them are perfectly
valid arguments, but many of them are also just suppositions based on
the idea that C can't OOP.

>
> It's interesting that you'd mention Java here. I don't much like the
> Java language or the Java programming culture, but Java bytecode has
> the interesting property that, with a little plumbing, one can send
> executable code over the network and have it run on a remote machine.
> This actually winds up being useful for large-scale data crunching,
> where you want to move the code to the data rather than the data to
> the code wherever possible. I wouldn't know how to build a system
> that does this in C (for instance) that isn't brittle.
There is no magic to it. Java's core is usually written in C after all.
Realistically, the reason Java can do that is that Java bytecode is
processor generic. You could theoretically do that with C as long as
the processors are the same.

>
> It depends on what the utility is. C does not support certain useful
> forms of abstraction available in other languages. (I'm not talking
> about inheritance here. Generics and mixins are to my knowledge both
> impossible to do in a performant and syntactically transparent way in
> C. Ditto for anonymous functions. The way you emulate tagged unions
> in C---a struct with a tag field and a union member---is a little
> scary in any large code base because incomplete 'switch' statements
> won't raise compile-time warnings.)
Generics are little more than data in a buffer, IMHO. All you need do
is cast them as you see fit. The fact that other languages offer you
syntactic sugar to do it, is just fine too. The real comment is that
the language you refer to is not more capable. You are running it on
the same hardware. The difference is that the other language just makes
it easier for you in some cases, not necessarily better.

>
> I think you have aimed your criticism at the wrong target. It is
> annoying that "new" and "user-friendly" have both become synonymous
> with "does not work under heavy load or unusual conditions" in Linux.
> It wasn't always that way. But I would look toward the people
> building brittle stuff that instead of the guy who wrote adduser if I
> wanted to diagnose the problem.

I would rather address the disease than the symptom. I'd rather see
that the root cause: the cathedral of dependencies gets taken down a
notch. Doing that starts at the beginning, IMHO.