51 ms·

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

253 points by azhenley 8y ago

dzdt 8y ago
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?
- aidenn0 8y ago
  I'm not sure how your comment pertains to the contents of the video, but considering it's been over 30 yeears since he started work on LaTeX, it wouldn't be that odd even if he were to advocate against using it.
- DSingularity 8y ago
  When you are writing a paper that requires latex it’s because it requires programming to properly set things up. Producing a typeset paper with latex is part writing and part programming.
  - Yoric 8y ago
    Well, in my experience, academics often write with LaTeX because that's what they know how to use. I've had to actually code in (La)TeX for some papers or slides, but that was pretty unusual. Most of the time, I was using it out of inertia, and because I trusted it more than Microsoft Word (which used to be very bad, at the time, I imagine it has grown better).
    - whatshisface 8y ago
      I find LaTeX to be a lot better at typesetting than Word, even today. It is much better at deciding how much space should go between words and the equations are as refined as it gets.
    - romwell 8y ago
      >Well, in my experience, academics often write with LaTeX because that's what they know how to use It's all they know how to use because it's the only thing that actually works to produce results they need with minimal pain. And you might not need to program in LaTeX, but everyone has their custom macros. Word really hasn't changed that much.
    - emodendroket 8y ago
      Word has a lot of great features but is also easy to get going and use the completely wrong way -- great to get people to buy it but likely to lead to some bad experiences trying to edit documents.
- deleted 8y ago
  [deleted]
- tincholio 8y ago
  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.
  - pessimizer 8y ago
    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.
aidenn0 8y ago
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 significant use. It seems intuitive to me that typed languages are bad for exploring algorithmic design, so could this where the disconnect is? Most programmers do not know what algorithm their final product is going to have when they start and dynamic languages are much more ergonomic when you are exploring he design space. Certainly if I knew exactly what program I was going to write when I started, I could probably write it in haskell; indeed once I have a working program, translating it to haskell is often fairly mechanical. However much of my time is spent trialing algorithms that may or may not be a good fit for the problem I'm solving and in those cases I feel like haskell gets in my way, while lisp gets out of my way. I don't know if there is any practical takeaway from this, but it does seem to at least give an explanation for the divide between PL theory and practice.
- drb91 8y ago
  > 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 love the ability of static, declared types to organize assumptions about code; I also love the ability to do terrible things to types to shoehorn poorly designed third party libraries into my codebase. I don't see it as a developer preference so much as dependent on the problem domain.
  - pixelrevision 8y ago
    For me it's typically weighted less on the type system and more the fact that I don't need to wait for a compiler or use any fancy tools to get a quick idea realized.
mad44 8y ago
A summary of the article the talk was based on and some discussion on this. http://muratbuffalo.blogspot.com/2018/07/if-youre-not-writing-program-dont-use.html http://muratbuffalo.blogspot.com/2018/07/if-youre-not-writin...
- jkingsbery 8y ago
  "It's quite likely that during their lifetime, machine learning will completely change the nature of programming." - Why is this the case? Even if it's true, it hardly seems obviously true.
  - about_help 8y ago
    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.
    - wellpast 8y ago
      This still hardly seems obvious.
    - Retra 8y ago
      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 conclusion. Now, machine learning to find bugs or adjust variables... yeah. I can see that.
      - deleted 8y ago
        [deleted]
    - xamuel 8y ago
      Assuming you could concretely nail down all the vague terms you just used, I'd be willing to bet real money we won't have anything remotely like that within the next 10 years :)
dmreedy 8y ago
I believe these are the kinds of ideas that might actually create a genuine engineering culture in software development. Until we start applying this kind of rigor to our work, I don't believe the title of "Software Engineer" is justified. It doesn't have to be TLA+; it doesn't have to be any particular tool or technology or pattern or whatever. But the attitude that rigor and formal technique is worth the additional effort is something that I don't find often in the current culture, or at least the narrow slice of it that I've experienced. The quote at the end sums it up nicely. Coding should be the easy part. A sentiment everyone tends to nod their head along with, but rarely has the discipline and willpower to implement.
- thwy12321 8y ago
  Coding is completely different from engineering, it will never be engineering, and it will never be the easy part. Engineering is a solved problem because we keep building the same buildings and the same bridges over and over. Its like deploying the same API over and over but only changing a few lines in a very rigorous way. If anything, engineering is not engineering and coding is engineering. Coding is actually creating. There is no strong hardened fool proof way to do it, theres simply too much complexity, too many possibilities for what could be.
