[roosterdawn]

All I see is a list of complaints about warts that Python has, and no real foundational reasons for or against using Python, such as the ecosystem, long term cost of ownership, ease of iteration, or ability to manage a codebase at scale. I think this blog post is not named accurately.

[eythian]

None of ecosystem, long term ownership, iteration, or codebases at scale are relevant to a foundational language (i.e. one that is being taught in order to teach the concepts of programming.)

A simple, clear syntax that comes, as much as is reasonable, secondary to whatever the concept being taught is is most important to me.

[roosterdawn]

> None of ecosystem, long term ownership, iteration, or codebases at scale are relevant to a foundational language (i.e. one that is being taught in order to teach the concepts of programming.)

I cannot agree with this. Embedded in this argument is the idea that syntactic specialization towards pedagogy is a worthwhile goal rather than ramping up a pupil towards where they'd be able to function independently as a software engineer by giving them a solid theoretical and applied foundation.

Part of being an engineer is learning how the quirks of the language evolved, the history of how it got to be that way, and what it means in terms of the long term evolution of the language and ecosystem as collectively reasoned through by the eyes of skilled practitioners. You get to see the decision making process of language design, and how the plan became a prototype became a battle hardened tool that can adequately work in a variety of real situations, well enough to gain a significant plurality (or mindshare) for a specific real world use case.

Just because studying Latin is useful for understanding English at a deeper level doesn't mean it's a good idea to learn Latin before learning english. It doesn't change the fact that a) immersion is the best way to build fluency, and b) fluency is the goal, does it? What makes programming languages any different?

[eythian]

So, I'm thinking from an introduction in an academic setting, some people (in my limited teaching experience, most people) aren't planning to go on to become software developers - they just need some background for what they're actually studying. You're not being a strictly vocational trainer, and you're starting people from "this is a variable, this is an if" and getting them to "this is a sorting algorithm, this is a tree." I.e. the foundations of programming.

At this stage, keeping people away from excessive boilerplate ("public static void main" is confusing), libraries apart from something that makes the teaching process easier, version control, and so on all contributes to teaching the programming process, which is hard enough as it is.

By all means, introduce those things when they get to software engineering, but by that stage the need for a foundational language has passed and people should be able to pick and learn whatever languages or other tools suit their specific needs.

> Just because studying Latin is useful for understanding English at a deeper level doesn't mean it's a good idea to learn Latin before learning english.

The flaw with this analogy is that it's not about "at a deeper level", it's more like learning simple English and not getting bogged down with subjunctives and constructions like "I had had a hotdog", as those can come later and aren't important right now.

[anthonygd]

In an educational setting you need to be clear whether you're talking about Computer _Science_, _Engineering_ or trade. There is value in all 3 approaches but don't make the mistake of thinking they're all the same.

Using the term "foundational language" makes me think Science, which has very little overlap with the trade approach. An engineering approach stands somewhere in between, but still has very different objectives than science.

[roosterdawn]

> There is value in all 3 approaches but don't make the mistake of thinking they're all the same.

I respectfully disagree, and would gladly take the counterpoint to that argument. You will find the intersection of the three inside of many real world engineering problems. On the contrary, I am skeptical of the idea that applications in any one particular area don't have corresponding mirror images in the other two. Based on achievements in all three (research, engineering and trade), it is my opinionated belief that a focus on the intersection is where you create compounding value. I would love to hear a compelling counter-argument.