10 ms·

Haskell and OCaml are also 90's languages. The rise of Python at the expense of safer, typed, faster, more principled languages makes me very sad for the state

by willtim 10y ago

Haskell and OCaml are also 90's languages. The rise of Python at the expense of safer, typed, faster, more principled languages makes me very sad for the state of our industry. I do not even believe it is the best choice for teaching programming to children. It heavily mixes and conflates higher-level ideas like lambdas and list comprehensions with imperative programming and mutation (the assignment syntax "x=x+1" must be especially confusing to high-school kids). It also throws in "object-oriented programming" constructs into the mix too.

ue_ 10y ago
>x=x+1 I've always heard this explained along the lines of "adds 1 to whatever x is, then puts that value into x, so x is one more than it was before".
- tim333 10y ago
  I first came across that as a school kid (in BASIC) and didn't find it confusing at all. I still find functional computing confusing - I mean to do something for the numbers 1 to 100 instead of for x = 1 to 100 you have to do some weird tail call recursion which if you are lucky the compiler then converts back to for x = 1 to 100 because that's how processors work efficiently.
  - willtim 10y ago
    I learnt BBC Basic before my high-school algebra and was certainly confused by the different meanings. Don't concern yourself with tail recursion if you are still learning FP, it's just an optimisation, nothing to do with semantics. Python doesn't have it and few people care. What do you want to do with the numbers 1..100? A for loop doesn't give me any hints, which is part of its problem.
  - lmm 10y ago
    Don't bother thinking about what the processor is doing. Just trust it to figure it out. Tell it what to do (which shouldn't involve "weird tail recursion" - rather you probably want to use "map" or similar), and let the runtime/processor do it for you. If and when it turns out to actually be too slowly, and you profile it and can't immediately see why, then you're allowed to worry about that kind of thing. Not before.
- willtim 10y ago
  The syntax is trying to look friendly and familiar, but ultimately it's an abuse of a standard mathematical notation that has meant something else for hundreds of years. The original meaning, an equality relation, is still being taught to high-school children today, typically before python is forced upon them.
  - hota_mazi 10y ago
    You're over dramatizing. The human brain is very good at interpreting things in context and it's really trivial for even middle school kids to understand that `=` in math is different from `=` in programming. Do you want an example of something that beginner programmers struggle with? Pointers.
    - augustk 10y ago
      But you still need a symbol for the equality operator, so not choosing "=" for that seems rather absurd. It's comparable to making the choice to use + for string concatenation and ++ for (numeric) addition.
  - zephyrfalcon 10y ago
    Good god. If anything is "forced" upon high-school kids, it's algebra. (Maybe ask the average high schooler and see what they have to say about it.) I haven't heard of any schools that make Python mandatory though; where are these located?
pjmlp 10y ago
They suffered from the VM rise of Java and CLR, finally we are circling back to AOT tooling and FP concepts are becoming mainstream so advocating them is easier nowadays. Also these things take time, even C++, I saw recent presentations from BMW[1] and Sony[1] that only now in 2017 they are transitioning from C to C++11 (not C++14) for some specific embedded development. [1] - https://fosdem.org/2017/schedule/event/succes_failure_autonomous_driving/ https://fosdem.org/2017/schedule/event/succes_failure_autono... [2] - http://sched.co/9OOs http://sched.co/9OOs
sevensor 10y ago
> "x=x+1" must be especially confusing to high-school kids I like immutability as much as the next programmer, probably more. But the idea that changing the value of a variable in memory is confusing to high-school kids gets repeated way too often with way too little evidence. X isn't the x from algebra, x is your bank account balance. That it changes at payday is not a hard analogy to understand. I have yet to meet the high-school kid who thinks this says that 1=0. Now, like the rest of us, high-school kids can get tripped up by assignment and its consequences. Functional programming offers us great tools to deal with that. But the 1=0 argument is not credible to your average procedural programmer who's been doing assignment since the age of fourteen, and is in full command of basic algebra. A much better argument would be that Haskell lets you take advantage of algebra as an analogy, and Python doesn't unless you're unusually disciplined. Edit: removed a word for grammar.
- willtim 10y ago
  I never said mutating a variable is confusing. I said repurposing the equality operator is potentially confusing, especially for children. Pascal used ":=" to mean assignment, long before Python existed.
  - dragonwriter 10y ago
    BASIC used "=" for both assignment and equality tests long before Pascal existed and was more popular for teaching the youngest students even when Pascal was available, so I find the idea that the use of "=" for assignment is some kind of barrier that high school kids (or younger, even) are going to have a lot of problems with just as implausible as the idea that imperative mutation is such a problem.
    - willtim 10y ago
      It was before my time, but ALGOL used ":=" long before BASIC existed. The point is that academics have repeatedly not used "=" for assignment for successive new languages over many decades. Clearly they care, even if you do not.
