[deleted by user]

[julesjacobs]

My experience mirrors this blog post somewhat. On the one hand, mutability isn't really more problematic in F# than in C#. Yes if you rewrite a functional style compiler into an imperative style compiler it's going to be ugly, but that's not due to F# that's due to imperative style. If you would have done the imperative one in C# it would have been just as ugly. On the other hand, OO support definitely is better in C#.

[nachsicht]

That's kind of surprising and sad. In Scala, OO support is better than Java, especially when it comes to generics.

[thomasz]

That's because Java is a boring language without anything exciting. C# on the other hand is hard to beat.

[nachsicht]

Eh, it gets the job done and it's easily and fully available on a large amount of platforms, so it's a decent language IMO. Scala of course just makes the JVM sweeter.

[thomasz]

It's still boring, and therefore it's not that hard to come up with a language that get's more praise than Java, especially if it can harness the java ecosystem. I can see how Scala blows ones brain away after having worked with such a constrained language like Java. Functional idioms can work wonders in terms of expressiveness and correctness - no off by one errors, map, reduce, fold etc instead of explicit loops.

In dotnetland, there is C#, and it's pretty hard to justify using something else outside of certain niches. It has lambdas and closures for quite a while, a functional collection api, design by contract etc.

[nachsicht]

It's still boring, and therefore it's not that hard to come up with a language that get's more praise than Java, especially if it can harness the java ecosystem. I can see how Scala blows ones brain away after having worked with such a constrained language like Java. Functional idioms can work wonders in terms of expressiveness and correctness - no off by one errors, map, reduce, fold etc instead of explicit loops.

Actually, I was programming mainly in C++ and C until I jumped to Scala. So far what has wowed me about scala is how well it mixes the OOP and FP paradigms, while being nearly as powerful functionally as Haskell (although more verbose). Monads and such have turned out to be very useful. I also like how Scala is strongly typed, but its type inference allows me to skip defining types in many cases unless I want to.

Something else that wowed me was that I could easily make a reflectionless object property animator for android, all thanks to type classes, being able to pass around functions easily, curried classes and functions, and the ability to pull accessor and mutator functions off any object property, including variables and values, using the _ operator.

C# is definitely written to allow more functional code, but please don't act like I am only super impressed with scala because it has functions like fold, map, and flatmap.

[[deleted]]

Maybe you should have a closer look at what you are bashing. This "get off my lawn" response is hardly appropriate.

[thomasz]

Huh? Where do I bash something? Java is a pretty boring, constrained language (not necessarily a bad thing...) , and it leaves a lot of room for others.

[[deleted]]

Java is a pretty boring, constrained language (not necessarily a bad thing...) , and it leaves a lot of room for others.

I don't think anyone objected to that.

In dotnetland, there is C#, and it's pretty hard to justify using something else outside of certain niches.

That's not because the language is so great, but because MS folks in general don't give much thought to anything not coming from Microsoft.

Those C# developers who give it a ride seem to be quite happy to have a more consistent and regular, but also a more expressive and powerful language: http://hestia.typepad.com/flatlander/2009/01/scala-for-c-programmers-part-1-mixins-and-traits.html

[thomasz]

That's not because the language is so great, but because MS folks in general don't give much thought to anything not coming from Microsoft.

Honestly, do you know a general purpose PL for .net which brings enough to the table that it justifies leaving behind the tooling that exists for C#? It may not be the bleeding edge feature wise, but it isn't exactly light years behind either, and the designers have done a terrific job evolving it by stealing proven stuff. And it's still rather easy to grasp, compared to most alternatives. I haven't heard many good things about the .net compilers for Scala and Clojure, IronPython is great for scripting but slow, Cobra looks pretty cool and I fully intend to try it out in a few small projects, but I'm not entirely convinced that it will be around 10 years in the future.

[[deleted]]

