3 ms·

> Well, that wasn't part of the conversation until now. Sure it was. You kept saying "this isn't a solution." All I did was point out the converse. I experien

> Well, that wasn't part of the conversation until now. Sure it was. You kept saying "this isn't a solution." All I did was point out the converse. I experienced the kind of "modern" CS education that you consider a failure, and believe it or not, I have about as much scorn for it as you do. I did get some good exposure to serious analysis and low-level programming, but the other half of what I learned was pretty much a waste and I had to unlearn it the hard way after leaving school. So, I'm not here to defend the Java idiom of mile-high towers of superclasses, runtime polymorphism that nobody will ever need, or wild pointer goose chases that accomplish nothing but stalling the pipeline. All that stuff is a waste of everyone's time. I like my compiled code to stay lightweight and close to the metal. I am here to defend expressive type systems that permit detailed annotations of what should or shouldn't be done with a particular piece of data. I shouldn't have to rely on comments alone to say "the pointer returned by this function must be freed by the caller" or "the pointer returned by this function must NEVER be freed by the caller." I want the compiler to understand me when I say these things, and I want it to enforce my rules. C doesn't have that, obviously, but I'm sure you already know that it was a huge change from its immediate predecessors, which didn't have types. Even early C didn't have structs. It added these features because they made programming less error-prone. Nobody wanted to manually calculate field offsets and risk getting it wrong. That was 50 years ago. There have been missteps since then (I think every PL theorist counts OOP among these) but that doesn't mean C has to be the absolute last systems language ever in the history of computing.

robomartin 4y ago
> that you consider a failure It isn't a failure. It simply isn't optimal. Just my opinion, of course. Which means I could be very wrong. > "the pointer returned by this function must be freed by the caller" or "the pointer returned by this function must NEVER be freed by the caller." Those two are examples of bad programming. Both constraints are almost guaranteed to create, at a minimum, an unmanageable mess and, at worst, very dangerous software (think embedded controller for a robot or a rocket). While I have not looked, I would be very surprised if something like that existed in the Linux codebase, which is C. > that doesn't mean C has to be the absolute last systems language ever in the history of computing. I don't think I have suggested this at all in this conversation. My position is very simple: Don't blame the language for bad programming. This is rarely the problem. The fact that someone can cause a mess using pointers does not mean pointers are the problem. They simply don't know what they are doing. The Linux codebase uses pointers everywhere, right? Is it a mess? No. Maybe that's because they are using the language correctly. I am also not saying that all work in evolving programming languages should stop because C is perfect. Not the case I have made at all. What I will say is that --again, my opinion-- quite a few of the modern paradigms are complete nonsense in support of lazy programmers. The question to ask might be something like: Would you have been able to create the software without bugs using C? If the answer is "yes", then it is likely the newfangled language was not needed or justified. As an observation, pretty much all of these languages look like C. Outside of assembler, the only three languages I have used in my career that explored other paradigms were Forth, LISP and APL. I used these languages professionally for about 10 years. Not one of the modern languages people rave about have done anything to truly push the mark forward. In many ways APL was, in my opinion, the pinnacle. It' problem was that it surfaced way ahead of hardware being able to embrace it. For example, this code would take half a page of crud to create with any of the C-derivative modern languages: +/⍉10 10 ⍴ ⍳100 And we were able to do this FORTY years ago. What does it do? This creates a vector of 100 consecutive numbers, 1 to 100. ⍳100 This reshapes the vector into a 10 x 10 matrix: 10 10 ⍴ ⍳100 In other words: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 This rotates the matrix along it's diagonal: ⍉10 10 ⍴ ⍳100 This: 1 11 21 31 41 51 61 71 81 91 2 12 22 32 42 52 62 72 82 92 3 13 23 33 43 53 63 73 83 93 4 14 24 34 44 54 64 74 84 94 5 15 25 35 45 55 65 75 85 95 6 16 26 36 46 56 66 76 86 96 7 17 27 37 47 57 67 77 87 97 8 18 28 38 48 58 68 78 88 98 9 19 29 39 49 59 69 79 89 99 10 20 30 40 50 60 70 80 90 100 This delivers the sum of each row as a vector: +/⍉10 10 ⍴ ⍳100 Result: 460 470 480 490 500 510 520 530 540 550 You can also do it this way, same result: +⌿10 10 ⍴ ⍳100 Of course, this is a super-simple example of something that isn't necessarily ground-breaking on first inspection. Anyone should be able to reproduce this result with reasonable efficiency using C or derivatives. Not one line, but, who cares, that's not the important metric. One of the most interesting demonstration of APL for those who have never seen it in action is this implementation of Conway's Game of Life in APL. Very much worth watching: https://www.youtube.com/watch?v=a9xAKttWgP4 https://www.youtube.com/watch?v=a9xAKttWgP4 Once you internalize APL (which does not happen through casual use) it changes the way you think about how to solve problems computationally. You, quite literally, think at an entirely different level. Your brain visualizes data structures and implementation in a very different form. The closest equivalent I can reach for is using musical notation to describe music; which, of course, requires someone to have internalized the connection between notation and music. This is where I was going when I said that we likely need a better programming paradigm for AI. That, in my opinion, can easily justify a new language. And, yes, I am biased --ten years of APL use will do that to you-- I think it has to be symbolic. Quite literally, a new language --just like musical notation is a language for music. Going back to my core premise and the title of this thread: Throwing Rust at software development isn't going to fix bad programming. I don't see the point. And, yes, I could be wrong. If all hope of having capable programmers is gone, then, yes, of course, we need to make sure they don't make a mess just 'cause they have no clue.

