251–260 of 272 posts
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"…
Earlier quoted context omitted.
> 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...
https://en.wikipedia.org/wiki/Shriram_Krishnamurthi
I think he knows the background of Racket quite well. ;-)
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"…
Teaching languages that are even modestly successful in that role tend to achieve significant use outside of teaching, as well, so that tends not to be true. Lots of languages that end up having broad general use are created with a minimum ore specific motivating use, and teaching is no less legitimate than any other motivating use. Pascal, for instance, was a teaching language, and it for quite a while had enormous industrial uptake.
Earlier quoted context omitted.
No. But whenever somebody says that to me, it's a bad sign...
https://cs.brown.edu/~sk/ https://en.wikipedia.org/wiki/Shriram_Krishnamurthi http://www.htdp.org I think he knows the background of Racket quite well. ;-)
That does explain why he came off as a bit defensive.
But then, so was I: Did I mention I'm not a CL fanatic?
Earlier quoted context omitted.
https://cs.brown.edu/~sk/ https://en.wikipedia.org/wiki/Shriram_Krishnamurthi http://www.htdp.org I think he knows the background of Racket quite well. ;-)
Ah, well. That does explain why he came off as a bit defensive. But then, so was I: Did I mention I'm not a CL fanatic?
The converted ones are usually the most fanatic.
Every time I see a project pop up touted as being simple and a good "teaching language", it has some weirdness or pet features thrown in that turns enough people off to keep adoption low. If you want a good teaching language which will receive substantial adoption, do this: * syntax-wise, use curlies and semicolons like C, Java, Perl, JS, etc. * use many of the good function names that Perl uses. * have all variables…
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?
For the language I described above:
* it's like JS but with warts removed
* it's like C or C++, but higher level
* it's like Java but doesn't require types or the JVM
* it's like Perl but without the context rules and other zaniness
* it's like Python but with better names, more familiar syntax, and better scoping
(It's even a little like Scheme but with more conventional syntax, and regular lists, maps, and sets.)
Students can use it in your class, then if they want to pursue programming in earnest, can very easily segue to any of those common languages above. Not only that:
* They can easily re-type their classwork programs in any of the above langs, and not feel like their teacher had them using something that was only applicable to their particular class.
* They can show their classwork programs to any JS/C/C++/Java/Perl/Python programmer and it will be easy for that person to make sense of what they're looking at (with no previous experience with the lang described above).
I have no experience with Pyret, and don't want to cast any judgement on it or the people working on it. Maybe it's great and will benefit students even when they move on from their class which uses it.
Every time I see a project pop up touted as being simple and a good "teaching language", it has some weirdness or pet features thrown in that turns enough people off to keep adoption low. If you want a good teaching language which will receive substantial adoption, do this: * syntax-wise, use curlies and semicolons like C, Java, Perl, JS, etc. * use many of the good function names that Perl uses. * have all variables…
A new language created: branchly
Seems like language implementors are like carpenters: once you're a skilled pro, you're not interested in making a plain simple bookshelf. It's got to have dovetail joints, beveled edges, countersunk fasteners with plugs over them, light sanding between multiple coats of finish... then it's great, but not affordable and I'm back to looking for a simple bookshelf.
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…
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.
Example from the OP: fun to-celsius(f): (f - 32) * (5 / 9) end What's the justification for allowing the use of hyphens/dashes in reference names, when underscores would seemingly provide the same purpose? One of the most common problems I notice in newbie code is inconsistency in using whitespace, e.g. `a-b` vs `a - b`, though in that situation, for Python and virtually every other language I've used, those both res…
Hyphens commonly are used to join words into compoubds in English, underscores are not; the latter are used in many programming languages as a result of the fact that not allowing hyphens to serve that role when they also serve as an operator in other contexts simplifies automated parsing (and allows syntax that supports more compact expressions, and there was a time when bytes of source code had a greater cost than they do now.)
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…
So, for a curriculum based on that basic approach that starts with the analytical methods and then adds concrete programming on top of it, the Pyret approach -- which requires and gives effect to elements of the analytical product that Python would not require and provides no convenient means to clean express that also gives it concrete effect -- is probably both simpler (as the two-way correspondence between code and analysis is better) and more productive.
It's probably not particularly useful to discuss the quality of a pedagogically-focussed language outside of the context of an approach to pedagogy.