As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I've been getting into compiler creation. I've found some terrific beginner stuff and advanced stuff but nothing in the middle. I've created 3 different simple proof-of-concept compilers for toy languages but I want to expose myself to something real.
The most straight forward real language in terms of syntax seems to be C. Since the language I'm most comfortable with right now is C#, I'd love to study the source code of a real non-tutorial C compiler written in C#. Does one (with source code available) exist?
Ideally I'd like a C compiler, not a .NET or C# compiler, but with the source code written in C#.
I know C# --> C feels a little backwards but it'll allow me to ease deeper into compilers starting with a familiar language before I go changing that too.
Although I'm not looking for C#/.NET compilers, here are some in case someone sees this question who is looking for that:
Create a Language Compiler for the .NET Framework
Mono C# Compiler
Source for a C# compiler written in pure C# (.NET v1) (thanks Luiscencio)
You are going to have a hard time finding sample code. Compiler writers use bootstrapping. The first C compiler was written in B. Which was then used to write the first C++ compiler. Which was used to write the C# compiler. Which is very commonly used to write compilers for managed code.
This is not a process that ever goes backwards. Although side-ways was common, C compilers often were used to cross-compile a compiler for another operating system.
I think I used this book, it has terrific C compiler code in the appendices. Written in C. I used parts of it when writing a Basic compiler I needed in a large project. The expression parser is hard to get right, it has an elegant solution for the operator precedence rules.
Targeting a managed language is the easier way to get this going. The language shouldn't matter too much, it is getting it working that is the real challenge. Even though it is a lot easier to get managed code working. If you want to target C, you'll need black-belt machine code skillz and deep insight in the object file format and the linker.
The most straightforward real language in terms of syntax seems to be C.
I'm not sure what you mean by "real language", but whatever "real language" means, I cannot agree that C has a "straightforward" lexical or syntactic grammar, and its semantics are underspecified. If you want an extremely straightforward language with pretty well-defined semantics, why not go for Scheme? Scheme has a very easy grammar but is certainly not trivial to get its semantics right.
found this via google.
http://blogs.msdn.com/jmstall/archive/2005/02/06/368192.aspx
EDIT: and this (not exactly C):
http://msdn.microsoft.com/en-us/magazine/cc136756.aspx
I don't know of one that exists, but there's no reason one couldn't, or shouldn't.
Writing a compiler for a C-like language is a classic project for one-semester college compiler courses. If you know C# already, it provides a lot of features which will make your job easier than when I was in college! There are plenty of libraries sitting around which will make the job easier, without taking away the challenge, and you can always replace them with your own ad-hoc code if you need flexibility they don't provide.
The first C compiler was written in BCPL because it's what they had. Current C compilers are usually written in C because they aim to be portable. I don't think anyone would argue that C is a good language for writing compilers in. (C# isn't perfect but it's a lot better!) In a statically-compiled language like C, I don't think you get much benefit, if any, from using the target language to write the compiler.
A compiler in an HLL potentially has many advantages. It'd be shorter and simpler than one written in C. That alone could make a lot of things sufficiently easier that they could be pulled below the threshold of "too hard that nobody's ever going to do them". (GCC is kind of the poster-child for how a compiler written in a LLL can be so complex that it moves at a glacial rate.) Optimizations are basically graph transformations, which aren't exactly C's forte.
I don't consider it "backwards" at all to use C# to compile C. Unless somebody's proposing to rewrite all their C code in a higher-level language, it still needs to be compiled somehow, and that means you need a compiler. Shouldn't that compiler be written with tools that enable it to offer the best reliability and performance?
Good luck! I look forward to seeing what you write!
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Today the Common Language Run Time Supports Many Languages including Iron Python and Iron Ruby. We can similarly can use J Ruby and J Python in Java Run Time environments . If so why the .net frame work common language run time cannot support for Java? Um just curious to know though u may see this as a dumb question .
The CLR was actually designed so that it could do everything required to run Java. (Indeed, there are some warts in the way IL is defined which are there specifically for compatibility with Java.) You just need a way of converting bytecode to IL, or compiling from Java source code to IL. J# was one way of doing this, but the limitation of using Java 1.1.4 was a pretty huge one.
I suspect the reason for not going further wasn't an issue with running Java as a language, but the fact that system libraries would need porting. If you were willing to write Java-like source code but target .NET framework libraries (and only .NET framework libraries), with a version of the JLS which switched java.lang.String to System.String etc, it would be doable. I don't think there'd be much benefit though, when C# is simply a nicer language in almost all ways.
You may be interested in looking at IKVM.NET though - an implementation of Java running on the CLI.
First of all, Java may only be called Java if it compiles to JVM bytecode and runs on a certified JVM (iirc), those were the reasons behind Microsoft's efforts being named J++ and J#.
Then there is still J#, which is something close to Java, running on the CLR.
Then there is IKVM which is an implementation of a JVM and the class library on top of the CLR.
Actually, the class library might be the most annoying thing in this case. J# comes with an own library containing the Java core classes just for that purpose and the language closely ties in with that class library (just as it does in .NET).
The final thing though is probably: Why bother at all? Java itself would be a sub-par language on the CLR, where careful effort is needed to recreate things like its not-actual generics. Due to this interoperability with other CLR languages will likely be limited, too. There are powerful translators from Java to C# if you have a large Java codebase and want to use .NET, but a CLR-native Java, compatible with SuOracle's would be a lot of effort for something that you'd only want to touch for compatibility purposes and which poorly interfaces with the CLR or other .NET languages.
CLR does support J#. In an utopian world CLR should have supported C# and Java, but Java is a competitor to Microsoft's C# and hence it won't support Java.
The way I see it, C# is a superset of Java, so you should technically be able to compile a Java class to CIL.
As others have pointed out, Microsoft has no intention of supporting their competition, however I see there have been some projects, such as Ja.NET, to compile Java code to the CLR. There's also IKVM.NET, which among other things seems to be able to translate Java bytecode to CIL, and includes the Java class library from OpenJDK compiled to .NET.
The respective Virtual Machines act on Intermediate Code in a different language (CIL for .net), and IL for .net and JVM are incompatible with each other.
The IL and Runtime features sometimes disallow a few things, for example Generics in C# are closely tied to how Generics in the .net Runtime work, while Java has a completely different implementation.
Still, there shouldn't be much technically preventing Java from running on .net, just no one did it yet. It's a massive effort, for what? Is there really enough money to make? If there is a business, someone will do it. But if you're in the business of Java, then most likely you are also tied closely to it's tools and environments, e.g. Eclipse and Tomcat, possibly Ant and Maven.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been using C/C++ and Python, but I now I see that a lot of new programming books use Java or C# as examples.
I don't think I'll use Java or C# for the time being, but I guess I have to study one of the languages (or both of them) in order to read/understand the books.
How similar Java and C#? If I learn Java, is learning C# almost free? Or vice versa?
If I have to choose only one of the two languages, which would be better? Which has wider coverage in terms of programming language?
You are asking several questions at once. Let me address them separately:
How similar Java and C#?
Both C# and Java drew from C/C++ (and Objective C, and others) to define their syntax. And both of them are compiled to an intermediate language.
This common origin makes the languages look similar in many levels, to the point that code in either language can be confused with the other by beginners; and also makes the runtime environment somewhat comparable. However, there are substantial differences in both design principles and how each language evolved that make working with each quite different; here are the most prominent ones:
On the syntax level, Java was influenced by Smalltalk, while C# tried to stay closer to C/C++ (eg: compare Java's extends and implements with C#'s : notation) and took a vague inspiration from VB on those concepts that weren't mappable to C/C++ (example: property syntax).
On the features level, C# 1 was definitely close to Java. Among the few differences they had, I'd highlight C#'s support for "unsafe" code (including pointers) and for delegates; and Java's controversial throws. This makes sense, since one of the goals of C# was to become an alternative to Java.
Many language features differ heavily on implementation details. For example, enums are very C'ish on C#, but are full objects in Java; or generics are implemented on the IL-level in C#, but in Java are dealt with via type erasure (neither is really close to C++'s templates besides syntax).
On the API level, they are worlds apart. C# relies on the .Net Framework, which was built on Microsoft's experience with the Visual Studio family of products (and thus is significantly Windows-oriented), while Java's Class Library was built, IIRC, from scratch, and heavily evolved over time (on these Swing days, does anyone remember AWT? I do).
Finally, it's worth mentioning that each of the languages has its own idioms, and its own community of supporters behind it.
If I learn Java, is learning C# almost
free? Or vice versa?
Neither. The key similarity is the basic syntax (semicolons, curly braces, array indexing, case-sensitiveness, etc), and you already have that from C/C++.
If I have to choose only one of the two languages, which would be better?
Short answer: flip a coin.
Long answer: it depends on your coding style and on what aspects of the language you value most. My best advise is to start by trying to learn both, until you feel that one of the languages pulls you more strongly than the other.
Alternatively, you can take a look at http://en.wikipedia.org/wiki/Comparison_of_Java_and_C_Sharp.
Which has wider coverage in terms of programming language?
If you mean language built-in features, I'd say C# wins for a narrow margin. Most of the features that C# has and Java lacks are syntax sugar (although they together make a significant difference on the learning curve and on the way the language is used). I value really high C#'s operator overload and extension methods. Also, LINQ is quite an interesting concept, but it is essentially a declarative syntax for loops.
Hope this helps.
The libraries are very different, and the approach to documentation is very different. I find the C# approach to easier.
To illustrate what I mean, in either language some object that you want to deal with may be implemented by inheriting from "object" to "generic object" to "specific object." In Java, if you want to find out about a property of the "generic object" you have to go to the doc for that, whereas in C# documentation, all the properties are listed for the "specific object."
At least that's the way it seemed to me back a few years ago when I did some Java.
If you want a brutally subjective answer.
I have just finished a degree in Computer Science in England, I chose a university that taught C# as opposed to Java.........reason being, so I could easily walk straight into a highly paid job as a software developer with a company that simply only wants people who know the "new" technologies.
These are companies such as Investment Banks, tech startups, IT Consulting firms.
So if you want to pick one to learn......
Think about the end goal.....if it's cash and modern knowledge...follow C#.
....and if it's anything else, follow C#
P.S. Java is terrible - I had to say it.
Not a 1:1 mapping since C# 1.0. C# has added lots of stuff (LINQ, closures,etc.) that have no analog in Java.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I work for a tech company that does more prototyping than product shipment. I just got asked what's the difference between C# and F#, why did MS create F# and what scenarios would it be better than C#.
I've been using the language for a while now and I love it so I could easily go on about the great features of F# however I lack the experience in C# to say why we should use one over the other.
What's the benefits of using C# vs F# or F# vs C#?
General benefits of functional programming over imperative languages:
You can formulate many problems much easier, closer to their definition and more concise in a functional programming language like F# and your code is less error-prone (immutability, more powerful type system, intuitive recurive algorithms). You can code what you mean instead of what the computer wants you to say ;-) You will find many discussions like this when you google it or even search for it at SO.
Special F#-advantages:
Asynchronous programming is extremely easy and intuitive with async {}-expressions - Even with ParallelFX, the corresponding C#-code is much bigger
Very easy integration of compiler compilers and domain-specific languages
Extending the language as you need it: LOP
Units of measure
More flexible syntax
Often shorter and more elegant solutions
Take a look at this document
The advantages of C# are that it's often more accurate to "imperative"-applications (User-interface, imperative algorithms) than a functional programming language, that the .NET-Framework it uses is designed imperatively and that it's more widespread.
Furthermore you can have F# and C# together in one solution, so you can combine the benefits of both languages and use them where they're needed.
It's like asking what's the benefit of a hammer over a screwdriver. At an extremely high level, both do essentially the same thing, but at the implementation level it's important to select the optimal tool for what you're trying to accomplish. There are tasks that are difficult and time-consuming in c# but easy in f# - like trying to pound a nail with a screwdriver. You can do it, for sure - it's just not ideal.
Data manipulation is one example I can personally point to where f# really shines and c# can potentially be unwieldy. On the flip side, I'd say (generally speaking) complex stateful UI is easier in OO (c#) than functional (f#). (There would probably be some people who disagree with this since it's "cool" right now to "prove" how easy it is to do anything in F#, but I stand by it). There are countless others.
F# Has Better Performance than C# in Math
You could use F# projects in the same solution with C# (and call from one to another)
F# is really good for complex algorithmic programming, financial and scientific applications
F# logically is really good for the parallel execution (it is easier to make F# code execute on parallel cores, than C#)
To answer your question as I understand it: Why use C#? (You say you're already sold on F#.)
First off. It's not just "functional versus OO". It's "Functional+OO versus OO". C#'s functional features are pretty rudimentary. F#'s are not. Meanwhile, F# does almost all of C#'s OO features. For the most part, F# ends up as a superset of C#'s functionality.
However, there are a few cases where F# might not be the best choice:
Interop. There are plenty of libraries that just aren't going to be too comfortable from F#. Maybe they exploit certain C# OO things that F# doesn't do the same, or perhaps they rely on internals of the C# compiler. For example, Expression. While you can easily turn an F# quotation into an Expression, the result is not always exactly what C# would create. Certain libraries have a problem with this.
Yes, interop is a pretty big net and can result in a bit of friction with some libraries.
I consider interop to also include if you have a large existing codebase. It might not make sense to just start writing parts in F#.
Design tools. F# doesn't have any. Does not mean it couldn't have any, but just right now you can't whip up a WinForms app with F# codebehind. Even where it is supported, like in ASPX pages, you don't currently get IntelliSense. So, you need to carefully consider where your boundaries will be for generated code. On a really tiny project that almost exclusively uses the various designers, it might not be worth it to use F# for the "glue" or logic. On larger projects, this might become less of an issue.
This isn't an intrinsic problem. Unlike the Rex M's answer, I don't see anything intrinsic about C# or F# that make them better to do a UI with lots of mutable fields. Maybe he was referring to the extra overhead of having to write "mutable" and using <- instead of =.
Also depends on the library/designer used. We love using ASP.NET MVC with F# for all the controllers, then a C# web project to get the ASPX designers. We mix the actual ASPX "code inline" between C# and F#, depending on what we need on that page. (IntelliSense versus F# types.)
Other tools. They might just be expecting C# only and not know how to deal with F# projects or compiled code. Also, F#'s libraries don't ship as part of .NET, so you have a bit extra to ship around.
But the number one issue? People. If none of your developers want to learn F#, or worse, have severe difficulty comprehending certain aspects, then you're probably toast. (Although, I'd argue you're toast anyways in that case.) Oh, and if management says no, that might be an issue.
I wrote about this a while ago: Why NOT F#?
You're asking for a comparison between a procedural language and a functional language so I feel your question can be answered here: What is the difference between procedural programming and functional programming?
As to why MS created F# the answer is simply: Creating a functional language with access to the .Net library simply expanded their market base. And seeing how the syntax is nearly identical to OCaml, it really didn't require much effort on their part.
F# is not yet-another-programming-language if you are comparing it to C#, C++, VB.
C#, C, VB are all imperative or procedural programming languages. F# is a functional programming language.
Two main benefits of functional programming languages (compared to imperative languages) are 1. that they don't have side-effects. This makes mathematical reasoning about properties of your program a lot easier.
2. that functions are first class citizens. You can pass functions as parameters to another functions just as easily as you can other values.
Both imperative and functional programming languages have their uses. Although I have not done any serious work in F# yet, we are currently implementing a scheduling component in one of our products based on C# and are going to do an experiment by coding the same scheduler in F# as well to see if the correctness of the implementation can be validated more easily than with the C# equivalent.
F# is essentially the C++ of functional programming languages. They kept almost everything from Objective Caml, including the really stupid parts, and threw it on top of the .NET runtime in such a way that it brings in all the bad things from .NET as well.
For example, with Objective Caml you get one type of null, the option<T>. With F# you get three types of null, option<T>, Nullable<T>, and reference nulls. This means if you have an option you need to first check to see if it is "None", then you need to check if it is "Some(null)".
F# is like the old Java clone J#, just a bastardized language just to attract attention. Some people will love it, a few of those will even use it, but in the end it is still a 20-year-old language tacked onto the CLR.
One of the aspects of .NET I like the most are generics. Even if you write procedural code in F#, you will still benefit from type inference. It makes writing generic code easy.
In C#, you write concrete code by default, and you have to put in some extra work to write generic code.
In F#, you write generic code by default. After spending over a year of programming in both F# and C#, I find that library code I write in F# is both more concise and more generic than the code I write in C#, and is therefore also more reusable. I miss many opportunities to write generic code in C#, probably because I'm blinded by the mandatory type annotations.
There are however situations where using C# is preferable, depending on one's taste and programming style.
C# does not impose an order of declaration among types, and it's not sensitive to the order in which files are compiled.
C# has some implicit conversions that F# cannot afford because of type inference.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 14 years ago.
What do you see as benefits for one over the other? As far as I know, it's just preference. I have way more experience with C# than I do with Visual Basic and was wondering if I should dabble in Visual Basic for certain types of projects?
VB4 was my first language, with VB6 being the last time I touched it. I have moved to c# and wouldnt consider going back. VB just feels too fat and fluffy for me (preference).
All the .NET languages compile to IL though...
Note: c# is "closer" to java...
I personally prefer C#, I love the syntax and I feel really comfortable with the language.
Some say that C# programmers are paid better than VB programmers, but I think you should try both languages and see on which you fell better.
Top 10 reasons C# is better than VB.NET
Top 10 reasons VB.NET is better than C#
If you plan on doing any SSIS you will need to know VB. This one of few areas that I am aware of in which it truly matters which language you choose as SSIS only supports VB for any "integrated" code you write for it.
You are correct in saying that it is a preference as all .NET languages are compiled to IL. So choose the one you are most comfortable with and don't worry too much about it.
Coming from a curly-braces background I find c# to be a lot easier to read and write. I find VB.Net to be too verbose and some of the syntax (I'm looking at you, arrays) makes my eyes water.
I also get frustrated by the background compilation in VB.Net, especially on large projects where it can make the IDE unresponsive.
The only advantage VB.Net has over C# in my opinion is optional parameters. These make certain interop tasks a lot easier but I think c# is due to get them in 4.0.
VB.NET
In my opinion, C# was created only for marketing reasons to bring Java developers to .NET.
There are many more developer jobs in the job marketplace for C# over VB. Visual Basic got a bad wrap from the get go because it was an interpreted language. Back in the early days of computers, interpreted was bad and slow.
In the beginning, Microsoft built VB mostly for consultants to be able to quickly and effectively write internal software.
I cringe when I see C#, but these days, I write in JavaScript more than any other language and I love it.
VB's language keywords makes more sense to me over C#'s such as Imports vs Using. With declarations, I do not like having object type coming before the variable's name. And it seems that C# has many hidden rules with parenthesis and what not that a developer must know just to even read C#. Whereas VB is straight to the point and flows very nicely without crazy syntaxes.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
At my university most of my classes have been in Java. I have also recently learned C# (and the Visual Studio environment) at a summer internship. Now I'm taking an Intro to Computer Graphics class and the grad student teaching the class prefers us to use C++ to access the OpenGL bindings via GLUT.
Does anyone have any good resources on how to make a good transition from Java/C# to C++? Obviously pointers are going to be a big issue, but any other things I should be looking out for? Any tutorials, guides, etc. would be very helpful!
Thanks!
Yeah, I got bit by the same bug. The university tended to lean on Java, and then allowed you to choose the language you wanted to work with during projects.
The best way is to just jump in. Start small, take baby steps, and just Google things that confuse you when you get there. Also find projects that have released their source code. See how they structure their programs. Basically, just tinker with concepts. There is plenty of information around the web.
Make it fun and grab a C++ game development book so it doesn't become mind numbing too quickly.
Here's some places that I found useful while learning
http://www.cprogramming.com/
http://www.wikipedia.com
http://www.cplusplus.com/
If you already know Java/C# I'd recommend going directly to C instead of C++. According to the website, GLUT has the same bindings for C as C++ so you should be all set. Anyways, the best way to learn C is to purchase and read a copy of "The C Programming Language" and sit down with your C compiler and get your stuff to run.
Effective C++ by Scott Meyers is a great book to help you learn C++. Gives you an overview of the language and introduces a lot of key concepts that you will use throughout the development of basically any C++ program.
Effective C++ by Scott Meyers is a great book to help you learn C++. Gives you an overview of the language and introduces a lot of key concepts that you will use throughout the development of basically any C++ program.
I love this book in all 3 editions, and it was one of the books in a class I had as a Senior at UT, but it's just not a starting book. You can become comfortable in C++ with a lot less, though you certainly won't be one with the compiler until you have read Meyer's work.
I don't know if it's still in print but I found Navigating C++ usefull, but I was also very comfortable with pointers from Pascal. Err of course I am forgetting that 15 years ago you had to learn what OOP was, now it's a little more assumed. So perhaps Meyer's is not out of line. Thoughts?
Wikipedia has an article on comparisons between Java and C++.
You don't have to worry about checked exceptions in C++, but you do need to know about const correctness.
There are two main differences: the syntax, and memory management.
In C++ you have pointers, which are more powerful (or less powerful depending on your interpretation of power) object references, which you already know about from Java.
In Java you might do this:
Thing mything = new Thing(); // mything is an object reference
mything.method();
In C++ you would do this:
Thing * mything = new Thing(); // mything is an object pointer
mything->method();
delete mything;
The syntactical difference is obvious: '->' instead of '.' when calling an object method from a pointer to an object. In C++, you have to free the memory explicitly when you are done with an object. At the end of the day you are doing the same thing in C++ and Java, instantiating objects and calling methods, putting useless semicolons at the end of every line, etc. Is it any wonder that Python is becoming so popular?:
mything = Thing() # mything is whatever I want it to be
mything.method()
Skimming through any half decent C++ text will help you fill in the rest of the details.
I also thoroughly recommend Bruce Eckel's Thinking in C++. A fantastic book for already experienced programmers that want to get into the C++ mindset.
He is kind enough to make electronic versions of his books available for free.
I strongly recommend that anyone learning C++ reads Stroustrups "The C++ Programming Language." Meyers and Eckel have great stuff, but nothing beats learning from the guy who decided what the language should be and how he intended for it to be used.
I had the exact same issue. The only book I was able to find was "Pro Visual C++ 2005 for C# Developers" by Dean C. Wills. It's a good read with excellent examples, and I think the angle from which the book comes is probably what you're looking for.
You will need a completely differnt feeling for memory handling. Also think about freeing everything you don't need anymore. In Java and C# you just let go of your objects and the memory gets tidy up for you - you can't do that in CPP