Hacker News Reader

Comment by david927 | Hacker News Reader

With the deepest reverence to John McCarthy, I regret to say that Lisp is our cosmological constant. It creates a static universe that is otherwise expanding; it reduces the problem to a solvable one and then declares victory. The truth is, it's all state. All of it.

Remember that movie "Boy in the Plastic Bubble," about a boy with an immune system deficiency who lives instead a hermetically-sealed, sterile bubble? That's not the answer. We instead need to create immune systems (read: robust systems) rather than simply avoiding them.

[I know I'm simplifying things, and this is not meant to be a slight.]

View on HN

I attended TechMesh 2012 in London. The creators of Haskell were there, and there was a number of other Haskell talks. They were almost all about how to model state, I/O, etc. One of the Haskell creators also created Quickcheck, a generative testing tool where tests are written in Haskell. He talked about how he found state related bugs in Riak. Rich Hickey, author of Clojure, was there, he keynoted about state. I'd argue that the whole point of Clojure is to manage state. Specifically, have a model for how to work with the passing of time.

In other words: functional programming and Lisp does not translate to ignoring state.

How to model a state is a meaningless question without asking state of what.

Same is true for I/O. You must start from a protocol.

Most of people probably underestimate how many brilliant people contribute to what we could call a modern Lisp.

With all respect, Clojure is nowhere near in terms of sanity, consistency and uniformity.

I don't event want to argue about Haskell. Seems like words "monad" is the same as words "chakra" or "dharma" in a popular culture.))

> With all respect, Closure is nowhere near in terms of sanity, consistency and uniformity.

It's Clojure http://clojure.org/

Closure is Google's js library and tools https://developers.google.com/closure/

Yeah, thank you. It was a typo..

Ir you are talking about syntax uniformity, lisp is not very regular also http://xahlee.info/UnixResource_dir/writ/lisp_problems.html

Although I agree that clojure has is warts. For example clojurescript uses the numerical stack of JavaScript. So you get different and unexpected results than when running on the JVM

lisp is much more regular in syntax than most popular languages, and Xah's page that you point to amounts to little more than saying "I don't know lisp well, so I find various aspects of the language - backquote, quote, unquote-splicing, etc. - confusing."

One of Clojure's goals is to interop well with its host platform, which it does in both cases. I'm not sure I'd count that trade off as a wart.

If you have issues related to the syntax uniformity of certain Lisp dialects, please speak for yourself rather then linking to that troll Xah Lee.

Xah Lee recommends that developers subjugate themselves to Wolfram Research which controls the proprietary program Mathematica.

Even though some Lisp dialects have a couple of quoting operators like ' and ` at least they don't have infix operators like + and * that Mathematica has. Besides, a few quote operators is no basis to say that Lisp syntax is "not very regular."

> Seems like words "monad" is the same as words "chakra" or "dharma" in a popular culture.

Are there any more interesting concepts you stubbornly dismiss?

[aside] that looks like it was a very interesting conference. i can't find much related info. will it be annual? are they spreading to other places? who was behind it? [edit:] it seems to be an indie thing http://techmeshconf.com/techmesh-london-2012/contact/

They're redoing it this year, and considering doing one in New York this year as well. I think the organizers is a loose collection of Erlang companies (Trifork, Erlang Solutions, probably more). IIRC they organized an Erlang conference and decided to relaunch it as a general FP conference.

It was _really_ good, you should definitely check it out :)

I'm sorry but what you're saying is immediately obvious. No one in the functional programming world is laboring under the impression that state doesn't exist.

The real issue is whether you think it's worth separating out code that can be reasoned about in a mathematical fashion from stateful code that has to deal with mutating concerns. Functional programming is where research on improving abstractions to better allow this separation of concerns, which is pretty much the opposite of a clumsy hermetically-sealed bubble rolling around and knocking lamps over, etc.

I'm not sure what I said is obvious because you seem to have missed my point. I didn't say that "state exists". I said, "It's all state." I'm saying the notion of "separating out code that can be reasoned about in a mathematical fashion," while a successful strategy in the past, is inherently crippled by that division.

For the record, I also did not think whatever you were saying was obvious, but if your point is that understanding programs by "separating out code that can be reasoned about in a mathematical fashion" is no longer a viable strategy, I must take issue with your statement. Can you provide an example of a side effect free function that can't be reasoned about mathematically? I'm sure they exist, but they seem to me to be a kind of exotic beast. Or maybe I am just not familiar with your domain of expertise?

