Exactly. As N goes to infinity only the biggest term of N is going to matter - the rest is just a drop in the bucket. Big-O (and family) notation is really just about getting a general idea of a functions performance.

ty!

The defpage thing looks like standard routing for noir. If you drop down to compojure (which noir uses) it's something like:

This type of syntax makes me feel right at home. It's very similar to express in node.js.

Where ... could either be:

1. A ring (1 level below compojure) response which is a map with the status code, headers and body.

or

2. An expression (foo) where foo is a function that's a hiccup template.

I'm still confused on the mutability stuff. They have 3 or 4 things dedicated to it. State seems to be everywhere in web apps. Even if you had a simple counter that incremented for each request and stored in a session, that is state and that counter should probably be mutated no?

I watched some talk by the author of clojure last night and he made it seem like concurrency is nice on clojure only if you're talking about same-machine concurrency through multiple cores. Their whole system seems to turn to poo once you talk about introducing multiple machines (distributed concurrency).

I wonder if this is why most people try to keep their apps stateless and just throw things in redis. Then you don't have to worry about state across multiple machines or even cores. Just use sticky sessions on a load balancer and keep your apps kind of stupid.

Edit:

Are you dead set on noir btw? I'm a little scared to use it because it looks like it's a dead project. It hasn't been touched in ages but seems to be built on the most popular web components (ring, compojure, hiccup).

Agreed. I haven't watched the talk yet (ehrmahgerd the android youtube app is so ****ing worthless) but I think intent is way clearer when you raise InvalidPasswordError or DatabaseTimeoutError or whatever instead of ValueError or (ugh) Exception. Especially when you don't include an error string.

Maybe there are people creating exceptions that are too close to existing exceptions for no reason? Unless there is some weird huge overhead thing with custom exceptions I'm not seeing it either.

I don't have any opinions on this. Do what makes you comfortable. I don't think that there would be strong opinions on much of anything with the stack you choose from anyone in the community. Adaption is probably more important than getting into petty wars.


http://yogthos.net/blog/23

http://dev.clojure.org/display/doc/Getting+Started

Noir isn't "dead."

Not dead-set on anything. I just used Noir because it was what was I found that seemed good enough when I was at the bottom of my learning curve. This isn't to say that I would use Compujure right now. I honestly don't know.

Well, I did slip something past you. There has to be some state in the program. There simply is no way around that. Having a user login creates state, indicated by session/put! <--- The exclamation will always indicate mutation. In my code, there is session/get in two different places. While that particular value isn't mutated, the session state of the entire system is already in that one state.

The simple counter is... the very antithesis of FP and the cornerstone of understanding what it is that makes FP not IP.

This:

i = i + 1

...is mutation.

Consider a different viewpoint.

i = [1, 2, 3, 4.... inf]

In this case, i already owns all the values of 1 to inf, so suppose you ask the program what i is, and you get 1. You are never mutating the value of i, but you are simply asking what the next value in i is, which in this case is 2. There is never a mutation here. This is lazy evaluation. You can get creative and make i be multiples of 10 or squares or whatever. The point is that i is always this "infinite" value of values, but you are creating a sort of "promise" that i will always evaluate to the next value.

http://en.wikipedia.org/wiki/Lazy_ev...ata_structures

http://stackoverflow.com/questions/4...sequence-usage

http://clojure.org/sequences

http://stackoverflow.com/questions/4...ent-in-clojure

http://stackoverflow.com/questions/3...ted-in-clojure

http://en.wikipedia.org/wiki/Thunk_(delayed_computation)

You can also read this section of SICP for a deep overview of why mutation is considered bad in FP and how the equivalent is implemented. Clojure doesn't have streams, but close enough. It also gets into the issues of concurrency and comes to funky conclusion. Try reading this and the next page:

http://mitpress.mit.edu/sicp/full-te...ok-Z-H-23.html

