I don't think that it qualifies as a leaky abstraction by your definition.
While needing to manage effects (i.e., time) explicitly may be annoying and expensive, it doesn't leak implementation details per se.
Your argument might be that the cost of managing this makes using leaky abstractions more attractive, but in that case it would be 'functional programming encourages leaky abstractions' rather than 'is a leaky abstraction', which seems a far more defensible claim.
But I don't think you've really made a good argument for that here either, possibly because you've skipped over the meat of the problem by begging the question. :)
Thanks for the feedback. I disagree that this is about encouraging leaky abstractions, it is more the fact that in the end, when you start really debugging, you always end up asking "What order is the chip executing this in?" on some level, as well as "What is the state of the computer (file system, graphics card, network card, etc.) right now?" and that you can't control those outside systems having side effects on each other.
That is the point, that functional programming languages continue to lose in adoption to imperative languages because imperative languages match the underlying system better on a fundamental level. Not even a new concept, just trying to present it in a way I thought was interesting.
Hmm, I am unconvinced that the reason for this is due to a lack of tooling for debugging the underlying infrastructure.
Let's consider Javascript -- the debuggers generally only debug Javascript and don't do any of the extra things you're talking about.
Yet people find it to be a perfectly reasonable language and it is very popular.
It also has an algorithmic evaluation strategy, where i/o occurs outside the program flow (with the exception of things like nodejs and ajax synchronous calls, but these are pretty exceptional).
If your idea was the reason for a lack of popularity in functional languages you'd expect it to apply here as well, but it doesn't.
I think the true causes are probably (a) network effects, and (b) people are taught mechanical evaluation models from a early age [so, really network effects again].
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don't think that it qualifies as a leaky abstraction by your definition.
While needing to manage effects (i.e., time) explicitly may be annoying and expensive, it doesn't leak implementation details per se.
Your argument might be that the cost of managing this makes using leaky abstractions more attractive, but in that case it would be 'functional programming encourages leaky abstractions' rather than 'is a leaky abstraction', which seems a far more defensible claim.
But I don't think you've really made a good argument for that here either, possibly because you've skipped over the meat of the problem by begging the question. :)
Thanks for the feedback. I disagree that this is about encouraging leaky abstractions, it is more the fact that in the end, when you start really debugging, you always end up asking "What order is the chip executing this in?" on some level, as well as "What is the state of the computer (file system, graphics card, network card, etc.) right now?" and that you can't control those outside systems having side effects on each other.
Well, in that case you're not debugging the functional system -- you're debugging a procedural system that's implementing it.
And certainly the system that realizes your program (specification) is full of concrete -- that's kind of the point.
So I'm a bit confused as to how or why this is relevant. :)
That is the point, that functional programming languages continue to lose in adoption to imperative languages because imperative languages match the underlying system better on a fundamental level. Not even a new concept, just trying to present it in a way I thought was interesting.
Hmm, I am unconvinced that the reason for this is due to a lack of tooling for debugging the underlying infrastructure.
Let's consider Javascript -- the debuggers generally only debug Javascript and don't do any of the extra things you're talking about.
Yet people find it to be a perfectly reasonable language and it is very popular.
It also has an algorithmic evaluation strategy, where i/o occurs outside the program flow (with the exception of things like nodejs and ajax synchronous calls, but these are pretty exceptional).
If your idea was the reason for a lack of popularity in functional languages you'd expect it to apply here as well, but it doesn't.
I think the true causes are probably (a) network effects, and (b) people are taught mechanical evaluation models from a early age [so, really network effects again].