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.
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?
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.
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.