djpowell

Clojure programming might be more data-oriented than Haskell programming. I've never done any real-world Haskell programming, but I'd guess it'ld have a completely different feel.

The dynamic-typing means Clojure code is usually built around data-flows of maps/vectors/strings (generic information types that are trivial to integrate from different sources), trivial serialization, code-as-data.

I'd guess Haskell code is more likely to be built around abstractions based on the more powerful type system.

clojure.core.logic - a Prolog-like logic language that you can embed in the middle of a Clojure function - is a good example of something that is possible thanks to Clojure's lisp macros.

You can't just buy what you want from them without a legitimate legal basis.

http://www.hscic.gov.uk/dlesaac

You could get IE5 for win3.1, which isn't a million miles behind IE6 that a lot of people are still using / developing for.

Vista had some horrible graphics performance, by disabling 2D graphics acceleration, and in keeping shadow copies of graphics buffers in RAM. There is some explanation here: http://www.tomshardware.co.uk/2d-windows-gdi,review-31795-7....

killnine: btw you have been hell-banned for the past 18 months. pretty harsh.

No, that isn't right.

Years before the first release of Clojure, Rich used to maintain a parallel build of Clojure for both platforms before concentrating on the JVM; but that is ancient history, and isn't relevant to ClojureCLR today.

ClojureCLR is a port maintained by David Miller, Rich doesn't work on it, so it isn't surprising that he hasn't made any comments about it.

Though it is true that the CLR implementation has much less adoption than the JVM or JS implementations.

DDL is boring. DML/DQL are the power of SQL and the relational model. They are what enables ad-hoc querying that the schema designer had never considered. As soon as you do anything other than select * the composite types defined in DDL aren't as important.

I was suggesting that the immutable part of FP (which is most of it) has a lot of similarity with relational querying, which is very successful in the real world.

A dynamically-typed OO language like Python is very different from a dynamically-typed functional language like Clojure. [1]

In a functional language you are mostly passing around fairly pure concepts of data as lists and maps, and transforming and combining data between functions. This data is standalone, and serialisable, and so easy to understand; a REPL-oriented environment means that code gets implemented incrementally, building from some inputs to the required result interactively, so everything gets some testing as it is developed.

The static types of this pure data probably wouldn't be very interesting.

Compare with SQL - SQL lets you join and transform arbitrary tables using queries. SQL doesn't require you to create up-front static types to accommodate the shapes of the resultsets of queries that are include joins. The Clojure Way has a lot in common with SQL, I find.

[1] of course there are plenty of large real world systems written in Python etc.

The main thing I care about with a mail client is the exit strategy - if I don't like it, can I export all my mail losslessly to mbox or eml files?

Does anyone know how it fares at this?

I use gmail now, though in the past I've used The Bat.

Yeah, I often see technology: news tickers, desktop widget, live tiles, full-screen apps, etc; that seem to assume that I'll be spending some significant amount of staring at a device waiting for it to ambiently present me information at a snails pace, while I just stand there doing nothing.

Even when I'm using social features of my app, my focus is - "I'll see what my friends are up to while I wait for coffee"; "I'll post something to keep in touch with people". I'm never going to get my phone out of my pocket, turn on the screen, and just stand there hoping that if I wait long enough it might tell me something interesting.

Lisps separate the notion of reading strings into data structures, from evaluating those data structures. So it would be easy to assume that read-string was safe to use, but there were actually some lesser-known features in the Clojure reader that allowed code execution.

The reducers versions have the drawback that they aren't lazy because they are defined in terms of reduce; so there is still a place for the core map/filter/etc functions which can operate on, and return lazy sequences without doing any actual work.

There is a very short set of slieds explaining as much here: http://perl.plover.com/yak/design/

Joel Spolsky wrote a good summary about the Hungarian notation, and how it got corrupted within Microsoft:

http://www.joelonsoftware.com/articles/Wrong.html

Could some of these be caused by 3rd party in-process shell extensions? Especially ones that aren't compatible with Windows 8?

Yeah, you have to create an account by entering your email address and a password. That's all. I don't think there is an association between the account and device - the account is just where your settings get stored.

I agree that the requirement to be online to use the config program is silly, but most of the conspiracy theories, talk of DRM, and vilification of the company that are flying round seem a bit overblown.

Their privacy policy prohibits sharing of personal data with third-parties, so I assume that they don't. There really seems to be nothing to see here.

Cloud storage of mouse settings is perhaps a bit wacky, but I really don't think there is a conspiracy behind it.

It might make more sense for the driver to allow local configuration, and then sync that to the cloud, rather than the other way around - but meh. The lack of internet connection probably isn't a real-world problem for users of a mouse targeted at MMO gaming.

I've got one of these mice, and I can't reproduce any unresponsiveness when the driver transitions from online to offline.

I think the real lesson to be learnt here is that even if you've done nothing wrong, if you don't want to be the target of internet hysteria, be very careful that no feature in your product can inaccurately be described by people on forums with the letters D-R-M... especially when it isn't.

RFC3339 is a pretty reasonable profile of ISO8601 http://www.ietf.org/rfc/rfc3339.txt

I'm always a bit nervous when people talk about ISO8601, given that very few people have probably read the spec, and are likely guessing as to its content.

HTTP URIs never officially supported this syntax anyway: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2...

The userinfo component is supported according to the URI generic syntax, which FTP URIs follow, but HTTP URIs don't. See the sadly still not obsolete RFC1738: http://tools.ietf.org/html/rfc1738#section-3.1

They are likely to be more useful when using Clojure as a serialisation syntax for data (much like how JSON is used with JavaScript), rather than when used directly in source code.

I assume that these extensible literals will be ported to the JavaScript and .NET implementations of Clojure, making it easier to work with rich data types without having to pepper your code with calls to date parsing functions, etc.

Having an intuitive, idiomatic concept of 'data' at the heart of your code is an important aspect of Clojure.

In comparison, I find it hard to the answer the question, "How is data represented in Java?" Which is why I find doing things like data transformation to be far easier in Clojure than in Java.

Let's say you have some data, perhaps some of it is from an SQL database, some from files, some from NoSQL. In Clojure there is a small set of data structures, and a unified lazy sequence abstraction that can bring all of these together. You've got a huge standard library of functions for manipulating sequences and maps, rather than having to write your own one-off functions for working with custom OO classes.

Perhaps you want to do some processing on the data and convert it to JSON. Immutability and lazy sequences let you work from the problem towards the solution by layering small reusable functions over your data to get it to where you want it. And you can do this without it being hopelessly inefficient.

Another advantage that is easy to overlook is the environment. The ideal Clojure environment is an editor or IDE that is backed with a REPL. You can write a bit of code in your editor, perhaps assign some test data to a variable, and then with a couple of keystrokes, send the code to the REPL and see it working in a live environment. Perhaps your function isn't quite right, no problem, fix it, a couple more key-strokes and try it again. Writing code incrementally in this way has a similar effect to test-driven development. You are writing small pieces of code and the code is being tested as you develop it (albeit only informally).

Is a massive rippling mutable OO graph the universal way to do game state? It presumably makes concurrency an impossible deadlock-fest.

Are there any examples of using something like relational tables for game state?

Yes. Fire up multiple live-repls and they'll all be connected to the same address-space, and function redefinitions in one will instantly be visible in the others. Fun if you're playing around with Clojure's concurrency constructs.

Here is something similar that I wrote for connecting a Clojure REPL to a Clojure/Java process:

https://github.com/djpowell/liverepl