Live data from Hacker News

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

youtube.com

101–110 of 288 posts

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

#101
post #88

Earlier quoted context omitted.

Gradual typing has a strong tendency to turn into never-typing because when you've got it running there is no real point to going back and adding types. Which divides people back into those who want dynamic typing and those who want static typing.

Tracing JIT VMs gather the information on what the types actually are at runtime. I wish that such JIT VMs running server software would gather such information, which could then be automatically applied.

The JIT VMs gather that information, but then are careful to hide all of the typed calls behind run-time checks for the validity of the types. Failing to do so is an invitation to create bugs on rare use cases that didn't happen to be in your run. Making those code changes either results in duplicated auto-generated code that nobody looks at, or results in a source of possible bugs.

To give a concrete example, suppose that you have a weighted graph whose weights are integers. Code to find a Minimum Spanning Tree will always have an integer for the weight. Great. But if you add that type annotation, you'll run into trouble when someone checks whether the previously found MST is unique by calling the same algorithm again using as weights (weight, edges_in_common_with_prev_mst). (This will find the MST that shares as few edges as possible with the original, so if there are > 1 you'll find a different one.) Those ordered pairs were just fine in the original code, but don't fit the type annotation.

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

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

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

#103
post #93
post #31

Earlier quoted context omitted.

With C# you can mix dynamic and static to some degree. In some cases like parsing JSON dynamic code can be much shorter. But for maintainability the dynamic code parts should be kept localized and to a minimum/

Works pretty well in typescript, too. I don't find myself actually using gradual typing though. Not very often at least. Even in prototypical stages of an application, I usually just put together the types of what I currently have, even if I think they will change later.

Typescript is pretty similar to C# from what I can tell. Not a surprise considering that the designer is the same.

I have found it very useful for things like translating incoming JSON or XML to the typed world. As long as the input data is of known format dynamic code is much shorter and concise.

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

#104
post #12
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 find that ML (Ocaml and F#) does not get in my way (Haskell being the exception due to the absence of quick and dirty mutability) while dynamic typing (in python) does hinder me when I depend on external libraries.

> Haskell being the exception due to the absence of quick and dirty mutability

Haskell has ST for mutable local variables, and for the truly "quick and dirty" cases there's always unsafePerformIO. What is it you're trying to express that wouldn't be handled by either of these options?

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

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

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

#106

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.

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

#107

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…

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?

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

#108

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…

> time to phase out teaching imperative

Knuth would probably disagree.

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

#109
post #65

Earlier quoted context omitted.

>the attitude that rigor and formal technique is worth the additional effort Commercially speaking - it's usually not.

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.

It speaks to economics.

A business process that works "by itself" most of the time, but requires human intervention once in a while, is still a functional business process. The unit of "software + 5% of this person's time" is perfectly workable. And if the cost of the fix is more than the NPV of 5% of that person's time, it isn't worth making.

Catastrophic failure risk, of course, changes the analysis. But a huge range of things are not catastrophic in their failure modes.

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

#110
post #106

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.

> Computers are still imperative

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

Post reply on HN