> Do. Not. Break. Workflows. Software that doesn't understand this principle is something I don't trust not to break itself when its developers decide to get cute.
What use would magit be if it presented the exact same interface as `git rebase`?
Do you know what it would lose?
> Did I stop and read the docs to figure out how it wanted me to rebase in this brave new world? Hell no.
I suppose you don't since you didn't read the docs.
Why try it in the first place if you expected it to be the exact same?
> they're case classes then you're moving around a lot of unnecessary data fields and you've got the overhead of making fifty intermediate case classes yourself.
Haskell developer here... What about case classes and lenses? Do they solve this?
As I understand it lenses don't change the underlying data structure. For ETL you need a way to basically say "the code only uses fields X, Y and Z so we will only load X, Y and Z during runtime." Automatically based on usage without having to keep updating your lens definition. Modern on disk file formats are columnar so they can very efficiently read subsets of the data. If your data has 200 columns than reading the 199 unnecessary ones can be very slow.
They could help with the intermediate data structure but some of them aren't subsets or trivial derivatives. So you really need an inline way to create single use case classes. I think frameless in Scala can do some of this for standard transformations but that requires the black magic of shapeless.
Spark in Python (and the untyped Dataframe API in Scala) compiles everything internally before running it to achieve the above. So it's trivial to have unit tests on empty data structures which "type check" your Spark code.
Cardelli's definitions are extremely odd; if you take them literally then Python is type safe but Java is not.
In everyday language a downcast, even a checked one, is not a type-safe operation, and so to the extent that Go's limited type system makes it impractical to write programs without downcasts I'd say that Go is fundamentally type-unsafe.
Well, it's a matter of taste, I guess. In my opinion any downcast that reliably distinguishes between valid and invalid values is type-safe. The behaviour of
defer func() {
if e := recover(); e != nil {
fmt.Printf("not a string %v\n", e)
}
}()
v := interface{}(5)
u := v.(string)
fmt.Println(u)
is well-defined: it will print "not a string", always.
By that logic there's no such thing as a non-type-safe language, because all programs have behaviour.
Normally one would say a checked downcast like that is not type-safe, because you can't reason locally about the type behaviour of the downcast based on knowing the type of v. You would have to know the value of v, which is a Turing-complete problem in the general case.
> All the magic will make them feel confused and powerless when they do anything outside of the blessed path.
Maybe, but what are the chances they chalk it up to a normal and acceptable learning path?
> They can't extrapolate that forM_ works for any monad in the future.
I think it's important people know that, but how much does it matter for IHP's intended audience?
> Agreed, I wish we all used |> instead of &, but that operator is called & in Haskell. You're crippling your users' ability to read other code-bases in the future
I think this is an important point, but I'm not sure how much it would matter for most.
> And that same code would be plenty readable with &, don't you agree?
Most would assume & means something with boolean and I bet. I find & readable, but even Haskellers on my team didn't really seem to take to it.
> There's so much more to "building" than the first month of development!
People don't really value the long term but default I've found. Then once they have committed to something to a degree, they don't change from it.
If IHP makes it easy enough to get to the point of feeling like one should keep using it rather than starting over...
Maybe the extra learning challenge will feel "normal", worth it, and otherwise motivated.
> Haskell is an order of magnitude more productive for me than other languages (ruby), because of its differences.
I can relate to this, but coming from Python. Others who aren't sold on Haskell by it's usually toured virtues are probably likely to be sold by getting someone spun up to hack away on more quickly.
I find making a lot of these arguments kind of funny since I typically find myself arguing from your position :)
> There are keyboards for people who want a truly ergonomic input system and there are keyboards for fanboys
> Kinesis advantage 2 is for the first kind and ergodox is for the fanboys
Maybe it's true, but I bought the Moonlander (same brand as ergodox) for ergonomic reasons. It allowed my hands to be more in line with my shoulders and reduced shoulder pain/tightness I would have at the end of the day.
I want to try the Kinesis advantage, but one thing stopping me is the fact that it's not a split keyboard. I think it's likely my natural arm position is wider than the Kinesis.
> The most efficient tools are usually the most ugly and boring ones
I think there's some truth to this, but speaking it as such an absolute truth seems misguided.
> I was spending my free time dabbling in Haskell. His response was 'lol, why would you do that?'. His point was that spending time learning things that you're not going to be using directly any time soon is a waste of time.
Just as an anecdote, if you are persistent enough you can learn Haskell and get a job writing it :)
