mgreenbe

Scheme's dynamic-wind is a rather general form of this; PLT documents it pretty well http://download.plt-scheme.org/doc/103p1/html/mzscheme/node8... . It's designed for use with funny control structures, like continuations, so that should sit well with Ruby types.

I must confess, I had no idea what the combinators had to do with the Ruby. "It looks a little different than the combinatorial version" is a bit of an understatement. And real men program with nothing but X.

EDITED: to fix a link and add a note about continuations.

Is your multicore webserver embedded? If not, I'm not sure this is for you.

  The embedded processor chip in mobile phones is small and
  not very powerful, so machine learning is more applicable
  to use in these devices in order to make the chip more
  energy efficient and powerful. (http://www.milepost.eu/resources.html)

More explanation is available here: http://ctuning.org/wiki/index.php/CTools:MilepostFramework. The chart should give you a basic idea of their architecture: they dynamically instrument runs of your programs under different optimization to find optimal settings for your release build.

Idempotency is a property of mathematical functions: f : X -> X is idempotent iff f(f(x)) = f(x) for all x in X. Absolute value is an example of an idempotent function.

Reentrancy is a property of computational functions: a function f is reentrant if two copies of f can run at the same time (in the same memory space, etc. -- the details vary) and both copies behave as if the other weren't running. This can exclude or restrict, e.g. static fields or global variables.

RE and FSM are equivalent. There are no problems handled better by regular expression than by FSM. Of course, this is for a very narrow definition of problem. And, by most accounts, a narrow definition of FSM. SCM calls its systems FSMs even though they have stacks. Sure, the number of programmer defined states is finite, but the number of system states is infinite. Also, what do you mean by better? :)

So, for an un-specious response: FSMs are well suited to stream processing, while REs do well with block processing. (And are generally implemented by compilation into FSMs, anyway.) FSMs also do well as program logic/control structures, often clarifying the underlying system.

SMC also seems more robust. If you look in the examples section of the manual, they describe an "FSM" that can identify palindromes on the alphabet { '0', '1', 'c' }, where 'c' indicates the center. This is not a regular language -- SMC has a stack.

<http://www.cs.brown.edu/~sk/Publications/Talks/SwineBeforePe...; is a fun talk that describes an implementation of state machines in Scheme macros. With a good compiler, those tail calls will be translated to local branches!

This notion of "analogy" is formalized in category theory. At times this is done to great effect --- the generalizing power of category theory can help a mathematician see the forest for the trees. This has been done to great effect, e.g., in programming language theory. Then again, at times category theory is shallow, nothing more than abstract nonsense. (N.B. this is a technical term.)

The strict formalist in me likes category theory because it has so many names for things, many of which are in Greek. The intuitionist in me thinks the field is pointless but likes drawings with arrows in them. All in all, it's a win-win. :)

Does Scala perform deforestation? If not, then separating construction and deconstruction is an abstraction win but a performance loss. A commenter, brandon, mentions this.

That being said, I've always preferred to think in terms of separation of (computational) concerns, something functional programming excels at. And it's often not hard to deforest manually when the time comes.

Right -- like Haskell, for example. Mixed paradigm programming is surely the way to go; ideology is surely the wrong way. C and OCaml both support mixed programming, but Haskell supports it better: monads allow you to isolate the side-effecting portions of your program. It's funny that the OP mentions Backus' FP, which had a "job control" language that functioned like the IO monad.

I think he means "not a team player" in a very literal sense: if you are too lazy to organize and document your code, you are valuing a few minutes of your time as more important than much more of someone else's. That "someone else" is most likely on your team.

I think that alignment and organization is important, but any formal system -- e.g., align all basic blocks of assignments -- is bound to be irritating. I align related statements, with liberal whitespace to distinguish unrelated sections of the same basic block.

"Why" comments are key not only on code, but on data structure definitions also. Is that tree any old tree, a min-heap, a BST, a DAG?

Building a mathematical model is also a process of trial and error. Which definitions are necessary? What are the invariants of the structures you build, and how must those structures interact?

Particularly when modeling CS structures, mathematics feels like programming (to me). This makes particular sense when you reason about CS structures using constructive logic -- then it is programming.

Neal Stephenson has a fun depiction of wootz manufacture in The Baroque Cycle. I can't evaluate its accuracy, but it's certainly a fun scene!

