←back to thread

296 points gyre007 | 1 comments | | HN request time: 0.001s | source
Show context
hootbootscoot ◴[] No.21281666[source]
So, I DO believe that this earnest high-level programmer is very earnest, I just don't think that he is starting with a full deck of cards. The manner in which he quickly brings up "C" and it's "killer app" being systems programming, and then jumps into the Javascript morass, it sort of suggests that he should start with first principles on how computers function.

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.

replies(1): >>21282164 #
mac01021 ◴[] No.21282164[source]
Some of those sources are pretty daunting...
replies(1): >>21283305 #
1. hootbootscoot ◴[] No.21283305[source]
indeed... hence the desire for blackboxes.

leaky abstractions require the occasional lid-lifting... and all abstractions have a tendency to leak somewhere or other, especially if they attempt to be all encompassing.

I think FP is certainly a viable high-level specification but ultimately there is lower-level code 'getting stuff done' (lol, "side effects") One has to be at least roughly aware of HOW ones specification is getting implemented in order to solve problems that arise and in order to optimize.

This is all the more compelling reason to cease this relentless push to "cram more stuff down the tubes" or "add more layers to the stack"

I honestly think that we need to return to KIS/KISS (keeping it simple)

SIMPLIFY and remove extraneous stuff that prevents one from having a total mental model of what is happening.