mgreenbe

Proof-carrying code is a fine idea, but the proofs for JS programs get into subtle security ideas, confidentiality and integrity being the big two. Information-flow type systems can address this, but I'm not sure I would call them production ready.

Moreover, Javascript is already a very low bar to set in terms of security, and there are still serious compatibility issues between implementations.

Finally, the fact that the web is human-readable is a boon. Who will standardize the bytecode representation? Our benevolent Macromedia/Adobe overlords? Microsoft? The W3C?

This is great. Computation exists outside of computers, and this seems like a great approach to highlight that idea. I only read http://csunplugged.com/~csunplug/programming-languages-0, but it gives a pretty good summary of the basic issues involved with programming a computer. The ideas are relevant and interesting, and the absence of an actual computer is barely noticed.

Agreed. The mainstream parties today are so overloaded that I suspect noone fits their stereotypes completely. The amount of finger-pointing and name-calling attributable to this sort of misconception is unfathomable, and I think it's one of the most serious problems in American politics.

I wasn't thinking of callbacks, but rather of the generic plumbing for, e.g., GUI elements that contain other GUI elements. And I never suggested it was necessary, only useful: it's nice to have Button be a type, but it's also nice to have addToWindow take any Element. There are GUI systems that don't do this---the DOM, for example---but they have their own warts.

I don't follow the last two sentences.

Why ask this question about Java in particular? I think the real question is whether inheritance is useful in nominal type systems with objects and interfaces.

And I think the real answer is yes. Inheritance is very nice in the API for GUIs. I've never seen the idea applied usefully elsewhere, though I'm sure there are examples.

  Matlab does have a lot of great features like ... clean syntax

Are we talking about the same Matlab? The one where you get one function per file?

Can someone in the know add more detail, i.e., is any of this due to proprietary algorithms, or is this a question of implementation and tuning? Why is R faster in a few cases?

Is there something in the setting described not resolved by (the dictionary-passing implementation of) typeclasses? The modeling problem described seems more like the problem of modeling "top levels" in general than generic functions in particular.

MVC never made a great deal of sense to me, in that I've never really seen a system that entirely embodies what's described. Nevertheless, programming Javascript is tough because it's easy to confuse the DOM---the view---with the client-side model. When updates can come from the server or the view, maintaining the client side model is quite difficult.

Plug: Flapjax <http://flapjax-lang.org/>; helps with this a bit. My own thesis work used Flapjax to prototype an even more robust system.

Seriously. Anonymous functions without a sane lexical system is asking for trouble, though marking closure variables will mitigate the problems a little.

I agree that PHP's house is on fire, but PHP has such a big house that I'm not sure it's noticed yet.

Having slowly switched to a (nearly) completely DIY diet over the past six years, I've lost about 25 or 30 pounds, though I have a small frame (5'10") and was never particularly heavy to begin with (170lb or so down to 145lb). Food you make yourself certainly tastes better---most prepared food I've tried has been full of rancid oils and musty, stale flavors.

Nevertheless, I'm hesitant to blame prepared foods as a genre. I think the real problem is a lack of consciousness, where people habitually overeat rich foods. Some of my coworkers have sizable portions of meat and cheese at nearly every meal---I don't know how they do it!

Of course programming languages involve trade-offs. Concrete syntax trade-offs abound, but more important are semantic trade-offs. Many are of the form feature vs. performance. Dispatch? Memory safety? Laziness? Otherss are more complicated, like those involving type systems, which are formally complex while affecting the informal "feel" of the language.

I think it's specious to suggest that the problems in programming language design and implementation are illusionary, and that we could somehow code "the way would we [sic] like". The language of computation is extremely subtle, and the process of building abstractions over our computers' basic operations is still more subtle. We are not done exploring possibilities---nor, I suspect, will we ever be.

It is an object lesson in concrete syntax design. This result probably won't be of interest to Perl hackers for precisely that reason.

I didn't mean to snipe: the "funny" I'm using is in a "cite original sources" mode, which has little/nothing to do with the non-academic world. :)

  Recursive subroutines that concatenate/sum to a global 
  variable or a carry-along output variable

Wow...I didn't see this in the article. That is downright boneheaded. Is accumulator-passing style forbidden for a reason? It's a cheap way to make functions tail-recursive---much cheaper than CPS!

First, I don't buy the post's statistics. 65% of the subjects administered every shock in the experiment. But

  when we believe that someone knows more than us about a 
  subject, they can get us to do what they want most of the 
  time (or 65% of the time if you can believe the experiment)

mis-parses the probabilities.

Second, I think the "(65% of) people obey to authority despite what should be their better judgment" overfits the results of the experiment. Perhaps people simply listen to scientists during experiments?

When someone points out in a comment that this could be seen as verbal nitpicking, he responds well:

  ...the issue arises because there are the people who 
  understand and use the terms interchangeably, relying on 
  other readers to be like themselves and understand in 
  context of the communication.

  However it's the people who don't understand the 
  differences that the clarification is needed, and they 
  run into trouble, or start making 1/2 correct inferences 
  and mis-communicating to others.

  It pays to be precise, and when in the habit of using the 
  correct terminology, comprehension becomes easier for all 
  parties.

