Archive for the ‘Programming languages’ Category

EcmaScript is no assembly language

Wednesday, September 28th, 2011

Hi!

Windows 8, Tizen – there seems to be a HTML 5 + JavaScript hype. The myriads of web developers are expected to write all their stupid apps to make a platform popular. Some may know that I really do not like EcmaScript, however, it is good to allow using it, there may be domains where it is appropriate, there may be cases where it is the best choice to reuse some EcmaScript code. But seriously, that way technical possibilities get wasted. Reusing all the high-quality desktop application code – nearly impossible. Using certain paradigms of great programming languages – nearly impossible. I know, you can translate LLVM IL to EcmaScript, but EcmaScript is really not an assembly language. That it is not its purpose and it is not suitable, do not tell me V8 would be good, it cannot transform EcmaScript to an assembly language, even Google is now propagating Nativ Client (NaCl), really cool technology, to allow any language (great developments of the past!) being ed, by reusing existing languages, suitable as universal low-level representations: x86 machine code and LLVM IL. It had taken long time until there was finally a usable version of Qt for Android (Necessitas), reimplementation of everything and Java got in the way of a quick port, although there has always been the possibility to use native object-files. How long would something usable take for Tizen? And do not forget: Qt is huge an popular, it may be unaffordable for other projects somehow relying on certain OS capabilities. Thus, why not just supplying existing API? Why not just keeping great ecosystem, being open for new innovation and new technology which is compatible with it? Why limiting everything with EcmaScript’s poor capabilities? Web developers can still be attracted, EcmaScript and even HTML 5 can perfectly be combined with Qt. Even Apple failed with its original web-apps-only strategy, why should anybody else succeed with that nonsense now, years later? Microsoft is despaired, Google wants to control everything with Chrome OS, but why the hell should MeeGo be dropped?

New HTML/JavaScript-focused architectures: you suck.

PS:
Tizen wants to allow native access, but they “anticipate” that most stuff should be written with EcmaScript. Thus it will certainly not be easier than with Android to reuse existing technology.

Regarding Dynamic Typing

Sunday, July 10th, 2011

Currenty there seems to be a big hype about EcmaScript (JavaScript). Google probably wants to enslave the world with Chrome OS, where the system is not much more than an EcmaScript virtual machine provider (maybe it will support native applications through NaCl, like Android does not only allow Java…), Microsoft wants to reimplement their Windows interface, Qt invented QML, the EcmaScript extension we all know about, providing cool declarative features. Today I want to talk about a fundamental property of EcmaScript and why it just sucks: dynamic typing.

Clarification

First let us clarify the meaning of “dynamic typing”. “Dynamic typing” means that the type of expressions gets checked at runtime, expressions which may have any type are possible. It should not be confused with duck typing, e.g. many types using dynamic typing have a lot of built-in functions relying on specific types (“the frog will not get accepted”), e.g. most functions in PHP’s standard library (expecting string, integer, array or what ever). But for example C++ function templates in etc. provide duck typing (they will accept anything looking like an iterator), or the signatures in old g++ versions provided duck typing. Determining types may happen at compile time (type inference) even with dynamic typing, and of course optimising compilers/interpreters are doing that.

Impact on Development

Let us talk about an argument for dynamic typing: it makes life easier. Actually, that can be right, there are domains where you just do not want to care about such stuff, for example when writing a shell script with few lines of code or when quickly doing some calculations with a computer algebra system. But Typo3, MediaWiki, Windows, Plasma etc. are much more than that. Why do I doubt that dynamic typing makes life easier in those contexts? Because it is error-prone. It is always better when errors get detected at compile time. It is good to fulfill contracts when programming, and they should get verified at compile time, such that they can be easily found and will not annoy the user. A type of contract (not the only one, cf. design by contract) which has been used for long time is the type system. The programmer assures that a variable has a certain type. What happens in dynamically typed languages? You do not have to state the contract, the compiler (or code checker) will usually not be able to check it, it is just in your brain, but of course you will still rely on that contract, the type is something you rely on most of the time when programming, I know that x is an integer when using x for some arithmetics. But you will do mistakes and you get buggy software. That is the fundamental disadvantage when programming, but of course I have to compare it to the advantages of dynamic typing: you can write code quickly and efficiently not mentioning the type everywhere. But there are more proper ways to achieve that: use type inference. The type of a variable will be determined by the compiler when initialising it and you will get an error when you are trying to change the type. That is good because in most cases the type of a variable will not change. And you will get informed about undefined variables (a typo should not cause a runtime error, but in dynamically typed languages it does). For the case that you need a structure allowing different types at the same position there are algebraic data types. With algebraic data types you can state a contract with only few tokens (instead of a nested array/dictionary data structure with a layout which is just implicitly given by the manipulation of it, that does often happen in dynamically typed languages), for variable declaration you only need one token, maybe a single character. That minimalistic overhead in code length is definitely worth it once the software has reached a certain complexity. That threshold is probably not very high, annoying mistakes which could have been avoided with static type checking can already occur in small programs just computing some stuff or something like that.