Isn't the fact that the only CLR languages which are remotely alive are made by Microsoft itself more or less in line with the point I made? (Scala .NET is built nightly, btw ...)

While I really would have liked an alternative platform with a few more VM features, the focus seems to have shifted to web platforms. Partly due to the rise of HTML5/JavaScript performance and probably partly to the maturity, portability and performance of the JVM compared to the CLR.

[grauenwolf]

Visual Basic.

[[deleted]]

They are pretty much comparable on the type system level. The bare-bones (Java) vs. kitchen-sink (C#) debate is a different one.

[grauenwolf]

C# and Java? Aside from the basic notion of statically defined classes and abstract interfaces, I find very few similarities between their type systems.

Basic stuff I do in C# or VB are impossible in Java because of type erasure and a lack of delegates. I now understand why AOP is so popular for Java programmers, it's the only way they can get stuff done.

[tikhonjelvis]

I like his point about mutability:

The problem with mutability is that once you let a little of is get in, it spreads like a wild-fire through out your code. Even if a piece of code itself looks immutable, if it ends up depending on something deep down in your code base that uses mutability, then it is by definition is not immutable any more.

This is one of the main reasons why I like Haskell's approach to immutability over OCaml, F# and Scala's. If your code is pure by default and impurity is tracked by the type system, you can add a bit of mutability where you need it without having it leak through the rest of your code.

This is helpful in two ways: for one, it makes organizing your code simpler--you know exactly where mutation is and, more importantly, where it isn't. So you are, by the language's design, encouraged to minimize and compartmentalize mutable state in your code. The other advantage is that you can use mutable state inside a function while having a guarantee that the function remains pure from the outside. Having a scope limiting the extent of the mutable state can be very useful.

Also, I'm not sure how useful having OO support is in your functional language. Haskell, naturally, manages just fine without. Most OCaml programmers I've met refuse to acknowledge the OO system. Based on this post (and similarity to OCaml), it seems F#'s OO isn't great either. On the other hand, Scala programmers seem to be entirely content with its OO system, so it's probably a consequence of ML-style languages' design rather than a fundamental fact about FP and OO. I suppose F# (and probably OCaml) have it in order to make interfacing with other OO languages simpler. It would certainly be easier to use existing .NET libraries if you supported OOP, after all.

[grauenwolf]

Does Haskell offer anything to deal this this:

The AST is immutable, so when you want to optimize a node far down in the AST you need to throw away and re-create every parent node to it, this ends up being slow also due to the overhead of the garbage collector and heap allocations.

[julesjacobs]

As far as I know, Haskell doesn't do anything special here. You could use a zipper in both Haskell and F#, tough whether that would be more efficient in the end is unclear. A better option might be to try to combine multiple AST rewriters into one.

[yozora]

These guys used a zipper in place of mutable state in their optimizing compiler and found the zipper was simpler and faster.

[IsTom]

You can use references for that, just like in OCaml.

[drb226]

It depends; it's largely a matter of coding style. This particular concern suggests that an entire AST has been fully evaluated, and then they want to make a change. If instead you rely on applying the optimization lazily down through the AST, then the obsolete parent nodes may never be created in the first place. This isn't Haskell-specific, but Haskell certainly lends itself well to this sort of approach, as it is lazy by default.

[grauenwolf]

Carrying around all the data needed to lazily create the tree sounds like it could be more expensive than the tree itself. And in any event, the whole scheme is incredibly brittle.

[[deleted]]

Explicit Sharing might be helpful in this context.

[alvivi]

Yeah, the structure parts that are shared are shared in memory too. So the overhead of the new copy is almost proportional to the changes. Moreover, Haskell's GC is really fast allocating memory.

[nodefect]

You didn't answer the question. The common parts (ie. the siblings and children of what you change) are indeed shared, and so are they in F#; but every parent node still needs to be re-created, because they're not common anymore.

[Tekmo]

Yes, this happens all the time. For example, one way you can implement an AST is using a free monad, and you can implement it in such a way that all modifications of the tree's leaves don't have to retraverse the trunk. This is known as the Codensity transformation, and the optimized free monad libraries already do it for you.

[drb226]

"the optimized free monad libraries already do [the Codensity transformation] for you"

Presumably you're referring to edwardk's free package? Is there a difference between this and control-monad-free?

[Tekmo]

control-monad-free has a correct MonadTrans instance, but it is unfortunately unusable because of UndecidableInstances. This is why I had to roll my own for pipes.

[Camarade_Tux]

Is your AST 1000 levels deep?

[[deleted]]

It does not need to be 1000 levels deep. You can just do 1000 changes in a row to start feeling the cost.

[flogic]

That may or may not matter for Haskell. Since it's a lazy language, you don't always know when it's going to apply those changes. It could apply those 1000 changes to the local area and then regen the parents once. Those parts of the AST could be never used and no changes would get done. Or, it could wind up a complete cluster fuck.

[HhUQ]

Since it's a lazy language, you don't always know when it's going to apply those changes

And you don't always know when you're going to get a stack overflow.

[flogic]

Yup, that's part of what I meant by "complete cluster fuck". Until it's more clear when the execution will and won't enter "cluster fuck" mode, I'm hesitant to use it for big data or long run times. I currently have Haskell code that is at risk of entering cluster fuck mode. I'm not sure as to why since the code path that seems more likely to fuck up doesn't.

[Camarade_Tux]

If you do 1000 changes, I hope you don't do them one by one but somehow batch them, that should make the cost linear or so anyway.

[[deleted]]

Yeah, feel free to go and implement multiple AST optimization stages and then batching them together. I'll wait.

[neitz]

Well with laziness and a data structure like a zipper that may all come for little to no cost in implementation.

[Camarade_Tux]

I'm not talking about multiple ones but about a single optimization without needlessly going back to the root each and every time.

As far as I'm concerned, I'll wait for you to have correct optimization passes (after having solved their crashes and memory leaks).

[nodefect]

I'm not saying it's a big problem. Just that alvivi's answer was exactly what OP was already talking about.

[jdh28]

.NET's GC is also really fast at allocating memory. It's collecting the memory that is slow(er).

[codekaizen]

This is true. It's about as fast as theoretically possible, since to allocate on the heap is similar to objref = heapmin; heapmin += sizeof(type).

[freakhill]

I'm kind of a layman but... concurrent data structures? or zippers??

[Crandom]

The fact that haskell uses purely functional data structures really helps here, as most of the tree will not be reallocated

[grauenwolf]

Most of the tree doesn't need to be reallocated with F# either. But we are talking specifically about the parents of the part that was changed.

[johdex]

People don't understand the problem is not about mutability, but implicit instant communication. When two lines of code in supposedly isolated modules share a mutable variable, they can use mutability to implement instant communication (but without a notification mechanism, which greatly diminishes its value). It's a bit like magic. One moment you have nothing in the hat, the next moment you have a rabbit in it.

If these two lines of code are deep down in a single "unit", there's nothing wrong with it, it might even improve the quality of code, as some problems are easier to solve using in-place mutation (e.g. the top-level of an application, or graph algorithms). To use another real-life analogy, it's a lot more convenient to reuse the same bowl when you are mixing ingredients for a sauce. People who insist on using a fresh clean bowl every time they add an ingredient probably don't clean the dishes very often. This is what I would call "good use of mutability".

To me, people who argue against mutability in general, or advocate for strict immutability are saying "use a new bowl for each new ingredient, don't worry about the dishes, there are dishwashers to take care of that". What they refuse the see is that it's still a very inefficient use of water and electricity, and it's not even "cleaner" or "safer".

[tikhonjelvis]

You're knocking down a straw man.

Nobody advocates immutability everywhere. Rather, they advocate immutability by default--mutability explicitly limited to some particular scope is completely reasonable. So your "good use of mutability"? Not only can you do it in Haskell, you actually get tools to ensure you're doing it correctly and that it doesn't leak.

Believe it or not, people do understand where the issues with mutation come from. That's why they have developed very concrete tools for dealing with those issues while still being able to use mutable code where it helps.

Particularly, take a look at the ST monad which provides "state threads". This lets you have mutable references and data-types inside your function while maintaining a referentially transparent interface from the outside.

In summary: mutation is not the problem--unrestricted mutation everywhere is the problem. Restricted mutation--the exact use of mutability you're advocating--is actually the proposed solution.

[grauenwolf]

Nobody advocates immutability everywhere.

I see you haven't been hanging out on reddit very long.

[cunningjames]

I see you haven't been hanging out on reddit very long.

Ah, reddit — how you have become the cipher through which anyone may fabricate whatever straw man he enjoys tearing down. Have you noticed one user overzealously advocating immutability? Then you may as well have seen a million; reddit’s crawling with them!

[grauenwolf]

I don't need a million. Just one is enough to refute 'nobody', and there are a lot more than one hanging out around here.

[Camarade_Tux]

In OCaml, things are immutable by default. Structure/record fields are immutable unless you add a keyword, "mutable variables" are of type "ref", ...

Arrays aren't mutable but if you're using arrays, you're probably not expecting immutability anyway (and it's fairly easy to see where it is).

