F# - A New .Net language

Goalie_Ca writes "Neonerds.net has learned of an implementation of the ML programming language for the .NET Framework. F# is essentially an implementation of the core of the OCaml programming language . F#/OCaml/ML is a mixed functional-imperative programming language which is excellent for medium-advanced programmers and for teaching. In addition, you can access hundreds of .NET libraries using F#, and the F# code you write can be accessed from C# and other .NET languages. See the F# Homepage."

Comments

That's the power of .NET

[frleong]

Smaller languages can really compete with popular languages, because the same library is available to everyone. This promotes fairness in the development tools domain (in contrast with what MS does in its business tactics).

Although there are other languages that can run on JVM, the ease of getting inheritance and cooperation to this level is only possible in .NET.

Re:That's the power of .NET

[Beliskner]

the CLS runtime is a cheap knockoff of the JVM, take a look at the API and its obvious

Samba is a cheap knock-off of WinNT SMB server, but here's the secret - the knockoff *can* be better than the original.

Re:That's the power of .NET

[Ed Avis]

So this compiler lets you access Microsoft's proprietary .Net class libraries. A native code O'Caml compiler can access the hundreds of libraries written in C, on a range of platforms. What's the big deal?

Re:That's the power of .NET

[Beliskner]

So this compiler lets you access Microsoft's proprietary .Net class libraries. A native code O'Caml compiler can access the hundreds of libraries written in C, on a range of platforms. What's the big deal?

You are correct. Micro$oft is constructing a Developers' Superstore - a familiar place where any developer of any language will go to code. Micro$oft is trying to achieve branding.

This is a tried and tested method, 50 years ago you went to the clothes store and bought some clothes, electrical store and bought some electricals, mechanical store and bought a washing machine, tool store and bought some tools.

Micro$oft is trying to construt a "Wal-Mart" that everybody goes to instead of all these disparate places. Not bad, appeals to beginners.

Right now a new developer says "I want to learn how to code" and you say, "Which platform? What type of program - textprocessing=Perl, compiler=Haskell, generalhighexecspeed=C++, generalhighdevelopmentspeed=Java, webdevelopment=PHP,J2EE,..." Micro$oft is trying to make it so that instead of all these disparate RPMs that confuse the heck out of newbie developers, you just use one IDE - Micro$oft's IDE, same as Wal-mart. The only difference (apart from the obvious) to a newbie will be that C++ has a compile button and Perl doesn't, his questions will become gradually more complicated after that. The weakness is that a bug in the CLR will affect all languages that use that functionality, you lose bug compartmentalisation and damage limitation.

Re:That's the power of .NET

[Zeinfeld]

the CLS runtime is a cheap knockoff of the JVM, take a look at the API and its obvious.

The CLR assembly code is based on the intermediate code from the Microsoft C++ compiler that existed several years before Java was made public. The byte code format of the Java VM and CLR are completely different. Java is a virtual machine and CLR is an intemediate code format of an object oriented compiler.

C# is essentially a wrapper for the CLS API.

Which is what you would expect from a modern programming language, remove all unnecessary inconsistencies you can.

C# does have features that no other mainstream programming environment has had since the Lisp machine. All managed objects can be querried to examine the metadata, the programmer can define attributes of their own to be included in the metadata.

What this means is that you can write a new data structure foo and then call XMLSerialize (foo) without having to do any more code. If you want to serialize to a specific schema you decorate the data structure definition with attributes. There is also a tool that does this for you.

The really cool thing about .NET for language developers however is that you get access to all the tools of a high quality programming environment without a lot of work. You get the debugger, the class browser, access to the .NET libraries, and the language sensitive editing.

Re:That's the power of .NET

[Beliskner]

Yes. But considering how many people still run unpatched IIs servers infected by Code Red.... Everybody with an unpatched zlib raise your hands ;-)

Actually to be fair the last time I saw an NT4 box without SP6 was... about a couple of years ago so there's a lot of variance. If every popular app install e.g. latest Macromedia automatically overwrites the old buggy CLR with the latest one (like MFC libs).... Wow, that could be good, very few Java app installers automatically overwrite old JVMs.

I foresee in 2 years people on /. bithcin' about Macromedia FlashPlayer v7 requiring a DRM-compliant CLR. Then in 20 years developers will become so lazy with drag-n-drop coding that every app uses CLR, then Windows XP^2 will only allow CLR apps to run and they'll deprecate the entire Win32 API. L33t Fortran, C and assembler coders will be 90 years old so nobody will be able to use "dangerous" ByteArrays.

Re:That's the power of .NET

[g4dget]

the CLS runtime is a cheap knockoff of the JVM,

The CLR is clearly a knockoff of the JVM, but it is not a "cheap knockoff". With the CLR, Microsoft fixes problems that Sun has promised to address years ago but failed to do anything about. I, for one, am tired of listening to Sun's unfulfilled promises.

Microsoft has finished screwing customers, and is on to screwing programmers.

I have no doubt that if you become a Microsoft customer, you will get screwed. But the open C#/CLR implementations (Mono, P.NET) look a lot more promising than the open Java implementations (gcj, Kaffe), in terms of completeness and conformance to a published specification (ECMA C#). And the reason for that is that Sun did not want the competition and Sun did not want an open, well-defined specification, while the existence of Java forced Microsoft to be more open than they usually would be.

Re:That's the power of .NET

[tshak]

the CLS runtime is a cheap knockoff of the JVM

I suggest you read a book like "Compiling for the .NET CLR" which is written by a computer scientist who has been working with Abstract Stack Machines for many years (the JVM included). A fool is thought to be wise when he keeps his mouth shut.

Re:That's the power of .NET

[RetroGeek]

the CLS runtime is a cheap knockoff of the JVM

And the JVM is a cheap knockoff of P-CODE.

"The intermediate code produced by the Pascal-P compiler." And this was in 1976.

Re:That's the power of .NET

[alext]

And the closed Java implementations on Linux and BSD are a lot more promising (as in production-ready) than Mono et al.

In fact, with alternative hardware platforms such as PPC and ARM diluting the hold of x86-based Linux, anyone now writing end-user Linux apps in something other than Java should pause to consider how accessible and maintainable their products will be.

I agree Java will certainly face a challenge from the Dotnet platform. F Sharp is a very clear warning signal to Sun, and it won't just be academics who want to move on from C++ and Simula 67.

Re:That's the power of .NET

[gaj]

In fact, with alternative hardware platforms such as PPC and ARM diluting the hold of x86-based Linux, anyone now writing end-user Linux apps in something other than Java should pause to consider how accessible and maintainable their products will be.

I make a living coding Java on Linux. Frankly, your statement is silly. First of all, JDKs on the "other" processors are well behind current x86 releases (ppc at 1.3.0, arm at 1.3.1, x86 at 1.4, for example). Second, having to deal with with what Java version is on the end user's machine leads to most of us distributing the JRE with our code. That means separate packages for each platform, and, given point one above, either limiting supported platforms or using an LCD java version.

Given those (and other) issues, I think I would seriously consider C or C++ with perhaps wxwindows as the GUI toolkit for future end user apps. Java's standard library is nice, but the performance, memory and distribution hassles are (or can be) a bitch. Of course, they are somewhat balanced by Java's nice (not perfect, but nice) standard library and the fact that Java the language is easy to build good code in. It has warts, yes, but nothing to compare to the disfigured freak that is C++. Back on the first hand again, C++ and C leave the door open for additional end user niceties because they aren't using up all the cycles and bytes just standing still (modulo coder skill, of course).

