C as a web scripting language

[Dik T. Winter]

>
> I sure wouldn't do it, normally. I have a single C web app in my collection,
> for specialized reasons; in general, I would not use C for web apps, because
> it's very much not a string processing language by nature.

Another point: if the machines that works as web server changes you may need
to recompile your C program on the new machine in order to keep it working.
That can be difficult if you do not have access to the machine itself. I am
now up against that situation. 32-bit applications statically loaded work
(compiled on another machine), dynamic applications do not work (a difference
in shared libraries...) and 64-bit applications statically loaded do not
work as web application for some mysterious reason.

 

[Charlton Wilbur]

SR> By this definition, an interpreter might internally use a
SR> compiler and then execute the compiled code, so the program does
SR> not necessarily need to run slower. However, it might indeed
SR> have an extended startup-time in this case compared to an
SR> interpreter that immediatly starts interpreting.

And this is, in fact, precisely what Perl (and I believe Python) does,
and where a great deal of the overhead of execution comes from. You
are, to invoke the cliché, attempting to teach your grandmother to suck eggs.

Someday, perhaps even within our lifetime, someone may develop a way for
code to be cached once it is compiled by one of these hybrid languages,
and thus the overhead of compilation may only be incurred when the code
changes. Truly, when that happens we will be living in an age of
wonders, and we can only wait for some great man to come and make it
happen.

Charlton

 

[Charlton Wilbur]

jn> You are repeating here the views that you need to trust the
jn> programmers as little as you can, because they are just mostly
jn> inept.

My view is that, as a programmer, the fewer chances a programmer has to
royally **** things up, the better.

I'm a programmer, and I think that 80% of programmers, like 80% of
humans in general, are idiots most of the time, and the other 20% of
programmers, like 20% of people in general, are idiots some of the
time. And the 80%/20% distinction may be too generous - it may be
closer to 90%/10% or 95%/5%.

So yes, you need to trust the programmers as little as you can.
Because, you know, if you expect people to regularly do stupid things,
and you plan for that, you can usually come out ahead. If you expect
people to do smart things all the time, and you plan for that, the first
boneheaded move can set you back for months, if not kill your project
altogether.

And I say this as a programmer. I like to think I'm in the 20%, but
odds are against it. And I've done boneheaded things myself before.

Charlton

 

[jacob navia]

Charlton Wilbur a critics :

My view is that, as a programmer, the fewer chances a programmer has to
royally **** things up, the better.

I'm a programmer, and I think that 80% of programmers, like 80% of
humans in general, are idiots most of the time, and the other 20% of
programmers, like 20% of people in general, are idiots some of the
time. And the 80%/20% distinction may be too generous - it may be
closer to 90%/10% or 95%/5%.

OK. You are of course entitled to your opinion. I just wanted to tell you
that it is self fulfilling. People are AWARE of your attitude and will
fulfill YOUR expectations. If I had a manager like you, I would surely
do as little as I can, leave obvious bugs in the software untouched,
and spend most of my work time looking for another job.

Most of the teams I have worked with, were led by people that made
me clear that they had HIGH expectations from me, and that I was
*expected* to be bright. In those teams I did my best in every
opportunity because I liked the work atmosphere where people are
respected and appreciated for what they do.

To get back to the discussion at hand. Source code management
systems have high quality and are mostly free (i.e. SVN for instance).
Apparently you do not use them because (obviously) it is yet another
thing that can go wrong in the hands of incompetent programmers.

Then (obviously too) you loose the source code for that C program since
nobody CARED to save it. Who cares? Nobody.

And when the guy that wrote that program found another job at last, he left
immediately and did not care at all what happened with his source code
anyway (or erased it intentionally as a goodbye present ).

Then, you feel comforted in your view: people are 80% idiots most
of the time. Conclusion: Ban C from development so that the idiots
do not screw up again.

It is a vicious circle of negative reinforcement. The only way to
break that is to use POSITIVE reinforcement but that would contradict
your world view.

You are stuck.

 

[bartc]

A compiler translates, an interpreter executes.

By this definition, an interpreter might internally use a
compiler and then execute the compiled code, so the program
does not necessarily need to run slower. However, it might
indeed have an extended startup-time in this case compared
to an interpreter that immediatly starts interpreting. But
since such an immediate interpreter also needs to start to
interpret header files without visible effects first, the
difference might not be that large.

It's difficult to believe some of this stuff. Simple compilation to
intermediate code is very fast on a modern machine, you normally wouldn't
even notice it, for smallish modules anyway. (JIT compilation to native code
might be a bit different if heavily optimised.)