- batteryhorse 8y ago
  I disagree that engineering is the best approach to writing software. I think this is the fundamental difference between people who prefer static vs dynamic typing. People who prefer static typing are more likely to say that one solution is more "correct" than the other, whereas dynamic typing allows more flexibility. I see writing software to be similar to writing music. Music has rules and structure, but leaves room for creativity and allows two or more highly skilled musicians to be able to play music together and improvise. Static typing imposes limitations (kind of like government), whereas dynamic typing gives you more freedom (but requires responsibility)
  - eponeponepon 8y ago
    You're conflating the act of building a product with the act of writing code. Even in the most expressive of languages, there are objectively good and bad ways of instructing your hardware to perform a particular calculation or set of calculations - and in the more rigid languages there is often a flat-out right and wrong way. Design your product with as much free thought and creativity as you please, but never let yourself believe your actual code is art. That - among many other outcomes - is how your platform gets compromised and your customers' identities stolen - not to mention how the successors to your job end up cursing your name and wasting time and money replacing your code wholesale.
ryanmarsh 8y ago
With all due respect to Leslie Lamport his "what could be more beautiful" explanation of Euclid's algorithm is no easier for me to make sense of than these[0] various implementations. For a "complex" problem[1] you cannot write a unified field definition[2] before the fact. Otherwise the problem would have to be merely complicated (most sufficiently useful systems are complex). The easiest way humans can make sense of a complex problem is to define a set of misfits[2], or tests. In practice efforts to find a better way of expressing the hidden algorithm of any given software system have failed. Yet "tests" have proven themselves as a sustainable way for humans to iteratively arrive at the most suitable solution to a complex problem and to guide understanding after the fact. tl;dr a more elegant programming language is nice but does not solve the fundamental problem with human minds and solving complex problem domains 0: http://www.codecodex.com/wiki/Euclidean_algorithm http://www.codecodex.com/wiki/Euclidean_algorithm 1: Cynefin, Dave Snowden 2: Notes on the Synthesis of Form, Christopher Alexander
- deleted 8y ago
  [deleted]
- gav 8y ago
  I have a feeling if more people read Alexander's books on design and patterns the quality of systems as a whole would increase. He is largely unknown in the tech circles I've been in.
- pron 8y ago
  I can't say I fully understand what you're saying (you use some uncommon terminology without defining it), but expressing algorithms mathematically does not impose any style or order on the exploration of the problem. It just gives you a language that is far more flexible for talking about both your problem and your solution at any level of detail that you choose than any programming language. TLA+ certainly allows you to describe a system as a set of scenarios/properties (what I assume you would call tests), and also of asserting that a design satisfies them. There was a system I worked on that was so complex that I was only able to design it using TLA+; engineers at Amazon, Microsoft, Oracle and Intel report similar experiences.
georgewsinger 8y ago
TLA+ vs. Functional Languages. I once tried to understand how TLA+ could be useful if your implementation language was primarily functional (i.e., Haskell). I wrote to Leslie Lamport on his mailing list and he actually responded with what I think was a very informative dialogue: https://groups.google.com/forum/#!searchin/tlaplus/George$20functional%7Csort:date/tlaplus/7vxzRBAR6TQ/AU_p_BwCFwAJ https://groups.google.com/forum/#!searchin/tlaplus/George$20... I hope TLA+ gains more popularity. It's an interesting technology.
- heydenberk 8y ago
  You should submit this thread to HN!
deleted 8y ago
[deleted]
jononor 8y ago
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.
- settler4 8y ago
  And then find a way to run that and so turn it into a programming language?
  - jononor 8y ago
    No we already have enough of those. But one could implement a way of annotating that some code/package (in ordinary programming language) implements a certain specification. This metadata should be searchable through the package manager.
    - emodendroket 8y ago
      What, like WCF?
- pron 8y ago
  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).
  - jononor 8y ago
    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.
lake99 8y ago
Looks like an interesting talk, but are the slides available online somewhere? Edit: Never mind. I found the slides he had made for the same talk given elsewhere. https://drive.google.com/open?id=1sZciK13LDh4rBFwbRCk0Oylga3NtNH6k https://drive.google.com/open?id=1sZciK13LDh4rBFwbRCk0Oylga3...
fastball 8y ago
As a side note: this presentation has a lot of wasted space in the video, and no offense to the speaker but I'd rather have a better view of his slides than his face. I can't even read some of the algorithms put on the screen!
- fastball 8y ago
  Downvotes? You guys prefer to not be able to see the slides and to instead have a good portion of the video's space taken up by the speaker themselves? Am I alone in this?
