2

I just love F# for tasks that lends themselves to functional programming. I use C# for imperative OO.

But it is getting increasingly painful to leave the non verbose grammar and type inference of F# whenever switching to C#.

Does anyone know if there is something cooking for non verbose imperative programming as the syntax and type inference does not really relate to imperative vs functional.

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
Jack Wester
  • 5,170
  • 3
  • 28
  • 47
  • Have you looked into ruby/IronRuby? – Candide Feb 17 '12 at 10:48
  • Look into Cobra and Boo. Those support static implicit typing with a python like syntax. Cobra seems to be much better designed than Boo, but the IDE support is very lacking. | IronPython on the other hand doesn't use type inference, it's dynamically typed. – CodesInChaos Feb 17 '12 at 10:57
  • 1
    @Ingenu I think Ruby and IronRuby lacks strong typing. Type inference still means type safe – Jack Wester Feb 17 '12 at 11:46
  • VB.Net is very verbose compared to F# – Jack Wester Feb 17 '12 at 11:47
  • @Tudor Isn't Python without strong typing? Type inference means non verbose AND type safe – Jack Wester Feb 17 '12 at 11:49
  • @CodeInChaos Thanks. Looks like Cobra might be worth looking into. Why don't you add your comment as an answer? It deserves an up vote. – Jack Wester Feb 17 '12 at 12:07
  • @JoachimWester I'm not sure how it is that forward referencing is essential to imperative programming. – Onorio Catenacci Feb 17 '12 at 14:51
  • Frankly, I don't even like the idea of bringing that much OO and Imperative style programming to F#. I believe that sticking to a paradigm is important, and I fear that F# will get too muddy with that much OO, and that its core paradigm of Functional programming will get twisted. OO and Functional are really different styles, and one should embrace one paradigm or the other within the context of a software project. – Nick Feb 17 '12 at 16:53
  • 1
    Not sure how mature it is, but it looks [there's an effort under way to bring Scala to .NET](http://www.scala-lang.org/node/10299). As functional/OO hybrids go, it trends OO. – Daniel Feb 17 '12 at 17:02
  • Writing a parser in C# is less productive than in F#. At the same time, writing PacMan in F# without mutable state is more of a challenge than a productivity boost. – Jack Wester Feb 17 '12 at 17:04
  • A point is that the syntax in F# is superior to the legacy syntax in C# and that it's frustrating to use C style curly braces and verbose declarations. I has nothing to do with functional vs object oriented. – Jack Wester Feb 17 '12 at 17:05
  • 1
    @JoachimWester: I don't think you're going to be satisfied with any answers you get here, because the short answer to your question is "no." At the moment, F# is as good as it gets for a terse, statically-typed language targeting .NET. – Daniel Feb 17 '12 at 17:19

4 Answers4

7

F# 3.0 is getting some features to better support imperative object-oriented programming (which is often needed when working with imperative .NET libraries for data access). It will have auto-implemented properties (see MSDN documentation):

type MyClass() =
    let random  = new System.Random()
    member val AutoProperty = random.Next() with get, set
    member this.ExplicitProperty = random.Next()

It also lets you calculate an initial value using the member let construct (in contrast to just member which re-evaluates the body each time it is called).

F# 3.0 is not going to make imperative programming easier when it comes to mutation and things like break and continue in loops. I think the emphasis on immutable state is to encourage good F# programming style, but there has been a lot of discussion about this and you can suggest & vote for this.

And just a note regarding your comments where "pure functional programming is a bad match". I think this really depends on the libraries that are available and the mental model you're following. I'm quite convinced that FP is actually pretty good for GUIs, there are just no F# libraries that would prove it. You may find this question interesting: Is functional GUI programming possible?

Community
  • 1
  • 1
Tomas Petricek
  • 240,744
  • 19
  • 378
  • 553
  • 1
    To be really purist about functional you will need a database that treats time as part of the state. I.e. when you change a name on a person, that person has two names in two times. This would make it immutable. The hardware for big data temporal databases are just not there. And when it comes to scientific deep ontology models, you need stronger conceptual OO support (objects being both instances and classes) and not weaker which is often the case with most functional languages. I see no conflict, just a bad understanding that it is not OO vs functional but rather declarative vs imperative. – Jack Wester Feb 17 '12 at 12:01
  • Once again, thanks for your excellent replies. Upvoted and accepted. – Jack Wester Feb 17 '12 at 12:06
  • F# 3.0 looks very exciting. I would love to have a single language – Jack Wester Feb 17 '12 at 13:00
  • I know I'm in the minority but I don't consider the addition of automatic properties a good thing. Too many developers add mutators/inspectors to every property--might as well make them all public and save the additional code. – Onorio Catenacci Feb 17 '12 at 14:50
  • @JoachimWester your interpretation of pure functional data misses the point that you only to keep old versions that are referenced, and usually they aren't. You may also want to read about functional reactive programming, which offers a purely functional way of dealing with interactivity and user interfaces without the need for mutable state. – Daniel Lyons Feb 17 '12 at 23:49
  • @Daniel I strongly disagree. The database is the first parameter of the outermost function and the events affecting it is the second parameter being a list of transactional events. This is how we do it and the cool effect is that we can retroactively undo errors made by the database user. Try to do that in an imperative database. – Jack Wester Feb 18 '12 at 00:22
  • @Daniel. A practical example is that if we enter a record in our database saying that we have 10 items in stock for 1 dollar. Then enter a transaction adding another 10 for 2 dollars. Then we sell 11 items. First in first out gives that the average purchase price was (10*1+1*2)/11 dollar. The cool thing is that our non imperative database lets us change a transaction retroactively and everything becomes correct. It is like Excel with the time dimension. And the outer most caller is the only mutable variable and thus keeps your "reference" to the persistent database objects. – Jack Wester Feb 18 '12 at 00:27
  • Our database is simply a function calculating its transactions since it was instantiated. No different from defining the square root of a number other than that the levels of nesting and types is greater and that the outermost "stack" is persistent on disk and logs. – Jack Wester Feb 18 '12 at 00:47
  • @JoachimWester I fail to understand how you can both "change a transaction retroactively" and call your data immutable. – Daniel Lyons Feb 18 '12 at 04:47
  • @Daniel Because the database in this case is a function and a structure declaration. It does not have data. Data is a list of transactions given to the function as a parameter. This is the clue, the database is a function, not a state full mutable storage. – Jack Wester Feb 18 '12 at 05:16
  • @Daniel Lyons - So to recap your failure to understand. I don't change the transaction, I call the database with a different parameter (a set). The parameter is the chain of events and its sorting is time. – Jack Wester Feb 18 '12 at 05:27
  • So in your functional database, where do you store the parameter set upon which the entire interpretation of the database rests? I think since you have sufficiently redefined every commonplace term and are only interested in discussing technologies you invented that if this were Wikipedia, I would put "Neutrality Disputed" right next to everything you've written. – Daniel Lyons Feb 18 '12 at 05:45
  • @Daniel - Is this your argument. I've removed the product reference to satisfy your neutrality point. I agree with it. – Jack Wester Feb 18 '12 at 05:52
  • In functional programming, you must redefine terms such as database or resort to adopting to a database property to be mutable, which then makes talking about side effect free databases pointless. I do not really understand your argument. – Jack Wester Feb 18 '12 at 05:57
  • If there is a term I'm not using correctly, please advice me on this and I'll clarify or change it to the correct term. Be specific. – Jack Wester Feb 18 '12 at 05:58
  • @Daniel "So in your functional database, where do you store the parameter set upon which the entire interpretation of the database rests?" Yes. But remove entire and replace it with the interpretation of the part of the database that my function answers – Jack Wester Feb 18 '12 at 06:03
  • @JoachimWester As a DBA with 6 years of Haskell programming under my belt, I am adequately aware of both functional programming and databases, and I haven't seen a single mention of what you're talking about anywhere but in this thread. I am aware of FRP, I am aware of event sourcing. I think your idea has merit, and your product may as well, but I don't think it is an appropriate to assert either that your definition of functional database is _the_ definition or to assert that current hardware is insufficient for such a thing. – Daniel Lyons Feb 18 '12 at 06:06
  • @Daniel - Conceptual illustration (NOT from any product we use or have created): SELECT P FROM Person P WHERE Name='Daniel' WHEN '2012-02-18' Will calculate you at a certain point in time by sequencing a range in the set of events. Another point in time renders another result. – Jack Wester Feb 18 '12 at 06:08
  • @JoachimWester The crux of what I'm saying is that your response to the user begins with the database unqualified, but your response usurps the ordinary definition for your own purposes. You are trying to sound authoritative in order to mislead, but this is essentially an unexplored field. – Daniel Lyons Feb 18 '12 at 06:10
  • @Daniel Lyons I am certainly NOT implying that it is THE definition. There is many ways to write high order functions. For me, this is a nice way to avoid side effects for database code. And rest assured that reading stock quantities without having them materialized using mutable properties requires more computational resources. – Jack Wester Feb 18 '12 at 06:13
  • @Daniel. My appologies. I have worked with this for over 20 years and over 6000 database installations, so I easily slip into this mode. I'm sorry. – Jack Wester Feb 18 '12 at 06:16
  • @Daniel - Seing my own posts, I which to replace quote "the database is" with "a database or dataset might be treated as". Okay? – Jack Wester Feb 18 '12 at 06:18
  • Hmm, the only production database I know that supports this kind of thing is gemstone (smalltalk) – Stephan Eggermont Feb 18 '12 at 10:35
  • @Stephan Cool. I was not aware of that. Have you had any experience with it? Is it worth checking out? – Jack Wester Feb 18 '12 at 11:34
  • I have a small production system using Seaside, Pharo & Gemstone. VmWare has a free version using 2GB of ram and 2 cores. It simply works – Stephan Eggermont Feb 18 '12 at 15:29
  • @Stephan - I like their approach – Jack Wester Feb 18 '12 at 16:13
  • +1: "I'm quite convinced that FP is actually pretty good for GUIs". Message passing between asynchronous agents is perfect for GUIs. – J D Feb 20 '12 at 09:32
7

I'm not clear on what you dislike about F#. While it favors a functional programming style, it also improves on imperative programming in .NET in many ways. I can't think of any C# code that can't be replaced by functionally identical--and much shorter--F# code (unsafe code being the only exception that comes to mind).

Even a mutable type representing, for instance, a database record

class Employee {
    public Employee(string firstName, string lastName, int age) {
        this.FirstName = firstName;
        this.LastName = lastName;
        this.Age = age;
    }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int Age { get; set; }
}

can be reduced to the following in F#:

type Employee =
  { mutable FirstName : string
    mutable LastName : string
    mutable Age : int }

And that's supposed to be C#'s cup of tea.

When you run into a feature F# lacks, it generally suggests there's a better way. That's a good time to stop and analyze the shortcomings of the typical imperative approach.

Indeed, F#'s greatest strength may be that it is a multi-paradigm language. You can use OO to structure your project, and functional programming "in the small" to organize your modules--no single style has to dominate. It merely increases the size of your toolbox.

If there are specific tasks/concepts you're having trouble porting to F#, you should mention them so others can offer solutions.

Daniel
  • 47,404
  • 11
  • 101
  • 179
  • What are you referring to, something in one of the answers or the long list of (mostly false) shortcomings (from over 2 years ago) in the question? If it's the latter, maybe you should post a separate question linking to that one and ask if that list is still (or ever was) valid, and what alternatives F# offers. – Daniel Feb 17 '12 at 16:21
  • I like F#. It does seem however that it tries to 'protect' the programmer from imperative style programming. http://stackoverflow.com/questions/1135280/what-is-f-lacking-for-oo-or-imperative I prefer to have both paradigm treated as first class citizens. We have a real time persistent ontology simulating real world entities implemented in C# and a query optimizer, parser and logic framework written in F#. To me, there is no conflict and F# should not try to 'help' me by making imperative constructs less 'comfortable'. I want short and simple syntax in a single language. F# is almost there. – Jack Wester Feb 17 '12 at 16:21
  • 1
    If it's the bullet points in that question that are bugging you, I can tell you most of them are dubious or represent a trade-off (with no mention of what F# offers instead). I don't think there will ever be a language that's a cross of C and Haskell. Some features are either/or. – Daniel Feb 17 '12 at 16:24
  • @JoachimWester: One thing to keep in mind is that some of the "annoyances" about working with imperative constructs in F# are equally annoying in C#, you just don't notice since the imperative construct is default. For instance `<-` allows using `=` for equality, `mutable` versus `readonly` in C#. `break`, `continue` and `goto` don't exist, but otherwise most are just a functional first mentality, not an imperative is bad mentality. – Guvante Feb 17 '12 at 21:26
  • @Gavante. I agree. As F# comes from a scientific research background, I'm disappointed that the things that got lost in C++/Java/C# is not fixed. Part from the early binding (i.e. strong typing) and performance, Java was a major step backwards from Smalltalk. The main problem was that it flirted to much with C++ and failed to see what C++ missed from the original ideas of OO. And C++ missed a lot. – Jack Wester Feb 17 '12 at 21:39
  • The declarative way of viewing collections (just as in Smalltalk) is fine and won't be missed. I'm disappointed though that a language that borrows so much from the scientific communities inherits the mistakes from C# and Java. The most important ones for me is that the type system fails to view types as instances and inherits the static and constructor nightmare inherited from C# inherited from Java inherited from C++ inherited from Stousups cfront implementation. It was a compromise to make C++ work without runtime types just as C does. Now F# ignores to correct it. – Jack Wester Feb 17 '12 at 21:40
  • @Having looked in to you answer and the bullet list, I'm now feeling better about giving F# as a general purpose solution. I can do without break and continue as I miss operating on collections and doing loops the ala Smalltalk anyway. How about forward referencing, does that give you a lot of headaches in F# as compared to C#? – Jack Wester Feb 17 '12 at 22:49
  • @Daniel. Thanks, you've inspired me to try to move to F# all together. I'm still curious to hear from anyone abandoning C# for .NET framework programming. How about XAML support? – Jack Wester Feb 18 '12 at 01:27
6

There are a few niche languages on .net which might have the properties you want.

In particular Boo and Cobra. They are languages that support implicit static typing with a python like syntax. Boo seems to be more popular, but I dislike several of their design choices. Cobra on the other hand looks nicely designed.

Due to the low popularity, the IDE support is pretty weak, especially for Cobra.

IronPython and IronRuby on the other hand, only support dynamic typing. Which reduces compile time safety, and makes static analysis (useful for Intellisense or refactoring) much harder.

CodesInChaos
  • 106,488
  • 23
  • 218
  • 262
  • Do you have a link for Cobra? If you google for it seems to drown out by other things called Cobra. – Robert Feb 17 '12 at 12:28
0

I'll also say that you seem to have mixed up the concepts of imperative and OO--they're not the same thing. C is an imperative language but it's certainly not OO. And from the texts quoted in this question it seems that Dr. Kay really had it in mind that Smalltalk would be a functional language and Smalltalk is the progenitor of most OO concepts. The imperative "property" of a language is orthogonal to it's object oriented properties. So if you're really asking if F# will have better support for OO then I think Tomas has already answered your question very well. All I'm saying is be careful in thinking about imperative coding and OO coding--they're not the same thing.

Community
  • 1
  • 1
Onorio Catenacci
  • 14,928
  • 14
  • 81
  • 132
  • Having written object oriented language compilers in the 80's, I don't think I have the concepts mixed up. – Jack Wester Feb 17 '12 at 21:06
  • The reason I'm asking the question is that I just started to use F# and I like it and I want to know what my options are to diminish my use of C# – Jack Wester Feb 17 '12 at 23:49
  • Ok--reading your original question it sounded as if you weren't clear on the distinction. I wasn't questioning your qualifications--I don't know you. Your question was worded in such a way as to leave some room for doubt. – Onorio Catenacci Feb 18 '12 at 21:45