6 ms·

And yet, under almost every high-level language that "does all the work that I do manually", what is there? Under Python in C++ Under PHP is C++ Under Haskel

And yet, under almost every high-level language that "does all the work that I do manually", what is there? Under Python in C++ Under PHP is C++ Under Haskell is a variant of C called C-- Under Lua is C Under Perl is C Is this because "the dinosaurs haven't died yet"? No. It's because writing a high-level programming language almost always requires a lower-level language. Under all of your high-level abstractions, there needs to be some compiles-to-assembly language that has access to memory management. Under all of your fancy high-level language debuggers, there needs to be some disassembly and translation of the assembly code to match the symbol databases for your high-level code. Under all of your binaries, there needs to be a kernel that can translate API calls, handle interrupts, dispatch exceptions, manage memory protection, and schedule threads. Can you do all of this with Haskell? Sure. But the first Haskell compiler written in Haskell needs to be compiled by something. It can be C, C++, C--, or even assembly for all I care, but it has to exist. Even the first C compilers needed to be written in something that wasn't C. The bottom line is that it has nothing to do with "technical debt". These languages exist because they can work on hardware without heavy frameworks weighing them down. They rely on the bare system, and not on a bunch of abstractions. And that's why they can be used as a layer between hardware and the much-needed abstractions brought to us by high-level languages. These "old" languages have many strengths, and you're foolish to write them off just because their strengths don't fit your use-cases. Without the programmers that are "lost" to these "old paradigms", you would have nobody to maintain, develop, or secure your new paradigms. And that's a consequence that only considers one of the many strengths of these languages; there's many more consequences that we'd face if nobody new learned how to use them.

innguest 11y ago
That's the Stroustrup argument - it's everywhere so it must be good! Like dust, or herpes. Your argument is its own counter-argument. Why is everyone running away from C so badly that they are even willing to put up with PHP? That's how much C sucks. The evidence is in everyone making other languages as soon as they can to get away from C. Look at Lua. People cannot even put up with writing their whole applications in C, it's such a pain, they need an escape valve called Lua so they can breath a little. That things are built atop C is the story of Academia in the USA. They have predominantly taught ALGOL-like languages and favored the Von Neumann architecture to complete detriment of Lambda Calculus. So it's because it's all people know, and they don't know any better. C is so much the wrong language to write programming languages in, that they wrote Yacc, Bison, etc because programming parsers and lexers are so impossibly difficult to write in such a limited language like C, that people gave up, and made tools to generate C code for them. Eww. And that's the industry standard, some smelly C code that vomits more C code that no one can write because C doesn't offer the appropriate abstractions to deal with the problem. That's technical debt. Your language is so weak no one has the balls to write a parser on it? Well guess what, throw it in the garbage and start over. Do not pass on that technical debt to further generations. If a language is weak, stop all work on it, move on to a stronger language that can express more things. Which is why from very early on two schools of thought diverged and... just read "Worse is Better". :) Point is, C people think worse is better, they don't want to take the time to make sure their stuff is solid because they like to brag that they get so much done and so clearly C must be better. I can make 10 sand castles in under an hour but when the sea flows it takes them with it. But no tsunami can take a stone castle. Why don't you want to strive to build stone castles? As a final point, consider that your precious C programs and the C compiler can only run because of the CPU, which was not written in C nor in any Von Neumann language - oh no, they were written functionally, with only logic gates, in a dataflow-oriented way, because you know, they really needed this to work. That's why CPUs don't have bugs - they picked a better starting language than C, with a principled approach (logic) that is amenable to mathematical verification. Guess what - functional programming languages are also increasingly more amenable to mathematical verification. Once this is popularized, you'll be delegated to maintaining the old sand castles from dinosaurs while we will be building stone castles over here. Join us. :)
- nickcano 11y ago
  I give up. You are literally drenched in a dogmatic hate for low-level and far too under-educated to argue with.
  - innguest 11y ago
    Ah yes, that's the problem. It must be, otherwise how could you be right and not have counter-arguments? ;)
  - codygman 11y ago
    It doesn't seem like innguest hates low-level to me. Kind of random question: What do you think of Rust and ATS?
