skysight-inc/HackerNews huggingface dataset:
Highly nested constructs are more common and natural in Lisp. I think that explains the low level of indentation. It also hurts readability compared to imperative languages, where it's common to have long sequences like this:

do something;
do something else;
do something else;
do something else;
do something else;

Sequences like that give you long columns of aligned text that make it much easier to judge relative indentation on the screen.

Lisp's readability advantage (if it indeed has one; I'm giving it the benefit of the doubt for now) are at the whole-program level. On the function level, it seems more difficult than imperative languages. It would be more fair, and more to the point, to compare it to functional languages. If you write in an imperative style in Lisp, all the parens line up neatly, and it isn't so hard to read. But who codes that way unless they have to?
First, if you're writing code in an editor, there's no problem with using that editor help you write the code. Complaining about having to use an editor to use paren-matching is like complaining about screws because they don't work so great without a screwdriver. You have tools, you can use them, you don't get man-points for scratching your code into a stone slab with a chisel.

That rant aside...

Trailing parens (and trailing braces in brace-y languages) do increase local readability, but they do so at a global readibility cost. They eat lines of code, which makes it difficult to see an entire code fragment at a time. Like all trade-offs, there are reasons why you should and shouldn't, and situations where you should and shouldn't. And the important thing is, the cost of trailing parens is higher in a Lisp than it is in your average brace-delimited language. This doesn't mean that it's always the right decision in C or the wrong one in Lisp, but on average C is more likely to get a net benefit than Lisp.

Lisp simply nests more than C-style languages. This means that you pay the line-costs more often and your code density goes down a lot faster. There are a couple of reasons that Lisp nests deeper, some of them from the language itself, some cultural. From the language side, C only uses braces for control structures, and those don't return values. In Lisp, both functions and control structures use parentheses, and control structures return values so they often get used as arguments to functions, increasing the nest depth. From the cultural side, C-ish languages use variable assignment and sequencing of operations as its fundamental operations and braced control structures are less frequent, while Lisp passes values as arguments to functions as its fundamental operation. Lisp tends to use additional parentheses in places where a brace language would use a semicolon instead of a brace.[1]

I have to say, the trailing-parens didn't really help me read the example that much. Having extra parentheses didn't help me figure out what line indented with what. In fact, it made it harder because there were more lines in the way. I suppose people who favor brace-y languages count braces rather than matching indentation, but like I said before, Lisp nests more so that's a lot of counting. Again, this doesn't mean that stacking parens is always right in Lisp, or even that it's right in this code sample, since I'm not the one writing or reading it. It means that, once again, these religious wars are silly and you should pick what works best, and my $/50 is that trailing is more expensive in Lisp so it doesn't increase readability as often. FWIW, people who claim Lisp code is naturally more dense could argue that Lisp can more easily pay those extra lines.

[1] Example idiomatic C-ish language (JavaScript perhaps):

a = foo(x, y);
b = bar(x, y);
return qux(a, b);

vs idiomatic equivalent lisp, which prefers to nest deeper rather than assign intermediate values:

(qux
(foo x y)
(bar x y))
The Story Behind EMC's Acquisition of Greenplum
This is the opinion of people who don't try or fail at the App Store.

For a counterpoint, my start-up (me, my fiancée, and my good friend) started an indie GPS app at the tail end of last summer. We worked hard, did many iterations, built up our userbase, and now we have several top grossing navigation apps, and we are piling up cash in the bank.

We don't have a marketing budget. All we do is engineer and Tweet, and we have had steady growth. Now we are also licensing the mapping platform to a handful of other companies, and I'm guessing our revenues will double or triple over the next couple of months, again.

For all those deciding whether to do an iPhone app, it can be done. But pick a niche and plan to work harder than any job you've ever had, or it probably won't pay off. There may be a lot of disgustingly successful Fart apps, outliers in the game section, and the like. But there are also indie devs that make a job of it, and there is plenty of money in it for us too.

People like to say the "App Store" is a bad bet. The truth is, any start-up is a longshot, and the App Store is a fine way to sell software. We pivoted away from the web and Facebook because we found it too hard to monetize, even though we had strong traffic growth and we had won an fbFund grant early on. Different strategies work for different people - you just have to experiment, instead of basing your decisions on bad assumptions and never reevaluating them.
That was the spirit of the times--finding ways to ensure demand kept up with rapidly expanding industrial capacity.
The Screw-Me Scenario
I tend to think that Linus was right and microkernels are in reality a bad design.

Case in point: Minix 1.5 (which I hacked on before Linux came along).

