4 ms·

I don't enjoy being a lone gunman. Being able to lean on other peoples' libraries and works on Github is an incredible boon and timesaver. Reinventing everythi

I don't enjoy being a lone gunman. Being able to lean on other peoples' libraries and works on Github is an incredible boon and timesaver. Reinventing everything yourself on F# is scarcely an option, especially if you're seeking a valuable community to collaborate with. You might as well tell everyone who doesn't like the government to go buy a farm and live off the land. When I am in the mood for being adventurous, I go with something that makes me feel truly transcendent in productivity, like Clojure. Plus, I still get an awesome community. Hell, I've had Rich Hickey answer my questions before. Where else could I possibly have such a grin-inducing experience?

DanielBMarkham 16y ago
I guess I don't understand your criteria. There's plenty of help available on F#. Mono was painful, at least for me, but nothing like C++ or .NET internals. When I'm coding I look for community support and ease of solutions. I have that. So why again would I switch? I guess what I'm saying is that I don't understand your criteria. Who cares if famous person X answers your question? I just want to get my work done, not become a celebrity or hang out with the cool kids. Once I decided to move to linux I thought about moving to OCaml, Java, or Haskell. It's really not that big of a leap, and I've done some Java and OCaml in the past. But in the end I liked having other .NET folks making assemblies that I could pull into .NET and use. A zillion guys out there coding for the CLR, and I can leverage that. All that other stuff -- TDD, CI, good abstractions, dependency management, etc -- that's just good coding practices. Has nothing at all to do with .NET, does it? In you have a hammer and it's not working, stop hammering. But you don't have to throw out your entire toolbox. Just pick up the screwdriver. In fact, that's the difference between the tool -- VB, C#, MVC, whatever -- and the toolbox. Seems like you just jumped from one example to a broad generalization. Whatever works for you, though. That's my whole point: instead of making big generalizations about the state of microsoft, .net, and the community, just mind your knitting. You'll kill more time thrashing around reacting to perceived problems than you'll save from a new platform. Don't do that. This isn't really an argument for or against .NET. Perhaps Java rocks for you. Just don't waste time trying to find the perfect language. Instead go make things that people want. Even if you do that at 50% efficiency, you're still better off than using the perfect tool making a bunch of stuff that has no value. There is a cost to switching.
- shortlived 16y ago
  > Mono was painful, at least for me I'm interested to hear more about mono, what was painful exactly? How is the performance compared to the MS implementation?
  - DanielBMarkham 16y ago
    I plan on writing a long blog post once I get it all nailed. It will probably go something like this: the linux environment is like running an operating system at the same time while you're coding it -- little pieces of code and scripts here and there. That makes linking, compiling, and installing the primary chores. Although there is an awesome package manager, it doesn't have the coverage you'll probably need. So lots of different pieces to plug in, lots of advice on the net, some of it bad or incomplete, and instead of just googling you end up doing quite a bit of thinking as you assemble your development environment and OS. Nothing at all like the VS2010 pnp stuff. But I'm specifically referring to F#, which is a PITA on mono right now. I understand it's going to become part of the standard distro. Can't wait for that to happen. The default Monodevelop c# environment looks easier, but even then I'm having to do things like figure out where the gac is, find sql drivers and install them, bludgeon my way through mono dll linkage problems (Hey mono -- it's in the gac, it's in the directory, and you can compile it. Why the frack can't you find it when you run the program? I have to statically link my mysql driver, making my 2K executable into 1.5MB. That's hosed.) Example #2: I have some generic type magic that works fine in Windows. Basically I throw an object at a function and it generates an SQL INSERT for me. Works and tested and being used in Win. Over in mono, however, for the type name all I'm getting is "System.Object" which, of course, is the correct base type, but not the real type name the caller is using. Can Mono handle this type-fu? Or am I stepping into some area the Mono guys just haven't developed yet? Don't know. Could be a while trying to track that down. Just like all these other snags. It just seems like every little thing is more painful than it should be. Like debugging. Still haven't figured out how to get the interactive debugger to work on F#. I'm sure after an hour or two I'll figure it out -- or not. And there's 20 things like that. Because I'm new to the entire thing, each little step hurts. I think it's doable, I think it's worthwhile, but if I were taking a team through this I would definitely want somebody onboard who has already been there, done that (and could mentor). Quite frankly doing it on my own gets a bit discouraging at times.