- jawnv6 11y ago
  Detailed reply below, but I'm going to agree with the other child and say that you're vastly under-educated in this area and arguing from a point of ignorance. CPU's are not written in a "functional" manner, any similarity is superficial at best and certainly not anything to base practices on. CPU's are relatively, not completely as you so carelessly asserted, bug-free through a development process with high standards. > As a final point, consider that your precious C programs and the C compiler can only run because of the CPU, which was not written in C nor in any Von Neumann language - oh no, they were written functionally, with only logic gates, in a dataflow-oriented way, because you know, they really needed this to work. HDL's are not "only" logic gates. Have you developed anything substantial in a HDL? I'd think the lack of recursion alone would cleanly delineate them from anything functional. My own work with FPGA's started without language, literally wiring things together in a GUI. That's the legacy ASIC design descended from, not a functional ivory tower. > That's why CPUs don't have bugs - they picked a better starting language than C, with a principled approach (logic) that is amenable to mathematical verification. iHDL is not a "better" language than C. Imagine having to specify the exact opcode you wanted the linker to emit for a particular instruction, that's the level of dipping into implementation details that HDL's allow. It's not uncommon to have "behavioral" code that is checked in concert with the rest of the design, "implementation" code representing the actual circuit, and some poor engineer tasked with signing off that the two are equivalent without the ability to simulate all inputs. Formal verification is a specialized technique that is only used on vanishingly small parts of the design. At no point in the consideration of an HDL for a new design is "amenable to mathematical verification" given weight. Another slight problem with your argument: CPU's DO have bugs. Google up "Intel Errata" and prepare for your stone castle to be torn apart. If you'd like to duck this and say that they're esoteric and don't matter, I'd really like to know what you think about the TSX-killing errata that's essentially set back parallel computing in a measurable way. Why wasn't this subjected to formal verification magic? > Guess what - functional programming languages are also increasingly more amenable to mathematical verification. Once this is popularized, you'll be delegated to maintaining the old sand castles from dinosaurs while we will be building stone castles over here. Join us. :) You don't understand what you're comparing to with enough fidelity to trust the end result. The easiest way to imagine a CPU design team is that it's Just Another Software project. The only extra constraints are that you can't run it full speed. You can simulate a 5GHz chip at 5Hz with SW-like visibility. At some point in the alpha, the team will spend a few million dollars to wait 8 weeks to get a few dozen test chips that will run at full speed, with near-zero visibility. So the question is how much extra unit testing would you do, on each of those models, with those kind of timelines. Formal verification doesn't make a dent on modern CPU design. It's all these extra considerations (read:bodies) taken during the design process that make up the gap. Please, try to educate yourself before going off on half-baked assumptions based on superficial similarities.

innguest 11y ago

That's the Stroustrup argument - it's everywhere so it must be good! Like dust, or herpes. Your argument is its own counter-argument. Why is everyone running away from C so badly that they are even willing to put up with PHP? That's how much C sucks. The evidence is in everyone making other languages as soon as they can to get away from C. Look at Lua. People cannot even put up with writing their whole applications in C, it's such a pain, they need an escape valve called Lua so they can breath a little. That things are built atop C is the story of Academia in the USA. They have predominantly taught ALGOL-like languages and favored the Von Neumann architecture to complete detriment of Lambda Calculus. So it's because it's all people know, and they don't know any better. C is so much the wrong language to write programming languages in, that they wrote Yacc, Bison, etc because programming parsers and lexers are so impossibly difficult to write in such a limited language like C, that people gave up, and made tools to generate C code for them. Eww. And that's the industry standard, some smelly C code that vomits more C code that no one can write because C doesn't offer the appropriate abstractions to deal with the problem. That's technical debt. Your language is so weak no one has the balls to write a parser on it? Well guess what, throw it in the garbage and start over. Do not pass on that technical debt to further generations. If a language is weak, stop all work on it, move on to a stronger language that can express more things. Which is why from very early on two schools of thought diverged and... just read "Worse is Better". :) Point is, C people think worse is better, they don't want to take the time to make sure their stuff is solid because they like to brag that they get so much done and so clearly C must be better. I can make 10 sand castles in under an hour but when the sea flows it takes them with it. But no tsunami can take a stone castle. Why don't you want to strive to build stone castles? As a final point, consider that your precious C programs and the C compiler can only run because of the CPU, which was not written in C nor in any Von Neumann language - oh no, they were written functionally, with only logic gates, in a dataflow-oriented way, because you know, they really needed this to work. That's why CPUs don't have bugs - they picked a better starting language than C, with a principled approach (logic) that is amenable to mathematical verification. Guess what - functional programming languages are also increasingly more amenable to mathematical verification. Once this is popularized, you'll be delegated to maintaining the old sand castles from dinosaurs while we will be building stone castles over here. Join us. :)

