Comment by jswrenn | Hacker News Reader

Comment by jswrenn | Hacker News Reader

Parent Full thread

Languages such as C, Java, Python, and Rust are usually designed by experienced programmers in industry, for experienced programmers in industry. Pyret, on the other hand, is designed by computer science educators, for computer science education.

This does not preclude Pyret from being a useful language for general-purpose programming; it just means that language design decisions are driven foremost by pedagogy. For example, Pyret trades performance for mathematical familiarity by using exact representations of rational numbers as its primary number type. Language like C, Java, Python, and Rust are all distinguished by different priorities that have guided their language design, too.

I disagree with your characterization of any language as being the "real thing" because it privileges some languages above others, but let's run with it for a moment: A systems programmer might call Rust or C the "real thing", in contrast to Python, and perhaps they would even consider delta "quality performance". A sysadmin might call Python the "real thing" in contrast to C, and consider delta "quality productivity". Assuming learning one programming language does not preclude you from learning another, why shouldn't a computer science education call "Pyret" the "real thing" and be asked to justify the "delta learning" of moving to language that isn't designed with pedagogic interests in mind?

(Disclosure: I am an occasional developer to Pyret, and this comment might not represent the views of the rest of the team. If skrishnamurthi or jpolitz replies, read their comment instead!)

I don't think you've responded to the most important point made by the parent, which is that any pedagogical value provided by a pedagogically-designed language over an engineering-designed language must be very substantial to offset the specified costs.

You have drawn privileged lines of your own across programming languages by suggesting that languages designed for education are better in the education context, and that languages designed for engineering are less fit for education. Do you think there is a pedagogical outcome difference arising from programming language difference?

So how much is that difference? How does one demonstrate the additional pedagogical value? Conversely, how does one demonstrate the relative disadvantages of using Python in education? Is the difference from Python -> Pyret an interesting barrier to students of computer science?

Meanwhile, the argument about the cost of maintaining tools and environment stands unchallenged, and the argument about the inertia of moving to a completely different ecosystem remains unchallenged.

PS: What pedagogical literature guides the pedagogically-focused design of this language? I couldn't find any on the website.

Wouldn't the value of education oriented languages be that educators can avoid specific complexities that get in way the of teaching core concepts?

Once a student has core concepts, then they have something they can build on with other languages that have more issues (potentially complex) stemming from practical problems. This prevents needing to learn two complex things at the same time.

Does pyret have easier to understand errors around syntax and typographical errors than Python? Most real languages won't search for similar identifiers to one that is misspelled and make suggestions, does pyret do anything like this (Other teaching tools do)?

I rephrase your post in my head:

The value of an education-oriented programming language is a boost to X education outcome relative to competing alternatives, and that "avoiding specific complexities" would be the mechanism by which to achieve your outcome.

Therefore,