That 400x benchmark (which was only 7x on my machine), was some 40 lines of
code, with no imports.

Reducing one of the limits (but still with 40 lines), made it 1x as fast as
C. Clearly any overheads of processing source code are neglible. (With this
benchmark, the true slowdown factor, on my machine, was about 40x when
console writing overheads are taken into account. This has nothing to do
with the 'costs' of 'compiling' source code.)

 

[Seebs]

I have yet to find a language that is not a terrible choice for Web
programming.

I find ruby+rails pretty friendly for it. It's not flawless, but it has
definitely gotten to "much nicer than terrible". Honestly, I actually sort
of enjoy doing web stuff in rails...

I find that reason to be utterly risible. If you can't keep track of
source code, what makes you think you can keep track of source code?

This is not as ridiculous as it might seem. I have at least once fixed
a bug in a C-based CGI thing in a hurry and then forgotten to save the
fixed code.

Performance is *always* nice to have.

True.

But not always *significant*, depending on the kind of performance at issue.
For most of the web-based stuff I do, any language I've tried is orders of
magnitude faster than I care about; the CPU time of most tasks is a tiny
fraction of the time spent waiting on a database or network. So at that
point, all else being equal, I tend to like to write in environments close
to the domain I need to work in. I have done CGI in C, but it's not
especially fun, and it may not be particularly robust. I have had at least
one bug in it which would not have been a bug in a scripting language.

-s

 

[Seebs]

Okay, yes, you're right - but in any case I find C easier to read than
PHP or Python, so for me the human cycles go hand in hand with the
machine cycles. Having said that, I do use PHP rather than C for Web
programming. Please don't ask me why, because I'm not sure whether I
actually know.

I used PHP some. I actually ended up having to use it for a non-trivial
project once due to lack of support for other languages in a vendor-provided
bit. (Eww. Long story.)

After reading a couple of books about PHP, I found myself thinking about
bleach a lot. It's a beautiful example of the genre of the first languages
so many programmers write, which are sort of like C only different in some
way. It's not a language I would ever use willingly.

I actually *like* Ruby, making it the third language I've ever gotten along
with. (C and sh are the other two. And I'm not totally sold on sh, but
it is expressive and widely available.)

-s

 

[Seebs]

OK. You are of course entitled to your opinion. I just wanted to tell you
that it is self fulfilling. People are AWARE of your attitude and will
fulfill YOUR expectations. If I had a manager like you, I would surely
do as little as I can, leave obvious bugs in the software untouched,
and spend most of my work time looking for another job.

Wacky.

I am pretty sure my manager is well aware that I make mistakes. I make
some truly SPECTACULAR mistakes, too. I once tested a refactoring change
(thus, no expected changes) against the wrong source tree -- one not
containing the change -- and as a result checked something into the main
product tree which, get this, *caused make to dump core*.

Awesome, no?

So we have a lot of processes and procedures. We use code review. We
have gatekeepers, who are not the same as code reviewers. We do tests
and validation. If I think I've fixed something, and I've tested it, and
I want to check it into the tree, before it gets out to a customer, it will
be:

* Reviewed by at least one other programmer in detail.
* Evaluated carefully by someone ELSE to check for risk of impact
to other parts of the system which depended on the old behavior,
or clashes with other ongoing development.
* Run through a complete test of whether the reproducer for the
bug now works correctly instead of showing the bug.

That's the minimum.

And yes, we've had bugs make it through that whole process, because *people
make mistakes*.

Most of the teams I have worked with, were led by people that made
me clear that they had HIGH expectations from me, and that I was
*expected* to be bright. In those teams I did my best in every
opportunity because I liked the work atmosphere where people are
respected and appreciated for what they do.

Yup!

But expecting me to be bright doesn't mean expecting me not to make boneheaded
mistakes.

So we sanity-check things. We add "stop and print an error" behaviors to
the build system when things look suspicious. In short, we react accordingly
to the information that programmers make mistakes.

And no, we don't trust programmers. I don't trust myself, because I have
a very large amount of data showing me that I make stupid mistakes all
the time. I actually sent a document out for review which referred to
the "build problem" rather than the "build process".

To get back to the discussion at hand. Source code management
systems have high quality and are mostly free (i.e. SVN for instance).
Apparently you do not use them because (obviously) it is yet another
thing that can go wrong in the hands of incompetent programmers.

Oh, I use source code management systems. I love me some git. Makes me
happy.

But I also forget to do things. ALL THE TIME. I can fix something and
forget to check it in, or check it in to the wrong branch, or try to
check it in and do something stupid that zorches the tree.

