If I had to work in c# / f# what would I miss most?

Am 07.01.2012 17:38, schrieb Tim P:
> Hi guys,
> I've used neither c# nor f# and was wondering what the major "losses"
> and the benefits would be of switching development to such an
> environment for reasons of interoperability with existing software.
>
> Tim
>
for me it would be the ide. last time i checked, Intellij idea > any c# IDE

On 2012.01.07. 17:38, Tim P wrote:
> Hi guys,
> I've used neither c# nor f# and was wondering what the major "losses"
> and the benefits would be of switching development to such an
> environment for reasons of interoperability with existing software.
>
> Tim
>
In F# - no type classes, less flexible class/interface declaration (the
dependencies almost have to be a partial ordering; this might be on the
plus side, although -for me- this was a little inconvenient working with
APIs designed to C#/VB.NET/C++), different type inference (less types
required to be declared in the public API, not always good). The
implicit conversions are not so implicit usually (this might be my
fault, I am not sure).

In C# - no pattern matching, no anonymous classes, no type classes

Just some things that I found to be not so comfortable. Your preferences
might differ. (Both languages are pretty good in my opinion.)
Cheers, gabor

Well, having used C# and .Net for the past six months, here is what
I'd say the losses are compared to scala.

- Language. I of course Scala is a much better designed and more
productive language than C#. C# is kind of a kitchen sink language
with lots of features tacked onto it every release. While I actually
really enjoy using the language, I much prefer Scala.
- Integration. Scala mixes OO and functional much better than F#
appears to based on my studies. I also get the impression that
Scala's tooling integration with Java is better. F# doesn't support
joint projects with C#, for instance.
- Cross platform compatibility. We use mono to run our C# code on
Linux. I am both impressed at how good mono is given its youth and
lack of resources, and also impressed at how far it has to go. If you
want your code to run on more than one (desktop)OS, the JVM is a much
better technology.
- Open source ecosystem. This hasn't been a problem for us, but
there's a lot more open source code to take advantage of on the JVM.
This is especially true for web development.
- Scriptability. The .NET workflow assumes that you're going to use
visual studio on Windows. You can work at the level of scripts and the
command line, but this is easier on the JVM on a Linux box. As a
programmer, I like to automate things with scripts, but I find it
harder to do so on .NET in Windows.
- Testing. There does not seem to be a good automated testing
ecosystem in .NET. VS has a built-in unit tester but it has bugs and
is apparently deprecated due to lack of customer interest. I haven't
used NUnit but have heard good things about it. Overall, though, the
testing culture, libraries and integration with build processes seems
much better on the JVM.

And now, the strengths!
- Visual Studio is pretty rock solid, of course, and I've heard good
things about resharper. I don't know how the F# IDE compares to
Scala's, though.
-C# is a pretty decent language on its own right if you decide to use
it instead of F#, even if the functional features are a little
lacking.
-Native code integration. It's so easy to call native code in C#! It's
also easier to write performant code with structs, richer primitive
support, reified generics, and unsafe code.
- Compilation time. C# compiles fast, and while I've never used F#, it
probably compiles a lot faster than Scala with much less resources.
- F#, when you stick to the functional side, is probably considered
more "functional" than Scala in that it has full type inference and
proper tail recursion. The JVM in general seems more hostile to
functional languages than the CLR.
- Better Windows integration. If you're only targeting Windows, then
of course .NET meshes with the OS way better than the JVM does.

On Jan 7, 10:38 am, Tim P wrote:
> Hi guys,
> I've used neither c# nor f# and was wondering what the major "losses"
> and the benefits would be of switching development to such an
> environment for reasons of interoperability with existing software.
>
> Tim

I'm in the reverse situation - evaluating whether it is worth
investing in learning Scala from an F# background.

