osd

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?

The implication wasn't clear because, frankly, it's a silly thought. This post is ripe for that "that's not how any of this works" meme.

I can understand the emotional intent, but it's important to ensure that routes we take actually get us to the outcomes we want.

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.

if the terrorist organization is able to fund itself, then no, 10 to 1 is not money well spent. You'll lose in the long run.

As someone who has switched almost entirely away from .net to go, this is absolutely untrue. I'm fairly certain the issue was PEBKAC

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.

"not least of all, the variety of form factors and new players such as Chrome OS, which isn't included here for logistical reasons."

From the article, no the chromebook is not the reason for the bump in linux. It would be interesting to know exactly why chrome os is not counted.

My guess on Apple's dip is that Apple's current offerings are not that great compared to where they stood 4-5 years ago.

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.

No, no no no.

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.

You got extremely lucky. Not that windows is much better, but in general there are hiccups to upgrading with most linux distros as well as windows.

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

http://macdailynews.com/2007/10/02/lecture_hall_photo_shows_...

That's apparently the school of journalism...

That's an unfair comparison. Python is notoriously bad with memory/speed in every flavor

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

I could see how this statement could be construed as inflammatory, but I don't think he was implying that Go is a play toy. He was implying that you can't make a judgment on the language based on making play toys (the toy IRC client mentioned in the article).

This is a really weird article. It manages to "cover" a huge amount of ground while simultaneously saying pretty much nothing.

This is a guess, but if I were to have a problem with the term CQRS Library, it is that the query and command sides of CQRS really shouldn't be linked in any way. CQRS is a methodology that stresses that decoupling above all else. If your the command and query portions of your CQRS tech stack both fall under a single library, that seems to go against the methodology.