I'm sure this is just a troll post but wouldn't anyone your property management "caught" using this device simply say they used off the premises and that would be the end of it?
> which means runtime errors in the object tree usually causes the entire app to crash with very abstract error messages.
This is absolutely untrue. Xaml errors can be caught like any other error, and most errors get swallowed rather than crash the application (which can cause some debugging headaches when things aren't rendering as you expect).
> I used to think XAML could be better if architected well, but the missing ecosystem and usage around it made it so, that HTML was and still is massively more productive.
I don't think html is massively more productive. I'm not even saying that WPF is so much better, but start debugging any reasonably large react application and you're just as likely to get into an unproductive quagmire.
Your comment reads that you're angry at Github for not taking a more open source approach. That's a fine opinion to have, but it doesn't make sense to demonize them for being a for-profit company. They are not robbing anyone of anything.
Starving the competition with loss-leader tactics is not an unbeatable strategy. If, however, you don't have anything to offer other than a run of the mill payment processing platform, then yea, you're going to have a tough time beating someone who can cut costs. They have a feature you don't, you should lose.
$20 is less than a drop in the bucket, but $20 dollars for essentially a donation is another matter. For the companies that already contribute monetarily to open source, I don't think much changes. The unfortunate reality is that for companies who don't, not much changes.
jetbrains is doing a very good job of creating good error messages, but just like any other jvm language, you can run into huge, messy, jvm stacktraces. In my experience, Java/jvm proficiency is useful
lambda's are much more limited in flexibility when compared with linq. Because of the way java lambda's work, I imagine there are some scenarios where they are more performant, but it probably comes down to the specific problem/usage.
It's not a personal attack because I don't actually know anything about you, and I'm not claiming to. I'm making that statement in regard to your two posts up the chain. They are statements that don't reveal any solid, usable points other than to say "simpler code is easier to understand, sometimes performance doesn't matter as much" but in such a strong form as to suggest that the advice plays out a lot in the real world. It doesn't.
I have worked on large codebases. You sound less like you have a solid opinion backed up by experience and more like you enjoy spouting platitudes and best practices in meetings without getting dirty with too much code yourself.
I cannot believe that you are honestly saying a 2x increase to throughput in production is something you "shouldn't take seriously" because the code isn't as readable as it was before.
Programmers are expensive. Hardware is cheap. That doesn't justify completely throwing out the window any performance increasing changes just because a fresh college grad won't be able to understand what's going on within 10 minutes.
To be fair, the correct use case for Dispose is extremely confusing in .NET. Dispose feel like a language construct to novice developers, but it's left to library designers to properly implement it. There are multiple cases of Microsoft designed API's that don't properly implement dispose, and therefore can't properly be used with 'using.' I'm sure the amount of non-microsoft-blessed code with this issue is far larger.
Enjoyed the article. My personal battle with f# has always been searching for what is idiomatic. Everything feels a little bit foreign when you write something in f#. One of the responses the author leaves in reply to a comment is something that I found important the more I used f#, and is something that never really gets said out loud.
"Bottom line: people need to embrace the fact that F# is a hybrid language, and that the primary motivation for using F# is the .NET platform. People interested in FP but not in .NET should just try SML or Haskell. Claiming that F# is “up there” with Haskell or SML is false advertising and ultimately deals unpleasant surprises to people coming either from .NET or Haskell backgrounds."
f# needs to find its place not only in the FP world, but also in the .NET world. That's a very hard thing to do. The language is fun, and I hope it finds its way.
I've read a few of this guys blog posts and they are generally fairly interesting. This one a little less so, but I had a good chuckle from the line about why he implemented generics in magpie. "Magpie has generics because I’m firmly of the opinion that a type system without generics is about as useful as a language with functions but no parameters." Let the go programmers pour hate upon this blog post
Garbage collection does not actually solve the problem of lifetimes. At least not in the gc'd languages I am intimately familiar (c#/java). I cannot comment on whether or not Go solves the problem of lifetimes because I don't know the language well enough, but I feel confident that if it does solve the problem, it is with garbage collection in conjunction with another concept