
Web programs written in C++ are no big deal - sciurus
http://rachelbythebay.com/w/2012/01/05/libraries/
======
tptacek
Writing C++ code that works reliably in a benign setting is not a big deal.
With the right libraries, it is almost as easy and perhaps only a little
slower than writing in a high-level language; you can't, for instance, really
believe that everyone who writes a popular iOS application is a solid bare-
metal C programmer.

But writing reliable C++ code that works under adversarial conditions is _very
hard_ ; hard enough that the best C programmers in the world have track
records like "only one theoretically-exploitable memory corruption
vulnerability in the release history", and quite a few people who set out with
"no vulnerabilities" in their project charter end up with _way_ worse records.

I've found over the last couple years that one way to get C/C++ code fit into
a web application is via "nosql" databases, particularly Redis; let something
like Ruby/Rack or Python/WSGI or Java Servlets soak up the hostile HTTP
traffic, and use it to drive an async API over Redis.

The less C/C++/ObjC code you have talking to an adversary, the better off you
are.

I'm a C/C++ programmer; C is my first language, from when I was a teenager. I
respect C programmers. But if I was interviewing a developer and they told me
their gut was to write a C program to do something a Rails program would
normally do, and it wasn't an exceptionally specific circumstance, I would
think less of them.

~~~
akg
I'm not sure I understand why one particular language would lend itself to
more vulnerability than another. The less skilled someone is at a particular
language, the more bugs/vulnerabilities he is likely to produce. It is a
function of technical skill rather than a quality of the language.

For example a Ruby interpreter or a Java runtime that you trust to handle all
your HTTP requests are prominently written in C/C++.

I think what makes popular packages like Ruby/Java/Rails (etc.) more secure is
the sheer number of users they have. Those technologies have been hammered out
over several projects and by a plethora of users and developers. Writing a
component that rivals that number of interactions is tough, but certainly
doable.

~~~
tptacek
There's one (mainstream) C Ruby that needs to be audited. But _every_ C CGI
program needs to be audited.

C programs are susceptible to memory corruption. Programs written in
practically every mainstream high level language are not susceptible to those
problems (until they start using third-party C extensions). That's the
security win of not using C code.

------
pshc
* Dismissing newer technologies as "shiny" instead of evaluating their merits

* Language hipsterism

* Being disturbed by modular code

* Dismissing high-level code that might have leaky abstractions

* Plain CGI

* Being turned off by callbacks and reinventing the wheel instead

* The usual silliness about all tools being capable and therefore equal (they're all Turing complete, yes, but we still want to know which ones are more productive for some use case.)

This is grumpy posturing and C++ is now blub. Am I being trolled?

~~~
mvgoogler
_Am I being trolled?_ It feels more to me like you're the one that's doing the
trolling, but maybe I'm just mis-reading your post.

Disclaimer: I worked with the OP and she is a _ferociously_ productive
engineer.

 __Dismissing newer technologies as "shiny" instead of evaluating their
merits*

Or, evaluating technologies based on how useful hey are rather than the amount
of hype they are generating

 __Language hipsterism*

Huh? I don't even know what this means.

 __Being disturbed by modular code*

The OP was disturbed at the thought of building a program by gluing together
"modules". In this sense she is using "module" to mean (essentially) black-
boxes of unknown origin and quality. If you had ever seen her code you would
have a hard time convincing anyone that it wasn't modular.

* Being turned off by callbacks and reinventing the wheel instead

The OP says she hates the design of cgic, not that she's against callbacks.
She made a practical decision that cgic didn't do enough for her to warrant
the pain of using it, and discovered that creating something that she actually
liked using wasn't _that_ much work.

To put it more generally, she is saying that - given the choice between using
some existing code that isn't quite right (or outright sucks for some reason
or another) and taking some time to roll her own, she has found that it is
often worthwhile to spend a little time to create something that she knows
works and that she enjoys using.

