Pyret – A language exploring scripting and functional programming • Hacker News Board

Re: Pyret – A language exploring scripting and functional programming

#261

Post by zem » Fri, Dec 16, 2016, 7:46 PM UTC

a0 wrote: post #236

zem wrote: post #129

Earlier quoted context omitted.

i think the pyret syntax is wonderful, personally. it takes a lot of good bits from my two favourite languages, ruby and ocaml, and blends them into a nicely coherent whole. there are a few minor things i'd probably have done differently, but on the whole i find pyret code very pleasant to read.

> there are a few minor things i'd probably have done differently, but on the whole i find pyret code very pleasant to read. Curious to know what would you have done differently. I'm working on a programming language based on OCaml with Ruby-like syntax.

just bikesheddy stuff like

* |> rather than ^ for the pipe operator (more consistent with several other languages)

* [list| 1, 2, 3] rather than [list: 1, 2, 3] (just for better visual distinction, though the current syntax does look pretty clean and uncluttered)

* having a separate code block for methods of individual variants rather than interspersing them with data definitions (because i think it's important that the basic data definition be as uncluttered as possible)

if you'd like some syntax feedback on your language i'd be happy to take a peek :)

Re: Pyret – A language exploring scripting and functional programming

#262

Post by codygman » Fri, Dec 16, 2016, 11:32 PM UTC

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.

I know a fair amount of Haskell. For instance I know Haskell doesn't use reference equality.

Re: Pyret – A language exploring scripting and functional programming

#263

Post by skrishnamurthi » Sat, Dec 17, 2016, 12:54 AM UTC

zem wrote: post #261

a0 wrote: post #236

Earlier quoted context omitted.

> there are a few minor things i'd probably have done differently, but on the whole i find pyret code very pleasant to read. Curious to know what would you have done differently. I'm working on a programming language based on OCaml with Ruby-like syntax.

just bikesheddy stuff like * |> rather than ^ for the pipe operator (more consistent with several other languages) * [list| 1, 2, 3] rather than [list: 1, 2, 3] (just for better visual distinction, though the current syntax does look pretty clean and uncluttered) * having a separate code block for methods of individual variants rather than interspersing them with data definitions (because i think it's important that…

I'd disagree with the second one. `[list: 1, 2, 3]` reads more like in English: "I'm going to define a list: one, two, three…". Whereas `[list| 1, 2, 3]` has no obvious vocalization. (Vocalization is an important characteristic for us; it's how `ask` came to have its syntax.) In addition, we usually use `|` in programming languages in a separator kind of way (even `||` for "or" separates expressions), which it's certainly not in the list expression.

Re: Pyret – A language exploring scripting and functional programming

#264

Post by skrishnamurthi » Sat, Dec 17, 2016, 12:57 AM UTC

branchly2 wrote: post #256

jpolitz wrote: post #156

Earlier quoted context omitted.

Thanks for the advice! What are some examples where a teaching language has followed these points and succeeded? What is the weirdness and/or pet features you see in Pyret?

I'm an old curmudgeonly programmer (more hobby than pro), have kids in middle and high school, and have some meager amount of teaching experience. Here's my take: your students (especially in middle and high school) are generally a captive audience. Maybe later, if they have more interest in comp sci, they may be interested in using a more alternative language, but right now they want you to give them something that…

Your initial list pretty much exactly describes Pyret. It doesn't have JS's warts, but still runs in the browser entirely. It's higher-level than C and C++. It doesn't require types or a JVM. It isn't like Perl in any of the zany ways. It's a bit like Python and with totally sane scoping. And it's very much like Scheme but with conventional (infix) syntax and lists, sets, maps… And it's used in several high schools already.

Re: Pyret – A language exploring scripting and functional programming

#265

Post by skrishnamurthi » Sat, Dec 17, 2016, 12:59 AM UTC

codygman wrote: post #262

skrishnamurthi wrote: post #249

Earlier quoted context omitted.

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

I know a fair amount of Haskell. For instance I know Haskell doesn't use reference equality.

And the lack of it makes it hard to test for things like node equality when doing graph algorithms. There's an extra layer of encoding you need to be able to simulate reference equality. And even if you addressed the equality issue, I brought up two other issues that you didn't address.

Re: Pyret – A language exploring scripting and functional programming

#266

Post by skrishnamurthi » Sat, Dec 17, 2016, 12:59 AM UTC

tome wrote: post #250

skrishnamurthi wrote: post #249

Earlier quoted context omitted.

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.

See https://news.ycombinator.com/item?id=13198342

Re: Pyret – A language exploring scripting and functional programming

#267

Post by zem » Sat, Dec 17, 2016, 1:26 AM UTC

skrishnamurthi wrote: post #263

zem wrote: post #261

Earlier quoted context omitted.

just bikesheddy stuff like * |> rather than ^ for the pipe operator (more consistent with several other languages) * [list| 1, 2, 3] rather than [list: 1, 2, 3] (just for better visual distinction, though the current syntax does look pretty clean and uncluttered) * having a separate code block for methods of individual variants rather than interspersing them with data definitions (because i think it's important that…

I'd disagree with the second one. `[list: 1, 2, 3]` reads more like in English: "I'm going to define a list: one, two, three…". Whereas `[list| 1, 2, 3]` has no obvious vocalization. (Vocalization is an important characteristic for us; it's how `ask` came to have its syntax.) In addition, we usually use `|` in programming languages in a separator kind of way (even `||` for "or" separates expressions), which it's cert…

"list where the elements are 1, 2, 3", by analogy with set builder notation or list comprehensions :) but i agree the current one reads better as english.

it's the separator aspect i was getting at with my proposal though - visually it's [ datatype | elements ] whereas the current one looks more like the colon is part of the first element - [(list : 1), 2, 3]

Re: Pyret – A language exploring scripting and functional programming

#268

Post by Confusion » Sat, Dec 17, 2016, 10:08 AM UTC

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…

  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.

Re: Pyret – A language exploring scripting and functional programming

#269

Post by cwyers » Sat, Dec 17, 2016, 5:09 PM UTC

dragonwriter wrote: post #258

cwyers wrote: post #144

Earlier quoted context omitted.

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.

Re: Pyret – A language exploring scripting and functional programming

#270

Post by not-just-yeti » Sat, Dec 17, 2016, 5:36 PM UTC

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…

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