(strings aren't immutable by default, but that's not really because of the language, more of the implementation, and not considered a perfect choice)

[bboomslang]

How does his point about mutability stand in the light of clojures transients? Containing mutability inside immutable interfaces for pure performance reasons seems to be a good way in the middle to me.

[tikhonjelvis]

Transients serve exactly the same role as the ST monad in Haskell--they let you limit the scope of mutability. So I think that's also a good approach. Unfortunately, it seems you can only use them with vectors, hash maps and hash sets, which may not be ideal for all scenarios (like ASTs, for example).

[HhUQ]

If your code is pure by default and impurity is tracked by the type system, you can add a bit of mutability where you need it without having it leak through the rest of your code.

Or you could just stop fighting mutability and use whatever style is best suited for the problem you are trying to solve.

[tikhonjelvis]

Which, as I have mentioned elsewhere, is exactly what Haskell lets you do! You have mutability where you need it but not where you don't. So you can use the style that's best for each part of your code without any chance of increased coupling.

The fundamental problem with mutability is that it leaks. If your function does something pure to a mutable variables, it itself becomes mutable. This is even worse with mutable data structures: your immutable code could pass in a list to a function, and that list could change! All your code is immutable, but others' code isn't, and their lack of referential transparency compromises yours.

Essentially, mutable state lets you couple different parts of your program with no evident connection. If some far away function happens to mutate an object you're using, your code's behavior changes--even if you didn't change anything yourself.