- yoz-y 8y ago
  I agree, the slides and speaker views should have been flipped.
nkoren 8y ago
Meta-comment: if you're producing a video of a presentation with lots of equations on the slides, PLEASE make the slides larger than a postage-stamp. I wanted to be able to follow this in detail, but was unable to do so because the slides were illegible, and following them verbally was something that even tripped up the presenter.
- mickeyr 8y ago
  There's a better version here: https://hitsmediaweb.h-its.org/Mediasite/Play/abdee6c8696a48288ce8c3e004c50cd41d?playFrom=13826&autoStart=false&popout=true https://hitsmediaweb.h-its.org/Mediasite/Play/abdee6c8696a48...
cwyers 8y ago
The assertion here seems to be that TLA+ isn't a programming language? I'm not sure that makes sense to me.
- pron 8y ago
  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 TLA+ cannot be a programming language, and that no programming language can have a similar descriptive power (you could embed a specification language inside a programming language, but then you arguably have two languages).
  - cwyers 8y ago
    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.
    - pron 8y ago
      > Since when is it a requirement that a programming language be efficient? It is (generally) a requirement that if you're writing a linear time algorithm, then the compiled/interpreted language will be executed in linear time. This is not the case for TLA+. You can describe linear time algorithms in a way that can only be compiled into, say, an exponential-time program, and possibly even not at all (i.e., extracting an implementation is undecidable). I wrote about this at some length here: https://pron.github.io/posts/tlaplus_part3 https://pron.github.io/posts/tlaplus_part3 > My larger point is that he seems to be using "programming language" as a shorthand for an imperative, typed programming language He means a language with the property I mentioned above. It is somewhat true that Prolog has a tiny portion of the expressive power that comes from a truly nondeterministic language such as TLA+, but it still falls under "programming language." If you want to get technical, a language such as Prolog can let you program with some limited use of quantifiers. In TLA+, you can specify using unlimited use of quantifiers ranging over infinite and even uncountable domains. In TLA+ you can describe the property "decides halting in linear time," and then show that a specific implementation can do so in some special cases for example. No programming language can do that (i.e. describe non-computable "algorithms") but it is essential for specification languages.
zackmorris 8y ago
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). And this was for a computer engineering degree at one of the best state universities for engineering in the US. Honestly 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. I don't care if they're where the jobs are. The mental cost of tracing through highly-imperative code, especially the new implicit style of languages and frameworks like Ruby and AngularJS (which 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) is so high that the underlying business logic is effectively obfuscated. I think we should get back to fundamentals. Maybe start with the shell and explain why separate address spaces connected by pipes are such a powerful abstraction, maybe touch on the Actor model, maybe show how spreadsheets and functional programming are equivalent, and how even written notation is superfluous. Really focus on declarative programming and code as media, and how that made the web approachable by nontechnical folks before it was turned into single page application spaghetti. There are so many examples from history of where better ways were found before the mainstream fell back into bad habits.
- Retric 8y ago
  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.
  - Koshkin 8y ago
    > Computers are still imperative "Computer Science is no more about computers than astronomy is about telescopes." — (Mis)attributed to Edsger Dijkstra, 1970.
moron4hire 8y ago
I think he makes an assumption that is fundamentally incorrect in the vast majority of cases: that the people owning the programs care about specification. There is a huge, dark-matter body of software development that goes on in the world under the thumb of megalomaniacs whose only metric of productivity is how much unpaid overtime his programmers are working.
jventura 8y ago
I don't know who the target audience was, but I found the lecture very confusing and the message really badly passed (he keeps talking what is already written in the slides, etc.). I had to play it at 1.6x the regular speed so I could move on with it. Regarding the topic, I think there are multiple ways of expressing ideas, where math happens to be just one of them. For instance, for the Greatest Common Divisor example, you could just say that "if x equals y the cgd of x and y is x, else you need to keep subtracting the smallest number from the largest until both are equal". You could use simple math, such as: / x if x=y gcd(x,y) = | gcd(x-y, y) if x > y \ gcd(x, y-x) if x < y Or you could use code: def gcd(x,y): if x==y: return x elif x>y: return gcd(x-y, y) else: return gcd(x, y-x) In essence, what I want to say is that his definition of beauty and power may not match mine, but I will not argue that math can be more succinct or allow for better abstractions in many cases. In the end, I got the feeling that he is trying to "sell" us his TLA+ approach.
- maccam912 8y ago
  I think he was trying to show that the TLA+ approach led to easier proofs of the base case and inductive case. I don't think he's arguing that your gcd program is bad. That's what I'd use. But TLA+ might be a good tool to break out when you need to have a solid proof that the code you wrote will always end up getting you the right answer. We probably don't need it for side projects, but it's nice to know that AWS has some proofs around that the services I use there can't end up in an inconsistent state as a result of any coding logic.
