5 ms·
Are you sour because you don't understand pointers, or something? I'm 22 and I almost exclusively use C++, C, and x86 assembly. These types of languages are not
by nickcano 11y ago
Are you sour because you don't understand pointers, or something? I'm 22 and I almost exclusively use C++, C, and x86 assembly. These types of languages are not going anywhere, and a fair portion "the next generation of programmers" is perfectly fine with that.
- innguest 11y agoNo. I understood and wrote tutorials on pointers when I was 17. I never understood what people don't get about them. They literally exist in real life in the back of any indexed book. I'm just angry that new programmers still have to pay towards the technical debt of old school programmers. It's sad to see that we're losing new programmers to old paradigms. Just so you know the state of the art, there are people out there mathematically proving that the operating system cores they wrote have no bugs. So long as you insist on managing everything yourself because "speed, man" you will continue to work overtime chasing bugs that aren't your fault (the fault is squarely on the paradigm called Von Neumann). Good luck wasting your life away making programs the most complicated way possible so you can feel productive. I'll be putting these Haskell Lego pieces together over here and let the compiler do all the work that you do manually. Because apparently your type of person (the type that accepts that status quo and thinks it's the best we've got and doesn't contribute to pushing for better things) will keep coming - these types of people are not going anywhere.
- nickcano 11y agoAnd 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 agoThat'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. :)