h_r

That's what I was thinking... Why can't we solve this with non-repudiation crypto that is already available?

I have mixed feelings about the various arguments I see raised in the comments. It seems crazy to me to insist that efficiency and productivity gains via technology have, as their proper goal, a world in which none of that matters. Freeing up time in this way benefits us as individuals as well. Just staying alive and entertaining ourselves requires goal-directed behavior. I like not having to spend hours cooking food daily on an open fire.

Your argument about keyboards struck me in just this way - it's a mistake to assume that we should stick with the status quo and have machines adapt to us. After all, writing on paper (or with a digital stylus) is just another iteration of improving the technology. Nobody wants to pound symbols into stone with a chisel, for example.

I can type much faster than I can write cursively and it would be incredibly painful to revert to such writing. Natural language speech input can improve a lot of things vs typing, but I think writing code - for as long as it lasts - would be tricky to implement well using our voices.

One weak advantage is panspermia allows you to avoid the question.

That seems to be an odd way of looking at it, IMO. Most of the time, the entire point of building an API is to present consistent functionality to any consumer, not only ones under your control. Also, a well-behaved API is versioned so as to allow evolution of the API without breaking existing clients who can upgrade to new versions as they are able.

Are there significant risks from running virtualization locally like this? If so, can you provide any links or elaborate a bit so I can follow up? Most of what I've seen on such vulnerabilities refer to server infrastructure.

Seems like that would require an understanding of language that far exceeds the current state of the art. And much of the time logic doesn't even apply because the text is incoherent.

The things you cite as missing in C# can be found in F# on .NET Core. Have you ever tried it? I find it hard to stomach C# after delving deeply into F#, and you still get to use Dapper! Swagger though... not sure if anyone ever got that working well with Giraffe or any other more functional web framework. When I say "working" I mean automatically generating the Swagger docs for you.

I'm genuinely curious if there are black or African American programmers who actually use git who are offended by the term. Speaking for myself (white programmer) it just seems to be an obvious use of the adjective form of the word as either the principal branch (like master bath) or the branch from which other branches are copied (as in the initial, pristine version). If there are such comments I haven't come across them yet.

There are several comments by other white people who see this as a highly commendable act. Does anyone actually subject to racism see this move as a positive step that addresses a real problem?

