To explain what I mean by the two approaches, I will cite the intro course sequences of two departments at three top universities.<p><i>1. Berkeley EECS</i><p>Course sequence are CS61A, CS61B and CS61C. 61A teaches programming in Python and Scheme. 61B teaches data structures and some basic algos in Java. 61C teaches C and assembly (RISC V)<p><i>2. Carnegie Mellon University</i><p>They start with a C like language called C0 and then they teach functional programming using Standard ML. Their algorithms class also using Standard ML to teach parallel algorithm design.<p><i>3 University of Waterloo</i><p>They start with teaching languages in Racket and then move on to C.<p><i>4 MIT</i><p>They do majority of the intro and algo classes in Python and then do C for the computer architecture class (Risc V). MIT doesn't have a functional programming requirement for their degree.<p>So the question is which method fares better on the average? Exceptional students will ofcourse adjust with whatever conditions and learn for them. To serve the average student better who have had no programming experience before, which approach is ideal?<p>P.S.: I am talking about lower level intro classes only.
The titles question is not exactly as discussed in the body of your topic.<p>“Bottom up vs top down” is not the same question as “low level vs high level” or “domain specific toy language vs hardest core versatile language” (sic.)<p>Outside of this academic consideration, top down refers to design and development methodology: plan everything first through specification vs work on minimal viable feature and iteratively add everything else.<p>The answer to the toy language concern, real programmers who did not come from debt riddled academia wonder “why bother?” Though “we” too know DSL solves some complexities through the focus of isolation (algorithmic grace vs crude language fixture.)<p>As for top down vs bottom up methodology (“waterfall vs agile”,
etc.) certain psychological strategies organize in advance really really well and nearly everyone else is better off implementing one specific isolated feature at a time. Most modern teams have a pragmatic mixture of both (I usually think configuration management, ACL, and plugin structure through first, and add usable features iteratively.)<p>And lastly this consideration you have added regarding exceptional vs mediocre students/devs. Counter to the trend of making things easier on the most common denominators, FORCING THE MEDIOCRE THROUGH RIGOR PRODUCES COMPETENCE! Not the other way. Fish or cut bait. Forcing uncomfortable rigor through the resistant underprepared mind makes greater minds. Don't feel sorry for those who underperform, the field is competitive for a reason and getting by on minimal requirements does not help anyone.<p>The best way to learn for anyone is screwing around. Formal structured learning however will produce wider competence. Only the leisure of academia bothers with things one will never use again, yet this guided tourism of ideals does provide versatile insights.<p>Screw around with something you like! That will keep the learner engaged and set a trend throughout for self serving exploration.