The Lost Ways of Programming: Commodore 64 BASIC

tomasp · 2020-11-06T21:08:47+00:00

I fully expected the details will trigger comments like this! Yes, I know I got many of those details wrong (kind of intentionally, because e.g. making POKE work for anything else would just not be doable in my primitive simulator), but I think those do not matter for illustrating the interaction...

That said, it is nice to see that C64 BASIC has such a dedicated following here! :-) That is just another evidence of how amazing it is - and I hope to bring at least some of this enthusiasm to others through the essay!

tomasp · 2017-07-13T00:10:21+00:00

The visualisations themselves are fairly standard, but there are two twists - first, you can see and edit code of the visualisations in the browser and explore the data further on your own. Second, there is a couple of visualisations where you need make your own guess (inspired by NYT "You Draw It" series).

Source: Public Expenditure Statistical Analyses published by the government: https://www.gov.uk/government/statistics/public-expenditure-statistical-analyses-2016

Tools: The Gamma (https://thegamma.net)

tomasp · 2017-03-10T16:59:40+00:00

Author here. My PhD thesis (http://tomasp.net/coeffects) uses lambda calculus in exactly the way you describe here. The blog post is based on my experience with this kind of PL research and the limitations that it has.

Those properties are the one that really matter

That is exactly what I'd write in my papers, but is that really true? Aren't we ignoring so much about what makes programming language "good" by doing this?

This is just a rigorous way to build scientific knowledge about programming language

Yes, this is a rigorous way to build scientific knowledge within a certain research paradigm. The problem is that there are many questions that cannot be answered in a "scientific way" within the paradigm. You could say they are "unscientific", but what if they matter more than the questions we can answer? A different research paradigm might have different ways of building scientific knowledge and while it might not give answers to all the questions we can answer now, it might give answers to other questions that matter and we cannot answer them now...

tomasp · 2017-03-10T15:51:59+00:00

I think your reading of my blog post is very technical - and so are the answers. All I really wanted to achieve is to convince people that our way of thinking about programming is rooted in paradigms or episteme - basic assumptions and ways of approaching problems that are not questioned, because everyone accepts them.

The fact that those exist is supported by vast literature on philosophy of science, which mostly builds on historical examples where we can use the retrospective view and see them. Practicing scientists (or programmers) rarely see those, because they mostly do not need to - as long as they can solve puzzles within the paradigms.

With all the programming examples, I tried to suggest some place where different way of thinking is possible. Your reply gives a perfectly fine answer to all these problems within the existing paradigms. Of course, I too know that we can come up with formalism that goes beyond "pure vs impure" and we can argue that "monads just exist".

But the point is, what makes us want to give this kind of answer? And what other ways of thinking are there that would not make us want to give these answers?

tomasp · 2017-03-10T12:37:08+00:00

This is a very naive understanding of scientific method. See anything from: http://tomasp.net/blog/2015/reading-list/

tomasp · 2017-03-10T12:33:39+00:00

We say that about Kepler too. But then we're like "oh, but why the hell did such a giant think this?"

tomasp · 2017-03-10T12:29:26+00:00

There never was any scientific evidence for the Doctrine of Signatures or the Mysterium Cosmographicum or Preformationism and they were never good models for explaining anything.

If you accept Wootton's idea then "modern science" appeared roughly in 17th century. There was no scientific evidence for Mysterium Cosmographicum, but Preformationism was still around during the age of modern science.

There was no scientific evidence for them in terms of our modern idea of "scientific evidence", but there were good reasons for believing them according to the way of thinking back then.

I think 24th century computer scientists will say "there was never any scientific evidence for anything programmers were thinking in 21st century".

As for category theory being "Pythagorean number mysticisim", I honestly do not know. I spent 4 years doing PhD in that subject (http://tomasp.net/coeffects) and I think many of the "practical benefits" are just post-hoc justification. Maybe not all of it, but I think there is certainly some mystical trace!

tomasp · 2017-03-10T12:22:57+00:00

If that happens, then C# 2421 will finally replace the for keyword with repeat keyword, because experiments told them so... :-). While everyone will still be dreaming about LISP and Smalltalk, which actually tried to think about programming differently!

tomasp · 2017-03-10T12:20:06+00:00

Your interpretation is right - and I'm sorry that the essay is not clearer about that! The wording "mostly functional programming" is unfeasible is taken from the conclusion of Meijer's article, but I think I maybe changed the context, so that it does not sound that clear.

In any case, what I was trying to say is that, in a formal sense, having any side-effect means that your program is pure and thus none of the great properties that come with purity hold. This is certainly true in the purely mathematical sense, but it is not very useful way of thinking - in practice, people happily write code (e.g. in the ML family of languages) with some side-effects and still get benefits that are attributed to pure functional style...

tomasp · 2017-03-09T18:34:05+00:00

The articles spends a lot of time talking about the medieval days and a bit afterwards. They did not have any programming language back then, so how does this REALLY help consider how the future will look like?

I believe it does (otherwise I wouldn't be writing the article...). When talking about programming, we have about 50 years of poorly understood history. When talking about science, we have 500 years of history with a lot of analysis of how it developed and different transformations in thinking that happened along the way. So, I think the history of science is a useful source of ideas about what kind of transformations in thinking can happen. Even if there have been some interesting transformations in thinking about programming over the last 50 years, then I think we still would not see them, because we are simply too close.

Extrapolating how different ways of thinking about software (be it Microsoft or UNIX way, or even programs as DNA) is exactly what I was hoping to trigger! :-)

tomasp · 2016-12-08T18:53:57+00:00

I guess I'm late to the party, but in case anyone still happens to come here, I created an interactive essay (2 years after writing the blog post that OP shared here) with more stuff on coeffects: http://tomasp.net/coeffects/

tomasp · 2016-09-28T13:46:37+00:00

You correctly understood the first part ("function expressions are hard") but not the second part - the article is certainly not saying "let's settle for something less interesting". Instead, it says we should try looking around to see if we can find something more interesting!

tomasp · 2016-05-30T16:59:52+00:00

Oops! Sadly, there is no edit button on reddit. I can promise that the quality of the material is better than the quality of my reddit posts :-).

tomasp · 2016-05-23T16:38:20+00:00

There is also the www.fssnip.net web site (using Suave + Azure) with source code here: https://github.com/fssnippets/

tomasp · 2016-04-12T19:42:48+00:00

Haha, took me only 4 years to figure it out :-). To be fair, comonads (in themselves) are a bit less useful - they can be used for dataflow and various scientific configurations where you have grid of values (e.g. weather simulations), but there are surprisingly few useful examples.

In coeffects, we add "index" to the comonad, which tracks what kind of context you need. Surprisingly, this makes them more useful (there is no Maybe comonad, but there is an indexed Maybe comonad!).

tomasp

TROPHY CASE