|
Kent Sharkey wrote: Just confirming that we're still living in the real world.
I thought the world around us was the Matrix. Isn't it Morpheus ?
Patrice
“Everything should be made as simple as possible, but no simpler.” Albert Einstein
|
|
|
|
|
In a lovely demonstration of light's quantum effects, physicists in the UK have just mixed a molecule with light at room temperature for the first time ever. So.... they left something on the window ledge?
|
|
|
|
|
They mixed it, so there must have been a bowl involved.
cheers
Chris Maunder
|
|
|
|
|
The US broadband industry has lost its lawsuit attempting to overturn the Federal Communications Commission's net neutrality rules and the related reclassification of Internet service providers as common carriers. I'm sure that will settle things from now on
|
|
|
|
|
If it’s not already, Scala deserves a place at or near the top of your to-learn list — something I saw definitive evidence of last fall when I was coming off a post-doc position and considering leaving academia for the tech industry. You mean they're remaking that Eddie Murphy film?
|
|
|
|
|
I read What is Scala[^] and I wondered...
What's the point? What can it do that C# can't? Why should I use it when my C# (or my Java since it seems to want to compete with Java) is perfectly fine?
It does't look like a develper language (from the web site) so who is the target audience of Scala?
Overall... Meh...
|
|
|
|
|
Super Lloyd wrote: What can it do that C# can't?
Super Lloyd wrote: Overall... Meh..
My sentiments exactly.
I love OOP as it is in C++, C#, Java. These kids and their darned new languages.
Then I think, wait do I sound like those devs when I was starting out who would say things like,
"What do you need OOP for anyways? C is perfectly fine without it. I've got functions. These kids and their new languages."
And when those C guys were learning languages the older devs would say to them:
"What do you need all that high-level stuff for anyways? Assembler is just fine : mov ax, 4. These kids are so weak these days."
And before that, the older devs would say,
"These darn kids and their Assembler. All you need is 01010001 00110101"
It makes you wonder about it all. 
|
|
|
|
|
Yes, yes.. but read the "advantages of Scala"
- Scalable language... The explanation is lacking there, no idea what they are talking about, will give them the benefit of the doubt... it seems to say Scala is an hybrid of automatic (infered) strong typing and script / compiled language.. mm.. . maybe...
- Object Oriented, ahem, C# too
- Functional, ahem, C# too
- Seemless Java interop, well C# interop seemlessy with other C# hey!
- Function are object, well C# too
- Future proof (because async friendly), well C# is leading the charge with async friendliness
- Fun, well C# is fun
Is that all?
Winner: C#! All those point were like there since 1.0! (well async is new in... 4.0? I will give it that, only 2 years old)
|
|
|
|
|
I like the way you think!! C#, the clear winner. 
|
|
|
|
|
Super Lloyd wrote: Object Oriented, ahem, C# tooFunctional, ahem, C# too
C# isn't really functional... You should try F#. I believe F# is to the CLR what Scala is to the JVM 
|
|
|
|
|
By no stretch of the imagination is C# functional. F# yes, C# has a few functional features, but lacks many more than it possesses.
Functions in C# are NOT objects, they don't support composition, delegates are more like function pointers than higher order functions. Some of the expression tree stuff approaches functional views of higher-order functions, but I suspect you really don't understand functional programming.
C#'s async is a different level of support for concurrency. Functional programs have immutability throughout - as such race conditions are literally impossible - that's what they mean by async-friendly. No imperative language (with the possible exception of Rust) offers anything like the same safety.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Alright, "perhaps" scala has some scalability feature and perhaps some functional language have missing feature from C#.
Aside from that, as to composition, I can't see what C# is missing... from some F# composition sample C#, behold!
Funct<T> LoggingVersion(Funct<T> func)
{
return () => {
Console.WriteLine("Calling method");
return func();
};
}
Funct<T, T> x = ....;
Funct<T, T> squared = t => { var tmp = x(t); return tmp * tmp; };
Although.. mm... F# syntax would yet bit leaner then C# on the squareIt above sample I would admit....
modified 15-Jun-16 11:00am.
|
|
|
|
|
Compare that to Haskell (from the top of my head).
There is the func1 . func2 . func3 syntax, which is true composition (or, mathematically, (g o f)(x)=g(f(x)).
Then there is the following.
add x y = x + y
increment = add 1
Is this currying or partial application? I never seem to know
And of course Haskell (and F#) functions are pure, meaning they have no side effects.
C# functions aren't really functions in the mathematical meaning, they are procedures.
Because functional languages are basically math you can reason about programs (in theory). You just know that an add function will always have the same output for the same input. You also know that the order in which you execute functions don't matter to the workings of that function. There isn't some hidden variable anywhere that gets set when you execute another function first
But having mathematical functions is just one feature of functional languages. Let's not forget immutability and (complete) lazy evaluation!
Unfortunately, I haven't yet discovered if "studying evening after evening wondering how the hell to do something, that would've taken you a minute in C#, because you can't have state or mutability" is also a feature
|
|
|
|
|
Sander Rossel wrote: Unfortunately, I haven't yet discovered if "studying evening after evening wondering how the hell to do something, that would've taken you a minute in C#, because you can't have state or mutability" is also a feature
I did suffer from the same problem! 
|
|
|
|
|
That's where Monads come in in Haskell.
The IO monad wraps a computation and allows it to have side effects (writing/reading).
getLine = do c <- getChar
if c == '\n'
then return ""
else do l <- getLine
return c : l
Most of that is obvious, it reads individual characters and builds up the line (a list of Char) using the ':' operator (the list constructor - 'a' : "bc" is "abc".
It effectively gives you a small imperative sub-language, but retains functional purity. A benefit of this is that side-effects are localised.
It will be evident from the signature of getLine:
getLine :: IO String
That these side-effects are present.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Yeah, but even IO is somewhat "pure" in that it doesn't affect the state of the system.
I had to create a card game for school, but how are you going to keep the drawn cards and scores in memory (no file or database)?
In the end I just put the cards and scores in a variable and passed it to just about every function in my application.
According to the teacher that was fine, but it feels dirty...
|
|
|
|
|
That's exactly what the State monad is for - it allows you to create state that, from that point, is implicitly passed through a series of computations.
Here's a little example of its usage as a stack...
import Control.Monad.State
stackManip :: State Stack Int
stackManip = do
push 3
a <- pop
pop
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
That, quite simply, is not function composition. It is simply wrapping one function in another.
LoggingVersion is not even a function, as it has side-effects (writing to console).
Function composition is much more concise, and pure:
descendingSort = (sort . reverse)
Where ".", in Haskell (the functional language I'm most familiar with) is composition.
No need to specify that arguments must be passed from one to another.
Because the two functions are pure, the compiler can perform quite aggressive optimisation and, if multiple cores are available, arrange for them to be distributed between them.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
This is just a nicer syntax for it!
Don't get me wrong, I think nicer syntax is important. It does reduce error rate and make life easier. It can be a selling point.
But it's simply wrong to say C# doesn't do it.
|
|
|
|
|
OK, C# allows function composition, but only to the extent C supports OOP. It is possible, but without syntactical support, I wouldn't really call it "supported", just possible.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
My story is
C
=(big improvement)=> Objective-C
=(that was a regression :'( )=> Java + C++
=(that was a slight improvement)=> .NET,
=(slight improvement)=> .NET + C++/CLI,
=(yet more improvement)=> .NET,
=(yet more improvement)=> .NET,
=(slight improvements)=> .NET
In all those case it was quite obvious from the get go that the improvement were there...
On the other hand, going the Scala way seems contrived and a regression (Java interop? for god's sake man!)
I would definitely be more excited by Go[^], Rust[^], D[^], if not for the lack of good Windows GUI library!
|
|
|
|
|
I think the "efficient immutable data structures" and "first class functions" are the key.
Immutability allows programs to take better advantage of concurrency.
If you haven't coded in a functional language for any time, I would recommend it - it will change the way you approach problems.
I'm with Uncle Bob on this - the more languages you learn, especially ones quite different from those you're familiar with - will keep making you a better developer.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Those are all great points and I agree with you. I recently watched the Pluralsight video, Applying Functional Principles In C# by Vladimir Khorikov and it was fantastic. For a (long) while I felt like functional programming was just ugly syntax, then after watching that I saw that it is actually a paradigm shift to development thinking.
I really like the idea of methods that have no side effects and which always return expected types.
Fantastic stuff and a completely different way of thinking.
|
|
|
|
|
raddevus wrote: Pluralsight video, Applying Functional Principles In C# by Vladimir Khorikov and it was fantastic.
Cheers. Just added to my playlists.
I'm studying a bit of F# at the moment, prompted by a machine learning book I'm reading that uses F#. I started to get a bit lost with the F#, so I'm returning to it for a while. I've had several attempts. It's difficult to retain if you're not using it day to day.
Kevin
|
|
|
|
|
Keep at it, I've been studying Haskell on/off for a couple of years, some bits (monads especially) are only now really sinking in.
Most of us have spent all our time learning imperative languages, the change to functional thinking is much harder. Happily, I am sure that it has made a better programmer whatever language I am using at the time.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
