Is F# the only actively-developed functional language for the CLI, which supports Mono and has Monodevelop plug-in? or are there others I missed?
F# is pretty fun, but it's not as awesome as a lisp like clojure which sadly doesn't support mono yet.
There's IronScheme, Clojure (or more precisely ClojureCLR) and Nemerle. The CLI port of Scala picked up steam again a couple of months ago and is even sponsored by Microsoft, although AFAIR the projected feature-parity release (i.e. the point at which the JVM and CLI versions have the samne features and are released on the same day) is 3.0, which is still one or two years away.
Related
How is the versioning of Jython? If I install Jython 2.5 does it mean that I can program in Python 2.5 syntax in spite of Python3.3 or the Jython versioning system is dependent?
By now the last version of Jython available for production is 2.5.3. If the versioning of Jython is based on Python, it looks deluding to be able to program only In Python 2.5 or earlier.
Jython x.y.z means that it's spec compatible with Python x.y, e.g. Jython 2.5.3 is compatible with Python 2.5 versions. (Python 2.5 introduced the "with" statement aka context manage. This has been implemented in Jython 2.5.)
As implementing each new version is a lot of work and the Jython project has not enough resources to keep up with all versions it was decided to not implement all intermediate versions.
The PyPy project aims to avoid this by abstracting and automating the transformation to a concrete runtime system (native, jvm, .net, etc.)
I don't understand the part "in spite of Python 3.3" in your question.
1.3 Is Jython the same language as Python?
Yes. Jython is an implementation of the Python language in Java. We strive to ensure that Jython remains as compatible with CPython as possible. The latest Jython release (2.2) implements the same language as CPython 2.2 and many of the CPython standard library modules.
There are two incompatibilities with modern CPython that often catch newcomers. First, Jython 2.2 does not implement any features added to CPython in version 2.3 or later. This includes language features such as decorators, and library modules such as optparse. A more modern version of Jython is under active development.
Second, Jython programs cannot use CPython extension modules written in C. These modules usually have files with the extension .pyc, .pyd or .dll. If you want to use such a module, you should look for an equivalent written in pure Python or Java.
There are a number of other differences between the two implementations that are unlikely to go away. These range from the trivial - Jython's code objects don't have a co_code attribute because they don't have any Python bytecodes; to the significant - Jython uses Java's true garbage collection rather than Python's reference counting scheme.
http://jython.sourceforge.net/docs/differences.html
Python has never really had much of a language definition beyond it's C-based implementation. The existence of Jython changed that for the first time and will hopefully lead to a much clearer sense of what Python the language is; independent of any specific implementation.
From: http://www.jython.org/archive/22/userfaq.html#id4
To me it seems that you only have access to Python2.5 if you are using Jython 2.5.3.
Please do not promote Nautilus or Glamour here. I'm using Pharo 1.3 (without plans to migrate to Pharo 1.4 or 2.0). It seems to be many version of OmniBrowser out there. Which one is the most tested (in the sense of coverage) or just buggy-free?
http://www.squeaksource.com/PharoOB
http://source.lukas-renggli.ch/ob21
http://source.lukas-renggli.ch/omnibrowser
http://source.wiresong.ca/ob/
...and probably more
I have some questions for it:
Does it work with Shout correctly?
Can I load it without the AST and Refactoring Engine?
Can I load it without Morphic?
It is compatible with any version of Squeak?
It is loadable in Cuis?
Thanks
Omnibrowser is pre-installed in Pharo 1.3.
If you're talking about installing it in 1.3 core, use:
Gofer new
squeaksource: 'MetacelloRepository';
package: 'ConfigurationOfOmniBrowser';
load.
((Smalltalk at: #ConfigurationOfOmniBrowser) project perform: #version: with: '1.3') load: #( Dev ).
As to your other questions...
Does it work with Shout correctly? Yes.
Can I load it without the AST and Refactoring Engine? Yes. Load the #Core group instead of #Dev.
Can I load it without Morphic? No.
It is compatible with any version of Squeak? Yes. You can load it into Squeak 4.2 and 4.3 with:
Installer ss
project: 'MetacelloRepository';
install: #ConfigurationOfOmniBrowser.
((Smalltalk at: #ConfigurationOfOmniBrowser) project perform: #stableVersion) load: #( Dev ).
Although there seem to be some problems with it. For instance, refactorings didn't seem to take, and I had to change a few #createCompletionController methods, as errors came up, to:
createCompletionController
^ OController model: self
It is loadable in Cuis? Highly doubtful.
The repository http://source.wiresong.ca/ob/ is the official OmniBrowser repository for Squeak (using Tool-Builder). The repository http://source.lukas-renggli.ch/omnibrowser is the official OmniBrowser repository for Pharo (using Polymorph). In both repositories the core packages are identical and mirrored regularly.
The repository http://source.lukas-renggli.ch/ob21 is outdated, it stems from an experiment that I started many years ago. I removed the repository for now to avoid further confusion. All other repositories (as well as the various Metacello configurations) are based on outdated and forked code. The code you get there lacks many improvements and misses important fixes that had been implemented a long time ago.
For Pharo 1.3, as Philippe points out, you have to merely file-in https://github.com/renggli/builder/blob/master/scripts/omnibrowser.st to get a stable installation. Shout, eCompletion, the Refactoring Engine, and various other extensions are optional. Just remove the parts you don't need from the script. Technically Morphic is not needed either, but then you don't get a default user-interface. There are several other interfaces like OB-Web and OB-Mars that you could load, but I don't know how well they currently work.
The same file-in also works in Squeak. You just have to replace the following packages:
Refactoring-Pharo-Platform with Refactoring-Squeak-Platform (if you want the refactoring engine)
OB-Pharo-Platform with OB-Squeak-Platform
OB-Polymorph with OB-ToolBuilder
Shout is preinstalled in Squeak and not needed
eCompletion does not work in Squeak (as far as I know)
I don't think OmniBrowser works in Cuis. It could be made to work by providing the necessary platform and UI packages. OmniBrowser is unlikely to ever be supported in Pharo 1.4 or Pharo 2.0, because central parts of the reflective system (such as MethodReference and SystemNavigation) changed drastically.
I use the one from http://source.lukas-renggli.ch/omnibrowser because I know where Lukas lives ;-) Lukas has been maintaining it for several years now and I've never had any issues. Having that said it only really works in Pharo 1.3.
Does it work with Shout correctly? Yes
Can I load it without the AST and Refactoring Engine? Yes
Can I load it without Morphic? No
It is compatible with any version of Squeak? No, only Pharo 1.3
It is loadable in Cuis? No, only Pharo 1.3
I use the load script from
https://github.com/renggli/builder/blob/master/scripts/omnibrowser.st unfortunately there is no Metacello configuration.
I have a friend who is was a serious Linux developer but now he's working with C# on Windows and is really loving it. I'm attracted to C# because, like Java, I should be able to compile on one system and run anywhere.
If you are developing on Windows with C#, you're using dot-Net. On Linux and MacOS, you're using Mono.
Other people have posted that Mono is pretty good, no longer a science project, and that most of the core Microsoft functionality is present. But that's not really getting at the questions that I have. I'm wondering:
How does performance of Mono on Linux/MacOS rate against Java? If I want to run fast on all three platforms with the same object code, what's my best choice?
Is it easy/possible/reasonable to use Mono with makefiles and do my development with emacs?
Is there support for code factoring in MacOS and Linux, or am I better off just biting the bullet and doing all of my development in Windows?
How well does Mono work with Subversion and the rest of the open source development stack? How about autoconf? Or is this a completely different way of doing things?
Thanks
I have been using Mono on Linux for about three years and lately have been using it on OS X. Some of the Linux stuff was pretty extensive but the OS X stuff has just been some simple ASP.NET MVC2 apps so far.
1) Performance of Mono has never been an issue for me. That is not to say that performance has not been important, it is just that the performance of Mono itself has never been an issue. A lot of what I have done is web based so I/O and database memory use have hit me before Mono has.
Historically, the biggest deficiency with Mono has been the Garbage Collector (GC). I would say that Java is better tuned in this regard. The most recent versions of Mono have made huge strides in this area but I do not have any hard numbers for you in terms of comparisons.
I am sure Mono is faster sometimes and Java sometimes but I would say that Java is faster overall.
2) You can certainly do Mono development with makefiles. Certainly the Mono team itself does. Also you can certainly use Emacs and there is a C# mode for it.
I tend to use MonoDevelop and xbuild (Mono version of msbuild) myself and do not have any experience doing C# work in Emacs. MonoDevelop is great because it is exactly the same on all platforms. Also, although I rarely use it anymore, it is nice that the project format is the same as Visual Studio and SharpDevelop.
3) MonoDevelop has pretty decent code factoring support. It is the same on Windows, Linux, and Mac. You do not need to use Windows for development (though you certainly can) but I believe you will be happier using an IDE like MonoDevelop. Even things like Intellisense become hard to live without once you are used to them. But integrated debugging, being able to drill-down into the framework, database integration, unit testing, SCM integration, and other nice tooling support all in one place is just the way to go (for me at least).
4) Mono itself does not care about version control of course. Your source files are just text and you could use anything to manage them.
That said, MonoDevelop has fantastic Subversion support built right into the IDE. I have used it extensively and it is one of the reasons I have trouble moving off MonoDevelop even on Windows. The latest version of MonoDevelop (2.6 beta) includes Git support as well.
You did not mention unit testing but MonoDevelop also has NUnit support built into the IDE. I use that on every project as well and it works excellently. The version in MonoDevelop is 2.4.8 (if memory serves) so it is not quite current but it works great.
In a nutshell, Mono works really well with Open Source tooling in general. It has always played really well for me.
Autoconf is of course used by the Mono project itself but, as a Mono developer, I have never seen a need for it. I strive to only use managed code in my projects. As such, all I need on the target platform is Mono (or .NET). Not having to worry about all that stuff is one of the primary benefits of a managed environment like Mono or Java. The runtime itself (the CLR) ensures that my app has everything it needs to function properly.
I know that MonoDevelop will build autoconf/autorun files for C/C++ projects (non-Mono) but I have not done much with it myself.
As to a previous comment, the Mono JIT is obviously tuned to the target platform. That is where platform specific performance tuning happens.
Just as a comment, I find that Mono is best viewed as a development environment in it's own right rather than a compatibility layer for Microsoft stuff. The Mono team has extended .NET in many interesting ways. Anything you develop for Mono will run on .NET but there are some .NET features not available for Mono. For example, Mono does not support Windows Presentation Foundation (WPF). You have to use Windows Forms or GTK# for cross-platform GUI work. You can also use something like Cocoa# or MonoMac on the Mac, MonoTouch on iPhone, or MonoDroid for Android. You can use Moonlight instead of Silverlight as well although I have not played with it much.
One more thing since you asked about Java. I have found a few times that the Java world had libraries that I could not find equivalents for in the .NET world. In these cases, I have had amazing luck using IKVM.NET to integrate this into my Mono apps. IKVM.NET also works on .NET but Mono and IKVM.NET are very cozy and even share some code.
So there you go, one real answer for you at least.
I'm evaluating components for a new embedded platform. CPU is an ARM9 and OS is Linux. Because the platform will be in use at least for 10 years I think the language should be chosen carefully as well. I'm already running Mono on possible target platform. Beside that I'm to dumb to compile Mono with my Compiler (according to Google more or less everyone else has the same problems), it's already running. I've written some benchmarks for our specific needs and I was quite impressed that Mono was never more than twice as slow compared to plain C. Memory usage is OK, and when I remove all unneeded files the footprint is acceptable. I just like to know if anyone else uses Mono on an embedded platform? Did you have any problems? Things which everyone should consider?
Given that the iPhone and Android are ARM, Mono is very well supported on ARM. And because Novell sells supported versions of Mono targeting those platforms, it is likely to stay well supported for quite some time.
One thing to note is the Mono runtime is licensed under the LGPL, so you need to ensure your usage complies with the license, or you will need to purchase a commercial license for Mono.
I'm working on a cross-platform solution currently. The solution uses XmlMtomReader and XmlMtomWriter from .NET framework 3.0.
Now i need to know if these two classes (and all the nessasary infrastructure around them) are fully supported in Mono project from the porting-it-to-linux point of view. :)
You can check it on the mono status:
http://go-mono.com/status/
You can also check your code using the mono migration analyser
http://www.mono-project.com/MoMA
I checked they are currently not implemented
The APIs are available on the current Mono 2.6 preview, but they are not available on the 2.4 release (the current official release).