dragonwriter 10y ago
> the assignment syntax "x=x+1" must be especially confusing to high-school kids It wasn't at all confusing to me as an elementary school kid in BASIC, so I doubt it. The variables = named boxes metaphor was a fairly standard part of the pedagogy. Immutability is great, sure, but let's not pretend that imperative sequences of instructions aren't basic and common things humans have to deal with and quite natural.
- willtim 10y ago
  I wasn't arguing against imperative semantics. I was trying to point out that Python abuses notation and conflates paradigms; and so perhaps may not be the best teaching language. Both Haskell and OCaml make very good imperative languages, but are much more explicit about what's going on. Assignments are clear to see (using "<-") and one must explicitly declare a mutable reference, rather than the Python default of everything is mutable.
hota_mazi 10y ago
> The rise of Python at the expense of safer, typed, faster, more principled languages makes me very sad for the state of our industry There is no rise. Not any more. At best, it's a plateau, and in my opinion, all dynamically typed languages except Javascript are on a straight decline curve, slowly being replaced by statically typed languages. I noticed that a lot of people who enjoy Go come from Ruby or Python. Go's type system is clearly antiquated and weak, but it's a straight upgrade from a dynamically typed language, which is why it's finding an audience with the Python/Ruby crowd.
- willtim 10y ago
  I hope you are right. It's spreading all over the industry I work in and the schools want to teach it to my kids.
- zephyrfalcon 10y ago
  """There is no rise. Not any more. At best, it's a plateau, and in my opinion, all dynamically typed languages except Javascript are on a straight decline curve, slowly being replaced by statically typed languages.""" This sounds like wishful thinking. (Your wish, apparently... certainly not mine. :-) I have seen no evidence that Python is on the way out. If I look at the languages asked for in HN's "Who's Hiring" thread, Python is #1. Even so, there are dynamically typed functional languages, like Clojure and Elixir, that are definitely on the way up.
  - hota_mazi 10y ago
    Sure, it's just my opinion. Your post history seems to suggest you are heavily involved in Python. I'm not. I don't write Python, I don't write Go, I have no dog in this race. I'm just observing trends, like I've been doing for the 30+ years I've been in this industry. And these past few years, I've observed enough hints that people are moving from Python and Ruby in droves. And also that no large projects would be started in either of these languages today. Python/Ruby are going to stay around forever, no doubt, but much more as a glue/infrastructure language to write scripts here and there (and TensorFlow might help Python stay relevant for a bit longer too).
