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

Re: Pyret – A language exploring scripting and functional programming

#161

Post by vorg » Thu, Dec 15, 2016, 10:07 PM UTC

AstralStorm wrote: post #75

lmm wrote: post #63

Earlier quoted context omitted.

"def" is an abbreviation non-programmers are more likely to understand than "fun".

But that's no fun. ;-) Seriously, fun is obvious for function to anyone. (also, defun in some other languages fits the bill) In contrast, def doesn't explain what is defined. (See Groovy where it is a real problem or JavaScript where you can use var for everything.)

I remember Apache Groovy's use of the verb def to match the verbs and adverbs of the other statement-level keywords (e.g. switch, if, while, return) instead of a noun like any to match the type names it stands in for (e.g. int, bool, String, null) was, er, discussed at length on their mailing list back around 2005-06. The Nabble interface to those discussions has since been obfuscated by being redirected and embedded within a page from the groovy-lang.org website so I can't easily find a link to those discussions.

Re: Pyret – A language exploring scripting and functional programming

#162

Post by thecity2 » Thu, Dec 15, 2016, 10:13 PM UTC

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. Just my two cents.

Re: Pyret – A language exploring scripting and functional programming

#163

Post by szemet » Thu, Dec 15, 2016, 10:30 PM UTC

AstralStorm wrote: post #80

sdx23 wrote: post #60

Earlier quoted context omitted.

In what world is: def square(n): return n * n ... easier for a beginner to understand than: square n = n * n

Is square a function or object/data structure result of operation? Welcome to the Real World. Please make different entities look different.

Usually when one starts to learn to program already have learned some math. So knows only this notation for funcions: square(x) = x*x

"Return" seems meaningless.

So that is the "real world" function declaration (if this phrase makes any sense for a math notation convention) for a nonprogrammer.

Is that what you mean? Because then I agree...

Re: Pyret – A language exploring scripting and functional programming

#164

Post by sqeaky » Thu, Dec 15, 2016, 10:38 PM UTC

threatofrain wrote: post #149

sqeaky wrote: post #147

Earlier quoted context omitted.

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

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

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.

Re: Pyret – A language exploring scripting and functional programming

#165

Post by skrishnamurthi » Thu, Dec 15, 2016, 10:38 PM UTC

analog31 wrote: post #132

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

The first language that I learned was a "teaching" language: BASIC. That was in ~ 1981. A potential advantage at the time was that BASIC tended to be a completely self contained environment, meaning that you didn't have to assemble things like build tools and libraries. "Hello world" was one line of code, you entered it, and it ran. And at that time, just dealing with the tools -- typically on a mainframe -- was the…

"Ignore" is easier said than done. Students make mistakes. They type the wrong character. They put something in thew wrong place. If you don't enforce your sub-language, you are effectively throwing them into the open, and they suffer. We've seen numerous examples of this, which is why DrRacket offers teaching languages that are subsets of the full language, with customized errors that match the student's vocabulary and level of understanding, etc.

Re: Pyret – A language exploring scripting and functional programming

#166

Post by skrishnamurthi » Thu, Dec 15, 2016, 10:40 PM UTC

kazinator wrote: post #69

cygned wrote: post #26

Earlier quoted context omitted.

As a Clojure programmer, I learned to love hyphens, so much more readable. But since Clojure is a Lisp, is does not suffer this whitespace problem/confusion. (- a b)

An infix language could also require whitespace around operators, so that a-b could be a an identifier. Like in a Lisp infix macro: (infix (a + b * c) / d). This kind of thing is quite habitable: we hardly lose sleep over (3.4) the list of one float versus (3 . 4) the dotted pair of integers.

We're discussing an infix language that does exactly that. In Pyret, binary operators must be surrounded by spaces. Therefore, `a-b` is not ambiguous.

Re: Pyret – A language exploring scripting and functional programming

#167

Post by semi-extrinsic » Thu, Dec 15, 2016, 10:40 PM UTC

jpolitz wrote: post #113

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

This paper ( http://cs.brown.edu/~sk/Publications/Papers/Published/fffkf-... ) linked from "Why Pyret" ( http://www.pyret.org/pyret-code/ ) is a long answer to "why teaching languages." It may also be useful to know that Pyret exists as part of a larger project and community. We're using Pyret to develop curricula for Bootstrap ( http://www.bootstrapworld.org/ ), which integrates computing curricula into existing mid…

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 that writing a working BASIC program made me learn stuff better and deeper and quicker than the homework I avoided.

I have a four-year-old now, and the other day she asked if I could count to a thousand million. I answered "Nope, but I'll show you Mr. Fortran, he can." Give kids a DO loop, some arrays and WRITE statements and they will conquer the world. For learning, it's hard to beat the simplicity of

    program count
    do i=1,1000000000
      if i % 1000000 == 0 then
        write(*,*) i," Million"
      end if
    end do
    end program

And I'm sorry to report, your examples don't convince me further of Pyret. (I'm a Python fan, BTW.) The docs you link for the "dead simple animation framework" assumes I understand templates; that's hardly dead simple. And while cloud integration is all cool for spreadsheets, if you did the same with Pandas in Python it would take no more lines of code, be no more complicated, but would start you on a tool that tons of people use for Real Work every day in a wide range of industries and sciences. Not just limited to interacting with half-baked Google Sheets data, you could read anything from HDF5 produced at CERN to SQL data from NASDAQ.

Re: Pyret – A language exploring scripting and functional programming

#168

Post by munificent » Thu, Dec 15, 2016, 10:42 PM UTC

jswrenn wrote: post #127

dom0 wrote: post #114

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

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

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.

Re: Pyret – A language exploring scripting and functional programming

#169

Post by skrishnamurthi » Thu, Dec 15, 2016, 10:44 PM UTC

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

Re: Pyret – A language exploring scripting and functional programming

#170

Post by skrishnamurthi » Thu, Dec 15, 2016, 10:46 PM UTC

eykanal wrote: post #2

So, as someone without too much experience in language development, the concept of having unit tests being an extension of the functions themselves seems very interesting. Clearly this doesn't work for all scenarios—multiple functions interacting, any sort of GUI interaction—but that's a very intriguing concept.

Actually, it does work for interaction if you program interactions Pyret-style, which effectively separate model from view. Models are updated functionally, so it's trivial to write tests for the model-updaters. Animations and games are obtained by having the underlying event loop infrastructure automatically compose these functions. This is the same methodology we use in Racket and in the Bootstrap curriculum [http://www.bootstrapworld.org/].