The Lounge - CodeProject

I'm reading a C# book that was recommended on here recently and found this gem in the beginning.

Quote:
The truth of the matter is that many of C#’s syntactic constructs are modeled after various aspects of Visual Basic (VB) and C++.

TROELSEN, ANDREW; Japikse, Philip. C# 6.0 and the .NET 4.6 Framework (Kindle Locations 3123-3124). Apress. Kindle Edition.

$Shucks | :-\$

There are two kinds of people in the world: those who can extrapolate from incomplete data.

There are only 10 types of people in the world, those who understand binary and those who don't.

Funny, C# was modeled mostly after Java and C++, but no one ever mentions the Java part.

modified 2-Aug-17 11:01am.

Citation?

I always wanted to do that once. I used to be too trusting and took everybody's word for everything. Smile | :)

I do remember hearing about the C++ part, but was copying Java not the typical accusation from the Javaites, used to dismiss C# as cheap imitation?

Visual J++ - Wikipedia

Quote:
Microsoft later developed the C# ("C Sharp") language as the primary language for the .NET platform, which was in many ways influenced by Java; subsequently the .NET Framework shares many ideas in common with Java. Much like Java, C# is compiled to a type of bytecode (called CIL), and runs on top of a virtual machine called the Common Language Runtime in .NET. Visual Studio 2005 was the last release to include J#.

Now is it bad enough that you let somebody else kick your butts without you trying to do it to each other? Now if we're all talking about the same man, and I think we are... it appears he's got a rather growing collection of our bikes.

modified 31-Aug-21 21:01pm.

Sure, but even C# 1.0 took some things further than Java did at that time.

I agree, there was good (and new) stuff from the start - it was kind of like an improved C++/Java language from day one and has evolved from their ever since.

J++ had some improvements over Java too, it was just a really poor choice of name that put off both Java and C++ developers from the start.

Now is it bad enough that you let somebody else kick your butts without you trying to do it to each other? Now if we're all talking about the same man, and I think we are... it appears he's got a rather growing collection of our bikes.

modified 31-Aug-21 21:01pm.

The improvements on J++ were the reason for abandoning J++. Did they not put Microsoft before the choice of removing them or else losing the license for J++?

It looks like it was more of a legal thing with Sun.. from 2002, Sun, Microsoft settle Java suit - CNET

Quote:
A Microsoft representative said the dispute lingered for too long. "We don't think anyone wins, but considering the lawsuit has been ongoing for three years, this is a good conclusion to this controversy," said Microsoft spokesman Jim Cullinan.

With the deal struck, Cullinan said Microsoft will be allowed to continue to offer its existing Java products, including its popular J++ development tool, for the next seven years. Microsoft product manager Tony Goodhew said the company will include J++ as a separate CD with the next version of Visual Studio.

Now is it bad enough that you let somebody else kick your butts without you trying to do it to each other? Now if we're all talking about the same man, and I think we are... it appears he's got a rather growing collection of our bikes.

modified 31-Aug-21 21:01pm.

Brent Jenkins wrote:
It looks like it was more of a legal thing with Sun

One of the points of java was that you were supposed to be able to run it on any VM on any supported OS.

Microsoft made specific changes to their java that made it impossible to run on different VMs or even compile.

CNN - Sun alleges new Java violations by Microsoft - July 13, 1998[^]

Hey, but we've got .NET Core now Big Grin | :-D

Now is it bad enough that you let somebody else kick your butts without you trying to do it to each other? Now if we're all talking about the same man, and I think we are... it appears he's got a rather growing collection of our bikes.

modified 31-Aug-21 21:01pm.

We don't think anyone wins

Wrong - the attorneys (always) win.

Yeah, but the point is, it was based on Java. Way more than VB. I think that book author is just biased. I don't have citations, but I always heard that even MS hired some top Java guys to help with the initial design of C#.

As much as we love to hate Java, we still have it thank for what we use.

Jeremy Falcon

Anders Hejlsberg - Wikipedia - he didn't work for Sun but he worked on Microsoft's J++ language.

