| News | Features | Interviews |
| Blog | Contact | Editorials |
| FreeBSD moves away from GCC, embraces Clang |
| By special contributor R_T_F_M on 2012-09-13 21:19:45 |
| "For the past several years we've been working towards migrating from GCC to Clang/LLVM as our default compiler. We intend to ship FreeBSD 10.0 with Clang as the default compiler on i386 and amd64 platforms. To this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64 platforms on November 4th." |
|
| RE[15]: C++ |
| By moondevil on 2012-09-15 13:46:57 |
|
> Java as a platform needed to suffer a dramatic loss of developer mind-share before its developers finally relented, compromised the language's elegant OO design and grudgingly started to add support for a lot of features that C++ (and Python and Ada and C#) have had forever. We had to wait way to long for generics, and absurdly long for RAII. Funny, because here in Germany I get called every single week for new Java projects. My employer has lots of Java projects proposals without enough developers to take care of them all. That does not look like loss of mind-share to me. Now I agree with you that generics in Java suck, and I also don't like the way the language is going with the annotation overload that it is getting (@override, @value, ...). For me, Java is just another tool. The language I use, always depends on the project requirements, and is usually already decided by the customer. |
 - Score: 2 |
| RE[7]: C++ |
| By moondevil on 2012-09-15 14:02:50 |
|
> We're talking about different things. COM is an object-communication system, not a library linking system. As far as I can understand it (and I'm not a Windows developer), COM would take care of the problem of communicating objects between heterogeneous languages, but it's not an ABI or linking standard and it wouldn't take care of actually linking the program units in the first place. Since when? COM is all about libraries. Your COM components can exist in separate executables, for more security. In this case a kind of local RPC is used. However, most COM components are actually dynamic libraries that get dynamically linked with your application and follow the same format as C++ VMT. No communication going on here. In Windows 8 COM got extended. Now with WinRT, COM makes use of .NET metadata for language interoperation. If Metro succeeds, many Windows developers believe Win32 might be in the legacy path, with WinRT taking over the full spectrum of Windows APIs. > > Again, C as lingua franca only works if C is the language exposed by the operating system. Lets not forget there were system programming languages before it, and after it, why should C exist forever? And the system-development languages before it blew, which is why C was developed. And the system-development languages used after it have to be restricted; remember the above post about how C++, when used as a kernel language, can't make use of a laundry-list of features? That's because of the same problem; you can't use features that would require the generation of implicit premains, or would refer to state that the underlying system is supposed to maintain (because in a kernel, there is no underlying system). The system-development-safe part of C++ you end up with isn't much larger or much different than C. C got developed, because of UNIX. If UNIX had failed in the market, most probably no one would be talking about C today. Now UNIX got successfull, everyone wanted to have UNIX like utilities and C started to be ported everywhere. The day, operating system vendors start using another language for systems programming, like Microsoft is doing now with Windows 8, then C starts to loose its influence in this area as well. At least in the desktop area. If the operating system vendor does not offer you a C compiler, or C like APIs, then there is not a C interface to talk about. You FORTRAN compiler, Ada compiler will need to support another type of interface. This is nothing new. From what I know, there are no C like interfaces in mainframe systems, and you are forced to use whatever call convention the OS vendor decided upon. |
| - Score: 2 |
| RE[7]: C++ |
| By satsujinka on 2012-09-15 23:13:31 |
|
Oh hey, the security circus is back in town. I've already dealt with the issues you bring up, but here we go again. Mistakes get checked by others. Don't release software before hand. Using arrays is not a matter of pride, but one of humility. Other people have to read the code. Use something easy to read. Manual can be easier if it makes things easier to understand. In this case, arrays have special syntax that makes them easier to understand than vectors. Thus even though it's manual, it's still easier. The language of the compiler is irrelevant. Most projects just use the most popular compiler. It simply makes rational sense to do so, as popular compilers have more extensions, optimizations, and (hopefully) less bugs (or they'll be fixed sooner.) It is entirely possible to compile linux or freeBSD with tcc or pcc. Both of which are written in C. Therefore, it is not true that C requires C++. It is also important to point out, that using a program is in no way, shape, or form a validation of the language used to write it. In order to hate, one must have passion. I certainly don't. I don't go around trying to stop people from using C++, it's their choice they can use what they like. Personally, I find C++ to be an ugly language. It tries to do too many things at once and ends up being overly verbose in everything it does. This makes it harder to read. Which makes it harder to understand. I much prefer using smaller, more concise languages. Yes, that's languages plural. Lastly, irony. Irony is all about expectation. If you don't understand this then, please, stop using the word. Specifically, Irony is about averaged expectation, also known as common sense. Something can be ironic only if the average person wouldn't have expected that outcome. Also, expectation is empirical. You can go out and ask people what they expect. |
| - Score: 2 |
| RE[6]: C++ |
| By satsujinka on 2012-09-15 23:21:25 |
|
So your favorite language is two parts bloat to one part batteries included? No wonder we disagree. That's pretty much the definition of the worst language ever. |
| - Score: 2 |
| RE[16]: C++ |
| By boldingd on 2012-09-16 02:48:14 |
|
> Funny, because here in Germany I get called every single week for new Java projects. My employer has lots of Java projects proposals without enough developers to take care of them all. That does not look like loss of mind-share to me. I admit that I have no solid empiracal measure of language usage or user-base growth, but I have the strong impression that Java as a general-purpose desktop application language is dieing. It isn't being shipped on new Windows machines anymore, new software projects aren't using Java, the language is fading away. It certainly still has its users -- I've written an internal-use web service in JSP, and it's Android's native language, after all -- but I think it's days as a general-use language are pretty much over. > Now I agree with you that generics in Java suck, and I also don't like the way the language is going with the annotation overload that it is getting (@override, @value, ...). For me, Java is just another tool. The language I use, always depends on the project requirements, and is usually already decided by the customer. I never said that generics in Java sucked! I'm glad they finally got them, long overdue as they where. Given how much more type-safe generics make abstract container classes, I was saying that it was a crying shame that it took Sun so long to break down and add generics into the language! To me, that's the story of the growth of Java. They looked at C++ and said "there's gotta be a simpler way to build a language." (And for my money, they're right on that.) So they stripped out a lot of the most confusing features and worst design decisions, and Java was what they where left with. But they took out to much; things like generics, while ugly from a type-flexible pure OOP perspective, end up being net benefits for the language. And they where too slow to add those features back into Java. So you're left with an under-expressive language that's missing features that older languages have had since before Java existed. I mean, Java finally gets what amount to a Python with-block in Java 7, in 2012? Why the hell did it take that long? And why is the RAII block that we finally do get merged with try-catch blocks? What would've been so bad about introducing a with block? |
| - Score: 2 |
| RE[8]: C++ |
| By boldingd on 2012-09-16 03:06:36 |
|
> Since when? COM is all about libraries. Your COM components can exist in separate executables, for more security. In this case a kind of local RPC is used. However, most COM components are actually dynamic libraries that get dynamically linked with your application and follow the same format as C++ VMT. No communication going on here. In Windows 8 COM got extended. Now with WinRT, COM makes use of .NET metadata for language interoperation. If Metro succeeds, many Windows developers believe Win32 might be in the legacy path, with WinRT taking over the full spectrum of Windows APIs. I'm not a Windows dev, but from what I'm reading, COM isn't a calling convention, it's an object serialization technique. You're right that it will help different OOP languages on the same underlying platform swap objects easily, but that's not the only problem I'm talking about. That works because COM support is pushed into the language run-time and underlying platform, and handled by the compiler; things change when one of the languages you're using isn't object-oriented or doesn't have usable COM bindings, like Fortran, Ada or C. Exactly the reason that C is the common language for multi-language linking is that C linking is the lowest common denominator among calling conventions, and that's still going to be true even on a platform that makes heavy use of COM in its low-level APIs. > C got developed, because of UNIX. If UNIX had failed in the market, most probably no one would be talking about C today. Now UNIX got successfull, everyone wanted to have UNIX like utilities and C started to be ported everywhere. The day, operating system vendors start using another language for systems programming, like Microsoft is doing now with Windows 8, then C starts to loose its influence in this area as well. At least in the desktop area. If the operating system vendor does not offer you a C compiler, or C like APIs, then there is not a C interface to talk about. You FORTRAN compiler, Ada compiler will need to support another type of interface. This is nothing new. From what I know, there are no C like interfaces in mainframe systems, and you are forced to use whatever call convention the OS vendor decided upon. "C exists because of Unix" is historically true, but you're missing the point. The reason that C came into existance was that B and BCPL - and pretty much all low-level system languages - sucked. C became popular because there was a huge need for a portable, high-level language that could still be used for low-level work. C and Unix answered real needs in the market that nobody else did; it's not as if they became popular by coincidence or clever marketing. |
| - Score: 2 |
| RE[9]: C++ |
| By moondevil on 2012-09-16 06:23:36 |
|
> Exactly the reason that C is the common language for multi-language linking is that C linking is the lowest common denominator among calling conventions, and that's still going to be true even on a platform that makes heavy use of COM in its low-level APIs. You keep avoiding to answer how you would use C linkage if the operating system would no longer offer it. > "C exists because of Unix" is historically true, but you're missing the point. The reason that C came into existance was that B and BCPL - and pretty much all low-level system languages - sucked. No, the UNIX authors did not like the other system programming languages. Algol 68 and PL/I were two that could have been used. There were operating systems already written in those languages, so I doubt that they really sucked. But I was not there, so my conclusion might be completely false. |
| - Score: 2 |
| RE[17]: C++ |
| By moondevil on 2012-09-16 16:28:23 |
|
For me generics in Java suck, because of type erasure they are only half way there when compared to what other languages offer as generics. But yeah, it is still way better than not having them. As for the things taking time to be implemented in Java vs Python, it is always like that when a language is subject to some form of standardization process, look at how slow FORTRAN, Ada, C++, C, OpenGL standards evolved, just to name a few examples. And compare their evolution with languages and API not subject to standardization processes. |
| - Score: 2 |
| RE[10]: C++ |
| By boldingd on 2012-09-17 08:19:47 |
|
> You keep avoiding to answer how you would use C linkage if the operating system would no longer offer it. OK, here: modern Linux doesn't even strictly use C calling and linkage. The reason that C is used as the linking standard at the seams of some multi-language projects is that C is the lowest-common denominator between different function call models. C-style calling and linking is extremely simple; it can be mapped onto the actual calling-and-linking in use on any platform, and for almost any language, there is a subset of that language that can be mapped onto C calling conventions. Using COM for object interchange and leaving the rest up to the compiler is compute until you want to link in a module written in a non-OOP language or compiled by a different compiler suite. Then you're back to a C-style interface and C calling conventions. Not because it's the platform's normal calling and linking conventions, but because it's a patch of common ground between the function-call models used in different compiled languages. Which isn't even to say that all multi-language projects will just do everything as extern C and call it a day; for some languages and platforms, other techniques (like COM interchange) will be better. But C as the basic, universal model of calling a function will never go away completely, and your eager and self-assured predictions of C's decline and demise in the coming years are comically premature. > No, the UNIX authors did not like the other system programming languages. Algol 68 and PL/I were two that could have been used. There were operating systems already written in those languages, so I doubt that they really sucked. But I was not there, so my conclusion might be completely false. Yeah, I'm going to stick with Thompson and Richie's contemporary assessment of the available languages, especially given that Richie was dissatisfied enough with his existing alternatives to create a whole new language. Also, C had plenty of its own selling-points. I've written C and FORTRAN, and I can tell you which I'd rather use for a new project. C was quicker and cleaner than anything it was competing against, and its portability was another major asset (FORTRAN compilers had a tendency to have syntax and operators specific to the platform they where designed for). I don't know why Algol and PL/I never gained traction. I've only heard PL/I mentioned as a historical footnote, but I don't know how it stacked up against it's contemporaries. As for Algol, bear in mind that it had already been released and largely failed in the market (yes it was used, yes it was still around, no, it had not displaced FORTRAN) when C got out into the wild in the late 70's. NB that I am just under 30 and was not around for any of the above. I just payed attention in Programming Languages. ^.^ |
| - Score: 2 |
| RE[11]: C++ |
| By moondevil on 2012-09-17 10:36:04 |
|
> But C as the basic, universal model of calling a function will never go away completely, and your eager and self-assured predictions of C's decline and demise in the coming years are comically premature. It might take a few generations still, but I am confident that with the change to more strongly typed languages, this will eventually happen. Even C++ has a stronger type safety than C. Just out of curiosity, yesterday I was reading some OS/400 documentation, nowadays known as z/OS. And discovered that everything in the OS gets compiled to bytecode and JITted on installation, similar to what .NET does. In this mainframe OS, the only calling convention is bytecode based, there is no C calling convention. Anyway, maybe I am plain wrong about C's future, and my bias against it is from a frustrated Turbo Pascal guy,that has seen enough core dumps and pointer tricks gone wrong in his life. Who knows what the future reserves. > NB that I am just under 30 and was not around for any of the above. I just payed attention in Programming Languages. ^.^ 36 here, and started using computers back in 86 at the age of 10. I was lucky that my university department had lots of literature of the early computing days, and I also took all compiler development and system programming classes. So it was quite nice to experience so much from the computing history. Sadly I think the younger generation that start nowadays learning about computers will miss quite a few things. |
| - Score: 2 |
| News | Features | Interviews |
| Blog | Contact | Editorials |