Performance

Dynamic typing causes big overhead because instructions have to be choosen at runtime based on type information all the time. Of course it is much more complicated to optimise dynamically typed languages, there might be corner cases where the type is not the expected one, but the runtime has to care about it etc. I often read statements like “the performance critical parts are implemented natively” etc., but regarding the amount of applications running using such languages (JavaScript, PHP, Ruby, Python, Lua) we have to state: it is performance critical, PHP is used for more than a preprocessor, QML is used for more than just representing the UI, JavaScript is used for drawing a lot of complex stuff in the browser, Python gets used for scientific computations, and Ruby is establishing new standards regarding overhead (that is not true, Scheme has been that slow before ;), but Ruby allows modifying a lot of stuff at runtime, too). There is reasonable overhead—for abstraction, generalisation, internationalisation etc., but dynamic typing affects nearly any operation when running the program, that is unreasonable and of course it will sum up to significant overhead, although it is simply not needed (and bad for environment ;)).

Special Issues

Regarding extreme flexibility

First of all: in 95% of applications you do not need it, you do not have to modify types at runtime, adding member functions to classes or objects and all that stuff. Sometimes it may be a good way to establish abstraction etc., but in those cases there are usually alternatives: meta-programming can be done at compile time, when manipulating all the types in Ruby they usually could have been manipulated at compile time, too, but Ruby does not support sophisticated compile time meta programming (ML and Template Haskell do, in C++ and D it is kinda limited). Regarding collection of information, debugging etc. using such features: debugging facilities should not influence the performance and cleanness, I am sure by involvement of meta programming you could implement language features allowing that when debugging without neglecting the type system. And of course a lot of flexibility at runtime can be achieved without allowing any type everywhere: dynamic dispatch (including stuff like inheritance, interfaces, signatures and even multi-dispatch), variant types at few places (e.g. QVariant, although I think it is used too often, signals can be implemented in a type safe way, and there are those type safe plugin factories as alternative to QtScript and Kross), signals and slots, aspects etc.

Regarding EcmaScript

You might say that EcmaScript is becoming fast enough because of good compilers and extensions like type safe arrays (e.g. containing only floating points). But EcmaScript will stay EcmaScript, it will keep the downsides of dynamic typing, those type safe arrays are an ugly hack to make it feasible for some specific applications. It is simply lacking a proper type system and it will not get it.

Regarding QML

Using EcmaScript for QtScript was a pragmatic choice, no awesome innovation: there were many web developers knowing about JavaScript. Unfortunately that caused yet another way to integrate scripts and certainly not the most flexible one (cf. my previous blog post), for some reason they did not want to reuse KDE’s innovation (like QtCreator and KDevelop, but that is really a different topic…). QML is based on EcmaScript because QtScript had been based on it before. Dynamic typing is definitely not an inherent property of such declarative UI, most of it could have looked the same with a native implementation based on C++, but also implementations in Ruby or whatever would be easily possible. I have to admit that C++ is not perfect, it does not provide sophisticated meta programming, algebraic types or one-letter type inference (“auto” has four letters ;)), the last one may be a small problem, but overall it is simply not simple enough ;), languages like Scala, D and OCaml have certain problems, too. Hence some of the non-declarative code in QML would have been disproportionately complicated compared to the declarative code. The general approach of declarative UI is certainly good, and now we probably have to accept that it has been implemented using EcmaScript, we can accept it, as long as it is still possible to write Plasmoids using C++ or whatever etc.—obviously that is the case. Thus QML is generally a good development in my opinion, although implementing program logic in it is often not a good idea and although dynamic typing leaves a bitter aftertaste.

I hope you have got my points about dynamic typing. Any opinions?

Unification and Orthogonalisation: Part 2, Plugins and Bindings

Sunday, April 17th, 2011

Hi folks!

Part 2 of the series, there will be hopefully some more rational discussions. I want to review KDE’s plugin system.

There are currently three mainly used Plugn-technologies used by KDE projects:

  • KPluginFactory
  • Kross
  • QtScript

