Hacker News new | past | comments | ask | show | jobs | submit login
Programming Paradigms and Beyond [pdf] (brown.edu)
156 points by efm 9 months ago | hide | past | web | favorite | 33 comments



Related to the idea of "Notional Machines" (§4) I recently realised that what I'm calling "denotational strategies" can be vastly more efficient for learning than "operational strategies". For example, learning recursion via an operational semantics / abstract machine model can make recursion seem very complex. Maintaining the stack and tracing through the control flow is hard. Alternatively one can use structural recursion patterns (think proof by induction) in which case you don't have to think through the control flow. The correctness is guaranteed if the individual cases are correct.

Probably this statement isn't so understandable from the above description. It really needs a blog post of its own.


Maybe. I don't believe any claims about "easier" without reasonable experimental evidence. Even in the realm of operational strategies, there are huge differences; see: http://cs.brown.edu/~sk/Publications/Papers/Published/tfk-ev...

My guess is that "denotational strategies" (from what I can guess you mean) just move the cognitive load around in other places. That doesn't make them worse, but it depends on which kind of cognitive load the learner best copes with.


Agreed that the lack of evidence makes any of my claims not much more than hot air. It's something I'm interested in rectifying but I'm not sure how to do in our context (professional training and free intro to programming).


I think that's true for anyone who's comfortable with proofs by induction, but most people aren't until well past the point where they'd normally learn to program.


You don't need to understand proof by induction to use these techniques. It's more than I have the energy to explain in a comment here, but the chapter on "Structural Recursion" at http://www.creativescala.org/creative-scala.pdf shows some of my thinking (though it has evolved a bit since that written.)


Looks rather like an abbreviated version of the _How to Design Programs_ design recipe to me…


It sure is!


Sure would have been nice to give credit, then…

But more importantly, I can tell you that the design recipe isn't enough. That's why we set out to study the notional machine question (paper cited in another response). We most definitely need it too; what we're trying to figure out is what form of notional machine matches best.


You're absolutely right on giving credit. I've added this: https://github.com/underscoreio/creative-scala/commit/6ecaa4...

And thanks for mentioning the paper. I'll give it a read.


Just want to say I really enjoyed your chapter on “Visuals and Blocked Languages”.

My career got started programming Flash. Mostly because I loved the visuals and wanted to code it. Even though there is scratch, and other block based languages it seems text is still the king.

Text as you’ve identified is not the most new comer friendly.

I still think the holy grail of visual programming is still to come. Most of coding is describing abstract syntax trees. A nice visual tree/graph manipulation editor has yet to be invented. Being able to have a hybrid text and visual seems like a good place to be.

I’ve spent many years thinking and obsessed about this concept. Especially around the ideas of code completion/intellisense.

What are your opinions on how kids in a decade will code?


I think we'll find that there are a dozen different _reasons_ kids will need/want to code, and each of those will lead to dramatically different environments and ways. For instance, do kids need intellisense? Yes, if they're trying to accomplish a particular application goal, whereas maybe it's a bad idea if they're still learning the basics of programming.


Good read. I feel the title should be "Teaching Programming Paradigms and Beyond" since the text assumes familiarity with complete CS landscape and comments on success of several teaching methods.

I would recommend (also misleadingly titled) talk The Future of Programming by Bret Victor [1] which goes over some groundbreaking paradigms that have since become mostly forgotten.

[1] https://www.youtube.com/watch?v=8pTEmbeENF4


It's in a Handbook of Computing Education, so everything in the book is about "teaching". It would therefore have been especially odd to put that in the title.


Programming Paradigms and Beyond Shriram Krishnamurthi, Kathi Fisler The Cambridge Handbook of Computing Education Research, 2019

Programming Language education blind spots and opportunities for research. Recommended for anyone who teaches, learns or writes programming languages.


same Shriram that is involved in the Scheme-based Racket language, I would guess?


yes I think you're referring to https://www.pyret.org/


I think they're referring to the Racket programming language [0].

Shriram also authored "Programming Languages: Application and Interpretation" [1] and co-authored "How to Design Programs" [2] with Matthias Felleisen, Robby Findler, and Matthew Flatt. Both books use Racket as a base (well, PLAI uses PLAI/typed, which is built from Racket and utilized the DrRacket interpreter... close enough).

[0] https://racket-lang.org

[1] http://cs.brown.edu/~sk/Publications/Books/ProgLangs/

[2] http://www.htdp.org


Indeed, he's guilty of all of the above.


Thanks for all the good work! We used PLAI for Matthew's undergrad PL course at the U, and HtDP as supplementary material. Good stuff!


Thank you kindly!


That same one, yeah.


Thank you for the summary


I’m sad that such extensive research on paradigms and behavior doesn’t mention any of the very important and truly innovative work of Dr Harel such as “Statecharts: A visual formalism for complex systems” (1986) and “Behavioral programming” (2012)


Author here. I have great respect for Harel's statechart work, but it wasn't mentioned because it's not particularly germane to the topic at hand — the chapter is part of a computing education handbook. There are indeed other such chapters where one could imagine these references making a lot of sense.


I think DRAKON (https://en.wikipedia.org/wiki/DRAKON) worth mentioning in Visual Programming. It is very different from other visual programming systems and had clearness for complex algorithms that other visual systems lack (no line intersections, skews and other).


Too late to make changes, I'm afraid.


Thank you for post... Wondering if you can recommend any further reading? (Besides your forthcoming book :-) ) I am very interested in this topic, especially how one might make a easy-for-novices programming language. (I am sure there are many existing examples as well.)


Not MY forthcoming book (-: — "Handbook" means the chapters are written by many different people. The main chapter that deals with PLs is this one, though. What do you think it's lacking? (Did you actually read it? <-;)


Attended a talk about teaching programming to kids by the first author that was well attended by programmers and teachers. It was a very enriching experience. I'm definitely going to read this through.


Interesting paper. I’m missing Peter van Roy’s “Programming paradigms for dummies” in the list of references, though.

https://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf


Sometimes it helps to read the text, not just the references.


Is there a html version of this? The font size is too small for my eyes.


So after a bit of digging I found this free iOS app “Foxit reader”. It has a “re-flow” mode that allows making font sizes larger, responsive widths, and reading pdfs on a phone much more accessible.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: