Are you using F# as a purely functional language or also as OOP?
I'm currently following a course in Haskell, a purely functional language, and I must say that some problems are pretty neatly solved using the functional paradigm
For example the quicksort can be written in only 5 lines of readable code (taken from the Haskell introduction[^]).
you can work on a complex problem in F# all day and at the end of it have expressed the solution with such elegance and so little clutter that it feels quite artistic.
Agreed, but that's sort of the problem I find with FP in general -- I have to spend all day figuring out how to express the solution!
One of the biggest difficulties, and the reason I don't use F# as my primary language, is the issue of state. How have you solved the problem of managing state, or do you resort to using stateful / mutable objects? I understand how to pass state with monads (or continuations) but in broader terms, I still struggle with statefulness vs. pure immutable FP.
I was a little worried about learning Oxygene and moving away from Delphi, but I'm really glad I did. There are so many things that are a snap to do with xaml and some classes that were a royal pain to do in Delphi. Things like making a dbgrid cell have some combinations of controls or pictures. Trivial in Oxygene Silverlight or WPF app.
I do recommend learning it. The price is small and it works pretty well on multiple platforms (platform specific, not platform agnostic).
I was actually expecting the result to be in the low single-digits; I am actually surprised by the love I saw!
I grew up on BASIC - I cut my coding teeth using a TRS-80 Color Computer 2 with 16 K of RAM and cassette tape drive, running Microsoft's Extended Color BASIC.
Now, for a new problem - one I defined? I wouldn't select just any BASIC!
Today, I would use QB64 (http://www.qb64.net/) - cross-platform across the "big-3" (Windows, Mac, Linux) - compiles to native, and 64 bit. Supports everything on modern operating systems, including OpenGL! Best of all, the vast majority of QBasic and QuickBasic software will compile without changes needed. For those that do need changes, those changes will be relatively few. Those that will have major difficulty running will be those that used assembler routines or other direct hardware access, but if you understand what is being done by those routines, chances are they can be ported to use more standard methods.
The biggest downside, though, to QB64 - is the lack of object orientation. You can fake it a bit, but its fairly hacky - reminiscent of doing OOP in standard C (maybe worse).
I'll always have a place in my heart for BASIC. I'm glad to see others do, too!
Part of the reason that probably a lot of people like C# is that it does works, works well Inside Visual Studio and it is fast to compile.
And by the way some language feature like LINQ, lambda (and async that I haven't yet used) are great and have equivalent. Even the way to implemenent IEnumerable is simple and nice.
However, I would like if it would supports templates like C++ does... And with many other things, most of the power but without the complexity.
On the other hand, C++ (and C++/CLI) could have been much more interesting to uses if since the start :
- Visual Studio would have work as well with C++/CLI.
- STL.NET would have work (correctly, effeciently, transparently...)
- Intellisence would have works for C++ code.
- Designer would have works well for WinForms, Database, WPF.
- LINQ would be available.
- Compilation and linking would not be so slow.
- Compiling pure assemblies would not means forgetting most standard C++.
- C++/CLI would have been implemented correctly to fit with standard C++ so that it would have been easy to have template code that works both on managed types and unmanaged one (no gcnew, ^ or %).
- Better language integration including Intellisence and Browsing accross languages.
- and so on...
I really like C++ once but given all the drawbacks and the fact that for real applications, often the things that are missing in C# does not matters much finally.