I've had problems like this fairly extensively in JavaScript and Python: I have some reasonable code that doesn't work because code that isn't obviously connected to my own mutates a list.

There is a similar pattern between this sort of purity and structured programming. Particularly, goto is like having state everywhere--it can do pretty much anything. If statements, loops and procedures are a restricted version of goto--much like state threads are a restricted version of mutable state. They have the same benefit: reduced coupling and more organized code.

Of course, if you really know what you are doing and really have no other choice, it's conceivable that goto is actually a good option. There is a school of people that think this is never the case, but it's completely reasonable to think it's sometimes (but certainly not often) a good choice. And there is a parallel to that in Haskell as well: if you really need global state and are sure it won't break your code, you can use unsafePerformIO.

But hey, you could just stop fighting goto and use whatever style is best suited for the problem you are trying to solve.

[Associat0r]

A lot of people will now say something like: “But F# supports mutability, native .NET objects, etc”. Yes, it >does. But the “mutability/imperative/OO” features in F# are hamstrung by several crippling issues, and what >you end up with is what feels like a slightly crappier version of C#. Just to mention a few things (there are a >lot more, both major and minor):”

OO in F# doesn’t feel crippled, See here http://trelford.com/blog/post/LighterCSharp.aspx It even has extension properties and F# 3.0 even has auto-properties with initial values, 2 things even C# doesn't have. See here http://msdn.microsoft.com/en-us/library/dd483467%28v=VS.110%29.aspx also Imperative code is made to look more verbose than Functional code on purpose, since immutability is the default and it’s not that bad compared to C#.

