|
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.
|
|
|
|
|
I've been coding, and paying the bills quite well with, C# for the last six or so years. Prior to that, years and years of VB classic. I cut my teeth on straight C for MS-DOS and am now forcing myself to learn C++ and the raw Windows API for one simple reason. I keep hitting brick walls when trying to deeply integrate with Windows using .NET for desktop and system type applications. It seems like Microsoft wants the rest of the world to write everything in the .NET language of their choice, but anything core to the OS or delivered with Windows is written in C++, the core stuff still being written in good ole C.
I have no intent of starting to develop everything in C++, that would be masochistic and just plain silly. But let's face it, there is a definite bias against using .NET internally within Microsoft itself. That speaks volumes. Just try and write a shell extension or integrate with Windows beyond the level built into .NET and you'll see where I'm coming from. It's as if a giant wall was erected with a sign that says ".NET developers travel no further, C/C++ developers welcome, come on in."
I understand they don't want us .NET developers venturing into dangerous Windows API territory, but if .NET is going to be all things to all people, then they need to do a better job of bridging the gap between the Windows API and .NET so .NET developers aren't forced to jump through inordinately painful hoops to get the job done.
|
|
|
|
|
You nailed it, Michael! I have only seen a couple of "real" applications come out of Redmond that are .NET. The first one that comes to mind is Office Accounting. Most things from them are C++.
You are right; that speaks volumes.
|
|
|
|
|
Matt Sollars wrote: You nailed it, Michael! I have only seen a couple of "real" applications come out of Redmond that are .NET. The first one that comes to mind is Office Accounting. Most things from them are C++.
ASP.NET, ASP.NET MVC and LinqToSQL/Entity Framework are 100% C# and there are lots of "real" applications being developed with those tools.
Todd Smith
|
|
|
|
|
Hi Todd,
I am pretty sure Michael was referring to Windows applications. I was certainly reading his comment that way when I replied.
I think Microsoft is definitely taking initiative with regards to developing Web applications on the .NET Framework. I credit Scott Guthrie for his absolute determination to drive excellence in the Web divisions of Microsoft.
|
|
|
|
|
Indeed I was referring to desktop applications and any other application that needs to deal with the Windows API in a manner not made readily accessible from .NET. There are certain types of applications that will never be written in .NET (at least not commercially viable ones). Imaging and multimedia applications come to mind most readily. Paint.NET is cool and I use it regularly, but it's no Photoshop and the thought of creating something like Photoshop in .NET is ludicrous. The same goes for video editing apps, audio processing applications, high end games, and a lot of other things. .NET is great for gluing together components, as was classic VB, but it's no replacement for C++ and I don't really think it was intended to be. Anything that needs to integrate with the Windows shell or attain the highest performance when manipulating bytes in memory will remain most comfortably in the domain of C/C++. Period.
Yes, for web development, .NET is awesome.
|
|
|
|
|
It's because C# is horrendously inefficient. Yes, this still matters even on quad core CPU's. There are things C# is good for, but for many many things it is appallingly incompetent.
C# and C/C++ pay my bills, and the largest C# project I'm involved in is currently getting optimized by converting a chunk at a time into native C or C++.
He said, "Boy I'm just old and lonely,
But thank you for your concern,
Here's wishing you a Happy New Year."
I wished him one back in return.
modified on Monday, February 9, 2009 1:53 PM
|
|
|
|