jerf 10y ago
"the assignment syntax "x=x+1" must be especially confusing to high-school kids" Many other comments already discussing this, but I have to add this. I don't think that has ever confused more than a handful of high school students because you are almost certainly bringing an understanding of "=" that you acquired at a much higher level of math. For a lot of students, "=" isn't even what you would consider the "equality" operator... it's the simplify operator. That is: 2 + 2 = ____ has, for them, One and Precisely One answer. (You know this to be true, because your brain has already supplied that answer, and you already know that "3 + 1" is not an acceptable thing to put in that blank, even if a later understanding swoops in to say "Well, yes it is..." You still first knew the One and Precisely One answer.) So it's not the "equality" operator for them. (I will give this kudo to Common Core, it tries much harder to avoid grinding the "simplify" definition into children's heads than older curricula.) I don't think they get much collision with the "simplify" operator while programming because the contexts are too different. I'd also submit that the conception of mathematical statements existing timelessly in some abstract math space would be foreign to them, and it is not hard for them to develop the "intuition" that "x = x + 1" is simply a statement that "after" this statement x will be one greater. The only people who have trouble with "x = x + 1" are mathematicians trained to a very particular formal level, where they understand the idea of equality more deeply than a high school student but still haven't noticed that operators and formalisms change between branches of math all the time and insisting on your precise definition of an operator hasn't yet inhibited you from understanding the branches of math that redefine it themselves. Granted, no branch of math uses a definition that looks like the imperative programming version (even mathematical formalizations of imperative programming tend not to use = for assignment from what I can recall), but it's still just one more definition in a constellation of definitions, not the uniquely odd one out. You're going to have a hard time with homotopy type theory if you insist on your conventional = definition, for instance.
- willtim 10y ago
  In the UK, algebra is first introduced using the equality operator, often with pictures of weight scales and weights, which students are asked to balance. Then they are introduced to a concise notation for this, e.g.: 1 + x = 3 Simplification comes later; and it often involves moving terms from one side of the relation to the other, which isn't possible with an assignment operator. I have no doubt that beginners soon learn any different meaning of "=" over time, but why reuse the operator in the first place? Is it really making it "easier" for the beginner? At least with BASIC the context switch was easier as it was strictly imperative. Python tries to mix in more declarative concepts. The misuse of the equality operator is only one minor detail, but if people care so little about such details, how can they be trusted to look after the more important ones?
crdoconnor 10y ago
>The rise of Python at the expense of safer, typed, faster, more principled languages makes me very sad for the state of our industry. Stronger type systems don't come for free. They come at the expense of slower prototyping.
- willtim 10y ago
  I respectively disagree. I use types for rapid prototyping. Often I write out the type signatures first, type-check the high-level compositions and then fill in the implementations later.
zephyrfalcon 10y ago
You say that like it's a bad thing. Python is a multi-paradigm language, allowing you to pick (or create) the idiom that is best suited for solving the problem at hand. It is not a straitjacket language that tells you how to think. The use of "=" for assignment is only confusing if you are already used to using for equations, and even then it's only confusing for a very short time, since it's obvious that the two (assignment vs equations) are completely different things. Python is hardly the first language to use it, by the way; I got started with BASIC on a Commodore 16 which used X=X+1, before I even knew about equations.
- willtim 10y ago
  In practice I do not see it being any more "multi-paradigm" than e.g. Haskell is. It just conflates the imperative and declarative subsets, meaning that a lambda is not really a lambda etc

by willtim 10y ago

ue_ 10y ago

>x=x+1 I've always heard this explained along the lines of "adds 1 to whatever x is, then puts that value into x, so x is one more than it was before".

tim333 10y ago
I first came across that as a school kid (in BASIC) and didn't find it confusing at all. I still find functional computing confusing - I mean to do something for the numbers 1 to 100 instead of for x = 1 to 100 you have to do some weird tail call recursion which if you are lucky the compiler then converts back to for x = 1 to 100 because that's how processors work efficiently.
- willtim 10y ago
  I learnt BBC Basic before my high-school algebra and was certainly confused by the different meanings. Don't concern yourself with tail recursion if you are still learning FP, it's just an optimisation, nothing to do with semantics. Python doesn't have it and few people care. What do you want to do with the numbers 1..100? A for loop doesn't give me any hints, which is part of its problem.
- lmm 10y ago
  Don't bother thinking about what the processor is doing. Just trust it to figure it out. Tell it what to do (which shouldn't involve "weird tail recursion" - rather you probably want to use "map" or similar), and let the runtime/processor do it for you. If and when it turns out to actually be too slowly, and you profile it and can't immediately see why, then you're allowed to worry about that kind of thing. Not before.
willtim 10y ago
The syntax is trying to look friendly and familiar, but ultimately it's an abuse of a standard mathematical notation that has meant something else for hundreds of years. The original meaning, an equality relation, is still being taught to high-school children today, typically before python is forced upon them.
- hota_mazi 10y ago
  You're over dramatizing. The human brain is very good at interpreting things in context and it's really trivial for even middle school kids to understand that `=` in math is different from `=` in programming. Do you want an example of something that beginner programmers struggle with? Pointers.
  - augustk 10y ago
    But you still need a symbol for the equality operator, so not choosing "=" for that seems rather absurd. It's comparable to making the choice to use + for string concatenation and ++ for (numeric) addition.
