- 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.
Retiring Python as a Teaching Language
221–230 of 238 posts
Re: Retiring Python as a Teaching Language
#222Earlier 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…
Re: Retiring Python as a Teaching Language
#223Earlier 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 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
#224Re: Retiring Python as a Teaching Language
#225Earlier 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.
Re: Retiring Python as a Teaching Language
#226As 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…
Re: Retiring Python as a Teaching Language
#227As 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…
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
#228Earlier 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…
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
#229Earlier 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.
Re: Retiring Python as a Teaching Language
#230When 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…