Huh? Why would that be a valid point? It's no harder to swap out different kinds of render methods than it is to swap style sheets.
BTW:
> Programs written in compiled or runtime-based languages either run or they fail.
This is simply not true. No matter what you're writing code in, you can write it in a way that exhibits graceful degradation. It's just that some languages make it easier than others.
> It's no harder to swap out different kinds of render methods than it is to swap style sheets
The point is that with css the client can change the rendering in ways not foreseen by the developers. If I happen to have a rare form of color-blindness that means I cannot perceive the color purple, I can create a Firefox extension that changes purple to blue, and immediately all websites in the world becomes accessible to me.
If we consider HTML a kind of object-code where presentation is hardcoded into the on-the-wire output (like eg. PostScript), I would have to call around to all web-masters in the world and beg them to change their render-methods to accommodate my unique disability.
'Huh? Why would that be a valid point? It's no harder to swap
out different kinds of render methods than it is to swap
style sheets.'
its much much harder to switch rendering engines than to switch css files
try changing this websites rendering engine, first you need to hack the server, then you need to understand the source code(and learn the language if you dont know it already), then learn how the renders are perfomed, how the data is modelled.
then try switching its stylesheet, that can be a click away if you want it.
What you say is true, but only because the software most people use on their servers makes it true. The conclusion is not that we should continue to use the current broken infrastructure, but that we should build different infrastructure. Your argument is kind of like someone in 1904 arguing that air travel will never be commercially viable because there aren't any airports.
I find it a bit distressing that I would have to explain this here on HN of all places.
I didnt make an argument I pointed out a blatantly incorrect statement.
but to follow your point is there anything fundamentally flawed in the concept of html/css/javascript that makes portable sites impossible, or are you suggesting we make some pluggable generic server side rendering that can be controlled by the client because css doesnt deal with heights very well yet?
> is there anything fundamentally flawed in the concept of html/css/javascript that makes portable sites impossible
No, of course not.
> or are you suggesting we make some pluggable generic server side rendering that can be controlled by the client because css doesnt deal with heights very well yet
Yeah, pretty much. That way you don't have to wait for the standards bodies or the browser developers.
I didn't know about that particular comment, but I did know that this is not an idea that's original with me. It's completely obvious to anyone who has learned Lisp. The only reason I wrote it is that it's apparently not completely obvious to CSS advocates. I seemed to have garnered their attention for reasons passing my understanding, so I thought I'd try to take advantage of that to spread some enlightenment. I have found that sometimes merely stating the obvious somewhere that people can see it and link to it can be useful.
Global warming is a myth - not the fact that it exists but rather that it's caused by humans, and people die because of it.
State birth control... what, are you in favour of it?
Edit: why is this here?
Because lots of dictator wannabes like the idea that there's only enough space in the world for them, and that there is this really big problem of population that only someone as calculating as them can grasp. I'm sorry but this really pisses me off. We have lots of energy and lots of space, go and play with a ball and have fun.
Not just a possibility, its an emerging method of taking the web technologies to the desktop. You can mix AS3 and HTML/JS for a very clean, and fast implementation of typical desktop UI features. Honestly, AIR is perhaps the easiest way to package these sorts of things.
Sorry to keep replying like this, but I'm just utterly dismayed by your upvotes. To put it bluntly, you are wrong (particularly paragraph 1 sentence 1 and paragraph 3, mutability).
I'm not sure how you have arrived at Lisp being your ad hoc definition of functional programming, but it frightens me.
The main issue here is that the article isn't saying that only the lambda calculus is functional programming but it is saying that the whole paradigm is based on the lambda calculus and so to determine how functional a language is, you determine how similar it is to the lambda calculus.
Wikipedia on functional programming:
"Functional programming has its roots in the 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 embellishments to the lambda calculus."
Feel free to reply as many times as you'd like; however, you're a bit confused. You haven't read my comment attentively - Lisp is not my ad hoc definition of functional programming, and nothing in my words indicates that. I just used Lisp a few times as an example to show that the original post's idea of what a functional language is is too narrow and unreasonable.
You're saying in one paragraph that the paradigm of functional programming is "based on" the lambda calculus, and to support that you're citing wikipedia as saying it "has its roots" in the lambda calculus. These are two very different things. You can have roots in something with, and yet also contain other crucial ideas. Functional languages are like that: their basic syntax is inspired by the lambda calculus to a significant degree, but they don't reduce to it.
It's a mistake to assert, as you do so confidently, that how functional the language is depends on how similar it is to the lambda calculus. There is no Council on Functional Languages that ever decreed it to be the case. What "functional programming" and "a functional language" means is relatively messy, as most things in computing, and is determined by how people have been using these words, more or less consistently, over the decades. If you look at that, you'll discover, for example, that while having functions as first-class citizen was always a definite requirement of functional programming, neither immutable state nor TCO ever were.
It seems to me that, speaking generally, many people learn about the lambda calculus and get their minds blown. Lambda calculus is a very beautiful thing, but it did not invent passing functions to functions, returning functions as results, everything if a function, etc. That started four decades before with Russell & Whitehead's theory of types (numbers, first-order functions, second-order functions that act on first-order functions, third-order functions and so on) and was commonplace by Church's time. Church's contribution was a particularly simple and economic system of notation that used just one operator (the lambda) to climb the tower of types. Another ingenious notational idea was to use simple juxtaposition as function application. Functional languages later used these two ideas to great effect, but they never reduced to these two ideas and nothing else. What about conditional execution? Named variables? Lists as a fundamental structure? Static typing? Sure, you can simulate most of these in vanilla lambda calculus, just as you can simulate numbers with Church's encoding. But how is that any different than saying you can simulate loops and subroutine calls on a Turing machine, and therefore these are "just optimizations"?
To sum up: the common underlying theme for functional languages, if you look at them, has been freedom to use functions as values everywhere values are used, freedom to compose them at will, and freedom to easily define new ones. The syntax of working with functions and defining them has usually been inspired by the lambda calculus (though see Dylan for a weird exception). Being as close as possible to the lambda calculus is something that's never been a goal of functional programming as a whole, though recently some languages have gotten surprisingly close to it. Having features incompatible with or orthogonal to the usual understanding of lambda calculus has always been OK. TCO is an issue for language zealots to fight over, not a serious contender for what is or isn't functional.
It's a mistake to assert, as you do so confidently, that how functional the language is depends on how similar it is to the lambda calculus.
The article agrees with this assertion, Wikipedia agrees with this assertion and I agree with this assertion. Why is it a mistake to assert this? Granted you point to earlier type theory which I was unaware of, but my claim wasn't that lambda calculus was original.
If you look at that, you'll discover, for example, that while having functions as first-class citizen was always a definite requirement of functional programming, neither immutable state nor TCO ever were.
Here is another big gripe of mine. Given that there are practical reasons for the earlier functional languages to have been different from the lambda calculus (speed and memory), why continue using those languages as metrics later on when the limitations of speed and memory no longer apply?
Lisp was by all accounts an attempt to make a working lambda calculus[1]. However the machines weren't very quick then and speed was a real issue. Even later on when Scheme was designed, speed was an important consideration, and it probably did affect the resulting language.
What the author was saying about TCO was that, based on the fact that all our machines today use stacks, and not wanting to have programs that break(!), any implementations of lambda calculus on these machines must have TCO to allow as much of the lambda calculus as possible to be available in the programming language, lest you reject otherwise correct programs.
But make no mistake, Lisp[2] and functional programming languages ARE based on the lambda calculus. The article really did hit the nail on the head.
--
[1] "Lisp was originally created as a practical mathematical notation for computer programs, based on Alonzo Church's lambda calculus."
And quite relevant to this topic, our compilers and computers have (since the invention of Lisp and Scheme) gotten hugely better to the point where we can make much closer approximations to the lambda calculus such as the inclusion of lazy evaluation and immutability.
I'm not sure I agree with this first statement. For sure scheme was motivated by lambda calculus, but I do not believe McCarthy (a functional analyst by training) was aware of lambda calculus when he invented Lisp. Rather he was motivated by symbolic calculations often performed in functional analysis.
NOTE: I stand corrected, I just checked and McCarthy's Lisp paper does cite Church's thesis work. Somehow I had thought Algol was motivated by lambda calculus
No, it was an attempt to implement the Actor model in Lisp. The Actor model isn't what people usually have in mind when someone says OOP - it's more like Erlang or Termite.
