Hijacking this thread to ask you this.
What should I learn if I want to develop desktop apps and I like functional programming? I feel like most of the cool 'new' programming languages are OOP (rust, go, scala).
What should I learn if I want to develop desktop apps and I like functional programming? I feel like most of the cool 'new' programming languages are OOP (rust, go, scala).
Some links:
https://fsprojects.github.io/FsXaml/
https://github.com/Prolucid/Elmish.WPF
https://github.com/GtkSharp/GtkSharp
Starting a new project in WPF at this time doesn’t make sense.
So they are getting some newly found love on their way to the store.
Microsoft has realised that the best way to force devs into the shop is to merge Win32 and UWP worlds.
Since it's basically OCaml, it has objects, but it's mostly a FP language.
Because significant portion of your learning/cognitive effort you will be spending on understanding the UI paradigms offered by a given GUI toolkit.
So take a look at the languages, in language bindings available for
1) Qt UI toolkit http://wiki.qt.io/Language_Bindings
2) at the languages, in the language bindings available for wxWidgets UI toolkit
https://en.wikipedia.org/wiki/List_of_language_bindings_for_...
2) And same for FLTk http://www.fltk.org/wiki.php?LC+P139+TC+Q
Perhaps, also, you can also investigate if you can use F# (equivalent somewhat to ocaml), to develop Windows Apps with https://github.com/Microsoft/react-native-windows
Same for Nim https://github.com/andreaferretti/react.nim (there is probably a way to package it as Electron App ).
(depending on your desire for adventure/early/small community/small ecosystem interest)
For what it's worth rust and go are not OOP languages. Scala and Swift (to add another new, hot language) have inheritance and OOP features for ffi with their platform langagues java and objective-c respectively. However, the OOP features are largely discouraged and their type systems have more in common with haskell and other strongly typed functional languages. Rust has basically the same type system as haskell and swift with its famed borrow checker on top. Scala, Rust, Swift are all mixed paradigm with their community's' preference for functional design in roughly that order. Go has a totally different type system from the others and is almost entirely an imperative langauge.
I think Go works best for applications that don't need any "internal plumbing". For example, one of my projects is a query engine. It takes an AST and plans a pipeline of operators that compose together (map, filter, join etc.). It's pretty damn awkward to write in Go, and type safety often goes out the window. It's something that in other languages (Haskell, OCaml, Rust, Scala and Swift would all qualify) could be expressed with an elegant smattering of union types, generic functions and monadic chaining.
But that awkwardness is because the app is 99% framework (various types and functions being used to compose stuff together), most of which is a big, generic factory to produce a small engine. If your app is all imperative "meat", with little framework, then Go is a much better fit.
Or F# with WPF, though F# is also OOP, but for some reason I feel its less so then Scala, and forces more functional constructs on you.
ClojureScript with Electron can also be an option if you're okay with Electron apps.
Finally Haskell and reactive bananas is an option too, that's pretty strongly functional.
I'll also mention Red, red-lang.org, its still in alpha, but is pretty sweet for simple GUI app on desktop.
I code mainly in C# but I as F# for its REPL for some data manipulation tasks.
I found myself in that space for a while, but everything kind of made sense when the "Erlang is the most object-oriented language in the market" meme clicked into place: a (micro-)service, an Erlang-style actor and an object are almost the exact same unit of abstraction, applied in different ways. The model is always the same: you communicate by message passing — and, for the most part, you want your objects to be given orders rather than be asked questions.
When I went back to Java, it became evident how damaging the "everything is an object" mentality of Java really is — it really pushes people towards a whole bunch of anti-patterns. One obvious example is that structs are not objects, and you shouldn't try to make them be. Getters/setters are a clear sign that your entity is a struct rather than an object — if you're at that stage, stop trying to apply OOP principles around its design. Another recurring problem is abusing inheritance, and underusing interfaces. I've written maybe 2-3 abstract classes over the last few years, and, when I code review a PR with any abstract classes (or inheritance of any sort) in it, I can almost always get the original author to factor it away while agreeing that it was a problem in the design.
I suggest giving Kotlin a try. Data classes are as close to structs as you'll ever get in the JVM (until Valhalla ships), delegation is crazy easy to achieve, inheritance is heavily discouraged (by having everything be final by default), bare functions and extension functions help keep interfaces clean, and the lambda situation is much better than Java's (receiver lambdas are the language's killer feature, IMO).
If you're thinking of functions operating on immutable objects and returning new objects then that is not typically what we refer to as a OOP pattern though technically it may fit the definition.
More universities should spend time teaching BETA, Self, CLOS, Smalltak, component based architectures.
Yea but don't forget that closures are a poor man's objects!
-- Guy Steele
If you don't mind your app working through Electron or some other variation of a web-view, there's a lot of resources for those.
really looking forward to seeing where they go with it!
That's not a very good way to characterize functional programming languages. Obviously you can do functional programming without type inference (see Lisp), and type inference is similarly applicable to non-functional languages (see OCaml's purely imperative sublanguage).
Also, as far as I can tell, Rust uses (a modification of) the Hindley-Milner algorithm to infer lifetimes, not types. As languages in the functional camp typically don't have lifetimes, this argument is a bit strange.
True, I had forgotten that you can just write let foo = bar. (Not a regular Rust user.)
You can also check out Racket.
If you like windows but also want cross platform, C#/F# and Xamarin.Forms or UI or whatever its called. I've heard very positive things about dotnet gui work these days.
I'm spending time with rust to try my hand at game development. As an older developer, it's all a bit foreign to me so I don't really know what's good and what's not.
That having been said, desktop development is something the rust community at large is dedicated to ant interested in. There's already a fee libraries, like Conrod for Piston, gtk.rs, etc but I don't know how these options stack up against industry standards.
C# 7 is a lot more functional and pleasant than the C# 4/5 everybody dismissed years ago.
F# can compile to wherever you need it and you can write functional first and just include it in your nuget built just like you normally would.
If you're adamant about functional, consider dotnet. Of course C# is still very much OOP, that's just what it is. But I find the primary benefits to FP in my own code to be more related to correctness, testability (and therefore more correct) and a convenience in modelling data structures quicker than subclassing. Even with generics, having unions and record types makes it just that much more satisfying.
F# actually has a little micro-discipline called domain-driven programming. Search for that term and you can see how different researchers have used F#'s incredibly flexible type modelling to adapt to their domain and make their code easier for people in that domain easier to understand.
Hope this helps!