|
That's exactly my experience with Haskell.
Had one of those pleasant moments further up in the thread, when I was able to explain how to use State in functional programs - not that long ago I didn't understand it myself.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Super Lloyd wrote: What's the point? What can it do that C# can't?
It's to do with what type of problem you are trying to solve. From your link...
"Scala particularly shines when it comes to scalable server software that makes use of concurrent and synchronous processing, parallel utilization of multiple cores, and distributed processing in the cloud.
Its functional nature makes it easier to write safe and performant multi-threaded code. There’s typically less reliance on mutable state and Scala’s futures and actors provide powerful tools for organizing concurrent system at a high-level of abstraction."
Yes, you can do all this in C# or Java but you can do it more expressively and more robustly in the likes of Scala or F#, often utilising distributed computing and concurrency frameworks such as Akka[^]. Akka is itself written in Scala but can be consumed from Java.
A year or so ago it was ported to .NET (Akka.NET[^]) and can be consumed from C#. So you can stick with C# but the ideas ultimately came from functional programming concepts.
Kevin
|
|
|
|
|
You know JavaScript is sitting over in the corner there going "but...but I can be OOP too! And I'm functional! And future proof and stuff! Guys? Guys...?"
Man - developers are a fickle lot.
Personally it's always seemed that you can do anything with any language: it's the libraries and platform that's the trick. Async and parallelisation are awesome, but they are, essentially, optimisations.
It always seems to me that each language merely has a different way of doing the same thing, and more often than not it's purely up to which features you don't want when picking a language.
Of course there's the mindset of procedural vs (pure) functional vs OO vs list-based etc. That one seems to be either a domain driven choice or a masochist drive choice.
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: Personally it's always seemed that you can do anything with any language: it's the libraries and platform that's the trick. Async and parallelisation are awesome, but they are, essentially, optimisations.
I think it's that (irrespective of libraries) certain classes of problems are more effectively (or more easily) tackled with specific languages.
A good example is the machine learning I'm studying at the moment. The author tackles the first problem using C#. Then he provides the F# solution and you can easily see that the F# is superior in this context. But you have to see a demo to appreciate it. It's quite hard to tell apriori.
But even if you never use a functional language their influence on the OO languages, both features and libraries, is beneficial.
E.g., you can choose to use an excellent framework such as Akka.NET purely in C#. But this is ported from Akka, which is written in Scala, and is in turn a framework for the Actor Model of concurrency that was first implemented in a big way in Erlang, a functional language.
Kevin
|
|
|
|
|
Kevin McFarlane wrote: the Actor Model of concurrency that was first implemented in a big way in Erlang, a functional language.
Carl Hewitt (Wiki)[^] may disagree with that.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
I did say in a big way. I think Erlang was the first well-known or popular implementation.
Kevin
|
|
|
|
|
A jaw-dropping new photo shows a probable alien planet orbiting a star that lies 1,200 light-years from Earth. "Zoom in! Enhance!"
|
|
|
|
|
Kent Sharkey wrote: "Zoom in! Enhance!" (Accompanied by the sound of Deckard using the video-editing console in Blade Runner)
|
|
|
|
|
If they're more advanced, maybe we can learn their technology. If they're more Risan[^], we'll get a good show.
|
|
|
|
|
|
|
|
.NET ecosystem is dangerously oblivious to distributed computing. "Hey gypsy woman, look in your crystal ball and tell me what my future will be "
OK, it might be a bit too long for some people's attention span, but read on to find out why .NET is doomed because of plate armour, or something
|
|
|
|
|
And this kind of person is called an MVP! Wait V=Valueless. That's right. He mixed open source with distributed computing,...
|
|
|
|
|
The fact that the .NET ecosystem doesn't teach distributed computing would be a cause for concern, except that the future probably lies in intelligent backplane technology that makes a network of thousand of computer appear/work as one.
I genuinely expect the "Hadoop" equivalent of the next generation to be - SQL Server... because if all you are doing already is issuing commands and allowing the system to work out the implementation details, it stands to reason you don't want to or aren't going to work out those details yourself.
Yes it feels lazy/imprecise/inneficient to us old greys that grew up in the constraints of 640Kb but computing power is growing so fast and AI becoming so pervasive we have to accept that we will no longer be telling the computer* how to do something - just asking it for what we want it to do.
*Obviously multiple physical computers are implied here...
|
|
|
|
|
|
|
Yes, but hardly being used is his point I think. I'd guess that very few .NET devs have heard of Orleans or Akka.NET. Many have not even heard of F#, despite its being in the Visual Studio project templates!
Kevin
|
|
|
|
|
Likely true. I've not heard of those either, but then I'm not trying to do distributed computing. So, maybe, if I were, I'd gone in search of it. Maybe that's the case with other .Net devs.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
Chef today launched Habitat, a new open source project that allows developers to package their applications and run them on a wide variety of infrastructures. "What's in the box?"
|
|
|
|
|
A German university student has demonstrated an effective way to get code of his choosing to run on the computers of software developers, at least some of whom work for US governmental and military organizations. Pakcage mnageers considered harmful
|
|
|
|
|
Kent Sharkey wrote: Pakcage mnageers considered harmful Stupdity considered even more harmful
|
|
|
|
|
New programmers are programmers no more. Used to huge collections of Lego bricks because they wouldn't be able to sort an array if asked they first search for something already done and don't inspect what they download.
Languages and frameworks for these "developers" became so cluttered that a real inspection is nigh-impossible thanks to impossibly long lists of dependencies, inheritances and interfaces and no real documentation (automatically generated documentation is not documentation, period).
So we have thousands of people doing something they barely if ever understand with tools that make understanding harder beacuse of clutter... these are the results. Say hello to non-programmer developing...
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
Checked C is an extension to C that adds static and dynamic checking to detect or prevent common programming errors such as buffer overruns, out-of-bounds memory accesses, and incorrect type casts. Coming up next: Plaid Java
|
|
|
|
|
Well we all know that plaid is fastest.
|
|
|
|