QtScript and Kross work similarly, both use qt-metacalls to allow scripts to access C++-objects. Thus it does only work for QObjects and only for q-properties, signals, slots and functions marked as scriptable. Additionally some data-types get automatically converted (containers, strings) and there is usually a fixed set of supported datatypes, e.g. QPainter etc. Both Kross and QtScript are easy to use, you can load script files and call functions using QVariants/QScriptValues and it reuses the QMetaObject-stuff. However, in my opinion there are a lot of downsides of those approaches:

  • You have to change the C++-code to allow interfacing with it (subclassing QScriptable, marking methods as scriptable etc.)
  • No easy way to expose functionality of non-QObjects
  • No plugins written in C++, which would be natural to have, although it would not be that hard to allow at least C-plugins in Kross
  • KDE application are usually programmed using object-orientation, even scripts are handled as objects, but inside the scripts the object-oriented architecture does not get continued, e.g. kwin-scripts are written in a procedural style, sometimes that is nice, but sometimes it would be nice if the script would follow the overall-architecture with plugin-classes or whatever

Some downsides are specific for QtScript:

  • It does not work with other languages than EcmaScript/JavaScript (no Ruby, Python, Perl…)
  • Sometimes QScriptable has to be subclassed thus making core-classes and plugin-functionality unnecassarily interdependent

Well, there is an alternative: KPluginLoader. Wasn’t that an uncool, unnecessarily complicated, old technology for C++-plugins? No, it is not. The idea is old (similar API had been included in KDE 2.0), but there are good reasons that it is still used although it has been indeed focused on C++: It is really flexible and it is really cool. Let me describe the idea: It is integrated into XDG-configuration-system, each plugin is described by a .desktop-file referencing a shared object file. A factory-object inside this shared object file is used to create instances of a plugin-class, which may subclass a class used to allow plugins inside the application (e.g. a Plasma::Applet, a KoShape or whatever). The factory is the reason for the flexibility of the architecture: There are specialised factories not simply allocating a C++-object but loading script-files, e.g. there are KRubyPluginFactory, KPythonPluginFactory and KPerlPluginFactory creating an object inside the scripting-language subclassing the plugin-class and exposing it to C++, but even more specialised classes libraries like plasma_appletscript_simple_javascript allowing a procedural interface. Those classes make arbitrary applications like Konqueror and KDevelop scriptable.

That is really cool, but there are limitations: Because the meta-object-system is not used there has to be a binding exposing the API of the application to the script. Of course it is nice that such bindings are orthogonal to the application itself and even non-QObjects can be accessed, but unfortunately it is currently complicated to add such bindings to an application. E.g. most bindings are using Smoke to access the libraries and the Smoke-Generator to generate the code for bindings, but you have to invoke it for each language, and the Python binding is using SIP. Hence it is comprehensible that many applications are using Kross or QtScript (though I do not see any good arguments for QtScript).

What could be done for unification? How could the dependencies between the plugin-functionality and the core-stuff be reduced? In my opinion it should be made easier to create a binding since that is currently the difficult task about scripting usin KPluginFactory, creating a plugin-class and invokin KPluginLoader to get plugins is not that complicated. A comprehensive set of cmake-macros would be cool, allowing to create bindings for Ruby, Python, Perl and QtScript using a single xml-file, it should detect pregenerated binding-files, invoke installed smoke-generators, convert it to SIP-information, and install it were the specific scripting-language expects the files. Creating such a XML-file would certainly not be more complicated than adding Q_SCRIPTABLE everywhere.

Maybe some of Plasma’s efforts to make scripting easy could be generalised to be usable everywhere in KDE-based projects (they did a good job ;)). Of course there should be a general purpose QtScriptPluginFactory (there is no such class, isn’t that strange?), but there are also some special features in Plasma, e.g. limitating the accessible API is a nice feature, it should be implemented in the plugin-factories, usually scripting-languages provide features to restrict importing of modules, accessing files etc., there should be a unified set of xdg-properties to specify what a script should be allowed to do. Using X-KDE-PluginKeyword to specify the script to load is also not very elegant, and passing arguments to plugins is also not perfectly implemented. Procedural scripting would be nice to have in many cases, too, e.g. there could be a KProceduralRubyPluginFactory automatically wrapping the functions in the scripting-file into a plugin-object in a generic way.

With such improvements we may get rid of QtScript and Kross, the architecture of some applications could be improved easily, and everybody could choose if he wants to use EcmaScript, QML, C++, Ruby, Python, Perl or whatever.

Disclaimer: There are always some people confusing thoughts and announcements, although the number of disclaimers does not seem to matter for them, there should be at least one: That is a review, some thoughts, no announcement for whatever. And I am familiar with the codebase.

Tried Variadic Templates

