My Favorite Restaurant In New Orleans ... no longer in business

Over the years I've told many people about my experience at Jimmy Moran's Riverside Restaurant in New Orleans. Unfortunately, this place closed many years ago. But it had AMAZING Fettuccine Alfredo (yes, I had lots of Butter, Cream, and Parmesan over the years before I was weaned). He went to Italy to learn how to make it. He would come out to your table in the dining room with all the ingredients on a rolling cart covered with a white cloth, including freshly made Fettuccine pasta, and assemble an amazing pillow of clouds for you to eat! Every other time I've tried to get this dish in a restaurant it has been horrible. Sigh.

at No comments:

How to get text to look the right size on Laptop and Phone, and another trick

 I recently tried to publish some content and found the text to be WAY too small on cell phones. So I searched the web and found this <HEAD> content that fixes the problem. Just add this tag inside your HEAD block:

<meta name='viewport' content='width=device-width initial-scale=1'/>

I also noticed that they added a way to create nested tree views that open and close without and script or CSS in HTML5, which is now in every major browser. Just use the <details> and <summary> tags
at No comments:

Wean Yourself

I am weaned. Like most adult mammals, I don't eat dairy products. When I quit, at age 23, my face cleared up. No more pimples. Then my nose cleared up. I could smell! Then my energy level went up. I started riding my bike from Providence to Boston. I was clearly onto something. But in the mid-80s in New England it was not so easy. Now it's easy.

Dairy is not really good for you. The places with the highest dairy consumption have the highest osteoporosis. Do you really need all that fat and protein?

So I haven't had dairy in 30 years. Except in small amounts, like in baked goods. Not croissants. But an occasional cake. I employ the don't-ask-don't-tell policy sometimes. But mayonnaise is not dairy, so that's OK. My favorite food was Fettuccine Alfredo at Moran's Riverside restaurant in New Orleans. Amazing! But I don't miss dairy now. Not at all.

Lately dairy has been creeping into more foods, especially at restaurants. I recently order fried calamari, which came with (completely un-announced) lots of parmesan cheese all over it. When this happens I can't help feeling that they have sprinkled dirt all over my food, and then server it to me with a smile. I always send it back. Even more amazing was the cheese in the cole slaw I was served recently. I asked the manager over, who admitted they had added cheese but not mentioned it on the menu. She said "but it's so good!" Except when it's not.

Everyone always says "Give up cheese? I could never do that!" But it is surprisingly easy. Hamburgers are great without it. Even pizza is just as good without cheese... that's the way the italians do it, anyway. Other ethnic foods don't use it to begin with (although I have noticed a starting increase in the use of cream cheese in sushi). Just Say No!

Are you weaned?
at 3 comments:

Declarative versus Imperative


I responded to a recent discussion Declarative vs imperative programming on the Types mailing list, but my post was rejected because of a bad mail header. By the time I got around to fixing it, the discussion was old. But for what it's worth, here are my thoughts:
------
I have been thinking about the use of the words "declarative" and "imperative" for some time. This is my understanding of how they are commonly used in computer science today:
Declarative: describing "what" is to be computed rather than "how" to compute the result/behavior
Imperative: a description of a computation that involves implicit effects, usually mutable state and input/output.
As others have pointed out, our usage originally came from the distinction between imperative and declarative statements in natural languages. However, I think that our usage has diverged significantly from this origin, so that the words no longer form a dichotomy.
For example, one might argue that a finite state machine is both declarative and imperative in the computer science senses. I think Uday made a similar suggestion. There is also Wadler's classic paper on "How to declare an imperative".
Another hint that "declarative" and "imperative" are not antonyms is that the definitions don't have any significant words in common. The antonym of "imperative" in common usage is "pure functional". I don't know of a widely-used word that acts as an antonym for "declarative", although "operational" might work. It may be that "imperative" has a connotation of "step-by-step", which hints at it being the opposite of "declarative", but this connotation is fairly weak at this point. If we wanted to we could try to force “declarative” and “imperative” to be antonyms, possibly by redefining what we mean by “imperative”, but I'm not sure that would be an improvement.
I agree with those who say that "declarative" is a spectrum. For example, some people say that Haskell is a declarative language, but I my view Haskell programs are very much about *how* to compute a result. It is true that many details about how are left out (memory management, order of operations, etc). But if you compare a Haskell program with a logical specification (pre/post conditions), they are quite different. Thus while I would say Haskell is more declarative than many other programming languages, Haskell is not a declarative language in the strongest sense of the word. Haskell programs are not specifications, they are computations, in the sense that they say how to compute and answer.
Here is a quick shot at a spectrum between "how" and "what". Each level has a quick summary of the "how" that is involved, and it also includes all the "hows" listed below them. I suspect that many of you might disagree with the placement or absence of various languages, so I cannot claim that this list is definitive.
 More "How"