* The usual silliness about all tools being capable and therefore equal (they're all Turing complete, yes, but we still want to know which ones are more productive for some use case.)

The OP said no such thing. She said that she has found a language she is
highly productive in (C++) and she hasn't yet seen a newer "shinier" language
that would make enough of a difference to warrant switching to it.

~~~
pshc
> _At some point, you just have to shut up and make stuff._

It does sound like she's ferociously productive. It's also possible that she
could be ten times as productive and that C++ is holding her back. The
programmer credo is to work hard _and_ work smart.

> _I guess the current "shiny" thing is still more-or-less Ruby [with] Rails.
> Oh, I suppose there's also the whole node thing, in which you write things
> in Javascript and run them server-side with v8. She dismissed node right
> away (with no argument from me)_

> _I have no practical experience with them_

Casual dismissal without evaluation of merits.

> _it's all been linked to frothy people clamoring for the latest shiny thing.
> I've seen that pattern plenty of times before, and it's always annoying._

This is what I mean by hipsterism: Dismissal based on an excited fanbase.

> _that somehow you would need to abdicate almost all of your code to modules
> where you just hope they work._

I had a problem with this sweeping generalization. If cgic isn't great, that's
fine. Certainly you still have to evaluate your dependencies' merits.

> _that creates an awful design where you give up main() to that program's
> code and then just wake up when it decides to call back to you_

This did read like an indictment of callbacks as a whole, but I see now that
she's not happy about libraries that hijack main() and have some secondary
entry point. I concede that.

> _It might not be wonderful, but you could build something relatively
> quickly, at least in theory._

High-level languages have proven productivity gains and known pitfalls. Here,
she is hand-waving them away without giving them a chance.

> _Better still, since I"m not chasing the shininess in that realm, I can
> spend those cycles on other things._

Trollish fallacy.

> _she hasn't yet seen a newer "shinier" language that would make enough of a
> difference to warrant switching to it._

As far as I can tell she didn't even give them a fair chance. She dismissed
them based on supposed hype and blubbiness.

------
alttag
Heh.

I used to work for a company that used C (not C++) for its large web site.
They ran the entire site from a monolithic C file. To say again, the code for
the entire web site (including product listings, shopping cart, coupons, etc.)
was in _one_ .c file. To make things more "interesting," it was, at the time
controlled by a single developer who didn't work on site and wouldn't let
anyone else touch his code. This barrier was backed up, as I understood, by
both tradition and management.

The initial decision for C was, I think, the correct one. The site had been
around from the early days of the web, and speed was important. However, the
architecting and personnel decisions didn't keep up with the company's growth.
Another consequence, though, was switching to CSS (which came along later)
from, for example, spacer gifs, took a great deal of developer time and
testing, as did adding new features. It's the trade-off I think we all
understand well today: fast code or fast developers.

It was interesting to see the changes while I was there—the site began
(slowly) to get recoded in Java, and broken into more manageable chunks at the
same time. So far as I know, the whole thing is now in Java.

~~~
alttag
Oh, and to make things even more fun, much of the data passed around between
back-end processes and vendor apps was done in XML at the time ... and the XML
parsing library they used for C was a bit buggy... No one (w|c)ould fix it,
which broke some edge cases.

Fun times.

Also, if I had to guess, I suspect another factor in the transition was that C
programmers were getting more expensive and harder to find.

~~~
iso8859-1
Using a buggy XML parser has little to do with C...

------
pnathan
I left C++ a few years ago. It's not that it's a "bad" language, for a certain
value of bad.

It's just bloody inefficient to get things done in! Coding in it requires
girnormous amounts of text shovelling, typing attempts to be strict, template
meta-programming requires hand-coding type inference schemes, and on top of
that, the library/package management is a nightmare.

Well, I didn't think these harsh things when I 'left' C++, but as I worked
with more high-level languages, I realized that I was doing more, with less
code and dynamic duck-y typing, _and_ with _nice_ libraries only a `cpan`
away.

So when I hacked together a C++ program a year or so ago, I got punched in the
face by all these issues. It was a pain. So I said, okay, this is stupid. I
need to use C for low-level work like drivers, and use Common Lisp for other
things. Like what everyone else does[1].

Fundamentally, C++ has a number of flaws, of course - that's typical for a
pragmatic language - but the key flaw in my opinion is that it's a pain to get
higher-level stuff done in until you build the libraries that other language
constructs/libraries give you out of the box.

[1] For a very small subset of everyone else.

~~~
o2sd
I am currently writing part of a web application in C++, the other part of the
web application is being developed by another programmer in Ruby On Rails.

In a single request, the RoR part 'does' about a two dozen 'things', which
takes it around 2 seconds to complete.

The C++ part 'does' around 1.2 million 'things' which takes it between 0.1 to
0.2 seconds to complete. Building the the component that does 1.2 million
'things' is simply impractical in Ruby.

Admittedly, very few web applications have this type of requirement, but
perhaps in the future many more will. The two dozen or so 'things' the RoR
does would take a LOT of code in C++. Well, compared to RoR it would be a lot
of code. And the 1.2 million 'things' that the C++ application does would be
absurdly difficult to program in Ruby, and as mentioned, would take an
absurdly long time to execute.

So at the risk of sounding cliché, perhaps it is less a matter of Ruby vs C++,
and more one of using the right tool for the job. Once that decision has been
made, programmer productivity has more to do with the programmer than the
language. I am extremely productive in C++, even though I have to write a lot
of code to be productive. If I was a LISP expert, I would be ridiculously
productive, but only after 10 years[1] of learning and gaining experience in
LISP. Most projects don't have 10 years for you to become productive in the
language of choice.

[1] Yes, I am exaggerating. It would only take 9 years to become highly
productive in LISP.

~~~
dagw
I've done basically exactly the same thing. Much of the webapp is written in
python, but the core performance critical part is written in C++. There
basically wouldn't be any other way to make that particular app work, and this
approach worked really well.

That being said, I never felt particularly inclined to write the whole things
in C++.

~~~
o2sd
> That being said, I never felt particularly inclined to write the whole
> things in C++.

Agreed, however one of the problems we are encountering is passing messages
efficiently between RoR and the C++ components. Currently using XML until
another method that is more efficient, but no less flexible, presents itself.

Personally I think the debate should be less focused on which language to
write your web application in, and more on improving the glue between
different languages so in developing web applications we can have the best of
all possible worlds.

------
overgard
Here's the thing, writing a web app in C is like using a flame thrower to
light a candle. Yeah it's possible, but it's dangerous as hell at best and it
doesn't really gain you much.

And this distrust of other's libraries is odd. You're already running on an OS
that's providing millions of lines of code to you in the form of api's and
services, and using a compiler that's going to do all sorts of modifications
to what you've created at the machine code level. You're already well into
trusting a lot code that's not yours. But something that's a million times
easier (parsing HTTP headers), and now they're worried about other peoples
code? Seriously?

~~~
joe_the_user
Being in the process of writing a c++ web client, I am strongly inclined to
agree with your assessment of c and web apps.

The one thing is, if someone does write c web apps - having your own set of
libraries can be useful exactly then. The web has all these crazy encodings
and protocols and knowing exactly which way your library does them is really
useful when you use a language with no safety net or safety switch or
anything.

Spent the afternoon figuring out, sort-of, the url encoding of reddit's "api"
and how it interact with Qt's QURL class.

------
puls
Why must the standard of discourse always be "I'm right and you're wrong?" It
seems to me that more often than not in this technological day and age, the
situation is much closer to "I'm right and you're also right, and between our
two positions there's probably something for both of us to learn."

~~~
mattgreenrocks
Intellectual honesty is not a strong feature of the Internet. I point this out
whenever possible, but nobody seems to really care.

The medium selects those who are both loudest and have an adequate factual
basis. Peppering statements with "In my limited experience," makes you seem
meek, unfortunately. Blame the culture of needing traffic and thriving on
controversy. It feels like it is a race to the bottom. :(

~~~
_delirium
I had an interesting discussion about that with some professors as well. It
might not be _as_ bad as on the internet, but it does happen, in both research
and instruction, to some extent. One prof I know pretty well, who's a good
teacher, was lamenting that his students seem to actively _want_ him to be
definitive and un-nuanced. His tendency, which he has to work against a bit,
is to qualify statements by noting where his views aren't shared by everyone
in the field, where he's speculating past the established results, where he's
pretty confident of an approach but there are arguments for alternative
approaches, etc.

But students tend to interpret that as weak and muddled, and prefer profs who
"tell it like it is", even if that means in a fairly biased and opinionated
way. It seems they _particularly_ like it when you make black-and-white
statements that would be controversial, roughly equivalent to "there's a
debate on this but you don't need to know about the other viewpoint because
it's wrong".

------
alexchamberlain
THANK YOU! I totally agree that it is not unreasonable to write websites in
C/C++.

I've just started looking into writing Nginx modules, which are generally
written in C. Now that I've started to understand it, I can write secure
content handlers in a reasonable time and reasonable effort, whilst being able
to use the exhaustive libraries on offer, as well as my experience with the
language. Couple this with great performance, and I can't justify writing apps
in PHP anymore. We're moving more and more processing to the client , as we
have realised that networks are pretty slow. Well then, how do you justify
writing slow code behind the slow network?

I highly encourage the author to look at writing Nginx modules, possibly not
on a hackathon, since you get security and fantastic performance for free!

------
jacques_chester
The big reason for avoid C++ is to avoid bugs and security issues. In
particular, overflow attacks. That the language requires constant, conscious
diligence to achieve a security baseline that comes for free in other
languages is wasteful.

Then there's the library/tools situation. I did all the work for my honours
dissertation in Ruby in part because the Ruby ecosystem is vast and vibrant
(sometimes inconveniently so).

I imagine that the C++-for-the-web ecosystem is going to be a bit more
spartan.

~~~
daemin
Do you actually mean C?

Since in C++ you can use STL classes for buffers where they are automatically
resized as appropriate, streams for IO, etc. So you'd effectively have the
same resizing and safe objects to work with as in a higher level language.

As far as I see it both C++ and Ruby have a similar amount of libraries that
can be used, they both have a major web framework, Rails for Ruby and OKWS for
C++, and there's probably a plethora of smaller frameworks and helpers
available for each language.

Rails may seem like it would be winning (versus C++) on the ecosystem, but
that's because there's so many hip gems for Rails out there, but if you take a
look at all libraries it probably won't be so.

~~~
jacques_chester
I mean both, though OP addressed C++. And you've proved my point.

Proper use of carefully-written classes will reduce the risk of a buffer
overflow -- but you will need to exercise _additional vigilance_ ("Make sure
you use STL! Why isn't this code using STL?" etc), over and above addressing
the problem, to ensure string safeness is assured.

That's a dead loss that programmers in memory-safe languages simply don't have
to pay for the same level of confidence.

~~~
daemin
I consider the STL to be (essentially) part of the language, hence to program
without it, isn't really programming C++ anymore. This is especially true
since the introduction of C++11, where the STL enables many language features.

Essentially a string is std::string, a resiable buffer is std::vector<unsigned
char>, and for a string or a resiable (or unknown size) buffer to be anything
else you need to provide a very good reason.

I would also be careful with Ruby since a lot of (performance specific) gems
and plugins for Rails are written in C, and hence potentially suffer the same
problems that one is trying to avoid by using Ruby. Or at least you end up in
the same boat if you were using C or C++ to begin with.

------
petercooper
_[..] I haven't had a reason to touch them. The few times I've seen or heard
about them, it's all been linked to frothy people clamoring for the latest
shiny thing._

Avoiding a technology by applying a frivolous standard like this is a good way
to miss out on useful learning experiences.

"Doing" is great, but stretching your boundaries and trying new things outside
of your comfort zone is an essential part of being a well rounded programmer.

~~~
rachelbythebay
Ah, you grabbed onto the second sentence while dismissing the first. I avoid
them because I haven't had a reason to bother. The task could be accomplished
some other way, and was.

I've used plenty of things used by "foamers" out of necessity. I don't enjoy
it, but it does get the job done.

~~~
petercooper
_I've used plenty of things used by "foamers" out of necessity. I don't enjoy
it, but it does get the job done._

An unpleasant subset of a technology's userbase has no relationship to the
usefulness or learning experiences relating to the technology and is of no
relevance to the well-rounded, life-long learner.

Being distracted by the _who_ in technical pursuits is a burdensome impediment
against learning the valuable _whats_ and _whys_.

~~~
rachelbythebay
You have to work with the 'who' to actually get anywhere with some of this
stuff. And some of these communities are less than friendly. Some of them are
outright hostile.

Does that help?

~~~
kragen
Also, the other users of Ruby are the ones who wrote the libraries you get to
use in a Ruby program. Which is pretty relevant to the person in a nearby
thread who implicitly equates using the Linux virtual memory system to using
Rubyful Soup.

------
_delirium
I agree they're not a big deal per se, but I do find them _clunkier_. Facebook
seems to agree, and argued that it was worth expending the considerable
engineering effort it took to write a whole new PHP runtime, just to avoid the
obvious alternative, writing more of Facebook in C++. Though Google does write
a lot of its backend stuff in C++ successfully, so culture and what kind of
web software you're writing may be part of it.

~~~
alexchamberlain
No, Facebook had LOADS of PHP code thst sas failing terribly. It was easier to
write a PHP compiler that a rewrite in C++.However, now they have control of
the compiler, they can probably slowly replace the PHP with C++.

------
akkartik
Perl and python and ruby aren't just easier because they have more libraries.
They're easier because they have hash literals, a more flexible module system,
etc. (ahem, implicit/dynamic type checking)

I agree that the reliance of rails apps on gems is unfortunate. They're
rediscovering DLL hell for themselves. But the original DLL hell was all C++
apps. You can shoot yourself in the foot with over-reliance on libraries in
any language.

~~~
NathanWong
It's not clear that this comment is addressing any real issues.

Firstly, std::unordered_map is officially part of C++ now, and it's been
available in all major compilers for a long time. Secondly, there's no
substantial evidence provided to support the claim that the module system in a
dynamic language is "more flexible" - anytime you want to include someone
else's code in your source tree in any language you can just drop the source
in as though it was your own. Whether there's a "package manager" to hide the
references for you is beside the point; it's not as if the concept of shared
libraries is lost upon C and C++.

And "ahem" does not establish a valid argument as to why dynamic type checking
is "easier" (whatever that even means). In fact, I believe a strong argument
could be made that dynamic type checking is the worst aspect of dynamic
languages, and the interest that Haskell has been brewing up lately would tend
to support this. Static type checking brings bugs to the forefront when the
developer is in the room instead of the user. One could argue that runtime
reflection provides more flexibility and thus makes dynamic languages
"easier", but it's a stretch to extend that to dynamic typing.

I'm unsure of how DLL Hell would even apply to a SaaS application, unless
we're referring to completely different things; you have complete control of
your application's environment in a web app. If there's a package already
installed that you don't want or something is missing, you remove it or
install it. With the prevalence of virtualization and virtualization-as-a-
service, there's no reason to be trying to run two different applications that
require different dependencies on the same virtual box.

~~~
akkartik
It sounds like you're claiming C++ is as convenient as a 'HLL'. If so, I think
the divide is too great for us to talk across.

I've worked in C++ for ten years, but I think scripts in perl or python are
more convenient for many tasks. I haven't met anybody who disagreed about
something so basic, so I'm not sure how to respond. I use unordered_map _all_
the time, but I wouldn't claim it's the same as support for literal hash-
tables _in the language_. Implicit typing is useful if I am happy to allow my
tasks to die at runtime because I screwed up. After all, C++ apps often
segfault when I screw up.

------
boneheadmed
I have to say that I like the perspective. I think that a good programmer
should be able to use virtually any good language to create anything.

In particular, it seems worthwhile, if for example one is well versed in say
Ruby, to learn C to get at the root of what is occurring "under the hood". I
really enjoy Ruby, but I'm learning C to fully immerse myself in what is
occurring with the bits and bytes (or at least the bytes).

------
gaius
Ah, you kids! Back in the '90s, we thought nothing of building websites in
NSAPI.

------
racER
Well, I can't see any specific advantage on using C/C++ as backend of a plain
old CGI API. Personally I'd use PHP or something like that, which integrates
tighter with the web server. Using C on CGI is propably not very much faster
compared to an optimized PHP environment with precompiled (cached) p-code.

> "C programs are suspectible to memory corruption." (tptacek)

Yes, they are, because in C you _can_ do memory corruption, in many other
languages you _can't_ (even if you'd want to). But where do these corruptions
most likely occur, when speaking in context of web applications? Yes, in I/O
and string operations. And all these can be mitigated with somehow "safe"
classes - by these I mean not a home-brew string-class, but something like STL
(which has proven stability).

However, is memory corruption the only security risk? In my opinion, an
average C/C++ programmer creates more secure code than an average PHP
programmer - just because a C programmer is _used_ to the intrinsic security
issues, while the PHP coder won't produce an buffer overflow by not validating
input, but leaves eg. XSS or SQL injection holes.

Writing a web application in C without preparing for safe I/O & string
operations is as bad as writing dirty script code in PHP/Perl/Ruby/...

At my company we've written a really big web application (a hosting control
panel) completely in C/C++, but for other reasons than execution speed: the
runtime dependencies of a sellable web application are pure horror.
Neverending CPAN-depencencies in Perl, incompatible function changes in PHP,
and so on. With a monolithic app (web server & application logic all-in-one)
you just need a libc - that's all. Easy to roll out, and thus easy to sell. :)

------
16s
I've used C++ with cgi for years too! Glad to see others do it too. Makes for
blazing fast web apps and I'm just more comfortable working with it.

------
mwd_
Choosing a good language for your project is all about understanding trade-
offs and the overall space of languages. It's hard to do this if you only know
C++ and view everything else with suspicion. The comment "...back to
programming languages, one thing that always bothers me is why new ones keep
appearing" sounds like it was written to satirize that sort of perspective.

------
ComputerGuru
Does anyone know a _real_ (not proof of concept) FastCGI C++
library/framework?

~~~
sciurus
<http://news.ycombinator.com/item?id=3449294>

------
scscsc
I find it ironic that the author says that you should just shut up and make
stuff without taking his own advice (the part about making stuff will probably
follow soon).

Having written a C(++) web-app (using CGI), I'm ok with writing in C++ (it's
not _that_ bad), but the advantages of using a language more suited for web
development are not negligible. The author would probably find this out the
hard way (if/when (s)he gets to making stuff).