Wednesday, March 23rd, 2011

Hi!

Yesterday I tried to use variadic templates with gcc for the first time of my life. The compiler support is definitely good, it works as expected with –std=gnu++0x (it is never bad to use this option, it will add support for the -header and the auto-keyword, which makes code much more readable). However, I want to tell you how I think about this new language feature: It is ugly. Well, you can implement tuples with it, they are more compile-time-efficient than typelists and have a short syntax, the three dots work magically at some locations, but: they are not really handable, you cannot pass multiple of those “parameter packs”, as far as I know you would have to convert them into typelists to perform operations like concatenation, sorting etc., you can use a parameter pack as type-specification for the parameters of the function, but there is no more general concept for functions with flexible parameter list, partial specialization is still forbidden for functions, there is no way to access them non-recursively, sorry they are for meta-programming, and why should meta-programming in C++ look like programming in Haskell but more complicated? Why could C++0x/C++1x not fix that? I do not like D, because they do not have proper support for value-semantics, implicit sharing etc. and there are many inconsistencies (many of them are inherited from C++), but they added useful extensions for Templates, making them really usable for meta-programming. Pretty simple task: Write a generic function taking 0..∞ strings, which will print them. You will see the drawbacks, but of course I would be happy about more readable code:

#include <iostream>
using namespace std;
 
// a struct, because there are no partial specializations
// for functions
template<typename... args>
struct Print
{
    // checking, because you cannot explicitly construct
    // a parameter pack of strings
    static_assert((sizeof...(args)) == 0, "illegal arguments");
    static void exec()
    {
    }
};
 
template<typename... args>
struct Print<string, args...>
{
    static void exec(string x, args... rest)
    {
        cout << x << endl;
        // recursion, because there is no static-for (ammendment: unlike the foreach for tuples in D)
        print(rest...);
    }
};
 
// that function works
// but it would be probably three lines in D
template<typename... T>
void print(T... args)
{
    Print<T...>
        ::exec(args...);
}

I think you see what I meant, variadic templates are nice for printf and tuples, but for any slidely different tasks they are still ugly.

Yes, I used it, really (skip deleted files and minor edits), it was ugly, but it provides some abstraction making the code – probably not readable – at least less redundant (I do not like copy&paste programming, the reason for copy&paste programming the lack of nice meta-programming features). Some last words why I am not using D: in C++ I can achieve anything using templates and implicit casts, and I have real value-semantics, D did not want to be like Java, but it forbids some stuff which is responsible for a lot of flexibility in C++. And if I would switch the language, I would try to choose a language involving some new, innovative and consistent concepts, that is not the case for D, maybe for Scala, but it does not allow value-semantics, too.

Not everything about the Nokia-Microsoft-Deal is bad

Sunday, March 20th, 2011

At least Miguel de Icaza, founder of Gnome and Mono, thinks in a quite positive way about this deal, thank you, whilo, for the link. Well, what the hell is he talking about? He is a C# fanboy and he thinks abandoning MeeGo in favour of Windows Phone 7 is good for C#. I have always thought that there are some ideals which are more important to care about that the spread of a language, however, let us have a look at some arguments:

Although some open source advocates might see this as a set-back for Linux, Android is already the best-selling Linux OS of all times.

Oh, yes, we are just fatuous idealists, why should we care about the spread of Free Software if there is a free alternative? Wel, of course we should not care about the spread of digital restrictions management, because we can use our devices without DRM, etc. Sorry, that is ignorant, such a proprietary system like WP7, not even allowing GPL-programs, will certainly do harm.

This is fascinating turn of events for C# developers as Nokia will make WP7 more relevant in the marketplace, making C# the lingua-franca of all major mobile operating systems.

Wrong, according to his one diagrams C# had already been a lingua-france before the introduction of WP7. But there had been other linguae-francae, too, like C++ and EcmaScript, but he wants to support monopolists like Microsoft and the monopolism of a single programming language, why should there be choice? For the loss of freedom and choice he uses the euphemism “simplification”, aren’t iPhones quite simple, huh? Well, he did not mention MeeGo, which does not support Mono/.NET/C#, however, there was a Mono-port for Maemo, I am sure it would have been easily possible for MeeGo, too, why does he accept .NET – only WP7 is using .NET and Silverlight – and does not want Mono to be the “runtime-franca” for all devices? And of course he does not care about the millions of Symbian-devices, which support C++, Qt and EcmaScript/JavaScript.

We advise our users to split their user interface code from the engine, or their business logic. Developers should create a native experience for their mobile apps: one per platform.