- zephyrfalcon 10y ago
  Good god. If anything is "forced" upon high-school kids, it's algebra. (Maybe ask the average high schooler and see what they have to say about it.) I haven't heard of any schools that make Python mandatory though; where are these located?

pjmlp 10y ago

They suffered from the VM rise of Java and CLR, finally we are circling back to AOT tooling and FP concepts are becoming mainstream so advocating them is easier nowadays. Also these things take time, even C++, I saw recent presentations from BMW[1] and Sony[1] that only now in 2017 they are transitioning from C to C++11 (not C++14) for some specific embedded development. [1] - https://fosdem.org/2017/schedule/event/succes_failure_autonomous_driving/ https://fosdem.org/2017/schedule/event/succes_failure_autono... [2] - http://sched.co/9OOs http://sched.co/9OOs

sevensor 10y ago

> "x=x+1" must be especially confusing to high-school kids I like immutability as much as the next programmer, probably more. But the idea that changing the value of a variable in memory is confusing to high-school kids gets repeated way too often with way too little evidence. X isn't the x from algebra, x is your bank account balance. That it changes at payday is not a hard analogy to understand. I have yet to meet the high-school kid who thinks this says that 1=0. Now, like the rest of us, high-school kids can get tripped up by assignment and its consequences. Functional programming offers us great tools to deal with that. But the 1=0 argument is not credible to your average procedural programmer who's been doing assignment since the age of fourteen, and is in full command of basic algebra. A much better argument would be that Haskell lets you take advantage of algebra as an analogy, and Python doesn't unless you're unusually disciplined. Edit: removed a word for grammar.

willtim 10y ago
I never said mutating a variable is confusing. I said repurposing the equality operator is potentially confusing, especially for children. Pascal used ":=" to mean assignment, long before Python existed.
- dragonwriter 10y ago
  BASIC used "=" for both assignment and equality tests long before Pascal existed and was more popular for teaching the youngest students even when Pascal was available, so I find the idea that the use of "=" for assignment is some kind of barrier that high school kids (or younger, even) are going to have a lot of problems with just as implausible as the idea that imperative mutation is such a problem.
  - willtim 10y ago
    It was before my time, but ALGOL used ":=" long before BASIC existed. The point is that academics have repeatedly not used "=" for assignment for successive new languages over many decades. Clearly they care, even if you do not.

dragonwriter 10y ago

> the assignment syntax "x=x+1" must be especially confusing to high-school kids It wasn't at all confusing to me as an elementary school kid in BASIC, so I doubt it. The variables = named boxes metaphor was a fairly standard part of the pedagogy. Immutability is great, sure, but let's not pretend that imperative sequences of instructions aren't basic and common things humans have to deal with and quite natural.

willtim 10y ago
I wasn't arguing against imperative semantics. I was trying to point out that Python abuses notation and conflates paradigms; and so perhaps may not be the best teaching language. Both Haskell and OCaml make very good imperative languages, but are much more explicit about what's going on. Assignments are clear to see (using "<-") and one must explicitly declare a mutable reference, rather than the Python default of everything is mutable.

hota_mazi 10y ago

> The rise of Python at the expense of safer, typed, faster, more principled languages makes me very sad for the state of our industry There is no rise. Not any more. At best, it's a plateau, and in my opinion, all dynamically typed languages except Javascript are on a straight decline curve, slowly being replaced by statically typed languages. I noticed that a lot of people who enjoy Go come from Ruby or Python. Go's type system is clearly antiquated and weak, but it's a straight upgrade from a dynamically typed language, which is why it's finding an audience with the Python/Ruby crowd.

