I currently use Python for most of my programming projects (mainly rapid development of small programs and prototypes). I'd like to invest time in learning a language that gives me the flexibility to use various Microsoft tools and APIs whenever the opportunity arises. I'm trying to decide between IronPython and C#. Since Python is my favorite programming language (mainly because of its conciseness and clean syntax), IronPython sounds like the ideal option. Yet after reading about it a little bit I have several questions.
For those of you who have used IronPython, does it ever become unclear where classic Python ends and .NET begins? For example, there appears to be significant overlap in functionality between the .NET libraries and the Python standard library, so when I need to do string operations or parse XML, I'm unclear which library I'm supposed to use. Also, I'm unclear when I'm supposed to use Python versus .NET data types in my code. For example, which of the following would I be using in my code?
d = {}
or
d = System.Collections.Hashtable()
(By the way, it seems that if I do a lot of things like the latter I might lose some of the conciseness, which is why I favor Python in the first place.)
Another issue is that a number of Microsoft's developer tools, such as .NET CF and Xbox XNA, are not available in IronPython. Are there more situations where IronPython wouldn't give me the full reach of C#?
I've built a large-scale application in IronPython bound with C#.
It's almost completely seamless. The only things missing in IronPython from the true "python" feel are the C-based libraries (gotta use .NET for those) and IDLE.
The language interacts with other .NET languages like a dream... Specifically if you embed the interpreter and bind variables by reference.
By the way, a hash in IronPython is declared:
d = {}
Just be aware that it's actually an IronPython.Dict object, and not a C# dictionary. That said, the conversions often work invisibly if you pass it to a .NET class, and if you need to convert explicitly, there are built-ins that do it just fine.
All in all, an awesome language to use with .NET, if you have reason to.
Just a word of advice: Avoid the Visual Studio IronPython IDE like the plague. I found the automatic line completions screwed up on indentation, between spaces and tabs. Now -that- is a difficult-to-trace bug inserted into code.
I'd suggest taking a look at Boo [http://boo.codehaus.org/], a .NET-based language with a syntax inspired by Python, but which provides the full range of .NET 3.5 functionality.
IronPython is great for using .NET-centric libraries -- but it isn't well-suited to creating them due to underlying differences in how the languages do typing. As Boo does inference-based typing at compile time except where duck typing is explicitly requested (or a specific type is given by the user), it lets you build .NET-centric libraries easily usable from C# (and other languages') code, which IronPython isn't suitable for; also, as it has to do less introspection at runtime, Boo compiles to faster code.
Related
F# has recently caught my eye as something I'd like to learn more about, but I have never used the .NET platform and know very little about it. If I want to write a small website in .NET core can I do that with only F# or will I need to expand my learnings to include C#?
You can definitely use .NET Core with pure F#. There is no C# knowledge required, though it can be beneficial to familiarize yourself with it enough to understand usage and library documentation.
The official Getting Started with F# guide has a section on using .NET Core with "just F#", which you can use as a starting point.
As for writing a website, I highly recommend looking at the SAFE Stack intro, docs, and samples. It shows how you can use only F# for full stack web development, all using .NET Core.
This depends on your learning and working style.
Technically, F# does not need any support from C#. You can write complete programs of any kind whatsoever without ever touching C#.
However, a lot of F# resources online are geared towards migrating from C# to F#, and as a result are phrased in terms of the differences between the two. Something like "you've been doing this thing in C# before, but here's how it can be done way better in F#".
Additionally, a lot of .NET libraries are written in C#. The binaries are, of course, completely compatible with F#, so you don't need to do any sort of special tricks to use C#-written libraries. However, if you ever want to look at the source code, that's where C# knowledge would come in handy.
To be fair, there is quite a large number of F#-exclusive libraries out there, but the majority of .NET libraries are still in C#. So chances are, you will end up using some of them. Whether you would actually want to look at their source - that depends on your style.
There are some libraries that I could never get working nicely in F#, so I tend to have some C# projects built into my solution to handle things that I just could not find an elegant way of doing in F# - like using the high level "Nest" Elasticsearch driver. It is designed to give you very elegant code in C# but I found it was the exact opposite in F#, sort of defeating the point of using a high level driver.
C# is nothing to fear though, it is readable and intuitive for the most part. I came into F# with no knowledge of .NET and have learned what I've needed as I've gone along without any troubles.
I'm looking at Script#, JSIL and SharpKit as a tool to use to compile C# to Javascript, so I can program the client side functions of AJAX using C# in Visual Studio.
What are the pros and cons of each JSIL, Script# and SharpKit?
My project is a MVC4 project using razor engine and C#, if it matters.
If you're looking to integrate directly with an MVC project, something like Script# or SharpKit or something is probably your best bet - I know for a fact that Script# has stuff built in to make that sort of integration easier, so I would start there.
If you do want to try using JSIL, it probably has the core features you need, but things that you might want - like visual studio integration, automated deployment, etc - are not there. At present it is primarily targeted at cross-compilation of applications, so it does a good job of that but not as good a job of other use cases.
I'll try to give a summary of reasons why you might want to consider JSIL over those other alternatives - I can't really comment on the pros and cons of those alternatives in depth since I haven't used them:
JSIL has extremely wide support for the features available in C# 4. Notable ones (either because other tools don't support them, or they're complicated) include:
dynamic, yield, Structs, ref / out, Delegates, Generics, Nullables, Interfaces, and Enums.
Some of the above, of course, don't have complete support - to get an idea of things that absolutely will work, you can look at the test cases - each one is a small self-contained .cs file that is tested to ensure that JSIL and native C# produce the same output.
The reason for this extensive support is that my goal is for JSIL to enable you to translate a completely unmodified C# application to working JS. For all the demos up on the JSIL site, this is true, and I have a few nearly finished ports of larger real games in the wings for which this is also true.
Another reason is that JSIL makes it relatively straightforward for your C# and your JavaScript to talk.
All your C# types and methods are exposed via an interface that is as javascript-friendly as possible. The JS versions have basic overload resolution and dispatch so that native C# interfaces are callable from script code as if they were native JS in most cases. You don't have to take any steps to specifically tag methods you wish to expose to JS, or give them special names, or anything like that unless you want to.
When you want to call out from C# to JS, you can do it a few ways:
JSIL.Verbatim.Expression lets you insert raw javascript directly into the translated version of a function.
JSIL.Builtins.Global can be combined with dynamic and var to write JavaScript-like code directly in your C# function bodies.
The JSReplacement attribute can be used to replace invocations of a C# function with a parameterized JavaScript expression.
All of the above features can be combined with JSIL's mechanism for altering type information, called Proxies, to allow you to alter the type information of libraries you use, even if you don't have source code, in order to map their methods to JavaScript you've written.
And finally, C# methods that aren't translated to JS produce an empty method called an External that you can then replace with JavaScript at runtime to make it work again. Any External methods that you haven't replaced produce clear warning message at runtimes so you know what's missing.
JSIL makes aggressive use of type information, along with metadata you provide, to try and safely optimize the JavaScript it generates for you. In some cases this can produce better equivalent JavaScript than you would have written by hand - the main area where this is true at present is code that uses structs, but it also can apply in other cases.
For example, in this code snippet, JSIL is able to statically determine that despite the number of struct copies implied by the code, none of the copies are actually necessary for the code to behave correctly. The resulting JavaScript ends up not having any unnecessary copies, so it runs much faster than what you'd get if you naively translated the semantics of the original C#. This is a nice middle ground between writing the naive struct-based thing (Vector2s everywhere!) and going completely nuts with named return value optimization by hand, which, as I've described in the past, is pretty error-prone.
Okay, now for some downsides. Don't consider this list exhaustive:
Large portions of the .NET BCL don't have implementations provided for you by JSIL. In the future this may be addressed by translating the entire Mono mscorlib to JavaScript, but I don't have that working well enough to advocate it as an immediate solution. (This is fine for games so far, since they don't use much of the BCL.) This issue is primarily due to the IP problems related to translating Microsoft's mscorlib - if I could do that legally, I'd be doing it right now - it worked the last time I tested it.
As mentioned above, no visual studio integration. JSIL is pretty easy to use - you can feed it a .sln file to get a bunch of .js outputs automatically, and configure it automatically with a configuration file next to the project - but it's nowhere near as polished or integrated as say, Script#.
No vendor or support staff. If you want a bug fixed yesterday or you're having issues, I'm pretty much your only bet at present (though there are a few prolific contributors helping make things better, and more are always welcome!)
JavaScript performance is a goddamn labyrinth full of invisible land mines. If you just want apps to work, you probably won't have any issues here, but if like me you're trying to make real games run fast in browsers, JavaScript will make your life hell and in some cases JSIL will make it worse. The only good thing I can say here is that I'm working on it. :)
JavaScript minifiers and optimizers like Closure are explicitly not supported, because they require your code generator to jump through a bunch of hoops. I could see this being a real blocker depending on how you intend to use your code.
The static analyzer is still kind of fragile and there are still gaps in the language support. Each big application I port using JSIL usually reveals one or two bugs in JSIL - not huge game breakers, but ones that definitely break a feature or make things run slow.
Hope this information is helpful! Thanks for your interest.
Script# pros:
Free
Open source
Generates clean JavaScript
Script# cons:
Supports a subset of C# 2.0 language only
Can be compiled only in a separate project, cannot mix / re-use code between client and server
Low frequency of version updates
Does not offer support
Limited 3rd party library support, C# API is different than JavaScript API.
Not open source
Debugging in JavaScript only
SharpKit pros:
Commercial product
Supports full C# 4.0 language
High frequency of version updates
Support is available
Client / server code can be mixed and re-used within the same project
Extensive 3rd party library support, maintained as open-source - C# API matches exactly to JavaScript API
Supports basic C# debugging for Chrome browsers
Generates clean JavaScript
SharpKit cons:
Has a free version with no time limit, but limited to small / open-source projects
Not open source (only libraries are open-source)
JSIL pros:
Free
Open-source
JSIL cons:
Converts from IL (intermediate language), not from C#, which means a lower abstraction layer since code is already low-level.
Complex generated JavaScript code - almost like IL, hard to read and debug
Answers to feedbacks:
Kevin: JSIL output is not bad, it's simply generated to achieve full .NET behavior, much like SharpKit's CLR mode. On the other hand, SharpKit supports native code generation, in which any native JavaScript code can be generated from C#, exactly as it would have written by hand.
Sample of SharpKit's clean generated JavaScript code:
http://sharpkit.net/Wiki/Using_SharpKit.wiki
Developer can choose to create more complex code generation and gain more features, like support for compile-time method overloads. When specified, SharpKit generates method suffixes to overloaded methods.
Script# requires .NET 4 in order to run, but it does not support full C# 4.0 syntax, like Generics, ref and out parameters, namespace aliases, etc...
Another alternative is WootzJs. Full Disclosure, I am its author.
WootzJs is open-source and strives to be a fairly lightweight cross-compiler that allows for all the major C# language features.
Notable Language Features Supported:
yield statements (generated as an efficient state machine)
async/await methods (generated as a state machine like the C# compiler)
ref and out parameters
expression trees
lambdas and delegates (with proper capturing of this)
generics support in both the compiler and the runtime (invalidly casting to T will throw a cast exception)
C# semantics (as opposed to Javascript semantics) for closed varaibles
It is implemented using Roslyn, which means it will be first in line to take
advantage of future language improvements, since those will now be implemented via Roslyn itself. It provides a custom version of mscorlib so you know exactly what library functionality is actually available to you in your scripts.
What Are its Downsides?
The Javascript is not intended to look "pretty". It is clearly machine generated, though individual methods should be easy to reason about by looking at them.
Because of its extensive support for core libraries and reflection, the generated output is not the smallest on the block. Minification should produce an ~100k JS file, but minification is not yet supported.
WootzJs unabashedly pollutes native types with functions to encapsulate behavior for those types that would only be found in C#. For example, all the methods of System.String are added to the native Javascript String type.
Little support for binding to 3rd-party Javascript libraries presently exist. (Currently only jQuery)
Comparisons with Other Cross-Compilers:
Script# is very stable and has extensive integration with 3rd party Javascript libraries. Furthermore, it has excellent Visual Studio integration, and it provides a custom implementation of mscorlib. This means that you know precisely what functionality has actually been implemented at the tooling level. If, for example, Console.Write() is not implemented, that method will not be available in your editor.
However, due to its custom parser, it is still stuck in C# 2.0 (without even the generics found in that version of C#). This means that the modern C# developer is giving up an enormous set of language features that most of us depend on without reservation -- particularly the aforementioned generics in addition to lambdas and LINQ. This makes Script# essentially a non-starter for many developers.
JSIL is an extremely impressive work that cross-compiles IL into Javascript. It is so robust it can easily handle the cross-compilation of large 3d video games. The downside is that because of its completeness the resultant Javascript files are enormous. If you just want mscorlib.dll and System.dll, it's about a 50MB download. Furthermore, this project is really not designed to be used in the context of a web application, and the amount of effort required to get started is a bit daunting.
This toolkit too implements a custom mscorlib, again allowing you to know what capabilities are available to you. However, it has poor Visual Studio integration, forcing you to create all the custom build steps necessary to invoke the compiler and copy the output to the desired location.
SharpKit: this commercial product strives to provide support for most of the C# 4.0 language features. It generally
succeeds and there's a decent chance this product will meet your needs. It is lightweight (small .JS files), supports modern C# language features (generics, LINQ, etc.) and is usually reliable. It also has a large number of bindings for 3rd party Javascript librarires. However, there are a surprising number of edge cases that you will invariably encounter that are not supported.
For example, the type system is shallow and does not support representing generics or arrays (i.e. typeof(Foo[]) == typeof(Bar[]), typeof(List<string>) == typeof(List<int>)). The support for reflection is limited, with various member types incapable of supporting attributes. Expression tree support is non-existent, and the yield implementation is inefficient (no state machine). Also, a custom mscorlib is not available, and script C# files and normal C# files are intermingled in your projects, forcing you to decorate each and every script file with a [JsType] attribute to distinguish them from normally compiled classes.
We have SharpKit for two years and I must say that's upgraded the way we write code.
The pros as I see them:
The code is much more structured - we can now developed infrastrcture just like we did in C# without "banging our heads" with prototype.
It is very easy to refactor
We can use Code Snippets which results in better productivity and less development time
You can control the way the JS is rendered (you have several modes to choose from).
We can debug our C# code in the browser (Currently supported on Chrome only, but still :->)
Great support! If you send them a query you get a response very fast.
Support a large number of libraries & easily extensible
The cons:
The documentation is a bit poor, however once you get a hang of it you'll boost your development.
Glad if this could help!
For ScriptSharp, this stackoverflow link could be of help.
What advantages can ScriptSharp bring to my tool kit?
If you have any SVN tool, please download a sample from https://github.com/kevingadd/JSIL, this is a working source code and can help you go miles.
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 12 years ago.
I know it is a kind of broad question but any answer are appreciated.
All:
Require some form of runtime on your system (JVM/.net/Python runtime)
All can probably be compiled to executables without the runtime (this is iffy and situational, none of them are designed to work this way)
Are good languages
All have specific areas where they are much more appropriate than the other two
Java:
Tries very hard to be Cross Platform--generally succeeds
Little access to platform features that are not in the SDK
Slowest of the three to change and does not contain features common to the other two such as closures
Very backwards compatible (partly because of the previous point)
FAST (about 2x slower than C, quite a few x faster than python)
Probably has the most library support of the three
Strong multi-platform server systems already deployed using J2EE
Scales down to embedded (I've worked on 2 different embedded java projects--coming soon to a cable box near you)
Static
C#
Quicker to add new features
Windows only--Mono is cross platform but does not have the library support.
Started very similar to Java but has many more language features now.
Much better access to windows APIs
Not sure about speed--I think it's similar to Java.
Very good library support
The only one of the three that you have to pay for (it's free for "entry level")
Static
Python
Language is cross platform. Not sure about non-language platform access (such as drag-and-drop)--anyone know?
Probably an easier language to learn
The only one of the three that does not use c-like syntax
Slowest of the three, but still pretty darn fast compared to other dynamic languages.
Dynamic
This link is also interesting
Python is a dynamic language where Java and C# are really not. It is totally different than the other two. There are ways to accomplishing things in Python that do not translate well to the others and vice versa.
Java and C# look the same, but they have differences between the two under the sheets. Being an expert in one, does not make you an expert in the other by any stretch of the imagination. The syntax is similar and libraries are too, so it would be easier to get up to speed in one or the other, but there are subtleties that can trip you up.
C# and Java have almost identical syntax and very similar libraries. There are differences that you have to be aware of (Type Erasure in Java, for example).
Python is a completely different animal. It is a dynamic language (where the other two aren't). Python winds up being closer in style to something like Ruby.
Java and C# are statically typed languages, while Python is a dynamically typed language. That's a huge difference.
The syntax of Java and C# is similar (but I would not call it "almost identical" as Justin Niessner says).
Java and c# are pretty similar in terms of syntax and are mostly strongly typed (C# is getting more dynamic with every version), Python is a dynamic language
Java and C# are very similar and are syntactically similar to C/C++. They also use braces to mark code blocks.
Python is completely different. Although imperative like Java and C#, Python uses indentation to define blocks of code.
Java and C# are also compiled languages, whereas Python is interpreted and dynamic.
Python, Ruby, and Groovy are somewhat similar languages.
C# and Java are easy to move between, although I don't know many people who are experts in both. C#'s syntax is based off of Java, so they read very, very similarly. They both run cross-platform; Java on the JVM, C# on .NET or Mono. They're both OOP, and widely used for web development. I'd use whichever the team was more familiar with.
Python's off to the side there. It's also used frequently as a scripting language. It can use classes and object orientation, but isn't forced to. It's not as well supported for web work. I'd use this for a different set of tasks than C#/Java.
C# and Java are the two languages you listed that are most similar. Python has a very different syntax, and uses a slightly different programming model. Both C# and Java are Object Oriented languages at their core, with increasing nods to Dynamic Typing. Python began as a Dynamically Typed scripting language and has been picking up more and more Object Oriented features over the years.
The C# class library (.NET Framework) is theoretically multi-platform, though it's heavily weighted towards the Windows platform, and any other OS compatibility is largely an afterthought. The .NET framework currently has two "official" frameworks for building windowed applications (Windows Forms, and WPF) and two "official" frameworks for building web applications (ASP.NET, and ASP.NET MVC). Windows Forms is similar to Java Swing, but the other four frameworks are very different from much of what is found in the Java or Python worlds. There are many language features in C# that are different or lacking in Java, such as Delegates.
The Java class library is pretty solidly multi-platform. It's officially supported desktop and web frameworks (Swing and J2EE) are generally regarded as slow, and difficult to use. However, there is a very lively open source community which has built several competing frameworks that are very powerful and versatile. Java as a language is very slow to introduce new language features, though it is runtime-compatible with several other languages that run on the Java platform (Groovy, Jython, Scala, etc..). Java is the language which has has the most run-time optimizations put into it, so an application written in Java is almost certainly going to be faster than an application written in C# or Python.
Python is an interpreted language (in general), and is pretty solidly multi-platform. Python has no "official" desktop or web frameworks, though desktop applications can be written using GTK or Qt support, both of which are multi-platform. Django has become a de-facto standard for Python web development, and is regarded as a very powerful and expressive framework. Python is at this point fully Object Oriented, and is notable for it's powerful tools for working with collections/arrays/lists. As an interpreted language, Python will be significantly slower than either C# or Java.
Python was made to be simpler, more readable, flexible and object oriented than what existed before - i.e. Java, Perl etc. It's actually closer to Java than it is to Ruby. Ruby is more like Smalltalk. Think of Python as Java without the stuff that mostly gets in your way, makes things awkward to do, slows you down or clutters the essence of your logic. So no semi-colons, curly braces for scoping. No static variable declaration or variables at all really they're identifiers that point to objects instead.
There's also a standard style guide for Python unlike other languages. Indentation is used to indicate scope and inconsistent indentation is a syntax error.
It also includes some often used things built into the language: lists, dictionaries, sets, generators etc.
Java is nice for those familiar with C / C++ syntax and are set in their ways, like that syntax and find it readable. Ruby and Python are for those that preferred Pascal or Smalltalk to C, like Lisp etc.
They are not similar at ALL. They all take widely different approaches to OOP, syntax, and static/dynamic typing.
We have developed a C# class library on VS 2008. We want the same functionality as a C++ library on Red Hat Linux. How do we accomplish that?
I am sure we are not the first to migrate C# to C++. Are there any automated tools to convert the source code?
We know about Mono, but we would very much prefer C++ source code.
About 15% is the useful code, the rest 85% are unit tests using NUnit.
At the very least we do want to migrate all the unit tests as source code.
We used Reflector, which did almost all the work for us. The only thing it screwed up were constructors.
Consider the following C# code:
public MyClass() : this(1,2,3){}
it should be converted to
public MyClass() : {this(1,2,3);}
but Reflector converted it to
public MyClass() : {MyClass(1,2,3);}
um, are you asking for a general-purpose c# to c++ code converter that also switches platforms?
No problem, it's called a human, and you can hire or contract one from many different locations.
You may also want to look at the Mono Project, which has a fully functional c# compiler and .net runtime for various other platforms (including RH Linux). This way you would not need to recode the library into c++, although you may need to change the code in small ways if you're using things that mono does not support.
You can get a head start by first converting to C++/CLI (the .NET flavor of C++). Red Gate's .NET Reflector supports conversions between .NET languages (you need a plugin to decompile to C++/CLI) and there are other tools as well.
I don't think there's any way to automatically translate C# to C++, if that's what you're asking, so I don't think you could get the C++ you want without manually writing it. Maybe you can use the C# itself instead via Mono...?
Unfortunately, I'm not aware of any such tool. However, translation from C# to C++ should be easier than C++ to C#. The features C# supports but C++ doesn't (say, reflection, and defined behavior in certain cases -- like order of evaluation) is much smaller and easier to work around than the features C++ has but C# doesn't (looking at just C++ templates, you have template functions with the ability to deduce type arguments, passing compile-time constants as template arguments, partial template specialization, complete template specialization, CRTP, substitution failure is not an error, etc.).
Is there a particular reason you prefer C++ in RHEL ? If not Mono is a better solution.
I want to enhance an application with scripting support like many other applications have, e.g. MS Office using VBA or UltraEdit using JavaScript.
Which libraries do exist for C#/.NET (and which language(s) do they support)?
Please check CS Scripting library
Here is an article about scripting Photoshop CS with C#
This one discusses using LUA as scripting lib with C#.
IronPython is a dynamic .NET scripting language.
IronPython is an implementation of the Python programming language running under .NET and Silverlight. It supports an interactive console with fully dynamic compilation. It's well integrated with the rest of the .NET Framework and makes all .NET libraries easily available to Python programmers, while maintaining compatibility with the Python language.
See IronPython embedding for examples showing ways to call IronPython from .NET apps.
The IronPython Calculator and the Evaluator goes into the details of using IronPython from a C# application.
Lua is often touted as being one of the better ones... Try looking at this other question for more information: What are the most effective ways to use Lua with C#?
Also:
Lua Interface
Binding code to Lua
See "What is the best scripting language to embed in a C# desktop application."
Also see "It Already Is A Scripting Language" from Eric Lippert.
Don't forget LSharp, LISP in .NET. Something to keep an eye on if you are exploring functionality stage. Maybe Rob Blackwell will be glad to hear you're considering it.
You can bake your own scripting environment with Mono.CSharp (just one simple dll) or Roslyn, both are getting quite mature now.
Mono contains the Evaluator class and Roslyn the ScriptEngine, both make it a breeze setting up a script environment. Of course something like ScriptCS already builds on that (Roslyn) and gives you more features.
For an C# script environment built on Mono.CSharp you can check out CShell (which I made).
Depending on your needs, the SILK library might be a good option.
It's an easy to use interpreter. The interpreted language is not C#. It's a custom language that was designed to be easy to use (very little punctuation, not case sensitive, etc.) But it does support functions.
Built-in functions are handled via events. That is, when the interpreted code calls one of your internal functions, it raises an event in your program.