Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pyret – A language exploring scripting and functional programming

pyret.org

Post reply on HN
Print view View original

241–250 of 272 posts

Re: Pyret – A language exploring scripting and functional programming

#241

Post by Draiken »

theptip wrote: post #229
skrishnamurthi wrote: post #182

Earlier quoted context omitted.

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…

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 cl…

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.

Re: Pyret – A language exploring scripting and functional programming

#242

Post by qwertyuiop924 »

lispm wrote: post #232
qwertyuiop924 wrote: post #211

Earlier quoted context omitted.

Gladly. >including Racket's commercial users. A language doesn't need maturity to have commercial use. Rust had commercial adoption pre-1.0, and that adoption is increasing. Rust is also nowhere near mature. Racket being built in part for education is also undeniable. Look it up. Racket's library support vs CL's is highly debatable. Neithet is ideal, but both are "good enough," so let's leave it at that. As for Racke…

> Racket being built in part for education is also undeniable. Look it up. You realize who you said that to?

No. But whenever somebody says that to me, it's a bad sign...

Re: Pyret – A language exploring scripting and functional programming

#243

Post by dkersten »

CodeMage wrote: post #112
samcal wrote: post #105

Earlier quoted context omitted.

While I agree that the problem is not a very big deal, I think that you might be surprised how difficult understanding compiler errors can be for newcomers.

I regard that as a valuable teaching moment: "This, kids, is a great example of what you'll have to deal with all the time. Computers are not smart and neither are compilers. Forget a semicolon or some whitespace, and it's your job to clean up the mess after your compiler shits its bed."

Having been a tutor of first-year beginner programming students many years ago, my experience has been that its not quite as simple as this.

The number of people who forgot even the most simple syntax rules towards the end of the semester, even after having shown them during each lab session, was surprisingly high.

You tell them that the computer is super dumb and pedantic and they understand this. So you tell them the rules (semi colon at the end of line perhaps) and they understand. Then an hour later and they're staring blankly at the screen wondering why they got the exact same error again.

Obviously not all students are like this and almost all did get it after a while, but you'll be repeating your statement to them enough times that you wished the language didn't have whatever warts is causing the confusion.

I found Java particularly bad, because you have to tell beginners to ignore 90% of the hello world program (class ... public static void main ... - you have to tell them "hey, ignore class, public, static, void etc for now, we will cover it later"), which isn't satisfying at all and in my experience caused more confusion still...

Yes, you've got to treat it as a learning experience, but the students usually see it as a roadblock and cause of frustration. Often one that doesn't make sense to them and they question why its even a thing. ("why can I use '_' in identifiers and not '-'?", not too hard to explain of course but its yet another bit of incidental complexity to them)

Re: Pyret – A language exploring scripting and functional programming

#244

Post by skrishnamurthi »

theptip wrote: post #229
skrishnamurthi wrote: post #182

Earlier quoted context omitted.

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…

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 cl…

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].

Re: Pyret – A language exploring scripting and functional programming

#245

Post by skrishnamurthi »

acjohnson55 wrote: post #231
threatofrain wrote: post #140

Earlier quoted context omitted.

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…

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…

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.

Re: Pyret – A language exploring scripting and functional programming

#246

Post by skrishnamurthi »

threatofrain wrote: post #240
matt4077 wrote: post #225

Earlier quoted context omitted.

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 int…

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.

Re: Pyret – A language exploring scripting and functional programming

#247

Post by skrishnamurthi »

dom0 wrote: post #114
jswrenn wrote: post #104

Earlier quoted context omitted.

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…

> 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…

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.

Re: Pyret – A language exploring scripting and functional programming

#248

Post by skrishnamurthi »

steego wrote: post #98
davexunit wrote: post #38

Earlier quoted context omitted.

Can we stop assuming that only the syntaxes we are accustomed to are the only "readable" options?

Whether some is readable is always going to be subject to who's reading it. That's simply how readable/non-readable work. Now you can learn to read new languages (human or machine), but I suspect someone who knows a romance language will find other romance languages for more readable than Chinese. Romance languages share words, alphabets, and many syntactic features. You can draw from an existing body of knowledge an…

Pyret draws from traditional algebra notation, Python, and OCaml/Haskell. If you do not know any of these, you must be a pretty weak programmer. If you do most of these, you ought to be able to recognize almost every part of it. Anyway, the good news is that programming beginners — who don't know any languages — have no real trouble with it, so any difficulties may say more about the reader's blind-spots than about the language itself.

Re: Pyret – A language exploring scripting and functional programming

#249

Post by skrishnamurthi »

codygman wrote: post #235
skrishnamurthi wrote: post #169

Earlier quoted context omitted.

Because we also use Pyret to teach program complexity, and big-O is a whole 'nother can of worms in Haskell (the cost model is totally non-traditional). Because we use Pyret to introduce students to state, and even basic equality is a whole 'nother can of worms in Haskell. Because we teach basic algorithms in Pyret, and even something like DFS in Haskell is complicated (because of the preceding issues).

> even basic equality is a whole 'nother can of worms in Haskell How so?

I'm afraid I don't have time here to explain Haskell. Think about how graph reduction and reference equality would interact.

Re: Pyret – A language exploring scripting and functional programming

#250

Post by tome »

skrishnamurthi wrote: post #249
codygman wrote: post #235

Earlier quoted context omitted.

> even basic equality is a whole 'nother can of worms in Haskell How so?

I'm afraid I don't have time here to explain Haskell. Think about how graph reduction and reference equality would interact.

codygman and I both understand Haskell well, but neither of us (apparently) can work out what you mean. There's no "can of worms" around equality in Haskell as far as I can see.
Post reply on HN