Not that I hate Java, mind you. Again, its standard library is pretty damn nice (not perfect, but what is?) and the language itself is, IMHO, better than C++ from an every day point of view. I just think that its hype factor is still too damn high.

Re:That's the power of .NET

[alext]

I make a living coding Java on Linux. Frankly, your statement is silly.

How can the point be silly if you've decided to code in Java? Or are your technical choices made at random?

Second, having to deal with with what Java version is on the end user's machine leads to most of us distributing the JRE with our code.

That's bizarre - most companies do precisely the opposite. For example, BEA provide a WebLogic install specific to Windows that does include a VM, because Windows is a relatively well-defined base, but for Linux, Solaris, HP-UX etc. they provide one without. This is because they realize that choosing a VM on these platforms is generally the job of a sys admin and not something that their product alone should dictate.

Given those (and other) issues, I think I would seriously consider C or C++ with perhaps wxwindows as the GUI toolkit for future end user apps.

I suspect that there's some hollow laughter from other /. developers at this point. Anybody proposing C++ with GUI libraries (not to mention STL, database and threading libraries) as a more portable platform than Java is seriously out of touch with reality.

Java's standard library is nice, but the performance, memory and distribution hassles are (or can be) a bitch.

Performance is good enough to run high-volume transactions behind innumerable web sites. It's also good enough for intensive GUI work (e.g. JBuilder). Memory demands don't seem to be a problem, after all, people are developing apps that can run on phones. 'Distribution hassles' presumably refers to the same self-inflicted 'problem' above.

Re:That's the power of .NET

[caca_phony]

Hi, this is me conspicuously not raising my hand regarding your zlib question, just trying to back up your point (I got the 0-day fixes through apt-get updgrade). I am actually kind of irritated by the way that programs for Windows so often come with hidden system upgrades. I guess after learning Linux first, it seems like a foo install should install foo, not foo, libbar libbaz and an out of date quuxlib to replace the newer one I already had.

Re:That's the power of .NET

[g4dget]

And the closed Java implementations on Linux and BSD are a lot more promising [...]

What do you mean by "all"? There is effectively only one closed Java implementation on any platform: the one from Sun; all others are derived from it in one way or another. Even legal issues aside, the Java platform simply isn't well-specified enough to have any interoperable, fully independent implementations.

In fact, with alternative hardware platforms such as PPC and ARM diluting the hold of x86-based Linux, anyone now writing end-user Linux apps in something other than Java should pause to consider how accessible and maintainable their products will be.

