Ubuntu's Unity Written In Qt/QML For "Unity Next"

[vininim]

Wow, this math vs linguists bikering is totally nonsense.

Programming is math.

You have physical hardware which "is a computing model". Then you have programming language implementations on top of that hardware, which are computing models. The software you write to those implementations are subject to those models. You're a human being writing data to be interpreted by a model that is basically mathematics.

If we go to the abstraction part of the process (the desgining and paradigms), they are all based on formal models that have a ton of mathematics. This is the point where the debate of computer science being a part of (applied) math starts. Beside that, it's all math.

All paradigms discussed are turing-complete. All have efficient compilers. And all programers involved in them deviate from the pure paradigm to achieve better performance. In the process of writing code, inefficieny and bugs are introduced by the human (be it the source or the compiler guy).

So the initial discussion of procedural vs object-oriented vs functional is shifted to the human element: programmers and maintainers. It's about cognition/neuroscience/management/sociology, not about mathematics. The mathematic part of the paradigms have evolved past the point where there is any discussion about the merits. The real discussion is if we, monkeys who think in terms of bananas, deal better with programming language X or Y, which mainly follow paradigm A and/or B.

[shruti001]

i like all the implementation by ubantu and i guess this will be also a great one.............

[JS987]

You don't know what you're saying. Modeling is inherently about abstracting information into something that can actually be worked with, and even if you're going to turn around and restrict that to OOP design patterns. For instance C++ doesn't have properties at the language level and so in Qt we use a macro to get around that issue, which is essentially a wrapper around a private piece of data, a getter, and a setter.
Yeah it is kinda slow to have to write those capabilities for abstracting the related design patterns in yourself as opposed to just using one of the languages that already has done most of the work for you in that regard. That doesn't however mean that you can't use or create those standard design patterns yourself. It's slow and painful, and likely to be buggy as you're building up from scratch as opposed to using something well tested but you can do it.

I meant you shouldn't use and waste time with creating fake emulation of OOP like GObject if C++ supports OOP.

[Luke_Wolf]

I meant you shouldn't use and waste time with creating fake emulation of OOP like GObject if C++ supports OOP.

And here's where other than your calling it fake emulation of OOP, I can certainly agree with you. If the work has already been done for us then why re-implement your own when there's a fully capable superset of C that is available for use.... Which there are valid reasons to do but unless you're creating a toolkit or your own language those reasons are highly flawed.

[dee.]

[Triv00ett]

It is about doing whats best for Canonical.

[dee.]

I meant you shouldn't use and waste time with creating fake emulation of OOP like GObject if C++ supports OOP.

There's nothing fake about it. There's nothing "emulation" about it. Ultimately, both C++ and C/GObject compile to assembler, and are basically indistinguishable from each other (apart from some conventions like different name-mangling schemes).

Besides, C++ is a flawed, bloated piece of crap that lacks real runtime encapsulation, has a horrible template system that makes debugging a nightmare, is not easily parseable because of inconsistent syntax, etc. You might disagree, but there are plenty of people who dislike C++ for these very valid reasons, so it makes sense to create an OOP language that is a clean implementation AND fully compatible with C code.

[JS987]

There's nothing fake about it. There's nothing "emulation" about it. Ultimately, both C++ and C/GObject compile to assembler, and are basically indistinguishable from each other (apart from some conventions like different name-mangling schemes).
Besides, C++ is a flawed, bloated piece of crap that lacks real runtime encapsulation, has a horrible template system that makes debugging a nightmare, is not easily parseable because of inconsistent syntax, etc. You might disagree, but there are plenty of people who dislike C++ for these very valid reasons, so it makes sense to create an OOP language that is a clean implementation AND fully compatible with C code.

I already said reasons why GObject is fake emulation. See my previous posts.
All features supported by C++ are useful. Fast, universal, type-safe and memory efficient containers aren't possible without templates. There is bug in debugger or compiler if you have problem with debugging of templates.