Fixnum

On the other hand, the burden of proof is on the library writer who creates the typeclass instance, not on the end user - possible largely thanks to purity - whereas programmers may expect to re-implement various patterns by hand.

It could be related to StackOverflow displaying "Hot Network Questions" in a sidebar, some of which are from the aviation StackExchange, combined with the usual phenomenon of upvoted stories attracting similar submissions.

Incidentally, I find this sidebar extremely distracting; maybe it's time for a plugin/script to fix it.

Julia seems nice, but the fact that the developers don't care about TCO is annoying and vaguely reminiscent of Python. If this were added, not only would many algorithms become more natural to express, but it'd go to the top of my list as a recommended first language (instead of Scheme or Lua).

It's being fixed.

http://www.reddit.com/r/haskell/comments/1rpte3/explanation_...

They're not similar at all. FoCS is mostly about introductory programming and data structures (with a tiny bit about automata). Sipser's book is about computation and complexity - it's comparable to Hopcroft and Ullman's Intro to automata theory, languages, and computation, for which Ullman recommends FoCS or equivalent as a prerequisite.

Actually, Scheme is more accessible than ever before. If installing MIT Scheme and Edwin/Emacs is too difficult, now there's Racket-SICP, which allows you to program with DrRacket, a beginner-friendly graphical IDE, and actually comes with implementations of some parts of SICP that MIT Scheme omitted, like the picture language and (afaik) some concurrency primitives.

Is Scheme really decreasing in usage? Sure, in recent years there have been high-profile moves to Python at MIT and UCB, but I don't know of any hard stats on worldwide Scheme usage. Not that it matters.

For one thing, you generate as few as possible by aggressively fusing away intermediate lists (at least if your language is pure).

Also, the garbage collector will often move lists into contiguous region(s) of memory.

More to the point, though, sometimes a list is the appropriate data structure for a problem (like returning all intermediate results from the Collatz call, where you don't know how many there will be). Sure, you could use an array and double its size every now and then, but you're doing an awful lot of violence to your program just to handle something the runtime could take care of for you :)

And yes, I know there will be a slight performance penalty under many circumstances.

The point is you're supposed to use truly random word combinations since those are at least memorable.

  $ wc -l /usr/share/dict/words
  119095
  $ python -c 'print(119095 ** 4)'
  201175048646341950625
  $ python -c 'print(85 ** 10)'
  19687440434072265625

So, even if your target is known to be using this scheme in pure form, this has more entropy than a completely random 10-digit password (assuming ~85 characters) -- and who would actually be using such a thing, except someone using a password management program - who could just as easily be using a 20-character random password?

So even if it becomes known, it's an improvement on what users are doing now.

DARPA is trying it:

http://www.crash-safe.org/node/9

For imperative languages, the most popular approach to formal proof is to add partial correctness annotations in an axiomatic semantics such as Hoare logic. I've heard that Microsoft does this to verify many properties of the Windows kernel. (I think the most popular tools are 3rd-party and proprietary at the moment.) Of course, finding the right theorems to write down is not easy either.

There's currently an attempt to formalize a subset of C, with an axiomatic semantics, all the way from specification down to machine language: http://vst.cs.princeton.edu/

I think Vidarh's point is that the US has a long history of manipulating and overthrowing democratically elected governments, a practice certainly made easier when the CIA or NSA have access to the complete communications of the politicians (or candidates). That's certainly an 'existential threat to democracy', just not the one you vote in (with some nominal power to exercise 'oversight' over such agencies).

Something like http://scratch.mit.edu/ ?

Out of curiosity, what's wrong with Unison?

I was involved in marking a standardized test for high school students and one question involved inventing a story on an (unspecified) election. What shocked me the most, aside from the poor writing ability, the unintentionally unbelievable facts of the stories, and the surprising amount of confusion and internal contradiction within the students' responses, was that although remarkably few students demonstrated much awareness of politics or the political process, despite having taken a mandatory course on this subject, nearly all of the students regarded voting as a mystical or near-spiritual experience of civic involvement, social communion, and individual empowerment.

Some students were probably 'sucking up'. But nearly every student?

Google didn't exactly invent the self-driving car - they basically bought the Stanford team and some people from CMU and elsewhere.

