391–400 of 402 posts
Earlier quoted context omitted.
"pure FP" does not mean only writing in a functional style. Purity refers to referential transparency, ie., functions do not depend on or modify some global state.
I know what purity is. It is a core principle of functional programing. So ”functional“ already implies purity, and ”pure functional“ implies exclusively functional (e.g. Haskell).
His overall solution highlighted in the intro is that he's moved on from inlining and now does pure functional programming. Inlining is only relevant for him during IO or state changes which he does as minimally as possible and segregates this from his core logic. Pure functional programming is the bigger insight here that most programmers will just never understand why there's a benefit there. In fact most programme…
1) programming which is based on "functions" (procedures) as values, including anonymous lambdas (hence map/fold/etc paradigms), which is only really possible in languages that intentionally support it
2) programming where every procedure (except some boundary code for IO/etc) is truly is a well-defined mathematical function, which is possible in almost any programming language
1) describes any language you would call a "functional programming language," whereas 2) involves well-understood concepts around mutability and determinism that a minority (correctly) describe as "pure functional programming."
So I think it's a bit judgmental to say "lack of insight" when it's more about shifting terminology. A very high-reliability C program might be "purely functional" (inside of an IO/memory boundary) and built by engineers with the precise insight you're discussing, but in most contexts it would be odd to say "purely functional," especially if the code eschews C mechanics around function pointers. In most imperative contexts it is clearer to describe purely functional ideas in terms of imperative programming (which are equally clear, if less philosophically interesting).
Can someone explain what inlined means here? It was my assumption that the compiler will automatically inline functions and you don't need to do it explicitly. Unless it means something else in this context
Earlier quoted context omitted.
> macOS is produced by the richest company on Earth and a few years ago the CALCULATOR app had a bug that made it give the wrong answers... This is stated as if surprising, presumably because we think of a calculator app as a simple thing, but it probably shouldn't be that surprising--surely the calculator app isn't used that often, and so doesn't get much in-the-field testing. Maybe you've occasionally used the calc…
Constantly, to keep the results of a calculation on screen. It's fallacious to assume that your own usage patterns are common. Hell, with as much evidence as you (none), I would venture that more people use the Calculator app than know that you can type calculations in Spotlight at all.
I don't assume that my usage pattern is common. (My usage pattern is to drop to `bc`.) I assume that Calculator usage isn't common, but, recognizing that that is an assumption and that the only way to get evidence is to ask, I asked:
> Maybe you've occasionally used the calculator in Spotlight, but have you ever opened the app?
And you answered, so now together we have double the evidence that I alone did before. :-)
Earlier quoted context omitted.
> macOS is produced by the richest company on Earth and a few years ago the CALCULATOR app had a bug that made it give the wrong answers... This is stated as if surprising, presumably because we think of a calculator app as a simple thing, but it probably shouldn't be that surprising--surely the calculator app isn't used that often, and so doesn't get much in-the-field testing. Maybe you've occasionally used the calc…
I think this is backwards. A calculator app should be a simple thing. There's nothing undefined or novel about a calculator app. You can buy a much more capable physical calculator from Texas Instruments for less than $100 and I'm pretty sure the CPU in one of those is just an ant with some pen and paper. You and I only think it's complex because we've become accustomed to everything being complex when it comes to wr…
Right, and that's my point: if all you want is a rock-solid computational platform, then you can use, for example, `bc`. (That's what I do.) I assume that Apple assumes that their users want something fancier than that, and it's there, with the fanciness of a shiny user interface on a less-exercised code path, that the bugs will inevitably come.
His overall solution highlighted in the intro is that he's moved on from inlining and now does pure functional programming. Inlining is only relevant for him during IO or state changes which he does as minimally as possible and segregates this from his core logic. Pure functional programming is the bigger insight here that most programmers will just never understand why there's a benefit there. In fact most programme…
this is a really non-productive comment. you have an opportunity to teach and share knowledge but instead you hoard and condescend, and rant about your implied superiority.
if so many programmers don't understand -- what's more productive: this comment, or helping "most programmers" to get it, and understand?
Earlier quoted context omitted.
I think this is backwards. A calculator app should be a simple thing. There's nothing undefined or novel about a calculator app. You can buy a much more capable physical calculator from Texas Instruments for less than $100 and I'm pretty sure the CPU in one of those is just an ant with some pen and paper. You and I only think it's complex because we've become accustomed to everything being complex when it comes to wr…
> That's my point. The mathematical operations are not hard (even the "fancy" ones like the trig functions). Formatting a number to be displayed is also not hard (again, those $100 calculators do it just fine). Right, and that's my point: if all you want is a rock-solid computational platform, then you can use, for example, `bc`. (That's what I do.) I assume that Apple assumes that their users want something fancier…
(For what it's worth, Qalculate destroys both bc and the Mac calculator app in both command line and GUI categories, so making working software isn't entirely a lost art.)
Earlier quoted context omitted.
I’ve had the opposite experience before. As a young developer, there were a number of times where I advocated for doing something “the right way” instead of “the good enough way”, was overruled by seniors, and then later I had to fix a bug by doing it “the right way” like I’d wanted to in the first place. Doing it the right way from the start would have saved so much time.
Here is an unwanted senior tip, in many consulting projects without the “the good enough way” first, there isn't anything left for doing “the right way” later on.
His overall solution highlighted in the intro is that he's moved on from inlining and now does pure functional programming. Inlining is only relevant for him during IO or state changes which he does as minimally as possible and segregates this from his core logic. Pure functional programming is the bigger insight here that most programmers will just never understand why there's a benefit there. In fact most programme…
where does the condescension come from? the loftiness/lording over people who "just don't get it", that clearly comes across in your communication? this is a really non-productive comment. you have an opportunity to teach and share knowledge but instead you hoard and condescend, and rant about your implied superiority. if so many programmers don't understand -- what's more productive: this comment, or helping "most p…
I love to teach and explain but this is one of those things that can’t be conveyed. You have to do it yourself.
If you want an explanation though, use Google. But I don’t think explanations actually help you grok what’s really happening. You really have to come to catharsis yourself.
Learn Haskell. Learn it to the point where you completely understand the purpose of the IO monad and why it exists and helps a program organize better. Then you will understand.
When you do get it. You’ll be among a small few who have obtained something that’s almost like forbidden knowledge. No one will “get” you.
Earlier quoted context omitted.
> I'm not sure if this is needed for variables that are only read It’s not needed. In fact, you should leave it out for read-only variables. That’s standard practice - if you use `nonlocal` people reading the code will expect to see writes to the variables.
> That’s standard practice - if you use `nonlocal` people reading the code will expect to see writes to the variables. Since when? I was under the impression Python virtually doesn't have lexical scoping at all and that's why `nonlocal` exists. I mean hell, in CPython you can literally access and modify the local variables of your caller (and everything else up the call stack too). I never associated `nonlocal` at al…
Python has had lexical scoping since version 2.2. PEP 227 [0] "describes the addition of statically nested scoping (lexical scoping)" - allowing access to (but not assignment to) names in outer scopes.
`nonlocal` was introduced later, in Python 3.0 [1], specifically to allow assignment to names in outer scopes.