Then (obviously too) you loose the source code for that C program since
nobody CARED to save it. Who cares? Nobody.

Or possibly due to some unplanned or unforseen circumstance. I lost some
source code changes a few days ago, because a hard drive crashed and it
hadn't occurred to me to make backups of the home directory on my dedicated
video gaming machine.

It is a vicious circle of negative reinforcement. The only way to
break that is to use POSITIVE reinforcement but that would contradict
your world view.

Positive reinforcement is great, but denying reality isn't.

Reality is that humans make mistakes, and a well-designed system will not
assume that they don't.

-s

 

[Default User]

I used PHP some. I actually ended up having to use it for a
non-trivial project once due to lack of support for other languages
in a vendor-provided bit. (Eww. Long story.)

After reading a couple of books about PHP, I found myself thinking
about bleach a lot. It's a beautiful example of the genre of the
first languages so many programmers write, which are sort of like C
only different in some way. It's not a language I would ever use
willingly.

Strokes for folks. I've used PHP quite a bit, and like it just fine.



Brian

 

[Richard Bos]

jn> You are repeating here the views that you need to trust the
jn> programmers as little as you can, because they are just mostly
jn> inept.

This is a fucked up way to quote Usenet posts.

My view is that, as a programmer, the fewer chances a programmer has to
royally **** things up, the better.

I'm a programmer, and I think that 80% of programmers, like 80% of
humans in general, are idiots most of the time, and the other 20% of
programmers, like 20% of people in general, are idiots some of the
time. And the 80%/20% distinction may be too generous - it may be
closer to 90%/10% or 95%/5%.

You may be correct, but that's not what C is for. If you want Logo, you
know where to find it.

Richard

 

[Richard Bos]

That's not the same risk.

It's like losing your wedding video, compared with someone stealing your
VCR. One is easily replaceable, the other isn't (ignoring the fact that VCRs
are near obsolete).

Frankly, as someone who does both programming _and_ sysadminning for his
profession, I'm amazed that nobody has mentioned backups yet.

Richard

 

[Charlton Wilbur]

jn> Most of the teams I have worked with, were led by people that
jn> made me clear that they had HIGH expectations from me, and that
jn> I was *expected* to be bright. In those teams I did my best in
jn> every opportunity because I liked the work atmosphere where
jn> people are respected and appreciated for what they do.

Every team I've worked on that was successful had two things: high, but
achievable expectations, and sanity checking because people make
mistakes.

jn> To get back to the discussion at hand. Source code management
jn> systems have high quality and are mostly free (i.e. SVN for
jn> instance). Apparently you do not use them because (obviously)
jn> it is yet another thing that can go wrong in the hands of
jn> incompetent programmers.

Actually, no. Source code management systems are one of the smart
things to use, because they hedge against the mistakes made by even
competent programmers.

Further, you're putting words in my mouth: I didn't say that people
weren't competent programmers. I said that 80% of people, including
programmers, were idiots most of the time. While the strict percentage
might not hold in all environments, you can tell yourself by a survey of
this newsgroup (and possibly with a little bit of reflection and
introspection) that even competent programmers are quite capable of
being idiots.

jn> Then (obviously too) you loose the source code for that C
jn> program since nobody CARED to save it. Who cares? Nobody.

jn> And when the guy that wrote that program found another job at
jn> last, he left immediately and did not care at all what happened
jn> with his source code anyway (or erased it intentionally as a
jn> goodbye present ).

In the case at hand, it was a company where source code management had
never been used, and despite my best efforts, was still not being used
at the time I left.

I did not lose the source code; it was lost before I was hired, and I
had to deal with constant complaints about the bugs in the code. I
could not fix the bugs without the source code or without completely
reimplementing the project. There was no management support for the
latter, and I have never been invested enough in a company to do six man
months of unpaid volunteer work that management was not interested in.

I am mildly entertained by the narrative you have constructed to portray
me as the source of all stupid decisions and the cause of all
misfortunes, but it has little bearing on what actually happened.

jn> Then, you feel comforted in your view: people are 80% idiots
jn> most of the time. Conclusion: Ban C from development so that the
jn> idiots do not screw up again.

In a situation where C has no advantages to make up for the drawbacks
and the risks, why should it be used?

Charlton

 

[Charlton Wilbur]

RB> You may be correct, but that's not what C is for. If you want
RB> Logo, you know where to find it.

No, it isn't what C is for, and you have just reiterated my point.

There are some things for which LOGO is the best tool. Using C in those
situations is a mistake. Remember, the initial question here was about
using C for web programming.

Charlton