Live data from Hacker News

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

youtube.com

111–120 of 288 posts

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

#111
post #6
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…

Most of the oldies I know prefer static typing. A lot of the new people use dynamic types because that's all they know.

Care to define "old"? I'm 38, and the programmers I know that are older than me don't seem to have a significantly different spread compared to younger (excluding 1-language programmers in both cases).

Maybe a bit less python and a bit more of one of: perl/awk/apl/smalltalk but still they seem to choose untyped languages over typed languages when they are unconstrained to pick the language.

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

#112
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).

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

#113
post #83

Earlier quoted context omitted.

Does this speak more to the pursuit of the application of software to problems generally or to the baseline triviality of problems that are funded to have software applied to them? To me it seems like an incentive problem that starts with the distorting effects of unsophisticated investors w/ unrealisitic expectations who fund following a herd mentality only things they can themselves pattern-match to.

To me it speaks of Software being "good enough" far more easily than it can be perfect. > To me it seems like an incentive problem Why is it a problem if a buyer gets something that works well enough for a lot less time/money put in? Further to that - specifications and requirements are often imperfect, poorly pinned down, ever-changing. Software creation out in the commercial world has shifted working patterns to tr…

I'm not sure I follow.

The challenge with this formulation of "ever-changing" is that it assumes that things like Agile methods are somehow creating the capacity to iterate toward something of value with intention and ambition in such a way that you'll achieve whatever it is that you're trying to achieve.

However, what happens is that the lack of rigor in software development today seems to cause the lineage of development and associated created technology to drift further and further away from the desired commercial goal as those goals change or mutate.

Creating a bunch of brittle technology and technical debt to poorly approximate Purpose-A (a purpose by the way that you might be able to formally prove trivially is actually impossible and you either shouldn't waste the money or should intentionally select the best sub-optimal solution) doesn't help you get to Purpose-B any faster. As you become aware that Purpose-B is a thing you need to angle toward, you're still dealing with the pile of bubblegum, toothpicks, and instruction manuals written in alien script that still hasn't achieved Purpose-A.

It's a really weird thing to me that as an entire ecosystem and community we've decided that the most valuable way to approach software is to declare that it's impossible to ever "finish" it.

If I have a series of high-assurance layers to build upon that I know I can trust, then iterating and adapting to changes actually becomes faster and easier, because I know the surface area of where a problem can actually reside and how deep in any part of a system I actually have to uproot and start over. In the current formulation of the world, basically everything is a suspect, and basically any solution is considered viable... whether it truly is or not.

I've been in situations where Product Managers and Engineers spent months off and on arguing over some proposed solution or feature and never getting anywhere because everybody's basis was built on social capital, political capital, and mythology. What finally killed the conversation and allowed progress to actually happen? When a TLA+ model that invalidated one of the proposed hypotheses was presented. "Well, look. The way you want to do this is actually impossible. It will need to be done like this, this, or this instead." Seven... _seven_... sprints of about a dozen people wasted because nobody could formalize either the requirement or the approach. Until somebody did. This wasn't for a safety-critical system either.

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

#114
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…

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.

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

#115
post #59

Earlier quoted context omitted.

I think that tools such as TLA+ show their value not by convincing people that they're worth the extra effort but that they actually save you effort. The experience at Amazon and Microsoft shows exactly that, and managers were relatively easily convinced.

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…

The problem is, most of the people who you are working with, only have 0-2 years of experience in the technology that they are using (use of research / deep learning to build products). Look at their resumes. They'd be either recent PhD grads, who haven't built a single product in their life. Or traditional engineers who had just joined the field of building products with an approach that is very different from one that they are experienced in.

I would also caution you. Do you really know the technology that you are trying to make safe? Building systems with research / deep learning is as different from traditional software development as synthetic biology from electrical engineering.

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

#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 expression ... but runs way slower than an "ugly" equivalent in c code.

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

#117
post #102
post #77

The assertion here seems to be that TLA+ isn't a programming language? I'm not sure that makes sense to me.

It most certainly isn't. It is generally impossible to interpret/compile a TLA+ algorithm efficiently (i.e. as a program that runs with similar complexity to the algorithm) because of the inherent nondeterminism in TLA+. OTOH, it is precisely this nondeterminism that allows you to use TLA+ to describe any algorithm/system at any level of detail. In fact, you can show that a language with similar descriptive power to…

Since when is it a requirement that a programming language be efficient?

My larger point is that he seems to be using "programming language" as a shorthand for an imperative, typed programming language. A lot of what he says doesn't seem to apply very well to SQL or Prolog or Lisp, for instance. (I say this having only skimmed the slides, I don't have two hours for this right now.) I won't say that it's a straw man, because there are plenty of programming languages that fit the way he's using the term and some of them are incredibly popular, but it seems to be a definition that leaves out a lot of programming languages.

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

#118
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.

> Computers are still imperative "Computer Science is no more about computers than astronomy is about telescopes." — (Mis)attributed to Edsger Dijkstra, 1970.

Meanwhile, in the real world...

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

#119
post #75
post #69

Earlier quoted context omitted.

Usually risks people not using it or playing your game. Rarely does it kill and in those cases (self driving cars, banking) those application usually has a company behind them.

If the RSS reader you're building has no guarantees of working it has no value to anyone. Not all software needs to try and be bug free but all software should strive to minimize the number of bugs in it. Static typing helps to minimize bugs (when used correctly) by allowing function contract declarations and reducing the build up of defensive guards over time. I've seen code in dynamically typed languages with lines…

If it has no guarantee and it works it still has value for whoever uses it. If it didn't work it might have less value but still has some value.

Why would guarantee free software have no value. It's like buying a used phone.. no guarantee but it still has value.

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

#120
post #2

Lamport is famous in part for his work on LaTeX, the document typesetting language. It is Turing complete. Should no one write papers in LaTeX?

I'd say that he's known as one of the fathers of distributed systems, and for winning a Turing award, more than for writing LaTeX. Also, it's not LaTeX that's Turing complete, but rather TeX. LaTeX is basically a bunch of TeX macros. Also, the rest of your comment doesn't make any sense, either.

It's not a confusing comment. Lamport says that programming languages should only be used for programs. Lamport is also famous for using a programming language for typesetting.

A comment about the things you think he's more famous for doesn't make sense. A comment about LaTeX not being turing-complete, and citing as proof that it's largely a bunch of macros written in a turing-complete language (glued together with that turing-complete language) doesn't make sense either.

Post reply on HN