Review our idea and MVP: Sell your Flickr photos - <AUTHOR>

Quick Summary:
Saas app allowing Flickr users to create a portfolio site automatically and Charge for them via Paypal.
MVP Site:
www.flickrcommerce.com
More details:
We(agiliq.com/whoweare) built it over a period of 24 hours, for the Yahoo Hack Day, Bangalore event. All code for this is open sourced at http://github.com/agiliq/yahoo-hack-day-2010 . I cant think of licences so we can keep this opensource, but still keep a reasonable competitive advantage, so I am open to suggestion there as well.
I am looking for feedback mostly on the idea, as we have a lot to work for the site. (But it should be usable anyway).
API's used.
Flickr API with flickrpy Paypal  Website standards payments (until we can get our Paypal app approved) Paypal adaptive payments.
Also this looks a very obvious idea to me, so I cant think of why this has not been done before. :)
(Also, if you have not looked at Paypal Adaptive Payments API, you should look at it. Its much saner than their older API, and allows some neat things like chained payments, which means you accept payments from a single user to a single user, and transparently split it, which means we can make a simple cost structure with percentage of Photos sold, without having an upfront charge.)
Edit: Also asked on onstartups: at http://answers.onstartups.com/questions/13098/review-this-idea-and-mvp-sell-your-flickr-photos <comment><USER2> Here's a bug report:

Hit the login with my flickr id, log in, get redirected to a non-existent page, because (for reasons of Yahoo!) my flickr ID has spaces in it.

My flickr page <http://www.flickr.com/photos/laprice/> and the page you construct for me is l.%20a.%20price.flickrcommerce.com It looks like you need to sanitise urls before recording them, or maybe you aren't using the correct field in the API but one that is usually OK, but not this time.

Any how, I would love to try it out, and having my photos be another income stream would help me to afford the lens habit I've acquired this summer.

<comment><AUTHOR> <http://laprice.flickrcommerce.com/>

Updated. Please set your Paypal username, that will allow to show the Paypal links.

<comment><USER2> OK, I've updated it. It works now.

A couple of things I notice about the rest of the application:

1\. using a square aspect ratio for presenting the pictures squashes some pics stretches others, it's not appropriate and looks really grotesque. You need to respect the work if you're presenting art.

2\. You're violating flickr's terms of service for the API; each picture should link back to the flickr page for that photo, that will get you shut down more quickly than having flickr in the domain name.

3\. I'm not exactly clear on what people would be buying with this. Are they getting a physical artifact (i.e. a print, a transparency, what?) Or just a download of the image at the largest size? If so, how is this any different than getty images?

4\. On the configuration page you left the admin documentation link in the template but didn't install the documentation, either remove the link to Documentation or make it go somewhere useful. And you provide no navigation back to the the user's page. Your admin workflow is fairly rough right at the moment, most people don't like to deal with more than 5+/-3 items at a time, throwing 24 items at once and not providing a means of grouping them is poor UI.

</comment></comment></comment><comment><USER3> The problem with selling of photos is that the owner is not "selling" the photo away, at least he would not be willing to in most practical situations.

What the owner sells is the "right to use the picture" and the price of the sale depends on where it is being published. If a college student wants to include it in his presentation, the owner would be willing to give away the permission for free and if Conde Nast wants to include it as a magazine cover, then the owner would be willing to charge a 1000 dollars.

Your assumption of "selling" the photos to some one for some fixed price, is not sufficiently sophisticated and is unlikely to appeal to the target audience, the photographers.

I think what you should do, at least for the start is: Allow the owner to sell the printed copies of their photographs and ship them, and donate all the profits to a social cause: <http://www.acumenfund.org/> This lets the photographer put up a banner saying, buy the printed copies of my photo and help the children in India get education.

</comment><comment><USER4> You might want to get a new name / domain. You may have problems using another company's name as part of your own.

<comment><AUTHOR> Agree with that. However, what would be a good way to show connection with Flickr, as it is a Flickr focussed site, without infringing on trademarks etc?

<comment><USER4> I wouldn't know, I'm not a lawyer. I imagine it's perfectly okay to use the word 'Flickr' to describe what your product does. "Sell your Flickr photos!" Just not to name your product.

</comment></comment></comment><comment><USER5> How will you promote this? The big challenge is getting the word out to people with Flickr accounts.

Another issue - I don't know if it's your problem or not - is people selling photos that don't belong to them by uploading copyrighted content to their flickr account and selling it from your site. But let's say someone buys an image without realizing it's copyrighted until after the purchase - do you allow them to get a refund or do you provide some way for them to report the problem?

</comment><comment><USER5> How long does it take for a Paypal app like this to get approved? Do you need a merchant acccount to act as an intermediary between the buyer and seller?

You mentioned that you are using Paypal Website Payments Standard "until you get your Paypal app approved". After it's approved, what happens? Will you have to pay a monthly fee (Website Payments Pro) to keep your Paypal app going?

<comment><AUTHOR> No merchant account needed. Paypal needs to enable App for adaptive payments. All business Paypal accounts have API access, which is the only thing needed for Website Standard.

Until we have the Adaptive app enabled, we cannot take a cut. (To enable payments to two accounts, we would need the buyer to authorize twice, which makes a much less seamless exp.)

With the adaptive payments API, user just needs to pay to one account, and the developer can split it between two Paypal accounts. After our app is approved we will move to Adaptive payments.

</comment></comment><comment><USER5> I like the design and the site seems responsive - who are you using for hosting?

<comment><AUTHOR> Design: We did. Hosting: Linode</comment></comment>


Trading two for one - A Monty Hall variant. - <AUTHOR>

Suppose I have ten cards, one of which represents a prize of great value. I shuffle them, spread them out face down, and let you choose any two. You take them, but you don't look at them.
I take the remaining eight cards and look at them. One by one, I show you six of them. I want to keep the tension high, so I definitely don't reveal the card of great value. After all, I might not have it.
After revealing those six of the cards, I have two, you have two, and I make you this offer:

    You can choose and keep one
    (but only one) of my cards,
    if you give me both of yours.

 Assuming this isn't a card trick, and that everything is as I've described - should you accept? <comment><USER2> From the outset when you take your cards you have a 2 in 10 (20%) chance of having the prize. The dealer has a 8 in 10 (80%) chance of having it. After the dealer looks at and discards six cards it is still a 8 in 10 (80%) chance.

I would trade my 20% chance for a 50/50 shot on the 80% chance which is 40%.

It's a good variation on the problem though. The thing is that the Monty Hall problem gets less intuitive when you deal with smaller numbers. When you're dealing with 10 cards you _feel_ like you probably don't have it to begin with. When it's 1 in 3, you feel like you're closer.

</comment><comment><AUTHOR> It's a great variant for teaching about probability, because switching is the right answer, even if you don't then get the prize. Sometimes you switch, but choose the wrong one of the two.

So for bonus points, what values of 10, 2 and 6 make this a 50-50 proposition? More particularly, what does the relationship between 10, 2 and 6 have to become?

</comment><comment><USER3> I'd accept, and expect to double my chances of winning the prize by doing so (from 20% to 40%).</comment>


Show HN: Weather and Clock app for Kids - <AUTHOR> http://www.kidoteca.com/weather-and-clock-for-kids/ <comment><USER2> Here's one data point: I just started playing the demo video and my little boy came running. He was smiling and really into it.

Definitely got something right with the sound effects and voices!

</comment><comment><USER3> First thought: Looks great, artwork is fantastic.

Second thought: I don't have kids and maybe I don't have a clue, but I wonder whether kids will understand it, especially the concept of numeric temperatures. What age group are you aiming this at? I could imagine that for kids it would be more valuable to explain the weather ("It's gonna snow", "Warm enough for T-Shirts", "Don't forget your umbrella"...). Or maybe explain the numbers ("temperature is in the high 90s - that means that it's so hot your going to sweat").

<comment><AUTHOR> It shows the weather in the window, and graphics change (for example if it is raining the character grabs a umbrella).

Also if you tap any text, speech happen.

The purpose of this is teach kids the meaning of the numbers on this context.

This is why it has two clocks too (one analog and one digital)

</comment></comment><comment><USER4> I was at my daughter's end of term assembly last week, and a younger sibling from another family was getting tetchy.

I had your Matroska (sp?) game on my phone and she loved it, and I got to hear the assembly :-)

<comment><AUTHOR> Thanks :)

Right now we got suddenly bogged by OEM work (ie: some manufacturers want to ship our apps on their stuff), but as soon as we finish that we will release a new version of the Matryoshka (with 9 dolls instead of 3, plus a challenge mode of sorts).

</comment></comment><comment><USER5> Nice!

One comment: At :45, when the character clicked the clock at "02:28 pm" the voice read it as "2 hours 28 minutes". Probably need a better time->text conversion.

<comment><AUTHOR> The non-formal english rules for time are absurdly crazy (At least to me), so I went with normal rules that all other countries use...

Maybe one day I will take my time to figure how US people speak the time.

<comment><USER5> In US English the example would be "two twenty-eight pm". This appears sane to me. The only complexity is for a single-digit minute, in which case you pronounce the 0 as "oh": "two oh-eight pm". I guess you have the exact hour, too: "2 o'clock".

Is there really a country that says "2 hours 28 minutes" for 2:28 pm? Omitting "pm" seems to leave it underspecified unless you have a locale that uses 24-hour time starting at noon.

If you want complex time rules, in colloquial Thai the day is broken up into roughly 6-hour periods, with a flexible additional split in afternoon/evening...

