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

231–240 of 272 posts

Re: Pyret – A language exploring scripting and functional programming

#231

Post by acjohnson55 »

threatofrain wrote: post #140
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…

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

Re: Pyret – A language exploring scripting and functional programming

#232

Post by lispm »

qwertyuiop924 wrote: post #211
skrishnamurthi wrote: post #198

Earlier quoted context omitted.

Says you, and many disagree, including Racket's commercial users. But of course it's pointless arguing with a CL fanatic (I learned that two decades ago on c.l.s, and looks like nothing has changed), so please do go ahead and have the last word.

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?

Re: Pyret – A language exploring scripting and functional programming

#234

Post by nnq »

jhbadger wrote: post #111
nnq wrote: post #96

Earlier quoted context omitted.

> a challenging claim to make ...or more like the obvious intuition and wisdom of 99% of working software developers. The intuition is not backed up by any peer-reviewed evidence but by the real world fact that most production code ends up written in C++, Java, C#, JavaScript, PHP, Python,Ruby etc. and not Haskell, OCaml, F#, Clojure etc. Since they made the first stone tools and cave drawings, humans have always def…

Based on ancient literature and holy texts, people from early cultures seemed to be obsessed with their lineage, stating "I am X son of Y, who was son of Z" etc. Do you think they thought about it in terms of procedures for determining lineages or just definitions of relationships? The latter would be easier to model in languages like Prolog rather than C++ or Java.

Their kings were. Imho there's a certain minority of people, maybe 0.001%, who are definitely not what I call "makers", with waaaay above average "communication/leadership/manipulation + sword swindling" skills who end up kings/emperors/etc. (at least the first time; then it's just because they were born in the right bloodline - hence another reason for "bloodline obsession"). And their scribes (the guys with good communication but bad sword swindling skills and of the wrong bloodline).

The rest of the people were more obsessed with "what steps to follow to plant my seeds in the ground so as to increase the probability of crop yield" or "what steps to take when preserving food so as not to get really sick" or "what steps to do in what order when building my house do it does not fall down on me at the next storm" etc.

Oh, and lineage is pretty much retrospective "how-to knowledge" anyway: it describes what the sequences of actions where that resulted in someone existing today: 'X1 and X2 had a baby", then "the son of X1 and X2 married Y0" and "moved to village Q" after "fighting in war Z" etc. History is pretty much recorded procedure.

Not until we got to philosophy, geometry and other types of math did we really have clear what-is knowledge... (Except maybe for religion, and no wonder that smart priests and monks were pretty damn good at math.)

As an example, go to any remote village with and ask them "where is X" and what they'll inevitable tell you is "what actions to perform to get from here to place X". (The infuriating part is that some of the modern humans kept this thought pattern and good luck getting indications to how to get anywhere from them... thank god for the "what is" knowledge provided easily by google maps :) )

Re: Pyret – A language exploring scripting and functional programming

#235

Post by codygman »

skrishnamurthi wrote: post #169
thecity2 wrote: post #162

Why not just use the "easy" parts of Haskell as a teaching language for functional programming? No monads, applicatives, etc. No category theory. Just immutability, laziness, pattern matching, and type classes. I feel like that makes as much sense as developing an entirely new language that most likely will only be used by a complete novice. Conversely, one can grow with a language like Haskell for an entire lifetime…

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?

Re: Pyret – A language exploring scripting and functional programming

#236

Post by a0 »

zem wrote: post #129
gr3yh47 wrote: post #5

Honestly imo Python is the best language to start with for learning. It has all the basic constructs of both functional and object oriented programming in plain english without a bunch of syntax to worry about. I personally think it's the most readable language. it's also quite intuitive imo. Lastly, there's a fantastic community and instant help is available for all skill levels but especially beginners on #python o…

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.

Re: Pyret – A language exploring scripting and functional programming

#237

Post by semi-extrinsic »

jpolitz wrote: post #186
semi-extrinsic wrote: post #167

Earlier quoted context omitted.

I also belong to the skeptic crowd as far as fancy CS teaching languages are concerned. I think there's much greater value in a first language that's three things: dead simple, useful, and which lets you poke through the abstractions. A lot of us hackers here today cut our teeth on BASIC, even me as a 90's kid. I remember the joy at having automated away rote chemistry or physics homework, and in hindsight realise th…

Thanks for the feedback. > The docs you link for the "dead simple animation framework" assumes I understand templates; that's hardly dead simple The idea of "templates" comes with a lot of baggage from C++-land. If we were doing this with C++ templates, I'd agree, because the errors are abysmal and the types are difficult to write. As an example, we teach students to pick "the type of their reactor's state" as a usef…

Thanks for the response!

> The idea of "templates" comes with a lot of baggage from C++-land. If we were doing this with C++ templates, I'd agree, because the errors are abysmal and the types are difficult to write.

You're spot on. I suspect most people familiar with template-ish expressions come from C++, where you encounter quite a few projects that are "templates all the way down" (looking at you, OpenFOAM).

Re: Pyret – A language exploring scripting and functional programming

#238

Post by StreamBright »

gfodor wrote: post #52

I've never understood the idea of a 'teaching' programming language. (Modulo examples like Logo and Scratch, which offer much more than a language as part of a wider teaching/computing system.) You spend all this time ramping up on a language, toolchain, library, etc, that you will eventually be unable to leverage beyond a certain point since it is not one used by everyday programmers. The delta in "quality learning"…

I think teaching LISP (Clojure) is an excellent option to demonstrate how easily you can solves complex problems by chopping up the problem to simple idempotent functions. Teaching students to use a complex OOP language with lots of gotchas and tricks is much harder in my opinion. Focusing on the concepts of data structures, recursion, time complexity is great for most newcomers to software.

Re: Pyret – A language exploring scripting and functional programming

#239

Post by Grue3 »

wolfgang42 wrote: post #77
kpil wrote: post #66

Earlier quoted context omitted.

I'd say there is some room for confusion, even if it's not in the grammar. I have spent quite some time chasing bugs of the type (- a -1) where the second minus ended up there because of either a copy/paste-error or a brain fart due to the original expression was a - 1...

I'm not sure how (- a - 1) would work, unless you've named something "-"?

- is a function. Because Closure is a Lisp1, substraction function being passed as an argument like that is very probable. In Common Lisp you'd pass #'-, so it's clear that it's a function being passed.

Re: Pyret – A language exploring scripting and functional programming

#240

Post by threatofrain »

matt4077 wrote: post #225
threatofrain wrote: post #212

Earlier quoted context omitted.

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

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 pushing for a discussion of outcomes?

Post reply on HN