Mind that the above is from 1996, and I'm not sure what progress has been made. I do think its interesting that Haskell, OCaml, and other "research" languages into concurrency are FP and (mostly) eschew mutation. Clojure is strongly derived from the research language arena.

Most of this gets over my head, but I think you may be confusing concurrency with parallelism; they are related, but they aren't the same thing. Even Clojure for all the talk of concurrency, doesn't have any silver bullets to solve the issues. I doubt any language makes concurrency or parallelism "easy."

You may be interested in Datamic, which is created by Hickey. The rational section rails against mutability. I haven't used it yet, but I've only seen good things about it judging from HN.

http://www.datomic.com/

Basically his argument is that the Python standard library uses only 165 exceptions in 200k LOC so at the very least you should think hard if you really need a new one. You should try to use existings ones whenever possible because programmers know them anyways.

He also had a couple of slides on naming exceptions that basically came down to "don't be redundant" i.e. BlahErrorException < BlahError etc.

Obviously these rules are not something to blindly follow but rather suggestions.
---
Dave iirc you posted something along the lines of "I kind of want to learn Prolog now". I just saw that Clojure actually has something like core.logic so maybe take a look at that. There's a book called "The Reasoned Schemer" which you could adopt to Clojure. Dunno much about Scheme/Clojure but the stated goal of the book is to teach functional programmers about logic and logic programmers about functional programming.

I'm not sure how they can claim it's not dead. The project isn't even using clojure 1.4. It's also using much older builds of ring and compojure.

The lazy seq for the counter seems nice.

Yep, there is no silver bullet. That's why in most cases people avoid the problem and keep state out of their app. Then multi-box scaling is dead simple, just throw more boxes at it without touching your app code.

There was an interesting slidecast from Wooga where they did the exact opposite with Erlang processes though. I don't know enough to make any conclusion. All I know is they managed to run like 250 million game requests a day with 12 medium amazon instances and when they switched to Erlang they replaced 80 ruby app servers with a single Erlang app server of the same size.

They kept all the state in the app process but I don't think that works with Clojure.

I agree that if you have an exception that is covered by an existing exception by all means you should use it instead of creating a new one (although even then it sometimes makes sense to extend it with your better named exception). But the argument about only 165 exceptions to 200K LOC seems silly to me.

This one seems reasonable to me.

Overall it just seemed like a weird point to bring up because its not something I've ever seen or heard of being a problem (as opposed to your example about like a one function python class) and even in the rare cases where it might be a problem there doesn't really seem to be much of a cost to it.

hi ive been given an algorithm (bubble sort) to test running times as n increases. Im a bit confused, as n gets larger, the runnning time gets larger, then it significantly drops as n gets larger, then starts to increase again. It doesnt make any sense why it would do this, also happens on my mates pc. (java and eclipse)..heres results...

Time taken to calculate input size 0 in the worst case is 467ns.
Time taken to calculate input size 50 in the worst case is 40118ns.
Time taken to calculate input size 100 in the worst case is 160006ns.
Time taken to calculate input size 150 in the worst case is 566320ns.
Time taken to calculate input size 200 in the worst case is 750585ns.
Time taken to calculate input size 250 in the worst case is 1278186ns.
Time taken to calculate input size 300 in the worst case is 1287517ns.
Time taken to calculate input size 350 in the worst case is 1808120ns.
Time taken to calculate input size 400 in the worst case is 2256886ns.
Time taken to calculate input size 450 in the worst case is 3264507ns.
Time taken to calculate input size 500 in the worst case is 1248332ns.
Time taken to calculate input size 550 in the worst case is 200125ns.
Time taken to calculate input size 600 in the worst case is 339605ns.
Time taken to calculate input size 650 in the worst case is 239310ns.
Time taken to calculate input size 700 in the worst case is 294823ns.
Time taken to calculate input size 750 in the worst case is 334941ns.
Time taken to calculate input size 800 in the worst case is 380657ns.
Time taken to calculate input size 850 in the worst case is 421242ns.
Time taken to calculate input size 900 in the worst case is 363863ns.
Time taken to calculate input size 950 in the worst case is 400716ns.