How it exactly is it a "crippled vision"? There are tons and tons of code that I write every day that I'm able to separate out like this. Honestly there is way more code that you can reason about in this way then not reason about in this way. This isn't some academic exercise, people right functional code that operate in this way and do a lot of useful things everyday.

What makes you think that stateful code can't be reasoned about in a mathematical fashion?

Well, there's certainly a popular conception among program analysis and formal methods researchers that side effects make analysis much more difficult.

Lisp is a multi-paradigm language that's perfectly capable of representing state. Perhaps you're confusing it with some purely functional language like Haskell.

I'm not saying it can't represent state; I'm saying that it promotes avoidance of state as a virtue.

One of the reasons avoiding state is promoted is to make it easier to write robust software. State is too often the enemy of robustness.

And robustness is often the static plastic bubble that hides in itself, never accomplishing much in the real world.

State is too often the real world.

Mind you, I like robustness. It's like the cinder blocks I use to build my house, each robust and contained in itself. I just can't disregard state when stacking my cinder blocks on top of each other; the flexing and distribution of load is an emergent state that I have to consider when building each cinder block.

So to be clear here I assume you are talking about mutable state. Even if that is the case, it is not about avoiding state at all. It is about managing it explicitly.

I translate your first paragraph to "I have never used Haskell" in my head.

The idea that Haskell is somehow about not doing anything because it can't do state is just silly. It doesn't pass the smell test. People do not write web frameworks or compilers or anything in a language that "can't do anything" because it can't do state.

Haskell is not about "not touching state". That's just objectively wrong. It may not work exactly like you are used to, you may not like the tradeoffs, but Haskell can do things. I know, because I can make it do things.

I would say that it is.

Mutable state in software is like moving parts in hardware. It's often necessary, but it makes everything a bit more fragile.

Avoidance of state in general is a pretty ridiculous claim to make. Even when writing pure functions, the state consists of all of the arguments to all of the functions up the stack.

... of course Haskell is perfectly capable of representing state too ...

So because there is state you want to have a messy pile of it. Many lisps have more advanced system for states then most other languages.

Common Lisp has a better object system then any other in the world. Clojure has a time and state managment system.