- deleted 8y ago
  [deleted]
- Apaec 8y ago
  Code doesn't have to look like that, look at the Haskell version: gcd x y | x == y = x | x > y = gcd (x - y) y | otherwise = gcd x (y - x) Much more close to the math notation.
rixarn 8y ago
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.
- Jtsummers 8y ago
  The problem with being too close to your hardware is that you become non-portable, or you create a situation where a CPU for a word processor becomes the dominant platform for decades. The goal should be somewhere between the two levels. Most code doesn't need to be as efficient as hand-tuned assembly. And most languages aren't so bad that they create many orders of magnitude difference between that hand-tuned assembly and themselves in performance. C may keep you within the same order of magnitude as that hand-tuned assembly. But ocaml can as well, and offers much cleaner expressions of many algorithms and ideas (closer to their specification concept than their machine code run time). When one language becomes insufficient, accept polyglots. If Erlang's mathematical computations are too slow, create a C program that can be loaded in, or that calls out to OpenCL if need be. But Erlang's ability to express concurrency is among the best, and C's is among the worst. So why use one of the worst languages for concurrency when you can use one of the best, and restrict yourself to C code where needed? The same consideration should be applied to other problem areas. Logic languages and constraint programming can solve many computational problems, and often very efficiently. But both are light years away from the underlying machine they're running on. Should they be discarded so we can hand write and hand tune a constraint solver in C every time? While it's wasteful to rewrite everything 10 levels above your hardware (an interpreted language, running on a vm, running on a vm, until eventually you find the CPU), it's hardly appropriate to drop everything and insist on the lowest level (or near lowest level) language around. Instead, drop those inefficient languages that barely add anything of value (no novel capabilities, no better safety guarantees), keep the ones that are reasonably efficient or maybe inefficient but offer some true utility. Then code in the highest level language that's reasonable, moving down the stack only when needed for performance (or other) reasons.
dchichkov 8y ago
I thought more progressive approach is phasing out incomplete and obscure Greek single letter notations. Like done by OpenAI, or by "Structure and Interpretation of Classical Mechanics" or in the "Functional Differential Geometry".
jmpeax 8y ago
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.
microcolonel 8y ago
Spreadsheets are computer programs, and |things that are reasonable to represent as a spreadsheet| is the wrong subset of computer programs to solve your problem.
scentoni 8y ago
I noted that the one question in the video was asked by https://en.wikipedia.org/wiki/William_Kahan https://en.wikipedia.org/wiki/William_Kahan , the main architect of https://en.wikipedia.org/wiki/IEEE_754 https://en.wikipedia.org/wiki/IEEE_754 floating point. Both Lamport and Kahan are Turing Award winners. https://en.wikipedia.org/wiki/Leslie_Lamport https://en.wikipedia.org/wiki/Leslie_Lamport
cttet 8y ago
Don't have the chance to watch the video but highly disagree with the title. Math as a language is just a DSL which carries a lot of historical burden that is not friendly at all. Programming languages can achieve same level of abstraction with more clarity. Math instead added too much specific syntactic sugar(bad is multiply(b, a, d), log a is log(10, a) or log(e, a)), operator overload (/ for divide and dy/dx for differentiation operator, same grammar for scalar and matrix multiplication, one of which is communicative while the other is not), and complicated design (integral would be much clearer if we write integrate(target=ax, over=x, from=0, to=10) instead of the original one).
- wodenokoto 8y ago
  The talk is about TLA+, which is somehow not a programming language, yet you follow a syntax and describe algorithms and then I'm not sure what happens. Maybe you prove your algorithms and call it a day, or maybe you can ask your program to run it, like an external dependency. It's very unclear how TLA+ is neither programming or how it fits in with your programming. But he is not asking you to do normal math notation.
  - pron 8y ago
    > Maybe you prove your algorithms and call it a day You can do that, or check it with a model checker (which is much easier). Either way, you verify your algorithm rather than "run" it (although the model checker lets you simulate or "run" a random execution).
untangle 8y ago
A Programming Language (APL) started life as a mathematical notation. As such, it is the closest thing that I have encountered for expressing algorithms as code. It is the embodiment of "freeing the hidden algorithm." Fifty examples of such are given in the following link: http://www.jsoftware.com/papers/50/ http://www.jsoftware.com/papers/50/