anybody tell me why this happens? i just took time at start of algorithm, and then at end, and then end-start=running time

there are like a million layers between your code and the cpu, so you're not going to be able to test algorithmic complexity this way.

yeh its what we thought and thought was a bit strange as its coursework that we have to do experiments on these results. Pretty weird having coursework like this when that^^

How many runs is that over? Looks like you'll need a bunch of runs to try and get a better value, besides, profs loves lots of data, makes it look like you tried...

is it possible hotspot is remembering its learned optimizations? i don't know if it works like that or not, just a thought

Disclaimer: I'm no java expert.

There is something going on with memory allocation or garbage collection or something. If I initialize 'a' to a length of 1000 before running the main loop, for example, I get a really long time for the "0" input size and everything else looks normal.

Another way to illustrate this is to reverse the order that you are making the calls - ie: Start with 950 and go down. The extra time is front-loaded in the first call still.

This is not a real issue. You can go into the ~/project.clj file and update all the dependencies. I'm using 1.4 in my project. You can also update ring and other stuff to the newest.

I'm nervous about using Leinengen 2: https://github.com/technomancy/leiningen/wiki/Upgrading

This is quite all strange. It appears that for all the speak about non-mutability, Clojure stops short of saying mutation is bad since it offers Actors, Locking, and other things like that. I think that the tools are there to do whatever you want, and there is nothing that says something must be done one way or the other. I do think that it is better to learn the FP basics before introducing mutation and other IP concepts. They both have their place.

I think Erlang is a pretty cool concept as well. It also has real use-case in massively scaled systems and about 20 years of research on it. I don't think it will be upended anytime soon. Clojure is pretty by-the-book in regards to its opinions and reasoning for its flavor of FP.

Oh, that's good then. I'm used to very explicit dependency versioning from node. If you put 1.3 then it expects and uses 1.3, 1.4 wouldn't work. If you wanted 1.3+, then you would have to put a > in there but there wouldn't be any guarantees of it working.

What makes you nervous about upgrading to 2? The guy who co-authored "Clojure Programming" mentioned in a video tutorial that it's solid and worth using. That was back in May.

I never used 1.x so I'm not sure how nasty it is to upgrade. I do think lein is awesome overall though. I've never included or removed deps in such an easy way before.

This guy just gave a talk at the LA Clojure group about noir-async, which is asynchronious web-library: https://github.com/andrewvc/noir-async

Is that inline with Node.js?

thankyou for your help. One last question i swear

ive been given functions where i have to enter different input size's and it returns a running time (we are not allowed to view these functions). Then i plot a graph and get 3 different graphs, quadtratic, linear, logorithmic. It then states using these results "Attempt to find a function of n to describe how they vary with n." per function. How do i do this just by looking at the running times and the input size?

tried googling, tried looking back through lecture slides, cant find out what im meant to do.

Any hints/link would be grateful

Burnss I'm confused, it seems you answered your own question. If the graphs are quadratic, linear and log, then aren't those your functions of n?

yeh i confused myself, my bad! seems pretty "hard" topic to get head around at the start!

I'm not sure. I haven't looked too much into async web servers for clojure. I believe netty is the main one, and aleph is built ontop of netty which seems to be what's being used by noir-async.

You have to write your code asynchronously to benefit from it though and the things you depend on can't be synchronous. That's why node is a good fit for that pattern. Everything is async. I imagine it would be close to the polar opposite with clojure.

The nice thing is though it seems both netty and aleph have ring adapters so you wouldn't have to drop ring to use them.

Not sure if its anything to do with the hurricane, but am finding access to UK(and european) websites is very slow today.

A lot of people in NY/NY-area got absolutely destroyed. Tons of people without power and huge damage/flooding.

Wouldn't surprise me if it had some connection.

Ye, it looks really bad.