This is very, very true. Particularly when dealing with artifacts as subtle as programming languages, where, e.g., 'type' and 'class' shouldn't be used interchangeably. The problem is bad enough when dealing with core calculi---as this post demonstrates, being precise is doubly important when dealing with feature-rich languages, like C#.

It's not clogged from the machine's perspective, but the user's. The problem is cleanly maintaining a computer with a registry that's gone through hundreds of OS updates and driver/application installs and uninstalls.

I'm happy to see you agree, but---to play devil's advocate against my own belief/desire---consider the following Mad Lib:

An online reference crosslinking lay and expert knowledge would be an excellent resource, is technically achievable, and would further the worthwhile (in my judgment) goal of undoing the guild-like control over [PROFESSION (adj.)] knowledge once held by the [SAME PROFESSION (pl. n.)].

Are there professions about which this doesn't fit? For example, is WebMD satisfactory for medicine? More to the point, this doesn't really exist for computer science, the first field you'd expect to have it. What do you (and others) think the barriers are? Unwilling/absent expert users? Lack of incentives?

IANAL, but I totally agree---algorithmic law is a frightful prospect indeed, not to mention totally untrue to our legal tradition.

The second point the article makes is a good one, though. Lexis-Nexis and Westlaw are useful tools, but they are neither free nor particularly easy to navigate. A hypertext version of the law, organized hierarchically and cross-linked with explanations for lay people as well as expert opinions, would be invaluable. A "Legapedia", if you will---or "Nomopedia", if you're not the sort to mix Latin and Greek. :)

It's funny to see Haskell and TDD mentioned without QuickCheck http://www.haskell.org/haskellwiki/Introduction_to_QuickChec....

But, yes: referential transparency and functional (rather than sequential) composition make for a different refactoring model, one where eta expansion/contraction is the norm.

He does leave out the opportunity for more fluid refactorings: the lenPreviousLines function could be refactored in a more conventional way (changing the foldr of ((+).length) to a sum---which is a foldl---of a map, for example).

This is one of my favorite optimizations. It is excellent argument in favor of purity restrictions, too. I didn't know there was a way to instrument the compiler---neat!

Absolutely. My early programming courses all had code-writing on the written exams, all in Scheme. (I think Scheme is particularly well-suited to paper, though, because of its minimal syntax and its "general recursion for everything" approach.)

Programming on a computer---particularly in a REPL language like Scheme---tempts one to "just run it". Writing a program on paper requires reflection and planning: good skills, I think.

A little bit of a tease:

  Unfortunately, the right way to deal with the ego dilemma 
  is tricky and complex and deserves an entire post of it’s 
  own. It really involves revamping your entire belief 
  structure into something deeply probabilistic with a much 
  finer and more nuanced representation of ignorance which 
  I promise to write at a later date when I’ve fully 
  processed what I’m actually doing.

But still, http://en.wikipedia.org/wiki/Know_thyself is always good advice.

I agree heartily. Native speakers who are willing to correct you---and not default to some better, common language---are the best resource possible.

I've been in a few immersion programs, and they're all okay. The best I've seen was ulpan, in Israel. Recent immigrants are thrown together and taught Hebrew; since they don't necessarily have a common language, their medium of communication must be Hebrew. Since you're all learning together, mistakes are less embarrassing.

In all, nothing beats being there: you have to go somewhere the language is spoken and force yourself to be a part of it.

Already been posted: http://news.ycombinator.com/item?id=578632

I think his point is more subtle than that. Informal paper math doesn't always neatly line up with formal, computer-processed math---such as numerical processing or theorem proving. This disconnect can be extremely frustrating: I want to believe paper proofs, but simply writing down the theorem statement in a rigorous way can require significant changes. It's the frustration of understanding something on the surface but then realizing that in fact it makes no sense.

It's standard procedure in academia---in CS, at the very least---to notify the people you're correcting in advance. This ensures that they (a) know about the problem, (b) are aware of your efforts and can comment directly to you, and (c) can participate in the discussion that ensues when you publish.

Take it up with Dijkstra. I learned QBasic at around the same age, as well, and I don't feel impaired either---though Scheme certainly changed things at around age 14. I'm sure he was talking about Other People.

I'm surprised to see that it doesn't mention's Dijkstra's aphorism:

  It is practically impossible to teach good programming to 
  students that have had a prior exposure to BASIC: as 
  potential programmers they are mentally mutilated beyond 
  hope of regeneration.

http://www.cs.virginia.edu/~evans/cs655-S00/readings/ewd498....

Wait...you're telling me techne and episteme aren't the same? And that it's hard to reconcile craft and science using the tools of science alone? Whatever will we do?

As a fun aside, Connell's misunderstanding of the Church-Turing thesis is cute (though perhaps a little insulting to all of those computer architecture researchers in CS departments!). "All computing hardware is equivalent". I see -- I didn't realize that my 8bit 2-register CPU with 4KB of memory can do anything my 64bit 32-register CPU with 4GB of memory can do. But of course it can, because the lambda calculus can express any effectively computable function. Right, I see that now.