Anyone writing applications in Java (meaning, Sun's Java language and the Java2 APIs) for Linux should consider the folly of writing open source applications that depend on a proprietary runtime and set of libraries. Sun can pull the rug out from under open source Java efforts quickly by changing the licensing terms on their "standard" Java libraries.

And the closed Java implementations on Linux and BSD are a lot more promising (as in production-ready) than Mono et al.

The closed source implementation of Java is not really suitable for open source work on Linux unless you want to hand the keys to Linux to Sun. And you can guess what they would want to do with it.

The real choices for a Java-like open environment on Linux are the Java language with the JVM and non-standard libraries, or ECMA C# implementations, adding additional .NET features as needed. Neither choice is perfect, but ECMA C# is at least a well-defined target.

Re:That's the power of .NET

[alext]

In case it's not transparently obvious to everyone, I should point out that the above is complete FUD.

Anyone contemplating developing Java on Linux applications should read the following to set their mind at rest:

1. The list of already existing and completely open VM and class library ports at Kaffe.org. Sun can do nothing to restrict any of these clean-room developments, nor has it shown any sign of wishing to.

2. Sun's Community Source license. This explains the terms on which Sun's own code is shared. Note that this license has proven open enough for the Blackdown Linux port to be developed. Interestingly, the Blackdown group have listed what they would ideally want from Sun to keep their implementation fully compatible, and a "better definition" of the Java platform doesn't appear to be needed.

Attempts by Mono developers and other interested parties to discredit Java-on-Linux should be treated with great caution. Not only do they try to represent Sun and IBM as imposing more restrictions on open developments than Microsoft (presumably their status as actual open source contributors counts for nothing against the neutral and fair-dealing Redmond empire, well known for its 'embrace' of standards) but they deliberately misrepresent what parts of Dotnet are actually open and standardized. Any open app that uses a Dotnet GUI (Windows Forms or Web Forms) or database API (ADO.NET) is not using standard mechanisms - these APIs, and in fact over 1000 of the 1200 classes in Dotnet today, are entirely proprietary and are protected by patents.

Oh, and I didn't use the word "all" - et al translates as 'and others', a somewhat different meaning.

Re:That's the power of .NET

[elflord]

The Microsoft-dominated CLR is not really suitable for open source on Linux either - unless you want to make your software dependent on Microsoft's API - which may have "proprietary extensions" added at any time.

Again, there's mono. "Proprietary extensions" are not really a problem. Microsoft add "proprietary extensions" to C++ all the time, it doesn't stop me using C++ (I just ignore their extensions, and their C++ development tools ;-)

Re:That's the power of .NET

[g4dget]

The Microsoft-dominated CLR is not really suitable for open source on Linux either - unless you want to make your software dependent on Microsoft's API - which may have "proprietary extensions" added at any time.

Of course, Microsoft will extend the hell out of C#/CLR, just like Sun keeps adding APIs to Java. Both are trying to make their platforms so big and complex that they are unclonable and that they stay in complete control.

The difference is that for C#/CLR, we get an open, well-defined standard: ECMA C#. It defines a lot more APIs than standards for, say, C or C++. It's a good basis to start from. Furthermore, most people just won't care whether their Mono code runs with Microsoft's C# implementation or not--it just isn't relevant what Microsoft does.

As I said in my previous post, I don't know whether C#/CLR will work out for open source development. It may well not. Give it a year or two. What I do know is that Java definitely isn't working out: Sun has failed to follow through on most of their commitments, and technically, Java has failed to evolve much as well.

I'd trust Sun over Microsoft any day.

I consider it foolish to trust either company. What I trust is a standards process and an open source implementation of the standard with a well-defined license. ECMA C# has both.

Re:That's the power of .NET

[gaj]

I make a living coding Java on Linux. Frankly, your statement is silly.

How can the point be silly if you've decided to code in Java? Or are your technical choices made at random?

The original statement was silly regardless of what I code in. We originally chose Java because we build a cross-platform GUI based tool. In ther real world that brings us down to Java or C/C++ with GUI wrapper libraries. For technical, political and logistical reasons Java was chosen. Not random at all.

Second, having to deal with with what Java version is on the end user's machine leads to most of us distributing the JRE with our code.

That's bizarre - most companies do precisely the opposite. For example, BEA provide a WebLogic install specific to Windows that does include a VM, because Windows is a relatively well-defined base, but for Linux, Solaris, HP-UX etc. they provide one without. This is because they realize that choosing a VM on these platforms is generally the job of a sys admin and not something that their product alone should dictate.

Silly rabbit. You're thinking of the system JRE. Our install of the JRE is used by our program alone. We certainly don't touch the system JRE on any os, Windows or not. That would be stupid. As for "most companies" doing precisely the opposite, I thing a better phrasing would be "some companies". In fact, several of our OEMs either requested that we use our own JRE, or thought it was a good idea. I'm on the fence, myself, but this method has real advantages.

Given those (and other) issues, I think I would seriously consider C or C++ with perhaps wxwindows as the GUI toolkit for future end user apps.

I suspect that there's some hollow laughter from other /. developers at this point. Anybody proposing C++ with GUI libraries (not to mention STL, database and threading libraries) as a more portable platform than Java is seriously out of touch with reality.

Or not. See Mozilla, OpenOffice, Abyword, etc. More importandly, see many interal apps written using wxwindos or QT. As for STL; no one said it had to be used; in fact, I'm not not that big a fan of C++ in general, just pointing out that it would be no less a hassle than Java in some cases, and not much more in others. As for databse access, ODBC libs are there for C/C++; more importantly, the apps I write aren't db apps, so this is NaP. Threading? Pthreads is ugly, yes, but sufficiently portable. Java threading is much simpler, yes. This is major area where Java did improve upon it's parent's methods. As for my being out of touch with reality: guilty as charged, given your definition of reality.

Java's standard library is nice, but the performance, memory and distribution hassles are (or can be) a bitch.

Performance is good enough to run high-volume transactions behind innumerable web sites. It's also good enough for intensive GUI work (e.g. JBuilder). Memory demands don't seem to be a problem, after all, people are developing apps that can run on phones. 'Distribution hassles' presumably refers to the same self-inflicted 'problem' above.

Performance of long running apps where latency isn't a major issue is indeed acceptable. No point in being faster than you need to be, I suppose. As for holding up JBuilder an an icon of GUI usablility, it is a perfect example. I've not seen a pure Java app that is much better. Is it useable? Yes. But it still has annoying lags, even on a decent machine (say P4 1.5GHz, 1/2 GB RAM). You can build useable GUIs (I do), but only just barely, only with much tuning and only if the end user has a decent machine to run it on. As for you comments about memory, the Java that runs in phones (J2ME/MIDP) is not the Java used on workstations. The libraries are much different (especially the GUI classes: neither Swing nor AWT). Also, the memory handling is completely different (including a much simpler GC, one of the big reasons for memory use in J2SE). In short, that says nothing about J2SE (any implementation).

I stand by my original comments. I never said I wouldn't use Java, just that it is certainly not the no brainer, silver-bullet sollution for cross-platform development that the hype machine makes it out to be.

Re:That's the power of .NET

[ahde]

Smaller languages can really compete with popular languages...as long as they are c#

Re:That's the power of .NET

[ahde]

out of curiosity, since you're confident you've got them all, how many apps have a static zlib? I saw some preliminary lists when the advisories came out, but nothing definitive.

Why don't they use Smalltalk and stop F#$% around?

[crovira]

All this shit and more has been available for years in Smalltalk.

Support for .NET generics

[Jabes]

From the web page:

F# also happens to be the first released .NET language that is able to produce Generic IL, and the compiler was really designed with this target language in mind. However the compiler can also produce standard .NET binaries, which is just as well because there is no publicly available release of a .NET Common Language Runtime for .NET that supports generics.

So it looks like there are releases of Microsoft's jitter that have full support for execution-time expansion of generics. I can't wait!

Re:Why don't they use Smalltalk and stop F#$% arou

[dpbsmith]

Amen, brother.

I wouldn't mind it so much if someone would IMPROVE on Smalltalk, but why do we have to spend twenty years devising languages that are not quite as good as Smalltalk (in the name of efficiency, or compatibility, or ease of learning for people that have never learned more than one computer language...)

Smalltalk is the only language I've ever used that I felt truly extended my reach as a programmer and truly enabled me to do easily things that would have been difficult in other languages.

It is also the only language in which I have truly taken big, complicated, rich pieces of code that did ALMOST what I wanted and spent very small amounts of time subclassing them and making them do EXACTLY what I wanted--and without having to spend hours reverse-engineering and understanding what the original code was doing.

The power to lobotimize languages?

[SuperKendall]

Take a look here, at the comparison of F# to OCaml.

This is what I really dislike about .NET - the promise of multiple langauges, with the DELIVERY of multiple crippled langauges. If MS succeeds I can predict what will happen - the demise of almost any other interesting language, as developers are drawn in by the supposed "compatibility" of the C# libraries in thier favorite languages. But devoid of many interesting langauge features, combined with odd syntax for acccessing those wonderful Java, er, C# base libraries they wlll just drift to using C# (the ONLY language not neutered by the platform).

I think you are really a troll, but in any case you bring to light a common ignorance about the whole .NET platform that should be corrected whenever possible.

Re:The power to lobotimize languages?

[frleong]

This is what I really dislike about .NET - the promise of multiple langauges, with the DELIVERY of multiple crippled langauges

I don't know why you're calling me a troll (because I may seem to attack Java? But I like Java too and I actively program JSP and servlets at work!). But the point is that .NET allows these smaller languages to be put in commercial arena, which is good, because it promotes competition and may actually force the big ones to take some of the nicer features of these academic languages and everybody will benefit by then.

Re:The power to lobotimize languages?

[VP]

Maybe he called you a troll because you said:
Although there are other languages that can run on JVM, the ease of getting inheritance and cooperation to this level is only possible in .NET.

And if you had looked at the language description, you would have seen that F# lacks the following:

• Substructures/Namespaces/Packages
• Functors
• Inheritance (authoring)
• Structured classes
• Variance on type parameters
• Labels
• Default parameters
• "Printf" style formatting

Therefore your claim, that somehow getting parts of a language to run on .NET could be beneficial in some way, rings hollow...

Re:The power to lobotimize languages?

[SuperKendall]

I am truly sorry for calling the post a troll if it was not - I calculated it might be a troll not so much for attacking Java (indeed, it did not really do so at all) as seemingly being a bit too blindly supportive of .NET as a generic language platform.

In truth, I'm not aware of any language features that are that much more easily implemented on the .NET platform as opposed to the JVM - it even seems like both will be supporting Generics about the same time (the cynical among us would say .NET is waiting for the Java JSR to be finalized to see how Generics should be implemented in .NET!! ;-) )

I think the difference is that with .NET, Microsoft is strongly supporting multiple langauges on the platform while in Java, multiple langauges are fundimentially supported by the VM but not encouraged by tools - so while the JVM could have a multi-langauge develoipment tool, no-one has seen the benefit of doing so and thus none have been built.

While the mutli-langauge drive seems great at first, like I was saying I find it very disturbing that the same thing could happen to languages that has happened to OS's - we could enter a long dark period where the only real "language" you could program in is .NET, with only the ability to choose your favorite syntax (with your favorite syntax eventually and inevitably becoming C#). I like Java a lot but I also like to see work on other langauges (like Ruby) progress, and hate to see a movement to one unisex langauge.

Re:The power to lobotimize languages?

[frleong]

While the mutli-langauge drive seems great at first, like I was saying I find it very disturbing that the same thing could happen to languages that has happened to OS's - we could enter a long dark period where the only real "language" you could program in is .NET, with only the ability to choose your favorite syntax (with your favorite syntax eventually and inevitably becoming C#). I like Java a lot but I also like to see work on other langauges (like Ruby) progress, and hate to see a movement to one unisex langauge.

I see a different future scenario. Sure, the popular languages (C++, Java and presumably C#) will remain popular, but the lateral competition from these academic languages will more likely influence the future syntax of these popular languages. This benefits almost everybody in the end, i.e. users of these popular languages, I assume.

Re:The power to lobotimize languages?

[frleong]

In a way, I guess Generics could also provide the conterexample to your argument as well - look how long a very desired feature took to be included in the VM! What happens when more radical features cme along, will things ever be adopted by the "mainstream" langauges.

It took long because there was no competition. When Sun detected the forthcoming of .NET, it immediately jumped into concretizing ideas like generics. Marginal academic projects didn't have much influence before because many people wouldn't even bother to test them if they couldn't use the existing libraries to compare head-to-head language features (e.g. create the same application using different languages). Now that they can be brought forward, their influence will increase accordingly.

Re:The power to lobotimize languages?

[angel'o'sphere]

When Sun detected the forthcoming of .NET, it immediately jumped into concretizing ideas like generics.
How old is .NET? 2 years?
The sun integration path for generics exists since 1997. At that time the Pizza compiler was crafted by the team of Martin Oderski.

Marginal academic projects didn't have much influence before because many people wouldn't even bother to
This marginal academic project is now the foundation for Java with Generics. Java 1.5 will include generics and for Java 1.4 you can downlaod at sun a version including generics (JSR014).

However you are right if you like to say that generics should have been included from the start on.

angel'o'sphere

Re:The power to lobotimize languages?

[frleong]

How old is .NET? 2 years? The sun integration path for generics exists since 1997. At that time the Pizza compiler was crafted by the team of Martin Oderski.

Being in the path doesn't mean anything if nothing much else was done. It took them FIVE years, an eternity in the Internet age, to get only the technology in beta testing (when will JDK 1.5 be released?) Five years ago, dot com mania has not even started.

Re:The power to lobotimize languages?

[angel'o'sphere]

Sun crafted several frame works around Java, APIs and libraries.

No idea how compareable .NET is ... at least Java has now deep roots in all enterprise relevant software developments.

Well, FIVE years :-) .... the language was nearly stable over five years, the rescent assert introduction (faulty done IMHO) and templates soon (in about 12 month, you can download a eary birds version right now if you wish, search for JSR 014)
are the only mayor language enhancements.

Lets see what Microssoft is doing over the next five years and what OTOH SUN and teh Java Community will do.

angel'o'sphere

Re:MSFT public-relations apocalypse.

[matt_wilts]

>I can't believe a language named "F#" got past
> Microsoft's marketing department. Or are
> they retarded enough to think it won't get
>expanded to "F#@%"?

You think that's bad? As a non-programmer I expanded "F#/OCaml/ML" to "f*ck em all"...

To destroy languages is the power of .NET

[Baki]

Just compare any .NET language with the original, (C++ versus the real thing, F# versus ML etc). What you see is that any language, in order to achive interoperability at this level (including inheritance etc) and thus get access to .NET libraries, needs to be mutated into something different.

Only superficially all .NET languages are different, only superficially they are like their originals (syntax etc). In fact all .NET languages are structurally alike, only the syntax is somewhat different.

Therefore, should .NET succeed in the marketplace, it would be an enormous loss. The choice (of languages) is just fake. In fact it is total assimilation and destruction of variety.

I have nothing against the virtual machine idea (C# + CLR) which is 100% like Java + the JVM. That is a good principle which has its uses (just asking why not go with Java, C# merely adds some syntactic sugar but brings no true improvements such as templates or multiple inheritance). But this plan/strategy of so mutating all existing languages in all alike .NET variants is horrible.

Re:To destroy languages is the power of .NET

[g4dget]

Only superficially all .NET languages are different, only superficially they are like their originals (syntax etc).

F# is a language with type variables, type inference, and lexical closures. Those are real differences, not just syntax. I'd be overjoyed if, say, Java had support for them, but it doesn't.

(C# + CLR) which is 100% like Java + the JVM

No, C#/CLR are not "100% like" Java/JVM. C#/CLR is clearly based on Java/JVM, but Microsoft added a few features that make some difference. Among others, the CLR offers support for value types, pointer manipulation, and (experimentally) genericity. Those features do change the runtime significantly relative to the JVM (whether for better or for worse is a separate debate).

Re:To destroy languages is the power of .NET

[DickBreath]

C#/CLR is clearly based on Java/JVM, but Microsoft added a few features that make some difference. Among others, the CLR offers support for value types, pointer manipulation, and (experimentally) genericity.

You didn't mention an important one which is a big lack in JVM. That is: tail recursion. Does it have it?

Re:To destroy languages is the power of .NET

[redhog]

You probably mean tailö-recusion-optimization (that iss, that tail calls get optimized into jumps, that doesn't grow the stack).

It i not up to the JVM to implement or lack proper tail-recursion-optimization, but up to the java compiler. I know that a (standard compliant) Scheme compiler has been written targeting java bytecode. The Scheme standard requires proper tail-recursion-optimization.

Re:To destroy languages is the power of .NET

[Baki]

Java does not necessarily target its own windowing system. Via JNI one can bind any native window system you like (in fact IBM just did this with SWT in eclipse).

As a language, what does C# (or any .NET language for that mattre) add? None of them have multiple inheritance. C++.NET has templates, but that is also in the works for Java (not for C# as far as I know, but as soon as Java has it C# shall probably follow).

Yes, there are differences in licensing. But as we all know, CLR's openness is mostly cosmetic. Key to real usage of CLR shall be the standard class libraries, which are not open and only available on Windows. Really, this licensing issue is so weird. People keep complaining about Sun, where Sun has learned the hard way that they have to play it hard to avoid perversion of the Java standard as a platform neutral technology that runs everywhere.

Microsoft tried to subvert this, they almost succeeded; only after years of legal battle and sharpening of licensing rules Sun could avoid fragmentation and MSFTs usual 'embrace and extend' way. After MSFT saw they could not do this with Java, they even completely dropped it and came up with .NET.

In practice, Java runs on almost any platform around. In practice (even though CLR is supposedly open) .NET shall run only on Windows.

Re:To destroy languages is the power of .NET

[g4dget]

It i not up to the JVM to implement or lack proper tail-recursion-optimization, but up to the java compiler.

No, this is not true. TRO can happen whenever a method calls another method just before returning. But the JVM lacks the primitives for expressing this concept in general and it isn't guaranteed to perform the optimization automatically, either. When a Scheme compiler performs TRO on top of the JVM, it can't be using JVM method calls.

I know that a (standard compliant) Scheme compiler has been written targeting java bytecode. The Scheme standard requires proper tail-recursion-optimization.

Java is Turing equivalent, so you can implement any language on top of it (in the worst case, as a full interpreter). The real question for CLR/JVM is whether the optimization happens naturally when you map onto its built-in notion of functions. And for JVM, the answer appears to be "no".

Re:To destroy languages is the power of .NET

[DGolden]

The JVM (basically a neutered Forth VM) can't do proper-tail-recursion the "easy" way- it lacks the required stack manipulation primitives, according to some people they left them out for security reasons at the time of design.

The fully-rnrs-scheme-compliant scheme, SISC on the JVM uses the JVM heap, not stack, where most schemes on real processors would use the processor's real stacks, munging them for tail-recursion.

Re:To destroy languages is the power of .NET

[mark_lybarger]

In practice, Java runs on almost any platform around. In practice (even though CLR is supposedly open) .NET shall run only on Windows.

well said! though, it's not highly recommended (at least from my past expereience) to try running a weblogic java app server on a win 2K box, it is possible and does work.

Re:To destroy languages is the power of .NET

[evilpenguin]

I've been programming in C++ for, cripes, it must be ten years now and I've been doing Java on paying basis for three years. This is an honest and sincere question. Can anyone give me examples of where multiple inheritance is a) necessary, and b) superior to the Java trick of interfaces?

In my experience, multiple inheritance kills reuse, and is somtimes so overused that you get a complex, rootless graph of classes. I actually dislike multiple inheritance. Now, I freely admit that this could be product of ignorance of the the intelligent use of the feature.

By contrast, I genuinely like the Java system of interfaces. It adds a "works-like" or "can-do" semantic to the traditional object semantics of "is-a" and "has-a." In my experience, it is easier to keep clean and extend, and it doesn't really overcomplicate the class heirarchy.

Mind you, I've programmed in C for nearly 20 years, so it took a long time to really become an OO programmer instead of a C programmer who uses class libraries -- which is what I believe about 60% of C++ programmers really are. I think C++ took off because of the relatively easy transition from C, but I think all of my complaints about C++ come from the holdover baggage of C.

Things I dislike in C++
o "virtual" Sure, high efficiency, but can make for real confusion. "Which method got called?" I like Smalltalk and Java better on this.

o Multiple inheritance. I like interfaces. Please tell me why I'm wrong (the ony cure for ignorance is confession).

o Operator overloading (this is also something I like). Here my complaint is bad use of operator overloading. How am I supposed to know what it means to increment an Employee?

o Memory management. Being an old C and later C++ man I was highly dubious about Java's garbage collection model. One month of Java and I totally changed my tune. An entire class of bugs simply disappears. With Java "It compiles, therefore it works" became almost true. Never in C++.

o Pointers and instances. I don't like (and its just for cleanliness reasons -- not on principle) that you can instantiate an object both by declaration and allocation. In practice, I've ended up using object pointers all the time. When I mix object pointers (read references) and declared objects I end up confusing programmers who must maintain my code in the future. (Should "payment" be deleted or just go out of scope?)

o No root class. In Smalltalk and Java you get many advantages from having a root class that at some point every other class inherits from. In fact, it gets rid of many of the cases where templates are required in C++ (but not all -- I do like templates!)

Things I really like about C++:

o Templates. You can't beat 'em.

o Operator overloading. When you use it well, it's nice. One bit of code I wrote a long time ago that I use over and over again is a file-backed array class. Overload the subcript operator and your go right to line "n" of a text file. It works so well I haven't had to change a bit of code in it in five years.

o Speed. Java sucks on speed. It just does.

o Destructors. I really miss destructors in Java. Even though I consider it a small price to pay for losing the memory management/pointer bugs that are so easy to make in C/C++, it is nice (REALLY nice) to have a method that is ALWAYS called when the object is destroyed (no longer used), as opposed to when it happens to get garbage collected. This is especially noticed when dealing with resources outside of the language, like DB connections and sockets to external services. Sure, you code around this, but a destructor is really nice.

So, set me straight!

(No holy war intended here -- I love almost all the languages I've programmed in for one reason or another. They all have their uses.)

Re:To destroy languages is the power of .NET

[angel'o'sphere]

You didn't mention an important one which is a big lack in JVM. That is: tail recursion. Does it have it?

Tail Recursion is not the issue of a VM; be it CLR or JVM. Its a issue of the language.

Java supports recursion, like all modern languages except perhaps some BASICSs.

Do you perhaps mean tail recursion elimination? Thats an optimization which is done by the compiler.

Elimination of recursion, tail recirsion or others is hard in late bound invocations. In Java its only easy doable for static or final methods.

angel'o'sphere

Re:To destroy languages is the power of .NET

[angel'o'sphere]

The JVM (basically a neutered Forth VM) can't do proper-tail-recursion the "easy" way- it lacks the required stack manipulation primitives, according to some people they left them out for security reasons at the time of design


Can you explain that deeper or provide a link to a paper?

I learned Tail Recursion Elimination is done by unrolling a recursive call into a loop.

fib(int n) {
if (n == 0) return 1;
if (n == 1) return 1;
return n * fib(n-1); // tail of fuction fib-n
// and a call to fib-n-1
}

fib_loop(int n) {
if (n == 0) return 1;
if (n == 1) return 1; // end of loop!
int res = 1; // known from loop end
for (int i = n; i > 0; i--) {
res *= i;
}
return res;
}

This is PURE HIGH LEVEL language code, and tail recursion elimination is applied! This has nothing to do with the underlying virtual machine, IMHO.

angel'o'sphere

Re:To destroy languages is the power of .NET

[curri]

A few things (this is not a flame, your ideas seem reasonable enough :)

1. virtual In java (If I understand correctly) EVERY method is virtual. So you may not like the idea of non-virtual methods. They are there for performance. You can, of course, just declare all your methods virtual :)

2. Multiple inheritance is a more powerful mechanism, compared with interfaces. If you use pure-virtual classses, it can be equivalent to interfaces (although you can still attach some code), but it can do more.

The standard example is when you have 2 separate class hierarchies (sp?), and need to have a class that belongs to both. Say you have a GUI framework, and a persistence framework and want a persistent window :)

IF you had the code for both frameworks, you could probably change some things for interfaces.

My problem with interfaces is that they only pass type info, but no code; they make for a cleaner mechanism, but if you actually need to get code from 2 different classes you're screwed.

It may just be philosophical differences; I like the philosophy behind C++ (the programmer knows what (s)he wants to do, it's not the language's problem if they don't), and felt Java as taking things away because they're dangerous :)

3. Pointers/memory management It is nice to have garbage collection, and memory issues in C++ get to be more complicated. But you get more flexibility, performance and destructors :)

It's not that hard to mix pointers and instances most of the times. You would never delete an instance, of course, and very few times take the address of an instance (there are references in C++ now; it's not C). Also, you can use auto_ptr and all those goodies.