(Pyret intervention) -> (educators don't struggle with language complexities) -> (education outcome)

But first I want to know that there's even a difference between (Pyret intervention) and (Python intervention) on (education outcome).

I think you are intentionally simplifying my statements, and the intents of educators, in an intentionally disingenuous way. If you are not being malicious, then I apologize, but the only way I can interpret you seems to indicate you have an axe to grind.

Let me provide an example of a language complexity that hinders education, presuming education cares about things common to many languages like function, types, control flow, classes and objects.

In C++ there is a strong separation of declaration and definition, this is required for silly, technical and mostly historical reasons. Teaching all of the concepts needed to make sense of why the compiler cannot elide definitions included twice is not useful when trying to teach about anything other than C++.

Another example, in Java there is much boilerplate and an implicit package scope when scope specifiers are omitted. Most languages need little boilerplate and in order to understand why the implicit package level specification is bad (or good if you disagree with me), one must understand the concept of public and private already.

For each language I know I can highlight such things. There is plenty of room for simplified teaching languages then extra courses to cover language specific things.

None of this should be taken as a general defense of how programming is taught. I just mean that whatever problems there are, seem not to stem directly from the use of education oriented languages. I even think that classes focusing on specific languages should more closely resemble the real world, but not all people are ready for such detail.

> I think you are intentionally simplifying my statements, and the intents of educators, in an intentionally disingenuous way.

You're telling me that:

(Pyret intervention) -> (educators not struggling with complexity) -> (education outcome)

was so bad you think I'm dishonest? And you think that's the "only way" you can interpret the situation? And just in case you're wrong -- sorry?

1. Proposing a causal relationship: (independent variable) -> (dependent variable)

2. Proposing complexity: (independent variable) -> (mediating factors) -> (dependent variable).

This is a fucking good start to any policy conversation. Where else do you find this online?

I wanted to give you the opportunity to rebut, but instead you have degenerated to swearing, red herrings and an inappropriate breakdown to formal style rational logic.

This discussion clearly has too many factors to be argued by formal proof. We cannot prove our premises nor prove an argument is formally sound. Therefor we must rely heavily on induction as many trades do, both software development and teaching are trades in many regards. Each often requiring action without the time or ability to formally prove and instead relying on large scale informal experimentation. The very existence of unit tests demonstrates how clearly practical programming cannot be formally proven and the existence of the whole fields of psychology and sociology ought to serve as basis for teaching impossibility to formally prove. This seems so obvious I hadn't felt the need to state it previously.

I presumed you capable and understanding and knowing this. I inferred that someone choosing to represent the argument in such way must see the situation is too complex to break down like this and must be misrepresenting the facts or they must not be competent to discuss this topic. Because I presumed your competence I felt you must be misrepresenting the situation, I now see I was mistaken.

Your point wasn't completely absurd in the beginning, but now you're wilfully misunderstanding the arguments. It seems you're hedging some sort of grudge against educators?

Asking for a statement of relationship between proposed intervention and proposed outcome is not even near absurd. Pedagogical researchers in policy do this all the time.

For example, Fiona Phelps has researched into gaze aversion in multiple contexts, one of which is pedagogical, and in there she proposes an intervention for educators, and she discusses outcomes. She is interested in making a causal link between intervention and outcome. It should also be noted that the causal model she discusses is simple, discussable, falsifiable, affirmable, has few factors and few measurement instances.

Discussing simple causal models is standard professionalism in pedagogical policy literature... or any other empirical field involved in policy.

Is it that scary to say that a Pyret or Python intervention should have a relationship to CS graduation rates, upper division performance, GPA, or some other stated policy outcome?

Not stating your intervention outcomes allows you to go statistical fishing.

One can say the same thing about iPads in schools. It's not wrong to ask what outcome variables the school intends to affect with an iPad intervention. Maybe the effect is there, but we can't begin discussion unless the proposed intervention is willing to state its predicted outcomes.

Why are you <not> pushing for a discussion of outcomes?

Since you keep coming back to Python: I already responded to you, I believe, on a comparison to Python. In case not, here it is again. https://news.ycombinator.com/item?id=13189513 Lots of educational outcomes (e.g., just about everything in the Bootstrap project [http://www.bootstrapworld.org/]) are linked to these differences, but since most people here are hackers, not educators, I'm sticking to the technical issues that lead to those differences.

1. Python has strange scoping rules. They are certainly not clean and nicely orthogonal. They complicate the ability to build basic tools and make them correct (e.g., see the appendix of http://cs.brown.edu/~sk/Publications/Papers/Published/pmmwpl...).

2. Python does not offer a neat integrated testing story.

3. Python does not have a type-like annotation mechanism along with a type-checker and a type system that is not extremely complex. For some people who want to teach introductory programming, this really matters.

4. Python does not have a clean functional event-loop construct, which is central to the pedagogy we use in many application so Pyret.

5. Python does not offer a typed interface to external data. Pyret's table support is designed with types in mind, but you can also use it just fine without types. [Quick table demo: https://twitter.com/PyretLang/status/773605473824145408]

6. Pyret runs entirely in the browser. With a Stop button in the IDE. There's tremendous complexity involved in making that run. Just about no other language does that in the browser. That's a really valuable feature to a beginner whose programs may go haywire.

That's not all, but that's a start.

On 3) Why do you care about types when teaching programming? (Not being facetious, this is a genuine question).

I've always thought that the advantage of Python (or even JavaScript) as a first language is that you can defer thinking about (to the layperson) unintuitive concepts like types, and focus on the core concepts behind telling a computer to do what you tell it to. (Functions, variables, control flow, maybe classes if you're feeling fancy).

I've talked to a super-smart Hack Reactor graduate who was blown away by the concept of static typing when I explained it to him in detail; it was simply irrelevant to his understanding of functional programming, data structures, and algorithms, subjects which familiar with at quite a high level.

On 2), what's missing in Python beyond the unittest package?

On 4) and 5), are these things that you introduce early in your curriculum? They seem like quite niche aspects of programming. I've found that most python programmers haven't had cause to use an event loop in production, for example; only really if you're implementing a web server or networking stack, something that frameworks usually abstract from you.

Regarding 3 I believe it's matter of doing it sooner rather than later. You can pretend that things don't have a type, but it's a lie.

The only thing that languages like JavaScript do differently is to hide the types of variables. This forces the person reading/writing the code to keep track of what is on what variable at all times instead of having a compiler do it for him.

