h_r
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.
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?
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]
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.
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!
| ...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?
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 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.
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...
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`?
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 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?
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)
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.
.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.
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.