jimwise

That's good advice on ncurses-based systems.

This is Solaris 10 (SysV curses, with a hand-imported xterm-color terminfo entry). :-)

For more on the "Functional Patters are Concurrency Patterns" idea, see Bob Harper's recent post on the subject:

https://existentialtype.wordpress.com/2011/03/17/parallelism...

(The whole blog is worth reading; Harper is basically giving a blow-by-blow as CMU rolls out it's new functional-programming-first CS curriculum.)

Haven't checked which color escapes (16 or 256) it actually supports, but it does do the xterm-color color escapes just fine. GNUS looks really nice, for instance. :-)

I'd been using touchterm for a while, and had experimented with other iOS ssh clients. They... worked, but the experience always felt a bit clunky.

I've been using prompt for a day now, and so far it feels better than the others. The app design feels really clean, the method of expanding the keyboard to handle modifier keys and frequently-used non-alpha keys works well without grabbing too much screen real estate (this is clearly visible in the screen shots for what it's worth).

Finally, the terminal emulation has been flawless for me so far. Emacs runs well (and is quite usable with Prompt's modifier key placement, unlike in other iOS ssh clients I'd tried; remember, folks, ESC is Meta, Meta is ESC). touchTerm had some screen lag/partial refresh issues for me with Emacs -- these may have been fixed in later versions, though, as I gave up at some point.

In short, I like it.

obDisclaimer: I don't know the developers. I don't have a dog in this fight. I do like the app. I'm not the only one who likes it though -- see the daringfireball take here:

http://daringfireball.net/linked/2011/04/14/prompt

Quite correct -- sorry for the confusion; I misremembered the quote's original attribution, and didn't catch my mistake when looking up the link.

I suspect that in another few decades, GLS will, with Alan Perlis, Don Knuth, and perhaps Edsger Dijkstra, begin to take on the CS equivalent to the pop cultural role now played by Mark Twain, Abraham Lincoln, and Ben Franklin -- a figure to which half-remembered quotes or anecdotes are routinely ascribed.

But that's no excuse for my own half-memory here. Thanks for the correction.

Actually, today's hardware, with multiple cores/CPUs clashing over shared memory through non-shared cache, is less friendly to mutability than the old systems.

Immutability does require different data structures; a (singly-linked) list is easy to make immutable in most cases -- many lists with the same tail part can share that tail, without copying when a new list starts sharing that tail. Arrays, not so much.

Yes and no -- closures are a tool to provide a behavioral view of state which is environmental in imperative languages. A closure is a set of state, presented as a function, with behavior provided by that function. In an immutable world, a closure can implement a setter which returns a new function closed over the new value.

Objects, on the other hand are... a tool to provide a behavioral view of state which is environmental in imperative languages. An object is set of state, presented as a data structure, with behavior provided by fields in that data structure (one view) or by the way in which functions taking that data structure as an argument dispatch on its type (another). In an immutable world, such an object would have methods which return a new object with some modification made.

Without some mechanism (these are two) to wrap up related state into a passable/returnable datum, its hard to talk about dealing with such state being made immutable.

In other words, I don't think there's anything particular to OO about the mutable/immutable point the article is making; the important distinction is between operations on data structures vs. operations on the environment. The article is thus too hung up on objects as somehow `different' when it comes to immutability, but I don't think they are.

As a side note, for an example of an OO language more recent than Smalltalk which favors objects with immutable operations, look at Scala or Ruby.

Per Guy L. Steele:

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures."

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.

From:

http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...

Interesting timing for me -- I've been working through "The Art of Prolog" (MIT Press, 1994) recently -- I'd done some Prolog in school, but never beyond the ``here are a few weeks in a programming languages course'', and the logic programming discussion in both SICP and ``The Reasoned Schemer'' had made me want to go back to the source.

I'm about 2/3 of the way through the book, and I highly recommend it to anyone looking to learn the language in a more or less rigorous way. It won't make you a production Prolog programmer (any more than SICP will make you a production Schemer), but it starts with a firm grounding in the theory of logic programming, and works that up to a good grounding in Prolog step by step, before spending the latter half of the book working through idiomatic Prolog solutions to a bunch of standard (once-standard?) problems (a shell, an interpreter, a compiler), as well as problems more in line with Prolog's traditional uses (ELIZA, an expert system).

The book is here:

    http://www.amazon.com/Art-Prolog-Second-Programming-Techniques/dp/0262193388

``The Craft of Prolog'', which this post mentions is in the same series, and provides somewhat of a more pragmatic view of the language. I may get to that next. Meanwhile, ``The Reasoned Schemer'' provides the entry of ``the Little Schemer'' series into the field of logic programming, using the MiniKanren logic programming system for Scheme.

Interesting bug in this example:

Since the AppleScript instructs the terminal to change _the current session_'s theme, if ssh exits while you're in another tab (say due to a disconnect), the tab which is currently frontmost will have its theme changed to 'Solarized Dark', while the tab you had run ssh in will stay as 'Solarized Light'.

Of course, this won't show up in testing -- and will be rather surprising when it does show up. :-)

How would you compare this product to the consumer-grade stuff Vuzix[1] makes?

[1] http://www.vuzix.com/consumer/

Right. This is why Ada, which has always paid special attention to the needs of embedded systems, provides so many guarantees about what program behaviors are and are not allowed to cause allocations or exceptions.

The upcoming Ada 2012 standard even includes versions of Ada 2005's collection classes which are allocation-free (read: pre-allocated to a size specified at creation time, and guaranteed not to perform allocation after that point).

Ada's generic programming was a big influence on Stepanov's design of what became the STL (the first versions were a port of work he had done under Ada). Ironically, the Ada standards process moved so slowly that by the time Ada grew standards-mandated generic collection classes (previously this was something all vendors provided as an extension), it had time to learn the lessons of STL.

(Not a knock on STL, by the way -- STL's implementors have learned a lot over the life of the standard as well.)

I think you mean `correlation is not causation'. Where there is causation, there certainly _is_ correlation.

