catnaroek

12 ms·

61.
by catnaroek 9y ago
The problem with Ada isn't that it's niche. The problem is that it has a gazillion features whose purpose is (ostensibly) to make programming errors easy to prevent, identify and correct, but fail miserably at it. There is more to
62.
by catnaroek 9y ago
Safety can be established in three ways: (0) Automatically and statically, in which case there is an unavoidable tradeoff between the simplicity and the power of the static analyses. Example: non-lexical lifetimes. (1) Automatically and dyn
63.
by catnaroek 9y ago
It took me half a minute to just parse the title. Edit: I mean the title of this post here. The title of the linked article is, of course, very easy to read.
64.
by catnaroek 9y ago
A Go interface type is not an abstract data type. The difference is not even subtle: (0) An ADT has a single internal representation that is known to the implementor, but hidden from users. The upside is that the ADT implementor can use his
65.
by catnaroek 9y ago
> Abstract data types are designed specifically for data structures like queues and stacks Guess what all nontrivial programs manipulate in the end. > objects that don’t have such well defined invariants ... are either stateless or us
66.
by catnaroek 9y ago
If you want data abstraction to do at least a minimum of static invariant enforcement, you pretty much have to use abstract data types. But if you're fine with littering logs with “exception was caught here, such and such data structur
67.
by catnaroek 9y ago
Abstract data types have nothing to do with either algebraic data types or abstract classes.
68.
by catnaroek 9y ago
> Most interfaces have one implementation. Instead, they are about abstraction, design, and so on. Then what you want is an abstract data type. Unlike interfaces, which can be implemented anywhere, an abstract data type is implemented in
69.
by catnaroek 9y ago
It's no less immoral in programming languages than in real life, precisely because it tends to slip from the former into the latter.
70.
by catnaroek 9y ago
It is programmed by humans. Machine learning algorithms are designed and implemented by humans. If machine learning algorithms do not perform well in a way that puts human lives at risk, the humans who designed and implemented them are resp
71.
by catnaroek 9y ago
How shallow are the books that the author of this piece reads, that he can keep their entire contents in his head? I am pretty sure I can't keep the entire contents of my personal library in my head. And I don't even have that man
72.
by catnaroek 9y ago
> This is a collection of topics that you wouldn't ordinarily find in undergraduate math classes. Much of this course is covered in undergraduate math classes, except at much greater depth (especially algebra and probability theory)
73.
by catnaroek 9y ago
The original post to which you replied begins with: > As I said before, resource management is first and foremost a matter of correctness, so performance is neither here nor there. Your proposed alternatives, namely: > In Modula-3 or
74.
by catnaroek 9y ago
> Abstract data type inheritance is about substitution: this thing behaves in all the ways that thing does and has this behaviour (this is the Liskov substitution principle) There is no such thing as “inheritance” for abstract data types
75.
by catnaroek 9y ago
> Memory safety almost always involves some type of runtime checks: even memory safe languages usually (always?) have runtime checking of array bounds, for example. Indeed, array manipulation is completely unsafe in most languages, as ar
76.
by catnaroek 9y ago
In the presence of reference-counted mutable objects, destructors no longer guarantee that cleanup will happen. But that much is okay. This is a liveness property, and, as far as I can tell, nobody really knows of any non-annoying way to en
77.
by catnaroek 9y ago
> where you've basically created a c++ destructor style api with a lambda. Except for the part where destructors are meant to be called no more than once per object, at the end of its lifetime. All that you can guarantee is that `wi
78.
by catnaroek 9y ago
“Throw an exception on explicit use after free” is “memory safe” in exactly the same sense “throw an exception on explicit use of an operation on an argument of the wrong type” is “type safe”. In other words, not at all.
79.
by catnaroek 9y ago
> In Modula-3 or D, as as possible examples, a solution might be destructors or scope attributes. These still allow you to mismanage resources. > The only way to actually be 100% safe would be if everyone would be programming with for
80.
by catnaroek 9y ago
> At least in some languages this is not an issue if one is able to use higher order functions, with bonus points if they allow for trailing lambdas. I am afraid you are talking nonsense. Higher-order functions make verification harder
81.
by catnaroek 9y ago
> Replying here since your other comment may be gone. I deleted it because zenhack's reply was better. > Those are arguably more important if one wants mass adoption with all the library and funding benefits that come with it. I
82.
by catnaroek 9y ago
> Which is actually available in quite a few GC enabled languages. In existing implementations, not with Rust's static safety guarantees about dynamically allocated resources, sorry. “Just provide some way to disable the garbage col
83.
by catnaroek 9y ago
Tagged records are one possible in-memory representation of sum values, perhaps the most sensible one. But I don't want in-memory representations of sum values. I want sum values themselves. ML modules are much more than generic packag
84.
by catnaroek 9y ago
As I said before, resource management is first and foremost a matter of correctness, so performance is neither here nor there. While you don't need manual resource management for data structures containing values, you do need it for va
85.
by catnaroek 9y ago
Algebraic data types and ML-style modules are non-negotiable.
86.
by catnaroek 9y ago
Because Rust-style resource management is not only about performance, but also about correctness. And the ML crowd cares a lot about the latter - rightly so. I'd kill for a language with ordinary ML types for values (integers, string
87.
by catnaroek 9y ago
> You pitch "The best automated way to do X!", but in actuality you have a horde of people doing the work initially to figure out the problem before building the actual automation. It is plain dishonesty.
88.
by catnaroek 9y ago
I fail to see the point of this work. When I program, what I want to see is how each statement relates a precondition to a postcondition. From this point of view, the selling point of value-oriented programming is that conditions are partia
89.
by catnaroek 9y ago
> It's actually rare people need to do proofs. If they do, they can also prove the programs correct with a tool suited for it like Isabelle/HOL or Coq then extract them to the desired language. It's worked for extractions
90.
by catnaroek 9y ago
> languages with good metaprogramming facilities let the users them to fit their needs. No amount of metaprogramming can fix the intractability of proving programs correct in the base language, especially if the metaprogramming facilit

More ›