Indeed. And the age shows. In the section "Perl Wins the Comparison", they explain Perl's advantages:

  Good database connectivity gave Perl the nod over C++, 
  and since Sandell and Johnson received project text files 
  in various formats, Perl's ability to parse text with 
  regular expressions was much better than COBOL or 
  Oracle's PL/SQL.

These aren't the comparisons that would be made today, though I am very proud of Perl, having beaten COBOL and PL/SQL in a regex contest!

I also enjoyed the time-travel qualities of the conclusion of that section:

  They wrote the Web applications in Jscript, and other 
  parts of the system in Visual Basic. Some functions were 
  written in PL/SQL so they could be accessible from other 
  languages using the system. "If we did the project again, 
  we would probably strive to make more of it in Perl," 
  Sandell concedes. But with so little time, they couldn't 
  ask team members to learn a new language.

JScript no longer exists, unless it's a misnomer for JavaScript. Is it considered best practice to use code rather than stored procedures? (The question is genuine -- I'm not a software developer.)

That's not how constructivity works, though --- it's all or nothing. You can be careful about the points at which you use classical reasoning (or, here, probability), but then the whole proof is no longer constructive. The argument in favor of the constructive approach is that you can very carefully decide when you depart from it.

For a (Curry-Howard) corresponding intuition, a program is no longer functional the moment any computational effect is involved (mutable state, control effects like continuations and backtracking, etc.).

Thankfully, it is just speculation. From their abstract:

  Virtually no evidence exists to test these theories or 
  establish their relative magnitudes.

PhD programs work on the mentor/apprentice setup, though the apprenticeship usually teaches research methods, not engineering methods. To my mind, the mentor/apprentice setup is great when the apprentices are genuine and dedicated and the mentors are competent and equally dedicated. (And, of course, the numbers line up! Fifty "apprentices" and one mentor is just a class.)

