[Development] What kind of airplane we want to build?

[Bubke Marco]

On January 22, 2016 09:52:31 Hausmann Simon <Simon.Hausmann at theqtcompany.com> wrote:

> Hi,
>
> I think answering the question about the kind of airplane to build is closely tied to another question that may be worthwhile
> asking. I think it's worthwhile because I'm convinced that answers diverge greatly depending on who you ask.
>
>     Why are we trying to build an airplane?
>
> Or differently put: What is our mission?
>
> Is our mission to transport people from A to B? Is the mission to transport goods from A to B? Is our mission to get people from
> A to B in the quickest way? Or is it about safety? The answer greatly influences the type of airplane to build (in the event that
> the airplane is the right method of transportation).
>
>
> I'm of the opinion that our mission should be to make life easier for programmers.

I strongly agree with you. 

One of my fears is that we add too much implicit magic to make it easier for the novice but providing headache for the average programmer. The very experienced programmer will find a way around our magic so I don't care so much about him. 

One example is CoW and false sharing. CoW is good for novices but an average programmer who gets a performance problem which is popping up here and there because of false sharing is lost. 

And don't forget performance is a feature too. If your program is slow from time to time you have to fix it. Like I was running in performance problems with the clang code model. 

So I think we should try to provide a two layer approach. One layer without magic where you have to be very explicit and one with magic on top. 

In the sense of CoW for most cases it is not important. If we return a vector member of 100 small items from time to time the difference is nelectable in the big picture. Only on some hot spots it is getting important and here we have in my opinion to measure what is better. 

I don't know the answer but I mistrust every deductive anwser which is based on what you think. Modern computers are fat too complex to make a guess. It is far better to measure and to measure under a simular workload.. 

> That includes also novice programmers and especially people who's first language is not English.
>
> Who else agrees with me?
>
> Ways to achieve that include tooling to increase work flow productivity, intuitive and consistent APIs that are easy to remember
> and easy to use, especially for non-native english speakers. These are considerations that greatly affect the naming of functions
> (which may or may not justify diverging from the STL for example).
>
>
> Simon
>
> ________________________________________
> From: Development <development-bounces at qt-project.org> on behalf of Bubke Marco <Marco.Bubke at theqtcompany.com>
> Sent: Wednesday, January 20, 2016 11:48
> To: Development at qt-project.org
> Subject: [Development] What kind of airplane we want to build?
>
> Hello
>
> After the exciting discussions in the last time with all the energy spend on them I want to try to make a short summary.  Maybe we can transform the heat on some steam to progress further. ;-)
>
> I think many feel that C++ is rapidly changing. With C++ 17 on the horizon there is some excitement but also fear that Qt will not stay relevant if we not adapt. But there are arguments too about existing users who would be left in the cold we we change to much.
>
> So let use an airplane as metaphor. We built a fine piston engine airplane on that little bit cumbersome piston engine called C++. But now we see Jet engines coming up but all our technology is built the old piston engine technology so the adaption of jet engines is not that cheap. The jet engines are different but we are not sure about their advantages but we are sure it would be a big investment to change to them. So people propose different designs. Some say we should minimize investments and only apapt slowly other proposed to build a hyper mach airplane.
>
> The metaphor is not perfect but I hope it is productive enough.
>
> I think the big elephant is the massive move of the processing technology to multi cores,  massive multi cores formerly known as GPUs and the new parallel mechanism which are proposed to utilize them. Resumable functions, ranges, parallel stl and how they all are called. This will change how C++ looks but how can we change Qt in that picture to utilize this new technologies.
>
> I think it would be productive for the discussion to build story of what we want to do. A story of the big picture. Maybe as a first step we can show how we tackle problems with Qt 5 and what are the proposed technologies in the future C++ standard.
>
> Maybewe see that we don't have to change so much.  Maybe we find out the change would be so massive that we cannot call it Qt 6 anymore. There are many maybes because the future is uncertain but we handled uncertainty in the past so why we should not do it in the future?
>
> I really believe that before we make little changes like the containers etc. we have to find a story. A story how the future Qt should look, a story for the long run. In my opinion we have to build the story TOGETHER and this story should be build on actual experience and measured facts. We should be careful about emotions like doubt,  fear or excitement. I think we should be stay calm.
>
> So we can try now this new C++ prototypes, find out how they fit with our technology like signal/slots,  CoW etc.. And later if they are getting momentum we can provide our magic sauce on top to make our users more productive.
>
> And if we want change Qt much we have to provide a technology to make the adaptation of our users easy and reliable. So the gain should be bigger than the cost. I think Clang based technologies provide us some possible tools but we have to find out. It is not only about providing the tool kit for new shine projects but for existing ones too. Some maybe they don't want to change and that is a respectable decision but for the user who want and need to adapt we should make it easy.
>
> I know this sounds like common sense but after all the discussions in last time I think we should step back and get a bigger picture before starting detailed discussions again.
>
> So lets go out,  start prototypes,  gain experience and come back to fruitful discussions.  ;-)
>
> --
> Sent from cellphone, sorry for the typos
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Sent from cellphone, sorry for the typos