Whether it the choice of programming language, OS, VM, development
tool, VCS or whatever, I've noticed that while I always draw up some
personal laundry list of desirable features that I think I'll need and
compare on that basis, it is always an eye-opener to sit down and
actually try out the contenders. The 'ergonomics' tend to be the big
decider in the end - after spending a week using the whatever, do you
feel like it was a help or a hindrance? For programming languages, it
is surprising as to how much you can work around the lack of a feature
if you really need to - although if that becomes too much of an effort
than that counts as a minus as regards ergonomics.

What I'm doing is to port a complete project I wrote myself a while
back in F# to Scala.

That way I can do a performance comparison of like against like,
knowing that the codebase is not some benchmark that bears little
relationship to the solutions I have to deliver; instead it is real-
world code of significant size written to solve a real problem
according to the way I know I work in. So no surprises, and
personalised to me.

Of course, it means I'm not exploring whether I would have solved the
problem in some completely different way in Scala as opposed to F# -
but to be honest I don't think this would have been the case, as I
used a functional programming approach and then wrapped the
implementation up at a higher level in OO constructs. I'm sure I would
have done exactly the same in Scala, especially given I spent some
time thinking about the problem in the abstract before starting to
code (in fact to start with I was going to go for C# as the
implementation language - I jumped to F# for the implementation after
writing the initial set of unit tests in C#, which turned out to be a
good move).

I am hoping to explore whether some of programming-in-the-small design
can be changed in the Scala port to suit Scala better, and as to
whether the code is easier to deal with as a result.

Other criteria I'll check are how good the tools and testing
environment are. I've had more than enough vi, edlin and Emacs to last
a lifetime - these days I want IDEs with navigation, refactoring, test
integration and debugging all built in if I can get it.

Finally, what is the deployment story under the JVM versus the CLR? -
Especially regarding binary compatibility when library components
and / or dependent applications get changed in isolation on a
deployment site. For several client sites I've worked at, this is an
absolutely critical issue - you simply cannot just push out the entire
software stack in one go when things need updating. You may also have
to deal with native code integration: it's been a while since I had to
deal with native code and Java - since then, OneJar has come into
existence - but the deployment of native libraries used to be a
nightmare under the JVM.

So my advice - albeit rather time-consuming for you - is for you to
take a small chunk of existing software and port it: see how you feel
with the results.

On 2012, Jan 8, at 3:26 PM, Gerard Murphy wrote:
> Finally, what is the deployment story under the JVM versus the CLR? -
> Especially regarding binary compatibility when library components
> and / or dependent applications get changed in isolation on a
> deployment site. For several client sites I've worked at, this is an
> absolutely critical issue - you simply cannot just push out the entire
> software stack in one go when things need updating.

Interesting statement. Why not?

You will probably find that the jdk is much less tightly coupled to the OS than
the CLR is. We have the same issues with library compatibilities from the jdk up, though.

yours
Geir

Hi Geir,

Just so that we are on the same page, I'm referring more to the issue
of binary compatibility of library components built to run on the
JVM / CLR, rather than the ones shipped with the VMs (although there
are similar issues there too).

To appreciate that this might be an issue, you need to spend some time
working at any of the big investment banks. I'm not going to go into
detail about their working practices for obvious reasons, but this is
a genuine issue for them, and at least partially due to real technical
issues.

I do know of one bank that has circumvented that problem in a scorched-
Earth manner, but they have nothing to do with either the JVM or CLR -
so no point going into that here. :-)

Regards,

Gerard

On Jan 8, 2:32 pm, Geir Hedemark wrote:
> On 2012, Jan 8, at 3:26 PM, Gerard Murphy wrote:
>
> > Finally, what is the deployment story under the JVM versus the CLR? -
> > Especially regarding binary compatibility when library components
> > and / or dependent applications get changed in isolation on a
> > deployment site. For several client sites I've worked at, this is an
> > absolutely critical issue - you simply cannot just push out the entire
> > software stack in one go when things need updating.
>
> Interesting statement. Why not?
>
> You will probably find that the jdk is much less tightly coupled to the OS than
> the CLR is. We have the same issues with library compatibilities from the jdk up, though.
>
> yours
> Geir

