Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Whenever I see programs or scripts that convert between high-level programming languages they are always labelled as converters.

"VB.NET to C# converter" on Google results in expected, useful hits.

However "VB.NET to C# compiler" on Google results in things like comparisons between the C# and VB.NET compilers and other hits that are not quite what you'd be looking for.

Webopedia defines Compiler as

A program that translates source code into object code

Eric Lipper in an answer to: "How do I create my own programming language and a compiler for it" suggests:

One of the best ways to get started writing a compiler is by writing a high-level-language-to-high-level-language compiler.

Is a VB.NET to C# converter really just a compiler? If not, What separates the converter from also being a compiler?

share|improve this question
1  
    
Answer: yes. A compiler takes one language and rewrites it in another. Anything that does that qualifies, no matter whether it is common to call it a compiler. –  btilly Oct 28 '13 at 7:30
2  
No. VB.NET to C# converters are just that... converters. They mostly transform syntax. There's no guarantee that the resulting code will compile; I've seen them fail more often than not to provide an accurate translation, depending on the complexity of the code. If they were true compilers, that wouldn't happen. There are several steps in the compilation process that these converters don't do. –  Robert Harvey Oct 28 '13 at 19:47
add comment

3 Answers

up vote 2 down vote accepted

Depending on how you look at it, maybe the difference between a "converter" and a "compiler" kind of comes down to the objectives involved in one versus the other.

Do a "converter" and a "compiler" both perform lexical analysis and convert one flavor of code into another? Sure they do. But with totally different objectives.

You're going to use a "converter" to transform source code from one portable high-level language syntax to another portable high-level language syntax, so that you can maintain your source code in a different language, right?

The goal is that you end up with your source code base in C# instead of VB.NET. Maybe you just don't like VB.NET syntax, maybe all of your other source code is in C# and you want a uniform code base, maybe you have some VB.NET code which is perfectly fine except that you want to have your product run on mono. Maybe all sorts of things. Actually, it looks like there is a VB compiler in the works for Mono. Why, I really can't imagine. VB was great back in the day. R.I.P., VB.

So the work result of a converter, in the context we seem to be talking about, is maintainable, portable high-level source code that you'll put into your source code repository and make your team embrace, extend and maintain.

On the other hand, the work result of a compiler is executable, probably optimized and almost certainly non-maintainable and non-portable code that targets a specific CPU. The work result of a compiler is executable code.

Granted, I'm conflating the concepts of compilers and linkers here. But so did at least one of the commenters who referred to the C#/VB.NET compilers producing IL, which then needs to be "compiled" into executable code. :-)

.NET has a sort of fancy extra layer, where the "compiler" transforms your C# or VB (or F# or Eiffel or JScript or managed C++ or...) code into an IL assembly (an .exe or .dll file), and then when you "run" that code, the .NET JIT (Just-In-Time compiler) intervenes, magically and transparently converting your IL into native non-portable code for whatever CPU it finds itself running on. Or you can use ngen to convert your IL assembly into a native image for a particular CPU ahead of time (though the benefits may not be as dramatic as you hope).

So, via whatever circuitous route, the work product that is ultimately squirted out by a VB.NET to C# converter will be to take a source code file containing something like:

Dim i As Integer
For i = 1 To 100
   ' do something
Next

And convert it to something like this:

for( int i = 1; i <= 100; i++ )
    {
    // do something
    }

You'll store that resulting C# source code in your source code repository and use a compiler to turn that into executable code for distribution to your customer. And you get to program in C# instead of VB.

Note, by the way, some of the subtle difference in instinctive thinking that accompanies VB programming versus C# (C/C++) programming, where that loop iteration started at 1 instead of zero.

IL is really just a sort of CPU-agnostic assembly language. Unless you have some esoteric low-level, system-programmer reason to be maintaining code in IL, you just aren't ever going to be storing the stuff in your source code repository. Other times you might fiddle with IL are when you're actually a language programmer on the Microsoft .NET team or the Mono team or some other language team that makes a .NET compiler for a specific language (FORTRAN or COBOL, anyone?), or you are deep into debugging some weird edge case and use a disassembler on your own code, or you're trying to resolve a technical argument with another developer on your team who you know is crazily wrong about something (never happens, right?), or you're inspecting somebody else's IL assembly to try to figure out how it works or whether it is safe to call it in a certain way.

