The titles question is not exactly as discussed in the body of your topic.
“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.)
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.
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.)
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.)
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.
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.
Screw around with something you like! That will keep the learner engaged and set a trend throughout for self serving exploration.
Comments
The titles question is not exactly as discussed in the body of your topic.
“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.)
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.
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.)
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.)
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.
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.
Screw around with something you like! That will keep the learner engaged and set a trend throughout for self serving exploration.