willtim 10y ago
I hope you are right. It's spreading all over the industry I work in and the schools want to teach it to my kids.
zephyrfalcon 10y ago
"""There is no rise. Not any more. At best, it's a plateau, and in my opinion, all dynamically typed languages except Javascript are on a straight decline curve, slowly being replaced by statically typed languages.""" This sounds like wishful thinking. (Your wish, apparently... certainly not mine. :-) I have seen no evidence that Python is on the way out. If I look at the languages asked for in HN's "Who's Hiring" thread, Python is #1. Even so, there are dynamically typed functional languages, like Clojure and Elixir, that are definitely on the way up.
- hota_mazi 10y ago
  Sure, it's just my opinion. Your post history seems to suggest you are heavily involved in Python. I'm not. I don't write Python, I don't write Go, I have no dog in this race. I'm just observing trends, like I've been doing for the 30+ years I've been in this industry. And these past few years, I've observed enough hints that people are moving from Python and Ruby in droves. And also that no large projects would be started in either of these languages today. Python/Ruby are going to stay around forever, no doubt, but much more as a glue/infrastructure language to write scripts here and there (and TensorFlow might help Python stay relevant for a bit longer too).

jerf 10y ago

"the assignment syntax "x=x+1" must be especially confusing to high-school kids" Many other comments already discussing this, but I have to add this. I don't think that has ever confused more than a handful of high school students because you are almost certainly bringing an understanding of "=" that you acquired at a much higher level of math. For a lot of students, "=" isn't even what you would consider the "equality" operator... it's the simplify operator. That is: 2 + 2 = ____ has, for them, One and Precisely One answer. (You know this to be true, because your brain has already supplied that answer, and you already know that "3 + 1" is not an acceptable thing to put in that blank, even if a later understanding swoops in to say "Well, yes it is..." You still first knew the One and Precisely One answer.) So it's not the "equality" operator for them. (I will give this kudo to Common Core, it tries much harder to avoid grinding the "simplify" definition into children's heads than older curricula.) I don't think they get much collision with the "simplify" operator while programming because the contexts are too different. I'd also submit that the conception of mathematical statements existing timelessly in some abstract math space would be foreign to them, and it is not hard for them to develop the "intuition" that "x = x + 1" is simply a statement that "after" this statement x will be one greater. The only people who have trouble with "x = x + 1" are mathematicians trained to a very particular formal level, where they understand the idea of equality more deeply than a high school student but still haven't noticed that operators and formalisms change between branches of math all the time and insisting on your precise definition of an operator hasn't yet inhibited you from understanding the branches of math that redefine it themselves. Granted, no branch of math uses a definition that looks like the imperative programming version (even mathematical formalizations of imperative programming tend not to use = for assignment from what I can recall), but it's still just one more definition in a constellation of definitions, not the uniquely odd one out. You're going to have a hard time with homotopy type theory if you insist on your conventional = definition, for instance.

willtim 10y ago
In the UK, algebra is first introduced using the equality operator, often with pictures of weight scales and weights, which students are asked to balance. Then they are introduced to a concise notation for this, e.g.: 1 + x = 3 Simplification comes later; and it often involves moving terms from one side of the relation to the other, which isn't possible with an assignment operator. I have no doubt that beginners soon learn any different meaning of "=" over time, but why reuse the operator in the first place? Is it really making it "easier" for the beginner? At least with BASIC the context switch was easier as it was strictly imperative. Python tries to mix in more declarative concepts. The misuse of the equality operator is only one minor detail, but if people care so little about such details, how can they be trusted to look after the more important ones?

crdoconnor 10y ago

>The rise of Python at the expense of safer, typed, faster, more principled languages makes me very sad for the state of our industry. Stronger type systems don't come for free. They come at the expense of slower prototyping.

willtim 10y ago
I respectively disagree. I use types for rapid prototyping. Often I write out the type signatures first, type-check the high-level compositions and then fill in the implementations later.

zephyrfalcon 10y ago

You say that like it's a bad thing. Python is a multi-paradigm language, allowing you to pick (or create) the idiom that is best suited for solving the problem at hand. It is not a straitjacket language that tells you how to think. The use of "=" for assignment is only confusing if you are already used to using for equations, and even then it's only confusing for a very short time, since it's obvious that the two (assignment vs equations) are completely different things. Python is hardly the first language to use it, by the way; I got started with BASIC on a Commodore 16 which used X=X+1, before I even knew about equations.

willtim 10y ago
In practice I do not see it being any more "multi-paradigm" than e.g. Haskell is. It just conflates the imperative and declarative subsets, meaning that a lambda is not really a lambda etc