Re:To destroy languages is the power of .NET

[bentini]

That's not tail-recursion elimination. That's transforming recursion into iteration.

Also, your test if(n == 1) return 1 is unnecessary. As are both tests in the second version of the code. Tail recursion elimination still recurs, it just doesn't use any more stack space.

As a test, try to make mutually recursive tail recursive calls optimized. E.G., even and odd, where even returns 1 if n == 0, odd(n-1) otherwise, and odd returns !even(n-1).

-Dan

Re:To destroy languages is the power of .NET

[evilpenguin]

Yeah, I know (and agree with) everything you are saying, but you haven't made a compelling case for me. I would never want C++ to go away, but the number of situations in which I would use it has gone way, way down.

I actually wish Java wasn't so focused on the VM concept, which is nice, but I would rather have true native code compilers for Java that produced solid, fast code. My biggest gripes with Java are the slow VMs and outright bugs in the VM that cause lock-ups and runaway resource consumption in production cases.

Separate rant: Sun should just GPL the whole JVM and JDK. I've had problems in production Java systems that I *know* are in the implementation of the VM itself, and there is NOTHING I ca do about it. When you write in C++, you can generate assembly source and you can see every byte of code your application executes (okay, maybe not the libraries -- which is why I use gcc, then I can if I want to). In Java, you've got a black box VM that you have no idea about. Most of the time that's fine, but if there is something broken in the VM, too bad. You're on your own.

