| |||||||||||||
XDC2012: Programming languages for X application developmentXDC2012: Programming languages for X application developmentPosted Oct 10, 2012 3:02 UTC (Wed) by ncm (subscriber, #165)Parent article: XDC2012: Programming languages for X application development
When I see "C/C++" referred to as if it identified a single language, it warns me that someone is about to write something foolish, or worse. That expectation was fulfilled here (albeit through no fault of Michael's.)
Where to start? If memory leaks in C programs are somehow a worse problem than reference leaks in GC languages, why are the GC programs (most commonly Java, and Javascript in browsers) predominantly the ones that trigger the OOM-killer, or just crash with out-of-memory? How is C++, which provides copious support for automated resource management (not excluding memory management) in the same category as C, which offers none?
To say, "C/C++", makes sense in exactly one context: when identifying languages that can call into a library without a wrapper layer. Then it is a statement about the library and its interface, not about the languages or their properties.
The ability of UI framework coders to make any supercomputer feel like an HP-41 is legendary. Machines are a thousand times faster than in the '80s, yet GUI programs are as slow as ever, achieving very little more useful work, and often less. The problem to be solved is not to discover some magical language to consume even more overhead. It's to deliver to coders the existing power of existing machines in a way that allows that power to be applied to benefit the user. The problem was identically the same ten years ago. The slow progress is a disgrace.
Qt and GTK displacing other frameworks is progress only in the sense of consolidation: fewer coders are obliged to use the even-worse ones. Both still define their own universe of data structures that must be translated to and from native structures and wire protocols. Both (but GTK more than Qt) fail to take advantage of advances in programming language design since 1983. These failings leak into code that uses frameworks: Mozilla code, while nominally C++, infamously shies from all of the language's facilities that post-date 1990.
Modern language facilities embodied in standard C++ enable writing libraries that are more expressive than is usually achieved in a specialized language, yet without the overhead of another abstraction layer.
There is one shining example of progress, of user interface design exposing the power of modern hardware to users: twitch games. How sad that whenever they must do what another programs does, they fall back to doing it the same way, with all progress forgotten.
(Log in to post comments)
XDC2012: Programming languages for X application development Posted Oct 11, 2012 14:58 UTC (Thu) by HelloWorld (guest, #56129) [Link] I agree, the article is wrong in so many ways that it's hard to tell where even to start. You already mentioned C++' extensive support for automatic memory management through RAII. Saying that C# offers no advantages over Java shows utter cluelessness. Just to name a few: properties, operator overloading, the yield statement, lambdas/delegates, LINQ, reified generics, extension methods and probably tons of others that I've missed. He also seems to have no clue how GUI builders work nowadays. Qt designer and Glade aren't used as code generators. They generate an abstract description of the GUI (usually XML), and the event handlers are then connected automatically to the appropriate callbacks using things like GtkBuilder and QMetaObject::connectSlotsByName. And the fact that he doesn't know how to use these GUI builders right (as shown by his inability to create a flexible layout using these tools) speaks for itself. That leads me to another point where he's utterly wrong: Objective C. He says that it provides features that C and C++ don't. While that is technically right, it doesn't really matter. There are GObject and moc, which add the same kind of introspection that makes Objective C successful (OK, GObject is actually a pain to use, which is why Vala exists) and allow technologies like the aforementioned GtkBuilder and QMetaObject::connectSlotsByName. He also seems to be confused about control flow in web applications. Web applications use all kinds of callbacks for all kinds of things, yet he calls callbacks a "complicated flow of control" and "challenging for programmers" (I actually think that if you don't grok the idea of a callback, you shouldn't be programming at all, but the point is that web and desktop applications don't differ at all in that respect). There are also a few very important points that are completely missing from his presentation.
|
|||||||||||||