GXUI: A New Cross-Platform UI Library By Google

[Luke_Wolf]

Whenever I have used Dolphin, it has been from within KDE. Right now I'm using Enlightenment which uses neither GTK nor Qt by default (EFL)

Well... I can't say I've ever noticed this problem. I know that KDE just felt faster every version up till about KDE SC 4.8 or so after which performance leveled out, but you might want to give it a spin once everything has shifted over to KF5, Qt5 and KF5 bring their own performance improvements and enhancements, and the split up libraries should mean a lower memory footprint and such in terms of what it's having to load and such. Otherwise dunno.

[jonnor]

Well... Actually that's wrong. Programming languages DO in fact carry with them factors that influence the performance of a program. Functional languages can for example be aggressively concurrent by the compiler, and the more dynamic a language the more has to be shoved off to being determined at run time causing additional slowdowns vs a more static language where more things can be determined ahead of time. Garbage Collection implies that every so often the program will effectively pause to mark and collect the garbage, move the current in memory items into their appropriate generations, and so on. Not to mention that certain languages make going about things certain ways more or less difficult which effects how one goes about developing the software. Beyond that still questions like "How toolable is language X?" have significant effects on both the number of bugs in a program and the speed at which a piece a software is developed.

It's nice to believe that everything is up to the craftsman and that the tools he uses don't matter, but the simple reality is that this is not true. A good craftsman values a good set of tools and both despises and avoids those that harm his productivity.

Did you not read what I said? "Different programming languages make various aspects of these tasks easier and harder".
The choice of the right tools is a large part of being a craftsman. I only argue against statements like "the software is fast because it's written in C++" or "it's slow because it is written in Python" which are logical fallacies.

[Luke_Wolf]

Did you not read what I said? "Different programming languages make various aspects of these tasks easier and harder".
The choice of the right tools is a large part of being a craftsman. I only argue against statements like "the software is fast because it's written in C++" or "it's slow because it is written in Python" which are logical fallacies.

Except that's still wrong. Software indeed can't be fast just because it's written in C++, but it can be slow because it's written in python. Skill is required in order to make something fast, but for software to be slow is simply a question of drag, which includes the execution speed and the execution profile of the language itself in addition to factors that actually involve the skill of the individual craftsman. In effect you can have a program that is both fast and slow at the same time by implementing a fast algorithm in a really inefficient language. Yes in principle well written Python can be faster than very poorly written C++, but quite frankly I'm tired of people arguing that the tools that they use don't matter, and the lie that "only a bad craftsman blames his tools".

[alexvoda]

I'm tired of people arguing that the tools that they use don't matter, and the lie that "only a bad craftsman blames his tools".

Well, only a bad craftsman blames his tools after he chose the wrong tools for the job.
A good craftsman blames himself if he chooses the the wrong tools for the job.

[goTouch]

Oh... I dunno a significant chunk of the web built on ASP.NET, lots of enterprise LOB applications, PS Vita games, various PC games including the well acclaimed Dust: An Elysian Tail, most of the applications in the Windows Store are written in C#, the list goes on and on. The only areas that C# isn't used is in the high performance sphere which is the stronghold of C and C++, and the scientific community which is the stronghold of Fortran, Python, Matlab and the like. Otherwise C# is even at the forefront of Microsoft's embedded push and has been since they were first pushing IoT with the SPOT technologies, and R&D OS development with the likes of Singularity/Midori.

Do people love those slow C# apps or have to use it because software companies choose to make it use C# for fast-to-market reason instead of efficiency? Not getting tired of the minutes we waste waiting for app launching every day?

[jonnor]

Except that's still wrong. Software indeed can't be fast just because it's written in C++, but it can be slow because it's written in python. Skill is required in order to make something fast, but for software to be slow is simply a question of drag, which includes the execution speed and the execution profile of the language itself in addition to factors that actually involve the skill of the individual craftsman. In effect you can have a program that is both fast and slow at the same time by implementing a fast algorithm in a really inefficient language. Yes in principle well written Python can be faster than very poorly written C++, but quite frankly I'm tired of people arguing that the tools that they use don't matter, and the lie that "only a bad craftsman blames his tools".

You are right, a piece of software can be slow because its written in Python. What I intended was that saying "the software must be slow because its written in Foo" is wrong (and not just because 'slow' is relative and poorely defined if not further specified).

[Luke_Wolf]

Well, only a bad craftsman blames his tools after he chose the wrong tools for the job.
A good craftsman blames himself if he chooses the the wrong tools for the job.

You make the invalid assumption that a craftsman always, or even usually gets to choose the tools for the job. The majority of work in code is not in fact in creating new products but in maintaining and extending existing ones, additionally management has as much or even more say in how a developer chooses to go about their work than the developer himself. I've heard of, and been involved in one case where some nut manages to convince management to change everything to his particular golden hammer of choice despite all the work that's been put into the current solution.

You additionally make the invalid assumption that all tools are equal in quality but of different purposes, which is quite frankly not the case.

[Luke_Wolf]

Do people love those slow C# apps or have to use it because software companies choose to make it use C# for fast-to-market reason instead of efficiency? Not getting tired of the minutes we waste waiting for app launching every day?

The start up time associated with the .NET JITer is insignificant on most applications, Dust: An Elysian Tail starts up just as fast as other games, and Paint.NET isn't slowed down either. ASP.NET Pages only have a one time lag during the initial compile after a deployment and after that they're instant. Windows Store Applications are AoT compiled on the device using .NET Native just like Android is now doing. The only .NET application I've ever met that's started up inexcusably slow is Visual Studio, but AFAICT that has nothing to do with the JITing or being written in .NET, and more to do with how it's written and designed.

[rabcor]

Well... I can't say I've ever noticed this problem. I know that KDE just felt faster every version up till about KDE SC 4.8 or so after which performance leveled out, but you might want to give it a spin once everything has shifted over to KF5, Qt5 and KF5 bring their own performance improvements and enhancements, and the split up libraries should mean a lower memory footprint and such in terms of what it's having to load and such. Otherwise dunno.

I definitely will. I always check on KDE from time to time, if I didn't feel it was sluggish and it's compositing effects were unstable, I'd be using it.

[goTouch]

Then simply look at http://www.lazarus-ide.org . (There are also two other distributions that contain some cross compile utilities to directly get you running when developing for a bunch of platforms. Namely http://www.getlazarus.org and Codetyphon.)

Pascal, so nice! Amazing people are still developing around it.
Wish Rust is as elegant as Pascal, using some keywords instead of punctures, but it is more like C syntax.