Minix 1.5 has two "daemons" called mm and fs which run the memory management and filesystem respectively. Now consider process creation and loading (fork and exec). Creating and loading a process intimately involves both mm and fs, so in Minix 1.5 the program sends a message to mm [IIRC] which sends a message to fs and both daemons have to coordinate with each other. This makes it a lot more complex than if there was just one daemon (ie. a monolithic kernel).

Another example is that if mm or fs die, your OS dies. You can't restart one or the other because there's so much process state spread across the two daemons. So the claim that microkernels are more resilient because you can restart daemons seems to be nonsense (but I should say that QNX can apparently restart some(?) components transparently).

Nevertheless it's not all roses for monolithic kernels either. There's no process protection and they're usually written in deeply unsafe languages like C. Exokernels might be the answer to this because they have monolithic qualities (fast calls and shared state) but keep virtually everything running in userspace so you can use sane, safe programming techniques.
>In fact, is it cool, it is expected, it is flattering, and it is perfectly ethical. I'm guessing the StackOverflow team feels this way too.

really? You think so?

I am glad that there is an open source option, but I hate the fact that its all most 95% copy paste job of SO.

There is a difference between design inspired from something and blatant copying something.
The importance of touch
Well, "maximize revenue within the context of the law and ethics." leads to a standard of manipulating legal policy however possible and defining subjective values like "ethics" in the a context favorable to an organizations motives.

Any company that can't or won't do these things is at a severe disadvantage to the competition.
Your post reminds of this article I read now and again - http://www.conversiondoctor.com/conversion-blog/jobs-are-fil...

"Somewhere along the line the “American Dream” became having a “good job” that pays enough to be able to afford to “buy your own home”.

...

Historically the REAL “American Dream” used to be to owning your own business and becoming financially independent, while working for yourself, controlling your own destiny."
Or, if you don't want to jailbreak, you can just pay $99/year for a developer license and build+install whatever you want on your devices.

Think of it as a "freedom tax" for your hardware. Are tethering, WiFi scanning, and flash worth $99/year to you?
I said distasteful, I never said unethical or illegal.
"The angle of the spring's depression causes the bottom of the spring to push a tiny hammer down which actuates a membrane inside the keyboard chassis at the same time the spring buckles, causing a keystroke to be registered."

I thought the M used capacitive technology to register the stroke, which was one of the keys to it's durability. The one I took apart 10 years ago had no domes. Membranes just can't hold up like that.
Commonly, in 2.0 shops of few people:
Client-side -> "frontend"
Server-side -> "backend"

You're right that when the server-side gets nontrivial you need to stratify the architecture and the role definitions for the participants. At that point, "backend" means a just what you describe, and the business logic implementors are building what I'd call the middle-tier; it is seldom more than ORM retrieval, formatting and validation.

When you start involving ETL, algos, complex "systems" programming, deep integration with external vendors then you leave this paradigm and start having "real" backend devs.
I agree that if you build one web app tuned for mobile phones --- it should work for both iPhones and Android phones...as well as for browsers on laptops and desktops.

But, HTML5 is nowhere close to supporting the features you need, nor does it have access to essential phone hardware. I've built a browser based paint app and a browser based GPS using HTML5 and while fun, I think if you're honest, you know it's not quite ready for that yet. There is too much browser sniffing/adapter pattern going on and it can't be avoided.

That aside, my question to other mobile phone users is how Native vs. Web apps are perceived by users on a phone. Since the Native App is --- well, native --- it is given more prominence within the phone's UI. I suppose you could bookmark the web app, but it just doesn't seem to have as much importance as something natively installed with a shortcut icon, full access to all hardware, native menus, buttons, etc.

So, I don't think you can blatantly say "web apps are better than mobile" --- unless maybe you have a vested interest in that position --- like you're writing a book or something (ahem, ahem).

I think the reality is that app stores are a pretty cheap distro opportunity with millions of people with credit cards on file and are certainly not going anywhere in the near future.
everything he said was true and compelling. however there remain some arguments in favor of the App Store (unfortunately, in my mind) with the super simple purchase ability for users being possibly the most compelling. The large audience is still attractive but I think the benefit of this to developers is decreasing as the massive number of apps and updates cause so much noise it gets harder for any one app to stick out or be found at all. I've written 4 of the apps in the store now and have reached a point where I look hard for excuses to not make anymore, because I think in the long run it goes against my best interest and that of my clients. The best reason for a native mobile app is if it truly needs fast performance and/or offline access, for example.
The Clojure example he gives of a closing paren stack that looks like ]))))])))) highlights the downside of the Clojure sugar for vectors. It's a lot easier to just keep pounding out parens at the end of an expression until they match up than it is to carefully alternate ] and ). This outweighs whatever gains were made by the vector literals IMO.