I thoroughly agree with the relative value of your work and your school "work". Grades are a means turned into an end, and the sooner one realizes that the goal is understanding and not recognition the better. (It's convenient that the recognition tends to follow unasked!)

One of their possible reasons:

  Faculty members like to do research. "Research could be a 
  consumption good for faculty. If faculty enjoy engaging 
  in research, then, faculty could be paid partially ‘in 
  kind’ with research opportunities. Such in-kind payments 
  are consistent with the observed compensating 
  differential -- lower pay in academia compared to the 
  private sector for similar skills," the authors write.

You don't say! I would be tempted to dismiss this as academic navel-gazing, but the abstract for the paper <http://papers.nber.org/papers/w14974>; seems quite genuine:

  Some worry that faculty devoting more time to research 
  harms teaching and thus harms students' human capital 
  accumulation. ... Research is needed, particularly to 
  address what employers seek from higher education 
  graduates and to assess the validity of current measures 
  of teaching quality.

On the one hand, a candid look at university life is always a good thing. Using the metrics like "human capital accumulation" may not be. Has anyone done a comparative study of college and university mission statements?

Edited: to fix formatting of quotes.

Scala is definitely a rara avis, a serious engineering attempt by a PL academic. This doesn't happen often enough, though the effort involved makes it easy to understand why. Odersky should be applauded for his work, which is a contribution to both academia and industry.

  What we did in Scala was try to be more complete and
  orthogonal.

These are two of the most important contributions of PL academia: orthogonality and completeness. (I would say that soundness is the third.) Separating out designs into their atomic parts paves the way for better implementations and improved programmer understanding.

  I believe one of the things we have to work on is better
  tool support. Right now when you get a type error, we try
  to give you a nice error message. Sometimes it spans
  multiple lines to be able to explain more. We try to do a
  good job, but I think we could do much better if we could
  be more interactive.

Type inference research has spent a lot of time trying to infer types in more complicated settings (GADTs in Haskell, etc.). More time, I think, should be spent on understanding failure to infer types. The Damas-Milner inference algorithm for the Hindley-Milner type system is a good starting point -- few would argue that Ocaml and SML type errors are sufficient!

Parts two, three, and four of the interview:

http://www.artima.com/scalazine/articles/goals_of_scala.html

http://www.artima.com/scalazine/articles/scalas_type_system....

http://www.artima.com/scalazine/articles/pattern_matching.ht...

Edited: to fix hyperlinks.

Choosing whom to marry, what to buy or sell, and with whom/what to associate are, in fact, votes. Votes for a given lifestyle, place, thing, or idea. Or, even, person.

School is valuable inasmuch as it civilizes us, though "houses of detention rather than attention" hits the nail on the head.

Incorrect. Consider a file test.py:

  print "hello"
  x = 1 +

Note the syntax error. Running it, we see:

  $ python test.py
    File "test.py", line 2
      x = 1 +
            ^
  SyntaxError: invalid syntax

If syntax errors were runtime errors, we would see the effect of the print statement. This is not a top-level effect: the same is true even if a syntax error is under a function.

This is the worst bit:

  He added that he was being singled out for a paper that 
  was a chore to write and brought him no added prestige. 
  "Who cares? This is a review article," he says. "I'm 
  never going to write another one, because of this
  bullshit."

Review articles are invaluable, at least in my field. Collecting results that are disparate in time and space not only saves other researchers time, but the process of arranging the article often clarifies the presentation. (N.B. this probably only applies to theory-oriented fields.)

And it "brought him no added prestige"? It must have been pretty bad if no one noticed...

I think using ++i instead of i++ everywhere is clearer, actually -- there's no need to think about temporaries, and the order of evaluation is (marginally) more transparent.

Not that pre- and post-increment are ever that intuitive or transparent...

Stack-orientation isn't a axis on this chart, nor is macro support. So: next to Pascal and C.

Not quite. A lens comprises three operations:

  get : C -> A
  put : A x C -> C
  create : A -> C

And the GetPut, PutGet, CreateGet laws require of every lens that:

  put (get c) c = c
  get (put a c) = a
  get (create a) = a

In other words, if there are no edits, then it is a round trip. The real inequality you mean is bidirectional != bijective.

(EDIT: for typesetting equations.)

A corollary may be, "Don't assume something is wrong because you don't understand it." This is a trap I fall into all of the time. Certain things tend to elicit it broadly, such as the Hoare rule for assignment:

  {P[X/e]} X := e {P}

I don't think the tide is going to completely turn in the next three or four months. If this project meets its goals, I think CP2.6 -> US2.6 -> US3.0 is a more alluring migration path. If it truly succeeds, and CPython uses LLVM as its core, then the point is moot. I think 2.6 is the right place to start -- it's more stable and has a larger codebase.

To hedge a little, I say all this from a distance: I don't use Python on a daily -- or even monthly -- basis.

I agree; his next answer really hits dead on for me: "power is about what becomes palatable to the programmer". This reminds me of the "conciseness conjecture" from On the expressive power of programming languages by Matthias Felleisen (http://citeseer.ist.psu.edu/article/felleisen90expressive.ht...). I offer the (sub-)conjecture that palatability and concision are correlated.

Or that the current climate in the computer industry is similar to that of ten years ago.

I'd be curious to see a serious breakdown of which schools are seeing increased enrollment, and in which subprograms of CS.

This is surprisingly approachable. It's fun (and flattering, I suppose) to see computability explained in a broader context.

It makes me wonder: what is the lambda-calculus equivalent of the busy beaver? Number of normal-order steps before normalization (for a given program size)? Are the LCBB numbers different for different evaluation orders? What metric do you use for program size: depth? Number of lambdas?

I don't understand how the contrast -- using category theory to derive notions of computation and something attempting to patch up Perl's object system -- relates to the rest of the essay.

I don't mean to be coy, but what's the point? Is it that business skills are important, too, and that universities (and their CS departments in particular) are underserving the computing industry? That's what one of the comments (http://use.perl.org/comments.pl?sid=42485&cid=67709) seems to indicate. The American education system needs some work, but I think it's a mistake to see a university education as vocational training: the "fields" in a university don't correspond to "fields" in the world. It's a coincidence that computer science roughly corresponds to a field in high demand these days.

One can prove, ab initio, that 1+1=2 in less than ten lines in Coq.

Algorithms are _meaningless_ without accompanying proofs. There should be --- and is --- a continuum of formality. The 20th Century has been unique in recognizing the fallacies and contradictions of completely informal reasoning; why give up when we're finally ahead?