In any case, are their any methodological problems with this study that you can point to? Any other studies you can point to that give a different result?

I'm also curious about your anecdotal evidence, which you seem to give more weight than this study. Do you routinely ask people you meet whether they were home schooled? Do the ``intelligent, thoughtful'' people you meet routinely come out and tell you that they are not home schooled?

Almost three percent of the current US student population is home schooled[1]. You've probably met a lot more home schoolers than you realize...

[1] Study (pdf) as of 2007 at

    http://www.nces.ed.gov/pubs2009/2009030.pdf

I'm curious whether you think home schooling favors the wealthy more than the public school system does? Recall that public school funding is a local affair; the wealthier the local population, the better funded the school.

I'm also not sure what you mean by `scaling issues'? Many districts here in New York State avereage 45-50 students per teacher. We have a large family by the national or local averages, and our five kids have one homeschooling parent all to themselves...

This doesn't mean that homeschooling is affordable for everyone -- especially given that every parent (and non-parent, for that matter) is paying (directly if they own, indirectly if they rent) for the public school system, whether they use it or not.

It's certainly no less AI than natural language processing is -- both seek to use algorithmic approaches to resolve the ambiguities in a bunch of input captured from fuzzy real-world sources, and build data structures representing that data -- as best understood by the program -- that can be manipulated by more traditional processing algorithms.

Neat example of how all aspects of the pharo dev environment are visible to the programming language.

Though as for actually counting LoC, I agree with Bill Gates that "Measuring programming progress by lines of code is like measuring aircraft building progress by weight." :-)

This is a better starting point for the politics of the situation:

http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2011-Januar...

That depends. Do those jeans make your ass look fat?

As with the website, that paper discusses only the speed of BCrypt. There is no cryptanalysis at all, and no indication that BCrypt was submitted anywhere for peer review of its cryptographic soundness.

This doesn't mean BCrypt is unsound. It does mean that I would want to see such analysis before using it.

The question is not whether BCrypt is backed by Blowfish, the question is whether BCrypt uses Blowfish in a way which is cryptographically sound. If it does not, then an attacker may not need to use brute force. Assuming the author has read more of Mr. Schneier's book than the quoted preamble, he should know this -- Schneier discusses this at length in both editions of Applied Cryptography.

Again, an example of this is the 3DES encrypt/decrypt/encrypt process vs. a more naive encrypt/encrypt/encrypt process. One is substantially stronger than the other. One is a secure way to use DES, and one is not.

I'm not so sure. The other side of the coin is that ``{MD5, SHA1, SHA256, SHA512, SHA-3, etc}'' have had extensive peer review in the cryptography world.

There's a long history of ``clever new ways'' to use existing crypto algorithms turning out to have serious flaws -- a good example is early attempts to improve the strength of (56-bit key) DES by encrypting three times with three keys. This turns out to introduce enough non-randomness to make the result much weaker than one might expect; standard 3DES works by encrypting with the first key, decrypting with the second, and encrypting with the third, which results in very different properties of the output cyphertext.

I'm not saying BCrypt has the same sort of issues, but I'd like to see some cryptanalysis of this before trusting my users' data with it. Notably, there seems to be no links to such analysis on the BCrypt home page -- not even an argument from the author as to why this code should be cryptographically sound.

You mean other than that it's a tool used to launch DDoS attacks?

Joke aside, Host: is optional in HTTP/1.0 (it's mandatory in HTTP/1.1). I would not be surprised if blocking on this cut out some set of proxies and spiders out there as well (whether these are customers you can't afford to block is another question).

Any advice on what a hacker needs to know about getting busted by the swedes?

NetBSD too, FWIW:

http://ftp.netbsd.org/pub/NetBSD/misc/repositories/git/autho...

Flagged. Calling Assange a "homeless beggar who wants to take a shit on your carpet" adds nothing at all to the debate.

Amazon has every right to turn WL away. That they chose to do so is, IMO, unfortunate, for the reasons laid out here:

http://www.eff.org/deeplinks/2010/12/amazon-and-wikileaks-fi...

but that's their choice to make.

And if people who wish Amazon had done otherwise want to spend their dollars elsewhere, well, that's their choice to make, too.

Note that this experiment (balancing an inverted pendulum, then moving on to balancing an articulated inverted pendulum) is one of the examples from the original Papert LOGO papers of neat robotics problems which grade schoolers can understand and start working on (using the LOGO turtle or similar), but which can be refined as far as the student wishes to take it.

Like running sshd on another port (to stay on topic), it doesn't make the service more secure against someone who knows it's there, but it makes it less visible to automated scripts probing the standard location for known bugs.

Agreed. There's something slightly condescending about the book -- about an adult trying to think of awesome `childlike' things, and only coming up with outlandishness.

I've tried encouraging my children to remember and write down their dreams, and my impression (they might disagree!) is that the ones which struck them the most are those which were unlike reality in some small, but important way; not those which were simply bizarre.

Which is why API or other names with 'new' in them are a bad idea. :-)

All of which is a workaround for the fact that there is no explicit way to declare a c++ class to be abstract-only.

What happens if you do have shared logic to put in the abstract base class's destructor? It can't be pure virtual, and you're back to being able to instantiate your 'abstract' base class...