[HN Gopher] Programming Languages and Learning
___________________________________________________________________
Programming Languages and Learning
Author : mwcampbell
Score : 68 points
Date : 2022-03-14 16:07 UTC (6 hours ago)
(HTM) web link (quorumlanguage.com)
(TXT) w3m dump (quorumlanguage.com)
| askonomm wrote:
| > A number of experiments have been performed that show a
| positive impact of static type systems over dynamic type systems
|
| And here we have it folks, static typing is superior.
| dang wrote:
| Please don't post shallow comments like this, especially not on
| divisive topics like that one.
|
| https://news.ycombinator.com/newsguidelines.html
| rileyphone wrote:
| While I agree with this on principle, I feel this project is
| taking it in the wrong direction. Pretty much all of the
| languages in use today were designed without human factors in
| mind, especially the big, standardized ones that were actually
| based on some research. As it turned out, the most successful
| beginner languages, like Javascript and Python, are more dynamic
| and expressive - they were also designed, as far as I know, with
| no thought of existing research. The paucity of research around
| this, as mentioned in this article, should indicate how nebulous
| and hard to quantify the knowledge about this is. New efforts
| should be asking questions about why this is. The best way is to
| watch someone try to program and take notes of where they get
| hung up, as in [0].
|
| As for where I would point to regarding sensible language design,
| read http://worrydream.com/LearnableProgramming/ and the book
| recommended within, Mindstorms. I believe programming has the
| potential to be the emancipatory medium of thought in the coming
| century, but only if we can rethink what programming really is.
|
| [0]
| https://kilthub.cmu.edu/articles/Six_Learning_Barriers_in_En...
| erik_seaberg wrote:
| > As we push toward computer science for all, the design of our
| languages should be based increasingly on evidence.
|
| This is too broad a goal. Novices shouldn't be required to learn
| expert languages, and experts shouldn't be limited to using only
| novice-friendly languages. Because we who specialize will spend
| most of our careers as experts, it's crucial that we still have
| clear, concise, powerful languages available even though they
| require more investment that wouldn't pay off for everyone else.
| Qem wrote:
| I think the fundamental problem here is everybody must be a
| novice before they become a expert, and probably the only
| languages were the experts outnumber novices are the dead or
| dying ones. Most of time we are beginner-level at everything.
| If a language is too expert-focused, and hard to onboard people
| into, it has a hard time growing organically.
| Jensson wrote:
| Experts tend to outnumber the novices, since you are only a
| novice for a few years and then you are an expert for the
| rest of your career. People have all these strange notions in
| programming just because it is a growing field, but if you
| look around it isn't like novice teachers outnumber
| experiences ones, or novice doctors are all that common etc.
| Qem wrote:
| You must take into account attrition rate. Not every novice
| becomes a expert. Say in a given field, on average, each
| person spends 10% of their time as novice, and 90% as
| expert. If only one in ten novices actually grow into
| experts, in the overall population most man-hours are spent
| at beginner level. Novice teachers don't outnumber
| experiences ones, but students surely outnumber teachers,
| by a large margin. In a market that still didn't achieve
| steady state, like programming, some of the people that
| didn't made it through may end jumping ship to more
| beginner-friendly alternatives, that end with more people,
| more libraries, more learning resources, et cetera.
| Eventually the network effects will cause even the expert
| ponder over switching sides to get better libraries. Think
| how Python ate Perl lunch, despite the swiss-army chainsaw
| power of the later. Today there's probably much more Perl
| programmers than in the 90s, but yet we can't deny the
| language lost mindshare.
| [deleted]
| mcbuilder wrote:
| I've been teaching my 11 y.o. son programming with Julia and
| Project Euler. My personal opinion is that Julia is the best
| language to introduce to new programmers. First of all, it has
| very good "IDE" support in various editors with LSP (VS Code
| being a great newbie choice). It supports a nice mix of language
| features, mainly imperative constructs, but it also excels as a
| functional programming language.
|
| I was considering Haskell as a language, but unfortunately
| Haskell often feels like it gets in the way of your learning
| sometime. Want to teach for-loops for instance, well you gotta
| break out Monads.
|
| Python is a popular choice, but I think it's a horrible
| pedagogical language. I don't want to teach OO concepts, instead
| I rather have him think about the algorithm and basic computer
| science principles. The only reason I think people choose Python
| is that it's super easy to get started, but I think all that
| simplicity is just a wrapper around a fairly complex runtime.
| With Julia the abstractions are generic enough that they can stay
| as abstractions. With Python, I'd feel like I'm just teaching a
| package (i.e. numpy) and the concept of generic programming would
| just get ignored.
| Qem wrote:
| If you eventually reconsider the decision to not teach OO
| concepts, I recommend Pharo as a awesome language, including
| for teaching OOP as it was meant to be. It has firm roots on
| Smalltalk, very easy to install, with a superb IDE and proven
| track record on children education. There's a MOOC on
| https://mooc.pharo.org/ See also
| https://news.ycombinator.com/item?id=27368962 For a example of
| a nice educational project done with it, see
| https://news.ycombinator.com/item?id=30562009
| 3a2d29 wrote:
| "Python is a popular choice, but I think it's a horrible
| pedagogical language."
|
| Something like this occurred to me when I learned Javascript.
| Python is so easy initially, but its interesting how the CS
| principles of it are not so easy.
|
| I think this popular cause someone with a CS background can
| quickly get the ideas of variables and printing to terminal,
| but look at how javascript vs Python handle objects.
|
| Javascript it is just setting a variable to a bracket of
| values, like an array. Python you have to tackle concepts like
| what a class and self are.
|
| Not saying Python is better/worse than any other for learning,
| but I am certain its popularity for beginners is how easy you
| can go from 0 to something. Not how easy it is to learn CS and
| programming principles.
| sundarurfriend wrote:
| Thinking about it some, I agree. I'd have (and have in the
| past) disagreed about it being the best language for _self_
| -learning as a new programmer - it's decent, on par with most
| other languages, but not the _best_ language for that purpose.
| The error messages can be inscrutable (for now), the types can
| get complex and messy (though they 're are getting better,
| easier-to-read signatures over time), it might not have the
| library for what you have the impulse to build (which is an
| important motivator for new programmers - though this is again
| a "for now" problem).
|
| But with someone to guide you, it absolutely can be the best
| first language, because of the breadth of programming concepts
| it introduces you to. Python is a good first language if, say,
| you're in college and just want to get started with doing
| things in programming - where the focus is on programming as a
| tool to get the results you want, and less so on the shape of
| the tool itself and how it shapes your mind. At younger ages,
| when there's time to lay a firm foundation and explore the tool
| itself, Julia makes for a much better foundation, being a
| better jumping-off point for many more diverse paths in the
| programming landscape.
| pthread_t wrote:
| > I don't want to teach OO concepts
|
| Does python really force this? I can see this being the with
| java -- a language often used in intro to CS courses.
| Jtsummers wrote:
| It doesn't. Python is actually a pretty good language for
| teaching algorithms, you never need to type "defclass" unless
| you want to. You do, kind of, have to use methods, but that's
| not a huge burden for a learner compared to the other things
| they have to learn. Also, if you're using a language-agnostic
| algorithms textbook (in a course, solo, or as a mentor) then
| Python is _very_ close to the pseudocode in most of those.
| anonporridge wrote:
| Python's closeness to pseudocode is one reason why it makes
| a fantastic choice for whiteboard coding interviews.
|
| I've personally had interviewers frustrated that I solve
| problems correctly so much faster than they expected. And
| not only correctly, but to the point where I could type
| what I wrote verbatim into the interpreter and prove that
| it actually works.
| bitwize wrote:
| Python is pretty much zoomer BASIC. I think it's a pretty
| good choice for those early painful bits of learning how
| to program, when you have to understand that a program is
| sequenced instructions to a computer, that the effect of
| an instruction depends on what happened before, etc. You
| can write a complete Python program without defining a
| class or invoking an object. These concepts can be
| introduced after the learner has the basics down pat.
| RodgerTheGreat wrote:
| Python the language itself, _perhaps_ not. The standard
| library, on the other hand, is a random hodgepodge of
| imperative, OOP, and functional styles, and the greater
| library ecosystem is no different.
| dboreham wrote:
| Is this a machine-generated page? I ask because it begins by
| talking about teaching programming to K-12 students. Then the
| second section in the body has title : "Software Transactional
| Memory (STM)".
| mwcampbell wrote:
| Definitely not machine-generated; I know the professor who
| wrote it. I think he was just covering language semantics
| before syntax.
___________________________________________________________________
(page generated 2022-03-14 23:01 UTC)