101–110 of 417 posts
Earlier quoted context omitted.
What has he done? Everyone’s commenting he doesn’t like HN but when I clicked the link everything looks fine. Serious question.
You must be using Brave or a browser plugin which doesn't send referral headers. If you use a normal browser, it displays a testicle in an egg cup with a silly phrase complaining about the demographic of HN users.
Computers are imperative devices. I don't think that a for-loop or a map function fundamentally impede understanding of this concept. I DO think that pretending that languages that run on top of Virtual Machines need to aknowledge their dependency heirarchy and stop attempting to "level/equalize" the languages in question. One would use C in order to write a VM like V8 that then could run your scripting language. The core of Autocad is surely C++ with some lower-level C (and possibly assembler) regardless of whichever scripting language has then been implemented inside of this codebase, again, on a virtual machine.
The Operating System is a virtual machine. The memory management subsystem is a virtual machine.
Javascript runs on browsers. (Or V8, but then that was originally the JS engine of a browser) and has inherent flaws (lack of type system, for one) that limit it's use in specifying/driving code generation that could provide lower level functionality. THAT is the essential issue. VHDL and Verilog can specify digital logic up to a certain level of abstraction. C++ and C code generation frameworks can be used to generate HDL code to some degree, to the degree that libraries make them aware of the lower-level constructs such HDL's work in. I have no doubt that Pythons MyHDL presents a very low learning curve in terms of having the Python interface, but then the developer needs to be aware of what sort of HDL MyHDL will output and how it will actually perform in synthesis and on a real FPGA.
We don't need MORE layers of opaque abstraction. People need to learn more about how computers work as abstraction doesn't obviate the need to know how the lower levels work in order to optimize ones higher level code.
I can provide specific examples regarding libraries that purport to provide a somewhat blackbox interface, but upon deeper examination DO, in fact, require intimate knowledge of what is inside.
Abstractions are imperfect human attempts to separate concerns and they are temporary and social membranes.
Now, having said all of this: If a person ran a Symbolics Lisp system, such a system was holistic and the higher-level Lisp programmer could drill down into anything in the system and modify it or see how it was made.
I digress... read the source code for any magical black boxes you are thinking of employing in your work.
The top comment on YouTube raises a valid point: > I've programmed both functional and non-functional (not necessarily OO) programming languages for ~2 decades now. This misses the point. Even if functional programming helps you reason about ADTs and data flow, monads, etc, it has the opposite effect for helping you reason about what the machine is doing. You have no control over execution, memory layout, garbage col…
Functional Programming might have great advantages in correctness but sooner or later the code is going to be run on a real CPU with real instructions and all the mathematical abstractions don’t mean much there.
That said, I can see they have their place for specialized areas.
Earlier quoted context omitted.
I think partial application and pipe operators make this so very intuitive though: [butter, sugar, walnuts] |> mix() |> splitIntoPans(pans = 3) |> bake(time = 30, temp = 175) |> cool(time = 5)
We can improve the syntax further [butter, sugar, walnuts] mix() splitIntoPans(pans = 3) bake(time = 30, temp = 175) cool(time = 5) Hmm, wait a second.....
[butter, sugar, walnuts]
^^^
Somewhere wanted type CakeIngredients but missing record field "Flour"
Earlier quoted context omitted.
we users pay a price for this trend though :( Those python users could switch to F#/OCaml/Clojure and get a big speed boost too!
Python is perfectly fine for glueing together functionality that deals with high latency systems, like a data pipeline that executes queries that are running for minutes. It does not matter from the performance point of view if this code is in Forth or Python, but it matters from the point of view how long does it take to implement and how many engineering hours need to go into it. This is why Python is a good option…
Earlier quoted context omitted.
You may want to consider Ramda.js instead: https://ramdajs.com/ IMHO does a better job than Lodash, because: 1. All functions are automatically curried. 2. The order of parameters lends itself to composition. EDIT: 3. Transducers.
I never understood the point of Ramda. It's like it's trying to replace the core functionality of JS with something that's completely orthogonal to what the language actually is, but it's just a bolted on library. I've worked on codebases where people ignore all built-in JS functions (like Array.map/filter) and write Ramda spaghetti instead with multiple nested pipes and lens and what not to show off their FP purism.…
People at the places I work keep memeing links to blog posts along the lines of "OOP is dead. Functional programming is the new king". Yet to see a single line of a functional language in production. As other commenters have mentioned most decent modern lanuages are multi-paradigm.
Earlier quoted context omitted.
I think partial application and pipe operators make this so very intuitive though: [butter, sugar, walnuts] |> mix() |> splitIntoPans(pans = 3) |> bake(time = 30, temp = 175) |> cool(time = 5)
We can improve the syntax further [butter, sugar, walnuts] mix() splitIntoPans(pans = 3) bake(time = 30, temp = 175) cool(time = 5) Hmm, wait a second.....
Earlier quoted context omitted.
You may want to consider Ramda.js instead: https://ramdajs.com/ IMHO does a better job than Lodash, because: 1. All functions are automatically curried. 2. The order of parameters lends itself to composition. EDIT: 3. Transducers.
I never understood the point of Ramda. It's like it's trying to replace the core functionality of JS with something that's completely orthogonal to what the language actually is, but it's just a bolted on library. I've worked on codebases where people ignore all built-in JS functions (like Array.map/filter) and write Ramda spaghetti instead with multiple nested pipes and lens and what not to show off their FP purism.…
Richard Gabriel’s famous essay “Worse is better” ( https://www.jwz.org/doc/worse-is-better.html ) is an interesting perspective on why Lisp lost to C. In a way, the same arguments (simplicity vs consistency vs correctness vs completeness) can be made for why functional programming lost to OOP. But those philosophical perspectives aside, personally I find my brain works very much like a Turing Machine, when dealing wi…
> personally I find my brain works very much like a Turing Machine Exactly this. How baking a cake in FP looks like: * A cake is a hot cake that has been cooled on a damp tea towel, where a hot cake is a prepared cake that has been baked in a preheated oven for 30 minutes. * A preheated oven is an oven that has been heated to 175 degrees C. * A prepared cake is batter that has been poured into prepared pans, where ba…