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

101–110 of 272 posts

Re: Pyret – A language exploring scripting and functional programming

#101

Post by pgbovine »

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

What about a 'teaching' OS/compiler/toolchain vs. the 'real' thing? e.g., a stripped-down OS kernel with minimal clean code optimized for teaching vs. throwing someone into Linux source. or a teaching-oriented compiler vs. wading into GCC/LLVM?

Teaching languages/OSes/compilers/toolchains (if done well) lower the barrier to entry while providing a conceptual transition path to learning 'real' stuff later on the job. Plus, the 'real' thing that we may be teaching in school now may not even be relevant in 4 years in industry when students get out into the working world, and they will have to pick up new languages/toolchains/etc. constantly on the job anyways. There is definitely a good argument for authenticity, but also one for paring down extrinsic complexity to illustrate core computer science concepts. e.g., try explaining parsing using full-blown C++ as a case study -- that seems pretty daunting. But one of these teaching languages (if done well, of course) is much easier to write parsers for.

Re: Pyret – A language exploring scripting and functional programming

#102

Post by nine_k »

AbrahamParangi wrote: post #51

I strongly believe that people who are learning to program should learn in a language that can actually be used to make things. This may run counter to the 'work smarter, not harder' ethos I see here but I feel that programming competency in practice is much more a function of literal hours writing code than any other factor.* *with the caveat that competency tends to follow a sub-linear growth curve and people vary…

People who learn to program have to get used to the idea that programming languages are many, and they have to attain certain competence in several of them.

A typical frontend dev uses Javascript, CSS, HTML, likely some occasional bash.

A backend developer probably faces the preferred backend language (Java / Python / Ruby / PHP / whatever), SQL, and has to have at least a nebulous understanding of HTML, CSS, and JS.

A devops person has to face a shell language, the Unix tools mini-languages, have enough Python or Ruby chops to handle things like Ansible / Salt / Chef, and likely some SQL to keep an eye on the databases.

This does not include smaller languages like regexps, or narrow-use languages like XSLT, JSON Schema, etc.

There's no way you learn the One Practical Language That Matters and can be limited to it. You could in past, with a Spectrum or a TRS-80 and Basic, but the times have changed.

Re: Pyret – A language exploring scripting and functional programming

#103

Post by biot »

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

It does have one benefit: it forces the student to learn a second programming language sooner. I wouldn't want to work with someone who only knows the language they started out with, and likely still carries many bad habits from.

Re: Pyret – A language exploring scripting and functional programming

#104

Post by jswrenn »

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

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

Re: Pyret – A language exploring scripting and functional programming

#105

Post by samcal »

simplify wrote: post #95
eridius wrote: post #87

Earlier quoted context omitted.

Scheme and Racket are both LISPs, with very different syntax. Hyphens in identifiers aren't a hazard, because binary operators don't go between two other identifiers, and operators must be separated with spaces, e.g. subtraction looks like `(- 2 1)` instead of `2 - 1`. This means that using hyphens in identifiers is quite safe. But Pyret is using more traditional syntax, where binary operators go between their operan…

The problem is overblown. It's not going to cause any deep, hard-to-debug errors. If you accidentally type `a-b`, you'll get an error message that says "a-b is not defined". Fix it and you're done.

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.

Re: Pyret – A language exploring scripting and functional programming

#106

Post by Avshalom »

pierrebai wrote: post #93
Avshalom wrote: post #43

Earlier quoted context omitted.

Part of the reason whitespace is inconsistent around operators is because nothing about most languages forces you to care. It's a lot like case sensitivity in that regard.

There's more to it; making whitespace significant makes it harder to read in print and when presented with non-monospace fonts on-screen. Even without these caveat, it's still a bit harder to visually process. It's like the = vs == problems. It's easy to get right, you almost always get it right, but it's close enough to cause errors and requires extra concentration effort. Other lisp-ism: gratuitous abbreviations. I…

it's kind of interesting because originally my comment was a stronger defense of hyphens then when I compared it to Case sensitivity I actually back tracked.

Ada for instance specifically considered then rejected case sensitivity because they had a (at least one) study that said case sensitivity was a source of errors.

I don't know how well instrumented the pyret courses are but I would be very if they have studies on this.

Re: Pyret – A language exploring scripting and functional programming

#107

Post by emidln »

