Earlier quoted context omitted.
I have heard critiques of functional programming, but not that there is a problem with leaky abstractions. Can you provide an example? Does it invalidate the discipline of trying to use pure functions when possible? I learned to program using BASIC on an Apple II. All of the variables were global, and it wasn't until I got Apple Pascal that I had access to a language that had local variables. I immediately saw the ad…
Program execution time and memory footprint are great examples. Math does not care about these details, but just because two programs are logically equivalent does not mean they will behave identically. I am very pro functional programming, but your mental model needs to be accurate to really dig into the details. As such you really need to understand ASM and procedural code or it will eventually bite you.
If You're Not Writing a Program, Don't Use a Programming Language [video]
181–190 of 288 posts
Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#182Earlier quoted context omitted.
I'm finding a fifteen years figure hard to believe. There was a handful of people at that time that have invented deep learning. It took years to get any industry use, as the technology was not yet competitive, until AlexNet.
We don't work in AI/ML, we work on high-assurance distributed systems. That said, you'd be right. Not 15-years in something like computer vision. No such thing as formally verified NNs, regardless of what nuTonomy claims, exist. Even the basis about what one would be trying to verify is an open question. It's partially the point of DARPA's Assured Autonomy program. The problem at the moment is that the ecosystem has…
Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#183Earlier quoted context omitted.
>Honestly I think it might be time to phase out teaching imperative and object-oriented programming. I have seen plenty of universities teach Java and C++, haven't seen any that teach actual OOP. James Coplien aptly calls the current paradigm "class oriented programming".
It triggers me to no end when I watch an introductory course, for people with no previous exposure to any programming language, and the teacher starts with "public static void main()" In order to understand it, you need to have a good grasp of classes, static methods, access controls. This is usually followed up by a request to ignore the entire line, which is one of the worst habits you can have as a developer. Then…
Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#184Earlier quoted context omitted.
If you use TLA+ you'll see why this is likely unnecessary. A huge specification, made at three levels of detail, can run to 2500 LOC. Because you have so much control over the level of detail, and because the language is so expressive, there is little need for reuse (except maybe for some common definitions, e.g. of different consistency levels, which are very short but can be non-trivial).
How do you mean unnecessary? Surely writing such a specification takes many man hours, even after having spent many man hours to learn TLA+? Can none of this effort be encapsulated into something reusable? The desire for reuse is not driven by a want to reduce LOC, but hours spent.
I guess there are occasionally pieces that could be used as-is (e.g. a description of a lossy network), but those tend to be so simple, that looking for them in some Maven-central for spec modules would probably more effort than writing them from scratch every time.
Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#185Earlier quoted context omitted.
We don't work in AI/ML, we work on high-assurance distributed systems. That said, you'd be right. Not 15-years in something like computer vision. No such thing as formally verified NNs, regardless of what nuTonomy claims, exist. Even the basis about what one would be trying to verify is an open question. It's partially the point of DARPA's Assured Autonomy program. The problem at the moment is that the ecosystem has…
Isn't it a "high-assurance distributed AI/ML system"? It is interesting that there is indeed a tendency to factorize it. I believe, this tendency arises because there are two groups of people that are available - traditional engineers, that are excellent and experienced, but do not know the language of AI and can't tell an ensemble from an embedding. And AI engineers, who are yet to build their first product.
There's a layer of it (the AI/ML bits) which is necessarily probabilistic. That's by design. It's how it all works. All the layers below that today are currently terrifyingly probabilistic. It's difficult to advance the capability of the whole domain when the necessarily probabilistic parts are depending on shifting sands as a stable foundation.
I agree though that there's a large gap there in the domain expertise of the parties involved, and that's produced significant challenges as we've not yet figured out how to close that gap.
Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#186Earlier quoted context omitted.
Because soon you will just ask your computer to build your code after giving it a few parameters. Then you will proof read and sanity check the code and spend more time optimizing and working on the really hard problems.
How soon? I don't know of any software I've written for which that could be done. The first program I ever wrote was an implementation of Tic-Tac-Toe, and I can't imagine a set of parameters to produce that which aren't specifically for making games of that nature while also being easier to select than writing the code myself. I'd bet such a system is impossible in general, and that that should be the obvious conclus…
Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#187Earlier quoted context omitted.
Isn't it a "high-assurance distributed AI/ML system"? It is interesting that there is indeed a tendency to factorize it. I believe, this tendency arises because there are two groups of people that are available - traditional engineers, that are excellent and experienced, but do not know the language of AI and can't tell an ensemble from an embedding. And AI engineers, who are yet to build their first product.
Sort of. Except I don't think there's a such thing as "high-assurance AI/ML". Put simply for the audience here. The goal is to have the whole stack from top to bottom be as predictable and deterministic as possible. There's a layer of it (the AI/ML bits) which is necessarily probabilistic. That's by design. It's how it all works. All the layers below that today are currently terrifyingly probabilistic. It's difficult…
Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#188Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#189Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#190Earlier quoted context omitted.
Isn't it a "high-assurance distributed AI/ML system"? It is interesting that there is indeed a tendency to factorize it. I believe, this tendency arises because there are two groups of people that are available - traditional engineers, that are excellent and experienced, but do not know the language of AI and can't tell an ensemble from an embedding. And AI engineers, who are yet to build their first product.
Sort of. Except I don't think there's a such thing as "high-assurance AI/ML". Put simply for the audience here. The goal is to have the whole stack from top to bottom be as predictable and deterministic as possible. There's a layer of it (the AI/ML bits) which is necessarily probabilistic. That's by design. It's how it all works. All the layers below that today are currently terrifyingly probabilistic. It's difficult…