4 ms·
I know they exist, thanks. I am asking only about the motivation for fostering a new language for the CLR, and the costs involved. I am proposing that building
by MrMan 16y ago
I know they exist, thanks. I am asking only about the motivation for fostering a new language for the CLR, and the costs involved. I am proposing that building in tool support is, while necessary for adoption, costly.
Another anecdotal aside - small teams seem to throw together Eclipse-based tools with little cost. From a UX point of view, Eclipse is not provably "better" than tools built using Visual Studio, right?
- fleitz 16y agoThe problem with Visual Studio tools are COM, and a very high overhead to get something simple working. There are a lot of magic incantations you need to know to write VS plugins. If you don't get the magic words right nothing happens. If you have programmers on staff who know Visual Studio inside out, it's pretty easy to get stuff working. Like, say if your company had the team who wrote Visual Studio. Also, the tool support for F# sucks, basically the only thing Visual Studio will do for you in F# is intellisense. Drag a dbml file into an F# project? Nope, sorry doesn't work. xaml? same thing. ASP.NET? yeah right. If you want tool support in VS you better open up the project file and start adding it in.
- MrMan 16y agoThis is a key response. I am more interested in why MSFT would spend more resources creating more languages than on streamlining the facilities for creating languages. Maybe dog-fooding these things over the last 8 years or so has spurred, or will spur product groups and/or MS Research to put as many man-years of work into the meta-tools so that languages can be launched with much less effort. I am impressed, needless to say with F# itself, and I have learned a lot from this thread that I did not know about it, but "what is F#" is not the point of my question.