F#
-
What does F# give you that either C# or VB.Net doesn't already give you? Since they're all .Net languages, and they all compile to the same level, there are no optimizations that could possibly make learning F# a "good idea". I know there are some Pascal.Net implementations, as well as Cobol, but other than allowing the programmer to use old code with minor changes, there's no reason to use those languages on new projects. Unless F# closely resembles the language used in critical LOB apps, it's merely a curiosity. EDIT ========= Voting this post a 1 isn't going to change my views.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997modified on Friday, April 8, 2011 4:34 PM
So you program in IML? after all, C# and VB.NET give you nothing you can't get in IML, right? It is all in how you are able to represent the problem and the solution, it is a different type of abstraction than you get with procedural/OO/declarative languages.
Opacity, the new Transparency.
-
Thanks. That's good to know, but it didn't answer my question. I'm curious about how popular the language is and is anyone taking it seriously?
Everything makes sense in someone's mind
-
John Simmons / outlaw programmer wrote:
Since they're all .Net languages, and they all compile to the same level, there are no optimizations that could possibly make learning F# a "good idea".
It is not about optimizations. Some problems can be solved much easier with a language like F# than C#/VB.NET.
Cite a problem that is "easier" to solve with F# than with C#.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
So you program in IML? after all, C# and VB.NET give you nothing you can't get in IML, right? It is all in how you are able to represent the problem and the solution, it is a different type of abstraction than you get with procedural/OO/declarative languages.
Opacity, the new Transparency.
No single .net language provides anything more or less than any other language when you get down to the IML. The only reason for picking one over the other (assuming you're starting a brand new app with no mandates for language use) is comfort with said language. Fortran had its benefits, Cobol had its benefits, Pascal, C, C++, etc. With .Net, those benefits are pretty much gone because the compiler optimizes the source the same way. That's what I'm trying to say. Unless F# closely resembles another language that you're already comfortable with (like C# and Java/C++, or VB with vb.net), it's just a curiosity.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
Cite a problem that is "easier" to solve with F# than with C#.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997Parsers. Edit: Domain-specific languages, iterative evaluation (there aren't many practical REPL evaluators in C#), implementing mathematical equations as code -- generally, any kind of structured data translation.
modified on Friday, April 8, 2011 6:14 PM
-
No single .net language provides anything more or less than any other language when you get down to the IML. The only reason for picking one over the other (assuming you're starting a brand new app with no mandates for language use) is comfort with said language. Fortran had its benefits, Cobol had its benefits, Pascal, C, C++, etc. With .Net, those benefits are pretty much gone because the compiler optimizes the source the same way. That's what I'm trying to say. Unless F# closely resembles another language that you're already comfortable with (like C# and Java/C++, or VB with vb.net), it's just a curiosity.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997Try running a well-written F# program through Reflector and disassemble it to C#. It won't even come close to being readable. You really don't know what you're missing out on if you think imperative languages are comparable to functional languages just because they're both turing complete. It's apples and oranges.
-
No single .net language provides anything more or less than any other language when you get down to the IML. The only reason for picking one over the other (assuming you're starting a brand new app with no mandates for language use) is comfort with said language. Fortran had its benefits, Cobol had its benefits, Pascal, C, C++, etc. With .Net, those benefits are pretty much gone because the compiler optimizes the source the same way. That's what I'm trying to say. Unless F# closely resembles another language that you're already comfortable with (like C# and Java/C++, or VB with vb.net), it's just a curiosity.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997The issue is that different languages are better able to express different concepts. Once you have the concept, you can often go back to the old language and express the concepts. The same way you can express OO ideas in c, or Z80 or PIC assembler, though they don't support it native. The real point of a new language is what you are NOT familiar with, since that is the part that expands your concept space. You learn it, not for the new syntax that express old ideas, but for the new idea parts. Then, having learned it, you can figure out how to use the ideas in your native language, and add that power. So obviously, all the power of every language abstraction is available in as low a level microprocessor machine code as you care to hash out the 0s & 1s for. Everything else, from assembler, even ILM, to C# and VB, to whatever the current fad language is, are just curiosities that let us write machine code using different viewpoints.
Opacity, the new Transparency.
-
What does F# give you that either C# or VB.Net doesn't already give you? Since they're all .Net languages, and they all compile to the same level, there are no optimizations that could possibly make learning F# a "good idea". I know there are some Pascal.Net implementations, as well as Cobol, but other than allowing the programmer to use old code with minor changes, there's no reason to use those languages on new projects. Unless F# closely resembles the language used in critical LOB apps, it's merely a curiosity. EDIT ========= Voting this post a 1 isn't going to change my views.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997modified on Friday, April 8, 2011 4:34 PM
-
I've never used it... there's always a latest and greatest, its a headache to try and keep up with every single language... :wtf:
Keeping up to date is part of your job description as a software developer...
-
Keeping up to date is part of your job description as a software developer...
i'm an engineer, not a software developer, but maybe you didn't read all the posts before commenting
-
i'm an engineer, not a software developer, but maybe you didn't read all the posts before commenting
My bad.