As for the speech in question, I did not find it very interesting, basically it can be comprised into Massey saying -'gui apps on the desktop is hard for me, I believe it has to do with the fact that I don't understand desktop programming languages, we need to make it easier to create gui apps on the desktop for me because I've bought into the lie that it is in trouble due to competition from mobile/web', followed by -'I have no answers or anything concrete to back my statements with but that's what I've heard people say '.
As for the speech in question, I did not find it very interesting, basically it can be comprised into Massey saying -'gui apps on the desktop is hard, I believe it has to do with programming languages, we need to make it easier to create gui apps on the desktop because it is in trouble due to competition from mobile/web', followed by -'I have no answers or anything concrete to back my statements with'.
Summed up quite well.
His arguments against C++/Qt were funny, too, especially for a "man with experience":
All those includes. Handcrafted Layouts that misbehave when resizing the app.
Handcrafted Layouts? Doesn't he know about Qt-Designer, or (if he codes the widget layout by hand) QLayout and its subclasses?
And again bashing moc... Well, OK, it's sort of a blackbox. But you can rely on it. And IMHO he disqualifies himself as someone who is able to call a language as desktop-app-capable by saying "well, I don't understand the code moc produces". Ah, OK...
In the end he even had to say that until now he was not aware of QtQuick/QML. Erm, it's out quite some time now, discussed quite a lot, hyped - and he did not hear about it until now?
Again, what qualified him to do this talk?!?
Well to use your analogy, not every doctor needs to know how to do surgery. There is room for programmers who don't know (because they don't need to) about things like pointers or how the computer cpu/memory operates in terms of caches, branches, etc. Most programming done today does not require this level of expertise, obviously it's still good knowledge to have even in very high level languages but it's not a necessity in order to be productive in their domain (usually those providing the frameworks used in these high-level languages will have mitigated such problems as far as they are able to).
If gui app development on X is made easier then that is great, still unlike Massey from this speech I don't think the programming language is a problem as you can use the available X toolkits from just about any language these days, you don't have to use C or C++, you can even combine different languages and use say Python to drive the gui code and call C code for anything that requires performance (should there be a need).
I'd wager that if there is a problem then it is that the toolkit's themselves are perhaps more difficult to use then they would have to be (note, I have very little experience with X toolkits as I haven't done any real gui based programming since my early Windows days which was ages ago), perhaps what we need is another new modern shiny toolkit to rule them all? ;D.
I think you shouldn't be allowed to drive a car without a car license. High level languages like C# or Java have strong performance penalties if you don't know about programming. Garbage collectors not always do their job right and sometimes lead to high memory consumption. Aside from platform details more that 50% of programmers don't know how to structurate their code. Most of them do copy-paste programming (they carry bugs through all their code), others have over abstraction tendency (they code things that are only in their own heads), and others don't comment their code as a norm.
As for the toolkits comment, I think that's a good point, since (for example) if you want to load jpeg and png images in Linux, you have to use libjpeg and libpng, and increase your code dependencies. Regarding that, I can't understand how Linux comunity can agree to develop a common kernel and not to develop a single toolkit, and a single IDE. I know that there exist several in Linux, but can you imagine why they cannot run in a 256Mb memory ARM neither x86 machine, when kernel does?
well, I didn't saw the videos but...everyone who writes a GUI based program in C or C++ should be thrown into a desert, far away from any technology so that he can't do any further damage to humanity.
If you visit viewtouch.com you will see a touchscreen Xlib GUI written in C which I have been selling to restaurants since 1995. Support is a breeze because I can X forward my clients' displays to me in my home office. Mostly I use the widgets for point of sale applications but they can be used for anything, really.
If anyone would like access to the source for the ViewTouch touchscreen widget framework, just contact me at my web site. The first version was originally written in C in 1986 for the Atari ST but the version I am selling to restaurants now was written in 1995 in C, then changed, somewhat, to C++ in 2000. Some of the functionality of the touchscreen GUI is also based upon Perl scripts. There are many other types of programs that could be created from this touchscreen widget framework other than point of sale, of course. I regard the GUI as a graphical programming tool itself.
Last edited by Remote User; 09-23-2012 at 10:15 AM.
I think you shouldn't be allowed to drive a car without a car license.
Well any fool can learn to handle a car well enough to get a licence (atleast here in sweden!, beware ), becoming a surgeon (which is what you originally equaled with programming) is another thing entirely imo.
Originally Posted by peperoni
High level languages like C# or Java have strong performance penalties if you don't know about programming.
Well that argument can be placed upon C/C++ etc aswell, however I would say that C# and Java can have strong performance penalties even if you know alot about programming. But I don't see you choosing Java or C# for performance reasons, you choose them for rapid development and for that purpose they obviously do their job well, though perhaps mainly due to the strenght of their frameworks.
Originally Posted by peperoni
As for the toolkits comment, I think that's a good point, since (for example) if you want to load jpeg and png images in Linux, you have to use libjpeg and libpng, and increase your code dependencies.
Well any toolkit offering this functionality would simply be wrappers and still use libjpeg and libpng so it's not as if you would decrease the dependencies anyway. Still it might be nice to have it the functionality wrapped in a consistent framework
Originally Posted by peperoni
Regarding that, I can't understand how Linux comunity can agree to develop a common kernel and not to develop a single toolkit, and a single IDE. I know that there exist several in Linux, but can you imagine why they cannot run in a 256Mb memory ARM neither x86 machine, when kernel does?
On *nix machines there has never been any central authority dictating user space components, the kernel developers have nothing to do with what goes on in the user space, particularly the desktop. But it's not as if say Microsoft is much better, on Windows you have the classic Windows API, MFC (basically C++ wrapper for WAPI), Windows Forms, WPF, (am I missing some more?) and these are all from the same company. Then there is also Qt and Gtk available for Windows from third parties.
Now not surprisingly there will be an even wider range of offerings on *nix as there is no 'official' toolkit, I don't think that is a bad thing really as it becomes a matter of 'survival of the fittest'. The 'problem' I suppose is that no *nix toolkit has gathered enough mindshare to become 'THE TOOLKIT', I guess Gtk leads the race based on number of applications using it but I seriously doubt any *nix desktop user out there doesn't have Qt on their system unless it's just been installed.
So neither Gtk or Qt has become THE toolkit, and in practice you need to have both installed on your *nix desktop, if this means that we need a new toolkit which will hopefully rule them all or if these two with their respective strenghts will remain the two major toolkits side by side on *nix happily ever after is something only time will tell.
well this guy is point is kinda moot, i don't believe we need more McDonalds developers[average .NET ] to bring mayhem to linux and i really don't get his point because if 1 thing is missing in linux is not the small things but what he calls "mega apps" and AAA game titles[valve is helping here] and both need developers with a lot higher paygrade than your average-what-is-a-cache C# cheapo developer.
an all the mobile things is /dev/null for me, i don't even get what he means because is absolutely normal that you find more devs in mobile than in desktop and is very logical, those are simple client side applications[server side do the heavy lift] that need to run on constrained hardware enviroments and have touch capabilities all based on a vendor controlled SDK that contain functionality enough to achieve this sort of apps[trivial functionality, loots of eyecandy and internet access] targeted almost exclusively to entertaiment and basic media consumption not serious work. So compare a desktop need vs mobile is idiotic at best, the requirements are too freaking far away to even considered it, i mean as you won't expect to see photoshop cs6 working fast in your asus prime you can't expect that facebook android client will revolutionize your desktop either[an open to an explanation if someone understand wtf was that about].
about xoreax point about gtk/qt i think it hitted the nail, we just have two 200 pounds gorillas in a tie fight for now but this days if you either write in GTK or QT is bound to work in any linux system since for many reason they naturally ship both systems.
about the gui code discussion, i do consider plain old C is not a good choice mostly because you will end with a nested struct madness but C++ is an excellent choice and particularly QT4 is awesome and easy if you can put 3 neurons to work togheter, gtk can be a bit bitchy sometimes tho but i agree that if you find C++/Qt4 too hard for GUI code, my friend you picked wrong the career.
beside McDonalds languages are mostly a security mess[easy to decompile[obfuscator are useless], easy attack vector, hard to protect] like .NET is, they provide medium to massive performance hit, often focused to the lowest denominator of developer you can find[introducing from security problems to resource hog monsters] and many other issues that windows is plaged with and that contradicts everything linux commmity believe in[security, efficiency, code quality, optimal resources usage], so like the mono dudes learned the hard way linux community won't embrace McDonalds languages as primary language target ever and not especially from a dude like this "desktop is screwed cuz all devs go to android OMG" or MS troy horse/Miguel Icaza[well at least MS pay him very good]
if you are one of those troll that believe public source code affect security, you my friend should sue your college and ask a refund cuz you wasted 5 years of your life in vain
He's referring to your comment about how some "McDonald's" languages aren't good for security because they're easy to decompile and hard to obfuscate. His point was that open source software does not make it hard for you to decompile it, since you have the actual source code; no need to decompile it. For the same reason, hard to obfuscate isn't an issue for open software, because obfuscating it makes no sense.