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]

#201

Post by seanmcdirmid » Tue, Sep 25, 2018, 12:44 AM UTC

laythea wrote: post #168

zackmorris wrote: post #92

I wasn't exposed to spreadsheets until a few years into college back around 1996 or 1997 maybe (I had been programming in C/C++ for 7 or 8 years by then). I wasn't taught matrix math until pretty late in the curriculum, I want to say junior or senior year. Also I was lucky to have a semester of Scheme but they were transitioning to teaching Java around the time I graduated (I don't know if they ever switched back). A…

"...have logic flows having no obvious connection to one another, or transition through async handlers connected by a convention which isn't immediately obvious to the developer" This is very true. I hate parsing code written like this, or code written using a mashup of concepts, requiring mind gymnastics to fathom an implementation of a solution to a relatively simple problem. It makes the job so much more unnecessa…

Inverted control is a hallmark of many programming domains. It’s not like you can get the user to be synchronous with respect to the program they are using (unless it is a non interactive batch tool). Even functional paradigms like Rx have control flow running around all over the place, the only saving grace is if you can keep it encapsulates via a set of opaque data flow pipes (and often you can’t).

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

#202

Post by im_down_w_otp » Tue, Sep 25, 2018, 12:48 AM UTC

ajmurmann wrote: post #153

im_down_w_otp wrote: post #71

Earlier quoted context omitted.

Absolutely agree. I work in the autonomous vehicle space, specifically in creating high-assurance resilient systems, and I've had more arguments that I care to count which went something like the following: Them, "All that extra effort sounds great, but we don't have the time to do that. It will explode the really tight build, test, debug cycle we have now. Suddenly every cycle will be 100x as long." Me, "First of al…

I think your frustration largely arises because the problem you work on is uncommon. The goals you are working towards are very large and error is not an option because people die or at least massive property damage occurs. Most applications aren't like that. It doesn't matter much if 1/10k image upload to Instagram fail. We have a lot more Instagrams than autonomous cars so the engineering culture conversion is larg…

My particular vein of work certainly makes me more likely to have interacted with this different way of doing things, but I don't think at all that it's a necessary component to there being reasons to consider it and reap the benefits of it. Because I didn't always used to be in this vein of work, and in retrospect I would have benefited enormously from being more judicious and fastidious in my prior lives using things like TLA+ or requiring even super basic things from my co-workers/teammates like property-based tests. I would have saved so much time and money and heartache over the years.

It can't possibly be more efficient to take 50 fairly expensive people and have them iterate 10,000 times toward something that still ends up being fairly broken---and requires maintenance in perpetuity---than it is to take 6 slightly more expensive people, and have them iterate 10 times toward something that does exactly and only what it is supposed to do and requires basically no attention once it's been instantiated, can it? Even if you're Instagram.

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

#203

Post by macspoofing » Tue, Sep 25, 2018, 12:53 AM UTC

zackmorris wrote: post #92

I wasn't exposed to spreadsheets until a few years into college back around 1996 or 1997 maybe (I had been programming in C/C++ for 7 or 8 years by then). I wasn't taught matrix math until pretty late in the curriculum, I want to say junior or senior year. Also I was lucky to have a semester of Scheme but they were transitioning to teaching Java around the time I graduated (I don't know if they ever switched back). A…

>I think it might be time to phase out teaching imperative and object-oriented programming. Most of the grief in my career has come from them.

Good luck. Computer Science degrees are balancing act between practical and theoretical. More importantly students want to work with technologies that are popular in the industry today. You can try to to stand against the tide, but you will lose.

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

#204

Post by ezoe » Tue, Sep 25, 2018, 1:05 AM UTC

zackmorris wrote: post #92

I wasn't exposed to spreadsheets until a few years into college back around 1996 or 1997 maybe (I had been programming in C/C++ for 7 or 8 years by then). I wasn't taught matrix math until pretty late in the curriculum, I want to say junior or senior year. Also I was lucky to have a semester of Scheme but they were transitioning to teaching Java around the time I graduated (I don't know if they ever switched back). A…

Real hardware is imperative. Object-oriented programming was once treated like Functional programming. The languages which did implement OOP as it was originally thought was horribly inefficient. So practical languages took the good idea out of OOP for convenient syntax sugars.

Functional Programming will follow the same path. You probably don't like it for it will be ended up impure and just some syntax sugar that looks like FP, but rest of the world like it because it gets the job done.

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

#205

Post by vmchale » Tue, Sep 25, 2018, 1:09 AM UTC

Retric wrote: post #106

zackmorris wrote: post #92

I wasn't exposed to spreadsheets until a few years into college back around 1996 or 1997 maybe (I had been programming in C/C++ for 7 or 8 years by then). I wasn't taught matrix math until pretty late in the curriculum, I want to say junior or senior year. Also I was lucky to have a semester of Scheme but they were transitioning to teaching Java around the time I graduated (I don't know if they ever switched back). A…

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.

> so all functional code is arguably syntactic sugar

No. "Syntatic sugar" implies that it is relatively trivial 1-1 translation that could in principle go backwards. Functional programming has many, many more optimizations and transformations.

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

#206

Post by thrmsforbfast » Tue, Sep 25, 2018, 1:17 AM UTC

rixarn wrote: post #116

I'm more with Mike Acton in this respect; the hardware is the platform, not the software. And in that sense... In order to really make good use of your hardware you need to understand your hardware and code accordingly. I doubt you can achieve great performance on a language that focuses entirely on mathematical representations without considering the hardware. So yeah... you end up with a beautiful mathematical expr…

> In order to really make good use of your hardware you need to understand your hardware and code accordingly

Understanding your hardware is only half the story. To use the hardware effectively, you also need to have mathemaitcal insights into your problem.

A rather extreme proof of this fact is bubble_sort.c vs. quick_sort.java. I think it's clear which of those is using the machine more effectively...

> I doubt you can achieve great performance on a language that focuses entirely on mathematical representations without considering the hardware.

Plenty of very high level languages have extremely effective compilers. SQL query engines come to mind.

> So yeah... you end up with a beautiful mathematical expression ... but runs way slower than an "ugly" equivalent in c code.

TLA+ et al. are about primarily about correctness and designed for situations where correctness is hard to get. Beauty is relevant only in-so-far as it helps one the path to correctness.

But yes, hand-craft code will get you your GIGO much faster :)

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

#207

Post by Retric » Tue, Sep 25, 2018, 1:22 AM 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…

When you try and ignore the hardware you find out things like random bit errors occur. Thus pure symbol manipulation is unequivocally false.

Pretending a computer is somethings else can be a useful abstraction, but you can actually learn what’s going on.

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

#208

Post by Retric » Tue, Sep 25, 2018, 1:25 AM UTC

panic wrote: post #181

Retric wrote: post #132

Earlier quoted context omitted.

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.

I mean as a mental model.

You can for example analyze a program assuming an ideal compiler (which I have seen people do), or you can understand the actual compiler used. The second is an implementation detail subject to change, but it’s also more accurate.

I recall one meeting when people said doing comparisons with a list of objects one comparison at a time should be as fast as doing the same thing one object at a time. I pointed out that due to cache issues doing each check an object at a time would be faster. A few people where shocked when the test showed a significant improvement.

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

#209

Post by [deleted] » Tue, Sep 25, 2018, 1:25 AM UTC

arithma wrote: post #158

im_down_w_otp wrote: post #71

Earlier quoted context omitted.

Absolutely agree. I work in the autonomous vehicle space, specifically in creating high-assurance resilient systems, and I've had more arguments that I care to count which went something like the following: Them, "All that extra effort sounds great, but we don't have the time to do that. It will explode the really tight build, test, debug cycle we have now. Suddenly every cycle will be 100x as long." Me, "First of al…

Either your frustration is great, or you have the mind of a jedi. This is without a doubt the most scathing review I've read of agile, and you don't seem to even be trying.

[deleted]

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

#210

Post by IX-103 » Tue, Sep 25, 2018, 1:33 AM UTC

im_down_w_otp wrote: post #185

dchichkov wrote: post #182

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…

So, two questions:

1. What parts of AI/ML have to be nondeterministic?

Once the model is trained then it should be completely deterministic. There are some training techniques that randomize the order or grouping of data, but they are primarily used because random is almost as good as finding the optimal ordering/grouping and finding the optimal ordering/grouping is hard. Sometimes randomness is used to augment the data to give you more examples to for against (because the model is too complex to train/fit with the data you have it you want to be robust to certain variations in input. If you're talking outputs then you should get the same outputs from a model given the same inputs. There are some really bad models out there that are way over fitted (relevant xkcd - https://m.xkcd.com/2048/ see "house of cards") and some people working on ML have a terrible grasp of statical techniques (just try models until they find one that fits), but even these models are deterministic.

What is so bad about nondeterminism anyway? Ethernet used nondeterminism to handle collision resolution. There best prime finding algorithms are nondeterministic. There is nothing wrong with appropriate nondeterminism.