Live data from Hacker News

If You're Not Writing a Program, Don't Use a Programming Language [video]

youtube.com

181–190 of 288 posts

Re: If You're Not Writing a Program, Don't Use a Programming Language [video]

#181
post #132
post #122

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.

I don't like how people equate the algebraic FP style of programming with "math" -- there are plenty of ways to model execution time and memory footprint using math, for example. A functional program is no more "mathematical" than an imperative one.

Re: If You're Not Writing a Program, Don't Use a Programming Language [video]

#182

Earlier 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…

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.

Re: If You're Not Writing a Program, Don't Use a Programming Language [video]

#183

Earlier 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…

The thing I love about Python as a teaching language is that you don't need to tell people anything about objects to get them started, and even to do some more advanced stuff (e.g. turtle graphics). And then you can introduce objects, and they light up the mental image of the world that is already there - because objects were part of the ride all along, just staying in the background.

Re: If You're Not Writing a Program, Don't Use a Programming Language [video]

#184
post #112

Earlier 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.

Most of the effort writing TLA+ is about the what not the how. In general, we know how to make code reuse effective when a lot of implementation hides behind a thin API, but in TLA+ there is no implementation in a meaningful sense. A library of requirements would make about as much sense, and while maybe it's something that could be done, I'm not sure we know how to do it (but if you've seen something like it, I'd love to see it). So maybe it's an interesting idea, but I'm not sure how it would be done. Aside from a utility module that I like including in most of my specs, I never "reuse" modules as is. I often do, however, copy-paste-modify pieces of other specifications, which, I assume, is not unlike how lawyers reuse portions of contracts.

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]

#185

Earlier 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.

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 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]

#186
post #97

Earlier 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…

[deleted]

Re: If You're Not Writing a Program, Don't Use a Programming Language [video]

#187

Earlier 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…

Are you sure, such thing as "high-assurance AI/ML" doesn't exist? Are you an expert in AI, with many years of experience building products with AI technology?

Re: If You're Not Writing a Program, Don't Use a Programming Language [video]

#188
I find it frustrating how he's against "types" but shows the GCD algorithm where x and y must adhere to a type that can be compared with equality, admits an ordering, and has a subtraction operator. Is the algorithm defined for the reals? Can we use a partial ordering? I'm skeptical of any proposal that seems to have missed even a superficial coverage of existing knowledge/literature on the topic.

Re: If You're Not Writing a Program, Don't Use a Programming Language [video]

#190

Earlier 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…

[deleted]
Post reply on HN