Slashdot Mirror

There was another Slashdot story a few months ago that C was making a comeback. Now Slashdot ponders if Ruby, one of the languages that contributed to the "death" of C can make it another 25 years.

The answer is no. At least, not in the way it is now. I suspect that, like Perl and Python and other interpreted languages, Ruby will always have a little niche of users. There will always be projects that are well suited to the ease of letting your programming language do all the thinking for you, and which don't care about the performance hit. JIT, if it makes it into Ruby, will further extend this, especially for the (often rather vocal) crowd that thinks JIT is magick that makes an interpreted language just as performant as compiled. Unfortunately, there is no fairy here, and Ruby (like the ones before it) will never be a real boy.

A comment made by one of the developers of PiTiVi (an open source video editor done in Python) on the how-to-contribute page for that project actually sums up Python in general, and also extends quite well to my thoughs on Ruby and most others in the same vein:

GStreamer Editing Services, the C library on which Pitivi depends to do all the serious work. If you want to work on the backend, this is the way to go.

Which is a great summation for Python, and is so applicable to Ruby as well it could have been written about it. Great for quick and dirty little tools, good for a project framework perhaps, but if you want to do serious work, go to a C library. This will always be the case. Ruby and Python and Perl and even mighty Java, they will have their niches supported by adherents who expound some aspect of their garbage collection, or ease of use, or type safety, but for the real work, people will always turn to native code. In a few years there will be some new debutant... there will always be some new debutant, bright and beautiful in that sparkling ball gown, that will draw all the ooohs and aahhhs of the boys in the crowd and which will rally the people to cry "this... THIS is the one that will kill native code dead once and for all", and yet it will never happen.

Care to point one out?

PyCAM and PiTiVi are two off the top of my head. PyCAM is CPU bound and Python doesn't do its calculations any favours. It's sluggish at the best of times and almost impossible to produce versions that work cross platform. PiTiVi isn't terrible as basically it's just a front end for GStreamer, and as that it's a good use of Python. But it's not cross platform, which defeats half the purpose.

Interestingly, looking at the PiTiVi web site, on the contributing page:

GStreamer Editing Services, the C library on which Pitivi depends to do all the serious work. If you want to work on the backend, this is the way to go.

Which just about sums up Python. Great for quick and dirty little tools, good for a front end, but bad in that most serious front ends require a widget kit that will be problematic for cross-platform, and if you want to do serious work, go to C.

And as you seem to live under a rock: Java is no longer interpreted, since u .. o ... 1995 or so?

Not sure what native compiler you're thinking of. Maybe I do live under a rock. GCJ is gone - GNU is trying to sweep it under the carpet as the bad idea it was, since it never really worked well (read at all). Ok, doing some research I see that there is some product called Escelsior Jet that claims to be a compiler. However, from its web site:

First, the AOT compiler turns your jar and class files into a conventional binary executable. That executable is fully interoperable with our JVM, which includes a JIT compiler to handle any classes that were not precompiled.

So it's not clear if any general purpose Java app can be rendered into 100% native code. It looks like it will do all the pure Java, but how many normally used Java classes this includes is another question. I have never ever heard of Excelsior Jet before, and neither has Wikipedia. It's mentioned in a couple Stack Exchange questions, likely posts from employees at Excelsior Jet in my assessment.

If it is JIT you are speaking of, JIT is not native. JIT is a marketing term for various usually caching optimizations intended to make interpreting bytecode less slow. JIT means different things to different interpreters, but it always involves run-time conversion of bytecode to machine code, which is what interpreting is, and despite what marketing people say, is universally slower than AOT conversion to purely native code.

I guess you have a different idea what "system progaming" is than most people. System programming is not done in C since decades. You probably mean the remains of embedded programming where people are forced to use extremely small micro controllers for extremely simple tasks. The biggest "system programming" project that still is mostly done in C (instead of C++) is probably the linux kernel.

This is just wrong. Windows kernel, plus many device drivers. BSD kernel plus most device drivers (except in MacOS which uses a subset of C++ for device drivers). Linux kernel, as you mention, plus almost all device drivers. Every other Unix kernel and all their device drivers. Virtually the whole OS for most real time OSes. That right there is 99.99% of computing devices on the planet. C is very large on the military scene right now. Most Western navy's combat management systems are more or less entirely C, or use such a stripped down subset of C++ that you might as well call it C anyway (see below). Some colleagues of mine on the aircraft side of things played around with realtime java a bit for avionics, but it didn't really go anywhere.

Some will use C++ for drivers, though in many operating systems that's problematic because of the runtime, so they use it stripped down again. Mayb

PiTiVi is still going strong, even though it only take 30seconds to break it in Unity.

Probability of seeing it in 16.04 is about $12,327 to 1+ bug reviews of whatever Ubuntu-Y will be.

PiTiVi is still going strong, even though it only take 30seconds to break it in Unity.

Probability of seeing it in 16.04 is about $12,327 to 1+ bug reviews of whatever Ubuntu-Y will be.

Arch and Fedora already provide Pitivi 0.92. It can also be installed on Ubuntu/Debian, see http://www.paulox.net/429 If you have suggestions on improving http://wiki.pitivi.org/wiki/Bu... or need help with it you can find us on Freenode#pitivi.

Disclaimer : I'm one of the Pitivi's developers, and I'm very excited about that campaign. We feel like Pitivi's technological choices (being based on GStreamer), and its large community make it the most promising open source video editing application out there ! I encourage you to visit our website for that campaign at http://fundraiser.pitivi.org/ , as we've put a lot of effort into explaining all this in details !

PiTiVi (wp) seems interesting, not tried it myself so far.

I guess I'll be the first to give a shout-out to Pitivi and Open Shot Video.

Reading Jonathan Thomas' ( Open Shot Video ) valiant attempt at creating a NLE from Gstreamer/Gnonlin it appears that the Gnonlin API/toolkit/whatever is VERY confusing to program a video editor in ( and unstable ). But since Jonathan chose MLT things are rapidly moving along for him. I often wonder why KDEnlive is so unstable because Kino is rock solid ( for me ) and it is also based on Dan Dennedy's impressive MLT toolkit.

But I truly believe that Pitivi will be the defacto NLE on linux. For the sole reason that Gstreamer is the defacto multimedia framework. It will probably be another five years before Pitivi is really a good stable functional application, and I say that because it took Gstreamer 10 years to do the same.

There are currently other alternatives under development for those interested. Among those, check out PiTiVi for something based on GTK and GStreamer. They need hackers. (And there was also a speech about it at the GUADEC, you might want to take a look at the video archives)

A GStreamer-based video editor for Gnome:

http://www.pitivi.org/

You may want to keep an eye on PiTiVi http://pitivi.org/ it is a "GStreamer based non-linear audio/video editing software" it is still in really early development but looks to have great potential. It's aimed at the average joe home movie maker, so pretty much most people :) GStreamer is so beginning to rock hard!!

I read a discussion about this a few days ago on elysiun (Blender-centric site)... the consensus is that there aren't any really solid GPL NLEs out there yet, but there are lots of attempts:
http://www.pitivi.org/
http://kdenlive.sourceforge.net/
http://positron.sourceforge.net/

That, for me, is one of the biggest stumbling blocks for a fully-open movie... I can't live without my Final Cut Pro. Are there any other options anyone knows about?