On Thu, Oct 8, 2009 at 7:58 PM, <steve-ALUG@hst.me.uk> wrote:

Srdjan Todorovic wrote:

...

Programming for Linux is great - so many tools and languages to choose from. What languages do you program in?

Visual Basic, Visual Basic.net and many years ago, C++.  So I'd be rusty at C++, and I don't particularly fancy using VB under Mono - I tried to get it working a few times, and failed abysmally! :-(

Mono is an awesome open source implementation for .net - You could try getting Mono for windows and keep writing in Visual Studio but running in Mono, then when you port to Linux it isn't so much of a surprise. I actually develop in VC# express for my linux box. If you're into your Gui apps, then Windows Forms & WPF of course will not work nativly (without using Wine or similar), but there are things which you can use instead, such as GTK ( http://www.mono-project.com/GtkSharp ). GTK also has the advantage that (once you've installed its components) works on most modern OS's. Best Regards JT

...

Mono is an awesome open source implementation for .net - You could try getting Mono for windows and keep writing in Visual Studio but running in Mono, then when you port to Linux it isn't so much of a surprise. I actually develop in VC# express for my linux box.

How do you do this?

Firstly, you can attempt to run a Visual Studio compile file in Mono. I've found this often works (except for where Windows Specific functions are called). So, I would compile my exe, then instead of running it directly, I would (in a command prompt) run: mono myfile.exe * There is a way to get visual studio to run that instead of you even inside its IDE but I can't remember the exact way. e.g: In Express, New CS Project, Console App: using System; class Program { static void Main(string[] args) { Console.WriteLine("Hello From " + System.Environment.CommandLine); Console.WriteLine("System Version: " + System.Environment.Version.ToString()); } } Compiling in visual studio, then running both from mono and the normal exe (from a mono command prompt): C:\Users\jt\Desktop\ConsoleApplication1\bin\Debug>ConsoleApplication1.exe Hello from ConsoleApplication1.exe System Version: 2.0.50727.3074 C:\Users\jt\Desktop\ConsoleApplication1\bin\Debug>mono ConsoleApplication1.exe Hello from C:\Users\jt\Desktop\ConsoleApplication1\bin\Debug\ConsoleApplication1.exe System Version: 2.0.50727.1433 And of course, running in Linux (uploading same Visual Studio compiled application: jt@cornflakes:~$ mono ConsoleApplication1.exe Hello from /home/jt/ConsoleApplication1.exe System Version: 2.0.50727.42 You can begin to see the subtle differences that Mono and standard .net virtual machines give. Something to be wary of is that Mono in Windows may have access to windows dll's, so some WPF and windows forms will still work.

I have to develop some windows apps which I use VC# express for, because it's not a bad development environment for all I normally think of MS products. However it would be very nice to test under Mono.

Oh, VS is awesome for developing - the apple xcode ide would be second on my list, followed by eclipse at quite a distance. (However Eclipse caters for languages that VS and the apple ide's do not, and :. it is awesome.). The downfall comes when you wan't to do something silly like talk to a mysql database rather then an mssql one. Best Regards, JT

I'd quite like to try Mono/C# to see what all the fuss is about, but I don't know the language. There was an interesting Java -> C++ transition document I read years ago. Is there some similar C++ -> C# document that you would reccommend?

I would like to know more about language transition documents in general. Haven't tried mono yet, will have to see if I can get MANGOS going with it. Cheers Richard

C# isn't, in my opinion anyway, "better" than the other languages like Delphi, Java, VB; it is fairly well supported however in terms of sample code and tools, so it's easy to get started (as are the others).  MS have done a decent job of a development environment and I was wrtting the application on a Windows platform so that was a contributory factor.

It's also worth looking at FreePascal (and Lazarus) which is comparable with older versions of Delphi but just feels dated now.

I think you hit the nail on the head with the dated: its all about how dated a language feels. As times change, all the basic functionality is provided for you, so you want quick and easy ways to access that to build bigger applications. The sorts of applications being built now where only being dreamt about 10 years ago, and 10 years beyond that. The second thing is that security holes and requirements change over time. Older languages (pascal, fortran) never where really designed to do web scripts and talk to databases. They don't have the kind of functions which are useful (hrm, how DO you escape attempted sql injection in Fortran? ... maybe I'll try something on my new punch card writer!) Also, there is a beginning to be a shift towards more high level virtual languages (again). There's lots of reasons for this, but at the moment one of the pressing reasons is that you don't (as a developer) have a good understanding of what target computer your app is going to run on. Is it a single processor box? is it some kind of funky quad processor box? Is it something scary like the itanium. The modern languages should be cool with abstracting to this sort of level, where older language (and I include C and Assembler in this) can't. I'm not saying they won't work, I'm just saying they wont be able to use the power as effectively. I personally think you also can say one language is better then another - for individual roles and specifics. If you are a hacker and you want to be able to just write something quickly to do something (spam a website, accept emails, scan a thousand files), then you are looking for a language which has that kind of functionality which is easy to write in - perl, bash, etc. If you're writing code for a bank, and have to be sure that its 100% correct, and that every exception possible is caught, and that every change to the code matches one of ten thousand test cases, then you might want something which is a little more meaty like C#, Java or C++. I think if I was going to start from scratch to write an app now, it would either be in: Bat / Bash for low level scripts (depending on OS) C# or Python for services Python/Django OR Php/Drupal for websites (or maybe something else if I was writing for cloud type services) JT

On Fri, Oct 9, 2009 at 11:28 PM, <steve-ALUG@hst.me.uk> wrote:

James Taylor wrote:

...

The second thing is that security holes and requirements change over time. Older languages (pascal, fortran) never where really designed to do web scripts and talk to databases. They don't have the kind of functions which are useful (hrm, how DO you escape attempted sql injection in Fortran? ... maybe I'll try something on my new punch card writer!)

Er, COBOL perhaps?  One of the first computer languages and designed to do database stuff!

As far as I'm aware, Cobol wasn't originally designed to "database" stuff - its just too old* (I'm talking pure original Cobol here). Programmers would have to develop their own file routines (however Cobol was one of the first languages to have the concept of "libraries" of other peoples code that you could call, so undoubtedly there would be database-type-libraries that could be added on. Secondly, my point is about useful function - even if Cobol (originally) did have database specific functions, they would be very low in comparison to the sort of database functions that exist using things like Django and LINQ style interactions. Would it even have the concept of SQL Injection if in those days they had no user input? (again, a concept which has to be bolted onto the language at a later point). I should point out that LINQ can be considered a bolt on - it didn't appear till .NET 3.5 JT

Snipping and reordering:

However, I am aware that this is a) Off Topic, and b) I'm by no means an expert on COBOL.

Blow that. This is one of the most interesting topics on the mailing lists in ages. Besides, you started this topic so you get to say what its about. Mark Rogers a while back on the thread said:

My experience is that the language differences are sufficiently subtle if you are a "programmer", ie you are used to programming generally.

I think thats a very generalized statement, and for the moment it suits my purpose to agree to exagerated proportions (I hate the term expert) : As an expert professional engineer in a different language, I'm more then have this discussion about Cobol...

...

As far as I'm aware, Cobol wasn't originally designed to "database" stuff - its just too old* (I'm talking pure original Cobol here). Programmers would have to develop their own file routines (however Cobol was one of the first languages to have the concept of "libraries" of other peoples code that you could call, so undoubtedly there would be database-type-libraries that could be added on.

Not trying to be awkward, but as far as I can work out, COBOL started with File handling routines, and these supported Indexed files right from the start, which is what it was intended to do - Common Business Oriented stuff.  Whilst indexed random access files might not qualify as the fully functional Relational Database Management system that we're expect when we talk about Databases today, I'm sure programmers at the time would have considered it "Database Stuff."

Lets hunt out some Cobol programmers.... Nev from the other topic is one! I think we're saying the same thing but the language is different - my point is that by "database stuff" I mean that the language itself does "database stuff" rather then programmers making database like applications using the more basic file handling. And this is part of the original point - if you've got 3 months to write an application in, and you spend two of those pissing about with file handles and following indexes, then you're program is limited in what it can do. Instead these days, I spend a fair amount of time working out what I want to build, what the data layout is, just like they would in original days, and then I just say create a database, create my objects as they are on paper, and just say "store 'em in there" and boom dingaling it does it. I then have 2 spair months to sit around complaining about various things and arguing about whether if I was writing in Cobol I would be a better programmer. Noodles from irc also pointed out that Cobol does include SQL injection routines, but I think we have a fundamental problem, which is that our concept of the language is what it could do when we discovered that language - Cobol dates to late 50's, SQL dates to early 70's, so certainly all that you could want from a language gets added to it over time. This though, can also be a bad thing - PHP got added to quite rapidly, but not in a very good manner, and as such there are various annoyances such as inconstancies in argument ordering across different libraries. So, I say one language *can* be better then another language, and age, and forward planning and knowledge of future technologies is one of the prime factors to this. Actually it seems there is a strand of Cobol for .Net, working fully and the engineers even going so far as to write ASPX pages... must.... not ..... must.........not....

On 09/10/2009, James Taylor <jmon.monster@googlemail.com> wrote:

...

Mono is an awesome open source implementation for .net - You could try getting Mono for windows and keep writing in Visual Studio but running in Mono, then when you port to Linux it isn't so much of a surprise. I actually develop in VC# express for my linux box.

I'd quite like to try Mono/C# to see what all the fuss is about, but I don't know the language. There was an interesting Java -> C++ transition document I read years ago. Is there some similar C++ -> C# document that you would reccommend?

To be honest, a Java -> C# tutorial might be better - couple of quick things first. What we're talking about is .Net. .Net is a compiled language called CLR, which you then write in any language you like in, that compiles to that CLR. So I can write in C#, you could write in VB, someone else could write in J# and we could all use each others libraries and classes as if they where written in our own langauge... So when I talk about C#, some times I am talking about it as a langauge (i.e. its syntax) and sometimes I'm talking about how .Net works. <the following is my opinion only I'm not looking to start a flame war. Also Java has had another major release since C# has released - the two languages cause each other to become better> C# is better then Java because basically, its younger. it was invented about ten years after Java and got to avoid all the mistakes that Java happened (through standards in naming conventions through to much more complex things. Microsoft pumped a lot of time and effort into deciding how it would work, instead of other languages which have "evolved", this has had a very clear design iteration to it. On one level, it works just like Java - its requires a virtual machine to run in, although instead of Java saying "write once, run eveywhere" .Net decided to go down the line of "write once, and understand that some bastard might be running it somewhere else" so there is a very clear delineation where you can write something like this: if(!HttpListener.IsSupported) { throw new ApplicationException("Windows XP SP2 or Server 2003 minimum required to use HttpListener Class"); } Now, this bit of code means that my code *will* run in Linux or a Mac (or even Windows XP SP1) but when It reaches that line I'm able to detect it, and either fall over gracefully, or provide an alternative (in this instance, I've thrown an app exception which for this app probably means game-over. The other great advantage over Java is the use of unmanaged. I've been writing C# full time for about five years now, and had been writing bits here and there before that, and in this time, I've only ever written two classes which where unmanaged, and they where hardware interface classes - if you're a hardware hacker, then you will probably do a lot more. The difference is that in Managed (normal), C# acts and feels like Java - you don't have pointers, you have references. When something goes out of scope, the garbage collector eats it up. In Unmanaged, you have access to things like malloc. Now, you loose a lot of power of C# protecting you, but you gain the power of being able to do your own funky small efficient nasty code. To swap into unmanaged is a simple one word tag. Downside of C# is that it has lost its Forced Exceptions (controversial!!) The reason I call this a downside is that there is no way to (at compile time) see which functions *might* throw an exception. If a programmer (especially of a class in another dll) has not documented (and there is a funky .net documentation feature javadoc but using XML tags), then that can goes unnoticed until that exception is actually thrown.

I'd rather not spend a lot of money on a C# book that spends > 50% of the time teaching you what a for/do/while loop is and what if statements are, or what objects are.

Try: http://www.harding.edu/fmccown/java1_5_csharp_comparison.html http://www.25hoursaday.com/CsharpVsJava.html

steve-ALUG@hst.me.uk wrote:

Not wishing to be to picky, however, this is as I understand what happens under Windows; Linux and Mono may be different. The .Net languages are compiled, but not to native machine code but to CLR - Common Language Runtime code - this is an intermediate level language (it used to be called MicroSoft Intermediate Language (MSIL)). This code is then compiled at runtime to native machine code. This second compilation step is performed not by a traditional compiler, but by a Just In Time Compiler (JIT Compiler) which compiles the CLR code into Machine code just in time, before it is needed. To be honest, I've never seen why this is supposed to be an advantage as the end result seems to be slower than native machine code. IBM got this right with the AS/400 back in the early 80's. Every application (and even bits of the OS itself) come compiled as TIMI objects which is a virtual instruction set.

However these instructions are never directly interpreted. There is a sort of JIT like final compile step run that translates these into the current architectures instruction set. Once done this native code is appended to the runable object and it then behaves (on that box) just like it was a native binary. Move it again to a different AS/400 on a different arch (say move it from an early CISC machine to the newer PPC based machines) and the process is repeated and it is now a native application for that machine. Due to this you can take application code from an 80's System/36 (which was a 48bit CISC machine) copy it straight to a brand new (i series PowerPC 64bit multi CPU) box and it will just work, but with all the advantages of being a native application for the newer machine. Not only does this work IBM pretty much promise that it *always* works with 100% compatibility.