I don't refactor with fear in my Rails apps since they have pretty good test coverage. I'm not saying it's perfect, but I've never had slow development because I wanted to refactor in this context.
It's been slower for me, personally. I write half the tests in Haskell than I had to in Python which means less updating of tests as requirements change. It won't feel slow to you until you've written productive (beyond beginner) software in Haskell.
New Haskell developers spend a bit of time figuring out why the types of an expression aren't what they think they are, especially when wading into using some of the libraries with more sophisticated use of types.
I'm not certain what you're asking. If you mean it's unfair to compare experienced Ruby developers to new Haskell developers I agree, I was just explaining where the sentiment was coming from (insofar as it was legitimate).
You're assuming that difficulty is a single constant, which is definitely not the case. The real state of things is that Haskell is more difficult than Ruby to get really good at, but the actual work of developing things in Ruby is much more difficult than developing things in Haskell. This is because when you develop things in Ruby, you spend a lot of time debugging heisenbugs due to the total lack of referential transparency.
Accordingly, yes, newcomers to Haskell will probably have difficulty understanding what the type system is telling them, and this will slow them down a bit. But analogously, newcomers to Ruby (especially those using a heavyweight framework) will have difficulty figuring out why their application is doing what it is, and this will slow them down a lot.
(Source: I've worked professionally in both languages.)
Comments
Not only true but faster because less time spent debugging.
And it's faster and easier to add new features because you can refactor without fear.
I don't refactor with fear in my Rails apps since they have pretty good test coverage. I'm not saying it's perfect, but I've never had slow development because I wanted to refactor in this context.
It's been slower for me, personally. I write half the tests in Haskell than I had to in Python which means less updating of tests as requirements change. It won't feel slow to you until you've written productive (beyond beginner) software in Haskell.
Only if you don't count debugging whatever the fancy type system is doing vs. what you need the behavior to be
What does this mean? I don't think most Haskell users spend a lot of time debugging the type system.
New Haskell developers spend a bit of time figuring out why the types of an expression aren't what they think they are, especially when wading into using some of the libraries with more sophisticated use of types.
Now, It's "New Haskell developers" vs "New Ruby/RoR developers". Isn't it?
I'm not certain what you're asking. If you mean it's unfair to compare experienced Ruby developers to new Haskell developers I agree, I was just explaining where the sentiment was coming from (insofar as it was legitimate).
Well, New Ruby developers doesn't have the same problem. They can move much faster than the initial uphill struggle that is Haskell.
Essentially, there are three sitations:
a) Everything is of the same difficulty. b) Haskell is more difficult than Ruby. c) Ruby is more difficult than Haskell.
I'd say (b) is a much saner conclusion.
You're assuming that difficulty is a single constant, which is definitely not the case. The real state of things is that Haskell is more difficult than Ruby to get really good at, but the actual work of developing things in Ruby is much more difficult than developing things in Haskell. This is because when you develop things in Ruby, you spend a lot of time debugging heisenbugs due to the total lack of referential transparency.
Accordingly, yes, newcomers to Haskell will probably have difficulty understanding what the type system is telling them, and this will slow them down a bit. But analogously, newcomers to Ruby (especially those using a heavyweight framework) will have difficulty figuring out why their application is doing what it is, and this will slow them down a lot.
(Source: I've worked professionally in both languages.)
Today I learned that a bug of which you can only know either its position or its velocity but not both to any significant degree, is a heisenbug.
I'm not sure if you're joking, but Heisenbug is used to mean "bug that changes when you try to observe it".
I think You are assuming that the learner here is already a (imperative or OOP categorized) programmer who is willing to learn these two languages.
For ruby still there would be some topics you need to know about before trying to learn language itself, if you are just starting out.
"You are assuming that the learner here is already a (imperative or OOP categorized) programmer who is willing to learn these two languages."
To be fair, that is not an uncommon situation.
agreed