253 points by azhenley 8y ago

dzdt 8y ago

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?

aidenn0 8y ago
I'm not sure how your comment pertains to the contents of the video, but considering it's been over 30 yeears since he started work on LaTeX, it wouldn't be that odd even if he were to advocate against using it.
DSingularity 8y ago
When you are writing a paper that requires latex it’s because it requires programming to properly set things up. Producing a typeset paper with latex is part writing and part programming.
- Yoric 8y ago
  Well, in my experience, academics often write with LaTeX because that's what they know how to use. I've had to actually code in (La)TeX for some papers or slides, but that was pretty unusual. Most of the time, I was using it out of inertia, and because I trusted it more than Microsoft Word (which used to be very bad, at the time, I imagine it has grown better).
  - whatshisface 8y ago
    I find LaTeX to be a lot better at typesetting than Word, even today. It is much better at deciding how much space should go between words and the equations are as refined as it gets.
  - romwell 8y ago
    >Well, in my experience, academics often write with LaTeX because that's what they know how to use It's all they know how to use because it's the only thing that actually works to produce results they need with minimal pain. And you might not need to program in LaTeX, but everyone has their custom macros. Word really hasn't changed that much.
  - emodendroket 8y ago
    Word has a lot of great features but is also easy to get going and use the completely wrong way -- great to get people to buy it but likely to lead to some bad experiences trying to edit documents.
deleted 8y ago
[deleted]
tincholio 8y ago
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.
- pessimizer 8y ago
  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.

aidenn0 8y ago

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 significant use. It seems intuitive to me that typed languages are bad for exploring algorithmic design, so could this where the disconnect is? Most programmers do not know what algorithm their final product is going to have when they start and dynamic languages are much more ergonomic when you are exploring he design space. Certainly if I knew exactly what program I was going to write when I started, I could probably write it in haskell; indeed once I have a working program, translating it to haskell is often fairly mechanical. However much of my time is spent trialing algorithms that may or may not be a good fit for the problem I'm solving and in those cases I feel like haskell gets in my way, while lisp gets out of my way. I don't know if there is any practical takeaway from this, but it does seem to at least give an explanation for the divide between PL theory and practice.

drb91 8y ago
> 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 love the ability of static, declared types to organize assumptions about code; I also love the ability to do terrible things to types to shoehorn poorly designed third party libraries into my codebase. I don't see it as a developer preference so much as dependent on the problem domain.
- pixelrevision 8y ago
  For me it's typically weighted less on the type system and more the fact that I don't need to wait for a compiler or use any fancy tools to get a quick idea realized.

mad44 8y ago

A summary of the article the talk was based on and some discussion on this. http://muratbuffalo.blogspot.com/2018/07/if-youre-not-writing-program-dont-use.html http://muratbuffalo.blogspot.com/2018/07/if-youre-not-writin...

jkingsbery 8y ago
"It's quite likely that during their lifetime, machine learning will completely change the nature of programming." - Why is this the case? Even if it's true, it hardly seems obviously true.
- about_help 8y ago
  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.
  - wellpast 8y ago
    This still hardly seems obvious.
  - Retra 8y ago
    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 conclusion. Now, machine learning to find bugs or adjust variables... yeah. I can see that.
    - deleted 8y ago
      [deleted]
  - xamuel 8y ago
    Assuming you could concretely nail down all the vague terms you just used, I'd be willing to bet real money we won't have anything remotely like that within the next 10 years :)

dmreedy 8y ago

I believe these are the kinds of ideas that might actually create a genuine engineering culture in software development. Until we start applying this kind of rigor to our work, I don't believe the title of "Software Engineer" is justified. It doesn't have to be TLA+; it doesn't have to be any particular tool or technology or pattern or whatever. But the attitude that rigor and formal technique is worth the additional effort is something that I don't find often in the current culture, or at least the narrow slice of it that I've experienced. The quote at the end sums it up nicely. Coding should be the easy part. A sentiment everyone tends to nod their head along with, but rarely has the discipline and willpower to implement.