I think I would have preferred some standard reader macros instead for collection literals.
> there are still plenty of web apps where webkit is unsupported.

I hope one of these days we will get to the point where web apps are standards complaint, rather than rendering engine complaint.

We've largely won the battle on earning recognition and support for Gecko, but now we have to do most of it over again for Webkit? What new and exciting engine will we be griping about in two years? Does this make sense?
great front-end devs are sooooo rare.
I've long ignored the Lisp formatting debates because I seem to provide, for myself at least, the only counter-example that many authors are convinced doesn't exist. That is, the traditional Lisp parentheses "hell" is very much readable to me, thank you. More so than the C-indented style.

I use C-M-b and -f to jump around the parentheses but I would do the same with properly indented C code as well. I don't always "see" whether this right paren aligns with the left paren that has 16 or 20 spaces of indentation.

Secondly, the author dismissed the argument of lots of indentation and lone right parens making the code longer, but it's a valid point. I can see the Lisp function in one screenful while the C version would flow outside. And for me, that's even worse.

Third, code always needs mental parsing in your head. Code isn't meant to be merely read, it's meant to be inspected and studied. It's an interactive process and it's not cheating to use an interactive editor to help you with that.
I think that the degree to which younger generations are "doing worse" is due to upbringing and work-ethic far more than it is due to opportunity. Today's younger generations start working later, work less, stay at home longer, spend a lot more time pursuing vanity educations with no economic value, have out of control spending habits, and are generally bad with money management.

And even then most "younger generations" live much easier and more wealthy lives than previous generations. They still have cable TV, the internet, cell phones, cars, prepared food, etc, etc, etc.

Every single person I've seen with drive, a good work-ethic, and sound financial sense has gotten ahead quickly in America, even if they never achieved any education beyond a high school diploma. That doesn't mean they all become millionaires, it just means they achieved financial stability and have significant control over their career path.
Feel free to put it through W3 validator, it is perfectly valid HTML5 (but the same can be done with 4 too).
What advice? To shutter the 30+ year old global information network upon which entire economies now depend and that at least a third of our species participates in because Prince doesn't like it anymore?
"Most small startups (by which I mean fewer than 20 people) don’t have enough work..."

What? WTH kind of startup is short on stuff to do? If you have 2 general-purpose devs, they're going to be 100% busy. if you have 1 front-end and 1 back-end dev, they're going to be 100% busy. If you add another dev, that person is going to be 100% busy, whether they're front-end or back-end.
These bait posts are annoying. Apple supplies the distribution, payment, promotion and a centralized market that can get you thousands of sales just by being good and on the store.

So how are you monetizing your web app? You taking payments? Paying bandwidth? Advertising?

Web apps are fine, but they're something ELSE not something better. Apple is doing some lifting on the App Store and they get a cut, that's it.
It would be easy to add a nice electric-right-paren function to clojure-mode that would be bound to ')'. It would always insert the right kind of a closing paren.

Actually, I'm wondering why that doesn't already exist there. (Just checked.)
"Give up 30% of your profits . . ."

Considering the huge # of apps priced @ $1.00 his math falls apart.

If you're charging $1.00 and have even REASONABLE merchant fees you're going to wind up shelling out $0.40 - 0.50 of every dollar to the merchant processor.

Even paypal is 1.9% - 2.9% + $0.30 USD for the bulk of transactions.

Not to mention access to millions of consumers, not to mention completely eliminating customer service costs, etc, etc, etc.
My startup is going to (hopefully) be in this situation in a few months.

I think we're going to try the HN consultants list first, then look at the SO job board. I want to hire someone as a consultant first, to get the feel of how they work, then increase their hours / usage as needed.
Also mentioned is that his schooling was entirely paid for along with his rent.

I imagine that if his parents weren't still subsidizing his life, he wouldn't have had any thought about rejecting that job offer.
Amazon.com takes a slice of my sales when I use their marketplace. I'm also forced to agree to their policies with regards to shipping fees (I get a credit, but my costs often are MORE than the credit) and their A-to-Z guarantee.

I still end up making more money with the "global" marketplace of Amazon.com than I would my local marketplace. I think the same applies to a well written app over a well written web app.
"- Don't be afraid to separate your code into many functions, even if you are using lisp."

Especially if you are using Lisp.
This is a popular idea lately, that web apps can (and should!) do everything that native apps do. Are there any examples of that people actually use regularly? I know I have tried a few of these 'apps-in-a-browser' and even the ones that worked reasonably well were still clunky enough that it always felt like a worse version of something else, to the point that I stopped using them quickly.
Starcraft came out in 1998 ;)
What it means to be a Dogpatcher
It seems to me like the second example's readability stems almost entirely from the indent increase. I don't see how the stacking helps or doesn't help at all. I just saw the addition linebreaks as noise that ruins the flow of the code.