That isn't so different from the uses of traditional CPU-specific assembly language (or assembler for discrete systems like the old mainframes and mini's before there really were all-in-one silicon CPU's). "High level" languages like LISP, COBOL, FORTRAN and C (which was originally billed as a sort of portable assembly language) were developed to make code easier for mere humans to grasp, and to make it possible to compile the same code to run on more than one type of computer. So a C compiler takes "high-level" C source code and turns it into assembly language for whatever CPU you're compiling for, and then you use a linker (which is usually automatically invoked by your compiler) to further transform that into actual binary code that you can shove straight through the CPU. But the compiler results aren't the thing that you keep around as "source" code, right?

Well, I do remember a case years ago where a team of developers had a set of "magic *.obj files" that they had to link against because the original source code had been lost somehow. But I digress...

It is entirely reasonable to assume that some .NET converters might actually work by "compiling" code into IL, then "decompiling" the resulting IL back into another language. At least a few of the IL disassemblers floating around do essentially that (including .NET Reflector and ILSpy). But the objective is still different from what a "compiler" does, right?

So I contend that a converter is not really just a compiler by another name.

share|improve this answer
    
Wouldn't converter in this case technically be called a transpiler? –  jhewlett Nov 4 '13 at 2:51
    
Yeah, I guess it is. Nice catch :-) en.wikipedia.org/wiki/Source-to-source_compiler –  Craig Nov 4 '13 at 17:17
    
And the WikiPedia article states what I was trying to convey about the level of abstraction being the differentiater. VB.NET and C# are at the same level of abstraction. That's just a conversion (though a type of compiler is used to accomplish it). VB.NET or C# and IL or assembler are at totally different levels of abstraction, and changing one into the other is what is more traditionally thought of as a compiler's job. I think that's what I was trying to express. :-) –  Craig Nov 4 '13 at 17:20
    
Although; isn't there still a distinction to made with respect to the quality and use of the translation? Take Hip Hop and Objective-C as examples. Those are clearly transpilers. But the bar is very high. They are used in automated build processes and can absolutely be relied upon to take, for example, PHP code to C++ that is totally buildable using a stock C++ compiler, right? Same story with Objective-C. Can the same be said about most of these VB.NET to C# types of converters? I still think it kind of goes to the purpose of the tool. –  Craig Nov 4 '13 at 18:17
    
Yes, I would agree that something that is not guaranteed to produce correct output is better labeled as a converter. I can't speak to the quality of any VB.NET to C# tools. –  jhewlett Nov 5 '13 at 0:51
add comment

According to Wikipedia,

A compiler is a computer program (or set of programs) that transforms source code written in a programming language (the source language) into another computer language

It doesn't say that a high-level language should be transformed into a low-level language. So yes, a converter which transforms code written in VB.NET to C# would be a compiler, as well as a converter from C# to Java or from Python to Ruby or Haskell to Lisp (if such converters exist).

What differentiates the term compiler from the term converter ? Nothing technical, I think. Since in current language, compiler often wrongly refers to a program which transforms source code into machine code, converter  may refer to a compiler which:

  • produces source code and not machine code,
  • source code written in higher-level languages compared to Assembler or even C,
  • source code written in an equally high-level language compared to the original language (Java vs. C#, for example).

Side note: a commonly made mistake is to call LESS to CSS or Sass to CSS compilers. They are preprocessors, not compilers, since they don't take source code written in a programming language as an input.

share|improve this answer
2  
While I agree with this answer to a certain point, there is something important to point out, most C# to VB.NET ( or vice versa ) converters simply convert the syntax of the code supplied. I would argue they are also preprocessors since the code that is generated still has to be compiled by the CSS ( or VB.NET equivalent compiler. –  Ramhound Oct 28 '13 at 16:18
    
@Ramhound good point, but CSC/VBC produces IL which then needs to be compiled to machine executable instructions... –  Steve Evers Oct 28 '13 at 20:01
    
@SteveEvers - Glade you knew what I meant by the CSS I did indeed mean CSC –  Ramhound Oct 29 '13 at 10:59
    
For that matter, the Objective-C "compiler" is really also a pre-processor, which takes the Objective-C syntax and turns it into C/C++ syntax, then feeds that through the gcc compiler. –  Craig Nov 3 '13 at 18:49
add comment

It would be possible to write a C#/VB compiler, but to the best of my knowledge (which admittedly is not all that extensive) currently what exists are converters.

So, the question is: what is the difference between a compiler and a converter? The answer to that is simple: A compiler either suceeds or it fails, a converter on the other hand is producing something which is expected to have more human input before it is complete, as such it should almost always produce something, even if the result is incomplete and unworkable.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.