Related
I want to write a library that is dynamically loadable and callable from C code, but I really don't want to write it in C - the code is security critical, so I want a language that makes it easier to have confidence that my code is correct. What are my options?
To be more specific, I want C programmers to be able to #include this, and -l that, and start using my library just as if I had written it in C. I'd like programmers in other languages to be able to use their favourite tools for linking to C libraries to link to it. Ideally I'd like that to be possible on every platform that supports C, but I'll settle for Linux, Windows and MacOS.
Anything that compiles to native code. So you might Google for that - "languages that compile to native code." See, e.g., Programming languages that compile to native code and have the batteries included
C++ is often the choice for this. Compiles to native code and provided you keep your interfaces simple, easy to write an adapter layer.
Objective C and Fortran are also possible.
It sounds like you are looking for a language with ABI compatibility or which can be described as resulting in native code. So long as it can be compiled to a valid object file (typically an .obj or .o file) which is accepted by the linker, that should be the main criteria. You also then want to write a header file as a convenience for any client code which is written in C (or a closely related language/variant thereof).
As mentioned by others, you need a pretty good reason for choosing a language other than C as it is the lingua-franco of low-level/systems software. Assembler is an option, although harder to port between platforms. D is a more portable - but less widespread - alternative which is designed to produce secure, efficient native code with a minimum of fuss. There are many others.
Almost every security critical application I know of is written in C. I don't believe that there are any other language that has higher real status in producing secure applications.
C is being said to be a poor language for security by people who don't understand.
If you want C programmers to use your library, use C. Doing anything else is tying one hand behind your back whilst trying to walk on a balance beam (the gymnastics equipment). Sure, there are dozens of other languages that are CAPABLE of interfacing to C, but it typically involves using a C layer and then stuffing the C data types into a language specific data type (Java Objects, Python Objects, etc, etc), and when the call is finished, you use the same conversion back to a C data type. Just makes it harder to work with, and potentially slower if you don't get all the design decisions right. And people won't understand the source code, so won't like to use it (see more about this below).
If you want security, then write very good code, wearing your "security aspects" hat firmly on at all times, find a security mailing list or website and post it there for review, take the review comments on board, understand the comments, and fix any comments that are meaningful to fix. Distribute the source code to the users, so people can see what your code does. Those that understand security will know what to look for and understand that you have done a good job (or a bad job, whichever is applicable) - and those who don't will hopefully trust the right pople. If it's good, people will use it. If it's "hidden", and not easy to access, you won't get many customers, no matter what language you use.
Don't worry, you won't reveal anything more from releasing source. If there is a flaw in the code, and it is popular (or important) enough, someone will find the flaw, even if you publish only binaries. For those skilled in reverse engineering, not having source code is only a small obstacle.
Security doesn't stem from using a specific language or a specific tool, it stems from good design and good basic understanding of the problems with security.
And remember security by obscurity (whether that means "hidden source code" or "unusual language" or something else obscure) is false security.
You might be interested in ATS, http://ats-lang.sourceforge.net/. ATS compiles via C, can be as efficient as C, and can be used in a way that is ABI-compatible with C. From the project website:
ATS is a statically typed programming language that unifies implementation with formal specification. It is equipped with a highly expressive type system rooted in the framework Applied Type System, which gives the language its name. In particular, both dependent types and linear types are available in ATS. The current implementation of ATS (ATS/Anairiats) is written in ATS itself. It can be as efficient as C/C++ (see The Computer Language Benchmarks Game for concrete evidence) and supports a variety of programming paradigms
ATS's dependent and linear type system helps produce static guarantees about your code, including various aspects of resource management safety.
Chris Double has been writing a series of articles exploring the power of ATS's type system for systems programming here: http://bluishcoder.co.nz/tags/ats/. Of particular note is this article: http://bluishcoder.co.nz/2012/08/30/safer-handling-of-c-memory-in-ats.html
This document covers aspects of calling back and forth between ATS and C code: https://docs.google.com/document/d/1W6DYQApEqKgyBzMbvpCI87DBfLdNAQ3E60u1hUiMoU0
The main downside is that dependently-typed programming is still a daunting prospect, even for non-systems programming. The syntax of the language is also a bit weird: consider lexical quirks such as the use of abst#ype as a keyword. Finally, ATS is to some degree a research project, and I personally don't know whether it would be sensible to adopt for a commercial endeavour.
Theoretically, it's going to be Fortran: less indirection (as in: my array is [here], not just a pointer to here, and this is true of most but not all of your data structures and variables).
However... There are many gotchas and quirks in Fortran: not, perhaps, as many as in C but you probably know your way around C rather better than Fortran. Which is the point behind most of the comments saying 'Know your code' - but do you really know what your compiler is doing?
Knowing you, I'm prepared to take it on trust that you do, for C. Most programers don't. You do not know and cannot know what a local JVM or JIT compiler does, and that's a black hole in your security model if you're using Java or C# r scripting languages.
Ignore anyone who tells you that the hairy-chested he-men of secure computing write their own assembler: they probably don't even know the security errors they're making in any and all nontrivial projects they release. Know your compiler, indeed.
You could write it in lua - providing a C API to a Lua library is relatively straight forward. C++ is also an option, though of course you'd have to write C wrappers and make sure no exceptions can escape your functions. But honestly, if it's security critical the minor inconveniences of the C language shouldn't be that much of a big deal. What you really should be doing is prove the correctness of your program where feasible, and test extensively where it's not.
You can write a library in Java. JNI is normally used to call C from Java, but it can be used the other way around.
There is finally a decent answer to this question: Rust.
Do any proposed, or implemented languages fit in the same (enormous) niche as C, with the intention of being an alternative, while maintaining all the applicability to OS, high performance, embedded and other roles?
There are quite a number of languages that were explicitly designed to fit all of that niche:
BitC
Cyclone
Forth
Mesa
CPL
BCPL (simplified version of CPL, implementation language of MULTICS)
B (Ken Thompsons first try at a systems programming language, based loosely on BCPL, precursor to C)
Ada
Go
D
C++
Modula-2 (specifically designed for the Lilith personal computer as a successor to Pascal for systems programming, also used by IBM as the implementation language for the original OS/400)
Oberon (specifically designed as a simpler successor to Modula-2)
Component Pascal (object-oriented successor to Oberon, despite the name it is not a direct successor to Pascal)
Modula-3 (despite the name not a successor to Modula-2 but an independent development)
Sing# (the implementation language of Microsoft Research's Singularity Research OS)
Limbo (language for the Inferno operating system (successor to Plan 9 (successor to Unix)))
Ooc
Erlang (maybe not for operating systems, but embedded realtime systems, especially in the telco industry (phone switches etc.), also lately (somewhat surprising to Erlang's inventors, actually) web servers, databsase systems, etc.)
Interestingly, there are also a number of languages that were not specifically designed to fill that niche, but that have been very successfully used in that niche:
Smalltalk (several Smalltalk OSs, embedded systems, microcontrollers, realtime systems, most famous: the Tektronix TDS500 series of digital oscilloscopes)
Lisp (several Lisp OSs, embedded systems, microcontrollers, some NASA spacecraft)
Java (several Java OSs (JNode, NewOS), embedded systems, microcontrollers, smartcards)
C# (several OSs (Cosmos, SharpOS), Mono is used in High-Performance Computing)
Haskell (the House OS, the seL4 verified microkernel)
Pascal (MacOS)
There's also a lot of languages that have not yet been used in that niche, but that certainly could be. (Mostly that is because those language communities themselves have been so indoctrinated by the "you can only write operating systems in C" bullshit that they actually believe their own language to be unusable.)
Ruby
Python
ECMAScript (which is actually used for writing high-performance webservers lately)
[Note that for each one of the three categories I listed there are literally thousands more languages that fit in there.]
In fact, one sometimes gets the feeling that languages which are not specifically designed for, say, operating system programming are actually better for that kind of thing. Compare, for example, the level of innovation, the stability, number of security holes, performance in something like a Smalltalk OS from the 1970s and Windows or OSX from 2010.
Personally, I believe that this is based on some deep-seated myths in the systems programming community. They believe that systems programming in a language with, say, strong typing, type safety, memory safety, pointer safety, automatic storage management is impossible and that the only way to get performance or realtime guarantees is to forego powerful abstraction facilities. However, it turns out that when you try to design a programming language for humans instead of machines, then humans can actually understand the programs they wrote, find security holes, fix bugs and locate and fix performance bottlenecks much better in a 1 line monad comprehension than in a 100 line for loop.
For example SqueakNOS, which is a variant of the Squeak Smalltalk system that runs without an OS (in other words: it is the OS) has pretty much all of the features that you would expect from a modern OS (graphical user interface, ...) plus some that you don't (embedded scripting language that can modify every single piece of the OS at runtime) and weighs in at just 300k SLOC and boots in less than 5 seconds while e.g. Windows weighs in at 50 million SLOC.
The obvious one is C++.
Does everything you describe, but extends C quite a bit with other features (Object Oriented, etc.).
Another interesting system programming language from Google: Go
BitC is a specific attempt. Here's a great article on alternatives to C, and why they've failed.
Ada is probably the most widely used language in this space apart from C.
It is designed above all to produce reliable bug free code, but, most Ada compilers produce well optimised effiecient machine code as well.
For a while this language was compulsary for Department of Defence projects and it is still widly used in avaionics, radar, navigation and weapons control systems.
You could consider D. From the homepage:
D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability.
The D language is statically typed and compiles directly to machine code. It's multiparadigm, supporting many programming styles: imperative, object oriented, and metaprogramming. It's a member of the C syntax family, and its appearance is very similar to that of C++.
Ada and in most cases Objective-C.
freepascal.
pascal was created even before C, when there was not enough RAM and CPU for virtual machines and is still used for exactly the same porpuses than C.
modern incarnations of pascal namely Delphi and freepascal added OO and generics, following the evolution C++ has represented.
they share many concepts and design like pointers, direct allocation deallocation of memory, direct call of ASM inside programs, they are so similar that is not unusual to load dll or c/c++ code in pascal programs and vice versa.
probably looking at ancient languages like Basic it is possible to find implementations that are fitting the same niche of c.
languages follow platforms...
Do any proposed, or implemented languages fit in the same (enormous) niche as C, with the intention of being an alternative, while maintaining all the applicability to OS, high performance, embedded and other roles?
OSs were historically implemented in assembler. Later on development shifted to C, which initially was a sort of macro assembler.
Now most OSs are written mostly in C because it is pretty much only language which maintains some sort of assembler backward compatibility (e.g. one can map one to one lion share of the assembler found in the hardware specs into C). And libc is the primary interface - often is the only interface - between kernel and user-space. And yet the interface covers not everything: some things in kernel has to be accessed directly as no standard interface is (yet) provisioned. E.g. one has to use a C struct to pass parameters/retrieve results to/from ioctl.
That means that the use of C in application development is in greater part pushed by the simple fact that if you use C you get automatically access to all the features of kernel (OS) which is also written in C.
Only language which can somehow compete with C is the language which is based/compatible with C. The sole alternative known to me is the C++. In older times there were also relatively popular translators like p2c (Pascal to C): developer programs in one language, but the source code is automatically translated into C for compilation. But the translators were rather buggy and without knowledge of C often programs couldn't be debugged. So if you have to know some C anyway, why bother with the translators.
I personally (and many other developers I'm sure) using various languages often stumbled upon the problem that the OS has a feature, but the language used doesn't provide any facility to access it. That I think is the major deterrent factor for other language development. Even if you have bright a idea for a new language (which is likely to be incompatible with C, otherwise idea wouldn't be that bright) you end up with the burden to reimplement interface to the pretty much whole OS (and various must-have application libraries).
As long as (1) C remain the sole language for system programming and (2) OS interfaces are still evolving, all non-C-compatible languages on the other side of fence, application development, would be at greater disadvantage.
P.S. Actually that is one of the molds I hope LLVM/clang might break. clang is implemented as a reusable library theoretically allowing to mix languages. E.g. main source file can be in one language (and parsed by one front-end), but the #includes could be in C (and parsed by the clang).
Scala Native tries to be the functional-programming & functional-objects evolution of C's niche. Scala Native generates hardware machine code instead of JVM. https://scala-native.readthedocs.io/en/v0.4.0/
I've been learning C: it's a beautiful, well-thought-out language. However, it is so low-level that writing any sort of major project becomes tedious.
What higher-level language has the most C-like syntax—but without all the clutter that you find in something like C++. Does one exist?
What higher-level language has the most C-like syntax—but without all the clutter that you find in something like C++?
I'm going to answer a slightly different question:
What is a language that is like C in that it is well designed and beautifully thought out, is like C in that it is good for systems programming, allows people to program at a higher level than C, and is relatively uncluttered?
I don't think this question has a single right answer, but here are three worthy candidates (in alphabetical order):
D. The D language is designed essentially as a better, cleaner C++. Like C++, D is explicitly designed to incorporate a lot of features, but one hopes in a cleaner, more harmonious way than C++. A major difference that enables programmers to work at a higher level is that memory is managed automatically by the language and safety is guaranteed by the compiler (and run-time system) through garbage collection.
Go. Go scores very high on being well designed and beautifully thought out: Rob Pike is a master designer and has been practicing this particular craft for 25 years. Its explicit goal is to be uncluttered and to make systems programming "fun again". Go is still a new language, and Rob has learned much from Squeak, Newsqueak, Alef, and Limbo. Because Rob understands that a great design is one with no unnecessary parts, Go is clean and uncluttered. Its primary features that are higher-level than C are type safety, garbage collection, and an excellent concurrency model.
Java. Java has a well-designed core (see Jim Waldo's book Java: The Good Parts) but unfortunately suffers from the clutter that any mature, successful language accumulates. The features of Java that make it most suitable for higher-level programming are interfaces, garbage collection, and exceptions.
The common thread here is using garbage collection to relieve the programmer of the burden of memory management. This is a major boost to productivity.
Each of these languages has much to recommend it. My own taste is for languages that are small and simple, and I admire Rob Pike's body of work very highly, so if I had to pick one for myself, it would be Go, despite the fact that it is new and unproven.
In C++ you can write C code and have it compile successfully as C++ (mostly). Therefore, although I suggest that your term "clutter" is both derogatory and ambiguous, the only clutter you will have is what you choose to write yourself. You can use C++ as a bigger tool-bag without using all the tools (or clutter if you prefer).
The answer therefore is C++ whether you like it or not. Most other C-like languages add OO features, which is perhaps what you regard as clutter, but you do not get something for nothing and you need to have syntax to support the additional features. Such languages include:
Java
C#
Objective-C
D
Of these Objective-C is probably the most C-Like since it is a superset of C in the way that C++ is not quite. It is also the preferred language for OSX and iPhone/iPod Touch development, which may be attractive.
Java is ubiquitous but probably best described as superficially C-like. C# has limited cross-platform support but is the path of least resistance for Windows GUI development with excellent free development tools. C# also has a simpler but more restrictive OO implementation than C++ so may meet your requirements, but its resemblance to C/C++ can be misleading; it is fundamentally different in how it works in a similar manner to Java. D is somewhat of a niche, being developed by a single author (albeit the author of the once renowned Zortech/Symantec C++ compiler).
Regarding it being "low level" and "tedious", when embarking on a "major project", you would seldom start from scratch with only the standard library and OS API available, you would make use of third-party and in-house developed libraries to quickly develop higher level functionality. That said, an OO approach is generally much more amenable to this 'code-reuse' approach, and of course C++'s standard library and third-party libraries are more extensive (not least because it can use C libraries as well as C++ libraries). In fact I would suggest that apart form support for OO, the only thing that makes C++ higher-level is its extensibility via classes as first-class objects. It remains suitable as a systems-level language nonetheless.
Google's Go language has a similar syntax (though different enough I suppose) and semantics, though with garbage collection, polymorphism, etc., built into the language.
The D programming language is an attempt to be what C++ should have been (not bashing on C++ at all it is my primary language) and I quote from the website, "D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability. " The issue with D is it is relatively new compared to a lot of languages but luckily it can still use C libraries which allows it to access a large pre-existing code base. Certainly worth checking out.
Java is another option however it is notably slower than C. Syntactically it is very similar and offers a nice object orientated environment for writing code. It is also considered by most to be a safer language than C and C++. It is widely used in enterprise.
Python while syntactically not like C is a high level Object Orientated Programming Language that is very popular and can import C modules which may be very useful down the track.
This is too broad a question and is best made Community wiki.
However, in my mind, the main distinguishing feature of C is it's compactness. The whole language can be described in a small book like K&R. One can remember all the syntactic details without much effort (since there are so few of them) and it doesn't try to protect it's users from themselves.
Languages like C++ are much more baroque. It's quite hard to remember all the rules and exceptions. I feel the same way about Perl and Ruby. There are lots of things to remember and lots of things to watch out for.
I feel the same sense of compactness with Python (although perhaps not as much as C). There's very little "special syntax" and all libraries and modules are operated upon in a similar fashion.
This (probably like most other comments on this question) is a personal evaluation and is by no means a final word.
Probably Java and C#... Java a little more so I think.
And it's not the language - it's all about the libraries. Try out Qt (http://qt.nokia.com/). It's for C++ and I know you said C but I'm just making a point that you'll find yourself writing just as little (and perhaps even less!) code than you'd write for applications in Java or C#. Plus they're native and cross-platform.
All about the libraries.
I've been learning C: it's a beautiful, well-thought-out language. However, it is so low-level that writing any sort of major project becomes tedious.
Some people would say that the second sentence proves that the assertion of the first sentence is false.
Another point is that this is pretty much unanswerable. What is a "high level" language? what are your criteria for "closeness"? Syntax, computational model, performance? And what kind of applications are you wanting to build with this hypothetical language?
And if you just want to confine yourself to languages that "look like" C, why? As someone who has lost count of the number of programming languages he has used, I can tell you that differences in programming language syntax are generally pretty unimportant. You can get used to pretty much any syntax, given time.
This comparison of basic instructions gives you a good idea of what languages are similar to each other.
I would say PHP is most like C except for the $variables, if you can distinguish php the language from php the platform. Java tries in some ways, but is too strongly object oriented to be similar to C.
Javascript has a reasonably C-like syntax, and it's a very popular language. Javascript has a lot of quirks, but it has one powerful similarity to C - it's simple. The complete Javascript specification is very short, and the language is very powerful and high-level. It would be great to clean it up from some of its ugly cruft, though.
I'll just point out that Pascal is semantically (though not so much syntactically) very similar to C, so there are options like Object Pascal, Modula 2, Ada and Oberon out there where you will be re-using most of the non-trivial part of what you already know, the trivial part being the spelling.
You're probably better off sticking with C# or Java in terms of job prospects, though.
EDIT
I'll also add that on the clutter issue, it is important to sort out which clutter is important. C has less "clutter" in it's language definition, true, but the relevant clutter is in source code. Consider the following...
// C
struct mystruct *myvar;
myvar = (struct mystruct *) malloc (sizeof (struct mystruct));
myvar->a = 1;
myvar->b = 2;
myvar->c = 3;
call_something (myvar);
free (myvar);
// C++
auto_ptr<mystruct> myvar (new myclass (1, 2, 3));
call_something (myvar);
The point is that the "clutter" in the language definition is there for a reason. With a little up-front work when writing libraries, a lot of work (and clutter) is avoided down the line. And even when you're writing a library, you benefit from the up-front work done by other library writers.
I'd vote C#. I don't know what you mean by "clutter," but from a usability standpoint, C# is nice because it avoids some of the tedious things of C++, like having to essentially "declare" each of your class's methods twice (prototyping it in the header file, then essentially duplicating the same thing in your class's implementation). Ditching header files was nice in other ways too, like doing away with dependency conflicts in big projects or avoiding circular references. In C#, the compiler takes care of all that (although you still have to set references to other files or assemblies).
I've been doing C# for 10 years and I still miss pointers, which believe it or not, in my opinion, actually made debugging easier!
If you're going to be programming often, it's good to know languages that are explicitly not like each other. It's especially useful to know high level scripting languages like python or ruby. If you can think like a programmer in C you should be fine learning either of these two.
Many big projects take advantage of the rapid prototyping of higher level languages like python or ruby, but also take advantage of low overhead (fast) compiled languages like C/C++.
If you think that C++ is cluttered, then you just don't know how to write effective C++, because nobody forces you to use any of the advanced tools available. You could write a C++ program entirely in C plus your favourite C++ feature (like the AWESOME standard library). That's the definition of uncluttered. A cluttered language would be Java/C#, where you HAVE to put every function in a class. That's clutter.
How about ActionScript 3? It's a lot like Java.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Why is C used for writing drivers and OS codes?
Is there a size problem?
Are there any drivers written in other languages?
Which language were XP, Vista, and Solaris written in?
C compiles down to machine code and doesn't require any runtime support for the language itself. This means that it's possible to write code that can run before things like filesystems, virtual memory, processes, and anything else but registers and RAM exist.
In safety-critical environments (think avionics, spacecraft, medical devices, transportation, control software for process control), systems (as well as drivers) are often written using Ada or even SPARK/Ada.
To clarify: C is usually understood to be fairly low level, and pretty much like a "macro language" for assembly itself, that's also where its power is coming from (speed, size, portability).
Ada, on the other, hand has been specifically designed for safety-critical applications with verifiability in mind, to quote Ada 2005 for Mission-Critical Systems:
Ada [9] is the language of choice for many critical systems due to its careful design and the existence of clear guidelines for building high integrity systems [10]
That's also where Ada's support for strong typing comes in, as well as a number of other important features (quoting design for safety):
Programming languages differ wildly in
their appropriateness for use in
safetyrelated systems. Carré et al.
identified six factors that influence
the suitability of a language for
high-integrity applications [Carré
1990]. These are:
Logical soundness
Complexity of definition
Expressive power
Security
Verifiability
Bounded time and space constraints
No standard programming language performs
well in all these areas although some
(such as Pascal and Ada) perform much
better than languages such as C or
C++. In highly critical applications
‘verifiability’ is of great
importance. Certain languages allow
powerful software verification tools
to be used to perform a wide range of
static tests on the code to detect a
range of programming errors.
[...] An
important issue in the selection of a
programming language is the quality of
the available compilers and other
tools. For certain languages validated
compilers are available. While not
guaranteeing perfection, validation
greatly increasing our confidence in a
tool. Unfortunately, validated
compilers are only available for a
limited number of languages, such as
Ada and Pascal. In addition to
compilers, developers of critical
systems will make use of a range of
other tools such as static code
analysis packages. The static tests
that can be performed on a piece of
code vary greatly depending on the
language used. To aid this process it
is common to restrict the features
that are used within certain languages
to a ‘safe subset’ of the language.
Well structured and defined languages
such as subsets of Ada, Pascal and
Modula-2 allow a great many tests to
be performed such as data flow
analysis, data use analysis,
information flow analysis and range
checking. Unfortunately many of these
tests cannot be performed on languages
such as C and C++ .
It would be really beyond the scope of this question to go into even more detail, but you may want to check out some of the following pointers:
Ada compared to C and C++
Ada vs. C
Quantifying the Debate: Ada vs. C++
Why choosing Ada as a teaching language? (Ada vs. C in University)
Comparing Development Costs of C and Ada (summary)
C / C++ / Java Pitfalls
& Ada Benefits
Is Ada a better C?
Ada, C, C++, and Java vs. The Steelman
Ada: Dispelling the Myths
Real-time programming safety in Java and Ada
If anyone wants to look into Ada some more, check out this: Ada Programming (wikibooks)
There are even programming languages that are specifically developed for highly critical applications, such as JOVIAL or HAL/S, the latter of which is used by the space shuttle program.
Is there any drivers written in any other languages?
I have seen some Linux drivers for special hardware being written in Ada, don't know about other operating systems though. However, such drivers usually end up wrapping the the C API.
Because C has the best combination of speed, low memory use, low-level access to the hardware, and popularity.
Most operating systems have a kernel written in C, and applications on top of that written in either C, C++, C# or Obj-C
C is by far the easiest language(other than assembly) to "get going" on bare bones hardware. With C, (assuming you have a 32bit bootloader such as GRUB to do the hard mode switching) all you must do is make a little crt0.asm file that sets up the stack and that's it(you get the language, not including libc). With C++ you must worry about dynamic casts, exceptions, global constructors, overriding new, etc etc.. With C# you must port the .Net runtime(which on it's own basically requires a kernel) and I'm not sure about Obj-C, but Im sure it has some requirements also...
C is simply the easiest language to use for drivers. Not only is it easy to get started with, but also it's easy to know exactly what happens at the machine level. Their is no operator overloading to confuse you and such. Sure it's handy in a "good" environment, but in Ring 0 where a bad pointer not only crashes your application, but usually results in a triple fault(reboot), blue screen, or kernel panic. You really like knowing what goes on in your machine..
"why we are using C language for writing drivers and OS codes.?"
So that programmers won't have to learn new syntax of each new assembly language for each new kind of machine.
"Is there any drivers written in any other languages?"
Historically, assembly languages. I don't remember if PL/S or BLISS could be used for drivers. Maybe B. In modern times, a few brave people use C++ but they have to be very careful. C++ can be used a bit more easily in user mode drivers in some situations.
Lisp machines had their operating systems written in Lisp, which shows that you don't have to use C or assembly. The Lisp machine business was destroyed by the availability of cheap PCs, whose operating systems were of course written in C and assembly.
C was one of the very first languages (that wasn't assembly) that was suitable for writing operating systems, so it caught on early. While other languages have appeared since that are also suitable for writing operating systems in, C has remained popular perhaps due to its long history and the familiarity programmers have with its structure and syntax.
C is also a language that teaches a lot about memory management and is low-level enough to show the barrier between hardware and software. This is something that is rare among many methodologies today, that have grown more towards abstraction way above anything at the hardware level. I find C is a great way to learn these things, while being able to write speedy code at the same time.
Remember that C was originally developed for writing operating systems (in this case - Unix) and similar low-level stuff. It is wery close to the system architecture and does not contain any extra features that we want to control, how they exactly work. However, please note that the rest of the operating system, including the programming libraries, does not have to be written in the same language, as the kernel. The kernel functions are provided through a system of interrupts and in fact such programming libraries can be written in any language that supports assembler snippets.
The most popular operating system nowadays are written in C: Windows, Linux and many other Unix clones, however this is not the rule. There are some object-oriented operating systems, where both the kernel and the programming interface are written in an objective language, such as:
NeXTSTEP - Objective-C
BeOS - C++
Syllable - C++
See: Object-oriented operating system on Wikipedia
Note that in Linux, it is possible to write kernel drivers in the languages other than C (however, it is not recommended). Anyway, everything becomes a machine code when it comes to running it.
"C compiles down to machine code and doesn't require any runtime support for the language itself."
This is the best feature of C
It's my belief that languages like Python, Java, and others are popular mainly because they offer extensive standard libraries that allow the programmer to code a solution in less lines. Literally a ruby programmer can open and read a file in one line where in C it takes multiple lines. However beneath this abstraction are multiple lines. Therefore the same abstraction be done in C and it's recommended. Oddly it seems the C philosophy is not to reduce the total lines of code so there is no organized effort to do so. C seems to be viewed as a language for all processor chips and naturally this means that it's hard to create any 'standard' abstracted one line solutions. But C does allow you to use #ifdef preprocessor commands so in theory you can have multiple variations of an implementation for multiple processors and platforms all on one header file. This can't be the case for python, or java. So while C does not have a fancy standard library it's useful for portability. If your company wants to offer programs that run on computers, embedded, and portable devices then C is your choice language. It's hard to replace C's usefulness in the world.
As another note for machines that have drivers in other languages, there is the SunSpot robotics platform. Drivers for devices that are connected (sensors, motors, and everything else that can communicate via the I/O pins) are written in Java by the user.
Does anyone have any experience with doing this? I'm working on a Java decompiler right now in C++, but would like a higher level language to do the actual transformations of the internal trees. I'm curious if the overhead of marshaling data between languages is worth the benefit of a more expressive and language for better articulating what I'm trying to accomplish (like Haskell). Is this actually done in the "real world", or is it usually pick a language at the beginning of a project and stick with it? Any tips from those who have attempted it?
I'm a big advocate of always choosing the right programming language for each challenge. If there is another language which handles some otherwise tricky task easily, I'd say go for it.
Does it happen in the real world? Yes. I am currently working on a project which is made up of both PHP and objective-c code.
The trick is, as you pointed out, the communication between the two languages. If at all possible, let each language stick to its own domain, and have the two sections communicate in the simplest way possible. In my case, it was XML documents sent via http. In your case, some kind of formatted text file might be the answer.
Marshalling costs depend on the languages and architecture you're working with. For example, if you're on the CLR or JVM, there are low-cost interop solutions available - though I know you are working with probably unmanaged C++.
Another avenue is an embedded domain-specific language. Tree transformations are often expressible via pattern matching and application of a relatively small number of functions. You could consider writing a simple tree pattern-matcher - e.g. something that looks like Lisp s-exprs but uses placeholders to capture variables - with associated actions that are functions that transform the matched subtree.
John Ousterhout, the inventor of Tcl/Tk was a stong advocate of multi-language programming and wrote quite extensively about it. In order to do it, you need a clean interface mechanism between the languages you are using for it. There are quite a few mechanisms for this. Examples of different mechanisms for doing this are:
SWIG (Simplified Wrapper and
Interface Generator can take a c
or c++ (or several other languages)
header file and generate an
interface for a high level language
such as perl or python that allows
you to access the API. There are
other systems that use this
approach.
Java supports JNI, and various
other systems such as Python's
ctypes, VisualWorks DLL/C
connect are native mechanisms
that allow you to explicitly
construct the call to the lower
level subsystem.
Tcl/Tk was designed explicitly to be
embeded, and has a native API
for a C library to add hooks into
the language. The constructs for
this resemble argv[] structures in
C, and were designed to make it
relatively easy to interface a
command-line based C program into
Tcl. This is similar to the above
example, but coming from the opposite
direction. Many scripting languages
such as Python, Lua and Tcl support
this type of mechanism.
Explicit glue mechanisms such as
Pyrex, which are similar to a
wrapper generator, but have their
own language for defining the
interface. Pyrex is actually a
complete programming language.
Middleware such as COM or
CORBA allow a generic
interface definition to be built
externally to the application in an
interface definition language
and language bindings for the
languages concerned to use the
common interface mechanism.