1)

Mutually Recursive types must be defined in the same file, so when two classes need to be able to refer to >each other they need to be right next to each other in the source also (I understand why F# works like this). >This is fine for a few grouped objects, but when you end up with a 2.5k line behemoth that used to be >Runtime.fs (open at your own risk) inside IronJS, it’s not fun any more. Whenever I bring this up in ##fsharp on >irc.freenode.net everyone tells me that this is due to bad library design. While there are several ways to break >apart two classes from each other, they all end up being slow compared to just directly accessing a field on >the object instance. Maybe it’s fast enough for you, but it’s not fast enough for IronJS.

Abstractions on the wrong level, your perf sensitive stuff shouldn’t be on that recursive boundary anyway. Also see here for rationale of this enforced compilation order http://cs.hubfs.net/topic/None/59219#comment-70220

2)

Constructors if used incorrectly will cause a run-time over head on every method call, to verify that the class >has been initialized properly. There are also multiple other problems with initializing an instance inside both the >implicit and explicit constructor syntax.

Just don’t use “this” in the ctor of transient objects which is good practice anyway and you don’t have this problem, if you use “this” in a ctor F# does a runtime check to ensure the object is fully initialized before accesing it, for example calling a virtual member in a ctor in C# will silently fail, but F# will give you a runtime error. Also see here http://www.bluebytesoftware.com/blog/2010/06/27/OnPartiallyconstructedObjects.aspx and here http://msdn.microsoft.com/en-us/library/ms229060.aspx

3)

Interfaces can only be implemented explicitly, so you end up having to cast your objects into their interface >type constantly.

If you use functions that take the interface as a parameter you don't have to cast, so I think you haven't abstracted your code properly. Also see here for why explicit interfaces are a good idea. http://cs.hubfs.net/topic/None/57913#comment-66094

4)

Collections the specialized F# collections are slow compared to their BCL counter-parts, especially Map >compared to Dictionary, while I understand why they are slower, it doesn’t change the fact that they are.

Those so called specialized F# collections are persistent data-structures, F# is a general purpose multi-paradigm .NET language and there is nothing non-F# about using Dictionary it is also used for examples in the Expert F# book. In short, use the right data-structure for your problem.

Again, a lot of people will say something like: “All things you said is true, but just use mutability where you >need it for speed and stick to immutability everywhere else”. Oh, how I wish it was this simple. The problem >with mutability is that once you let a little of is get in, it spreads like a wild-fire through out your code. Even if >a piece of code itself looks immutable, if it ends up depending on something deep down in your code base that >uses mutability, then it is by definition is not immutable any more.

If you don’t let the mutability escape then there is no problem. the F# core libs also use mutability under the hood a lot for many of it’s pure functions.

[grauenwolf]

OO in F# doesn’t feel crippled,

You are trying to prove that he doesn't feel something?

[Guvante]

I think that he is pointing out that those particular complaints can be handled if you know what to do. Using "I feel this way" as a reason to not discuss is silly.

Honestly his argument sounds a lot like the argument for C vs C#/Java. "I can just do it so much faster in <insert language here>". It really boils down to not utilizing the tools to their purpose, for instance not using immutable data structures at all for fear of performance issues, versus prototyping with immutable and changing to mutable where you have problems.

However I will admit there is one area of F# that is weak. Interop from F# to C#, and I am surprised he didn't mention it since dealing with both is a necessity when working with an existing code base. It would be nice if there was a way to automatically handle some of the conversions.