~~~
obtu
Here's the followup: <http://rachelbythebay.com/w/2012/01/10/cpp/> It's a
round-up of her recent blog posts about super trunking scanner, which scans
airwaves and displays the info it gleans to a web ui.

------
lrobb
The reaction to this piece is interesting... I was sort of "ho-hum" about it,
but I've written many a "web-app" in c/c++ - cgic on linux, isapi on
windows... not to mention socket servers with thread pools implementing custom
protocols...

I don't say that because I think it makes me special -- it's what we ALL used
to do because that's the only thing we had.

After you've done that for a few years, you become VERY efficient at banging
out code.

------
krf
qDecoder by Seungyoung Kim (www.qdecoder.org) is a terrific open source
library for using CGI with C and C++.

A lot of us did what this article mentioned - but probably in the 1990s when
desktop programmers were moving to the web. Most probably settled on Perl
after trying C and finding development was much faster with Perl.

------
albertsun
OkCupid is written in C++

<http://www.okcupid.com/about/technology>

------
reactor
<http://www.treefrogframework.org/> might help.

------
jterenzio
> At some point, you just have to shut up and make stuff.

Amen.

------
hackermom
For those who never dealt with the server end of the web in the mid-to-late
90s I can tell you that native executables for CGI was at that time not the
least rare or uncommon.