thwy12321 8y ago
Coding is completely different from engineering, it will never be engineering, and it will never be the easy part. Engineering is a solved problem because we keep building the same buildings and the same bridges over and over. Its like deploying the same API over and over but only changing a few lines in a very rigorous way. If anything, engineering is not engineering and coding is engineering. Coding is actually creating. There is no strong hardened fool proof way to do it, theres simply too much complexity, too many possibilities for what could be.
batteryhorse 8y ago
I disagree that engineering is the best approach to writing software. I think this is the fundamental difference between people who prefer static vs dynamic typing. People who prefer static typing are more likely to say that one solution is more "correct" than the other, whereas dynamic typing allows more flexibility. I see writing software to be similar to writing music. Music has rules and structure, but leaves room for creativity and allows two or more highly skilled musicians to be able to play music together and improvise. Static typing imposes limitations (kind of like government), whereas dynamic typing gives you more freedom (but requires responsibility)
- eponeponepon 8y ago
  You're conflating the act of building a product with the act of writing code. Even in the most expressive of languages, there are objectively good and bad ways of instructing your hardware to perform a particular calculation or set of calculations - and in the more rigid languages there is often a flat-out right and wrong way. Design your product with as much free thought and creativity as you please, but never let yourself believe your actual code is art. That - among many other outcomes - is how your platform gets compromised and your customers' identities stolen - not to mention how the successors to your job end up cursing your name and wasting time and money replacing your code wholesale.

ryanmarsh 8y ago

With all due respect to Leslie Lamport his "what could be more beautiful" explanation of Euclid's algorithm is no easier for me to make sense of than these[0] various implementations. For a "complex" problem[1] you cannot write a unified field definition[2] before the fact. Otherwise the problem would have to be merely complicated (most sufficiently useful systems are complex). The easiest way humans can make sense of a complex problem is to define a set of misfits[2], or tests. In practice efforts to find a better way of expressing the hidden algorithm of any given software system have failed. Yet "tests" have proven themselves as a sustainable way for humans to iteratively arrive at the most suitable solution to a complex problem and to guide understanding after the fact. tl;dr a more elegant programming language is nice but does not solve the fundamental problem with human minds and solving complex problem domains 0: http://www.codecodex.com/wiki/Euclidean_algorithm http://www.codecodex.com/wiki/Euclidean_algorithm 1: Cynefin, Dave Snowden 2: Notes on the Synthesis of Form, Christopher Alexander

deleted 8y ago
[deleted]
gav 8y ago
I have a feeling if more people read Alexander's books on design and patterns the quality of systems as a whole would increase. He is largely unknown in the tech circles I've been in.
pron 8y ago
I can't say I fully understand what you're saying (you use some uncommon terminology without defining it), but expressing algorithms mathematically does not impose any style or order on the exploration of the problem. It just gives you a language that is far more flexible for talking about both your problem and your solution at any level of detail that you choose than any programming language. TLA+ certainly allows you to describe a system as a set of scenarios/properties (what I assume you would call tests), and also of asserting that a design satisfies them. There was a system I worked on that was so complex that I was only able to design it using TLA+; engineers at Amazon, Microsoft, Oracle and Intel report similar experiences.

georgewsinger 8y ago

TLA+ vs. Functional Languages. I once tried to understand how TLA+ could be useful if your implementation language was primarily functional (i.e., Haskell). I wrote to Leslie Lamport on his mailing list and he actually responded with what I think was a very informative dialogue: https://groups.google.com/forum/#!searchin/tlaplus/George$20functional%7Csort:date/tlaplus/7vxzRBAR6TQ/AU_p_BwCFwAJ https://groups.google.com/forum/#!searchin/tlaplus/George$20... I hope TLA+ gains more popularity. It's an interesting technology.

heydenberk 8y ago
You should submit this thread to HN!

deleted 8y ago

[deleted]

jononor 8y ago

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.

settler4 8y ago
And then find a way to run that and so turn it into a programming language?
- jononor 8y ago
  No we already have enough of those. But one could implement a way of annotating that some code/package (in ordinary programming language) implements a certain specification. This metadata should be searchable through the package manager.
  - emodendroket 8y ago
    What, like WCF?
pron 8y ago
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).
- jononor 8y ago
  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.

lake99 8y ago

Looks like an interesting talk, but are the slides available online somewhere? Edit: Never mind. I found the slides he had made for the same talk given elsewhere. https://drive.google.com/open?id=1sZciK13LDh4rBFwbRCk0Oylga3NtNH6k https://drive.google.com/open?id=1sZciK13LDh4rBFwbRCk0Oylga3...

fastball 8y ago

As a side note: this presentation has a lot of wasted space in the video, and no offense to the speaker but I'd rather have a better view of his slides than his face. I can't even read some of the algorithms put on the screen!