It's funny you mention these two books in the same comment, since I always assumed Landau was one of the targets of Sussman and Wisdom's comment, "It is surprisingly easy to get the right answer with unclear and informal symbol manipulation." (See their paper, Functional differential geometry.) Sussman/Wisdom's book is, from a brief look, not 'rigorous' either, but the 'symbol manipulations' in Landau/Lifschitz's series are sometimes borderline insane!

The soon-to-be-released GHC 7.8 (Haskell) can defer type errors until runtime to allow you run your program even if part of it is broken, and you can also add "holes" in place of an arbitrary expression and the compiler will tell you the type of the expression you need to replace it with (of course, this will explode if run). I suspect GHC's error messages are better than Ocaml's as well.

> I'd concentrate first on building internally consistent mental models.

I strongly agree -- and the Lisp/REPL combination is extremely helpful. Specifically, I believe a Scheme-based approach is the best way to learn programming, even if you eventually decide to migrate to something less fortunate like Javascript or Python ... in under an hour from your first exposure you can be thinking about stuff rather than the syntax of loops. I won't attempt to justify the pedagogical reasons for this choice here.

Specifically, I'd recommend (1) using Racket, a "batteries-included" Scheme derivative with a simple IDE/debugger, and either (2) Concrete Abstractions (free at https://gustavus.edu/+max/concrete-abstractions-annotated-to...), or (3) the upcoming book Realm of Racket (coming in May), which will cover some of the same CS 101 material as well as GUI and distributed programming via writing games in Racket. (There is an earlier book called Land of Lisp but I feel its environment (CLISP) and coding practices are rather baroque.)

Depending on your student's interests you could simultaneously look at some web programming (plenty of HTML/CSS material is available from Mozilla, Google, etc.; there's an upcoming Udacity course on HTML5 game programming), lower-level stuff like assembly, arduino, or whatever.

Hope this helps.

A number of relevant disclosures are listed at http://www.salon.com/2010/12/24/wikileaks_23/ .

I don't know how one could argue that, e.g., releasing cables showing the Afghanistan war is "unwinnable" (a la Daniel Ellsberg), showing the deep hypocrisy and corruption of many governments (e.g., the Saudi rulership), and the bullying of all sorts of governments into falling in line with American military and economic interests isn't a "good".

If there haven't been any visible policy changes by the US government, then perhaps it's because such a change is not easily to connect directly to Wikileaks. Of course, it could be that Robert Gates is correct in saying claiming that consequences for US foreign policy (from the leaked diplomatic cables) have been "modest". If true, that is unfortunate, but surely not the fault of Wikileaks?