I guess it all boils down to there is no One True Language, One True Platform, or One True Operating System (or even One True License). It is all about freedom of choice.

Re:Will there be.....?

[Chris Pimlott]

I vote for S^ instead... 'shat'

Remember April 1st?

[WildBeast]

Did you remember when Slashdot said that they'll post articles about there sponsors products? Well here's the result.

I'm not anti-MS by any means but even I can notice that this F# have very limited appeal. Posting an article about it, is very suspicious.

Comment removed

[account_deleted]

Comment removed based on user account deletion

good job on the generic implementation, but...

[g4dget]

Looks like they did a good job on the generics support in their runtime. In particular, unlike batch C++ compilers, they delay generation of specialized code until it's needed. That gives you the efficiency of C++ (no boxing, for example) without the bloat. This is what Sun should have done. Instead, Java has a half-baked and not type-safe genericity hack. Even the more complex proposals for Java genericity have been more limited in comparison.

Let's just hope that the specification and implementation strategy for .NET genericity will be open. While there doesn't seem to be anything terribly sophisticated or novel in it, Microsoft could conceivably have applied for a bunch of patents and may try to keep efforts like the Mono project from implementing this.

As for F# itself, it seems to be a closed-source distribution only, which makes it uninteresting except as a technology demonstration. Microsoft almost certainly has no intention of supporting it commercially, making it effectively an orphaned, single-platform, non-evolving system. Even if it were a commercial product, lack of an open source distribution would make the chances of its adoption nearly zero.

