Slashdot Mirror
C Alive and Well Thanks to Portable.NET
rhysweatherley writes "So C is dead
in a world dominated by bytecode languages, is it? Well, not really.
Portable.NET
0.6.4 now has a fairly good C compiler that can compile C to IL bytecode,
to run on top of .NET runtimes. We need some assistance from the community to port glibc in the coming months, but it is coming along fast. The real
question is this: would you rather program against the pitiful number API's that come with C#, or the huge Free Software diversity that you get with C? The death of C has been greatly exaggerated. It will adapt - it always has."
...stop telling me things are DYING, maybe let me know when they're DEAD.
C is still alive and kickin' in the NIX community I'd say. It seems it's really just Windows where other languages (C++, C#) seem to be taking over. Just because C isn't being used much in the Windows world doesn't mean it's dying ot is going to die anytime soon.
Buckethead
QUOTE: The real question is this: would you rather program against the pitiful number API's that come with C#, or the huge Free Software diversity that you get with C? The death of C has been greatly exaggerated.
.NET API's are by no means 'pitiful in number', and they can be embraced, extended, and overridden as desired. C *can* adapt, but the point of a C# based desktop system or development platform is not solely to exclude C, but to bring the benefits of managed code to other system consumers. C could adapt, but not without a lot of overhead and fundamental changes that really is the point behind C#. I'm sure we'll be in a backwards-compatible, C-friendly world for a long time to come, but there's no reason to bash something new and different because it is new a different. That's just FUD.
Now what a spin. The
Be very, very careful what you put into that head, because you will never, ever get it out. -Thomas Cardinal Wolsey
FORTRAN and COBOL are still in wide use, even if they aren't as popular as they once were.
Mea navis aericumbens anguillis abundat
C has it's problems. You could complain about C all day, the problem is, it's the best thing we have right now. One of the problem with modern languages is, you can't write an operating system in them. One of the problems is half the new languages are scripting perl/python like langauges and the rest compile to byte code. Maybe C would go away if there was a compiled langauge that wasn't largely controlled by one company that produced fast code and was portable. The closest thing to that besides C is C++.
And its done by someone with a new technology to get people talking about it. Look at all the debates and forum chatter that got sparked off by intels "Bluetooth is dead". "C is dead", "CISC is dead"....
,"Apple is dead".
When technologies really do die, its when noone gives a damn about them, and so noone will be writing a story about it.
I still use punch cards, you insensitive clod!
As for Fortran and COBOL, Fortan is still an entry requirement to the California college system, and COBOL is still everywhere - deeply embedded into the payroll and employment operations of many businesses. And there are still vestiges of punch cards too - Scantrons and the like. So things don't die as easily as you might think. Much as we sometimes wish them away, they hang on.
If my answers frighten you, stop asking scary questions.
True enough, but that's not really the point of the posting. Lots of people know how to program C and not C++. Regardless of how one feels about procedural vs. OO languages, a .NET runtime for C does demonstrate the hardiness (or maybe just the deep entrenchment) of C.
It seems to me (even with my limited knowledge of programming and software engineering) that when such statements are made about the death (or undeath...mmm...CZombie...."HEADERS....HEADERSSS") , the idea that C# has its place in fitting in with the .NET framework, C has its place in things like...say...stuff like the Linux kernel (though that isn't near its only use), Java and it's being cross platform, etc is totally ignored.
Just because you can hammer in a screw if you try hard enough doesn't mean the screw driver is dead.
When a language has to piggy back on another or come up with these weird combinations you know it is on it's way out. With that logic every language with a .NET version is dead. First of all their are plenty of projects that hanve ane will continue to be written in C and compiled into good old unmanaged binary executables that execute without any of this newfangled bytecode. Also the whole point of .NET and the JVM is compile once, run anywhere. Java and Foo# are just languages well suited for such tasts. Programmmers always find a way to use whatever weird language, library, or methodology with whahtever new technology.
--- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
So, by that argument, shouldn't Java and C# both have been stillborn? Both piggy back on VMs and are the same 'weird' combination?? :)
True, and C++ is more than a better C. But how in the world do you do numbercrunching with a bytecode language? Tried to do so once for Java, and I'm NEVER going to do it again. Compilers do exploit the specific processor, VMs can do so, too, but why should I introduce a level of complexity, when I just want my processor to calculate things for me? It doesn't get easier, just more portable, but then, C++ seems fairly portable, using templates all along and letting the compiler do the nasty stuff. This means for C it's going to be macros. But hell, isn't it great when you actually know what happens? If you start out on some byte code language, you actually have no idea about the basics of your system. How can you program this system then? And for the anti-FORTRAN fraction. It is still the fastest thing out there!!! Anyone who tried solving a system of linear equations containing 1000 equations knows what I mean. My eyes still pop out when I see a FORTRAN subroutine at work that will do the job in seconds on a normal PIII desktop. So please stop this thing about dying languages which are in fact not dying but a little hard to cope with. This doesn'd make them old. It's just that some people don't want to go through the trouble of learning them, yet they are simply too good to be left out.
Black holes were created when god tried to divide by zero
...is like saying too many busses will eliminate sports cars.
The C design paradigm (low level, varied environment, highly optimized, developer control) is intended to solve an entirely different class of problem than Business runtimes (higher level, standard interface, managed resource, developer handholding). The two aren't in competition much at all.
Nor do I think much about trying putting a racing-wheel on a bus either. We already have C# and "Managed C++", both which can look quite a bit like C, if you want them to. All you have to do is ignore that they're fundimentally different in the way they treat resources due to the underlying runtime or lack thereof. (Which is like equating a bus to a sports car, ignoring the size and speed issues.)
Screw that! We need more programmers aware of vulnerabilities in systems and to be able to deal with it. Dumbing down a language at the expensive of performance is only going to dumb down the programmers. Well, to a point. My ideal programming language would be something that allows me to do practically anything with it and leaving its internals exposed. You can program with a safe subset if you're beginning, but you can then expand to advanced programming without the language limiting what you can do.
Saying C will die out is like saying that assembler will die out.
There will _ALWAYS_ be parts of an Operating System, hardware-oriented realtime or embedded app that _needs_ to be close to the metal. C/ASM is predictable, consistent, flexible and fine-grained in the things you can do with it. You certainly don't want a time critical interrupt handler routine that is supposed to be done in 5ms to suddenly decide that it needs to do some garbage collection or page in some hashing function to access an array of some sort.
Plus, C is great because it isn't assembly.
Even then, sometimes you just gotta write some ASM.
Sure, someone might make a "better" C that has similar goals (structured around ASM-style thinking rather than human-style thinking), but if they did it surely would be some incarnation of C. Compare traditional K&R C with the current features of GNU C (hooray for structure member tags!) or even the ANSI C99 specification.
Even though there has been no great change in the approach to programming itself (compare to LISP, haskell or Perl), C has nonetheless had continuous improvments along the way, from language and data structure standards to libraries, compilers, debugging tools, code profiling, and so on.
I find it hard to believe that we're going to have OS-level DMA transaction code written in Java or C#.
I once read in a visual basic for dummies manual (or was it Delphi?): "Trying to write an Operating System in Basic is like trying to fly to the moon in a hot air balloon".
At some point, you've _GOT_ to talk to the hardware.
- Paul
Or we can look at it like this: "Wouldn't it be better to have many different toolkits that allow string concatenation and tokenization than one standard library of string functions?"
Or maybe this: "Isn't it great that we have several different native APIs for threads, processes, and IPC depending on underlying platform, five different and incompatible implementations for cross-platform usage, and no way to easily switch between implementations after the project is underway?"
And next shall we talk about databases? Or maybe sound processing? Or regular expressions? Hmmm...
The thing that C zealots fail to recognize is the need for clean, standardized APIs (NOT implementations). If you write code that uses strncmp(...), aren't you glad that you don't have to worry if the C implementation is the BSD libc or glibc or MS Windows' C library? Don't you wish the same could be said for the user interface libraries -- for example being able to swap out the Qt or GTK+ implementations at compile or link time? Or the database libraries? (ODBC? Don't make me laugh.) But you can't because each implementation has its own interface even though a button is a button, a checkbox is a checkbox, a database connect is a database connect, a regexp is a regexp, etc.
This is what .NET gives; Not the mandated implementation, but much better it gives the recommended interface. If the C folks get it together and standardize more than just things like printf(...) and linked lists, you will get no end of gratitude from me and the gratitude of folks who are tired of reinventing the wheel and solving problems that were adequately solved twenty years ago. Unless that happens, you're gonna see more and more people moving to things like .NET and Java, warts and all.
POSIX was a good start, but it has stagnated and is showing its age.
- I don't need to go outside, my CRT tan'll do me just fine.
Please don't. Yes C++ as a language has compilers for many platforms which are pretty much compatible, but the degree of compatibility of these compilers don't mean much since the compatibility of an application is a totally different story. An application written in C++ will be using some kind of library, for DB access, for GUI, for network operations etc... Most of the times, these libraries are not cross platform. Or they have to be extended with platform spesific code. It has been discussed in /. many times, check it out yourself. Cross platform GUI, cross platform libraries, and there is almost always a catch in all the solutions. .NET i just don't believe MONO guys can keep up with it. C# 2.0 and longhorn will be a huge step forward for .NET technologies, and i don't thinkk MONO team can find resources to keep up with MS. .NET.
The story may change if you are writing C++ code that can stay in some kind of boundy, without using much library code, but unfortunately, i did not have that chance.
IMHO, java is really successfull in cross platform software development, without much work i can make java software work on another platform.
If C# had the same future, i'd be really glad, since i like it too, but as Microsoft works harder and harder on
Don't get me wrong, i loved the work they've done, but the result will be a platform inferior to java 1.5 and
So i'll be using C++ for platform spesific, high performance apps, C# for windows apps that require rapid development, and JAVA for cross platform. That's my 2 cents...
Of course you'd also have to disassembly every library MSOffice uses and every library those libraries use which includes the NT kernel. So by the time you're done, you'd be running Windows in a JVM just to run MS Office.
You know the old adage, "Use the right tool for the right job?" Well, use C when you need it. C is probably the most misused language I've ever seen. But of course, this is Slashdot, the land where opinions are forged and are never to change.
I won't the minimum distance between my program and the machine instructions. Currently, C is the best language for this purpose.
Nope, assembly is the best langage for that purpose (i.e. 0 difference between your language and the machine instructions). Programming languages exist to abstract away from the details of the hardware. This allows you to write less buggy, more portable code that can be compiled to run efficiently on lots of different architectures. C code will never run efficiently on, say, a massively parallel computer, but Haskell code might because its semantics aren't tied to a particular machine model.
Unfortunately, a lot of CS courses are teaching people the importance of "managed code" and "strong typing" etc. I say to hell with that. If I feel like messing up with memory at AF345F12:BA231DCE then I shell do so. I don't want to hide behind "type safety". I know what I am doing.
Sure you do. It's a mistake to think that programming languages which have PDP-11 oriented semantics and weak typing are giving you more "power" or "control". Power comes from modular code and well-designed algorithms, and control comes from a language which supports these things by abstracting away from irrelavent hardware issues. Why should I have to think about pointers to iterate through an array? Why should I have to write my own buggy and inefficient memory management code when it could all be done by a finely tuned and heavily tested GC?
C is not even the only language you can use for writing low-level code. Operating systems have been written in Lisp, for example. Nor is it the only language which compiles to efficient machine code: ML, Lisp, etc. can all run at comparable speeds.
Well, couple years ago i was really keen on becoming a 100% C++ writer and ditch my C habits entirely.
Due to the nature of most of my projects, like 90% of my time was spent writing wrappers for all sorts of C-style API interfaces.
Finally i gave up and embraced the zen - pick the right tool for the right job. Being proficient with all sorts of tools helps too.
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
Phew!! Thank god for your comment. It saved me a lot of typing :)
:)
On the subject of careless and stupid programmers with C, how about starting a movement to execute people who ignore warnings because they are only 'warnings'
anti FORTRAN fraction... There is one in the company I work for but they know only other languages. Notice how evolution has back tracked? How Fortran and Java are similar in referencing by reference and not value. And not allowing pointer arithmetic. Fortran was ahead of its time.
[1] as long as you disable exceptions & RTTI and stay away from virtual/multiple inheritance & pointers to member functions.
Actually it sounds from your own description that you got banned from the project for being an asshole. The fact that you have an axe to grind doesn't lend you much credibility to indict the whole project...
When I want to solve a program I choose the language I will use, taking into account the abstractions and facilities it offers.
- Convert digital photographs and GPS track logs into annotated photo albums and trip maps
- Examine the availability of 4500 URLs cited in computer science research papers.
- To create the diagrams and the index for my book Code Reading: The Open Source Perspective.
In all the above cases, I needed a typeless language with a rich set of operators, functions, and libraries to minimize the time I would spend to convert my ideas into code. Ruby and Python would have served me equally well.- the *BSD sed implementation.
- The socketpipe zero-overhead network pipe tool.
- The Outwit Windows-Unix shell integration tool suite.
- The fileprune backup file prune utility.
- A device driver for interfacing with my home's alarm system.
In these cases, I did not require any fancy data structures or framework APIs, but I did want tight integration with the underlying system, absolute efficiency, and minimum-fuss portability. For code that will be executed billions of times on tens of thousands of systems, spending some additional effort to provide the absolute efficiency and reasonable portability that are possible in C, is a proposition one should take into account.#include "/dev/tty"
I suspect that when people talk about the popularity of a language fading, they are really talking about the percentage of developers using it.
:)
This doesn't really tell anyone if the number of people using the language has changed. Given the explosion of programmers in recent years, be they professionally trained, or weekend dabblers, it is likely that they are using the current faddy or new languages, like Java, C# or VisualBASIC (not meant as flamebait; I use them myself when engineering requirements suggest them). This for the most part because their emphasis is on making pretty UIs and not any of the more traditional processing or server applications.
This 'explosion' of users with new languages doesn't mean that the old Fortran, Cobol or C applications will immediately be re-written in BoltsN.Nuts or whatever the latest and greatest is. These people will, quite sensibly, plod along with the tried and tested and will probably even continue developing within these skillsets.
The requirements for these skills may well have stayed the same, while the requirement for GUI apps and amateur (some calling themselves professional) developers has increased.
Before anyone can say a language is dying, lets see the figures. For all we know, these dying languages could even be growing (in numbers, if not percentage). Besides which, who should really give a damn?? If it works for you, use it. If it doesn't, but you're not harmed by it, live with the fact that the Borg haven't yet asssimilated us all
Remember, a language does not cause overflows - careless and stupid programmers do.
:-)
But why have a language that enables the possibility for careless and stupid programmers like myself to do overflows?
"Sir, perhaps its the fact that we put the self destruct button next to the light button on our new combat vehicle that causes a large number of them to explode?"
"Button proximity does not cause explosions! Careless operators cause explosions!!"
When I subscribed to Bugtraq, it seemed most of the vulnerabilites discovered (a couple per day) was caused by buffer overflows. The number of vulnerabilites discovered in Java systems (for instance) were rather few, and tended to be for things like DOS attacks, not getting your whole system security compromised.
Not that I think C is going anywhere, it is still going strong in Unix/LInux land and I like the fact that there are many different languages around. Just commenting on that particular sentence above.
Being bitter is drinking poison and hoping someone else will die
"The real question is this: would you rather program against the pitiful number API's that come with C#, or the huge Free Software diversity that you get with C? The death of C has been greatly exaggerated. It will adapt - it always has."
No - that's not the real question; it's: 'Oh no, not yet another C-like language!?'
What's the point, actually? C# is not something new, it's just an attempt to 'get the colour exactly the right shade of pink'. The truth is - C (the language) is precisely what it should be. So perhaps it would be nice to protect the more inept programmers against themselves, but that is simply a question of the runtime- and development environment, or perhaps some improved libraries.
As I always say: a good programmer can write good code in any language, and a bad programmer will not write good code in any language; it's as simple as that, really. This is because good programming is about good coding and debugging practice, both of which are independent of whichever language you use.
It's a common misconception that you need a ton of API's. up to a few years back, I also fell for the DEVStudio GUI builder, the MFC framework, and the libraries that orbit it. After 5 years of trying to get a hold on the beast, I met someone who had stepped back from all frameworks, and went back to ordinary console C and C++. I walked his footsteps, and my apps got reduced to 15% of their original size. Okay, the dummy users needed a few days more to learn the app, but with solid documentation, this was not an issue. And after 2 months, some RealBasic nutcase wrote a GUI wrapper on top of it in 1 week. Perfect !
When will I end this grieving ? When will my future begin ?
I have no faith in these OO language crap either. The real world maybe OO, but once your code is compiled, it is going to run us a sequence of statements: i.e., like an imperative language.
Well, DUH. In the end its just ones and zeroes no matter what language you use. OO does not change the way computers operate much, it is a way to help programmers think about the problem domain in a way that hopefully is a bit easier for most of us. Jeez.
If you don't like it because it cramps your "bursting with geek studliness" style, that's fine. But if you don't even understand what high level languages are for, I doubt you know what you are doing.
Being bitter is drinking poison and hoping someone else will die
I know the quote was wrong, and thus the entire discussion is senseless. But still, there are things to say about a language dying: (computer) languages do not die. Period. All of the languages ever invented are still used somewhere. People still use FORTRAN, COBOL, C64 BASIC and all kinds of other weird languages.
Besides, why would one of the most powerful and widely used and known languages (C) die? It is like saying noone uses a normal screwdriver anymore, just because they own a battery-powered one. Sometimes you just use the normal one, because it is easier, faster and it just works.
-- The Internet is a too slow way of doing things, you'd never do without it.
C is often chosen because it is the least of many possible evils, not because it is ideal.
Unless you choose something which really tries abstracting away from the underlying machine, like LISP or Mathematica, you're not making great leaps and bounds in moving from one language to another anyway. But many problems are so trivial (in the mathematical sense) that they're not worth the programmer's effort in coming to terms with the new paradigms[tm].
Michael, Michael, Michael... just as full of sh*t as ever... we both know why you were banned from the project. Does attempted blackmail ring a bell? How about repeated harassment of the developers?
/. folks who you really are, *sshole!
No, bug reports aren't harassment, but I'll tell you what is. Proposing something new, and totally irrelevent to the DotGNU project (as per its stated goals and mission) every ten seconds, then not writing ANY of the code yourself, and finally bitching constantly about none of the DotGNU hackers dropping everything to implement your umpteenth million off the wall idea, is most definitely harassment. You harassed Rhys so much he almost left the project completely just so he wouldn't have to deal with you anymore. It's no wonder he didn't want to deal with your bug reports, no matter how valid they may have been.
By the way, you forgot to mention that you were unbanned from the project. You forgot to mention that, as a result, the ban on you in the #dotgnu irc channel was lifted. You forgot to mention that as soon as you learned of this you joined and then proceeded to spam the #dotgnu channel. Next time why don't you try telling all these nice
Rich
Sure, but this helps only if you can assume that those compiled C and C++ binaries are already installed on the user's computer. The main point of "compile once, run anywhere" is to be able to distribute a compiled program that will run anywhere. Of course in DotGNU, we don't define "anywhere" as narrowly as the Microsoft monopolists do:
Unlike Microsoft's C compiler, whose output will only run on i386-based Microsoft Windows systems, our compiler turns portable ANSI C code into a truly portable executable that will run any platform that has a CLR ("Common Language Runtime"), regardless whether the system is 32-bit or 64-bit, little-endian or big.
Or is it because of some form of hatred towards C#
No. It's because there's a lot of C code out there that people might want to use from C# and other modern languages. Throwing that C code away and re-implementing in another language would be a waste of time.
"Most of the times, these libraries are not cross platform"
Well, duh, the claim is c++ is portible not "all libraries that c++ uses are portable"
Having said that I would say that there are degrees of cross-platform-ness. Java being much closer to the ideal than c++.
It has been said many times before, but it's worth reiterating: [nearly] all of those wonderful runtime environments, and interpreters are written in C. Sometimes, language designers try to implement a self-hosting interpreter (like, say, scheme in scheme, ...), but even here, it still has to be bootstrapped somehow. Unless you want to do this in (unportable) asm, you still need C.
cpghost at Cordula's Web.
C++ isn't a "better C", really, so I suppose I'm somewhat in agreement. C++ seriously breaks compatibility with C, of course, though uses roughly the same syntax to extend itself over the top.
Objective C is compatible with the underlying C (it's compatible with C99 too, last time I checked), while using a different "new" syntax for the object orientation, as well as providing a nifty class library and dynamic type checking.
In some respects, it's like C#, including the decently poor class library API (compared to Java, anyway), but to me, it's basically what C++ should've been. The only real "downside" in my opinion has been that it doesn't have class-local storage, but instead uses the exact same storage as C, which can make tracking data "globally" through an application slightly difficult, since you're either forced with global storage, or function-local storage (and then passing it around through everything via pointers), or some other more "traditional" means of throwing data about. C++ is nice that it's compatible with C libraries in general, and you can keep functions and data together in classes, which makes a decent amount of sense, though I've been told that the way C# does some of the more "trivial" data types (bools, attributes, etc) is a little more efficient relating to class storage.
But...here I am going on and on, too.
It's like comparing the importance of your spinal cord to the importance of your kidneys. They both kick ass and serve a particular purpose; in many cases they complement each other wonderfully. And let's not forget that Python and Java both use C as an extending languge.
Way to completely miss the point of language independence.
I am very small, utmostly microscopic.
but c is better suited for embedded applications is it not? where the performance if of utmost importance ?
C++ is perfectly portable if you don't use platform dependent libraries. You seem to be blaming the language because people develop platform dependent stuff for it! If your goal is to port stuff to another platform then obviously you start off with that in mind.
There's plenty of platform dependent Java code out there, or stuff that doesn't port properly.
In this world nothing is certain but death, taxes and flawed car analogies.
I'm not very familiar with KDE's language binding availability right now, but I know that being written in C++ would make it more difficult to provide alternate bindings. C, being the lowest portable denomiator of programming languages is simple to create alternate bindings for.
I cannot believe this tripe is modded as 'insightful'. What ignorant rubbish (both the comment and the moderation of it).
It is relatively easy (as easy as with C) to create bindings for C++. And even if it wasn't, you can create C bindings for C++, so you could simply then create the bindings for other languages using the C layer.
Free Gamer - Free games list and commentary
On the one hand, the article here is misleading. The slashdot news story it cites claims 'c' is dying, but the article that news story cites does not. So the cited story got twisted on slashdot.
So now we have a new slashdot story running with the mistake...
The majority of CPUs in today's world are not running desktops.
Things with C
Linux
compilers
Automotive
engine controllers
ABS controllers
Airbag controllers
Memory seat controllers
etc...
Calculators
desktop BIOS and chipsets
Cell phones
etc...
Most code written to run on the hardware is written in C. So the contention being refuted is faulty in the first place.
Having seen side by side comparisons of J#, C# & VB running on
Actually, in many scientific applications thanks to the templates you can have a very efficient code WITHOUT disabling exceptions, RTTI, ... and beat the pure C code simply because you could not write so much inline code that the inline expansion of all sorts of usage of all your template classes would result.
In a simple tight loop with simple operations, calling simple function C may beat C++ but in a more complex application C++ can be faster.
Sorry , Objective-C is a dogs breakfast. C++ might not be perfect but at least it attempts to be a logical continuation of C's syntax and mode of operation.
Obj-C on the other hand looks like the designers thought to hell with C , we'll design our own new-look language and shoehorn it kicking and screaming
into C. Embedded SQL aside I've never seen such an ugly kludge of a language in my 15 years of working in the computer industry.
Also, if you want protabe C++ code, all you have to do is draw a firm line in your design between platform specfic and the rest of your code.
Free Mac Mini Yeah, it's
The sad thing is, though it should run fine on a modern x86 processor, it is almost certainly slower than code that a decent C++ compiler with processor specific optimizations would produce. If the code had been written in C, it would be able to take advantage of MMX and SSE instructions with nothing but a recompile. I have seen hand-optimized assembly code for doing 64-bit arithmetic that was written a few years back; replacing this code by using __int64 and normal arithmetic operators resulted in a speedup.
I agree that if you want to allow other languages to interface with your C++ code, you write it differently. The thing is, with C++, this must be one of your design goals; if you write in C, your library is much more likely to be usable without an additional interface wrapper layer.
Yes C++ as a language has compilers for many platforms which are pretty much compatible, but the degree of compatibility of these compilers don't mean much since the compatibility of an application is a totally different story. An application written in C++ will be using some kind of library, for DB access, for GUI, for network operations etc... Most of the times, these libraries are not cross platform.
Well, they are cross-platform if you are writing a cross-platform application, and they are not cross-platform if you don't.
Furthermore, the kind of cross-platform compatibility people primarily worry about with C++ is for libraries: it is things like regexp libraries or XML libraries that are going to be reused across platforms; GUI and I/O parts of applications are best developed in a platform-specific manner.
Or they have to be extended with platform spesific code.
For some reason, Java marketing has created the notion that cross-platform development matters a great deal, but that is nonsense. Cross-platform development (and sandboxing) matters for browser applets, a market that Java has largely ceded to Flash. For desktop applications and server-side applications, cross-platform applications don't matter at all.
Writing in a cross-platform toolkit and adding a small amount of platform-specific code is actually far superior to the 100% cross-platform approach: it is nearly as easy to port the application between platforms, but the application becomes enormously more usable by following platform-specific conventions and offering platform-specific functionality.
What it comes down to is that C++ is a better language than Java for cross-platform development. C# may eventually supplant C++ in that regard, because C# is simpler and safer, but still offers C++'s access to platform-specific features. But Java's religious insistence on what they incorrectly call "cross-platform" support actually is counterproductive.
You're just a little too young. Objective-C is a cross between C and Smalltalk. I would say its a wonderful blend. If you know both of those languages, you pretty much will get most of Obj-C right the first time you try to do anything in it.
As classes are first class objects, I love it. However since its only used on Macs, I cry.
Want to see every step I took to start my company? http://www.rowdylabs.com/blogs/pitchtothegods
Believe me or not, I've met a few programmers (I can honestly say 3!) that were able to program in C++, but not in C!
All three were fresh out of school and were working as professional C++ programmers!
When I say "unable to program in C", I mean that exactly; they were unable to deal with pointers, didn't understand the basic variable types, couldn't write an application without the Visual C++ application-wizard generating a skeleton for them!
"What's a main?"
"ints have a range?"
"why is my unsigned variable never decrementing to -1?"
"Pass by reference???" *blank stare*
If I asked any questions like - "How do you think printf is implemented?"
I'd get a typical response like "dunno"
OK you say, printf is big, etc...
But when I'd ask "What does this code you wrote last month do?" and get "dunno" as an answer, it was sort of shocking.
You see, I think everyone trying to lower the bar by getting rid of C and anything low-level like that will backfire, if these fresh-out-of-school examples are any indication:
After finding them so useless at getting the job done except when everything was just about completely pre-chewed and put into their mouths, I did what I had to.
I laid-off one of them.
Another left out of boredom and apathy because I gave him the task of fixing his own bugs.
If we lower the bar, it won't prevent problems from existing and needing to be solved, you see, and only the programmers with TRUE aptitude will succeed, and they won't mind C one bit.
I don't know the meaning of the word 'don't' - J
The actual "C" language may be declining in use. However, every single one of the "replacement" languages I've seen mentioned are simply "[subjectively] improved" modifications of C. Personally, I rarely use the higher level versions of C like C# or Java, because my line of work requires me to interface with OpenGL and do very CPU intensive calculations. Pointer math is absolutely required to effectively utilize OpenGL's more advanced extensions such as vertex buffer objects. And you can just forget about optimizing your vector math for CPU vectorization and parallelization, etc... in languages like Java or C#. This is not to say, however, Java and C# do not have their own benefits. When you need to write a small application (perhaps a frontend, or what not) and performance is not important, it's often faster to develop them in a higher level language. It's another instance of "the right tool for the right job". But the low level versions of C won't be dying for a very long time, because there will always be a need for portable, high performance APIs. The APIs that your high level C languages may interface with to perform tasks you simply can't practically accomplish otherwise. And of course the actual system kernel that everything runs would never be practical in a high level language.
Fact: C is dead
Umm Doesn't that Linus guy write his little project thing in C ?
what is it called again ?
Type unto others as you would have them type unto you.
I bet you don't like seatbelts (only poor drivers need them!) or hospitals (just for people who are careless and don't look after themselves!) either.
What are you talking about?
Unsafe pointers are for the kernel to use, not userspace apps. Its okay if the kernel can crash the system, not if userspace apps can do so. Userspace apps cannot use unsafe pointers.
You don't switch between static and dynamic typing. Rather, you have dynamic typing, and optionally add type declarations in places where you want to tighten the interface or improve performance. There will be some runtime type checks, but modern compiler analysis can eliminate most of those checks. And what's wrong with type inferencing in your kernel? Type inferencing all happens at compile-time!
And the "raw core" they're talking about is not a low-level, close-to-hardware core, but a conceptually primitive core. The idea is that there is a simple base language to which both high and low level features can be added.
Strictly, Crush will have more overhead than C. However, given a good compiler, and well-written, straight-forward code, it is possible to achieve close to C performance for high-level languages like Crush. In some cases (things like generic data structures, where specializations can be used) performance can be even better.
Also note that while a kernel written in Crush might be 10-20% slower in raw performance, it makes up for it in other ways. For example, system calls won't have a huge overhead (hundreds of clock cycles on most modern kernels). Data doesn't keep having to be copied around. You don't have to put things like the X server in a seperate process to provide protection.
A deep unwavering belief is a sure sign you're missing something...