Listening to a podcast, I heard that C# is not dynamic language while Ruby is.
What is a "dynamic language"? Does the existence of dynamic languages imply that there are static languages?
Why is C# a dynamic language and what other languages are dynamic? If C# is not dynamic, why is Microsoft pushing it strongly to the market?
As well why most of .NET programmers are going crazy over it and leaving other languages and moving to C#?
Why is Ruby "the language of the future"?
What is a dynamic language?
Whether or not a language is dynamic typically refers to the type of binding the compiler does: static or late binding.
Static binding simply means that the method (or method hierarchy for virtual methods) is bound at compile time. There may be a virtual dispatch involved at runtime but the method token is bound at compile time. If a suitable method does not exist at compile time you will receive an error.
Dynamic languages are the opposite. They do their work at runtime. They do little or no checking for the existence of methods at compile time but instead do it all at runtime.
Why is C# not a dynamic language?
C#, prior to 4.0, is a statically bound language and hence is not a dynamic language.
Why is Ruby the language of the future?
This question is based on a false premise, namely that there does exist one language that is the future of programming. There isn't such a language today because no single language is the best at doing all the different types of programming that need to be done.
For instance Ruby is a great language for a lot of different applications: web development is a popular one. I would not however write an operating system in it.
In a dynamic language, you can do this:
var something = 1;
something = "Foo";
something = {"Something", 5.5};
In other words, the type is not static. In a statically typed language, this would result in a compiler error.
Languages such as C, C++, C#, and Java are statically typed.
Languages such as Ruby, Python, and Javascript are dynamically typed.
Also, this is not the same as "strongly or weakly" typed. That is something different all together.
I'm stunning at the way c# it's embracing a fundamental set
of programming paradigms.
We can say that c# alows a rich object oriented programming,
a rich component oriented programming,
a well integrated functional programing,
a complet set of query operations over differents types of data sources (linq),
a elegant aproach of cocurrent programming through pLinq and parallel extensions,
in the next release (c# 4.0) will have powerfull dynamic capabilities,
and it's almost sure that in c# 5.0 will have a solid set of meta-programming
features.
With just can say that c# it's doing a great job of integrating all this powerfull
stuff in just one tool box. That's in my opinion it's the way it must be,
because skipping from one programming language to another it's almost always very painfull.
C# is a statically typed language, because the type of every object you're working with needs to be known at compile time. In a dynamic language you don't need to know what type an object is at compile time. Maybe you import some classes that you don't know before hand, like you import all classes in a folder, like plugins or something. Or maybe even the type of an object depends on user-interaction.
You can achieve a similar effect by using interfaces or base classes, but it's not completely the same because you are limited to using classes that explicitly inherit from or implement that interface.
In dynamically typed languages it doesn't care what the type is when you compile it, it'll try to call the method you specified by name, if that method doesn't exist on the object it'll throw a run-time exception, so it's up to the programmer to ensure that that doesn't happen or handle it appropriately. You gain flexibility, but lose out a little on compile-time error checking.
Looking at the Wikipedia entry, we see that a dynamic language is one that does things are runtime that most do at compile time. Typically, in a dynamic language, a variable could change types quickly and easily, and there typically is no separate compile step (but rather either interpreted execution or really fast compiling). C# is a more conventional language, using variable declarations and being compiled.
The Wikipedia entry lists numerous dynamic languages.
"X is the Y of the future", on the other hand, means that somebody's trying to sell you something. (Not necessarily literally, but trying to influence your beliefs in a way convenient to the speaker.)
Did you know that VB6 is both static and dynamic?
If you declare variables with a given type, then you get static behaviour:
Dim name as Label
You can now only access members of name that are Labels and intellisense knows that.
If you have a class and add the implements keyword, then your class can implement methods of another class. This is inheritance of interface that VB6 allows. You can get some runtime polymorphism.
You can also declare variables like this:
Dim proxy As Object
Now intellisense doesn't give you any help and VB6 will allow you to do anything you like with proxy:
proxy.foo()
This line can sit inside a compiled and running program and cause no offence, especially if its not run itself. Its only when the line is run does the lookup take place.
You can also perform:
set proxy = <any instance>
and this will run. It doesn't matter whether <any instance> has a foo method or not.
And then any instance of any class that does implement foo can be assigned and the method called and VB6 will be happy.
Note that there are run-time performance penalties as you become increasingly dynamic.
In C# 3.0, the types of everything needs to be known at compile-time. It's a static language. A dynamic language uses dynamic dispatch at runtime to decide the type of things and what methods to call on those things. Both types of languages have their advantages and disadvantages. C# 4.0 will add dynamic capability. Anders Hejlsberg gave a great talk on static v.s. dynamic languages and C# 4.0 at PDC.
A dynamic language is generally considered to be one that can dynamically interpret & generate code at runtime. C# can't do that.
There are also dynamically typed & statically typed languages. Dynamically typed means that the type of a variable is not set and can change throughout the program execution.
The words static and dynamic are not cleary defined.
However, what is most often meant is two issues:
1) In static languages, the type of a variable (that is, the type of value the variable can contain or point to) cannot change during the course of a program. For example in C#, you declare the type of a variable when you define it, like:
int a;
Now a can only ever hold an int value - if you try to assign a string to it, or call a method on it, you will get a compile type error.
2) In static language the type of an object cannot change. In dynamic languages, an object can change in that you can attach or remove methods and properties, thereby basically turning it into a completely different object.
c# is statically typed, ie int i =0; try setting i to be a string. the compiler will complain,
where as python a variable that used to hold an integer can then be set to hold a string,
Static: Types are final,
Dynamic: Types can be changed,
c# is trying to add more dynamic like features, var for instance
There is no true "language of the future".
Different languages have different purposes.
At most, you could say Ruby is a language of the future.
According to Wikipedia:
Dynamic programming language is a term
used broadly in computer science to
describe a class of high-level
programming languages that execute at
runtime many common behaviors that
other languages might perform during
compilation, if at all. These
behaviors could include extension of
the program, by adding new code, by
extending objects and definitions, or
by modifying the type system, all
during program execution. These
behaviors can be emulated in nearly
any language of sufficient complexity,
but dynamic languages provide direct
tools to make use of them.
Most dynamic languages are dynamically typed, but not all.
Ruby is a dynamic language and C# is not, since Ruby is interpreted and C# is compiled. However, C# does include some features that make it appear dynamic.
A language is dynamically typed, that means a variable in that can be used for anything.
Variables are not typed, values are. A variable can have the value of any primitive type, or it can reference to any object.
Related
According to this article:
it is important to remember that C# is a statically typed language; which leaves no room for variant types
Which seems correct... However doesn't the Dynamic data type break that rule? Maybe I am missing some subtle difference that I am unaware of but a Dynamic data type seems like a real Variant (Like JavaScript or VBA) to me?
Under the covers dynamic is compiled to System.Object and the compiler writes patterns that are strongly typed, and do much of the work of the dispatch at runtime. Hence, C# (truly the CLR) is still strongly typed, but with some asterisks.
var here in C# is all about type inference and thats what that article is discussing.
When I use resharper tool, it just says "use built-in type "string" rather than using "String". Similarly, it converts UInt32 to just uint.
I have googled this and all I can find is they are aliases. Aliases meaning "Duplicates". Ok.
But, what exactly do they mean about it ?
When both are same, why the tool suggests using "string" and "uint" for "String" and "UInt32" ?
Also, what is the difference between dot-net types and C# types.
Have googled it but couldnt find any satisfying answers.
Thanks.
The answer given by Rafal sums it up, but there are a couple of clarifications I'd like to make: the only case when using keywords rather than type names is necessary is when defining an enum's underlying type -- In that case, using the latter would not be allowed.
Example:
enum Foo : Int32
{
}
The above won't compile.
Also, while I generally prefer to use keywords, it must be said that while the types are the same for every language running on the .NET Framework, the keywords are different. For example, while in C# long is an alias for Int64, in C++/CLI, long is actually an Int32. That can create some confusion when, for instance, porting code between CLI languages.
String and string are same and so are the UInt32 and uint.
This just due to CLS-compliance, so that you could write C# class library and use in VB program and vice versa.
Some excerpts from MSDN:
To fully interact with other objects regardless of the language they were implemented in, objects must expose to callers only those features that are common to all the languages they must interoperate with. For this reason, the Common Language Specification (CLS), which is a set of basic language features needed by many applications, has been defined. The CLS rules define a subset of the Common Type System; that is, all the rules that apply to the common type system apply to the CLS, except where stricter rules are defined in the CLS. The CLS helps enhance and ensure language interoperability by defining a set of features that developers can rely on to be available in a wide variety of languages.
Please refer Common Language Specification
There is no difference between String and string because as you have pointed out those are aliases - alias is just a different name for the same thing.
As to why Resharper does something you should ask or seek on resharper dedicated site. In my opinion it is merely question of convention - you should use one of those and why not use the one that majority uses.
Recently I have been exploring using the fancy new dynamic keyword introduced in C# 4.0 (DynamicObject, ExpandoObject etc..)
Now I can identify several uses (and several pitfalls) for the new introduction, but for the purpose of my project, and for this question - I am looking into cleaning up my late-bound string-based indexed collections to make them more safe.
So, before dynamics I had:
Car car1 = CARWarehouse1["Honda"];
And WITH dynamics I can now do (where CARWarehouse1 now extends the DynamicObjects base)
Car car1 = CARWarehouse1.Honda
This is all well and good, and from a quick glance it looks like I have achieved what I wanted.. but have I?
Because lets face it, for either method at compile time should I have mistyped my referenced car type, the compiler won't have a problem, but I will run into issues at runtime.
Therefore, what I really need is compile time property checking, and Intellisense support. So - can I do it?
I know that there are libraries out there such as Moq that have this capability, and Resharper gives some sort of support within intellisense, but I'm looking for a more rounded solution.
Any ideas, big, small, easy or complex are welcome.
Nope, no such thing for dynamic types.
Basically the compiler just skips all checks on variables marked as dynamic because there is no way to check anything. Properties on dynamic objects may be created at runtime, so the code can't be checked at compile time for accuracy.
If compile time checks and intellisense are important, don't use dynamic. If the scope of the object is pretty small you could use anonymous types instead, but I don't get the impression that's applicable to your situation. I'd suggest you just define the types you need, and stick with dictionaries and hashtables for any properties that you can't predict when coding.
I know that in C# 3.0 you can do some functional programming magic with Linq and lambda expression and all that stuff. However, is it really possible to go completely "pure" functional in C#? By "pure" I mean having methods that are pure (always gives the same output for the same input) and completely free of side-effects. How do we get around the fact that we do not even have immutable integer type in C#?
If you want to program in a pure functional way, there is nothing stopping you.
On the other hand, if you have some program, there is no magic flag you can flip to force the program to behave in a pure functional way.
For ints (immutable)
If you use an int as a parameter, it is passed by value. Any changes are not propogated to the caller.
If you use an int declared in one method's scope in a closure within the method, than that int variable is shared. In this case, one must either pledge not to modify the int (programmer enforced), or simply not use an int in this way.
And if you truly need an immutable int, have you seen the readonly keyword?
Have you looked into F#? It seems much more along the lines of what you are talking about. C# just really isn't designed with functional programming in mind, and therefore won't really give you any of the benefits that are normally associated with a functional language.
Unfortunately no - C# is not a pure functional language and it does not intend to be. What has happened is that the C# team has seen that there are benefits to adding certain functionally-styled constructs and syntax to the language.
Functional purity is better found in other places (Lisp derivatives like Common Lisp and Scheme are good places to start).
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 just want to clarify one thing. This is not a question on which one is better, that part I leave to someone else to discuss. I don't care about it.
I've been asked this question on my job interview and I thought it might be useful to learn a bit more.
These are the ones I could come up with:
Java is "platform independent". Well nowadays you could say there is the Mono project so C# could be considered too but
I believe it is a bit exaggerating. Why? Well, when a new release of Java is done it is simultaneously available on all platforms it supports, on the other hand how many features of C# 3.0 are still missing in the Mono implementation? Or is it really CLR vs. JRE that we should compare here?
Java doesn't support events and delegates. As far as I know.
In Java all methods are virtual
Development tools: I believe there isn't such a tool yet as Visual Studio. Especially if you've worked with team editions you'll know what I mean.
Please add others you think are relevant.
Update:
Just popped up my mind, Java doesn't have something like custom attributes on classes, methods etc. Or does it?
Comparing Java 7 and C# 3
(Some features of Java 7 aren't mentioned here, but the using statement advantage of all versions of C# over Java 1-6 has been removed.)
Not all of your summary is correct:
In Java methods are virtual by default but you can make them final. (In C# they're sealed by default, but you can make them virtual.)
There are plenty of IDEs for Java, both free (e.g. Eclipse, Netbeans) and commercial (e.g. IntelliJ IDEA)
Beyond that (and what's in your summary already):
Generics are completely different between the two; Java generics are just a compile-time "trick" (but a useful one at that). In C# and .NET generics are maintained at execution time too, and work for value types as well as reference types, keeping the appropriate efficiency (e.g. a List<byte> as a byte[] backing it, rather than an array of boxed bytes.)
C# doesn't have checked exceptions
Java doesn't allow the creation of user-defined value types
Java doesn't have operator and conversion overloading
Java doesn't have iterator blocks for simple implemetation of iterators
Java doesn't have anything like LINQ
Partly due to not having delegates, Java doesn't have anything quite like anonymous methods and lambda expressions. Anonymous inner classes usually fill these roles, but clunkily.
Java doesn't have expression trees
C# doesn't have anonymous inner classes
C# doesn't have Java's inner classes at all, in fact - all nested classes in C# are like Java's static nested classes
Java doesn't have static classes (which don't have any instance constructors, and can't be used for variables, parameters etc)
Java doesn't have any equivalent to the C# 3.0 anonymous types
Java doesn't have implicitly typed local variables
Java doesn't have extension methods
Java doesn't have object and collection initializer expressions
The access modifiers are somewhat different - in Java there's (currently) no direct equivalent of an assembly, so no idea of "internal" visibility; in C# there's no equivalent to the "default" visibility in Java which takes account of namespace (and inheritance)
The order of initialization in Java and C# is subtly different (C# executes variable initializers before the chained call to the base type's constructor)
Java doesn't have properties as part of the language; they're a convention of get/set/is methods
Java doesn't have the equivalent of "unsafe" code
Interop is easier in C# (and .NET in general) than Java's JNI
Java and C# have somewhat different ideas of enums. Java's are much more object-oriented.
Java has no preprocessor directives (#define, #if etc in C#).
Java has no equivalent of C#'s ref and out for passing parameters by reference
Java has no equivalent of partial types
C# interfaces cannot declare fields
Java has no unsigned integer types
Java has no language support for a decimal type. (java.math.BigDecimal provides something like System.Decimal - with differences - but there's no language support)
Java has no equivalent of nullable value types
Boxing in Java uses predefined (but "normal") reference types with particular operations on them. Boxing in C# and .NET is a more transparent affair, with a reference type being created for boxing by the CLR for any value type.
This is not exhaustive, but it covers everything I can think of off-hand.
The following is a great in depth reference by Dare Obasanjo on the differences between C# and Java. I always find myself referring to this article when switching between the two.
http://www.25hoursaday.com/CsharpVsJava.html
C# has automatic properties which are incredibly convenient and they also help to keep your code cleaner, at least when you don't have custom logic in your getters and setters.
Features of C# Absent in Java
• C# includes more primitive types and the functionality to catch arithmetic exceptions.
• Includes a large number of notational conveniences over Java, many of which, such as operator overloading and user-defined casts, are already familiar to the large community of C++ programmers.
• Event handling is a "first class citizen"—it is part of the language itself.
• Allows the definition of "structs", which are similar to classes but may be allocated on the stack (unlike instances of classes in C# and Java).
• C# implements properties as part of the language syntax.
• C# allows switch statements to operate on strings.
• C# allows anonymous methods providing closure functionality.
• C# allows iterator that employs co-routines via a functional-style yield keyword.
• C# has support for output parameters, aiding in the return of multiple values, a feature shared by C++ and SQL.
• C# has the ability to alias namespaces.
• C# has "Explicit Member Implementation" which allows a class to specifically implement methods of an interface, separate from its own class methods. This allows it also to implement two different interfaces which happen to have a method of the same name. The methods of an interface do not need to be public; they can be made to be accessible only via that interface.
• C# provides integration with COM.
• Following the example of C and C++, C# allows call by reference for primitive and reference types.
Features of Java Absent in C#
• Java's strictfp keyword guarantees that the result of floating point operations remain the same across platforms.
• Java supports checked exceptions for better enforcement of error trapping and handling.
Another good resource is http://www.javacamp.org/javavscsharp/
This site enumerates many examples that ilustrate almost all the differences between these two programming languages.
About the Attributes, Java has Annotations, that work almost the same way.
Generics:
With Java generics, you don't actually get any of the execution efficiency that you get with .NET because when you compile a generic class in Java, the compiler takes away the type parameter and substitutes Object everywhere. For instance if you have a Foo<T> class the java compiler generates Byte Code as if it was Foo<Object>. This means casting and also boxing/unboxing will have to be done in the "background".
I've been playing with Java/C# for a while now and, in my opinion, the major difference at the language level are, as you pointed, delegates.
Please go through the link given below
msdn.microsoft.com/en-us/library/ms836794.aspx
It covers both the similarity and difference between C# and java