|
I have to agree...
Also, does anyone else notice a striking similarity to Python?
|
|
|
|
|
It feels similar to a lot of dynamic languages...and even feels like LISP at times. It feels like C# did back in the early days...like it was a blend of the best of the best (C++, Java, VB, etc.), without the useless fluff.
|
|
|
|
|
What the F# is F#?
I feel Im getting old, not in the physical respect and certainly noy in the arithmetic way
But those new languages...
In my time I have learned C/C++ VB6 and java but always worked with something else. Always being the one who should take care of the old system until the new stuff was mature and stable or bridging the old and new stuff together.
The new stuff NEVER emerged... There was never recources enough or it was just not doable to migrate the old system to a new platform/language etc.
I always wanted to use the meethods and tools learned. Not because it was cool but because it would solve the problems with minimum effort and leave a managable system behind. Well documented and easy to maintain and scale up.
I have learned to build miracles with chewingum and old socks. I have keept the old smoking heaps of rubish alive and going. The future never arived, it was there all along. In the moment of triumf, of the joy of writing the next piece of software to save the customer some salary...
But, you know what they say: you are only as good as your last project...
Java
C#
Gupta Team Developer 3.1
VC++ 2003
Oracle 8i79i
W2K-XP
|
|
|
|
|
I agree completely, (I have 30 years of programming experience) and I experienced similar situations.
|
|
|
|
|
Jon Rista wrote: I can see it having tremendous potential as a scripting language.
WHy do you say that? F# is a compiled, statically typed language and is more suitable as a replacement of C# than a scripting language. If you are looking for a scripting language that runs on .NET platform, consider IronScheme, IronPython or IronRuby.
|
|
|
|
|
Because of #light mode, perhapse? And it doesn't have to be compiled...like any language, its a set of rules...syntax, semantics, etc. and it will be an open standard like C#. Wouldn't be that hard to write a parser for it and interperate F# "script" if a scripting language was needed for an application.
Also, F# will never be a replacement for C#...at best a compliment. It wasn't designed to solve the same kinds of problems C# was designed for.
|
|
|
|
|
Jon Rista wrote: Because of #light mode, perhapse?
What about #light mode? It merely removes some OCaml syntax.
Jon Rista wrote: Wouldn't be that hard to write a parser for it and interperate F# "script" if a scripting language was needed for an application.
No, but the same can be said for C#.
Jon Rista wrote: F# will never be a replacement for C#...
Unfortunatelly that is probably true, but not because they cover different use case scenarios (they don't) but because people are used to their ways. Also, there is already a lot of legacy C# code out there.
|
|
|
|
|
Nemanja Trifunovic wrote: What about #light mode? It merely removes some OCaml syntax.
Which makes it about the perfect "weight" for script. 
Nemanja Trifunovic wrote: No, but the same can be said for C#.
True enough, but with C#, you need to have a full class at some point. With F#, you can keep it light weight and simple. Both "could" be used as script...F# lends itself better to it.
Nemanja Trifunovic wrote: not because they cover different use case scenarios (they don't)
C# is an (imperative) OO language, and primarily covers the scenario where we define how to solve problems algorithmically. F# is a (declarative) functional language, and covers the scenario where we define what we need and what to do, but not specifically how to do it. How to do it vs. what to do. The latter is ideal from a scripting standpoint where your most probably automating a system that contains the "how to", and your just telling that system "what to do".
(C# offers some functional capabilities via Lambdas, type initializers, and type inference...but those limited functional capabilities can't replace F#.)
|
|
|
|
|
Rather than deal with the largely arbitrary class hierarchy of .NET, I'd prefer to count parentheses in LISP or track a Forth stack in my head.
|
|
|
|
|
Severian@Severian.org wrote: largely arbitrary class hierarchy of .NET
Largely arbitrary? How so? 
/ravi
|
|
|
|
|
Care to explain how the .NET framework class hierarchies are "arbitrary"?
|
|
|
|
|
Jon Rista wrote: Care to explain how the .NET framework class hierarchies are "arbitrary"?
Anyone who likes LISP is obviously a troll.
|
|
|
|
|
LISP has its place and solves certain problems very well. I don't particularly like its syntax (rather I think its atrocious), but it does have its place.
|
|
|
|
|
I'm sure you're correct. My post was in jest mostly. I don't know enough about LISP to make a real judgment on it.
|
|
|
|
|
Well, perhapse this would help shed some light (and humor) on the subject:
http://xkcd.com/297/
http://xkcd.com/224/
http://xkcd.com/312/
|
|
|
|
|
 I like the second one the best.
|
|
|
|
|
"My god, its full if 'car's"
|
|
|
|
|
I don't know about "largely", but there are some concerns. Like why ArgumentNullException and InvalidArgumentException don't agree on which order the parameter name and message should be in. 
(That's the only one that comes to mind at the moment.)
|
|
|
|
|
Two separate teams worked on each exception and they never spoke to each other 
Sunny Ahuwanya
"The beauty of the desert is that it hides a well somewhere"
-- Antoine de Saint Exupéry
|
|
|
|
|
Thank you, Captain Obvious.
|
|
|
|
|
PIEBALDconsult wrote: ArgumentNullException and InvalidArgumentException don't agree on which order the parameter name and message should be in
Mainly because there were really no defined standards for .NET when .NET 1.0 was first developed and it was something that "slipped through the cracks". Unfortunately, at the point it was discovered (after .NET 1.0 shipped), there was so much legacy code around that for Microsoft to have fixed it that they decided it was too large of a breaking change and so we are stuck with it.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
...er, and you get paid for that, right? 
|
|
|
|
|
I hate .net, but like I recently stated in the general discussion forum, when it comes to putting beans on the table, you gotta put philosophical considerations aside, and simply do what you gotta do.
"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
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: I hate .net, but like I recently stated in the general discussion forum, when it comes to putting beans on the table, you gotta put philosophical considerations aside, and simply do what you gotta do.
Agreed. It's why I have used classic VB for many years in the past. I try to hide that fact though. 
|
|
|
|
|
I guess I'm lucky. I don't have to use .NET: I put beans on the table using real C++, C, SQL, and the occasional bit of Python (for scripting) and rare assembly language (for performance).
Three sure signs that I probably don't want to install an (end-user) program:
- Requires VB runtime
- Requires Java runtime
- Requires .NET runtime
Maybe I just don't like runtime libraries!
I suppose since there are exceptions for .NET (I use Visual Studio, after all), it's the least of three evils. I've yet to see a Java or VB application that was what I consider commercial quality, though VB.NET certainly comes closer than earlier incarnations.
For me, .NET (and Java) put too many layers between the application and the hardware: too many unpredictable points of failure.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
