Paul Cantrell
I agree so hard with this thread from @quephird, and the @jrose post that inspired it.
Learning diverse and esoteric programming languages has unquestionably made me a better software developer and given me a leg up. And, no less important: it’s been •fun•! My own experience strongly bears out what these two are saying.
Paul Cantrell
@quephird @jrose
The Programming Languages course I teach is built around this idea of tinkering with the unfamiliar as a way of learning underlying patterns, and learning how to learn — as opposed to preparing students specifically for graduate research in programming languages (“this semester, we will build a subset of OCaml in OCaml”) or offering a utilitarian checklist of specific language paradigms and language features. (Both of those can be good courses, but they’re not the one I teach!)
2/
Paul Cantrell
I spend a lot of time giving my students advice that is various forms of “don’t artificially narrow yourself” and “learn to embrace the unfamiliar with curiosity instead of fear.”
And do they get this? From the p-lang course, from the curriculum in general? I think they actually •do• to a large extent. And I think two big reasons for it are (1) it’s a conscious learning goal across many classes through the curriculum, not just a single unit or an afterthought, and (2) we try to address this as •social-emotional learning•, not just technical knowledge accretion.
3/
Paul Cantrell
By “social-emotional learning,” I mean things like:
- Learning programming is hard, frustrating, daunting, makes you feel stupid; you need psychological tools for dealing with all that
- Programming carries all sorts of social baggage, is absurdly gendered and white in our culture, comes with all sorts of social pressures; you need to be mindful of all that or you’ll fall into the pit of it (whether you’re on the privileged or the marginalized side)
4/
Paul Cantrell
- Learning how to explain and share what you already know is at least as important as what you know
- Learning how to lift up the people around you instead of being an asshole pays •extraordinary• dividends — for your career, for the people around you, and for your own psychological health
…etc etc, I could go on.
/end
Paul Cantrell
@ddrake @quephird @jrose
Yes! “You cannot change the values of a variable” is a special day in the p-lang class: I show them some very, very, very basic Elm completely cold, and ask: “What can we ask about this language? What experiments will tell us what kind of language it is?” We do some tinkering with things they think they already know. We read the error messages carefully. It usually takes about 30-40 minutes for the class discussion to reach the point of “oh, wow, `=` doesn’t mean what we think it means in this language,” and it breaks their brain every time.
Dan Drake 🦆
@inthehands @quephird @jrose I too share a love of esoteria programming languages. I recall learning Haskell (arguably not so esoteric...) and I didn't really understand functional programming, or things like "you cannot change the values of a variable"...and figuring that out broke my brain, in the best way.
Put another way, it's good to learn such languages because, as they say: a mind, once stretched, never returns to its original dimensions!
Paul Cantrell
@thias @quephird @jrose
Yup, specific knowledge has a very short shelf life; underlying patterns, good meta-learning, and curiosity are all timeless.
🔏 Matthias Wiesmann
@inthehands @quephird @jrose Well, there is the aging factor also. Pascal was *the* high level language, then it was C, then it was Java. Rust is fashionable these days…
Marsh Gardiner 💡🐝🔧
@inthehands @quephird @jrose Obligatory Sapir-Whorf hypothesis reference incoming!
🔏 Matthias Wiesmann
@inthehands @quephird @jrose I think it's true and false at the same time, because the constraints and the hardware change. Linked-list made sense with relatively fast, but scarce memory, I don't see this pattern being useful ever again. Languages that can self-evaluation were so cool when I was at the Uni, blessed days before security.
There are also anti-patterns that are sadly timeless, like floating point numbers or languages that pretend they have a built-in type/class for human text…
Paul Cantrell
@thias @quephird @jrose
Linked lists are a great example, and I have a whole soapbox on what’s wrong and what’s right about teaching them that I don’t have time to type out right now. The very short of it:
- A linked list is rarely a good way to implement a List ADT on modern machines
- But doing that is a great exercise in implementing a contract and thinking about corner cases; useful learning if framed that way (“How can this break?” etc)
- But seriously, please please less of “What big O tradeoff makes using linked lists the right choice?”
- But but! linked / recursive data structures are •ubiquitous•, recognizing that pattern and working with it is essential
- Same for stacks, queues, lots of basic data structures curriculum: less about •choosing• the tool, more about •seeing• the tool
🔏 Matthias Wiesmann
@inthehands @quephird @jrose I think I went full circle about recursivity: costly option to enable in Fortran, everything is recursive in Lisp or Smalltalk (which I taught at EPFL) to dangerous thing that will probably blow in your face in production. If I had a time machine, I could probably have heated debates with myself and loose.
Paul Cantrell
To be clear, because I think it may have slipped by, when I say recursive data structures I mean that in contrast to recursive code: not necessarily a function calling itself, but a type T with a member that points to another T. Recursive code and recursive data structures do often go together, but it’s possible to work with a recursive data structure using non-recursive code.
🔏 Matthias Wiesmann
@inthehands @quephird @jrose indeed, but I would make similar reservations about recursive structures, as they imply pointers, memory layouts yada, yada. If you had told me in 2000 that the heap / stack would be some proeminent in newer languages like Swift I would have looked at you funny (Swift even has a keyword for recursive members). Mind you, this is no criticism, more me looking at the courses I gave and thinking “Mmh”.
Paul Cantrell
@thias @quephird @jrose
I mean, “heap allocations can be costly” has definitely been one of the longest-lived patterns of my programming life. There was that mystical window in the early 00s where it sort of seemed like infinite improvements to GC were going to make this a non-issue, but that was a short-lived mirage.
Paul Cantrell
@thias @quephird @jrose
OOP will give us limitless code reuse! XP will give us limitless flexibility! Infinite collaboration means there are no deep software problems! Business analysts will integrate software by dragging connections in a GUI between Java Beans!
🔏 Matthias Wiesmann
@inthehands @quephird @jrose yup, I taught in that mystical time window. Compilers were going to solve all optimisation problems, parallelism was dead, multithreading was the answer. Cooperative multitasking was clearly going rhe way of the dodo.
Alfred M. Szmidt
@thias "everything is recursive in Lisp or Smalltalk" -- it really isn't (I'd even argue that more often, that recursion is not idiomatic Lisp code). Nor is there any reason why recursion would "blow in your face" in production, Erlang uses plenty of (tail) recursion in production in the telco/fintech world.
🔏 Matthias Wiesmann
@amszmidt @inthehands @quephird @jrose recursion blew in my face in production, multiple times, it should have been optimised tail recursion, it should have been bounded, the stack should have been sufficient. Of course if the code had been in the right paradigm/language/universe there would have been no problem.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.