Even with the current example, I immediately said, "Inside the let." The only uncertainty for a half-second in my head was with the with-open, but that's only because 2-space tabs are pretty tight and long functions like that make reading the drop harder.
Apologia for Google Wave
Have you considered doing more marketing? Seems like you are in a spot where it would make sense.
What do I get for my 30%:

* Apple processes payments and wires me money

* Apple processes over 1GB of downloads per day for me (and growing)

* Apple makes my software discoverable to their hundreds of millions of already-entered-my-credit-card users

Also, for expensive apps, 30% might seem steep. But I challenge you to find a payment provider who will let you sell something for .99 and wants much less than 30%, as a fee or percentage. Plus, you can avoid the 30% if you want by having a free app with in-app purchases that you process via some other mechanism.
Ask HN: Is holding your head when you miss a goal a universal human reaction?
This seems to be very consistent across all world cup teams and spectators regardless of nationality.
Lets be clear... half of your list is from C:

-Procedural programming
-Structures and enumerations
-Text based macros
-Low-level memory access

And for the items they actually added to C to make C++, none of them are all that unusual, save templates (not sure if there is any other language that does it compile time).

IMO, Scala has more parts of the sink in it than C++. The problem with C++ isn't the kitchen sink. It's that its built on a language that isn't meant to hold the things that C++ would like to add to it.

Maybe I'm being pedantic, but when I see "kitchen sink" I have a vision of a lot of features. But frankly C++ isn't all that feature rich. But its the interaction complexity that makes it problematic. This is not a problem of throwing the kitchen sink at it, but rather a design problem.
Meh. Took me all of two seconds to figure out what scope that line was in. Then when I read on and was told its hard, I double-checked by counting parentheses only to find out I was right the first time. I honestly don't know what hes talking about.

As for "line count" not being important, I personally like fitting as much code into one screen as I can (especially since I often code on my netbook). Short functions are important, but even then, nice and compact code is still very important to me. Especially since I'll split code onto their own lines once the line gets more than about 70 or so characters long.

I dunno. Even if line count was unimportant to me, I don't see what the problem is, since I found it easy to spot the nesting.

Anyway, that code is much too complicated. Hes using Clojure (ie, a Lisp), he should make use of the available abstractions to simplify the code. This will, in turn, make it easier still to figure out nesting of arbitrary lines of code.
Sukhotin's Algorithm
You can "bookmark" web apps into your home screen with the iPhone. I'm sure Android offers some version of support for this as well.

But you still have to deal with stuff like having to login every time. Losing some screen space of your app to the Safari bar at the top, etc.
The importance of APM always struck me as evidence of misguided design in Starcraft/Starcraft II. It takes emphasis off the parts I find fun (the strategy), and puts it on the parts of the game that aren't interesting at all: micromanagement of units is just drudgery.

To increase the strategy and reduce the drudgery, you could either implement APM restrictions directly on the player (drop clicks, etc. -- very annoying) or you could design units to be maximally effective by default, without micromanagement.
I've browsed around a bit. This site actually seems quite useful. If nothing else, it's a good sounding board for "What is the best web site for X"
http://www.datawrangling.com/some-datasets-available-on-the-...

http://archive.ics.uci.edu/ml/datasets.html

http://data.worldbank.org/developers
>>300 apm is an exageration.. usually it's around 250+

Actually all top Terran players(Flash, Ruby, Fantasy) have around 400 APM. The other 2 races are not so micro intensive, but still 300 is not good enough to win a big torney.
SRI’s chief believes future iPhones & gadgets will have virtual assistants
But your buildout "now ended up requiring Haskell (GHC, Pandoc), Java, Python 2, Python 3, lxml, pyquery and YUI Compressor for my site to build!"

I don't think I'd call something that was built in 3 languages, one with two versions, as minimalist.
Wow, mega-linkbait title. In short, No. As the article goes on to argue (and I agree,) blessing the Amazon APIs as a standard would be great for the industry though they have their warts for sure.
Exactly. Linux is also useful enough to run the laptop Tannenbaum's presentation is running on while no version of Minix is. (He's running windows, but it could have been Linux)

Minix drivers would still have to exist, and to be usable, they still need access to hardware. There's no presented reason why Minix drivers should have fewer bugs / LoC than linux, except that individual drivers can't take down other "kernel" processes.

That might get you minor improvements in reliability, but it won't fix this issue of bugs existing in hardware drivers in the first place.

IMO, the way forward in reliability is a kernel written in a more correct, more expressive (haskell-ish) Programming Language.