joshmhanson
commented
5 years ago Thanks for posting all your thoughts! You were thorough, so I will be thorough too.
The code is ugly and hard to read. There are parentheses everywhere, both ) and ] but, surprisingly, no } (yet)
Yeah, S-expressions are a low-level syntax. You see them in the intermediate languages of many compilers, in WebAssembly, and commonly as a data serialization format. If we could have the exact same course that used a higher level syntax I would pick it in a heartbeat. I know one of the HtDP authors is working on one such language and that's likely where we're headed whenever there's more material available for us to use.
One advantage, however, of this lower-level syntax is how close it is to lambda calculus syntax, which (in my planned changes) students would be learning about soon after the course finishes. I think the advantages outweigh the disadvantages.
All of that said, I adopted a style for S-exp based languages (involving lots of newlines with vertically aligned columns) that I ended up preferring over everything else — even other languages.
The instructors insist on using naming conventions that, should they pass through my pull requests, I would reject outright. In few worlds outside of embedded are variables in functions now just one letter, so why can't we have (define (name-cat name) ...) instead of (define (name-cat n) ...)? Why name a constant (define P1 0) when you could name it (define START 0).
I agree with this; I ended up renaming some of the provided variables to make them easier to remember.
- There is an overreliance on course design schemas that can only be found in the course, that are overly complicated, and that would be difficult for a beginner to learn. I shouldn't have to return to a design pattern five times when designing a "world" - once for the world, three more times for templates... it's just repetitive and lacks value
- Over-reliance on copy-pasting. In an almost flagrant disregard of DRY (do not repeat yourself) principles, the instructors have us copy-pasting templates all over the place, even when they add little to no value and make the solution more complex.
- Over-reliance on function calls. Why, to make a list, must I call (cons 1 (cons 2 (cons 3 (cons 4 empty)))) instead of just (make-list 1 2 3 4) or similar?
I grouped these together because these are all really just the beginner-oriented pedagogical approach at work.
Beginners need to see the same patterns over and over again to ingrain them into their minds, so copy-pasting templates is directly beneficial. It's no different from a math teacher recommending that students copy down the formula for each new problem that they will use it to solve.
DRY (i.e. abstraction) comes later, when you know the patterns by heart, at which point you can use functions that abstract over those patterns. BSL deliberately doesn't include these, but ISL and ASL (used later in the course) provide many such abstractions, such as list-literal syntax (list 1 2 3 4). See the language progression here: https://docs.racket-lang.org/htdp-langs/beginner.html
No variables, only constants. This makes programs far more bracket-heavy than they need to be, and mean that simple tests and function definitions are dragged out over multiple lines
Not quite sure what you mean, are you talking about mutable data? If so see my next section.
No objects. You define structs, but these are essentially read-only collections of data. They are completely immutable. A function that needs to take a Cat and return a Cat must make an entirely new Cat. In object-orientated languages, however, the student would be able to simply call cat.setXPosition(cat.x + SPEED) and have done, compare with (make-cat (+ (cat-x cat) speed) (cat-y cat) (cat-age cat))
What you're describing isn't a difference between records/structs and objects, but a difference between records with and without mutable fields.
You mention "simply call cat.setX...`" but this is far from simple. Introducing mutation means completely re-designing the teaching material around a different and more complex model of computation. The substitution model is used here because it is the simplest starting point (they also use it in the beginning of SICP). It's the same model students would have been accustomed to in high school math. However, this model breaks in the presence of mutable data.
Plus, immutability is actually quite normal nowadays due to how mutation doesn't scale easily to large or complex systems. In React(+Redux) for instance, you are treating data as mostly immutable, with functional reducers for handling state and components as pure functions of the state. The React(+Redux) engine then handles the mutation by diffing the new structures against the old.
As an aside, objects occupy a layer of complexity above records/structs. Records are just regular product types. But an object is a kind of extensible record that somehow has access to self/this. How do you extend a record? You generally you need either subtyping or row polymorphism. While you could introduce objects in a beginner class I think it creates too much confusion and cognitive overload. Plus, almost every language tightly couples its object system with its class system, which is even more complexity.
Boundaries on student-defined data structures. We are essentially writing in a contract and then assuming that whoever calls it will obey this contract, but there is no code enforcing this behaviour. There is therefore nothing to stop the student from missing a case where they accidentally provide or return the wrong data type. (NB this is a problem with teaching untyped languages to beginners in general, and is not unique to student language))
All true. I wrote about the trade-offs of static vs. dynamic typing in a beginner course in #540. I find language-level dynamic typing to be silly in general — it is subsumed by static typing — but I ultimately felt that dynamic typing (or even no typing at all) is better suited for beginners.
But this is probably the only course where I feel comfortable with this, because if you pay careful attention, they are actually teaching type-driven programming with a simple algebraic type system. It's just that, for the sake of simplicity, nothing is verifying those types; they're going in the comments above each function. This provides the foundation for moving to static typing later.
If there is a way to make a zero-argument function I couldn't find it by trial and error (now that I've written this, someone is going to point out it's super easy), and the case isn't covered by the instructors. Therefore you simply can't implement generators without having them take arbitrary data that they then ignore - something else that would get a stern look in any code review.
I've never heard of a zero-argument function; if it has no arguments it would just immediately evaluate the right hand side to a value. To delay evaluation of the right hand side (i.e. to turn a value into something that can be called) you need an argument. An argument with no data is called the unit value and is written ().
Just as calling a function that takes unit is written some-fun () in most languages, in Lisp/Racket/BSL you just move the left parenthesis to the left of the function name, yielding (some-fun). You can make multiple calls to the same function this way, e.g. two calls would look like this: ((some-fun)).
But anyway, BSL is a deliberately limited language and perhaps doesn't support whatever you're doing. (Lambdas don't come until ISL.) I don't think any of this should be necessary in the course. I don't recall ever defining functions that took unit, and they would have taught the student everything needed to solve a certain problem. I do recall being challenged around generating something, but I eventually found a solution without doing anything fancy. I think I often experienced what you are: trying to solve something in the way I'm used to and struggling, because the problems are designed for people with a much more limited set of options and experience.
BSL - the language, despite being ugly and full of parentheses) is definitely not equipping the student to find gainful employment, nor the tools to move to e.g. javascript, java, python.
This is where OSSU differs significantly from coding bootcamps and other similar short-term programs. OSSU is meant for long-term study of several years, similar to an undergraduate degree. The goal is to provide the right level of difficulty at the right level of abstraction for students in a multi-year journey from novice to master. You don't have time for proper scaffolding and robust conceptual understanding in a short-term program.
Students will end up learning those messy industrial tools later in our curriculum, but learning simple and elegant models of computation first will give them a significant competitive advantage compared to their peers in the bootcamps. We can't compete with bootcamps on quantity, so we compete on quality.
xxylem
jestarray
anon88391
dropkickfish
log101
waciumawanjohi
I'll start with the pros, because there are some! It's clear the tutors worked very hard on the course and making it accessible.
Pros
Cons [NB some of this is very subjective, and I haven't yet finished the course. I had intended to so before I wrote this ticket, but after discussion with @hanjiexi I figured I may as well share now]
[Disclaimers: I am but one person, and the views expressed here are personal to me. I have not yet completed the course. I am not a beginner, although I am a beginner to computer science. I also sometimes exaggerate. I would not be exaggerating, however, in saying that I find the course incredibly frustrating] @gjergjk71 - anything to add?