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

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

#171

Post by hathawsh » Mon, Sep 24, 2018, 10:26 PM UTC

adw wrote: post #162

Retric wrote: post #106

Earlier quoted context omitted.

Computers are still imperative, so all functional code is arguably syntactic sugar over that core causing a lot of leaky abstractions to show up all over the place. I think the problem with Object-oriented programming is it's taught to soon. Start with Imperative then Functional then toss object oriented into your senior year.

A ton of problems in software engineering, I am convinced (and isn't wild generalization one of the marks of our field! I at least want to own my own hypocrisy here) are communication problems. Nearly all the interesting ones, anyway. And one of them is axioms no-one ever communicates . I've worked with programmers with at least three markedly different axiomatic bases, for want of some less pretentious – and less ex…

That's a very interesting categorization. I would generally place myself in the 'electrical engineers' category. I usually code in Python, Javascript, or Java, but I see those languages as essentially C or machine code with productivity enhancements like garbage collection, objects, closures, and lots of interoperable libraries.

OTOH, I would also place myself somewhat in the 'mathematician' category because I see imperative code as functional code where each instruction is a function that takes the current machine state and some parameters and computes a new machine state. The new machine state is an input for the next instruction. When you see it that way, instruction pipelines in the CPU become very easy to comprehend: the CPU calculates one or more possible future machine states while waiting for a response from DRAM, then selects the correct state based on the response.

Seeing it that way also reveals the main issue with imperative programming: the each instruction accepts too many inputs! Functional programming helps constrain the inputs so that it's easier to reason about what the code does and how it can change.

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

#172

Post by laythea » Mon, Sep 24, 2018, 10:28 PM UTC

drb91 wrote: post #5

aidenn0 wrote: post #3

I haven't watched the full talk, so let me know if this gets explored by Lamport, but... Here's a thought: PL researchers seem to generally agree that typed languages are superior to untyped languages, yet programmers tend to prefer untyped languages to typed languages, to the point where Java and C++ have the fanciest type systems in common use, with ML being the closest thing to an academic language that gets signi…

> programmers tend to prefer untyped (dyanamic?) languages to typed languages I have not found this in practice. I have found that some developers prefer a dynamically typed language for certain situations, like rapid prototyping. However when maintaining code bases, I've found that developers often bemoan the lack of static types to assist in small modifications to code they haven't touched in a while. Personally I…

Vote for Typed languages here, every day of the week. Why introduce yet another (and unnecessary) sub-game of "find the type"? Keep It Simple!

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

#173

Post by marcosdumay » Mon, Sep 24, 2018, 10:29 PM UTC

Koshkin wrote: post #114

winstonewert wrote: post #79

Earlier quoted context omitted.

I think a lot of the disconnect comes from "static typing" meaning different things to different people. When some people say "static typing" they are thinking a language like Haskell with a powerful type system. However, when most programmers say "static typing" they are thinking a language like Java or C++ with a rather underpowered type system. Programmers who prefer dynamic typing are largely deciding that they w…

The correct distinction is static vs. dynamic typing on the one hand, and strong vs. weak vs. no typing on the other.

I think the point is way more complex than this. Some type systems are more expressive than others, some type systems require more ceremony than others, and some type systems are more constraining than others.

The real problem with all those discussions about types (and why I think nobody should try to pass an opinion unless they tried something at least as good as Haskell) is that the most used static languages have the least constraining, most ceremonious and least expressive systems around. Developers gain nearly nothing from their type systems, but they are incredibly demanding of upkeep.

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

#174

Post by adw » Mon, Sep 24, 2018, 10:38 PM UTC

hathawsh wrote: post #171

adw wrote: post #162

Earlier quoted context omitted.

A ton of problems in software engineering, I am convinced (and isn't wild generalization one of the marks of our field! I at least want to own my own hypocrisy here) are communication problems. Nearly all the interesting ones, anyway. And one of them is axioms no-one ever communicates . I've worked with programmers with at least three markedly different axiomatic bases, for want of some less pretentious – and less ex…

That's a very interesting categorization. I would generally place myself in the 'electrical engineers' category. I usually code in Python, Javascript, or Java, but I see those languages as essentially C or machine code with productivity enhancements like garbage collection, objects, closures, and lots of interoperable libraries. OTOH, I would also place myself somewhat in the 'mathematician' category because I see im…

It's a pile of massive overgeneralizations, not least of which is that people don't fall neatly into these categories. But it's a useful framework for thinking about miscommunication, I've found.

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

#175

Post by im_down_w_otp » Mon, Sep 24, 2018, 10:45 PM UTC

dchichkov wrote: post #165

im_down_w_otp wrote: post #130

Earlier quoted context omitted.

That's an institutional problem though. Yes, it's true that most companies hire way more people, way too quickly than is probably prudent for a problem domain (especially one that is still such an open-ended science project like AVs), and that as a result barely anybody has any idea what they're doing measured against what's being expected of them, but that's a wound that is entirely self-inflicted. It's not a natura…

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 two science projects on its hands. How to make an ML-derived driver is one. How to make a stable, correct substrate for acquiring data, make a decision, and react correctly is another. The only one most people hire up for is the former, and the latter is at least as challenging.

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

#176

Post by adw » Mon, Sep 24, 2018, 10:46 PM UTC

nostrademons wrote: post #170

a-nikolaev wrote: post #166

Earlier quoted context omitted.

Yeah, interestingly, I have this impression that Python is a modern-day Fortran. (Largely for the reasons you describe in the third category of programmers.)

On some level that's literally true: when you run NumPy or SciPy code, most of your basic array manipulations are done by BLAS, which are a set of very tightly optimized linear algebra routines originally written in Fortran.

A very large part of the answer to "why do people use Python?" is "why did physicists adopt Python en masse in the early 2000s?" and a large part of the answer to _that_ is "f2py exists"...

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

#177

Post by pron » Mon, Sep 24, 2018, 10:48 PM UTC

323454 wrote: post #160

pron wrote: post #30

Earlier quoted context omitted.

Lamport would argue that if you're debating typed vs. untyped PLs, you're already missing the point, as all programming languages are necessarily [1] at a level that's too low for system/algorithmic thinking, and if you're working in a language appropriate to thinking about algorithms/systems, then the considerations surrounding typing are quite different from those pertaining to PLs (TLA+ happens to be untyped, but…

As I understand it, TLA may technically be untyped but that's simply because you are supposed to implement your own more granular type checking as part of your spec.

It's true that TLA+ doesn't rely on types to specify properties, but it's still untyped. You could implement similar arbitrary properties in any programming language as predicates.

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

#178

Post by jononor » Mon, Sep 24, 2018, 10:49 PM UTC

pron wrote: post #112

jononor wrote: post #56

I think we need reusable (formal) specifications for it to become adapted widely. If that could be done in a way similar to how we today use open source libraries of reusable code, findable via a package manager, it might fly. Writing formal specs from scratch each and every time is too time consuming relative to the gain, except for in a few critical usecases.

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.

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

#179

Post by steveklabnik » Mon, Sep 24, 2018, 10:53 PM UTC

zackmorris wrote: post #136

Joe-Z wrote: post #107

Earlier quoted context omitted.

Would you mind elaborating on "why separate address spaces connected by pipes are such a powerful abstraction", or point me to some sources? Likewise if there's something you can recommend for reading up on the Actor model?

Ya in my mind, executables that do one thing well and are connected by pipes is one of the most proven models for getting things done. Even relatively nontechnical people can write shell scripts, batch files and macros that take some kind of data from a socket/file/pipe, pass it through a bunch of black boxes and spit out an answer. This is very similar to the Actor model and is much simpler to reason about than the…

> I haven't fully learned Rust yet but from what I understand, the borrow checker only applies to mutable data

This is not correct. The borrow checker applies to references, both mutable and immutable.

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

#180

Post by hathawsh » Mon, Sep 24, 2018, 11:00 PM UTC

adw wrote: post #174

hathawsh wrote: post #171

Earlier quoted context omitted.

That's a very interesting categorization. I would generally place myself in the 'electrical engineers' category. I usually code in Python, Javascript, or Java, but I see those languages as essentially C or machine code with productivity enhancements like garbage collection, objects, closures, and lots of interoperable libraries. OTOH, I would also place myself somewhat in the 'mathematician' category because I see im…

It's a pile of massive overgeneralizations, not least of which is that people don't fall neatly into these categories. But it's a useful framework for thinking about miscommunication, I've found.

I agree. Next time I have a disagreement with another coder, I might ask them whether they see computers as primarily circuits, set theory implementations, or AI. (I might add "filing cabinet" as another category.) It would help me understand which assumptions I can probably make.