With respect to evolving balls of mud, the only thing that mostly worked for me is to try to find those boundaries where you can apply the [Strangler Pattern](https://docs.microsoft.com/en-us/azure/architecture/patterns...)

This made me laugh out loud. Early this afternoon I walked by a local church on the way to do some shopping and there was a group of 8 or 9 people kneeling in front of it praying. They were holding signs with various slogans, one of which said exactly that: Churches are vital business.

I should mention this is a Catholic church that serves the Eucharist during every mass where multiple people hand out wafers to eat, using their bare hands. [edit: grammar and additions]

I hardly know where to start with this. Parachutes are not a cliche example of anything other than engineered products that are the result of well understood principles of physics, knowledge which was hardly arrived at by magical intuition. And medicine lags far far behind in the maturity of the science (my understanding as a layman).

And your final example of showing up in scientifically illiterate society wielding a miracle drug and declaring that they need no evidence of its efficacy, ignoring the fact that such evidence was all on you prior to arriving there? Sorry, I don't see how this is productive.

Again, this is the very thing that needs to be shown. You're simply repeating the same mistake.

The post I was responding to really had no _point_, per se. It merely asserted that it's ridiculous to require such experiments because... miracle drug!

It's simply a problem of what is considered to be evidence in the scientific community. If everyone "got cured by a miracle drug", that implies you already have the compelling evidence in hand that the drug, in fact, is a cure. This is an example of begging the question.

What... what?! You think that

| ...those people recorded while spreading their spit all over a train cart.

are simply acting in ignorance because they have no idea how to behave?

A very high percentage choose to buy a house or car, or have children as part of their life planning when things look fairly stable. When you grow up and have adult responsibilities, the youthful feeling of invulnerability starts to fade.

I don't want to discuss this forever but I have a couple of comments:

Your points about efficiency are a separate topic entirely from the original claim that manually writing out an imperative solution makes it easier to see the algorithmic complexity. That was a surprising claim to me because, in my experience, if I understand what some HOF is doing, reading the code is even easier because there is less of it to wade through (and mental exhaustion doesn't make one easier to read vs the other).

In every mainstream language I can think of `map foo myCollection` creates an intermediary map

You need to build up the final result, sure. Not an intermediary map but whatever structure (or functor) you're mapping over. That is the whole point of immutable data structures. Also when you're using persistent data structures, which all modern FP languages do, the cost of constructing the result can be far less than what you expect, especially if the result is lazy and you need only some of the results. There is a cost to immutability and if it's unbearable in some situation, fall back to in-place mutation but the semantics of these two approaches are definitely not the same.

But I've also seen `sum map foo myCollection` so many times

Yeah... that should be a fold (reduce, whatever). :)

I agree with everything you've said here but being mentally exhausted doesn't make it more likely that you can read even more lines of code in a more reliable fashion.

I think the clue to your thinking, for me, is in your description of the `map` HOF as "slightly more complex". Having years of experience with both paradigms, I've found that grokking a call to one of these fundamental building blocks (map, filter, reduce, fold, etc) is nearly instantaneous. We've all experienced reading prose where the author was excessively verbose when the same point could have been made succinctly. It feels the same way reading for loops once you get over the learning curve of these very basic functional constructs. You have to keep repeating that boilerplate endlessly and it's very tedious to keep writing and reading it.

That's quite an interesting, if frightening, take on it. Assuming a developer knows what `map` does, then I wouldn't have very much confidence in their reading comprehension if they somehow mentally skipped over the main higher order function being called on a three word line of code.

Would anyone expect such a developer to read and parse several more lines of code more reliably, in order to understand the algorithmic complexity? Seems unwarranted to me...

Can you explain why you think it makes O(n) blocks trivial to identify?

How is such identification made easier by manually writing out a `for` loop applying a function foo to each element rather than writing `map foo myCollection`?

They could possibly do this but the logistics would be messy. For large marathons, people travel to the destination from all over the world and book hotels in the city where they can easily get to the start location. Also, seeing the city while running the marathon, however inconvenient to others, is part of the attraction of the location.

If the actual marathon course is somewhere remote from the city, it's unlikely such a place would have the hotel space for all the runners, and transporting them to/from the site would be a massive undertaking in itself. Chicago has about 45,000 runners every year. Then there are all the volunteers who need to get to and from stations around the course.

I'm not saying any of this to discount the argument that marathons impose a huge inconvenience, only that moving them elsewhere isn't so cut and dried a solution.

The most depressing thing for me as someone who loves F# is how `.net` is nearly synonymous with C# in most people's minds

Meetings, working on docs etc can still be billable. 8 hours straight in the zone every day? Nobody does that.

Maven and Gradle don't run anything in a dedicated JVM. They're just tools to accomplish various goals based on your dependencies: compile, package, test, maybe deploy. Not even remotely similar to runtime module management like you get in OSGi.

More like they have a right to their beliefs, inferior or not, as long as they don't try to impose them on me.

I honestly fail to see what has been dishonest in the communications around this.

The plan for .NET 5 does, in fact, unify .NET Standard, Core and Xamarin. These will no longer be separate things but will go forward under one name.

I'm not sure what you're claiming as the _breaking change_. Can you be specific? It's not, in fact, going to break anything from what I can see. .NET Standard will simply continue to grow larger in .NET Core 3+ until it covers everything. This seems to me to be very different from the Python situation where you are (probably) forced to make code changes to compile with Python 3. If I have some code that compiles with .NET Standard 2.0, are you under the impression that it won't compile with .NET Core 3+ or .NET 5? If so, what leads you to think that?

If you are thinking of porting an old 4.x app but you wait until some time beyond Nov 2020 (https://i.redd.it/f8todfd66uw21.png) then it is in your interest to track the latest .NET Standard along the way. If you haven't been keeping the app up to date, say you're on 4.6.1, and then you decide you like .NET 5 and want to move to it, I think you'll just have to try it and fix whatever breaks.

This is pretty much like every other porting project where you have an old neglected project that you want to bring up to date. Maybe there is an easier way but I don't know what it is. Staying on the legacy .NET Framework isn't the end of the world, you're just committing to maintaining it as is. If you want new features as they become available, well... that's on you, don't wait.

Maybe you move some functionality out of your legacy GUI app to microservices written in .NET 5, parts that are unlikely to have any porting issues. In any case it's not like anyone is going to be surprised by what's going on. Maybe the community will back port some new things to .NET 4.8. MS will be devoting their efforts to enhancing the new platform while keeping the old one on life support. I think that's reasonable. (edit: typos)

In the real world there are massive amounts of code in the .net framework.

Right, I agree with everything you said here. That's exactly the reason why MS said at the Build conference that they will be supporting .NET Framework "forever". There is a lot of it out there and it will likely remain for a very long time.

When I said there won't be a concern with portability via .NET Standard, I merely meant that the current shifting landscape of Framework features vs Core features vs the intersection known as Standard, will go away. There will be .NET 4.8 in maintenance mode and .NET 5 as the future, growth mode. Maintaining .NET Framework apps hopefully won't be a problem but if you're thinking of building a new app using .NET 4.8, you're likely making a big mistake unless it's to satisfy some immediate need that doesn't work on .NET Core. MS said they're committed to supporting people stuck in that position. Just don't expect new features that will appear in future .NET versions.

I don't see how you reached that conclusion. Once .NET 5 arrives, there won't be any more concern with ensuring portability between .NET Core apps and .NET Framework apps by way of targeting .NET Standard.

.NET Standard will be only one thing, if they end up retaining the name at all. It will be the the interface to everything in .NET 5. .NET Framework will just be its own thing maintained only for legacy compatibility. After .NET Core 3.0, new development will not be added to .NET Framework.

I do agree with you that it would be clearer if they only spoke of .NET 5 and .NET 4.8 Framework versions.

Yes that's a good question. The situation today with .NET Core vs .NET Standard is: Standard is the common functionality that works in both .NET Framework and .NET Core. Standard continues to overlap more with Framework as those features are added into Core.

After .NET Core 3.0, MS said new features will only be added in Core. And when they reach .NET 5, Standard and Core will be identical, with "Standard" being the library you link to regardless which specific .NET implementation you're running on: desktop, IoT, mobile, etc. I believe the diagram only means that "Standard" covers all of .NET 5, not some subset of Core. And .NET Framework is a separate, maintained legacy library off to the side.

Note, I don't work for Microsoft, this is just my understanding from reading their docs and talking with them about it online and at MS Build.

That's right; we'll have two incompatible .NETs for the foreseeable future but only one will be getting new features. .NET 5 will unify Core, Standard and Xamarin/Mono.