I understand people have difficulty with pointers and such, but not types. Without that knowledge you can't go anywhere.

From my point of view there is absolutely no advantage in hiding types when you always end up using them. Better to face the fact and teach them early on.

3. We teach types to students as young as 12. They have no trouble with the concept, because they're taught from a young age about classifying things, and types are a form of classification. So there's nothing "unintuitive" about it. The people who have the most trouble with types are adult programmers who were raised on languages with awful type systems, like Pascal, and cannot envision any other kind.

Furthermore, we use types as a central notion in our program design curriculum. The structure of the data (aka, "types") provide a hint as to the structure of the program. This helps students who are stuck get unstuck. That is, they are most helpful to the students least able to get started, which seems like quite a valuable place to focus.

Of course, having annotations and enforcing them statically are two different things. That's why Pyret lets you check annotations dynamically instead. And that makes it even simpler and more intuitive to introduce the concept.

2. Direct integration into the syntax of the language makes a huge difference. There's no library and additional complexity. For rank beginners, every new "moving part" is a source of problems. This is why most Python curricula do not emphasize writing tests early. In our curricula, students begin with writing examples of their program's behavior — expressed as tests — and use that to help figure out the way the program must work. (Just like you use examples to help figure out a more general structure in other disciplines.)

4. Event loops are central to reactive programming, i.e., animations and games. HtDP 2nd edition begins with writing an animation. The Bootstrap curriculum is focused around teaching students to write a game — but in the process learn algebra. It's niche to you because you have a particular model of programming education, which may well resemble what people were teaching in the 80s. That doesn't mean curricula haven't moved on. And we're talking about education, not production, which are two different things.

5. Combine the earlier points for this one.

Whenever making "I haven't seen", "I don't see", etc. comments, it may be helpful to keep in mind Paul Graham's Blub Paradox [http://www.paulgraham.com/avg.html].

> Why do you care about types when teaching programming?

Because programmers are always aware of types. You may not annotate that the function's `licensePlate` parameter is a string, but if you are thinking of taking a substring or string-appending it, of course you're aware of the type.

