71–80 of 141 posts
It is actually a nice informative video, but the title is as dumb as dumbness itself. Software should not be perfect. It should be useful. In places where perfection increases usefulness (s.a autopilot), go ahead make it perfect. In most cases, striving for "perfection" is a profound misallocation of resources.
Many very bright people in the major sects of ML and Scheme tried to achieve perfection, and they have concluded, many times, that perfection implies a mostly-functional strongly (and, perhaps, even statically typed but with optional annotations only, like it is in Haskell) language, possibly with uniform pattern-matching, annotated laziness, and high-order channels, and select and receive in the language itself. Suc…
Earlier quoted context omitted.
I honestly think Zig has the potential to be the C/C++ replacement. I haven’t checked out Jai yet but will now that you mention, thanks! This is somewhat subjective of course, but from what I’ve seen, Zig has just the right set of features to modernize systems programming, without making the language too complex or difficult to write (which arguably Rust’s “borrow checker” system does), and (like Rust) gets rid of so…
There are a lot of contenders. My own unsorted list is Nim, Rust, C++20xx, D, Objective C, Pony, Zig, Crystal, Red, and maybe a form of Lisp (why not Common Lisp). Even more unlikely a maybe and only for the C/C++ trenches of embedded systems, some form of Forth. If Jai ever ships I might consider adding it (at least as a contender to the C/C++ trenches of games and game engines), but it's absurd to think it will hav…
Rust, Zig, Kotlin, Swift, and many other modern languages can express the same concept of a null reference, but in a fundamentally superior way. In modern languages like these, the compiler will statically guarantee the impossibility of null dereference exceptions, without negatively impacting performance or code style!
But it goes beyond just static checking. It makes coding easier, too: You will never have to wonder whether a function returning a reference might return null on a common failure, vs throw an exception. You’ll never have to wonder if an object reference parameter is optional or not, because this will be explicit in the data type accepter/returned. You’ll never have to wonder if this variable of type T in fact contains a valid T value, or actually is just “null”, because the possible range of values will be encoded in the type system: If it could be null, you’ll know it and so will the compiler. Not only is this better for safety (the compiler won’t let you do the wrong thing), it’s self-documenting.
It blows my mind that any modern language design would willingly think nullable object references is still a good idea (or perhaps its out of ignorance), when there are truly zero-cost solutions to this — in both runtime performance and ease of writing code, as you can see for example from Zig or Kotlin.
[1] https://www.infoq.com/presentations/Null-References-The-Bill...
Many very bright people in the major sects of ML and Scheme tried to achieve perfection, and they have concluded, many times, that perfection implies a mostly-functional strongly (and, perhaps, even statically typed but with optional annotations only, like it is in Haskell) language, possibly with uniform pattern-matching, annotated laziness, and high-order channels, and select and receive in the language itself. Suc…
Also, perfection and practicality do not match either, since imperative languages are the most practical for many applications. Pushing software toward perfection gives diminishing returns, and after some threshold, a company will have negative profit due to expensive development costs.
I'm watching Zig and Jai closely. We need a better C and C++ isn't it. Good luck!
Earlier quoted context omitted.
I honestly think Zig has the potential to be the C/C++ replacement. I haven’t checked out Jai yet but will now that you mention, thanks! This is somewhat subjective of course, but from what I’ve seen, Zig has just the right set of features to modernize systems programming, without making the language too complex or difficult to write (which arguably Rust’s “borrow checker” system does), and (like Rust) gets rid of so…
There are a lot of contenders. My own unsorted list is Nim, Rust, C++20xx, D, Objective C, Pony, Zig, Crystal, Red, and maybe a form of Lisp (why not Common Lisp). Even more unlikely a maybe and only for the C/C++ trenches of embedded systems, some form of Forth. If Jai ever ships I might consider adding it (at least as a contender to the C/C++ trenches of games and game engines), but it's absurd to think it will hav…
Yes, a Lisp-like language could do it. Why not Common Lisp? Because PreScheme and ZL were both better if we're aiming at C's niche:
https://en.wikipedia.org/wiki/Scheme_48
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.40...
http://www.schemeworkshop.org/2011/papers/Atkinson2011.pdf
I was looking for a way to do metaprogramming, verified programming, LISP-like programming, and low-level programming. Past few years of searching led me to a lot of verification stuff obviously, PreScheme for low-level Lisp, ZL for Scheme/C, and Red/System for a REBOL-like answer. I was eyeballing Nim, too, since the masses usually hate LISP's syntax. Then, I thought a front-end that let one go with various syntax's, esp inspired by famous languages, with the same underlying semantics or just easy integration.
On a practical note, I noticed that strong integration with the dominant language with little to no performance hit is extremely important. Clojure building on Java in enterprise space is an example. It reuses it's ecosystem. For system space, I started recommending using C's data types and calling conventions where possible in new language so calling it would cost nothing. Then, maybe an option to extract to C for its compilers. So, whatever above languages are created need to integrate with C really well.
It is actually a nice informative video, but the title is as dumb as dumbness itself. Software should not be perfect. It should be useful. In places where perfection increases usefulness (s.a autopilot), go ahead make it perfect. In most cases, striving for "perfection" is a profound misallocation of resources.
Upvoted since this is a useful comment and worth mentioning. I'd expect some downvotes are based on negative reactions to this part of the comment: "the title is as dumb as dumbness itself." (Dear avip: if your comment said "the title is off-base" you would have made your point just as effectively and without the downvotes.)
There's a certain irony that the presenter quickly dismisses exception-based error handling, and then the first example handles an error by printing a message and exiting -- exactly what an unhandled exception does. This is more than a small piece of irony with a somewhat artificial example. Often, there simply isn't very much you can do with an error. In a SaaS world, you might not be able to tell the user what wron…
There's a certain irony that the presenter quickly dismisses exception-based error handling, and then the first example handles an error by printing a message and exiting -- exactly what an unhandled exception does. This is more than a small piece of irony with a somewhat artificial example. Often, there simply isn't very much you can do with an error. In a SaaS world, you might not be able to tell the user what wron…
I made this argument in the talk: the only problem with exception-based handling is the lack of explicitness. It's too easy to call functions without being aware of the set of possible errors. Many c++ projects disable exceptions entirely. Writing "exception safe" code is tricky and non-obvious. Functions which should be guaranteed to never fail often can throw std::bad_alloc. Try-catch syntax forces incorrect nestin…
But that's entirely fine! Programmers are far too obsessed with exactly which functions trigger which errors when it absolutely doesn't matter. All you need to know is what errors you can handle and where in the code you can handle them.
If there is a network exception and can recover and retry it at the start of the operation, it literally doesn't matter which of the thousands of functions up the call stack could have possibly triggered it. The only thing you need to know is the top-level network exception and where your network processing code starts. And if you can't handle a network error, it literally doesn't matter if one was triggered. The best you can do is abort and record a really good stack trace for that type of error.
Earlier quoted context omitted.
There are a lot of contenders. My own unsorted list is Nim, Rust, C++20xx, D, Objective C, Pony, Zig, Crystal, Red, and maybe a form of Lisp (why not Common Lisp). Even more unlikely a maybe and only for the C/C++ trenches of embedded systems, some form of Forth. If Jai ever ships I might consider adding it (at least as a contender to the C/C++ trenches of games and game engines), but it's absurd to think it will hav…
Many of those are ruled out as modern successors (in my mind, at least), when they continue to make “the billion dollar mistake” (to use its inventor’s own words[1]) of null references. Rust, Zig, Kotlin, Swift, and many other modern languages can express the same concept of a null reference, but in a fundamentally superior way. In modern languages like these, the compiler will statically guarantee the impossibility…
In any case I think the modern fashion of trying to eliminate null from PLs won't matter much in the effort to replace C, whereas something like a mandatory GC is an instant no-go (though Java at least was very successful at sparing the world a lot of C++). OTOH a language that makes more kinds of formal verification possible (beyond just type theory proofs) might one day replace C and have null-analysis as a subfeature too.