How the machine works
   Assembly
How memory is managed
   C, C++, etc
Order of operations
   Java, Smalltalk, Python, Ruby, etc
How data flows (with issues like nontermination and cut)
   Haskell, Prolog, Lambda Calculus (in various forms)
----split between Programming and Specification Languages---
Restricted Specification Languages
   BNF, SQL, Excel, Statecharts
Logical specification languages
   VDM, Z, B, Alloy
 More "What"
The idea that a specification language (by definition) cannot be executed is widely held but false. I consider BNF to be a simple counter example. BNF is clearly a specification language, and it clearly has efficient execution (parsing) strategies.
As for the objects/type distinction that sparked this discussion, I think the discussion was pretty reasonable, and I would like to thank Jonathan for presenting my views so articulately.
I agree with Uday that we need to get our own house in order. These kinds of discussions are a good start.
at 16 comments:

Advice for faculty candidates interviewing at UTCS

Everybody has heard the advice that job talks must be "accessible to a broad audience". Some people take this to mean that "all of the talk must be understandable by a broad CS audience". Unfortunately this leads the speaker to remove all the depth from their talk, for fear that somebody in the audience might not understand it. The resulting talks are underwhelming.

Keshav Pingali suggested this recipe based on thirds: 1/3 of your talk should be understandable by everyone. This should include the motivation and the high-level contribution and significance of the work. 1/3 of your talk should be understandable by people in your general area. Finally, 1/3 should be understandable by specialists working on your particular problem.

I'm not sure I would go so far as Keshav. But I do agree that there must be at least part of your talk where you describe the key problem and your solution in detail, and that this is likely to be fully understood by only a few people in the audience. But that's OK.

So PLEASE keep the depth in your talks and don't worry too much that somebody might not be able to follow. Just think about how many job talks you've been to where you haven't understood everything. It's OK. Take a deep breath. Show your depth!
at No comments:

Revised definitions of object and object-oriented

I revised my proposed definition of object based on feedback, to be more general. Please put comments on the original post. I'm very interested in getting more feedback on the definition.
at 5 comments:

The Day Functional Programming Became Pure

The definition of "functional programming" changed slowly over the last 20 years, as expressed on the Wikipedia page on Functional Programming. Perhaps the process started even earlier with John Backus's famous Turing Award lecture Can programming be liberated from the von Neumann style?: a functional style and its algebra of programs. [Note, I have revised this to put the quotations in chronological order and add a new paragraph on the end]

Before 14 August 2003, the page described functional programming as a style that emphasized the use of functions. For example on 14 October 2001‎ the entire page was 220 words long, and began:
Functional programming is a style of programming that emphasizes the evaluation of functional expressions, rather than execution of commands. The expressions in these languages are formed by using functions to combine basic values.  
A functional programming language is a language that supports and encourages functional programming. The oldest example is LISP. More recent examples include Scheme, ML, Haskell, Erlang, Clean.
Lisp is identified as the first functional language, and Schema, ML and Haskell are on equal footing.

The changes started on On 14 August 2003 when the pages from Nupedia, which had a structured and peer reviewed model for content production, were integrated into Wikipedia by Luxor to create a page with 1,640 words:
Functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions. In contrast to imperative programming, functional programming emphasizes the evaluation of functional expressions, rather than execution of commands. The expressions in these languages are formed by using functions to combine basic values.  