I rate Moose (http://moose.perl.org) up there with CLOS when it comes to power, extensibility and features.

However saying these are the best OOP systems in the world is still very subjective because I do have a fondness for the simplicity and elegance of Prototype based OO especially as implemented in languages like in Io, Rebol & Self.

You're making an extremely vague but bombastic claim here. I don't think you're intentionally trolling, but it operates on a very similar level.

What does this mean in practical terms? What are you specifically criticizing? It's obvious that you're taking some kind of dig at functional programming, but what is the actual critique or logical argument you're attempting to make here? It is very unclear.

Funny you should say that: just yesterday Reddit informed me that Lisp is 100% imperative because it has a loop keyword and allows destructive assignment.

Well, "Lisp" is a language family rather than a specific language. Although it's culturally drawn toward functional programming, Common Lisp is more or less an imperative language with first-class functions, much like Python is. Its designers chose this approach because they wanted it to be a "big tent" language that imposes few opinions on the programmer. Other Lisps like Clojure and Racket went in a different direction.

"The truth is, it's all state. All of it."

The problem is not state. The problem is being able to recreate the state: both for testing and for business purposes.

The bigger problem is that most programmers, like you, are knee-jerking before the issue of "recreating the state" and declaring that "It cannot be done, because it's all state".

And hence we have both languages who are build by considering mutability to be a virtue and back-end databases (your typical CRUD SQL DB) build upon the same false premises.

I'll give you one example: monday morning the service desk calls because one user of your app, at 3:07pm on friday, experienced a bug.

Can you "recreate the state" your application was in at that time as to be able to figure out what triggered the bug?

You probably can't. Because your DB has changed meanwhile: you're SOL because the 'U' and the 'D' in CRUD are destructive. It's mutability. It's the ennemy of determinism.

So now you're stuck calling your DB admin asking for a dump of the prod DB on last thursday evening and a dump of the log of the transactions that happened on friday... And you're spending hours and hours trying to recreate the state the environment was in when the sht hit the fan. And you may or may not be able to do it.

It's just one hypotethical scenario but things like that is the daily lot of many* programmers.

But software development, in many cases, shouldn't be that painful. If you were to use a CRA DB (Create Read Append) and languages favoring immutability and a more functional approach overall, you'd have a much much easier time recreating the state.

If you think of it, it's all a gigantic determistic machine.

So why can't we accept that the notion of time is an important one?

Why can't you realize that the battle the likes of Rich Hickey are fighting are worth it?

It is possible to use programming languages and DBs (or wrappers like Datomic in front of SQL DBs) that do definitely make it easier to reason about programs and that make it just so much easier to recreate the state and to query the past (which has a lot of business value).

Why do you react like this: "The truth is, it's all state". Saying that as if nothing could be done and as if every single programmer's life should be Java/C# + ORM + XML + SQL hell?

There are people trying to make our life as devs easier. Why not try to listen to what their saying?

Is Rich Hickey "seeing things" with Clojure + Datomic?

To me the combination of a functional language (or at least a language that can be used in a mostly functional way) and a CRA DB (Create Read Append) which incorporates the notion of time from the start is a godsend to our industry.

Why do you close your eyes?

Try googling around for "cqrs". There are many ideas on how to do exactly this effectively.

All it takes is to swap "write" operation with "event" entity (all is state). Combine that with intention revealing commands (customer_died instead of delete from customers where id=1) and you hit jackpot.

End result is nice stream of events which is ultimate source of truth and enables crazy queries you never thought you would ever need http://abdullin.com/journal/2010/6/3/time-machines-should-su...

This is quite interesting. In practice though, the lags between command/query models when the datastores are different(almost always, for large data) becomes a real concern

Pardon my pedantry, but CQRS doesn't necessitate eventual consistency. Denormalization of domain events into can happen synchronously. It all depends on the needs of the project. If the project information architecture and processes can support a degree of latency (which is implicit in almost any technology providing static screens anyway), then the performance gains of eventual consistency can be realized.

A good, nuanced explanation of CQRS is here: http://codeofrob.com/entries/cqrs-is-too-complicated.html

A CRA DB is essentially a SQL database with temporal capability.

Even if you have perfect time-warping capabilities, there are still big challenges to solving bugs with that kind of analysis. The time the bug is noticed may be long after the root cause, and working backward could be a very slow process.

That's why SQL has declarative constraints, to try to make the error noticed at a time closer to the root cause.

Would I like full time-warping capabilities sometimes? Of course. But it's just one more option, and a very expensive one at that. To be any use at all, we'd need to be able to warp backwards through the entire OS and its scheduling decisions (not just a single process), because many difficult bugs involve race conditions.

Really, we need better temporal capabilities, and more declarative constraints (that are immune from race conditions, like a UNIQUE constraint), better ways of avoiding race conditions, etc.; and they all need to work together.

That's why I have worked on temporal capabilities[1] as well as declarative constraints [2] (immune from races) in Postgres. Also, you might be interested in truly serializable transactions in postgres, which eliminate race conditions between transactions without blocking[3].

I feel like the programming language community should work more with the database community. From the article, they mention how restarts can help recover from errors encountered after part of the state has already been changed. But that kind of recovery is taken for granted with the atomic nature of transactions in a database. Database theory is largely about detecting, containing, mitigating, recovering from, and preventing errors[4].

[1] http://www.postgresql.org/docs/9.2/static/rangetypes.html [2] http://www.postgresql.org/docs/current/static/sql-createtabl... [3] http://drkp.net/drkp/papers/ssi-vldb12.pdf [4] http://thoughts.davisjeff.com/2009/12/23/good-error-recovery...

Why can't you stop making rhetorical arguments? Please, just say why you think something is good without attacking people who have a different point of view. Reading the sort of polemic above is exhausting and confusing.

Could you provide examples of CRA Databases. ?

I'm not familiar withe the concept and google and wikipedia haven't helped.

Thanks.

To me state is what makes lisp hard, every time I look at lisp code (scheme via guile) I need to interpret it in my head to figure out the state. And certainly the set! doesn't help.

Lisp puts a heavy burden on the individual programmer, and its benefits can be achieved with better planning and engineering with the standard C++ toolkit. Yet, it is not easy to achieve the advantages of C++, such as performance, parallel execution, low level with lisp.

Lisp is nice for the few who have small projects, big brains, and little time, but by tightly coupling the problem to the code (with no performance benefit) it creates a unstructured nonsense that nobody but the author can understand.

> The truth is, it's all state. All of it.

Lisp represents mutable state the same way Python and C++ do.

Reply on news.ycombinator.com