Roughly speaking, CPUs are highly optimized for sequential execution, with long pipelines, high power consumption, and complex implementations of arithmetic/logic instructions (I'm not an expert, but I _believe_ these are much _better_ than on GPUs, except possibly for certain graphics-related GPU primitives), but relatively few threads. GPUs are optimized for parallel execution, and run many more threads than CPUs, each with higher latency, but nonetheless with higher overall throughput.

Yet Google still has a reputation for very selective hiring ... is that because most of the hiring decision isn't interview-related (degree/GPA/projects/resume)? Or is it that, while the data structures/algorithms questions might not be too hard, it's possible that the interviews are still difficult, due perhaps to a degree of randomness, or to high standards (candidate is IO-bound not compute-bound, never makes a mistake, uses of axiomatic semantics to prove correctness as she writes...)?

The idea of a nation-state considering itself bound by the GPL is absurd.

Only users can keep themselves safe -- developers can't.

Until recently, Haskell didn't have an equivalent to Erlang's built-in support for distributed computing, but the new Cloud Haskell library (http://www.haskell.org/haskellwiki/Cloud_Haskell) provides message-passing concurrency with a semantics very close to that of Erlang (but with more support for type-safety).

I'm not sure Cloud Haskell is ready to dethrone Erlang (and the OTP framework, and tooling for debugging distributed processes, and special VM features, ...) for high-reliability distributed computing today, but Haskell and its libraries are evolving with absurd speed and the Cloud Haskell ecosystem could certainly be competitive with Erlang in the near future. Haskell can certainly be used to write high-performance network applications (e.g., Mighttpd, Warp), so it's surely only a matter of time ...

Unfortunately, it's only the first 95 pages.

> Is there a language, like Latin, that can help form the basis for understanding other languages and make learning easier?

As inetsee says, Scheme is this. It will provide you with a firm basis for actually understanding how programs execute. (Theoretically, learning C will also do this, but if you want to come from that direction I recommend learning some assembly language instead, since the semantics of C are surprisingly complex). Stretching the analogy rather dangerously, Scheme is as relevant to the past, present and future of other languages as Latin (though this is a conceptual rather than historical truth), as pedagogical/minimalist as Esperanto, and as expressive as English.

Also, if you find HtDP too tame or SICP too challenging (certainly possible unless you have a science/math background, though most parts requiring specific knowledge are optional), try Concrete Abstractions (http://gustavus.edu/+max/concrete-abstractions.html).

Be careful -- this doesn't fully memoize recursive functions unless you force the computation of intermediate results, since the recursive calls don't use memoization:

(define memo-fib (memoize fib)) ;; example from SICP (memo-fib 40) ;; long wait

I would love to see a good general-purpose 'memoize but rather doubt it's possible, though I think I remember seeing one in Common Lisp in "Paradigms of Artificial Intelligence Programming" that exploited CL's weird namespacing rules for functions to make recursive functions like 'fib run fast.

I see what you're saying about the quiz questions every few minutes.

On the other hand, she's not arguing for limiting ourselves to video lectures. Her point (see page 2) is that class time is precious and shouldn't be wasted on lecturing but on problem solving, critical thinking, and discussion, and this I totally agree with. (Why is it taking institutions so long to figure this out?)

I assume the article is referring to Fermi-Dirac statistics [1], not the Dirac equation.

That said, the Dirac equation (or relativistic QM more generally) as well as the Feynman path integral (the idea of which originated from a 1933 paper of Dirac) are pretty indispensable in modern condensed matter physics.

[1] https://secure.wikimedia.org/wikipedia/en/wiki/Fermi%E2%80%9...

I think Scheme comes the closest to being an ideal teaching language. It has all the same advantages adduced (great books, simplicity, power) in even greater measure. For instance, there's no 'funcall, 'apply, and sharp-quoting everywhere, and no powerful but baroque object and package systems deeply integrated into the language. Scheme macros are a bit complicated (especially implementation-wise) but can be sugared over (e.g. define-syntax-rule or CL-like syntax for basic macros) and at least they're "correct".

Scheme isn't perfect, of course, and I'd love to see a modern Scheme-like Lisp with a canonical implementation and borrowing freely from Haskell, Erlang, and friends while preserving its minimalist ethos (somehow neither Racket nor Clojure is this).

Of course, the readiness is all ... while there's a beauty in simplicity, can a novice without any higher mathematics really appreciate the style of programming one does in Scheme?

> tail-call recursion is almost inconsequential---this is a very introductory course, just an overview of CS, so performance isn't important.

> What is important are the big ideas.

Go back and read section 1.2 ("Procedures and the processes they generate") again. As far as its authors are concerned, this is one of the big ideas. Basic concepts of time and space complexity and recursive vs. iterative processes are so important that they appear as soon as the basics of Scheme have been introduced. It's a core theme of the book (Why is this n-queens program slow? How can we eliminate two extra stack saves in this register machine program?), and the main questions in chapter 5 that the evaluators in chapter 4 don't answer fully (but look closely at the CPS evaluator in section 4.3) are "how do procedures return values to their callers?" and the related "how can we write an evaluator that doesn't grow the stack when executing tail-recursive procedures?"

Ultimately, the beauty of SICP isn't in the paradigms covered but the understanding of how programs execute, and the beauty of Scheme is the simpleness of its control flow . It's far easier to a understand Scheme program than one written in Python, Haskell, Prolog, or any other high-level language. Do most people understand (modulo sophisticated optimizations) how the Python interpreter actually handles, say, comprehensions, iterators, generators, or its complex object-oriented features? Can a first-year student add these features by hand (forgetting completely about macros and first-class continuations) to an interpreter herself?

It amazes me that Berkeley professors don't want to teach Scheme (and worries me, as they're much cleverer than me). The whole magic of the language is that in the end there isn't any magic at all.