fastball 8y ago
Downvotes? You guys prefer to not be able to see the slides and to instead have a good portion of the video's space taken up by the speaker themselves? Am I alone in this?
yoz-y 8y ago
I agree, the slides and speaker views should have been flipped.

nkoren 8y ago

Meta-comment: if you're producing a video of a presentation with lots of equations on the slides, PLEASE make the slides larger than a postage-stamp. I wanted to be able to follow this in detail, but was unable to do so because the slides were illegible, and following them verbally was something that even tripped up the presenter.

mickeyr 8y ago
There's a better version here: https://hitsmediaweb.h-its.org/Mediasite/Play/abdee6c8696a48288ce8c3e004c50cd41d?playFrom=13826&autoStart=false&popout=true https://hitsmediaweb.h-its.org/Mediasite/Play/abdee6c8696a48...

cwyers 8y ago

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

pron 8y ago
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 TLA+ cannot be a programming language, and that no programming language can have a similar descriptive power (you could embed a specification language inside a programming language, but then you arguably have two languages).
- cwyers 8y ago
  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.
  - pron 8y ago
    > Since when is it a requirement that a programming language be efficient? It is (generally) a requirement that if you're writing a linear time algorithm, then the compiled/interpreted language will be executed in linear time. This is not the case for TLA+. You can describe linear time algorithms in a way that can only be compiled into, say, an exponential-time program, and possibly even not at all (i.e., extracting an implementation is undecidable). I wrote about this at some length here: https://pron.github.io/posts/tlaplus_part3 https://pron.github.io/posts/tlaplus_part3 > My larger point is that he seems to be using "programming language" as a shorthand for an imperative, typed programming language He means a language with the property I mentioned above. It is somewhat true that Prolog has a tiny portion of the expressive power that comes from a truly nondeterministic language such as TLA+, but it still falls under "programming language." If you want to get technical, a language such as Prolog can let you program with some limited use of quantifiers. In TLA+, you can specify using unlimited use of quantifiers ranging over infinite and even uncountable domains. In TLA+ you can describe the property "decides halting in linear time," and then show that a specific implementation can do so in some special cases for example. No programming language can do that (i.e. describe non-computable "algorithms") but it is essential for specification languages.

zackmorris 8y ago

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). And this was for a computer engineering degree at one of the best state universities for engineering in the US. Honestly 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. I don't care if they're where the jobs are. The mental cost of tracing through highly-imperative code, especially the new implicit style of languages and frameworks like Ruby and AngularJS (which 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) is so high that the underlying business logic is effectively obfuscated. I think we should get back to fundamentals. Maybe start with the shell and explain why separate address spaces connected by pipes are such a powerful abstraction, maybe touch on the Actor model, maybe show how spreadsheets and functional programming are equivalent, and how even written notation is superfluous. Really focus on declarative programming and code as media, and how that made the web approachable by nontechnical folks before it was turned into single page application spaghetti. There are so many examples from history of where better ways were found before the mainstream fell back into bad habits.

Retric 8y ago
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.
- Koshkin 8y ago
  > Computers are still imperative "Computer Science is no more about computers than astronomy is about telescopes." — (Mis)attributed to Edsger Dijkstra, 1970.

moron4hire 8y ago

I think he makes an assumption that is fundamentally incorrect in the vast majority of cases: that the people owning the programs care about specification. There is a huge, dark-matter body of software development that goes on in the world under the thumb of megalomaniacs whose only metric of productivity is how much unpaid overtime his programmers are working.

jventura 8y ago

I don't know who the target audience was, but I found the lecture very confusing and the message really badly passed (he keeps talking what is already written in the slides, etc.). I had to play it at 1.6x the regular speed so I could move on with it. Regarding the topic, I think there are multiple ways of expressing ideas, where math happens to be just one of them. For instance, for the Greatest Common Divisor example, you could just say that "if x equals y the cgd of x and y is x, else you need to keep subtracting the smallest number from the largest until both are equal". You could use simple math, such as: / x if x=y gcd(x,y) = | gcd(x-y, y) if x > y \ gcd(x, y-x) if x < y Or you could use code: def gcd(x,y): if x==y: return x elif x>y: return gcd(x-y, y) else: return gcd(x, y-x) In essence, what I want to say is that his definition of beauty and power may not match mine, but I will not argue that math can be more succinct or allow for better abstractions in many cases. In the end, I got the feeling that he is trying to "sell" us his TLA+ approach.