At this point functional programming is not about emphasizing use of functions. Instead it means programming with mathematical functions. Implicit in this definition is that such functions are pure, but because it is not explicit the implications were not clear. This description was elaborated until 29 May 2006, when the page read:
Functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions. Functional programming emphasizes the definition of functions rather than the implementation of state machines, in contrast to procedural programming, which emphasizes the execution of sequential commands. A purely functional program does not modify state to produce values (as is done in imperative programming), it constructs new values from (but does not overwrite) existing values. 
There is no uniform agreement on what constitutes functional programming or a functional programming language. Often considered important are higher-order and first-class functions, closures, and recursion. Other common features of functional programming languages are continuations, Hindley-Milner type inference systems, non-strict evaluation (i.e. "laziness"), and monads.
There is still a distinction between (ordinary) functional programming and the "pure" form of functional programming, which avoids the use of mutable state. At this point there was a small but significant change, in the middle of the night, with no fanfare, by an unknown person. At 01:07 on 29 May 2006 it was changed to read:
Functional programming is a programming style that treats computation as the evaluation of mathematical functions and avoids state and mutable data. Functional programming emphasizes the definition of functions, in contrast to procedural programming, which emphasizes the execution of sequential commands. 
Functional programming relies on concepts from the lambda calculus, Lisp, and more recently Haskell. Frequently mentioned are the avoidance of state and side-effects (which provides for referential transparency), higher order functions, recursion, and closures. 
At a stroke, the author made explicit the requirement for purity and added it to the definition of functional programming. This requirement had been implicit in the description of functional programming, as computation with mathematical functions. This author also resolved the uncertainty about how functional programming should be defined. Prior pages said there is no agreement, but the new definition was stated without such doubts.

The change was made by ideogram, whose real-world identity is not disclosed. This account was created a few days before the active editing of the Functional Programming page started. Since then the account has been banned numerous times for unacceptable behavior (trolling) but this seems to be urelated to the editing of the Functional Programming page.

They didn't leave a revision comment. On the other hand, there is some discussion about the issues on the Functional Programming Talk page. There have been edits since this point, which have restored some of the previous language, but they are later removed. Currently (July 14, 2012) the page reads:
In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. It emphasizes the application of functions, in contrast to the imperative programming style, which emphasizes changes in state.[1] Functional programming has its roots in lambda calculus, a formal system developed in the 1930s to investigate function definition, function application, and recursion. Many functional programming languages can be viewed as elaborations on the lambda calculus.[1] 
In practice, the difference between a mathematical function and the notion of a "function" used in imperative programming is that imperative functions can have side effects, changing the value of program state. Because of this, they lack referential transparency, i.e. the same language expression can result in different values at different times depending on the state of the executing program. Conversely, in functional code, the output value of a function depends only on the arguments that are input to the function, so calling a function f twice with the same value for an argument x will produce the same result f(x) both times. Eliminating side effects can make it much easier to understand and predict the behavior of a program, which is one of the key motivations for the development of functional programming.
[1] Paul Hudak. 1989. Conception, evolution, and application of functional programming languages. ACM Computing Surveys volume 21, issue 3 (September 1989).
What are the implications of this? How did this change come about? Are we in the midst of a (small) scientific revolution? Who is behind this?


According to the new definition ML and Lisp are no longer functional languages. It is possible to write some some in a functional subset of these languages. The first requirement is avoiding the use of "ref" types in ML, or the use of assignment and structural mutation in Lisp languages. However, this is not enough, because many of the standard libraries for ML and Lisp languages have side-effects. This is especially true of any libraries for IO. As a result, the range of program that can be conveniently written in a functional style is fairly limited.

at 11 comments:

Interesting discussion on DSLs

Discussion of Domain Specific Languages (DSL) on Lambda-the-Ultimate. Originally the discussion was sparked by a Facebook status update by Erik Meijer. But not everybody is friends with Erik, so it was not public. Please put comments on the LtU page.
at
Subscribe to: Posts (Atom)