Originally posted by deanjo
View Post
Announcement
Collapse
No announcement yet.
The Future of Compiz In Question
Collapse
X
-
-
Well here is what blackduck software has to say about the whole thing:
Black Duck Software Composition Analysis (SCA) provides a solution for managing open source security, quality, and license compliance risks that comes from the use of open source and third-party code.
In fact, we counted over 17,000 projects from the class of 2008 – those projects that show a creation or registration date in 2008. 47% of these newly created projects used the C language. Java came in as the number two language of choice at nearly 28%. Third was Javascript at over 20%. In the world of scripting, nearly 18% of the projects chose to use Perl while only 11% used PHP. These were both higher than Python at nearly 10% and Ruby at 6%. Note, most projects used more than one language and these results are based on the number of projects using a given language, not the number of lines of code created.
Leave a comment:
-
O dear, another language discussion... I'll just sit on my hands this round
Originally posted by StefanHamminga View PostI really don't agree here, in my opinion the 'bling' does a lot for the OSI've my TV hooked up to a HTPC
I agree... but keep in mind that htpc software is something different. Here the bling part is more important than in your everage desktop workplace.Last edited by tmpdir; 24 January 2009, 05:30 AM.
Leave a comment:
-
ReactOS uses C++, nuff said.
Explanation:
ReactOS uses C++ for a majority of its code, from kernel, to explorer, to notepad, etc.
It does use C, but C++ is favored.
The reverse is true in Linux kernel programming. There ARE a few bits and pieces of C++ code, but because of the general culture towards C++ (as already debated here), C code is more likely accepted, and so the shift there is toward C.
Honestly, it is just a matter of preference.
Case in point, Java.
A lot of people say Java is crap to work with because it is slow as molasses.
Well, when running as a JIT unoptimized JVM like the official Sun Java build, of course it is slow! However, running optimized builds made from source directly tend to be faster.
And getting around the JVM, you could AOT (ahead of time) compile the code with GCC and get code assembled into a true binary.
Performance is a matter of the runtime. Usability is a matter of preference. Meh.
Leave a comment:
-
Since this thread already has gone way off topic...
I'm experienced in C (many years of experience) and have also done some serious coding and debugging in C++ (using operators, templates, exceptions and whatnot).
For me, C is seriously lacking since it does not really support an object oriented approach. (Ok, I know there are ways to more or less use C in an object oriented way - f.ex. there's a document out there called "Object-Oriented Programming With ANSI-C". This is interesting and beautiful in its own way but requires a special pre-processor and other sacrifices. Normal structs containing function pointers does not allow inheritance in a comfortable way, and it gets even worse when you try to encapsulate data. Etc.)
Unfortunately I have not been able to get comfortable with C++ either. Abominations like automatic constructors that try to convert practically anything to something completely different (bye-bye type safety), templates (while macros are sometimes useful I think they should be used sparingly, and templates can really make debugging hellish - trying to debug cross compiled code on a target without gdb and with templates making printf unusable was not much fun - not to mention they mostly exist to enable programmers *not* to do things the correct, object oriented way) - and WHY does C++ still allow C-style casts?!
And what's wrong with Foo foo = Foo()? Why Foo foo()?
Oh, and operators: here is an interesting description of what you have to do to implement operator bool() properly. It amounts to at least an A4 page of code, with several classes. All this to enable the programmer to use object foo like this:
if (foo) {...}
... which only really makes the code less readable: are we checking if foo is NULL or are we calling foo.operator bool? Compare to
if (foo.is_ok()) {...} // Or whatever, which is crystal clear.
What I'd like is C with 'class' support incl inheritance and encapsulation, new/delete, and C++-style casts ONLY. No operators, friends, templates etc. Is that really too much to ask?
Leave a comment:
-
it was not me who started with the 'Linus is stupid because he refuses c++ for the kernel' bullshit. That was you c++ fanboys who started with that. And SUDDENLY you backflip. Well done.
Leave a comment:
-
Originally posted by energyman View Postof course qwould it increase the workload! People would have to KNOW and USE TWO languages to do, what they can do with ONE at the moment. They would have to READ two languages, UNDERSTAND pretty complex code in TWO languages. At the end: much more work for NOTHING.
For a given task X, it almost always takes less time to implement it just as efficiently in C++ than in C. Besides, there exist developers who are put off by the restriction to just C in the current Compiz, and might consider contributing if it used C++ (I'm such a developer, btw).
Originally posted by energyman View PostSo would you please come out of your little fanboy world and smell the roses?
Calling every C++ developer a fanboy doesn't help your argument. I didn't see anybody calling you a C troll.
Originally posted by energyman View Post'We are not talking about kernel development? Really? It was not me who brought up the kernel. It was not me attacking Linus for dismissing c++ for the linux kernel.
Since when is Compiz (a window manager) in kernelspace?
Leave a comment:
-
Originally posted by energyman View Postif c++ is not better than there is no reason to switch.
I just took affront to the claim that C++ is unsuited for kernel programming.
Leave a comment:
-
of course qwould it increase the workload! People would have to KNOW and USE TWO languages to do, what they can do with ONE at the moment. They would have to READ two languages, UNDERSTAND pretty complex code in TWO languages. At the end: much more work for NOTHING.
So would you please come out of your little fanboy world and smell the roses?
'We are not talking about kernel development? Really? It was not me who brought up the kernel. It was not me attacking Linus for dismissing c++ for the linux kernel.
Leave a comment:
-
Originally posted by energyman View PostAnd my most important point still stands: introducing c++ would increase work load and decrease the amount of people able to understand the code.
The first statement is not true, and the second is a tradeoff (less people, but more skilled).
Originally posted by energyman View Postso could you stop this bullshitting? All your 'arguments' why c++ is great have been refuted many times on lkml.
Stop using LKML and the Linux kernel developers as arguments. They're irrelevant in this case. In kernel programming you are generally afraid of any hidden memory allocations, and also hate any high-level abstractions which hide low-level complexities. In userspace programming, such abstractions are a good thing.
Originally posted by energyman View PostOh - and if you don#t beleif that gcc breaks a lot, just look at the kernel build system and all the stuff that is there just because of all the differently broken gccs. With c++ it would become much worse.
I know when GCC does and doesn't break very well, thanks. Once again, we are not talking about kernel development here.
Leave a comment:
Leave a comment: