Live data from Hacker News

Retiring Python as a Teaching Language

prog21.dadgum.com

221–230 of 238 posts

Re: Retiring Python as a Teaching Language

#221

- No memory management - No pointers - No cache - No branch predictor - No interrupts - No endianness - No alignment What exactly are we teaching students to program? It's certainly not a computer.

Turing machines don't have any of those things either, and they are certainly computers. Universal ones, in fact

Re: Retiring Python as a Teaching Language

#222

Earlier quoted context omitted.

In case anyone hasn't heard of it, Asm.JS is basically trying to turn JavaScript into a similar standard. Combine that with sourcemaps in browser debugger tools and we're really close. I've been using clojurescript recently, and I can even connect a REPL to the browser and make on-the-fly changes just like we've always been able to do with JavaScript.

What I really wish someone would build is this: Create a platform-independent machine language which is designed to be translated into arbitrary other machine languages. Then put the equivalent of FX!32[1] in the browser to translate it to whatever architecture the client is running on. And have a compiler that will compile to both that and to asm.js, with asm.js being used (with consequent lower performance) for leg…

This is known as UNCOL, and many attempts at it have been made, dating back to the 1960s.

Re: Retiring Python as a Teaching Language

#223
post #219
post #11

Earlier quoted context omitted.

> It's a common reaction displayed by the proponent base of many languages, even here on HN, to advocate the use of their language for every conceivable need. This can't possibly work well. Is that some law of nature, or merely a consequence in how we've designed languages thus far? A well designed type-infered statically typed language with a REPL/interpreter, a fast AOT compiler, an optional GC, good documentation…

A well-designed type-inferred statically-typed language either cannot support the following (which is valid Python), or can only do so with tradeoffs that either stretch the definition of "statically-typed", stretch the definition of "well-designed", or would make the language even more intimidating than monads make Haskell: def fizzbuzz(i): if i % 3 == 0: return "fizz" else if i % 5 == 0: return "buzz" else: return…

>A well-designed type-inferred statically-typed language either cannot support the following (which is valid Python), or can only do so with tradeoffs that either stretch the definition of "statically-typed", stretch the definition of "well-designed", or would make the language even more intimidating than monads make Haskell

A statically typed language can still have a generic type. C# for example has dynamic: https://msdn.microsoft.com/en-us/library/dd264736.aspx, and Objective-C has id.

You get static types whenever you need them and dynamic flexibility whenever you need it. No need to invoke something Haskelly at all.

For more type checking safety in this particular case, you could also say (or infer) that the return type is a union that's either "String | Integer".

I was talking about a possible very flexible uber-language here. Why would it miss those two oldest tricks in the book, that are already present in tons of existing languages?

That said, I didn't say it would have to express all idioms. Just that it would be applicable for as many domains as possible, from low (drivers, etc), to high (scripting, etc).

This particular idiom, as you also note, I don't find particular useful anyway, but rather a code smell. But if it was needed the two ways described above could solve it without much issue.

When you need to be quick and flexible use "dynamic" type, when you want to be fast and safe and take little memory switch it to a specific type. The language still covers both cases.

Re: Retiring Python as a Teaching Language

#225
post #180

Earlier quoted context omitted.

Home computers used to boot to a BASIC interpreter. To do anything you needed to use a little bit of BASIC. Looking at HN threads we see many people who claim this one thing created very many programmers. But back when it was happening we had teachers giving remedial classes to force BASIC users to "unlearn" bad habits. (There's probably a "BASIC considered harmful" somewhere). What language would you recommend for 8…

I agree with the article that JavaScript is a good choice. Nothing to install. No way (or there should be no way) to accidentally wipe the disk. Easy to share your code. Now, JavaScript certainly has some ugly parts, but the difference between it and the old-school BASICs is that it's possible (with care) to avoid most of the ugly parts in JavaScript. That wasn't possible with BASIC.

I totally agree but when they what to use the disk it requires NodeJs or similar and then you can wipe the disk again. But it easy to start safe.

Re: Retiring Python as a Teaching Language

#226

As much as i can't disagree with the choice (the realpolitik of programming has made it the most correct choice), i am saddened that the language on which the choice falls is one not chosen based on any merit, but merely due the historical accident of being the first to be implemented in a browser and having had no appreciable opposition due to browsers at the time being in hands of corporations. In "A Deepness on th…

It's not just the browser, people often want to create mobile apps today and there is no standard language that works for all platforms (you can try C# with Xamarin but it is not the native choice of all the platforms). And there is not always good, still developed, standardized UI libraries for every language. Many people starting with programming want to see something on the screen and then you need this. And there is usually some people who wan't to develop serverside web code which should be supported by the same language. If Xamarin was open source or free I think it with C# would be a great way to start programming. For now Javascript works.

Re: Retiring Python as a Teaching Language

#227

As much as i can't disagree with the choice (the realpolitik of programming has made it the most correct choice), i am saddened that the language on which the choice falls is one not chosen based on any merit, but merely due the historical accident of being the first to be implemented in a browser and having had no appreciable opposition due to browsers at the time being in hands of corporations. In "A Deepness on th…

It's not just the browser, people often want to create mobile apps today and there is no standard language that works for all platforms (you can try C# with Xamarin but it is not the native choice of all the platforms). And there is not always good, still developed, standardized UI libraries for every language. Many people starting with programming want to see something on the screen and then you need this. And there…

re: if open source

Free for open source () => http://resources.xamarin.com/open-source-contributor.html

re: if free

Free for students () => https://xamarin.com/student

re: if cheaper

So $25/month is too much for capability to ship on all three mobile platforms - native development - using a shared codebase written in one of the nicest languages (F#/C#) in existence? If you're a startup w/ at least three people in your team just send them a email to work something your in your favour.

Re: Retiring Python as a Teaching Language

#228
post #219
post #11

Earlier quoted context omitted.

> It's a common reaction displayed by the proponent base of many languages, even here on HN, to advocate the use of their language for every conceivable need. This can't possibly work well. Is that some law of nature, or merely a consequence in how we've designed languages thus far? A well designed type-infered statically typed language with a REPL/interpreter, a fast AOT compiler, an optional GC, good documentation…

A well-designed type-inferred statically-typed language either cannot support the following (which is valid Python), or can only do so with tradeoffs that either stretch the definition of "statically-typed", stretch the definition of "well-designed", or would make the language even more intimidating than monads make Haskell: def fizzbuzz(i): if i % 3 == 0: return "fizz" else if i % 5 == 0: return "buzz" else: return…

I'm not sure what your complaint is.

    import Control.Monad (forM_)
    
    fizzbuzz i | i `mod` 3 == 0 = Left "fizz"
               | i `mod` 5 == 0 = Left "buzz"
               | otherwise      = Right i
    
    main = forM_ [1..100] (\i -> either putStrLn print (fizzbuzz i))

Re: Retiring Python as a Teaching Language

#229

Earlier quoted context omitted.

I agree with the article that JavaScript is a good choice. Nothing to install. No way (or there should be no way) to accidentally wipe the disk. Easy to share your code. Now, JavaScript certainly has some ugly parts, but the difference between it and the old-school BASICs is that it's possible (with care) to avoid most of the ugly parts in JavaScript. That wasn't possible with BASIC.

I totally agree but when they what to use the disk it requires NodeJs or similar and then you can wipe the disk again. But it easy to start safe.

If you just want to persist data between sessions, you can do quite a bit with HTML5 localStorage.

Re: Retiring Python as a Teaching Language

#230

When I took an introduction to Computer Science in college, it was taught in Racket. Over winter break, I then learned Python, and I was baffled -- why would any curriculum not start with Python? Python was easy, expressive, and allowed the user to get lots done with little effort. It was great at motivating programming by showing its use and power. It seemed like an ideal introductory language. Over the last few yea…

I agree with everything you said about what makes racket a great fundamentals class, but I think you left out a key advantage. Most people haven't seen racket. Kids who took some basic CS course beforehand, but have to take the college introductory course, are practically level with kids who haven't seen anything.
Post reply on HN