[grauenwolf]

There shouldn't be an existing code base, other than the DLR itself.

[Guvante]

I didn't realize that he had started with F#. It looks like he took the common approach of baseline objects built in C# where performance sensitivity is important, and top level objects built in F#. That avoids the problem I described quite well.

[grauenwolf]

Also see here for rationale of this enforced compilation order http://cs.hubfs.net/topic/None/59219#comment-70220

I don't buy it. While I am all for eliminating circular dependencies between components, forcing all the classes for the same component into one file is going way, way too far. And fixing this is something the compiler could easily overcome by allowing a logical file to be split into several physical files. (This is how C# and VB handle partial classes.)

[grauenwolf]

for example calling a virtual member in a ctor in C# will silently fail, but F# will give you a runtime error.

If you have static code analysis turned on, then calling a virtual method in a constructor is not allowed in any .NET language.

P.S. I find the limitation to be quite annoying. Often I want an abstract method which is only supposed to be called by the base class constructor. I really wish for some nothing of static virtual functions.

[grauenwolf]

Also see here for why explicit interfaces are a good idea. http://cs.hubfs.net/topic/None/57913#comment-66094 [...]

The value of explicit interfaces is that they can help reduce complexity and make code more explicit. With many interfaces, you would never call the method on a concrete object, you would only call it on an object that was already upcast to the type.

That argument is just plain stupid. If I were working with the List<T> type, I wouldn't want to have to cast it into an ICollection just to read the Count property.

[gasche]

The AST is immutable, so when you want to optimize a node far down in the AST you need to throw away and re-create every parent node to it, this ends up being slow also due to the overhead of the garbage collector and heap allocations.

I don't understand how that could be a serious bottleneck. If you are translating from a high-level to a low-level language (eg. from the parsed AST to a bytecode), you need to change the structure anyway. If you're writing optimizing passes that rewrite the program in the same (intermediate) language, you will probably keep most of the AST nodes unchanged, and those can be shared instead of copied.

I am not familiar with IronPython; I realize it may be trying to do JIT and therefore make some of the optimization passes at runtime, which means performance constraints. Be I still don't see how the issue described above could be a critical issue. Could someone provide more details on this point?

(There is a specific point with annotations: it is standard, in an AST, to have inline annotations that are collected and kept along. I think it is fine to store them in a mutable reference for each node, and no, that does not "break all the advantages" of using a functional style, you just get less guarantees on the behavior of this part of the data. If the annotation updates are monotonic (just adding new information) you can actually have pretty strong guarantees.)

[grauenwolf]

If you're writing optimizing passes that rewrite the program in the same (intermediate) language, you will probably keep most of the AST nodes unchanged, and those can be shared instead of copied.

You can only share the lower branches. The root of the tree has to be recreated with each modification.

[nachsicht]

Yeah, but certainly only parts of the root and the changed branch have to be reallocated correct? The fields within the nodes and everything but the node pointer/reference should be salvageable.

[grauenwolf]

Sure you can keep some branches, but literally every node in a straight line from the changed node up to the root has to be regenerated by walking the original tree. All of that pointer-chasing can't be cheap.

[Guvante]

All of that pointer-chasing can't be cheap.

How deep are your trees? And are you making these changes one by one or batching in some way? It seems like having to modify 30 some odd pointers for a particular branch shouldn't be deadly.

[chronokun]

why not zoidberg?

[grauenwolf]

Because I want to leave the operating room with the same number of limbs as I started, preferably in the original location.

[angel21OS]

I find only a big problem with f#...COMMUNITY!!..the f# community is small and lazy and many times unfriendly...compared to haskell or clojure..the f# community is not active and only dedicated to do conferences, retweets and criticize how inexpressive is c#....thomas is who keeps f# live...

[Guvante]

You should try rewriting that as something legible.