<comment><AUTHOR> Oh, what you are complaining is the lack of PM.

I thought you was referring to crazy phrases (to me) of 3 hours and a quarter

Or half past 6 or something like that. (or 7 o clock)

There are no am/pm spoken because only US use am/pm format, in all other countries the default is 24-hour actually. So I think I missed that.

Maybe in the future I will implement am/pm spoken :)

<comment><USER6> I think his complaint was that "2:28" would be said as "two twenty-eight" in America, as opposed to "two hours twenty-eight minutes"</comment></comment></comment></comment></comment>


Builders of Obama's health website saw red flags - <AUTHOR> http://wtop.com/289/3488122/Obamacare-site-builders-saw-red-flags

<comment><AUTHOR> "Crammed into conference rooms with pizza for dinner, some programmers building the Obama administration's showcase health insurance website were growing increasingly stressed. Some worked past 10 p.m., energy drinks in hand. Others rewrote computer code over and over to meet what they considered last-minute requests for changes from the government or other contractors."

<comment><USER2> Per the NYT " _In the last 10 months alone, government documents show, officials modified hardware and software requirements for the exchange seven times._ " ([https://news.ycombinator.com/item?id=6583327](https://news.ycombinator.com/item?id=6583327)), and from multiple sources we've heard those change orders continued through the last week before the launch.

They're not the only ones who "consider" these to be "last-minute requests for changes from the government", which decided to be the integrator, including testing per the AP, for this effort (HHS's CMMS, a unit with no particular expertise in that).</comment></comment>


The Utah Teapot: Most Important Object in Computer Graphics History - <AUTHOR> http://nautil.us/blog/the-most-important-object-in-computer-graphics-history-is-this-teapot <comment><USER2> Also of note: Around the same time, University of Utah students created the first ever computer graphics generated picture that looks like its physical model: Marsha Sutherland's (Ivan Sutherland's wife) VW Bug [1].

The VW was hand measured by Sutherland's students: Jim Clark (of SGI/Netscape fame), Bui-Tui Phong (of Phong shading fame), Raphel Rom (of Catmull-Rom spline fame), and Robert McDermott (of Vegreville Egg fame). (I just listed some highlights of careers, they all accomplished much more!)

A first hand account of the model creation is preserved by Mr. McDermott on page 7 of the Fall 2003 edition of The Utah Teapot [2] (the aptly named University of Utah School of Computing quarterly newsletter).

The CS Dept. at the U of Utah has such a storied history, especially rich in fundamental computer graphics research [3]. Growing up in proximity to it definitely shaped my career path.

[1] [http://jalopnik.com/the-first-real-object-ever-3d-scanned- an...](http://jalopnik.com/the-first-real-object-ever-3d-scanned-and-rendered- was-494241353)

[2] [http://www.cs.utah.edu/docs/misc/Uteapot03.pdf](http://www.cs.utah.edu/docs/misc/Uteapot03.pdf)

[3] [http://www.cs.utah.edu/about/history](http://www.cs.utah.edu/about/history)

</comment><comment><USER3>
      > Back in his lab, he entered the sketched coordinates—called bézier
      > control points, first used in the design of automobile bodies—on a
      > Tektronix storage tube, an early computer memory.

Urg. Not a 'memory' in the computer sense, not being readable by the computer. What this means is that he used a Tektronix graphics terminal that had a self- persisting CRT display.¹

¹ [https://en.wikipedia.org/wiki/Direct- view_bistable_storage_t...](https://en.wikipedia.org/wiki/Direct- view_bistable_storage_tube)

 _Edit_ : Teapot on a Tektronix 4014: [https://youtu.be/bZOrL7f1-kE](https://youtu.be/bZOrL7f1-kE)

<comment><USER4> Incidentally, there was in fact CRT-based RAM at one time: [https://en.wikipedia.org/wiki/Williams_tube?wprov=sfla1](https://en.wikipedia.org/wiki/Williams_tube?wprov=sfla1)

</comment></comment><comment> david-given Yep, the Teapot is one of the highlights of the Computer History Museum in Mountain View. Possibly the most exciting teapot I've ever seen!

[https://goo.gl/photos/quo8W9BE75VQqkmr6](https://goo.gl/photos/quo8W9BE75VQqkmr6)

Other highlights include the working Babbage Engine, with a rather good lecture.

Antihighlights include the otherwise excellent display on the history of integrated circuits, sponsored by Intel, which doesn't mention ARM in any way anywhere...

The museum's totally worth a look if you're there.

<comment><USER5> Do they have a life-size wax figure of Lena Söderberg [1]? If not, someone should donate the money for one.

[1] [http://www.cs.cmu.edu/~chuck/lennapg/lenna.shtml](http://www.cs.cmu.edu/~chuck/lennapg/lenna.shtml)

<comment><USER6> Bear in mind [https://en.wikipedia.org/wiki/Lenna#Controversy](https://en.wikipedia.org/wiki/Lenna#Controversy)

</comment></comment></comment><comment><USER7> This teapot is the graphics and rendering equivalent of the image processing worlds "Lena" image (albeit with a less racy backstory)

<comment><USER8> I've wanted to compile a list of canonical simplified problem settings in various fields. Their longevity is interesting to me.

Things like the relativistic boxcars in physics, the urns and balls in probability ([http://www.arcaneknowledge.org/science/ehrenfest.html](http://www.arcaneknowledge.org/science/ehrenfest.html)), the teapot, Lena, blocks-world in AI.

<comment><USER9> Alice and Bob and Carol in cryptography.

<comment><USER8> Exactly!

</comment></comment></comment></comment><comment><USER10> I feel like the Stanford Bunny should get an honourable mention too.

[https://en.m.wikipedia.org/wiki/Stanford_bunny](https://en.m.wikipedia.org/wiki/Stanford_bunny)

<comment><USER11> And the Beetle: [http://www.wired.com/2013/05/augmented-reality-the-ivan- suth...](http://www.wired.com/2013/05/augmented-reality-the-ivan-sutherland- scanned-1967-vw-beetle/) .

</comment></comment><comment><USER12> The original is in a museum? I thought I read that it was in orbit somewhere between the orbits of Earth and Mars...

<comment><USER13> That's just some ancient book saying it.

<comment><USER12> So? The vast majority of people agree that's what happened to it.

</comment></comment></comment><comment><USER14> When I was in high school the U had a summer school where you would use their alpha_1 software for graphics modeling.

alpha_1 was a system going back to the 1980 designed specifically for modeling with NURBS: [https://www.cs.utah.edu/gdc/projects/alpha1/help/man/html/in...](https://www.cs.utah.edu/gdc/projects/alpha1/help/man/html/intro.html)

<comment><USER2> Yes, the UofU High School Ccomputing Institute [1]. I was accepted in '96 but already working a summer job in research park at the time (at a company w/ a commercial NURBS package) and didn't ever build a model. The coolest part is they would 3D print your model long before it being the commodity that it is today.

It'd be interesting to see a follow-up on the HSCI alumni and where they are now.

[1] [http://www.cs.utah.edu/~rma/hci/cs/hsci.html](http://www.cs.utah.edu/~rma/hci/cs/hsci.html)

<comment><USER14> I was in 2002, the last class I think. In fact, I can't find any reference anymore to the later classes. It used to be maintained, but it's disappeared.

I also recently noticed that websites historically hosted on home.utah.edu were removed. I was going to find my old model (a model of Escher's Belvedere) but it's now gone.

edit:

my model: [http://imgur.com/VqPVSAj](http://imgur.com/VqPVSAj)

<comment><USER2> Yes, 2002 was the last year. Prof. Dave Hanscom ran the HSCI from 1990 to 2002 [1].

I checked the Wayback Machine (archive.org), but unfortunately it doesn't have those pages mirrored. It's very sad that this history seems to be getting lost. At least one prestigious alumni (HSCI '92) that of I'm aware of is Berkeley Prof. Alexei Efros [2].

Awesome model! It's definitely one of the best ones I've seen from that program.

[1] [http://www.cs.utah.edu/~hanscom/](http://www.cs.utah.edu/~hanscom/)

[2] [http://www.eecs.berkeley.edu/~efros/](http://www.eecs.berkeley.edu/~efros/)

<comment><USER15> [http://web.archive.org/web/*/http://www.cs.utah.edu/~hanscom...](http://web.archive.org/web/*/http://www.cs.utah.edu/~hanscom/) shows 100 captures? And for the original HSCI main page, [http://web.archive.org/web/*/http://www.cs.utah.edu/~hsci/](http://web.archive.org/web/*/http://www.cs.utah.edu/~hsci/) there are 86 captures. Looking at Summer 2002, it appears that the hsci pages moved to [http://web.archive.org/web/*/http://www.eng.utah.edu/outreac...](http://web.archive.org/web/*/http://www.eng.utah.edu/outreach/hsci/) which has 64 captures.

Yes, the final captures of hsci all say "page not found" (soft 404), but the earlier ones are fine.

<comment><USER14> Thanks! I was looking for ece.utah.edu, I knew there was another domain involved.

</comment></comment></comment></comment></comment></comment><comment><USER16> Pixar gives out wind-up teapots at Siggraph each year.

[http://pixartimes.com/2013/08/01/video-a-look-at-pixars- coll...](http://pixartimes.com/2013/08/01/video-a-look-at-pixars-collectible- renderman-teapots/)

</comment><comment><USER17> Just a little trivia: the original model for the teapot did not have a bottom.

<comment><USER18> I imagine making a cuppa would go pourly.

<comment><USER19> This is potentially the most British joke possible.

</comment></comment></comment><comment><USER20> I remember my first time to the Computer History Museum, was wondering through and suddenly saw the teapot. I was stopped in my tracks.

</comment><comment><USER21> Way back (well, just shy of a decade ago) in my CompSci Signal and Image Processing course I got to know this teapot very, very well. Even created a 3-dimensional solar system of orbiting teapots that mimicked the exact orbits and rotations of the planets. Think I posted it on GitHub somewhere, too.

<comment><USER22> Whenever I read about Russell's Teapot, I envision it as a Utah teapot specifically.

</comment></comment><comment><USER23> Didn't realise it was a long standing graphics in joke. Reading this took me back 20 years to my time as an AVS/Express developer. AVS used the teapot as a standard object for testing geometry pipelines.

</comment><comment><USER24> Teapots are everywhere: [http://www.google.com/teapot](http://www.google.com/teapot)

<comment><USER25> Nice. On mobile, tilt your device.

<comment><USER26> Can also use the Chrome inspector to tilt it (set γ to negative values) [https://developer.chrome.com/devtools/docs/device- mode#devic...](https://developer.chrome.com/devtools/docs/device-mode#device- sensors)

</comment></comment></comment><comment><USER27> The Stanford bunny is a close second. It is used everywhere in SIGGRAPH demos.

</comment><comment><USER28> I had the privilege of working g with Martin for a while once. The guy is one of those brilliant folks who is also incredibly humble, friendly, and happy to teach things to newbies. And he's really funny.

</comment><comment><USER29> Goes beyond computer graphics. See HTTP status 418.

</comment><comment><USER30> Best article on HN I have read in a while. I always wondered where that teapot came from.

</comment><comment><USER31> too bad the handle on the lid looks nothing like the real tea pot it was modeled off...</comment>


Man to plead guilty to sending a strobing GIF to a reporter who has epilepsy - <AUTHOR> https://www.nytimes.com/2019/12/16/us/strobe-attack-epilepsy.html <comment><USER2> Related discussion around the original arrest in 2017: [https://news.ycombinator.com/item?id=13918892](https://news.ycombinator.com/item?id=13918892)

</comment><comment><USER3> Well that was dumb, but not a first amendment issue?

<comment><USER4> There are limitations on free speech, particularly speech that directly harms people - thus no shouting fire in a crowded theater.

That's if you even consider this speech, which seems iffy at best.

<comment><USER5> The "no shouting fire in a crowded theater" quote isn't good law, and hasn't been for 50 years: [https://www.theatlantic.com/national/archive/2012/11/its- tim...](https://www.theatlantic.com/national/archive/2012/11/its-time-to-stop- using-the-fire-in-a-crowded-theater-quote/264449/)

</comment></comment></comment><comment><USER6> Obviously I couldn't resist and googled to check what's out there. My eyes are melting...</comment>


Modern HTML Presentations with deck.js - <AUTHOR> https://github.com/imakewebthings/deck.js

<comment><USER2> Previously on HN (54 days ago, 62 comments): <http://news.ycombinator.com/item?id=2916352></comment>


Unix - The Hole Hawg - <AUTHOR> http://www.team.net/mjb/hawg.html

<comment><USER2> If you have patience, you will probably find like I did that anything computers can be understood without resorting to analogies, and that understanding is deeper without them. Stephenson's nonfiction about computers is _all_ analogies and hyperbole. It might be fun to read, but it will not tend to increase your understanding.

<comment><USER3> Metaphors and analogies are good tools for conveying subtler meanings that may not be evident at first sight.

</comment></comment><comment><USER4> The Hole Hawg analogy is also used in Stephenson's _In the Beginning was the Command Line_. He used to provide the text for free but I can't seem to find the link anymore. <http://www.nealstephenson.com/command/>

</comment><comment><USER5> The only problem is that OS X is a UNIX operating system.

<comment><USER6> He wrote it before OS X was released.</comment></comment>


Steve Yegge v. Rich Hickey re: "Clojure just needs to start saying Yes" - <AUTHOR> http://groups.google.com/group/seajure/msg/2d2ec7ac9f2b4713 <comment><USER2> One of my favorite things about Clojure is the things it's said "yes" to, as first-class language builtins: char, vector, set, and map notation; first class "vars" (actually thread locals), ways to manage and dereference state, Java interop that doesn't set your hair on fire, namespaces, keywords and namespaced keywords, and a whole bunch of features I'm probably forgetting.

Instead, Steve Yegge is asking for things that don't seem terribly important to me. Excluding loops from the language core is obvious; Clojure makes it really easy to use the functional style instead and loops would serve as a newbie trap. For the last two weeks I've been programming Clojure full-time and haven't used a single loop macro or loop-recur. He complains about the lack of circular dependencies; but no circular dependencies across namespaces is A Good Thing just as you shouldn't have circular dependencies across Java packages or C++ libraries. The guy he cites who declared macros evil is obviously not a part of 'mainstream' Clojure culture, and maybe someone can explain Yegge's anger about single-pass compilation, because I don't get it.

And of course, Clojure is a highly extensible language that has _implicitly_ said Yes to a vast ideascape.

<comment><USER3> I'm astonished to discover Clojure _does_ do single-pass compilation. It used to be done primarily because some intermediate representations of programs could not fit entirely in memory, but virtually every compiler now is multi- pass because so many optimization opportunities are lost otherwise.

I have minimum knowledge of Clojure, so is there some motivation for single- pass other than perhaps simplicity?

Edit: A brief outline of the tradeoffs: [http://en.wikipedia.org/wiki/Compiler#One- pass_versus_multi-...](http://en.wikipedia.org/wiki/Compiler#One- pass_versus_multi-pass_compilers)

<comment><USER4> The issue is not single-pass vs multi-pass. It is instead, what constitutes a compilation unit, i.e., a pass over what?

Clojure, like many Lisps before it, does not have a strong notion of a compilation unit. Lisps were designed to receive a set of interactions/forms via a REPL, not to compile files/modules/programs etc. This means you can build up a Lisp program interactively in very small pieces, switching between namespaces as you go, etc. It is a very valuable part of the Lisp programming experience. It implies that you can stream fragments of Lisp programs as small as a single form over sockets, and have them be compiled and evaluated as they arrive. It implies that you can define a macro and immediately have the compiler incorporate it in the compilation of the next form, or evaluate some small section of an otherwise broken file. Etc, etc. That "joke from the 1980's" still has legs, and can enable things large-unit/multi-unit compilers cannot. FWIW, Clojure's compiler is two-pass, but the units are tiny (top- level forms).

What Yegge is really asking for is multi-unit (and larger unit) compilation for circular reference, whereby one unit can refer to another, and vice versa, and the compilation of both units will leave hanging some references that can only be resolved after consideration of the other, and tying things together in a subsequent 'pass'. What would constitute such a unit in Clojure? Should Clojure start requiring files and defining semantics for them? (it does not now)

Forward reference need not require multi-pass nor compilation units. Common Lisp allows references to undeclared and undefined things, and generates runtime errors should they not be defined by then. Clojure could have taken the same approach. The tradeoffs with that are as follows:

1) less help at compilation time 2) interning clashes

While #1 is arguably the fundamental dynamic language tradeoff, there is no doubt that this checking is convenient and useful. Clojure supports 'declare' so you are not forced to define your functions in any particular order.

#2 is the devil in the details. Clojure, like Common Lisp, is designed to be compiled, and does not in general look things up by name at runtime. (You can of course design fast languages that look things up, as do good Smalltalk implementations, but remember these languages focus on dealing with dictionary-carrying objects, Lisps do not). So, both Clojure and CL reify names into things whose addresses can be bound in the compiled code (symbols for CL, vars for Clojure). These reified things are 'interned', such that any reference to the same name refers to the same object, and thus compilation can proceed referring to things whose values are not yet defined.

But, what should happen here, when the compiler has never before seen bar?

        (defn foo [] (bar))

or in CL:

        (defun foo () (bar))

CL happily compiles it, and if bar is never defined, a runtime error will occur. Ok, but, what reified thing (symbol) did it use for bar during compilation? The symbol it interned when the form was read. So, what happens when you get the runtime error and realize that bar is defined in another package you forgot to import. You try to import other-package and, BAM!, another error - conflict, other-package:bar conflicts with read-in- package:bar. Then you go learn about uninterning.

In Clojure, the form doesn't compile, you get a message, and no var is interned for bar. You require other-namespace and continue.

I vastly prefer this experience, and so made these tradeoffs. Many other benefits came about from using a non-interning reader, and interning only on definition/declaration. I'm not inclined to give them up, nor the benefits mentioned earlier, in order to support circular reference.

Rich

<comment><USER5> Most of the user annoyance vanishes if declare were to support qualified names: (declare other-namespace/symbol). Is there a technical limitation here?

-steve

<comment><USER4> One problem is what to do if the other-namespace doesn't already exist. It would have to be created, and that initialization is unlikely to be the same as the declared one. Possibly follow-on effects when it is subsequently required. The other option, with similar issues, is to allow fully qualified references to non-existent vars in code.

<comment><USER6> If it doesn't already exist, _then_ you issue a compilation error. Better then than the way it works today, IMO.

</comment></comment></comment></comment></comment></comment><comment><USER7> I don't know much about Clojure, but I know an argument from authority when I see it, and Yegge is making an argument from authority. He does a lot of, "You need users and you don't know anything about language marketing and building an ecosystem." With the implication being that Yegge _does_ know all about language marketing. I'm disappointed Yegge would go there...he's a smart guy. But, we all have bad days.

Unfortunately for Yegge's argument, he's never built a sizable language ecosystem from scratch, while Hickey _has_. So, he's making an argument based on authority that he doesn't have and the person he's arguing with _does_.

Hickey has done a brilliant job stripping off all the "I know better than you" bits of Yegge's comments, and brings it back down to the discussion of the language and nothing else. Frankly, it was pretty devastating, and I'm surprised Yegge walked so cockily into it. If I had any dogs in this fight, I know whose side I'd be taking.

<comment><USER8> According to his post to the list, Mr. Yegge is responsible for the attitude transplant that the Python community has experienced. It's amazing what he can accomplish from his desk, dashing off memos to language communities. Jack Welch wishes he had that kind of power as CEO of GE.

The most puzzling thing he says is that Clojure's language adoption efforts have been a failure because Clojure is _over three years old_ and hasn't broken the top ten in some pointless programming language survey.

How long did it take Python to get there? I'm guessing at least a decade. And does it even matter?

<comment><USER9> The issue with Clojure is that it really gained too much popularity before it was ready. Ready has a lot of implications. IDE support, debuggers, libraries, documentation, books, etc. While it is a good language and has a number of things going for it. It seems that the books and community added too much hype too soon. This caused new users to come, then go.

<comment><USER8> I don't know if I agree with you that Clojure's too popular right now, but I completely agree with you that the phenomenon exists in general. Rails back in the early days experienced a huge influx of PHP refugees, who significantly lowered the signal-to-noise ratio in the community.

I use a language's Freenode channel is a general barometer of the state of its community's health, and I notice no more questions from bandwagon jumpers _who have no clue whatsoever of what they're getting into_ on #clojure than I ever did on #scheme. I use those two channels for comparison because the sort of questions in question are similar: based on received assumptions that are counterproductive to being effective.

</comment></comment></comment></comment><comment><USER10> Good discussion. I agree with Rich in principle: a language's design should not say "yes" to everything, but I agree with Steve in some of the particulars.

After programming in Clojure for two weeks, I had a list of complaints about the language. It has now been two years, and nearly all of my objections went away as the language evolved and as I adapted to using it. Two years later, I just have two notable things to grumble about. Coincidentally, they seem to be closely related to Steve Yegge's concerns.

1\. No condition system. This is a big deal. Clojure piggy-backs on Java's exceptions, and currently lacks a good mechanism for user-defined error handling. Unfortunately, Java exception handling also happens to suck, since it throws away data in all stack frames from the throw to the catch. Implementing better error handling is under discussion on the Clojure development page (<http://dev.clojure.org/display/design/Error+Handling>). (Steve complains about the lack of non-local transfer of control, and he has a point: it could be used to make an arbitrarily powerful condition system, see [http://www.nhplace.com/kent/Papers/Condition- Handling-2001.h...](http://www.nhplace.com/kent/Papers/Condition- Handling-2001.html)).

2\. No built-in debugger. The way CL code doesn't just crash and throw away stack information is amazing. The lack of this feature in other languages is appalling.

In addition, I sort of agree that being forced to forward-declare things is annoying. I got used to it, but I don't really like the restriction. I do understand the reason behind it, though: auto-interning symbols in the reader (as Common Lisp does) can be confusing and occasionally problematic.

</comment><comment><USER11> This is a fascinating case study. I got sucked into reading the entire thread. Steve Yegge is talking about cultural and marketing issues that seem obvious to me. The responses on the list may not be representative of the community, but assuming they are, one can hazard a guess about the long-term trend: there's a clear failure to connect with what Yegge is saying. (Edit: I deleted an unnecessarily personal example here.)

Yegge isn't arguing for the abandonment of taste and rigour in a race to incorporate every kitchen appliance into the language. He's arguing that languages and communities that take a prescriptive (someone said "paternalistic") stance end up marginalizing themselves by their own rigidity, and that the antidote for this -- as well as the passageway toward wider adoption -- is to actively listen to and court new users. I couldn't agree more.

(Side note, this is why I like Common Lisp. Its loosey-goosey flexibility that always assumes the programmer knows best leads to an awesome fluidity that finds its around any obstacle. CL is unpopular, but not because of its pluralism. Qua language it has a deep respect for the user.)

There's another point here. Whether you're a fan of Steve Yegge or not (I didn't use to be, but after nodding with everything he said here I am now), he has a proven ability to mobilize a significant body of programmer opinion. To ignore what this guy says about the marketing of programming languages itself already displays a foolish disregard for the market.

<comment><USER12> I think Python is both prescriptive and widely popular.

<comment><USER13> It's also one of the more readable languages in existence and it's implicitly championed by an IT juggernaut.

<comment><USER14> Not for production code it isn't.

<comment><USER15> As compared to ? Python is very popular.

</comment></comment></comment></comment></comment><comment><USER16> I'm not sure why Yegge is talking about the Shangri-la of non-local exits, but... He is right that the culture of Clojure has some issues and often rejects ideas even when they're obvious, and it's not clear why.

Examples I've run into:

1\. The current clojure lambda shortcut-syntax is atrocious, and we can do better. Why don't we do better?

2\. Clojure could really benefit from a scheme-esque Macro-by-example library. A few exist but they seem largely ignored by the community; despite well- known-benefits to such a system in the normal daily use of macros.

3\. A strange hatred of macros. Yes, some people are reasonable and argue that functions should have primacy over macros because of composability (and they're right). But then there are people who will tell you macros are always bad, and if you show up in freenode #clojure to ask for help with them they will _actively laugh at you._

I love Clojure and I feel like I know it pretty well, so I'm not trying to say Clojure is considered harmful, etc. But I do think that some of Yegge's criticisms—while poorly delivered and sometimes poorly expressed—have an element of truth to them.

* _Full disclosure: I was involved in an effort to write a Clojure book for O'Reilly until I got involved with a new startup and had to terminate my involvement in the effort. I may not be the most unbiased judge of Clojure._

<comment><USER11> _if you show up in freenode #clojure to ask for help with them they will actively laugh at you_

Oh dear. That is a bad sign. It has always seemed to me that building a healthier community from the ground up was the biggest thing a successful new Lisp would have to offer. The behavior you describe is all too reminiscent. No one should _ever_ be "actively laughed at" for asking an honest question, and Clojure experts (if they know what's good for them) ought to take an aggressive stance against that kind of behavior. These communities are delicate things. They can become diseased.

It makes me mad to see anyone get "actively laughed at", let alone by bullies who assuage the beast of their own insecurity by doing the intellectual equivalent of beating up children.

Edit: oh, and: they're being laughed at for asking about macros? This _is_ a Lisp, right?

<comment><USER14> The best way to deal with trolls is to simply not feed them. My experience on Clojure IRC the past 3 years is that its orders of magnitude less condescending than the Python, Ruby, or Node.js IRC channels.

<comment><USER16> I won't name names, but you'd know the names I could name. It is true that, so long as you stay away from a few key third rails, the #clojure channel is generally a great place. One need only to go to #scala on a bad day to see what a few bad actors can do to make a place feel oppressive.

There's no value in such arguments tho. It's an undeniable truth that the Clojure community (and its libraries) are far less macro-friendly and macro- centric than other lisps. Even PLT Scheme seems more comfortable with defmacro usage.

<comment><USER17> There's a joke here about Scala and actors, I'm just sure of it.

</comment></comment></comment></comment></comment><comment><USER18> Oh god I so hope that Rich ignores this. A "just say yes" mindset is incredibly dangerous; yeah, ok, a trillion people use C++ but that doesn't make it a good language. Clojure to date has been built with great discipline, and it would be _tragic_ to see it go off those rails in the hopes of satisfying a huge mass-market that a) Clojure is fundamentally unsuited for and b) will never be happy regardless. When I say that Clojure is fundamentally unsuited for a certain "mass-market" I don't mean that it shouldn't or won't catch on and into i.e., the TIOBE top 10 -- just that it can't be everything to everyone, and shouldn't try to be. It's a wonderful language that understands what it tries to be, and I hope the Rich never forgets those underlying intuitions on (state, identity, functionalism). Abandoning that discipline own't make it any more powerful, but will just muddy the language to try and satisfy people who won't be impressed because of it.

</comment><comment><USER19> Youngme Moon, in her book "Different", offers the idea that one should say Yes where others say No, and No where others say Yes to produce meaningful difference. Once you go this way, you iterate and improve on the ways you say Yes to accentuate the difference. There are similar suggestions in other recent books on differentiation (Moore's "Dealing with Darwin", for example)

Look at all the ways Clojure says Yes, where other lisps/languages have said no. Being a lisp, embracing the JVM, immutable by default and everywhere, first-class concurrent primitives -- clojure should probably say No if it compromises these core goals. It should say YES when it furthers these tenets.

I don't use it enough to really understand Yegge's gripes, but the best move for clojure is probably to make these things possible as libraries if it doesn't want to embrace it in the core, and iterate on the core so that it's the only possible choice when you are in the situation that requires it.

</comment><comment><USER20> If you can't say no, what do you say to the users who are begging you to say no because they like the language as it is? Every language design decision is a compromise, and a person empowered to make those decisions is going to make people unhappy. Just look at Perl and Python: Perl said no to people who demanded orthogonality, and Python said no to people who wanted a free-for-all TIMTOWTDI language. Java said no to deterministic finalizers. C++ said no to exceptions that could be restarted. All those languages are doing fine.

A better idea would be to never turn your back on any class of users -- ignoring their specific requests, perhaps, but always making sure they can solve their problem using their language. Even that strategy doesn't require language support for everything. CPython does just fine with the scientific computing community by punting to C bindings, for example.

The examples Yegge provides don't make any sense to me. The need to port Java code to Clojure is questionable, since Clojure provides good Java bindings. If you want a more Clojure-y version of a Java library, then a straight line-for- line port is not much of an improvement. As for the LOOP macro, you don't have to add everybody's little helper function into the standard library. I'm a big fan of languages adding helper functions to standard libraries if there's one obvious way to write them and the act of adding them will save everyone else from including their own version in all their projects, but a LOOP macro is absolutely NOT that.

(Unless it's just a straight-up reimplementation of Common Lisp's LOOP macro, which would do exactly one job, which is allowing Common Lisp programmers to be more comfortable in Clojure. Hey, guess what -- Common Lisp programmers already have one of the easiest paths to learning Clojure, since they know a Lisp already. Many non-Lisp programmers are tackling the learning curve and embracing Clojure, so CLers can't complain that it's too hard. Plus, many Common Lisp fans regard LOOP as an abomination and never use it anyway. Writing control structures in a complex DSL that few programmers bother to learn completely is not one of Common Lisp's best features. Saying "no" to a Common Lisp-style LOOP macro would be the right thing to do.)

<comment><USER21> _I_ like Common Lisp's LOOP, personally.

<comment><USER22> It is an abomination until you learn how to use it, then it is completely awesome.

<comment><USER23> Everything is an abomination until you learn how to use it.

The difficulty with loop is it takes something trivial and makes it more complex than it needs to be. Simple things are not simple. Complex things are rare and loop doesn't simplify them enough.

<comment><USER22> That might be true. It is indeed complex if you look at the BNF in the hyper- spec. ([http://www.lispworks.com/documentation/HyperSpec/Body/m_loop...](http://www.lispworks.com/documentation/HyperSpec/Body/m_loop.htm))

If you ignore the hyperspec, however, and get a feel for it by looking at examples and writing code using it, it becomes quite simple. It is very useful when you are translating C or Java code.

(<http://www.unixuser.org/~euske/doc/cl/loop.html>)

I find it quite readable in comparison to many of common lisp alternatives for iteration. And I kind of disagree that simple things aren't simple.

For example: (loop for i from 0 below 10 do ...)

Is pretty much the simplest construct that you normally need. Granted, I would likely just use dotimes in that case... but lets say you are iterating between 5 and 15, dotimes becomes unwieldy, where the for loop is pretty much the same code with the numbers changed.

(loop for i from 5 below 15 do ....)

Now try incrementing by 2

(loop for i from 5 below 15 by 2 do ....)

compare to the similar do* code

(do* ((i 5 (+ i 2)))

        ((>= i 15))

      ....)

kind of a toss up to me.

Not that I don't understand your point... in fact, as little as a year ago, I felt that way too... but I have since changed my mind.

My current preference is to use do* if writing a macro that needs iteration, and to use loop when I am doing something similar to a list comprehension or array traversal.

</comment></comment></comment></comment></comment><comment><USER24> Yegge points to the Tiobe language index as a metric to language adoption, and implies that "No" languages have low uptake. What about Lua? The Lua implementers don't accept public patches, rather they will rewrite public patches that are submitted, and only if the change makes sense (citation: <http://lua-users.org/lists/lua-l/2008-06/msg00407.html>). Yet Lua is #12, up from 20.

Saying "no" to language suggestions is not a bad thing, it all depends on the goals of the language and the philosophy of the language authors. Perhaps Yegge should try and understand the reasons why patches aren't accepted, rather than force their acceptance via his soapbox.

<comment><USER25> Lua is probably a bit of a special case, as it grew extremely popular due to its original niche (trivial integration in complex C and C++ projects): Lua was born in 1993, and started getting used in big-name games in the late 90s already (Baldur's Gate was scripted in Lua in 1998, so was Grim Fandango the same year). From there, it took over most of the gaming industry and could only leak out as a popular language.

<comment><USER26> the other point of view is that that makes it nothing more than the new tcl, and tcl managed to lose its popularity.

<comment><USER25> tcl lost its popularity because it was displaced. By Lua. Because Lua had a lower dissonance with C and C++ (actual data types & al, for instance).

Could lua itself be displaced? Sure, but there's no contender I see right now. And I don't think that's an other point of view.

<comment><USER26> from what i remember, tcl's popularity waned long before lua caught on in a big way. people were looking to ruby and python as extension languages, even though they had a far higher impedance mismatch than tcl, simply because they were vastly more popular as languages by then

</comment></comment></comment></comment></comment><comment><USER27> I'd say be careful about reading into this thread too much. It's a public, ad hoc discussion, and won't be as carefully phrased or researched as a blog entry. Cherry-picking one quote, like "Clojure just needs to start saying yes" from a discussion like that and treating it like a mantra doesn't improve discussion nor is it fair to any of the participants.

It's an interesting thread, I'm glad it was linked, but take it for what it really is. Hickey's response is a good counter-argument to "languages should always say yes" but basically ignores any of the other subtleties of the discussion. His comment is a starting point, but he hasn't engaged and no one has responded (yet).

<comment><AUTHOR> I actually thought it was as fair and representative a quote as I could pull from the discussion; my apologies to Mr. Yegge if it's uncharitable from his perspective.

<comment><USER27> I understand, you've got a very limited space to work with. Just saying that anyone following the link should take your heading with the grain of salt it deserves.

(And the point is much less relevant now that Rich and Steve have both continued the discussion here)

</comment></comment></comment><comment><USER28> Clojure is an aesthetically clean, wonderful language for parallel manipulation of lazy sequences. However after using it as my main language for slightly over two years, I found myself all-to-often butting heads with its paternalistic functionalism (trust me, I'm a grown up, I can manage a little bit of mutable state without shooting myself in the foot).

While I would definitely use Clojure as a first choice for any project which was primarily defined by a need for massive parallelism, I am now happily using common lisp as my main language, and I'm a noticeably happier and more productive programmer (while most tasks can be transformed into a purely functional lazy sequence manipulation, the process often takes time and results in code which is harder to read and maintain).

</comment><comment><USER29> Clojure already says YES where other lisp-based languages said NO to. (Instead of wrapping all java, let's use it for its strength. Don't just use list, use vector, map, etc. No tail-recursive? Aight, let's do it anyway and find a work-around)

Now, we make to differentiate users and what they ask. Is it a new clojure user who is used to C++ and try to code C++ in clojure and suggest missing features? Or an experienced clojure user offering useful patches to the community. In the first case, the right answer should probably be "Oh, but XYZ is already in Clojure, it's a little bit different than what you've been used in C++, but in fact, it's even more powerful. Here's how you can do it [...]". In the second case, it's more complicated.. but we should go toward the Yes if it adds real value to a day to day task. I mean, even thought clojure is great, you can't guess everything that will be needed.. so you shouldn't be shy to add missing stuff.

Still, Rich's answer is pretty great IMO.

</comment><comment><USER30> One of the best things I like about clojure actually is how it is currently keeping away new users.

It is probably the best thing for clojure right now, looking at the rapid changes that have been happening from 1.0 to 1.2, 1.2 to 1.3 .. Hickey has a clear vision for what he wants the language to be and it doesn't look like he has finished thinking about it yet. It is good that the community is still small and the tools are immature. When the language design is at a stable state then would be the time to start evangelizing.

I keep thinking about what happened with ruby .. it is such a beautiful language but the community grew too fast and it is now stuck with so many conventions that could have been better thought out.

<comment><USER31> See also the Haskell "avoid success at all costs" unofficial slogan, e.g. [http://www.computerworld.com.au/article/261007/a-z_programmi...](http://www.computerworld.com.au/article/261007/a-z_programming_languages_haskell/?pp=10)

</comment></comment><comment><USER32> This whole "I used the language for 2 weeks so now I am qualified to change it radically" attitude is well-established in the Lisp community (yes I know Steve Yegge is a veteran lisper, but this still applies, especially to some of the other commenters). The authority on this is Brucio, the fictional author of "Lisp at Light Speed" [http://replay.web.archive.org/20080722232746/http://brucio.b...](http://replay.web.archive.org/20080722232746/http://brucio.blogspot.com/) Bruce's First Law of Lisp is "If it does not do exactly what you expect with zero hours consideration or experience, it is a bug in Lisp that should be fixed."

</comment><comment><USER33> I don't understand Rich Hickey's point. How does his thought experiment address Steve Yegge's points?

Would someone care to explain?

<comment><USER34> Reduction to absurdity: if (almost) everybody got to add something, you would have an undifferentiated mass of scar tissue. There needs to be some discrimination of what changes "fit" the language.

Of course, "fit" and beauty are in the eye of the beholder :-(

<comment><USER35> It doesn't quite work, because Steve says "you need to be more open to fixing annoyances" and Rich responds "Look what a mess would it be if we fixed everyone's annoyance!". There is a big continuum between the place Clojure is now and the hypothetical absurd described by Rich.

</comment></comment></comment><comment><USER36> My quest for languages that say "Yes" ended with assembly. I started in BASIC and found the strait jacket it imposed much too restrictive. Then Pascal was the big teaching language but it has it's own ways. It wasn't till I got good as x86 assembly that I felt totally in control and able to do things just the way I wanted. Having achieved that feeling 20ish years ago I've been running away from it ever since. C and C++ proved that at some size of code base even the most brilliant programmers can't do memory management correctly[1] so I love that modern language said "No" to memory management. I've worked at large software companies where the programming style guides ran to 80+ pages. That's 80 pages of documentation of how people will format their code so that it's done consistently. I love that Python said "No" to letting people format their code however they wanted. It's likely that these aren't the kinds of things that Steve Yegge is talking about, but there are a lot of things it's worth saying "No" to, and if they bug you (like they used to bug me) there's always assembly language.

[1] <http://research.microsoft.com/pubs/70226/tr-2005-139.pdf>

</comment><comment><USER37> For starters, I dislike the title of the post. The thread language design and community/eco-system creation around the language.

I am not aware of how if at all Steve is qualified to make a well judged statement on either language design or the communities that develop around languages since afaik he has not done either.

I have been following the thread from the beginning since I am on the list, Steve Yegge comes of as delusional with his claims on how he influenced the Python community with one of his blog posts.

On the couple of instances where Steve was requested about what he contributed in tangible fashion, he mentions months of effort an JSwat command line support, everyone interested should check out the project and his contributions on code.google.com

On the second occasion he refuses to publish anything that the community can see or use or enhance.

I hope he proves me wrong, but at this time, he is blowing a lot of hot air, off the wrong end, and should stay away from the blog post he intends to write, his facade of being a real voice for a developer community is crumbling fast

</comment><comment><USER38> I'll just quote Antoine de Saint-Exupery here: "You know you've achieved perfection in design, Not when you have nothing more to add, But when you have nothing more to take away."

<comment><USER13> McCarthy already wrote that perfectly minimialist language in 1960. It only had seven functions and two special forms. Most programmers use more than nine keywords today.

<http://www-formal.stanford.edu/jmc/recursive/recursive.html>

</comment></comment><comment><USER39> I see a lot of people bashing Yegge, bashing Tiobe, praising Clojure, and praising Rich Hickey. All of that is strawman bullshit though as far as I can tell.

Virtually no one seems to be addressing what I think is Yegge's core point: _neglect_.

Is it true that there is a considerable body of extant patches/libraries/fixes out there that are being _neglected_ so that a sizable portion of Clojure's user base is feeling _neglected_.

If so, then Yegge has a valid point. If not, then argue why he is wrong about _neglect_.

<comment><USER40> I wonder... have you heard Rich Hickey ever talk about many of those patches and why they haven't been accepted yet? Clojure has a great deal of conformity across its abstractions and interfaces. It is really easy to compose things together. A lot of thought and careful planning goes into that. Many patches etc run afoul of that because they don't meet that standard.

As to libraries, you don't need to be blessed for a library to go. How exactly does clojure core neglect a library? By not taking it into the core?

I didn't read this as being about neglect. I think his argument was that you need to give people what they want or they will leave. I don't find any validity in that. There are plenty of BDFL projects that do quite well.

I think the real message is... 'I want these things. Why won't get you give them to me.' If this was anything other than a bit of a childish rant, there would have been much better channels to carry it out in.

If you want people to change, you don't attack them in public. If you want to make yourself feel good and vent, you attack people in public.

<comment><USER39> Thank you.

This is the kind of response I was hoping to see. I'm not qualified to comment at all on Clojure, but I was interested to see what people thought who were part of this community.

I wish more people would address these points. If Clojure really is fine the way it is then argue that point positively rather than chip away at Strawman arguments, which, at best, were only tangential.

Finally, I'm not so sure about the public-private point you are making. There's a reason we protect free (public) speech: being publicly criticized is much harder to ignore than private requests.

This rant has become front page material on Hacker News. That's pressure. If there really is dissatisfaction amongst the Clojure community, this won't be the last time we'll be reading about this particular exchange.

<comment><USER40> The public/private was...

If you want to influence people, attacking them in public isn't the best way to go about it. Do it privately, discuss your concerns etc etc. If you just go for the public 'you are doing it wrong' approach, you breed resentment & distrust. OTOH, a good rant in public sure can make you feel good even if it probably isn't going to sway your target to your side. Then again, that wasn't really the reason it was done, was it?

Or put another way... if you are going to rant, rant. Don't pretend like your public ranting at someone is an attempt to get them to agree with you. It is about making yourself feel better. If you need/want to convince someone to join your side of an argument, quiet diplomacy is going to be far more effective.

</comment></comment></comment></comment><comment><USER41> I think more important than always saying Yes is providing the ability to make anything possible.

<comment><USER13> All turing complete languages make anything possible, right? The only question there is whether or not you detour through Greenspun's Tenth Rule to get where you're going.

I think Steve's point about Clojure having a limited time to gain acceptance before it's considered "over" is valid, even if he doesn't necessarily show us a way out.

<comment><USER41>
        All turing complete languages make
        anything possible, right?

But there must exist a point of diminishing returns. There is a difference between Turing Complete and Gosling Complete.

<comment><USER42> "Gosling Complete" is such an awesome phrase.

</comment></comment></comment></comment><comment><USER43> Isn't this how we got C++?

<comment><USER44> Rather, PHP.

To be fair, it is actually fairly popular, thats why.

<comment><AUTHOR> We just got done hearing about how PHP's early years included "official" abstention from frameworky things (<http://codefury.net/2011/04/why-php-was-a- ghetto/>). PHP "won" because of distribution, just like Javascript is "winning" now.

</comment></comment></comment><comment><USER21> My understanding of what Steve Yegge is saying is that the community needs to be open to ideas and debate, and in his experience it is not. He pulled a few examples from the top of his head.

At least that's how I read it.

</comment><comment><USER45> Mr. Yegge says, "it only takes a few people to poison a community"

Yes, and it is the kvetchers that are putting a black cloud over a language and community that has been evolving quite nicely otherwise.

<comment><USER46> I think the term you are looking for is 'wreckers'.

<comment><USER45> No. They are kvetching.

<comment><USER46> I was making a joke using communist terminology. To be more direct, I don't think Steve is casting a dark cloud over the community, in fact the opposite metaphor is better: he's bringing some important issues to light.

</comment></comment></comment></comment><comment><USER47> Yegge is full of it. Python said "no" over and over again, and it's gone like gangbusters.

</comment><comment><USER48> Let's see how Steve's statements stand against evidence.

> to get users, languages have to say Yes

What languages in wide use today got popular because they said yes? Is it

C, Java, Python, Lua?

I don't think those qualify as "yes" languages. Oh, maybe it is

Perl.

<comment><USER49> Perhaps if you count the CPAN.</comment></comment>


Android and its Fragmentation - <AUTHOR> http://androidmyway.wordpress.com/2012/11/11/android-and-its-fragmentation/ <comment><USER2> Android is designed for multiple screen sizes and resolutions. The vast majority of apps can cover every variation with three or four sets of layouts and graphical assets.

Android API levels are also well-verified by compatibility tests, and so result in excellent app compatibility across devices that have passed those compatibility tests.

Hardware variations outside of screen geometry are covered by manifest declarations for apps that rely on certain hardware, or runtime tests for apps that have features that are conditionally available, depending on available hardware.

In other words, for 95%+ of all apps, device independence is readily possible, and if it isn't attained, it's because the developer did not use Android's features for managing variations between devices.

In most cases it is simpler yet: A port from iOS lacks the flexibility in layouts and use of graphical assets a native Android app would be born with. If you don't address that issue early in an iOS-to-Android port, you're going to have a bad time.</comment>


Five ways to build a $100M business - <AUTHOR> http://christophjanz.blogspot.com/2014/10/five-ways-to-build-100-million-business.html

<comment><AUTHOR> Sounds like click-bait at first but it's written by a guy with years of SaaS and VC experience.</comment>


Observable: Introduction to Notebooks - <AUTHOR> https://beta.observablehq.com/@mbostock/introduction-to-notebooks <comment><USER2> Any reason to choose observable instead of jupyter ? A feature comparison matrix would be nice.

<comment><USER3> Here's the initial writeup on Observable: [https://webcache.googleusercontent.com/search?q=cache:ct2nne...](https://webcache.googleusercontent.com/search?q=cache:ct2nnekxn6sJ:https://observablehq.com/+&cd=1&hl=en&ct=clnk&gl=us)

And source: [https://github.com/observablehq/notebook- stdlib](https://github.com/observablehq/notebook-stdlib)

</comment></comment><comment><USER4> I'm wondering about secure dbi connections with gigabytes of data behind a firewall followed by not crashing the browser. For me if observablehq has this covered then going the observablehq route over any type of notebook would be pretty close to ideal over anything I currently use.</comment>


Driving Disrupted: Driverless Cars Change Everything - <AUTHOR> http://www.slideshare.net/sparksandhoney/autonomous-slideshare-pdf

<comment><USER2> That picture makes me think: straight jacket. soft and comfortable. relaxing. will it wreck into something? are they watching tv? why is she wearing sunglasses because it's not so bright. they are from the future.</comment>


Pandora to cut 5 percent of jobs - <AUTHOR> https://www.reuters.com/article/us-pandora-restructuring/pandora-to-cut-5-percent-of-jobs-idUSKBN1FK3B1 <comment><USER2> I think the surprising part, here, is how many employees they still have.</comment>


Intel's 12-Core Xeon With 30 MB Of L3: The New Mac Pro's CPU? - <AUTHOR> http://www.tomshardware.com/reviews/ivy-bridge-ep-xeon-e5-2697-v2-benchmarks,3585.html <comment><USER3> No, this is not the new Mac Pro's CPU. This is an Ivy Bridge part. The new Mac Pro will be using a _Haswell_ CPU.

Apple have already mentioned that the new Mac Pro will ship with Thunderbolt 2. Intel have stated that the Falcon Ridge controllers that drive Thunderbolt 2 will be part of Haswell.

Additionally, Apple have never used the "E" series for their CPUs and there's no indication to think they'll start with the new Mac Pro.

<comment><USER4> The Xeon Haswell refresh isn't due for another year, and is expected to feature DDR4. The Ivy Bridge refresh in this article isn't even out yet.

You could be right, but it would involve one hell of a bold move on Apple's part. They'd be getting Haswell Xeons a year before everyone else, to mildly improve a product they didn't even bother to upgrade to Sandy Bridge. In which case, why isn't it the 15 core version?

More than likely, they've instead figured out some way of supporting Thunderbolt 2 in the Ivy refresh.

By the way, this CPU is an EP, not an E (there is no 12 core E), which seems in line with the current specs.

[http://en.wikipedia.org/wiki/Mac_Pro#Specifications](http://en.wikipedia.org/wiki/Mac_Pro#Specifications) [http://en.wikipedia.org/wiki/Haswell_(microarchitecture)#Con...](http://en.wikipedia.org/wiki/Haswell_\(microarchitecture\)#Confirmed_new_features)

<comment><USER5> What the fuck is up with the desktop wait by the way?

</comment></comment></comment><comment><AUTHOR> What I get from this is that the new Mac Pro is going to be expensive - <USER2> older generation Sandy Bridge Intel Xeon E5-2687W still costs > $1900.

<comment><USER6> That's the retail price. Apple would probably get a relatively good discount.

<comment><USER7> Consider a current generation Mac Pro matched spec-for-spec with BYOC prices. Which costs more for YOU (not Apple)?

<comment><USER6> I recently bought a PC, rediscovered the joys of being paralysed by the possibility that every bloody program I could download probably contained some sort of malware, nagware, searchware, spyware or crapware, and then sold my PC and paid the goddamn markup like I should have done in the first place.

The two or three occasions on which I played computer games did not cover the time lost to trying to do work on a platform which doesn't have the tools I needed.

<comment><USER8> What would stop vendors creating such programs for Mac too?

<comment><USER6> I don't really give a hot damn why. The difference is that with a Mac it's a hypothetical and with Windows it happened to me _twice in the first week_.

<comment><USER9> So put linux on there. Then again, if you are so bad with computers that you are "paralysed by the possibility of nagware" then maybe you should be on ChromeOS or something.

<comment><USER6> I tried 6 distributions. 3 versions of Ubuntu, Arch, Red Hat and Mint.

They all either ran slow, were buggy, had incomplete software repos or didn't support my hardware.

(Arch was my favourite, FWIW.)

<comment><USER10> I have a Macbook pro at work and at home. But I use Linux on all servers. I suggest you consider standardizing on one so you can build up your skillset and be aware of the quirks. E.g. I now understand I'd better do an apt-get update periodically or before I want to install new software. The ubuntu desktop installs with sudo apt-get install ubuntu-desktop ... etc. You are right that it is easier to pay the OSX tax and I did. But the Ubuntu/Linux desktop is almost there ... such that I probably would be okay if my next laptop just ran Linux.

<comment><USER6> I use ubuntu on servers, so the relative poorness of the desktop version was a rude surprise. I've been using Linux on and off long enough that my first distro was Red Hat Linux 4.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> 30MB would fit in nice for scientific computing. Does it mean that Haswell Xeons will have 60MB?</comment>


So You Think You Have a Power Law - <AUTHOR> http://vserver1.cscs.lsa.umich.edu/~crshalizi/weblog/491.html <comment><USER2> The author is quite an interesting thinker, and I like many of his posts. (I agree that the default font set on his website is all wrong, much too small, so I zoomed in with my browser to read his words.) The key claim in his abstract is important and deserves more attention. (The article title in submission to HN should have "2007" included, as this posts dates back that far.)

"Power-law distributions occur in many situations of scientific interest and have significant consequences for our understanding of natural and man-made phenomena. Unfortunately, the empirical detection and characterization of power laws is made difficult by the large fluctuations that occur in the tail of the distribution. In particular, standard methods such as least-squares fitting are known to produce systematically biased estimates of parameters for power-law distributions and should not be used in most circumstances."

The author's take-home points are a list of good practices. He comments that much of the content of whole journals would disappear if authors and reviewers followed these practices.

"1\. Lots of distributions give you straight-ish lines on a log-log plot. True, a Gaussian or a Poisson won't, but lots of other things will.

"2\. Abusing linear regression makes the baby Gauss cry.

"3\. Use maximum likelihood to estimate the scaling exponent. It's fast! The formula is easy! Best of all, it works!

"4\. Use goodness of fit to estimate where the scaling region begins.

"5\. Use a goodness-of-fit test to check goodness of fit. In particular, if you're looking at the goodness of fit of a distribution, use a statistic meant for distributions, not one for regression curves.

"6\. Use Vuong's test to check alternatives, and be prepared for disappointment. Even if you've estimated the parameters of your parameters properly, and the fit is decent, you're not done yet.

"7\. Ask yourself whether you really care. Maybe you don't. A lot of the time, we think, all that's genuine important is that the tail is heavy, and it doesn't really matter whether it decays linearly in the log of the variable (power law) or quadratically (log-normal) or something else."

Good stuff. It takes a lot of practice to get statistical analysis right.

</comment><comment><USER3> Random note to author if they read this, the default font is unreadably small on my 24" monitor.

<comment><USER4> Use CTRL and +/\- to zoom in/out.

</comment></comment><comment><USER5> I love Clauset, Shalizi, and Newman for keeping up this fight. Even if you agree with them, you still have to include a linear regression in your paper to satisfy reviewers.

I was surprised to see this on HN, though. I guess everyone is trying to use power laws in one way or another.

<comment><USER6> Well, ever since Saddam tried to use power law to justify his invasion of Kuwait we've all been stepping on eggshells.

<comment><USER7> What?

</comment></comment></comment><comment><USER8> Visually identifying power laws from a log-log plot is a pervasive anti- pattern; this is a good treatment of why we should be sceptical and what we should do instead. Thanks to OP.

</comment><comment><USER9> This pattern annoys me to no end. People are quick to jump from a claim like "some users are more valuable than others" to "POWER LAW", and from there to folksy wisdom about an "80-20 rule".

<comment><USER10> I agree, both terms feel oddly specific to me when people throw them around casually, but the layman use is at least directionally correct.

Much more cringe inducing are all of the invented definitions of the Law of Large Numbers! (e.g. [http://www.fastcompany.com/1825592/9-reasons-choose- corporat...](http://www.fastcompany.com/1825592/9-reasons-choose-corporate- job-over-startup)).

<comment><USER11> Guh. I encountered this so much on an investment site that I wrote a blog post about the Law of Large Numbers because it was annoying me enough that I wanted to have a shorthand link. [http://confounding.net/2012/03/12/thats-not-how- the-law-of-l...](http://confounding.net/2012/03/12/thats-not-how-the-law-of- large-numbers-works/)

I equally hated "Well, it means something different in this field." No it doesn't, it's _math_. That's the whole point.

</comment></comment></comment><comment><USER12> About eight months ago I took the data from the Angel Investor Performance Project(1) and ran it through the powerlaw software(2).

The software said the data on angel funded startups (at least the ones in the AIPP survey) did not indicate that returns followed a power law. Given how often we say "power law!" in regards to startup outcomes, I just thought that was interesting.

(1) [http://www.angelcapitalassociation.org/data/Documents/Resour...](http://www.angelcapitalassociation.org/data/Documents/Resources/AngelGroupResarch/1d%20-%20Resources%20-%20Research/6%20RSCH_- _ACEF_-_Returns_to_Angel_Investor_in_Groups.pdf)

(2) [http://code.google.com/p/powerlaw/](http://code.google.com/p/powerlaw/)

<comment><USER13> Investment returns may not follow a power law given that they can come from "normalstan". The distribution of startup values for both funded and unfunded startups (including IPOs AND failures) would come from "extremistan" due to the presence of outliers. The data from extremistan will more likely follow a power law distribution. The terms normal and exstrem-istan come from the writings of Nassim Taleb, author of Fooled By Randomness and Black Swan: Impact of the Highly Improbable.

<comment><USER14> > The data from extremistan will more likely follow a power law distribution.

That's exactly the kind of logical inference that the linked article warns against, unless you have some additional reasoning behind that assertion.

</comment></comment></comment><comment><USER15> In general, very, very few things in nature follow a power law. And, either way, like is stated, it is fairly difficult (if not impossible) to even make sense of what _is_ a power law---notably, in phenomenological cases, power laws have no interpretable units, which come about only by the use of constants.

</comment><comment><USER16> This post is fantastic and the paper is fascinating. I particularly enjoyed his writing:

> This is why God, in Her wisdom and mercy, gave us the bootstrap.</comment>


Ask HN: Do you have a startup idea to share? - <AUTHOR>

I keep hearing and reading all the time that great ideas are everywhere and easy to come by but I find it extremely difficult to come up with a great or at least a good idea for a startup.<p>I am hoping that this will become a very long thread about new startup ideas and be an inspiration to all. <comment><USER2> _I find it extremely difficult to come up with a great or at least a good idea for a startup_

The idea itself isn't the hard part. I come up with dozens of ideas every week. The hard part is turning that idea into a successful business. That takes lots of hard work, sleepless nights, pounding pavements, fruitless sales calls and emails, the list goes on. The old adage of finding a problem and solving it still applies. Just today, one problem that presented itself that a startup could solve is:

Employee Scheduling. My wife is a per diem float team nurse at the number 3 hospital in the United States. When she wants to work, she calls in to an automated phone system, and records a series of messages after the beep to schedule herself (day shift, 12 hours, department, name, phone number, etc). Someone then listens to all of these messages, as well as messages from department heads looking to fill staffing needs. This person in the staffing office then calls my wife at 4am to let her know where she should report (or if they don't have anything for her). Tell me why that can't be a simple online/mobile app, with Twilio integration to send a text message, voicemail, or email confirmation? The same app could be used to schedule appointments for nearly anything...dentists, hair salons, you name it. You could beef it up by offering options such as realtime availability, payment processing, etc., to make it applicable to multiple industries. And you could charge a monthly fee, or per appointment, you name it.

Of course to turn this into a startup, you'd have to build the backend, the app, and have a sales team to sign up businesses, but it could be a hit.

<comment><USER3> Fruit couldn't be hanging any lower. This is so simple to build, so why don't they do it?

<comment><USER2> The technology side of it seems easy enough. A quick search revealed quite a few scheduling software packages, and a few hosted options. But look at all of things I've had to schedule over the phone recently: dentist appointment, eye doctor appointment, and a physical (the last one I put the request in online, and they called to confirm). It seems like the winner of this industry would be the one who could convince businesses to sign up.

<comment><USER3> The hard part might be plugging in their existing systems.

</comment></comment></comment></comment><comment><USER4> Ideas come in all shapes and sizes, disruptive and not-so disruptive. Take the iPhone and iPad; disruptive because so many other apps and startups based on making apps have been developed. Not-so disruptive are the apps themselves; do you want to share photos? there are many, many apps for that. If you're looking for one idea, here is one that no one has really captured and the reasons for this will become clear throughout my post.

Why is it that our greatest idea hasn't really been capitalized or used to its fullest. I am referring to the internet. We keep touting ourselves as "being connected"; we really are not, but can we become more connected? We are effective in Tweeting for a flash mob to occur in central station at time X, but why is it that we cannot issue an Amber alert of a missing child by the same means?; most of us now use mobile devices more than ever. Perhaps, because incidents like the NBC Twitter account being hacked and posting a bogus tweet on 9/11, just doesn't instill a lot of confidence in such a system. Nonetheless, it seems silly to me that we have to issue an Amber alert on highways for maximum exposure when we have the internet and mobile devices.

I'm really talking about our inter-connectivity and maximizing it to its full potential. Forums come close to making my point. For example, when was the last time you searched for a medical condition using Google. You often have to filter through a lot of pages to get the answer that you are looking for. The problem with forums is that the anonymity of the internet doesn't really afford the luxury of trusting Dr. Quack on the other side of the post. Wouldn't it be nice to just get more than a 2nd medical opinion? What about 1000 or 10000 medical opinions in a forum-like setting? It is unlikely in the current infrastructure because 1) we cannot verify whether the people posting are indeed professionals, 2) legal and liability issues, 3) compensation? (just listing it here because it's inevitable that people might want to be $ for their advice). Disregarding #1 and #3 for the moment, we could negate #2 if we could get an aggregate graph or pie chart of the responses. For example, "My son has this disease and he exhibits x, y, z, symptoms. What could it be?" Imagine how much more confident the parent would feel if he/she had an aggregate result of 80% respondents said disease x and 10% said disease y - from 1000 or 10000 medical professionals. Too far fetch of an idea? Perhaps, if we had a private and secure network along side the current internet, I can see it working. Social media forums, like FB, could take this on. Unfortunately, they exist as part of the current fabric of the internet and, by default, anonymity is rampant, and users in this forum I described would be less likely to submit their professional information to be stored in a server 'out there' with the risk of it being misused. Mistrust is the underlying issue; remember, the internet was built for 'trusted' parties - that is a rare commodity in this commercialized internet.

Forums (of all shapes and sizes) from legitimate people/professionals existing in this so-called private network could take on a whole new life of their own; and if you still want to post things anonymously, just go back to the old internet. But imagine the power of the 'many' -it clearly outweighs the 'few' and we aren't really maximizing it; the internet has become a dumping ground for data...

Be my guest on taking on this idea, otherwise, we could use more apps =)

</comment><comment><USER5> Ideas are not great by themselves. Ideas are only great because someone executed on that idea. Also, ideas are great within some context. The idea of flying on the 1600s would have had you accused of witchcraft (bad idea) but the Wright Bothers executed on the idea, resulting in airplanes (great idea).

In general, ideas are easy to create and essentially free. They become great because of the time, energy, and determination of people.

What you could do to generate possible ideas is take an bland industry and challenge the assumptions around that industry. From the assumption challenges will come the seeds to create a statrtup with potential. But the greatness will only come from people tackling those initial idea seeds.

</comment><comment><USER6> Execution over ideas in every case.

However, after diving a lot into Lean Product and UX Design, I have learned that the hardest part is finding problems worth solving. In my opinion, being able to discover problems that have terrible solutions and workarounds are really where good ideas are spawned, then "hypothesized" and "validated".

Also, for helping to formulate your ideas (I am assuming a business model), it has helped me to use a business model canvas. I like the "lean" one from <http://www.runningleanhq.com> and there is a link to one from Steve Blank's blog article: [http://steveblank.com/2011/09/22/how-to-build-a-web- startup-...](http://steveblank.com/2011/09/22/how-to-build-a-web-startup-lean- launchpad-edition/) and a good slide explanation: [http://steveblank.com/2010/11/15/creating-startup-success- cu...](http://steveblank.com/2010/11/15/creating-startup-success-customer- development-business-model-design/)

Hope this helps.

</comment><comment><USER7> Here's two suggestions (unrelated) that may help your brainstorming, with the benefit of some (potential) validation of market need:

1) (top down) check out www.crunchbase.com - there are about 75k companies there, a significant portion that are startups. Browse privately held companies in a category interesting to you -- you'll see 'current problems' that entrepreneurs and VCs believe are commercially viable.

2 (bottom up) Take a few areas of professional or personal interest, look at the leading tools/services/companies related to each of those interests, and for each check out discussion boards, FAQs, blogs, etc. to see where there is a lot of interest (via suggestions, complaints, work-arounds) for getting something fixed, or doing something better.

As you start to think of how YOU might tackle the problems you see from above, you are generating startup ideas ...

</comment><comment><USER8> The following steps would hopefully help: 1) Peruse quora.com every day, read the wall street journal, if you don't have a subscription you can get one online and read any journal. 2) Network and attend conferences that interest you. 3) Focus on an area that you have passion about and keep it simple. 4) Possible paths to explore beyond social media are: a) Ecosystem driven where there is demand i.e. Salesforce, Twilio, Google App Marketplace b) Healthcare c) Personalized Medicine d) Energy 5) Build a prototype(balsamiq) and develop a pitch. 6) Participate in business plan competitions. 7) Get going.

</comment><comment><USER9> I was 2 years into my search for seed funding for what some other guys launched as Gigwalk. I keep looking at GW to see what they are doing and it is not living up to the potential that I had imagined for it. I want someone to build a Gigwalk service that is aimed at professionals and also that allows the buying and selling of information with complete anonymity at both ends of the transaction. Tasks may be interviews, covert video or photos, translation of foreign texts - all aimed at professional journalists and information gatherers and all paying a lot more than current location based tasking chores.

</comment><comment><AUTHOR> I guess one of the reasons that I find it so difficult to find or come up with a great idea is because I am looking for an idea within my ability and resources - within my ability to execute as a single founder - within my coding, design and marketing ability and with a minimum amount of money.

For example something like www.metrolyrics.com is within my ability to execute. I wish I came up with that idea. Oh well. Anyway the story of this site and his founder is very educational. I can't find the link right now.

</comment><comment><USER10> A search engine for stuff in my house. I'm constantly struggling to find things around the house. If I could easily search the space in my house, my life would improve significantly.

<comment><USER11> I'm building one now. Hope to launch on Friday.

<http://www.ikeepm.com>

<comment><USER10> Ooh that looks interesting. But you just do inventories, right? I need something that lets me track the position of stuff inside the house. If you add that kind of thing, I'm sold.

<comment><USER11> What do you mean by position? You're allowed to create rooms and assign items to the rooms.

</comment></comment></comment></comment><comment><USER12> think of an idea from your area of expertise. ex: a restaurant owner develops software to helps his/her restaurant</comment>


Video: building an open source platform as a service with openshift origin - <AUTHOR> https://openshift.redhat.com/community/blogs/watch-the-video-building-an-open-source-platform-as-a-service-with-red-hats-openshift-origin

<comment><AUTHOR> <https://fedoraproject.org/wiki/Features/OpenShift_Origin> has the status of packaging for f18</comment>


Google App Engine OAuth authentication broken since 02/06/13 00:00 - <AUTHOR> https://code.google.com/p/googleappengine/issues/detail?id=8785

<comment><AUTHOR> No comment yet from anyone at Google after nearly 24 hours. This probably breaks every App using the builtin authentication. If anyone knows a workaround, I would appreciate hearing about it!</comment>