Quote:
In 1996, Hejlsberg left Borland and joined Microsoft. One of his first achievements was the J++ programming language and the Windows Foundation Classes; he also became a Microsoft Distinguished Engineer and Technical Fellow. Since 2000, he has been the lead architect of the team developing the C# language. In 2012 Hejlsberg announced his new project, TypeScript, a superset of JavaScript.

Now is it bad enough that you let somebody else kick your butts without you trying to do it to each other? Now if we're all talking about the same man, and I think we are... it appears he's got a rather growing collection of our bikes.

modified 31-Aug-21 21:01pm.

And this move KILLED Borland. Anders was the key behind Delphi, which I still use and enjoy.
He made Delphi and C++ Builder produce interchangeable object files (compile in one, use in the other),
which also helped him with C# and VB. Same trick.

I used to have a Quick XXX and a Turbo XXX of just about everything back in the day. $99.00 bought you a lot!

Dang I feel old...

Yep, I remember using C++ Builder back in the 1990's - it was a demo application I wrote in C++ Builder that landed me my first professional programming job (after spending about 12 years in electronics) Smile | :)

Now is it bad enough that you let somebody else kick your butts without you trying to do it to each other? Now if we're all talking about the same man, and I think we are... it appears he's got a rather growing collection of our bikes.

modified 31-Aug-21 21:01pm.

Is it worthwile to distinguish between "Based on Java" and "Based on experience with Java"?

It seems to me (own thoughts - no Wikipedia URL) that the C# designers sure made a thorough study of how Java served in practice, not just the formal language definition. Seeing how it was used, how the compiler handled it, how well the bytecode/VM idea worked in practice, made them go back to the drawing board, saying "OK, Java did it their way - some of it was successful, some of it was not. Now let us redo it in a way we believe will get at higher fraction of 'successful' elements." - Of course they did the same study of C++.

Whether you will call it "based on" or "based on experience with" may be a matter of taste, but to me, the former alternative suggests much more of "a further development of ...", which C# certainly is not from Java.

Brent Jenkins wrote:
Now is it bad enough that you let somebody else kick your butts without you trying to do it to each other? Now if we're all talking about the same man, and I think we are... it appears he's got a rather growing collection of our bikes.

Right turn Clyde.

Michael Martin
Australia

"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."
- Mr.Prakash One Fine Saturday. 24/04/2004

I must say that a statement that says "C# is compiled to a type of bytecode (called CIL)" (my emphasis) makes me somewhat sceptical to the competence of the writer. I doubt very much that (s)he has implemented very many compilers Smile | :)

Those who can, do.. those that can't, teach.. those that can't teach write Wikipedia articles Smile | :)

Now is it bad enough that you let somebody else kick your butts without you trying to do it to each other? Now if we're all talking about the same man, and I think we are... it appears he's got a rather growing collection of our bikes.

modified 31-Aug-21 21:01pm.

Can you elaborate? I have to say that I agree. Isn't the .NET CLI a type of bytecode?

I haven't been working with compilers for a number of years, so maybe there are younger species out there that do things in a different way - I know the "classical" way of doing it, believing that today's compilers are roughly the same:

First, you break the source text into tokens. Then you try to identify structures in the sequence of tokens so that you can form a tree of hiearchical groups representing e.g. functions at some intermediate level, statements at a lower level, terms of a mathematical expression even further down. The term DAG - Directed Acyclic Graph - is commonly used for the parse tree. Nodes in the DAG commonly consist of 3-tuples or 4-tuples in a more or less common format for all nodes: Some semantic / operation code, two or three operands, or whatever else the compiler writer finds necessary.

Many kinds of optimisation is done by restructuring the DAG: Recognizing identical sub-trees (e.g. common subexpressions) that need to be done only once, identifying statements that within a loop will have identical effect in every iteration so that sub-tree can be moved out of the loop, etc. etc. Unreachable code is pruned off the DAG. All such operations are done on an abstract level - a variable X is treated as X without regard to its location in memory, number of bits (unless the language makes special requirements) etc. etc. The DAG is completely independent of the word length, byte ordering, 1- or 2-complement arithmetic, register ID or field structure of the instruction code of any specific machine architecture. You may think of variables and locations as sort of still in a "symbolic" form (lots of symbolic labels where never visible in the source code, so this certainly is "sort of").

