I remember this being true for me, a long, long time ago. There was something like a four year gap between me being able to munge linked lists in TiBasic and me being able to reliably install java and compile System.out.println(“hello world”)
Yes. The reason I ended up being a python dev is that way back in the day there was a free, easy installer that ran on my machine, including a functional if basic IDE with syntax highlighting. This was Python 1.5 on a Mac Classic. Even getting a C compiler would have been a major lift, this was in the modem days so downloading was always an adventure.
Yes, definitely the case. Just imagine a class with 100 students, each with a system that has its own quirks (OS, browser, and a mix of versions, etc). We built codeBoot (https://codeboot.org) specifically for this reason!
I hate to second the grandparent, but perhaps the install process is the most difficult part for the instructor because it is at a stage where the instructor feels 90% responsible for the outcomes.
A criticism like “I didn’t understand recursive functions” is a student problem. A criticism like “the instructions to install the environment never worked” is much more clearly a problem of the instructions. Even if, as you said, there are subtleties.
I will maintain that the only way the install process is actually the most difficult part for the student is if they are already a competent programmer. Which seems unlikely for a class like this.
OK, sure the concepts might be harder than setting up an environment. But setting things up is, by experience, a very real, very annoying and time-consuming blocker. We have students come in with tablets and it "just works"!
Yes for me (although difficulty varies depending on what you're trying to install). I would have started programming 2 years earlier than I actually did if my first attempt to install tools to run a programming language had worked.
You have to precisely follow a sequence of instructions without the experience to understand their purpose, or any idea of how to fix things if you make a mistake.
Web technology is an exception to this. People already have a web browser, and ignoring mobile devices, browsers come with a js REPL.
A friend let me host a site on his server, I learned to use FTP (with a firefox add-on he recommended) to copy up HTML files. Later he saw how much duplication I was doing and showed me the humble include statement while using PHP, and pointed towards a book, and I learned to program that way by uploading PHP scripts and running them by visiting their URL. It was some time later before I succeeded in installing a local WAMP stack, even later switching to Linux at home, but if that was a prerequisite I might have bounced. Web technology even just from the backend perspective was a huge enabler.
Still, I don't know if such things are the biggest obstacles, I remember the conceptual hurdle of the for loop syntax being pretty difficult to overcome. (I crashed my friend's server once with a very long loop echoing stuff each iteration that I might have tried opening in multiple tabs at once too.)
I've also seen such initial setup hurdles justified as filters: if you can't handle this, well, programming is full of such obstacles (bigger, smaller, or about the same size left unstated), so maybe it's for the best you just give up now since you probably won't make it. I generally don't like that excuse, and appreciate that getting into programming has been made so easy, but at the same time when a lot of effort has been made into making something so easy (even if not quite as easy as it could be, or as easy as something else) and people still bounce off their first setup difficulty, I sympathize with those who think good riddance, especially if the person isn't an absolute beginner. The horse and water adage always applies.
Hey, this is super interesting! We have been working on a quite similar system over the past few years at Université de Montréal. We develop and use codeBoot (https://codeboot.org) to teach introductory programming courses there. We also wrote an executable book for teaching a Cegep course (think last year of high school in the US). You can find it here (https://420-sn1.codeboot.org/) but mind you, the English version is not completed past chapter 1. The book was written in French.
Our tech stack is different but the choices we made are quite similar. Multi-tiered platform, markdown for authoring, executable exercises, teacher platform to produce, give, receive and grade homework/exams, etc. A distinguishing characteristic is that codeBoot's Python interpreter (pyinterp) allows single-stepping through the code. That's quite useful for teaching and studying.
We have a few exciting features coming up and we're working on a proper landing page and clean English translation for the book. If anybody is interested to learn more, reply here or contact me (email in my profile). I'd love to connect with educators, students or hackers alike!
I have used Jupyter notebooks with a Docker deployment in my prior courses for OCaml and Prolog, with support for auto grading (using nbgrader). Jupyter notebooks aren’t great for version control. Otherwise, it worked pretty well across multiple iterations of the course with new professors coming in and independently being able to use the infra.
Are these first-year undergrad courses? We can't assume students know anything about Docker or can even install packages on their systems. Some of them really have no idea at all, so pointing them to codeBoot saves a lot of time. Docker would definitely work for more experienced students though!
BTW, here's another quite nice feature of codeBoot: easy sharing! The following link will bring you to a suspended execution of 'print("hello, world!")' that you can then single-step.
> So the later modules embed a full 32-bit Alpine Linux machine that boots inside the browser tab, using the v86 x86-to-wasm emulator... You are running OCaml bytecode inside a Linux guest inside an x86 machine emulated in WebAssembly, several layers of emulation deep
Wow, this is wild!
> The thing I would love to reach is booting a compiled unikernel directly in wasm via WASI, with no Linux host underneath at all. That would make the last module as live as the rest.
Couldn't the Mirage unikernel thingy be used to compile a unikernel with all of the needed OCaml libs + i/o support? Thus negating the need for having to boot Linux inside of a browser tab? Couldn't that be done in all of the places they're booting Linux in a tab?
I need a Linux VM to illustrate a couple of things in the last few lectures. Showing C undefined behaviour, memory safety issues and how that becomes security issues, compiling OCaml program to show test coverage, and being able to build unikernels. So can’t completely do away with Linux VMs.
For Unikernels, currently v86 is 32-bit only and OCaml 5 has dropped support for native 32-bit backends. In order to boot 64-bit unikernels, I’d need qemu. All of this could be done, but (a) this is likely to be quite slow (and the current emulation already is) and (b) the learning objectives are probably not improved a lot with the additional infrastructure. Hence, dropped it.
We don't even have the capability to build a _32-bit_ Unikernel now! That said, we _can_ boot 64-bit MirageOS unikernels on baremetal platforms. We use this capability in FIDES, which boots MirageOS unikernels on a bare-metal, security-enhanced, soft-core RISC-V processor: https://kcsrk.info/papers/fides_asiaccs_2026.pdf.
OCaml 4.x does support 32-bit native compilation, and I don't think it should be too hard to be able to boot them in the browser using v86.
> The single biggest obstacle a beginner hits with any language is not the conceptual understanding. It is the install.
Is that _really_ the case? I find it very unlikely (not just in an OCaml context).
I remember this being true for me, a long, long time ago. There was something like a four year gap between me being able to munge linked lists in TiBasic and me being able to reliably install java and compile System.out.println(“hello world”)
Yes. The reason I ended up being a python dev is that way back in the day there was a free, easy installer that ran on my machine, including a functional if basic IDE with syntax highlighting. This was Python 1.5 on a Mac Classic. Even getting a C compiler would have been a major lift, this was in the modem days so downloading was always an adventure.
Yes, definitely the case. Just imagine a class with 100 students, each with a system that has its own quirks (OS, browser, and a mix of versions, etc). We built codeBoot (https://codeboot.org) specifically for this reason!
In my experience you can just tell AI to install it and it will figure out all of those quirks on its own.
We started this project before LLMs were popularized :) And surprisingly enough, experience says a lot of students would get stuck anyway.
I hate to second the grandparent, but perhaps the install process is the most difficult part for the instructor because it is at a stage where the instructor feels 90% responsible for the outcomes.
A criticism like “I didn’t understand recursive functions” is a student problem. A criticism like “the instructions to install the environment never worked” is much more clearly a problem of the instructions. Even if, as you said, there are subtleties.
I will maintain that the only way the install process is actually the most difficult part for the student is if they are already a competent programmer. Which seems unlikely for a class like this.
OK, sure the concepts might be harder than setting up an environment. But setting things up is, by experience, a very real, very annoying and time-consuming blocker. We have students come in with tablets and it "just works"!
Yes for me (although difficulty varies depending on what you're trying to install). I would have started programming 2 years earlier than I actually did if my first attempt to install tools to run a programming language had worked.
You have to precisely follow a sequence of instructions without the experience to understand their purpose, or any idea of how to fix things if you make a mistake.
Web technology is an exception to this. People already have a web browser, and ignoring mobile devices, browsers come with a js REPL.
A friend let me host a site on his server, I learned to use FTP (with a firefox add-on he recommended) to copy up HTML files. Later he saw how much duplication I was doing and showed me the humble include statement while using PHP, and pointed towards a book, and I learned to program that way by uploading PHP scripts and running them by visiting their URL. It was some time later before I succeeded in installing a local WAMP stack, even later switching to Linux at home, but if that was a prerequisite I might have bounced. Web technology even just from the backend perspective was a huge enabler.
Still, I don't know if such things are the biggest obstacles, I remember the conceptual hurdle of the for loop syntax being pretty difficult to overcome. (I crashed my friend's server once with a very long loop echoing stuff each iteration that I might have tried opening in multiple tabs at once too.)
I've also seen such initial setup hurdles justified as filters: if you can't handle this, well, programming is full of such obstacles (bigger, smaller, or about the same size left unstated), so maybe it's for the best you just give up now since you probably won't make it. I generally don't like that excuse, and appreciate that getting into programming has been made so easy, but at the same time when a lot of effort has been made into making something so easy (even if not quite as easy as it could be, or as easy as something else) and people still bounce off their first setup difficulty, I sympathize with those who think good riddance, especially if the person isn't an absolute beginner. The horse and water adage always applies.
You don't get to hit other obstacles if you don't have the ability to run the code and play with it.
Hey, this is super interesting! We have been working on a quite similar system over the past few years at Université de Montréal. We develop and use codeBoot (https://codeboot.org) to teach introductory programming courses there. We also wrote an executable book for teaching a Cegep course (think last year of high school in the US). You can find it here (https://420-sn1.codeboot.org/) but mind you, the English version is not completed past chapter 1. The book was written in French.
Our tech stack is different but the choices we made are quite similar. Multi-tiered platform, markdown for authoring, executable exercises, teacher platform to produce, give, receive and grade homework/exams, etc. A distinguishing characteristic is that codeBoot's Python interpreter (pyinterp) allows single-stepping through the code. That's quite useful for teaching and studying.
We have a few exciting features coming up and we're working on a proper landing page and clean English translation for the book. If anybody is interested to learn more, reply here or contact me (email in my profile). I'd love to connect with educators, students or hackers alike!
Super interesting. Thanks for sharing.
I have used Jupyter notebooks with a Docker deployment in my prior courses for OCaml and Prolog, with support for auto grading (using nbgrader). Jupyter notebooks aren’t great for version control. Otherwise, it worked pretty well across multiple iterations of the course with new professors coming in and independently being able to use the infra.
Are these first-year undergrad courses? We can't assume students know anything about Docker or can even install packages on their systems. Some of them really have no idea at all, so pointing them to codeBoot saves a lot of time. Docker would definitely work for more experienced students though!
BTW, here's another quite nice feature of codeBoot: easy sharing! The following link will bring you to a suspended execution of 'print("hello, world!")' that you can then single-step.
https://app.codeboot.org/6.0.0/?init=.faGVsbG9fd29ybGQucHk=~...
Now I'm very curious about integrating OCaml too :)
> So the later modules embed a full 32-bit Alpine Linux machine that boots inside the browser tab, using the v86 x86-to-wasm emulator... You are running OCaml bytecode inside a Linux guest inside an x86 machine emulated in WebAssembly, several layers of emulation deep
Wow, this is wild!
> The thing I would love to reach is booting a compiled unikernel directly in wasm via WASI, with no Linux host underneath at all. That would make the last module as live as the rest.
Couldn't the Mirage unikernel thingy be used to compile a unikernel with all of the needed OCaml libs + i/o support? Thus negating the need for having to boot Linux inside of a browser tab? Couldn't that be done in all of the places they're booting Linux in a tab?
Author of the post here.
I need a Linux VM to illustrate a couple of things in the last few lectures. Showing C undefined behaviour, memory safety issues and how that becomes security issues, compiling OCaml program to show test coverage, and being able to build unikernels. So can’t completely do away with Linux VMs.
For Unikernels, currently v86 is 32-bit only and OCaml 5 has dropped support for native 32-bit backends. In order to boot 64-bit unikernels, I’d need qemu. All of this could be done, but (a) this is likely to be quite slow (and the current emulation already is) and (b) the learning objectives are probably not improved a lot with the additional infrastructure. Hence, dropped it.
Oh, I see, so there's no way to boot a 32-bit Unikernel on "bare metal" then?
We don't even have the capability to build a _32-bit_ Unikernel now! That said, we _can_ boot 64-bit MirageOS unikernels on baremetal platforms. We use this capability in FIDES, which boots MirageOS unikernels on a bare-metal, security-enhanced, soft-core RISC-V processor: https://kcsrk.info/papers/fides_asiaccs_2026.pdf.
OCaml 4.x does support 32-bit native compilation, and I don't think it should be too hard to be able to boot them in the browser using v86.
Interesting next step for Literate Programming.