DanielBMarkham 16y ago

I guess I don't understand your criteria. There's plenty of help available on F#. Mono was painful, at least for me, but nothing like C++ or .NET internals. When I'm coding I look for community support and ease of solutions. I have that. So why again would I switch? I guess what I'm saying is that I don't understand your criteria. Who cares if famous person X answers your question? I just want to get my work done, not become a celebrity or hang out with the cool kids. Once I decided to move to linux I thought about moving to OCaml, Java, or Haskell. It's really not that big of a leap, and I've done some Java and OCaml in the past. But in the end I liked having other .NET folks making assemblies that I could pull into .NET and use. A zillion guys out there coding for the CLR, and I can leverage that. All that other stuff -- TDD, CI, good abstractions, dependency management, etc -- that's just good coding practices. Has nothing at all to do with .NET, does it? In you have a hammer and it's not working, stop hammering. But you don't have to throw out your entire toolbox. Just pick up the screwdriver. In fact, that's the difference between the tool -- VB, C#, MVC, whatever -- and the toolbox. Seems like you just jumped from one example to a broad generalization. Whatever works for you, though. That's my whole point: instead of making big generalizations about the state of microsoft, .net, and the community, just mind your knitting. You'll kill more time thrashing around reacting to perceived problems than you'll save from a new platform. Don't do that. This isn't really an argument for or against .NET. Perhaps Java rocks for you. Just don't waste time trying to find the perfect language. Instead go make things that people want. Even if you do that at 50% efficiency, you're still better off than using the perfect tool making a bunch of stuff that has no value. There is a cost to switching.

shortlived 16y ago
> Mono was painful, at least for me I'm interested to hear more about mono, what was painful exactly? How is the performance compared to the MS implementation?
- DanielBMarkham 16y ago
  I plan on writing a long blog post once I get it all nailed. It will probably go something like this: the linux environment is like running an operating system at the same time while you're coding it -- little pieces of code and scripts here and there. That makes linking, compiling, and installing the primary chores. Although there is an awesome package manager, it doesn't have the coverage you'll probably need. So lots of different pieces to plug in, lots of advice on the net, some of it bad or incomplete, and instead of just googling you end up doing quite a bit of thinking as you assemble your development environment and OS. Nothing at all like the VS2010 pnp stuff. But I'm specifically referring to F#, which is a PITA on mono right now. I understand it's going to become part of the standard distro. Can't wait for that to happen. The default Monodevelop c# environment looks easier, but even then I'm having to do things like figure out where the gac is, find sql drivers and install them, bludgeon my way through mono dll linkage problems (Hey mono -- it's in the gac, it's in the directory, and you can compile it. Why the frack can't you find it when you run the program? I have to statically link my mysql driver, making my 2K executable into 1.5MB. That's hosed.) Example #2: I have some generic type magic that works fine in Windows. Basically I throw an object at a function and it generates an SQL INSERT for me. Works and tested and being used in Win. Over in mono, however, for the type name all I'm getting is "System.Object" which, of course, is the correct base type, but not the real type name the caller is using. Can Mono handle this type-fu? Or am I stepping into some area the Mono guys just haven't developed yet? Don't know. Could be a while trying to track that down. Just like all these other snags. It just seems like every little thing is more painful than it should be. Like debugging. Still haven't figured out how to get the interactive debugger to work on F#. I'm sure after an hour or two I'll figure it out -- or not. And there's 20 things like that. Because I'm new to the entire thing, each little step hurts. I think it's doable, I think it's worthwhile, but if I were taking a team through this I would definitely want somebody onboard who has already been there, done that (and could mentor). Quite frankly doing it on my own gets a bit discouraging at times.