On 2012, Jan 8, at 4:10 PM, Gerard Murphy wrote:
> Just so that we are on the same page, I'm referring more to the issue
> of binary compatibility of library components built to run on the
> JVM / CLR, rather than the ones shipped with the VMs (although there
> are similar issues there too).

Ah. Right. No, those are not so big in Scala, provided you are not trying to run multiple
applications in the same container. If you try that, you deserve all the problems you get.
T'is a silly decision to make. :)

The other part is that we (as in my team) have functional system tests. If something
breaks, we have a safety net. That makes it easier for us to move forward confidently.

You will experience compatiblity issues with the scala language itself - or at least, we
have for every release so far. This is part of the reason we are still on 2.8.1.
The benefits still outweigh the drawbacks for us, at least as long as I can keep hiring
above average developers for a sensible amount of money.

yours
Geir

On 8 Jan 2012, at 15:36, Geir Hedemark wrote:
> On 2012, Jan 8, at 4:10 PM, Gerard Murphy wrote:
>> Just so that we are on the same page, I'm referring more to the issue
>> of binary compatibility of library components built to run on the
>> JVM / CLR, rather than the ones shipped with the VMs (although there
>> are similar issues there too).
>
> Ah. Right. No, those are not so big in Scala, provided you are not trying to run multiple applications in the same container.
> ...
> You will experience compatiblity issues with the scala language itself - or at least, we have for every release so far

Perhaps we're interpreting Gerard's question differently, but I find your experience surprising, as mine has been the exact opposite. Yes, there are differences between compiler releases, but I've not typically found them too hard to cope with. Whereas there is, in general, no binary compatibility between a library compiled with one major version (e.g. 2.8.x) and code compiled with another (e.g. 2.9.x). Sbt's cross-build functionality is an attempt to address this problem.

This is a very major issue indeed, and one of the primary reasons why, so far, we've stuck to using Scala for test code only and have no production code written in the language.

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: paul@paulbutcher.com
AIM: paulrabutcher
Skype: paulrabutcher

On 2012, Jan 8, at 4:55 PM, Paul Butcher wrote:
> Perhaps we're interpreting Gerard's question differently, but I find your experience surprising, as mine has been the exact opposite. Yes, there are differences between compiler releases, but I've not typically found them too hard to cope with. Whereas there is, in general, no binary compatibility between a library compiled with one major version (e.g. 2.8.x) and code compiled with another (e.g. 2.9.x). Sbt's cross-build functionality is an attempt to address this problem.

I see the problem you are describing, and I can't see that we are experiencing it. We have chosen to have scala code in production.

SBT is working out fine for us. But as I said, we have chosen to stay on 2.8.1 for now since we don't see a compelling reason to move to a newer version. We have other fish to fry.

We have also rejected most of the scala-based libraries since they were poorly documented and too unstable (as in "rewritten too often") for us to want to use them when we started out two years or so ago. I suspect this reduces our library compatibility issues significantly, even if we are now stuck with a bunch of fairly static java libraries which are not always a good fit for the scala way of doing things.

The upside is that the libraries we use are somewhat stable and won't consume our precious time, which we want to spend writing code that gains our business some benefit, not upgrading libraries.

YMMV.

yours
Geir

Besides the point mentioned one important thing that drove me back to
the JVM after a few years in c# was the dependency on Microsoft.
If you are not able to use Mono and forced to use .Net you are bound
to use everything from MS. Visual Studio, TFS, Windows etc.
VS also needs the Resharper Plugin to be on the same level as Eclipse/
IntelliJ.

On Jan 7, 5:38 pm, Tim P wrote:
> Hi guys,
> I've used neither c# nor f# and was wondering what the major "losses"
> and the benefits would be of switching development to such an
> environment for reasons of interoperability with existing software.
>
> Tim

implicit, kind polymorphism.

Hi guys,
I've used neither c# nor f# and was wondering what the major "losses"
and the benefits would be of switching development to such an
environment for reasons of interoperability with existing software.

Tim