nickcano 11y ago
I give up. You are literally drenched in a dogmatic hate for low-level and far too under-educated to argue with.
- innguest 11y ago
  Ah yes, that's the problem. It must be, otherwise how could you be right and not have counter-arguments? ;)
- codygman 11y ago
  It doesn't seem like innguest hates low-level to me. Kind of random question: What do you think of Rust and ATS?
jawnv6 11y ago
Detailed reply below, but I'm going to agree with the other child and say that you're vastly under-educated in this area and arguing from a point of ignorance. CPU's are not written in a "functional" manner, any similarity is superficial at best and certainly not anything to base practices on. CPU's are relatively, not completely as you so carelessly asserted, bug-free through a development process with high standards. > As a final point, consider that your precious C programs and the C compiler can only run because of the CPU, which was not written in C nor in any Von Neumann language - oh no, they were written functionally, with only logic gates, in a dataflow-oriented way, because you know, they really needed this to work. HDL's are not "only" logic gates. Have you developed anything substantial in a HDL? I'd think the lack of recursion alone would cleanly delineate them from anything functional. My own work with FPGA's started without language, literally wiring things together in a GUI. That's the legacy ASIC design descended from, not a functional ivory tower. > That's why CPUs don't have bugs - they picked a better starting language than C, with a principled approach (logic) that is amenable to mathematical verification. iHDL is not a "better" language than C. Imagine having to specify the exact opcode you wanted the linker to emit for a particular instruction, that's the level of dipping into implementation details that HDL's allow. It's not uncommon to have "behavioral" code that is checked in concert with the rest of the design, "implementation" code representing the actual circuit, and some poor engineer tasked with signing off that the two are equivalent without the ability to simulate all inputs. Formal verification is a specialized technique that is only used on vanishingly small parts of the design. At no point in the consideration of an HDL for a new design is "amenable to mathematical verification" given weight. Another slight problem with your argument: CPU's DO have bugs. Google up "Intel Errata" and prepare for your stone castle to be torn apart. If you'd like to duck this and say that they're esoteric and don't matter, I'd really like to know what you think about the TSX-killing errata that's essentially set back parallel computing in a measurable way. Why wasn't this subjected to formal verification magic? > Guess what - functional programming languages are also increasingly more amenable to mathematical verification. Once this is popularized, you'll be delegated to maintaining the old sand castles from dinosaurs while we will be building stone castles over here. Join us. :) You don't understand what you're comparing to with enough fidelity to trust the end result. The easiest way to imagine a CPU design team is that it's Just Another Software project. The only extra constraints are that you can't run it full speed. You can simulate a 5GHz chip at 5Hz with SW-like visibility. At some point in the alpha, the team will spend a few million dollars to wait 8 weeks to get a few dozen test chips that will run at full speed, with near-zero visibility. So the question is how much extra unit testing would you do, on each of those models, with those kind of timelines. Formal verification doesn't make a dent on modern CPU design. It's all these extra considerations (read:bodies) taken during the design process that make up the gap. Please, try to educate yourself before going off on half-baked assumptions based on superficial similarities.