Re:Why don't they use Smalltalk and stop F#$% arou

[g4dget]

No, "all this shit" has not been around in Smalltalk. OCAML incorporates a lot of ideas and technologies developed in the 1980's and 1990's, after Smalltalk was designed. Whether you need the extra power of OCAML or whether it gets in your way is a separate question, but OCAML is not a subset of Smalltalk and Smalltalk is not the be-all-and-end-all of all ideas in programming.

Pay more for a brand name of asprin

[3seas]

That's what this is about, Branding!!!

I'm not interested in it. In fact I'm less then zero interested in it, as the generic brand contains the same ingredients and cost a whole hell of a lot less.

For those stuck on words used. Microsoft is a brand name. GNU, FSF, GPL is the generic indicator, organization of establishing the generic and the licensing of the generic that insures it stays that way.

Re:Pay more for a brand name of asprin

[3seas]

I should add that I'm so tired of Microsofts abstraction manipulations, or lies and manipulations of the meaning of words, etc...

It's like the boy who cried wolf. At some point it just becomes more productive to simple ignore them and their distortion. While focusing on that which is without alot of crying wolf.

Remember that developer use of .net is constrained to non-GLP work.

Re:MSFT public-relations apocalypse.

[mughi]

>I can't believe a language named "F#" got past
> Microsoft's marketing department. Or are
> they retarded enough to think it won't get
>expanded to "F#@%"?

You think that's bad? As a non-programmer I
expanded "F#/OCaml/ML" to "f*ck em all"...

Or.... for the paranoid out there... perhaps with the federal prosecution being dropped and everything else, this is MS's statement directly to programmers:
"Programmers??? F#/OCaml/ML"

Languages - an art form

[ndogg]

I see a few people complaining that there is "yet another language to learn."

They ask, "Why bother creating another language? There is quite a number of them out there. Any of them should be able to solve almost any problem out there."

Programming languages are an art form, and like any other art form, it deserves respect. Each programming language forces a programmer to think about a problem in a slightly different manner. Prolog forces a programmer to think in terms of goals to be achieved, and OO languages force a programmer to think in terms of self contained parts of the problem. Different programming languages make it easier to solve different types of problems. Haskell is a great language to represent infinite sequences due to its use of lazy evaluation.

Would you tell a musician to not experiment with sounds not created by traditional instruments because there are so many musical instruments out there for him/her to use, and that any musical piece can be performed with any of them? Musicians come up with new sounds all the time because those new sounds allow them to view music from another perspective

Compromise for interoperability is not destruction

[Carnage4Life]

Just compare any .NET language with the original, (C++ versus the real thing, F# versus ML etc). What you see is that any language, in order to achive interoperability at this level (including inheritance etc) and thus get access to .NET libraries, needs to be mutated into something different.

Agreed, this is true of any mechanism that allows interoperability. Java does not allow one to effectively utilize benefits of the target platform so that it is interoperable across operating systems. Many would claim that this is a good thing. SOAP and web services are making people similarly compromise to enable building distributed applications something that is accessible to the average developer. Again this is widely considered A Good Thing

Compromise for the sake of interoperability is something that is done all the time. The question typically is whether the amount of compromise is worth the benefits of interoperability.

Only superficially all .NET languages are different, only superficially they are like their originals (syntax etc). In fact all .NET languages are structurally alike, only the syntax is somewhat different.

I'm not sure what you mean by structurally alike but I'll hazard a guess and assume that you meant they are semantically alike. So far I have used 4 .NET languages to program; C#, JScript.NET, VB.NET, and Managed C++. Being skeptic I originally assumed that .NET Framework would simply be creating skinnable languages where the syntax may be different but the underlying semantics are mostly unchanged which in fact many claim is the case for VB.NET and C#.

However, the more I used the languages the more I realized that although some similarities existed the core of the languages from my past; JScript and C++ was still in their .NET versions. I can still declare vars in JScript and best of all in managed C++ I get all my favorite C++ constructs (STL, the 4 casts, templates, etc) but can combine them "managed code" to get the benefits of .NET.

Now there are certain compromises such as the fact that the CLR only supports single inheritance (which I believe some research language discussed a while ago on Slashdot found a workaround for) but in my opinion this is a small price to pay to be able to access my C++ objects from VB.NET or my C# objects from JScript.NET. I consider even better that there is one unified class library that I can count on across all the languages besides the language specific ones like the STL or the JScript function library.

Disclaimer: I work for Microsoft but the thoughts expressed in this post are my opinion and do not reflect the opinions, intentions, plans or strategies of my employer

A terrible loss

[Bodrius]

It could have been called ML#, or M# if you really need the one letter thing. But now by calling it F# they have inflicted terrible damage on the community.

Sure, it's F-unctional/imperative, but there are other Functional/imperative languages, how come they got the priviledge on the F? It's a non-intuitive choice for something based on ML, and it takes over the F...

How many headlines in SatireWire et al could have been based on that F#? How many inside jokes, idiomatic expressions? An important piece of the .Net culture has been removed before it had time to blossom.

Can you use "this F# S# is not compiling!" anymore? No, because it might not be implemented in F# and would confuse your co-workers, who would have otherwise understood your feelings exactly. We will see, ad nauseam, co-workers mocking poor F# developers with jokes that, in the pretense of sophistication ,will get old very quickly: "so, I hear you're using that F# language? Am I going to have to read that F# S# when you're done? I hated debugging that when I was in college, my prof was a F# A#".

Confusion in the workplace will stifle any creative idiomatic use of F#, nagging by co-workers with repetitive jokes will stifle any creative alrogithmic use. F# will die and will kill the F# with it.

Saying just "piece of S#!" is not the same. And how long before even that is removed, when they implement Smalltalk in .NET? What's next, A# for Algol?

Why, Microsoft, why?!

Re:Why don't they use Smalltalk and stop F#$% arou

[alext]

Yeah, he probably meant to say LISP :-)