Once you have done all the restructuring of the DAG that you care for, you may traverse the tree's leaf node to generate the actual machine instructions. (This part of the compiler is commonly called the "back end".) Now you assign memory addresses, use of registers, choose the fastest sequence of machine instructions for that specific machine. You can still do some optimization, e.g. keeping values in registers (now that you know which registers you've got), but it is essentially very local. The DAG indicates which sub-trees are semantically independent of each other, so that you may reorder them, run them in parallell, or e.g. assemble six independent multiplication operations into one vector multiply if your CPU allows. All internal symbolic rerferences can be peeled off; the only symbols retained are external entry points and references to external modules.

The back end may produce machine instructions for a hypthetical CPU that does not exist in silicon. Yet it has (or may have) its registers, word length, binary address space etc. There could be a machine having this instruction set as its native one. Many years ago, someone wrote an alternative microcode for a PDP-11 architecture so that it could execute the P4 bytecodes directly - but it was dead slow! Usually, you make a software virtual machine that pretends to be a "real" CPU for those instructions, interpreting the bytecodes one by one. JVM is such a virtual machine. For many years, this was The Way to run Java.

Compilers for dotNET essentially has no backend - they do not generate anything ready for execution. Essentially, their output is a linearization of the DAG, i.e. the abstract 4-tuple DAG nodes. The compiler backend is in the dotNET implementation: When a module is requested for the first time, the dotNET backend will do the last stages of compilation, creating machine specific binary code in the native instruction set of that specific machine, assigning specific locations to the named variables etc. The compiled result is stored in a cache, so that next time the same code is requested, no new compilation is required.

So, while Java bytecode is meant to be complete, ready to run, code (symbolic linking to other modules may still be required, but that is not code generation), dotNET assemblies are only half baked, requiring a final compilation step. This takes a little bit of time (it is surprisingly little!), but the generated code is native, requiring no interpretation.

Java compilers can generate binary code, rather than bytecode, but then it is for a specific machine. Or, the JVM may look at a (sequence of) bytecode(s) at run time, translate it to native instructions, but that is like interpreting Motorola 68000 instructions on a 386 (Apple did that when they switced to 386, to run old binary software!), but you will always be bound by the limitiations of the bytecode instruction set.

To a plain user with limited computer knowledge, there is little "visible" difference between the way JVM and dotNET works, but at the internal level, the architectures are signifiantly different.

That was a lovely, clear and comprehensive elaboration. Thank you (assuming of course, that it is correct!).

All correct, but are you disagreeing with 'C# is compiled to a type of bytecode'?

My immediate reaction: Yes, I would disagree. Bytecodes are ready for execution, while the dotNET output from a C# compiler is not.

You could say that I am using a "narrow" defintion of the term, but the term could have a more general meaning. Yes, it could - it could mean any code representation that is built up of bytes. Like source code Smile | :)

. We could even generalize the "byte" concept: The old Univac mainframes could work with 9 bit bytes (4 to the word) or 6 bit bytes (6 to the word), while DEC-10 and DEC-20 had 7-bit bytes (5 to the word and one spare bit).

But that is not the commmon "compiler guy" interpretation of "bytecode". The linearized DAG is not directly executable, like a bytecode. Obviously, you could, at run time, do a just-in-time compilation into a bytecode for an interpreter, rather than compiling into native binary code. But at least as far as I know, there are no virtual machines directly interpreting dotNET assemblies with no pre-execution processing step.

In my student days, we were a group of students making an attempt to build a direct interpreter for the intermedidate language from another front end compiler (for the CHILL programming language), having a similar architecture. We soon realized that the data structures required to maintain the current exeuction state would be immensly large and complex; the task of building the interpreter would far exceed making a complete backend compiler. You couldn't do without a unified symbol table. You couldn't do without a label-to-location mapping. You couldn't do without a lot of state information for various objects. You couldn't do without ... So we never completed the project. (It was a hobby project, not a course assignment.)

Nah, op-codes are ready for execution, bytecodes are not. I like this definition: Bytecode is a form of hardware-independent machine language that is executed by an interpreter. It can also be compiled into machine code for the target platform for better performance.

Welcome to the Lounge