~~~
biasedstudy
Having a lightweight, standalone executable with quick start up time is still
a major win.

~~~
cageface
What about caching database connections? Opening a new connection on every
request can be very slow, particularly for Oracle.

~~~
javadyan
One may consider using FastCGI to avoid the costs associated with starting a
new process with each request.

------
rubashov
This plus something for disk persistence is totally sufficient for writing web
apps in C++:

<http://cgi.sourceforge.net/>

~~~
akkartik
Disk persistence was actually the question I came to this thread with after
reading the article.

------
jQueryIsAwesome
Some of her points are vague and unclear:

> that somehow you would need to abdicate almost all of your code to modules
> where you just hope they work

Well, you are using jQuery, jQuery UI, jQuery Player and jQuery Scroll-into-
view in your example project, that is actually a big pile of modules if you
ask me.

------
drivebyacct2
Why C++? Go (golang.org) is too much fun!

~~~
drivebyacct2
I wish I could edit this comment, I think more explanation would have helped.
Go is low level (originally marketed as a systems-level language), but it
really is truly fun to use and it has whole swath of really comprehensive
libraries for throwing together web apps very quickly. (SPDY, WebSockets, and
much more, but I appreciate those features out of the box)

------
madaraz
There is a reason that NO major web application you name is written in C++,
Gmail, Facebook, Google Docs, YouTube. There are major advantages to writing
web applications in a higher level language and almost no advantages to
writing them in C++.

~~~
javadyan
I doubt that the parts of YouTube responsible for video-related heavy-lifting
(transcoding, detecting copyright infringement, etc.) are written in a dynamic
language like Python, Ruby or PHP or even a managed language like Java.

~~~
radarsat1
I always imagined that they just patch together a bunch of calls to mplayer
and ffmpeg using a bit of shell script.. ;)

~~~
javadyan
and by "algorithmic processing" I mean detecting when the video contains a
pirated song, for example.

~~~
alexchamberlain
I'm sure you could script that out to somone else... :oP