Anyhow, there are plenty of better candidates for 'redundant language' to pick on (XML and its myriad of ways to computational completeness, Python, Javascript...)

Re:Why don't they use Smalltalk and stop F#$% arou

[entrox]

That's not the point. I totally agree with what the parent poster said (just replace every occurance of "Smalltalk" with "Common Lisp" for my case).
Why do people have to reinvent the wheel a thousand times, but never succeeding in making it truly round? WHAT advantage has Ruby over Common Lisp or Smalltalk? WHY did it have to be made? What, as a language, can it do that Smalltalk or Common Lisp can't? It's a waste of time, really.

E#

[mlinksva]

F# looks cool, I've been meaning to learn O'Caml for awhile. But I really want to see E#.

Re:Compromise for interoperability is not destruct

[Baki]

I think the integration is too fine grained to implement really different languages, such as
- not-OO at all (but purely functional or logical languages)
- languages like ADA or OCCAM that have completely different parallelism paradigmas

I prefer more loose integration, where different languages/environments can implement truely different paradigmas. Then you integrate for example by:
- building a 'bridge' in the C, the de-facto glue language (JAVA has JNI, almost any language has some kind of interface to C
- more coarse component mechanisms such as Corba (or COM or web services if you like)

In more specialized environments (that thus are impossible to integrate at the fine level as .NET does) you can have more effective solutions for particular application domains.

Re:Grow up. Please.

[Phroggy]

Read site description. Originally, this was News for nerds. Stuff that matters.. It only picked up the ridiculously anti-MS slant after it was bought by VALinux.

Slashdot is a bit less pro-Debian than it once was, perhaps, but it's always been pro-Linux and anti-Microsoft. Your user ID doesn't suggest that you've been around long enough to know, though.

Too long

[ajs]

I'm getting sick of these long names like Coctothorpe and Foctothorpe. Can't we just go back to "C", "Perl" and exorbitantly long, "Pascal"?

FUD

[Hard_Code]

Well, I am a fulltime middleware Java programmer, and have no particular love for MS, but your post is mostly FUD. Microsoft is not trying to ingratiate themselves to *US*, the Slashdot crowd (duh!) - they are trying to jump off their legacy languages (VB, C++) into a J2EE-like world (which Java has had for years now), and to this goal, .NET/CLR is a pretty damn good architecture. The things which it *does* have over Java which are actually nice, is, for example, optional "unsafe" keywords for native integration, and auto-boxing (which Sun has now planned to introduce to Java in 1.5). .NET is a great platform for current Microsoft developers to migrate to a web-services/J2EE-like world, and it does a damn good job at it. I know if I was an MS developer I sure would rather develop in .NET/CLR/C# than the crap that they currently have to deal with (VB/C++/MFC/ActiveX/COM+).

.NET is a good architecture for what it is designed for. That doesn't mean MS is not still going to try to do something evil with it, but it is plainly dishonest to spew FUD like that against it. Read the spec before bitching.

Agreed, language designers != VM designers

[Ars-Fartsica]

.Net is not the only game in town for standardizing a virtual machine. The Parrot project, which is associated with Perl 6, is working towards a highly performant (pseudo)register-based VM that will be available as a separate codebase should other language builders wish to use it.

This makes sense - it is wasteful and time consuming for disparate teams to reinvent the VM.

Now before getting on your high horse about these unique VMs exposing some key element that the others omit - just remember, every language is ultimately a wrapper/macro/syntax rewrite of your CPUs intruction set. Raising the level of assumption to the VM level is realistic.

Now admittedly Parrot does not encapsulate a lot of the features in .Net (security, data abstraction, object pooling...etc etc), but its a step in the right direct.

Don't underestimate .Net - it makes sense.

SmallTalk is dead, get over it

[Ars-Fartsica]

There were a few stragglers still cranking around in SmallTalk a few years back, but at this point the prospects for this language having a real imapct is zilch. Throw it up on the scrap heap with Lisp and the other dead way-cool languages.

Re:SmallTalk is dead, get over it

[dvdeug]

There were a few stragglers still cranking around in SmallTalk a few years back

You mean like IBM? Last time I heard, VisualAge's IDE (and probably more) was written in Smalltalk.

but at this point the prospects for this language having a real imapct is zilch.

You mean, besides the impact it has already had? Smalltalk's OO strongly influenced how Java's OO was set up, among other things.

Throw it up on the scrap heap with Lisp and the other dead way-cool languages.

Um, Lisp? You know, the language that drives Sawfish and Emacs? It's hardly dead.

What is it with people's desire to throw away all languages but a couple of the cool new ones? A compiler doesn't stop working because some one comes up with a new language; and a large part of the reason these languages die is because people go "does anyone use that language anymore" and use something different, whether or not there's actually support for the language, or whether or not it would be the best language for the job, or whether or not you would enjoy writing it in that language most. Guess what; there are good compilers for Ada and Lisp and O'Caml and Smalltalk on Linux and all major platforms, and besides the libraries which do exists, all those languages may interfacing C from them easy. If you feel like it would be easiest to use them, or it would produce the best code, use them! Maybe it will provoke a renassiance in the language; or maybe it will just get the job done well in an enjoyable fashion.

Wrong, they are tools, not pieces of art

[Ars-Fartsica]

The languages that succeed are those that solve a particular problem well in a particular domain, with extra points for being easy to learn and extra extra points for being used by the most people (network effects).

Re:Compromise for interoperability is not destruct

[HiThere]

Eiffel# is a chopped down version of Eiffel, though the only thing that I really know is missing is the multiple inheritance. Unfortunately, that is so central to the core of Eiffel that I don't see how it could be considered the same language. More like Java with pre- and post-conditions. (It *may* include the equivalent of Java interfaces. I wasn't interested enough to look.)

Other languages may be less severely chopped. E.g., C++ doesn't use multiple inheritance very much, and a version of interfaces would probably be a adequate substitute. And Ruby and Smalltalk don't use multiple inheritance at all. I'm not really sure where Common Lisp falls. The importation of modules isn't the same as multiple inheritance, but it does have similarities.

If you want to look at the possibilities, check out the page "Languages for the Java VM" (sorry, I don't have the URL right to hand).

A virtual machine is really just a high level assembler language. You can probably do anything with it, but some things will be more expensive than others. And these won't necessarily be the same things that are implied by the underlying hardware.

I've got all day

[flacco]

F#UCKING C#UNTS, I say.

doo bee doo bee doo bee doo bee doo bee doo bee doo bee doo bee

Re:Compromise for interoperability is not destruct

[Malcontent]

Is it legal to use .NET to write GPLed applicatons? I heard that the license restricts the right of the programmer to choose how they wish the license their code. If this is the case (let me know if it's not) then any benefits the .NET platform may offer are useless.

Re:Why don't they use Smalltalk and stop F#$% arou

[elflord]

Why do people have to reinvent the wheel a thousand times, but never succeeding in making it truly round? WHAT advantage has Ruby over Common Lisp or Smalltalk?

Comparing ruby to common lisp doesn't make a whole lot of sense, they're substantially different beasts. Can you write GUI applications in common Lisp ? (and would you want to ?) Ruby has more of an OO bias, while Common Lisp has a functional bias (though both are multi-paradigm).

As for comparing it to smalltalk, IMO the main advantage Ruby has is that it's better at interoperating with the rest of the system. Smalltalk is great in a hypothetical universe where everyone programs in SmallTalk, but unfortunately, the real world doesn't work like that.

It's not a question of "what (x) can do that (y) can't". You can do everything in assembly language , however, you may find some tools more convenient.

you are confused

[g4dget]

The list of already existing and completely open VM and class library ports at Kaffe.org

So? Kaffe is not an implementation of the Java platform. It is a VM with a bunch of classes that conforms to nothing in particular. In fact, as far as VMs go, there are better open source VMs out there; Intel's ORP, for example, beats Sun's JVM on many benchmarks. But a VM is not an implementation of the Java platform, it is only a tiny component.

Sun's Community Source license [sun.com]. This explains the terms on which Sun's own code is shared. Note that this license has proven open enough for the Blackdown Linux [blackdown.org] port to be developed.

I suggest you actually read the SCL some time. You will see that Sun retains all the important rights. Of course, they let Blackdown do a port for now. If Java on Linux stops suiting Sun, they can shut down the effort easily.

Attempts by Mono developers and other interested parties to discredit Java-on-Linux should be treated with great caution. Not only do they try to represent Sun and IBM as imposing more restrictions on open developments than Microsoft

I made no such claims; you are arguing a straw man.

Any open app that uses a Dotnet GUI (Windows Forms or Web Forms) or database API (ADO.NET) is not using standard mechanisms

So? And your point is what? With ECMA C#, we at least get a set of standard libraries that is considerably more complete than what other language standards (e.g., C, C++, CommonLisp) offer. There is nothing comparable for Java. For Java, we only get Sun's proprietary documentation and a bunch of books.

these APIs, and in fact over 1000 of the 1200 classes in Dotnet today, are entirely proprietary and are protected by patents.

Can you back up those claims with some facts?

Anyone contemplating developing Java on Linux applications should read the following to set their mind at rest:

I think anybody following your advice is a fool. When choosing a language and environment for open source development, we need binding commitments that it remains open and a well-defined language and library standard. ECMA C# represents such a binding commitment and standard. There is nothing equivalent for even the smallest part of Java.

I used to think Java could fill the niche of a next generation application development language on Linux. But Sun has backed out of all commitments and is instead pushing "community" processes in which they retain the ultimate control over large parts of the Java platform.

Maybe the open source C#/CLR efforts won't work out. Maybe Microsoft has some devious master plan and a bunch of aces up their sleeve. But whatever the situation with C#/CLR, I'm convinced that Java is not the answer. If you don't trust the open source C#/CLR efforts, my recommendation would be to stick with C/C++ for the time being, or use one of the many other open source languages.

Re:Compromise for interoperability is not destruct

[Malcontent]

You know just when I think MS has hit the bottom of the slime bucket they do something to show me that there is no bottom of the MS slime pit. I can think of no other company who puts such restrictions on the usage of their IDEs of platforms.

This is not really fair...

[Tom7]

F# is not crippled. It's just missing the module constructs of O'Caml, which as far as I know should not cause any problem to be implemented -- they just aren't yet.

SML.NET, which I think works (though I haven't checked) apparently implements all of SML, including its module language. SML's module language is even cooler than O'caml's, too.

Re:Why don't they use Smalltalk and stop F#$% arou

[psaltes]

Well, this is not the sort of response I had expected. My post was quite honest in that I really thought the parent poster might actually like Ruby, given what they said, and I was suggesting it because odds are, they didn't know about it.

Perhaps, in the event that you read this response, you should read this article
and perhaps be enlightened (or not).

I use ruby because I like it, simple as that. I've used a bunch of other languages, not common lisp, but scheme, ML, and a little bit of smalltalk (among others). And it just happened that ruby has won out at this point, possibly to be replaced by liking some other language (though probably not common lisp or smalltalk) some day.

Anyone seriously thinking about the concept of reinventing the wheel should note the dramatic differences between the wheel that goes on the bottom of a 747, and the wheel used on a wagon 4000 years ago. Though it does seem like what you are asking is more like 'why doesn't everyone use common lisp, because it is the best language ever!' than actually 'why do people reinvent the wheel?'

And posting on slashdot is much more of a waste of time than writing a language.

Re:MSFT public-relations apocalypse.

[Decimal]

I can't believe a language named "F#" got past Microsoft's marketing department. Or are they retarded enough to think it won't get expanded to "F#@%"?/i.

Eventually, Microsoft will release a simplified version of F#. They could call it BrainF#.

References?

[crisco]

Do you have references for this? I'm sorry, I just can't believe this without corroborating material. There are too many GPL projects that compile under Visual Studio for this to have never been mentioned on /. before.

Re:References?

[crisco]

OK, I missed your earlier reply that linked to some discussion regarding this. The best comments are this and which seem to leave quite a bit of abiguity regarding the whole issue. I don't think that you can make the blanket statement that they prohibit the GPL, I believe that rather the license raises some issues WRT the GPL and the issue needs further clarification, unfortunately, given Microsoft's attitude toward the GPL, clarification may have to be at the end of a court battle.

Re:To destroy languages is the power of .NET QWZX

[Patrik Nordebo]

Available for the JVM: Scheme, Basic, Logo, Prolog, Smalltalk, COBOL, Ada 95, Python, Ruby, Forth, Pascal, Modula-2, Oberon-2. To mention a few. There are many, many more, but these are the more well-known ones I could find easily and quickly. Some of them may be brain damaged, but I suspect most of them aren't.

Besides, F-Pound is the proper pronunciation.

[bill_mcgonigle]

The # symbol, is the pound or number symbol. Notice how the vertical lines slant to the right. The Sharp symbol has true verticals, with slanted horizontals. Different symbol. Go check out a Unicode chart, there's a symbol for Sharp, and it's different than the symbol for Pound.

F#?

[Syberghost]

When I first saw the name, I figured it was a new Fortran from Microsoft...

FUD alert

[Anonymous Brave Guy]

Under the Visual Studio.NET eula you are not allowed to write GPL software...

Please stop spreading this garbage around. I've seen this claim made several times in the past month, but it still doesn't seem to be true for any VS EULA I've ever read. What you can't do is incorporate the redistributables into anything free/open source/GPL/etc. IOWs, you can't write your open source rival to MS' products using MFC, and then distribute all the MFC DLLs with it, for example. Nor can you give away the source code to MS libraries for free, even if you have that source code because you bought VS.

They can hardly stop me using their editor to write source code as a plain text file, though. (Although they can stop me shipping the version compiled with VC++'s default start-up code, since that is going to link stuff that I'm not allowed to redistribute under the EULA, of course.)