Of course it is a good thing to split GUI and programm logic. But do you write different user-interfaces for GNU/Linux, Windows and Mac OS X? Is that useful? No, you can simply use Qt, QWidgets, Plasma or whatever and it will be an interface well usable with any keyboard and mouse input devices. But for different smartphone-systems you want to rewrite the whole user-interface? Having 3.5″ or 4″ multi-touch devices running Symbian, MeeGo, Android, WP7, iOS or WebOS, why should they get seperate interfaces written using different APIs etc.? That is nonsense, it would have been nice with C++ and Qt for Symbian, MeeGo, Android and iOS, or even an approach using C# may be better when using the same Mono-runtime with the same GUI-libraries (maybe Qt) for every device.

This is a grand time to be a mobile developer.

Sorry, no, as I explained, Nokia using Windows Phone 7 does not make the situation better, and it is a really bad time for Free Software. Why should there room for somebody like him in Free Software communities? I do not get it, he can start working for Microsoft if he wants to.

Sorry, but everything about the Nokia-Microsoft-deal is bad.

Equal rights for the void!

Wednesday, March 9th, 2011

Hi!

This post may sound strange, but it is about programming languages, so do not care, if you are not interested in programming.

Well, today I want to talk about the type “void” in many programming languages. It is a really special type, because actually it does nothing. In Java you cannot do a lot with this type, I think the only valid usage of “void” is for methods’ result-type, void is not really a type in Java, it is more like the procedure-keyword in Pascal. In Java there are some relicts from C which do not actually fit into the concepts of the language (e.g. switch). However, in C and C++ you can do more with void, it is somehow a “real” type. Such features may appear weird at the first look, but I think they are really nice:

  • You have void-pointers, you can cast any pointer into a void-pointer – explicitly or implicitly
  • You can cast any value into a void-value, which you canot use then – explicitly or implicitly (cf. the definition of Q_UNUSED)
  • You can return any value from a void-function

Well, for long time I could not imagine what this could be good for. But now I think: that is really beautiful. When should implicit casts be allowed? When thinking about it, you may notice two cases: coercion from one type into a more powerful one (e.g. int → long), and coercion from one type into a more general, weaker one (e.g. QWidget* → QObject* or iostream& → istream&). But it is basically the same, consider types as sets or families of possible values/objects, implicit coercion from type A into type B is possible, iff A ⊂ B (A subset of B). And any operation supported for elements of B should be supported by elements of A. Which operations are supported for values of the type void? No operations, so all operations supported for void are supported for all the other types, why should we not cast from any type to void?
That is supported by C++. But unfortunately there are limitations: You cannot have void-variables or constants, but that would nicely fit into the concept and sometimes it would make generic programming easier. You cannot dereference a void-pointer, but why should it not simply be a void-value as usual? And of course it should be possible to allocate void on the heap, it should be just NULL, and the address of a void-value should be NULL, too. It is okay for me, if the compiler wants to warn you about your usage of void, but just for consistency in the language void should not be that different from the other types, and not having variables of that type is simply not very nice. Equal ights for the void!

However, there are two things which may be not so nice: 1. When considering two sets represented by two types and one set should be a superset of the other set, you have to consider some elements of those different sets being equal, and of course in practice you do it all the time when comparing ints with shorts etc., but for voids that is impossible, you cannot decide, if two void-values are equal, and 2. you cannot explicitly cast back from a void-value to a non-void-value. However, void-values are not the only ones, where comparison is impossible, though for the most frequently used types it is of course possible. Consider functions (handled at runtime) internally stored using some kind of an arithmetic formulas, Turing-machines, Lambda-calculus or whatever. Generally it is not possible to decide, if two of such functions are equal (unless the arithmetics are too simplistic), notice that there are many different representations for the same function. So requiring values to be comparable is not very clever in a general-purpose programming language. In practice for some types you may not even want to support the equality-test, because it may be difficult to implement or very slow or something like that. That are my reasons, why I think that the first issue is void. I currently cannot imagine any two types different from void where explicit casting is only possible in one direction. Maybe you can? However, if the type does not support equality-checking, after casting back and forth you cannot even say that the value is identical to the original one. But this issue remains unsolved. However, altogether I think that void should be a real type in our programming languages, because it is very consistent, and it should be different from nil/NULL/None, because nil/NULL/None should indicate the absence of a value of one specific type, and not the void.

Or I can put it that way: The void is like qualia: it is everywhere, it is contained in each individual, it does not express anything specific, you cannot differentiate between “my” and “your”, and of course you cannot cast it back to the individual with its personality.

:)

PS: My statements about allocation a position 0 were wrong in my opinion. Cf. the comments.