maccam912 8y ago
I think he was trying to show that the TLA+ approach led to easier proofs of the base case and inductive case. I don't think he's arguing that your gcd program is bad. That's what I'd use. But TLA+ might be a good tool to break out when you need to have a solid proof that the code you wrote will always end up getting you the right answer. We probably don't need it for side projects, but it's nice to know that AWS has some proofs around that the services I use there can't end up in an inconsistent state as a result of any coding logic.
deleted 8y ago
[deleted]
Apaec 8y ago
Code doesn't have to look like that, look at the Haskell version: gcd x y | x == y = x | x > y = gcd (x - y) y | otherwise = gcd x (y - x) Much more close to the math notation.

rixarn 8y ago

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.

Jtsummers 8y ago
The problem with being too close to your hardware is that you become non-portable, or you create a situation where a CPU for a word processor becomes the dominant platform for decades. The goal should be somewhere between the two levels. Most code doesn't need to be as efficient as hand-tuned assembly. And most languages aren't so bad that they create many orders of magnitude difference between that hand-tuned assembly and themselves in performance. C may keep you within the same order of magnitude as that hand-tuned assembly. But ocaml can as well, and offers much cleaner expressions of many algorithms and ideas (closer to their specification concept than their machine code run time). When one language becomes insufficient, accept polyglots. If Erlang's mathematical computations are too slow, create a C program that can be loaded in, or that calls out to OpenCL if need be. But Erlang's ability to express concurrency is among the best, and C's is among the worst. So why use one of the worst languages for concurrency when you can use one of the best, and restrict yourself to C code where needed? The same consideration should be applied to other problem areas. Logic languages and constraint programming can solve many computational problems, and often very efficiently. But both are light years away from the underlying machine they're running on. Should they be discarded so we can hand write and hand tune a constraint solver in C every time? While it's wasteful to rewrite everything 10 levels above your hardware (an interpreted language, running on a vm, running on a vm, until eventually you find the CPU), it's hardly appropriate to drop everything and insist on the lowest level (or near lowest level) language around. Instead, drop those inefficient languages that barely add anything of value (no novel capabilities, no better safety guarantees), keep the ones that are reasonably efficient or maybe inefficient but offer some true utility. Then code in the highest level language that's reasonable, moving down the stack only when needed for performance (or other) reasons.

dchichkov 8y ago

I thought more progressive approach is phasing out incomplete and obscure Greek single letter notations. Like done by OpenAI, or by "Structure and Interpretation of Classical Mechanics" or in the "Functional Differential Geometry".

jmpeax 8y ago

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.

microcolonel 8y ago

Spreadsheets are computer programs, and |things that are reasonable to represent as a spreadsheet| is the wrong subset of computer programs to solve your problem.

scentoni 8y ago

I noted that the one question in the video was asked by https://en.wikipedia.org/wiki/William_Kahan https://en.wikipedia.org/wiki/William_Kahan , the main architect of https://en.wikipedia.org/wiki/IEEE_754 https://en.wikipedia.org/wiki/IEEE_754 floating point. Both Lamport and Kahan are Turing Award winners. https://en.wikipedia.org/wiki/Leslie_Lamport https://en.wikipedia.org/wiki/Leslie_Lamport

cttet 8y ago

Don't have the chance to watch the video but highly disagree with the title. Math as a language is just a DSL which carries a lot of historical burden that is not friendly at all. Programming languages can achieve same level of abstraction with more clarity. Math instead added too much specific syntactic sugar(bad is multiply(b, a, d), log a is log(10, a) or log(e, a)), operator overload (/ for divide and dy/dx for differentiation operator, same grammar for scalar and matrix multiplication, one of which is communicative while the other is not), and complicated design (integral would be much clearer if we write integrate(target=ax, over=x, from=0, to=10) instead of the original one).

wodenokoto 8y ago
The talk is about TLA+, which is somehow not a programming language, yet you follow a syntax and describe algorithms and then I'm not sure what happens. Maybe you prove your algorithms and call it a day, or maybe you can ask your program to run it, like an external dependency. It's very unclear how TLA+ is neither programming or how it fits in with your programming. But he is not asking you to do normal math notation.
- pron 8y ago
  > Maybe you prove your algorithms and call it a day You can do that, or check it with a model checker (which is much easier). Either way, you verify your algorithm rather than "run" it (although the model checker lets you simulate or "run" a random execution).

untangle 8y ago

A Programming Language (APL) started life as a mathematical notation. As such, it is the closest thing that I have encountered for expressing algorithms as code. It is the embodiment of "freeing the hidden algorithm." Fifty examples of such are given in the following link: http://www.jsoftware.com/papers/50/ http://www.jsoftware.com/papers/50/