9 ms·
I feel that Python will be known in the future as the language that caused a generation to have a crippled sense of reasoning about how to design computer progr
by Blikkentrekker 6y ago
I feel that Python will be known in the future as the language that caused a generation to have a crippled sense of reasoning about how to design computer programs.
It's lack of a normal, standard scoping model alone teaches a very flawed reasoning about computer programs.
- goatlover 6y agoI'd vote for Javascript over Python.
- Blikkentrekker 6y agoJavascript is not so often used as a teaching language. There are many languages which hammer worse practices than either such as POSIX shell scripts, but they are seldom used as a teaching language. Python is in the unique space of having made horrible design decisions but somehow often used as a teaching language. One would assume that programmers are to understand such concepts as block scoping rules and the difference between lexical and dynamic variables. — how is Python to teach them that?
- rsj_hn 6y agoJavascript is too weird to be a teaching language. Lexical scoping, invisible and sometimes unintuitive conversion rules, challenging runtime environments, and asynchronous code are important concepts but I wouldn't put them into an intro to programming class. IMO the ideal programming track would be as follows: Intro to programming track: * Assembly --> to understand the basics of how computers work and learn simple procedural and abstraction rules. * C --> more procedural code, more abstractions, and higher order memory management * Java --> to learn interfaces, object oriented code, and an introduction to functional programming concepts like lambdas, pure functions, the value of immutable objects * {Racket/LISP or Favorite functional language} --> to gain intuition with more pure functional programming Then, I'd have separate tools track: * web dev * database * embedded dev * AI, etc. Then a separate theory track: * context free languages, regular expressions, compiler design * algorithms and data structures * some network theory and fault tolerance results Then I'd have a professional track: * tools: learn source control systems, IDEs, debuggers, profilers, bug management systems, different dev systems, using Jenkins or other CIT tools. * skills: learn about secure coding (best practices for writing auditable code with known failure modes), efficient coding (calculating big O for a given code, fixing performance bottlenecks), maintainable coding (best practices for decoupling code, writing testable code, writing unit tests) * theory: track where you learn advanced algorithm theory, design patterns, hopefully centered around case studies. With elective tracks for things like OS theory, networking, etc. Too many people leave college with lots of information about data structures and algorithms but don't know how to write a unit test, how to use an IDE, how to write unit tests, how to write secure, maintainable code.
- adrianN 6y agoI really don't think you should use C as a teaching language. There are way too many pitfalls, and using libraries is quite cumbersome.
- rsj_hn 6y agoI wouldn't program production code in C if I could avoid it. But sometimes you can't avoid it, and I wouldn't program production code in Pascal, either.
- adrianN 6y agoA programming language can both be the best fit for a concrete production problem and very unsuited as a teaching language.
- ajxs 6y agoAll of my academic computer science instruction was done in C. I was going to mention this in a response to one of the above comments regarding the pedagogical value of Python: I don't feel that taking onboard the concerns that come with programming in C (such as memory management) really made learning about computer science's fundamental algorithms and abstract data structures any easier. Many of the abstract data structures in question, such as trees and hash-maps, when practically implemented are dependent on an understanding of pointers that makes C an ideal pedagogical tool in at least one aspect. I don't think it's really practical for every scenario. I still think it's a great tool for teaching students about many aspects of how a modern computer, or operating-system functions. You definitely won't get far in gaining a holistic understanding of any modern operating-system without understanding C.
- deleted 6y ago[deleted]
- dunefox 6y ago> Java --> to learn interfaces, object oriented code, and an introduction to functional programming concepts like lambdas, pure functions, the value of immutable objects Jesus Christ, Java as an introduction to functional programming? I don't even know what to say.
- nerdponx 6y agoIt's lack of a normal, standard scoping model alone teaches a very flawed reasoning about computer programs. Scoping in class definitions is weird, yes. But is that your complaint? What's wrong with the scoping model in general?
- Blikkentrekker 6y agoIt's not merely that. That for-loops work by assignment rather than creating a new scope, or that if-conditions do not create a new scope for their arms is most unusual. Not only does it not teach programmers to properly reason about scope, but it results into subtle bugs that are easy to miss. Consider the following: list = [] for x in iterator: list.append(lambda y: some_code_that_closes_over(x)) This almost certainly does not behave as the programmer intended, for the for-loop does not create a new scope, so all iterations of the loop share the same scope, and thus every closure that closes over `x` handles the same `x`, which will have the value that `x` had at the last loop, thus effectively mutating the closure after appending it to the list, so that the list will only contain effectively identical closures. The proper way do it is by using the fact that functions do create a scope: list = [] def loop_function(x): list.append(lambda y: some_code_that_coses_over(x)) for x in iterator: loop_function(x) Certainly code that looks quite hackey to work around the lack of normal, expected block scoping.
- bb88 6y agoHow about not using lambdas which create accidental closures all over and use partial functions, instead? list.append(functools.partial(some_code_that_closes_over, x)) If you replace a lambda with a function definition in the for loop, it's easier to see the scoping issue is actually a closure. And that makes sense because lambda is shorthand for a function.
- Blikkentrekker 6y agoBecause the code that closes over can be arbitrarily complicated. I simply used code that only called a function with a single argument as a minimal example. Apart from that, your code technically does not do the same thing as it calls the inner function with two arguments, whereas mine simply discards the second argument.