robomartin 4y ago

> that you consider a failure It isn't a failure. It simply isn't optimal. Just my opinion, of course. Which means I could be very wrong. > "the pointer returned by this function must be freed by the caller" or "the pointer returned by this function must NEVER be freed by the caller." Those two are examples of bad programming. Both constraints are almost guaranteed to create, at a minimum, an unmanageable mess and, at worst, very dangerous software (think embedded controller for a robot or a rocket). While I have not looked, I would be very surprised if something like that existed in the Linux codebase, which is C. > that doesn't mean C has to be the absolute last systems language ever in the history of computing. I don't think I have suggested this at all in this conversation. My position is very simple: Don't blame the language for bad programming. This is rarely the problem. The fact that someone can cause a mess using pointers does not mean pointers are the problem. They simply don't know what they are doing. The Linux codebase uses pointers everywhere, right? Is it a mess? No. Maybe that's because they are using the language correctly. I am also not saying that all work in evolving programming languages should stop because C is perfect. Not the case I have made at all. What I will say is that --again, my opinion-- quite a few of the modern paradigms are complete nonsense in support of lazy programmers. The question to ask might be something like: Would you have been able to create the software without bugs using C? If the answer is "yes", then it is likely the newfangled language was not needed or justified. As an observation, pretty much all of these languages look like C. Outside of assembler, the only three languages I have used in my career that explored other paradigms were Forth, LISP and APL. I used these languages professionally for about 10 years. Not one of the modern languages people rave about have done anything to truly push the mark forward. In many ways APL was, in my opinion, the pinnacle. It' problem was that it surfaced way ahead of hardware being able to embrace it. For example, this code would take half a page of crud to create with any of the C-derivative modern languages: +/⍉10 10 ⍴ ⍳100 And we were able to do this FORTY years ago. What does it do? This creates a vector of 100 consecutive numbers, 1 to 100. ⍳100 This reshapes the vector into a 10 x 10 matrix: 10 10 ⍴ ⍳100 In other words: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 This rotates the matrix along it's diagonal: ⍉10 10 ⍴ ⍳100 This: 1 11 21 31 41 51 61 71 81 91 2 12 22 32 42 52 62 72 82 92 3 13 23 33 43 53 63 73 83 93 4 14 24 34 44 54 64 74 84 94 5 15 25 35 45 55 65 75 85 95 6 16 26 36 46 56 66 76 86 96 7 17 27 37 47 57 67 77 87 97 8 18 28 38 48 58 68 78 88 98 9 19 29 39 49 59 69 79 89 99 10 20 30 40 50 60 70 80 90 100 This delivers the sum of each row as a vector: +/⍉10 10 ⍴ ⍳100 Result: 460 470 480 490 500 510 520 530 540 550 You can also do it this way, same result: +⌿10 10 ⍴ ⍳100 Of course, this is a super-simple example of something that isn't necessarily ground-breaking on first inspection. Anyone should be able to reproduce this result with reasonable efficiency using C or derivatives. Not one line, but, who cares, that's not the important metric. One of the most interesting demonstration of APL for those who have never seen it in action is this implementation of Conway's Game of Life in APL. Very much worth watching: https://www.youtube.com/watch?v=a9xAKttWgP4 https://www.youtube.com/watch?v=a9xAKttWgP4 Once you internalize APL (which does not happen through casual use) it changes the way you think about how to solve problems computationally. You, quite literally, think at an entirely different level. Your brain visualizes data structures and implementation in a very different form. The closest equivalent I can reach for is using musical notation to describe music; which, of course, requires someone to have internalized the connection between notation and music. This is where I was going when I said that we likely need a better programming paradigm for AI. That, in my opinion, can easily justify a new language. And, yes, I am biased --ten years of APL use will do that to you-- I think it has to be symbolic. Quite literally, a new language --just like musical notation is a language for music. Going back to my core premise and the title of this thread: Throwing Rust at software development isn't going to fix bad programming. I don't see the point. And, yes, I could be wrong. If all hope of having capable programmers is gone, then, yes, of course, we need to make sure they don't make a mess just 'cause they have no clue.