makmanalp wrote: post #13
mattangriffel wrote: post #4

As someone who teaches coding to beginners for a living (I founded One Month and I teach Python to business students at Columbia University), this language looks really intimidating to beginners. Maybe Pyret isn't for beginners, and it's intended to teach people who already have some basic knowledge more advanced concepts like functional programming. That's fine. But to a total beginner, the syntax of Pyret is defini…

Annotations are optional. This is equally valid: fun square(n): n * n end Not that different after all! And I say this as a lover of python and significant whitespace, but not having it at first would be easier.

There should be optional syntax that allows:

    fun square(n):
      party in here
    unfun
    // no longer having fun here

Re: Pyret – A language exploring scripting and functional programming

#108

Post by jpolitz »

nnq wrote: post #100

Seems like a great functional scripting language with above-retard type system. This is really cool , no sarcasm. Just please don't label it as "educational" or "academic" or industry devs will avoid it out of pure macho-ism :) And find a way to marry it to a popular ecosystem, maybe a transpiler to js (for nodejs ecosystem) or python or go. 'Cause it really looks like a language I'd enjoy writing production code in…

Pyret's runtime is entirely built on JavaScript (seriously: you can load https://code.pyret.org/editor, then turn off the network, and your IDE still works), and Pyret programs compile to JavaScript. At the command-line, it builds standalone JavaScript files that run under node.

It's entirely possible to write pure JavaScript libraries that interface with the language (the compiler expects AMD style and requires that you write some small wrapping code). That's how the image library (https://www.pyret.org/docs/latest/image.html) works, for instance, and how we connect to Google Sheets (https://github.com/brownplt/pyret-lang/wiki/TM028-Pyret-and-...).

Industry devs should be suspicious of Pyret's performance right now, though that will improve as time goes on. We've been spending most of our effort supporting our student and teacher users, so things that really build the traditional out-of-the-box language experience aren't where a typical application developer would hope.

I think that's fine since we've made our intentions and goals clear (the educational audience and a coherent curricular design), and would be less fine if we were offering Pyret as a general-purpose language today. Offering it as general-purpose will become more and more reasonable as time goes on.

Re: Pyret – A language exploring scripting and functional programming

#109

Post by AbrahamParangi »

nine_k wrote: post #102
AbrahamParangi wrote: post #51

I strongly believe that people who are learning to program should learn in a language that can actually be used to make things. This may run counter to the 'work smarter, not harder' ethos I see here but I feel that programming competency in practice is much more a function of literal hours writing code than any other factor.* *with the caveat that competency tends to follow a sub-linear growth curve and people vary…

People who learn to program have to get used to the idea that programming languages are many, and they have to attain certain competence in several of them. A typical frontend dev uses Javascript, CSS, HTML, likely some occasional bash. A backend developer probably faces the preferred backend language (Java / Python / Ruby / PHP / whatever), SQL, and has to have at least a nebulous understanding of HTML, CSS, and JS.…

I agree that everyone likely has to learn more than one language in the course of their life, but the difficulty of learning language N is typically more than learning language N+1.

Therefore I believe that it is productive to start beginners off with a language which is:

1) as approachable as possible 2) as useful as possible

Such that the value of that first, most difficult learning experience is maximized and the challenge is minimized.

Re: Pyret – A language exploring scripting and functional programming

#110

Post by throw_again99 »

mkolosick wrote: post #92
throw_again99 wrote: post #78

Earlier quoted context omitted.

Hi, thanks. Primarily I wondered about actual mixing of ADTs and objects, which is limited even in OCaml, see e.g.: http://caml.inria.fr/pub/ml-archives/caml-list/2003/06/bed28... But does Pyret always translate an ADT to a class hierarchy behind the scenes? This example sure looks like it does: data Animal: | elephant(name, weight) | tiger(name, stripes) | horse(name, races-won) ... end fun animal-name(a :: Animal):…

Good question! Pyret does not translate to a class hierarchy. Pyret dynamically allows dot lookups on both objects and ADTs. In the type checker this means that an ADT permits dot lookup on any field that all variants have (in this case, `name`), as this will always be safe. Additionally, Pyret's type system internally tracks each of the different constructors as a refinement on the type. With the animal example this…

This is rather nice. You get a lot of convenience for that one type annotation!
Post reply on HN