If a beginner is only vaguely/intuitively thinking that the licensePlate is a string (sometimes confusedly thinking it's a number), then there'll be problems. So allowing a beginner to mention a type is important.

So the question is more: when learning to program, do you require every name to be annotated with a type? Some people feel this is overkill, and others think it helps, for CS1. And languages with implicit conversion-rules can confuse some beginners, while converting explicitly can annoy others.

Once somebody has internalized the rules, then yes of course you want the language to make "obvious" conversions and/or declarations for you (e.g. true-ish expressions, and (for Java) auto-boxing and auto-toSTring'ing). But just because experienced programmers find it indispensable doesn't mean it's appropriate for beginners.

(Btw, in addition to learner-vs-competent programmer, there is a separate issue, about the strength of the students: some people pick up programming-way-of-thinking easily, and others need MUCH more guidance before they become competent. Different language-choices might be appropriate for those two audiences, as well.)

One thing that comes to mind is that a language that prioritizes pedagogy would probably have a vastly different perspective on backward compatibility. And historically, that's a huge constraint on how "real-world" PLs can evolve in practice. Every language I've spent any amount of time with is either deeply encumbered by suboptimal design decisions on the past or has experienced extremely painful version transitions. A language whose first priority is pedagogy can presumably evolve much more freely. I don't know enough about Pyrets to say whether that is the case here.

Not enough upvotes for this. And yes, Pyret is free to break things and move on when we figure out better ways of doing things. We've done that a few times already.

> Languages such as C, Java, Python, and Rust are usually designed by experienced programmers in industry, for experienced programmers in industry. Pyret, on the other hand, is designed by computer science educators, for computer science education.

Honestly, looking at the examples on the Pyret main page makes me think that this isn't a good approach at all. I have been in software engineering for many years now and worked with quite some languages, yet I find the code practically in-understandable and the language looks very complex. So likely someone who "learned" using this language will have a lot of trouble actually working with real languages, assuming that he actually managed to learn this language as his first, which is rather unlikely I believe.

I was also involved in CS education - in first semester programming courses. And the language is really the last problem there (C was used, I think the dept. is moving to Python for that course though). Especially eg. Python is a good language overall and is already widely used in CS education.

In short, I don't see why the world needs this, and I actually think that using it would be actively harmful.

What characteristics makes a programming language a "real" programming language?

- has a standard library

- has library support for the usual stuff: strings, math, web, database, encoding, etc.

- written using a lower level language (like C, Rust, C++), self hosted (Go) or a mix of those (Dlang, Perl6)

- is actually used to build applications, has some sort of community around it (Rust, Perl, Python, Lua etc.) or some backing (Swift, Java, Go)

The most important distinction would be that you don't have to make a transition from education contexts to production contexts.

I mean, why isn't it possible to design a language that is both quite fit for education & production? Is Python vs. Pyret really that big a difference in education outcomes?

This is important for professors & TA's, educators, or enthusiast parents who wish to teach their children. All have to master a toolset and environment prior to teaching others, and maintaining the environment is also an ongoing cost. Some of this cost will be assuredly transferred to students, so we want to be sure that a "pedagogical" language without production traction has such powerful gains that it offsets the losses.

Yes, it is a big difference, depending on what you're trying to teach. If you want to teach a conventional CS curriculum recognizable from the 80s, Python is great (though some people really prefer teaching with static types, which Python does not have and which are absurdly hard to add now). Here are several other differences: https://news.ycombinator.com/item?id=13189513

It's a real language if there are programs written in it where the where the main goal is what the program does when you run it, and not what the author learned writing it.

This is kinda like learning CS theory - kinda useful to keep in mind for other things, but never actually used. ie -> set theory, Finite automata, Turing machines etc...

Yup, I second that. Lua is much more simpler by comparison. Python is pretty easy as well. You can do lots of stuff with those two alone, not only on desktop/mobile platforms but on embedded devices as well (think eLua, Arduino, Pinguino).

There are so many examples of people who have learned a Lisp-family language in school and gone on to learn an industrial language later. This is a Lisp-family language with some syntactic sugar to make it look more Pythonic, basically.

Since when are Lisp-family and industrial languages not overlapping sets?

I was trying to come up with something less loaded than parent's "real languages" phrasing, to describe the sorts of languages commonly used in industry, like Java and whatnot.

I think that's taking it a bit far. I especially don't see how being explicit about the problem you're solving (teaching computer science to newcomers in a collegiate setting) and focusing the effort towards that problem and iterating on the methods used to teach it (building better tools and iterating without importing unnecessary baggage) is "actively harmful."

Simply looking at text in a different language is not going to impart magical understanding. Things you haven't actually used in a non trivial program will seem complex at the beginning. And sure, you can rationalize that away by treating this like a special case, but it's just a general bias in our brains. And depending on your background, certain languages may seem more complex than others due to simply lack of exposure.

I'd rather propose putting it up to a damn test. Compare the computer science knowledge of outgoing students to other students in similar circumstances who were taught using a practical, heavily-used-in-industry language. Use a short test maybe, along with interviews to get at qualitative unknowns. The results of that could then be used to pick the best strategy to teaching going forward.

But also, in general, why not try to solve the problem better, without pre-supposing all the sunk costs and existing ideas? And not everything needs to be on the freaking altar of industry either. It's not like your college implementation of heap sort is gonna be mainlined in a company and used forever more. What're you optimizing, the couple of weeks it'd take for someone who already knows this to learn python? You already saved it probably by skipping the b.s. until it actually became relevant to learn about.

> I think that's taking it a bit far. I especially don't see how being explicit about the problem you're solving (teaching computer science to newcomers in a collegiate setting) and focusing the effort towards that problem and iterating on the methods used to teach it (building better tools and iterating without importing unnecessary baggage) is "actively harmful."

It's pretty clear that I was specifically referring to the language at hand and not to general idea/concept.

> ... needs this ... using it ...

Except there are numerous things Python can't do [https://news.ycombinator.com/item?id=13189513], and at least as much harm comes from trying to push the round Pythonic snake into a very square hole.

  yet I find the code practically in-understandable and the 
  language looks very complex

Well, then I wonder what these 'quite some languages' that you worked with are, because the language really doesn't look that uncommon or complex to me.

  I was also involved in CS education [..]
  And the language is really the last problem there

The people that created Pyret have been in CS education for decennia and have done a lot of research on 'how can we make CS education better'. Their conclusion was that the idiosyncrasies of the various industrial languages very much are the problem. You give to much weight to your own prejudices and subjective observations. The experimental results prove otherwise.

"For example, Pyret trades performance for mathematical familiarity by using exact representations of rational numbers as its primary number type."

(Disclaimer: I haven't used Pyret) But.. maybe the language allows the developer work out problems differently. With that in mind, perhaps asserting that the language was built for education, [so as to imply that it'll make you a better programmers in general, even in 'bloated or expert' languages], doesn't necessarily shed light on its actual benefits -- but I'll check it out later on to find out for certain.

Reply on news.ycombinator.com