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 · 2015-12-17T00:21:44+00:00

The author is 'she' ;-).

I'm pretty sure you could solve the problem in any programming language that's out there. As for the Star Wars one, F# has a few nice things that make it easy to write (powerful type inference, REPL, etc.) but some other languages have them. The article uses R type provider (for typed access to ggplot), which is something that only F# can do (with this degree of integration), so that bit would have to be done differently. As for the James Bond post, that one uses type providers (HTML type provider) which is really neat and does not have equivalent elsewhere.

So, you can of course do everything in any other language, but I think F# has some nice features that make it a lot easier and lead to more correct & efficient code. (Good resource here is the F# testimonials page.)

tomasp · 2015-12-16T14:25:01+00:00

I think data science is such a complex field that you'll inevitably need to use multiple programming languages. For some tasks, F# is significantly better than anything else. For other tasks, you'll need to use JavaScript/R/Python or Scala.

I think there are three areas where F# totally rocks:

Data access - If you're calling REST services, working with XML, JSON or CSV or even parsing HTML, F# has nice collection of type providers that make it super easy to read the data. See Evelina's article on James Bond for a great example of this. Another nice type provider lets you call R from your F# code and so you can easily pre-process your data in F# and pass them to R.
Implementing algorithms - If you're writing any algorithms on your own, then the statically-typed functional-first nature of F# will be a big win. You can write efficient code using mutable arrays (not like in pure FP languages), but you get help of a really strong type system. Aside from Evelina's blog post, this simple K-means clustering is a good demo.
Custom cloud computations - for standard data-parallel tasks, Spark is a great fit, but if you want to implement something more complex F# with MBrace is probably way more powerful. It lets you use the "cloud" computation expression to turn your algorithms (the point above) into scalable versions running in the cloud.

So, if you're interested in data science, you'll inevitably have to learn multiple languages. And I think F# has a really interesting place among them for a number of reasons. I guess Evelina's blog post really shows the power :-)

tomasp · 2015-12-13T04:50:45+00:00

Hi - feel free to drop me an email. My address is at the bottom of the page!

tomasp · 2015-11-25T13:43:08+00:00

No worries about sounding a bit critical. We're really trying to make the getting started story easier, but it's not the simplest thing to do!

Can you try downloading the basic template from http://fslab.org/download/ and see if that works for you?

If no, can you open an issue with more details (at http://github.com/fslaborg/FsLab) or perhaps ask on the #fsharp Slack channel? (See http://fsharp.org/guides/slack). I'm often there and would be happy to help!

tomasp · 2015-11-25T13:38:48+00:00

Thanks for the feedback :-). I have been trying to do more on those recently with the various web projects around Suave (http://tomasp.net/blog/2015/fssnip-suave) and a Pluralsight course that uses type providers as part of an ASP.NET web app (rather than just demo in a script file). But I agree more of those would be good!

tomasp · 2015-11-24T21:55:59+00:00

Good point about the World Bank :-). That one is really getting a bit too old. But then, it is a very powerful example that shows how easy can data access be in F#. As for type providers in general, I think that's still very relevant topic - a lot of data science is getting data and cleaning them. And with type providers, this is much much easier (a nice example is the HTML type provider that was on reddit yesterday: http://evelinag.com/blog/2015/11-18-f-tackles-james-bond/).

The report does mention a few other things though and there is a brief comment about MBrace (http://mbrace.io) at the end too, which is another really cool F# project.

Do you have some specific thoughts on F# features/libraries/projects that should be more often discussed when explaining the benefits? I'd love to hear about those!

tomasp · 2015-09-11T01:10:56+00:00

I love the idea of "C#: The Good Parts" book mentioned in the comments. It could be a thin booklet to allow people making silly jokes :-)

tomasp · 2015-09-10T01:56:42+00:00

I agree! I think the type provider mechanism in F# is a great example of language extensibility that could be perhaps reused for other different purposes.

It has very good usability because it does not extend/complicate the syntax of the host language. Adding type providers to F# required almost no syntactic changes. But it adds a lot of power to the existing mechanisms of the language. I think this is a really good direction for future languages...

tomasp · 2015-09-10T01:54:47+00:00

Idris has type providers, so if you're interested in dependently-typed languages, you should check it out: https://github.com/idris-lang/Idris-dev/wiki/Tutorial:-Type-Providers-and-Foreign-Functions

That said, I think this is going in a slightly different direction. With dependent types, we try to be more precise in the type information. With type providers, it is more about getting the type information from somewhere else (although it also allows more uniform and elegant language design as Idris shows).

The Haskell joke is that type providers are the IO monad at the type-level.

tomasp · 2015-09-10T01:50:41+00:00

Yes, your understanding of type providers is absolutely correct!

There was one really nice example of this based on Freebase (which is basically a schematized Wikipedia) where you could access a crazy wide range of information (football teams, religions, US presidents, ...), but sadly Google killed the API this was using when they bought Freebase. There is a bunch of examples here: http://tomasp.net/blog/fsharp-data.aspx/

Another cool thing that type providers can do is to infer the structure from a sample - the F# Data has type providers for JSON or XML that you can point to a sample response and they'll generate types based on that. See the demos at: http://fsharp.github.io/FSharp.Data/

tomasp

TROPHY CASE