All Children Should Be Delinquents - <AUTHOR> http://www.nytimes.com/2014/07/13/opinion/sunday/all-children-should-be-delinquents.html <comment><USER2> I believe it's the guilt of those things we did as children that makes us such restrictive parents. We realize that the things we did were dangerous and we don't want that for our kids.

Also, back then was a different time. You could do stuff like that, get caught, and not pay a huge price. Now, that's not true, in the US, at least. The climate is one of zero tolerance for stuff mentioned in the article. Example: some kids in the middle school my son goes to played a prank in the computer lab: they swapped a bunch of keys of some of the keyboards. The result? They were banned _for life_ from using computers in the school district (yes, this would follow them to high school). A complete over reaction, but the norm for punishment in the US.

<comment><USER3> I spent my teenage years in a third-world country. I would be convicted of the following if I had spent those years in the US:

1) Trespassing private property

2) Theft

3) Willful and malicious destruction of property

4) Arson

5) Indecent exposure

6) Consensual rape (my girlfriend was 2 years younger than me)

7) Driving under the influence

I consider myself a highly moral individual, and some people consider me the most level-headed and patient person around.

I would argue that being a vandal in your teenage years may have a positive impact on the rest of the life of some people. You have to be smart about it and try not to hurt you or anyone else too much in the process.

<comment><USER4> > You have to be smart about it and try not to hurt you or anyone else too > much in the process.

So theft, destruction of property, driving under the influence, and arson are victimless crimes?

Maybe I'm a stickler for rule of law but when you start fucking with other people's stuff, that's not cool (understatement). Especially if it's just because you're bored.

<comment><USER5> Although I'm sympathetic to your general view, driving under the influence is in fact a victimless crime. If the crime were "causing damage or injury as a result of driving under the influence", then it would have a victim, but getting drunk then driving somewhere and not hurting anyone is still a crime, but has no victim.

You could say you're increasing the risk for everyone else, but the same can be said for use of PCP or meth or some drug that correlates with higher rates of violent crimes, and those are acknowledged to be victimless crimes.

<comment><USER6> Its a sliding scale. What's the chance of this 'victimless crime' turning into a real one? And that ranges from property damage to manslaughter to killing whole families.

There's a risk/reward analysis at work here, an driving under the influence has had a very, very bad track record.

<comment><USER5> Well it just is a victimless crime is all. Clearly the author of the parent post didn't hurt anyone, so it had no victim.

It's probably not worth it to get into it, but I think I'd prefer a situation where you don't get punished for "pre-crime" like driving under the influence, but you get punished extra harshly for anything that causes damage as a result of something like that. So crash into a pole when sober, pay a fine. Crash into a pole when drunk, fine plus 3 months in jail. That sort of thing. Similarly you can imagine a lot of the outrage about jaywalking would go away if jaywalking were legal everywhere, but causing an accident or traffic jam while jaywalking would carry a hefty fine. This allows people to make local risk assessment decisions for which they are taking responsibility (it's 2 AM and there are no cars around - is it worth it to cross now knowing that if I do end up causing an accident or traffic jam it'll cost me $500?). Not saying it's a perfect system, but it seems like a start in addressing the legitimate concerns people have about victimless crimes.

<comment><USER4> Crash into a pedestrian, and you go to jail for 3 extra months?

I am biased because I lost a parent to this, but unlike, say, smoking weed in your house, driving under the influence has a near 100% chance of endangering people around you. Just like how people need a license to drive a car,it's not unreasonable to ask you to not be so selfish as to endanger those around you just because you got wasted and want to drive home in your 3 ton machine.

<comment><USER5> I was using crashing into a pole because it's something where you can see where you could plausibly have a huge disparity in sentencing outcomes in relative terms (there are always going to be thorny issues when you kill someone because even if you weren't driving drunk they're going to be picking apart all the different fault and negligence aspects anyway). For killing a pedestrian, you'd presumably make it so that killing someone while driving under the influence is presumptively negligent homicide as opposed to something like vehicular manslaughter.

Additionally, it's disingenuous to say there's a "near 100% chance of endangering people around you". That's saying that there's a 100% chance that you've increased the risk by some amount. There's nothing even close to a 100% chance that you will actually do any _damage_ to people around you, or crash. According to [1] there are 112 million self-reported episodes of impaired driving, and 1.4 million arrests, but 10,000 deaths. Obviously these are not hard numbers, but my guess is that driving under the influence likely triples or quadruples an existing (small) risk that you would kill or harm someone. That's not a trivial thing, but it would still mean that in the vast majority of cases, if you drive under the influence, everyone gets home safe.

And in any case, _I 'm not in favor of people driving under the influence_. Similarly I don't think people should drive while tired (it's a similar rate of impairment), but the simple fact is that these crimes _by themselves_ don't have victims, they are just occasionally the cause of actions which _do_ have victims. You can certainly make the case that drunk driving should be against the law for any number of reasons, but that's a separate issue as to whether that crime actually has a victim.

1\. [http://www.cdc.gov/MotorVehicleSafety/Impaired_Driving/impai...](http://www.cdc.gov/MotorVehicleSafety/Impaired_Driving/impaired- drv_factsheet.html)

<comment><USER6> Don't trivialize those 10,000 deaths. That's one in 11,000 drunk-driving episodes. Deaths, not some euphemistic small risk. Easily worth trying to mitigate. Absolutely makes it worth classifying out of the 'victimless crime' category.

<comment><USER5> For one thing I'm not trivializing them, I'm saying that saying that "100% of the time you are endangering people" is disingenuous considering there's only a 0.01% that anyone actually dies if you drive under the influence. There's not a whole lot to offer in the "benefits" column of drunk driving, so it's probably not reasonable even for fairly small increases of risk anyway.

And no, it does not make it worth classifying "out of the victimless crime" category, because victimless is not a matter of degree, it's a question of whether or not there is an aggrieved party. Any time there's an accident as a result of drunk driving, then it's got a victim. Otherwise there are only "potential" victims.

Again, I think it's a behavior that needs to be discouraged, because it forces people not capturing any of the benefit (the drinking, the convenience of being able to take your own car afterwards) to assume some of the risk (the chance that a drunk driver will harm them or their property). I'm just saying that driving drunk _by itself_ doesn't inherently have a victim.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> As a student who's followed the rules and essentially played by the book for pretty much my whole life, part of me regrets not doing stuff that defies norm, but another part of me is scared to think what I would look like if I got caught up in the 'wrong' things and never got interested in something useful.

I'd say this article is not necessarily the biggest advocate for delinquency, rather, it advocates for self-discovery in children, which is rare in modern parenting and educational systems. Sometimes this 'self-discovery' can lead to incidents of delinquency, but I think it's best to do dumb stuff young so you learn bad from good based on experience.

<comment><USER8> This may not exactly be delinquency, but as kids I and a friend _loved_ to explore construction sites on weekends. We never did anything dangerous really, it was just highly fascinating. But as we grew older, people who saw us started threatening to call the police, assuming we might be stealing something :( So in hindsight, I do wish we had used that "window of opportunity" even more. I have no idea how I would feel about my own children, should I have those; but we personally weren't reckless, stupid or malicious about it, just very curious and creative. The things you can get away with as a child, used well, can be a beautiful thing ^^ Not that we did anything great or learned anything useful, but it sure beat watching TV.

<comment><USER9> > but as kids I and a friend loved to explore construction sites on weekends.

Hehe that reminds me I did that with my dad, once. Looking back it was very dangerous but it was great fun. It was a new site for a 9 story residential building right next to ours. Once we thought we'd get caught by the guard, as we heard steps, so we hid, and it turns out it was some other people also exploring the site.

Another thing we did was climb a parachute training tower, and also hopped on a slow moving cargo train to hitch a 3 km ride towards my grandparents' house.

Aside from that (which if anyone knows me would totally uncharacteristic of me, but I guess it was more my dad than me), I was a pretty awkward nerd that liked tinkering with electronics (and later computers) and had only a few friends.

<comment><USER10> Do you think it might be that your father was trying to toughen you up a bit? Get you out and playing with the other teenagers?

Parents of nerds sometimes get worried like that. Which is also a 'self- determination' type issue just as much as raucous behaviour.

<comment><USER9> > Do you think it might be that your father was trying to toughen you up a > bit?

Who knows, it is possible. It was a fun thing to do, I look at it as more of a "hey let's do a crazy thing together" and one of the things I remember fondly.

> Parents of nerds sometimes get worried like that.

He was also a bit if nerd, and I think how I said "people would be surprised to hear I did those things" they would not a lot less surprised to find out my dad did those with me as well.

</comment></comment></comment></comment></comment><comment><USER11> Seems to be a meme that "back in my day kids just played and that was good!" Yeah, sure I played with Lawn Darts that were basically 12" long pieces of flying death, but I'm pretty sure I was lucky not to get injured. I try and get my son off the computer to do things, but I feel all these articles are more anecdotal than factual. I let my son fire of fireworks and what have you, but having had to rush the neighbor's kid "who doesn't get much supervision" to the hospital, I can say there is no invulnerability shield around children. They should play and have some risks, but as I was recounting just yesterday how I engulfed my childhood best friend in a giant fireball from a a gasoline fire, I was thinking maybe there are some things kids don't need to be doing...

<comment><USER12> You're right, you were lucky. Kids who do stuff sometimes die. Life is a deeply, profoundly unfair thing, in ways that cannot be fixed. If you want to have a life worth living, you have to do stuff, but that entails risk that something terrible might happen. I was tempted to say "but that doesn't mean you should take stupid risks like playing with gasoline" but then I realized even that was wrong. We took away chemistry sets and only later did somebody ask a bunch of scientists what got them interested in science, and it seems like quite a few of them say things like "burning/blowing stuff up."

[http://archive.wired.com/wired/archive/14.06/chemistry.html](http://archive.wired.com/wired/archive/14.06/chemistry.html)

"Vint Cerf – who became one of the architects of the Internet – spent months blowing up thermite volcanoes and launching backyard rockets. Growing up in Colorado, David Packard – the late cofounder of Hewlett-Packard – concocted new recipes for gunpowder. The neurologist Oliver Sacks writes about his adolescent love affair with "stinks and bangs" in Uncle Tungsten: Memories of a Chemical Boyhood. "There's no question that stinks and bangs and crystals and colors are what drew kids – particularly boys – to science," says Roald Hoffmann of Cornell University, who won the Nobel Prize for chemistry in 1981. "Now the potential for stinks and bangs has been legislated out.""

Maybe you don't get these great people if you remove their freedom to explore in their formative years. But that freedom also meant a bunch of kids blew their hands off or worse, and if your kid dies in a gasoline accident, it's your fault as a parent and nobody says "well he just wanted his kid to be Nobel Prize material, valiant effort." It's unfair, but reality doesn't care. All you can possibly change is the societal attitude, not the actual fact that freedom means some unsupervised kids always are gonna die and it might be yours.

</comment></comment><comment><USER13> I was very bookish as a child, and rarely did anything quite as exciting as the author describes, so I have a hard time relating. I also wonder if the author would look down on me for that, as the more "adventurous" kids did when I was a child.

<comment><USER14> It's about the FREEDOM to do it. Whether you actually do it or not is irrelevant.

</comment></comment><comment><USER15> In some ways, the most startling thing about this essay is the work affiliation of its author: "John Beckman is an English professor at the United States Naval Academy and the author of 'American Fun: Four Centuries of Joyous Revolt.'" On my own part, as a parent of four children, I encourage my children to be defiant in applying higher principles to analyzing whether or not to follow arbitrary rules. My oldest son coined the phrase "conform to nonconformity" when he was stifled by some of the silly customs at JHU-CTY camp. But for the most part, although young people try random misbehavior all over the world, there is a lot more personal development to be had from self- discipline in pursuit of curiosity and independence than from mindless thrill- seeking.

<comment><USER16> Relevant: One of my favorite pg quotes, from [http://www.paulgraham.com/word.html](http://www.paulgraham.com/word.html):

"Like real world resourcefulness, conversational resourcefulness often means doing things you don't want to. Chasing down all the implications of what's said to you can sometimes lead to uncomfortable conclusions. The best word to describe the failure to do so is probably "denial," though that seems a bit too narrow. A better way to describe the situation would be to say that the unsuccessful founders had the sort of conservatism that comes from weakness. They traversed idea space as gingerly as a very old person traverses the physical world."

Since reading that, I've loved the idea of traversing idea space the way you might look for easter eggs in video games- click all the things, flip over all the stones!

</comment></comment><comment><USER17> I am the "free range" parent and my wife is more of a helicopter parent–which is weird because my wife got in way more trouble as a teen.

When I was a kid, I took my BB guns places I shouldn't have, I never owned a bike helmet, and trampolines didn't have safety nets. Other than some things like that, I let my kids (ages 6, 8, 9) do as they please during their free time. My over-arching rules for them are "have fun, be kind to each other, and be safe". I'm sure I'll have to set more specific boundaries as they get old but for now it's fun to watch them just be fun, wild, dirty, creative kids.

(on a side note, I'm not sure "delinquency" is the term Id use)

<comment><USER18> I think it's reasonable to replace "which is weird because" with "which makes sense because" in this remark.

The version of your rules that I grew up with was "trust God and do Good". Religious angst aside, I don't think there's a minimum age for being able to tell the difference between serious, considered principles and ridiculous, unfounded assertions like "If you don't wear a helmet, you will get hit by a car and die."

</comment></comment><comment><USER19> "A ship is safe in harbor, but that's not what ships are for."

</comment><comment><USER20> As a child, I had all sort of dangerous adventures. As a 5 year olds (I don't really remember this one), we built a bonfire and got caught. As nine year olds we snuck out and went canoeing on "borrowed" canoes. At 12 we played around a farm with petrol. We climbed barn rafters hunting pigeons.

At 15-16 I smoked a lot of grass. We misused it and smoked much more than I would now. I had deeply tripy experiences dozens of times. Some of them scary. I don't think grass is bad, but I think it's tricky for kids, especially as it is basically open criminal activity. It create a distance between them and the police/teachers/parents.

I wouldn't take any of those experiences back. I find I like people who had such experiences as kids and that when I meet 19-20 year olds without them, I kind of think it's impoverished.

OTOH, I can't imagine standing by and letting 15 year olds smoke large quantities of grass or 9 year olds go canoeing by moonlight unsupervised.

All those things take casualties.

Catch 22.

</comment><comment><USER21> At the tail end, this goes tragically wrong. The author mentions cocaine, alcohol, and a loaded handgun.

One of my kindergarten friends got drunk one night and started playing with a handgun when he was 14. He'll be in prison until he's 45, without help from any cocaine. [1]

I think getting into a bit of mischief is a proper part of growing up, but I think the author advocates a bit too much.

[1] [http://law.justia.com/cases/minnesota/court-of- appeals/1996/...](http://law.justia.com/cases/minnesota/court-of- appeals/1996/c6952405.html)

</comment><comment><USER22> As a parent of two young kids, I agree - as long as the delinquency does not actually injure them or others badly, and they stay away from red-heads with loaded fucking guns!

Which is the whole problem - the reason we say "dont do that it will hurt" is that it probably will hurt. Yes kids need to learn their own limits, and I want that to happen. I just would prefer not to have the lesson end in A&E.

I think mobile technology will enable a longer "lead" \- but then who wants to be on a lead.

I think ultimately - I am my dad :-)

<comment><USER23> Um. ...red-heads...? Do you mean hotheads, perhaps?

<comment><USER24> I believe it's a reference to the article

<comment><USER22> Yeah - kid who was presumably abused by parents, sold drugs, beat up other kids, had access to firearms. Kind of glossed over a backstory in the article I felt.

</comment></comment></comment></comment><comment><USER10> _" There was one notorious kid with invisible parents who, when he was an eighth grader, already wore the blond bristles of a beard."_

Wonder what happened to him? Sounds like he was on a trajectory leading to problems.

<comment><USER25> If his path did lead to downfall, I'd say it was because he didn't fit into society's structure. In times past he might have become a great leader or warrior.

<comment><USER4> >In times past he might have become a great leader or warrior.

Is it a bad thing that warlord is no longer a thing we put onto our resumes?

<comment><USER25> I believe so. However, warlords don't write resumes, because they work for nobody.

</comment></comment></comment></comment><comment><USER26> The article fails to realise that in most of the anecdotes retold; today the state would intervene at the behest of a neighbour and "I read it in the New York Times" will not really prevent the investigation into why you allowed your child to play with knives, live for 3 days at the top of a slag heap of rubble or hold a loaded handgun.

Also - teenage mortality has reduced drastically[1]. It's hard to argue that could be a bad thing.

It is probably because we don't let them (wherever possible) carry out activities that might kill themselves.

I am a parent of 3; I will happily take my children mountain climbing, skiing, snowboarding, trekking, wild swimming. In a few years we plan to trek to Everest Base Camp and they are coming with me to the Andes.

We engage in _controlled risk._ If they break a limb skiing then they break a limb skiing. They pushed beyond their abilities in some way. I don't need to give them wrappers of cocaine from a criminal and a handgun to be a better parent.

There is also a very real risk of the "Tom Sawyer" bias. Each generation thinks their generation took greater risks and had more vivid adventures than the one previous. The cognitive dissonance curiously avoids the higher levels of child abuse, abduction, injury, poisoning, asphyxiation, malnutrition and disease. My father used to have great adventures playing as a child in asbestos riddled houses. You can talk to his friends about it sometimes...well the few that have not died before 60.

Oh look here is a group of kids that used lethal asbestos as chalk. [2] They really learned a valuable lesson about ad-hoc citizenry there.

[1][http://www.cbs.nl/en-GB/menu/themas/gezondheid- welzijn/publi...](http://www.cbs.nl/en-GB/menu/themas/gezondheid- welzijn/publicaties/artikelen/archief/2013/2013-3782-wm.htm) [2][http://www.bbc.co.uk/news/uk-england- tyne-24942338](http://www.bbc.co.uk/news/uk-england-tyne-24942338)

<comment><USER27> When did swimming become "wild swimming"? Is this just the first time I'm seeing this phrase?

<comment><USER28> Probably to differentiate from swimming-pool swimming?

</comment></comment></comment><comment><USER29> If the US were not that culturally focused on suing each other until death for stuff like spilling yourself with hot coffee and then suing McD for damages, kids in the US could be kids again.

<comment><USER30> The woman in Liebeck v. McDonald's [1] suffered third degree burns to 6% of her body and had to have skin grafts. The coffee was served around 180-190F (82-88C).

On the face of it, it may sound like a frivolous law suit but if you look into the details, it was far from it.

[1] [http://en.wikipedia.org/wiki/Liebeck_v._McDonald's_Restauran...](http://en.wikipedia.org/wiki/Liebeck_v._McDonald's_Restaurants)

<comment><USER26> Did she think it was ice-coffee? Had she ordered an ice-frappe and been delivered hot coffee which is typically made with freshly boiled water?

<comment><USER31> McDonalds had been warned about servig their coffee so hot; they had previously settled suits from hot coffee; they were serving coffee hotter than their rivals.

Try making a coffee today and taking the temperature of that coffee ten minutes after making it. I doubt it'd be hot enough to cause full thickness burns.

<comment><USER32> Where'd you get the 10 minute number from?

Also, if you put a lid on coffee (which you'd do when you want it to stay warm as when it's not necessarily for immediate consumption), it can stay hot quite a while.

Personally, I don't believe most people would have gotten third degree burns in a similar situation. Unfortunately, she was old (79), light (therefore likely frail; 47kg), and wore cotton (absorbent) sweatpants, and she must have kept them on for at least 12 seconds according to the evidence her own lawyers presented. Frankly, that's just a bunch of bad luck piled up. Most people would have stood up when the coffee spilled toward them, not sat in it for that long, and most people would have taken off at least partially the hot pants, thereby distributing the heat better, some people probably would have their pants off entirely by that point. (Wikipedia claims scalding rarely results in third-degree burns, let alone third degree burns on 6% of your body's surface area with a lot more second degree burn area).

Even at boiling point you need a number of circumstances to get this kind of injury. It takes quite a while, and needs to affect a large surface area, and needs to somehow be retained near the skin. That's just not all that likely to happen; and when it does, being old and light make recovery slower and less likely. She simply had the worst circumstances on all fronts.

<comment><USER31> 10 minutes is a pure guess at the time it takes to serve the coffee, pay for it, walk out of the restaurant, get in a car, be driven as a passenger, pull up some place and adjust the coffee.

> Even at boiling point you need a number of circumstances to get this kind of > injury. It takes quite a while, and needs to affect a large surface area, > and needs to somehow be retained near the skin.

2% of non-fatal household scald injuries in > 65 year olds needed tranfer to specialist hospitals for specialist treatment. If that's what you mean by rare then I guess we agree, but it's not what I'd call rare.

[http://www.cdc.gov/mmwr/preview/mmwrhtml/mm5836a1.htm?mobile...](http://www.cdc.gov/mmwr/preview/mmwrhtml/mm5836a1.htm?mobile=nocontent) (apologies for mobile link)

The CDC used to have tables for the length of time it took to achieve partial thickness or full thickness burns at various water temperatures.

At just 60 C it takes only five seconds to get a serious scald. At the temperature of 80 C burns are almost instant and probably require surgery.

Here's a nice chart with plenty of sourcing so we can check it for accuracy.

[http://www.accuratebuilding.com/services/legal/charts/hot_wa...](http://www.accuratebuilding.com/services/legal/charts/hot_water_burn_scalding_graph.html)</comment></comment></comment></comment></comment></comment>


Ask HN: Why aren't more people trying to cure ageing? - <AUTHOR> We know it could be possible, in theory. So why aren't more people trying to?<p>Disclaimer: I'm trying to (sort of), and I know there are a lot of initiatives. I'm just curious to why there isn't more, given what's at stake. <comment><USER2> When asking why more people aren't working on something that's high-risk & high-reward, it's best to look not at the goal itself, but rather how working on that goal is rewarded for the participants. For example, I spent almost a decade working on nuclear fusion. In theory, the reward for success would be very high. However, the reward for a small success isn't amazing (basically running a long-term research project, similar to a tenured professorship). And very few people who work on fusion get to that point. Most end up as frustrated post-docs, trying to compete for limited funding with researchers who have been established for decades. A lot of people leave once the personal cost gets bigger than the stars in their eyes.

So, because a successful long-term research project needs good human capital more than almost anything else, it helps to have:

1) Good rewards for small successes. This could be easy for life extension research if the intermediate step of "add 1 year" is rewarded well and the reward is public (so people know the reward is there).

2) An allied industry which provides jobs for "failures", from which they can regather strength before jumping back in. Silicon Valley has done well because failed software startup founders can work at a big software company for a while before jumping back in. Fusion suffers from the fact that once you get a job in another industry, jumping back in is difficult. I don't know if medicine is so specialized that this is a problem for aging cures.

3) A popular perception that the goal is achievable. Fusion does better at this than curing aging. This ties back into the "reward small goals" in point 1; publicly achieve small goals and the big goal doesn't look so impossible.

Good luck! We all hope you are able to contribute to an aging cure!

</comment><comment><USER3> 1\. Most/many drugs have side effects. A "cure" for aging would have to have a very weak side effect profile as it's not a terminal disease in the short run. 2. Clinical trials for aging would take a long time to run and be quite costly. 3. People are trying to cure this and quite a bit of money has been put into curing manifestations of aging (think all the Alzheimer's companies or Unity Biotechnologies.) it's also just really hard science...

</comment><comment><USER4> What is at stake ... ?

Certainly we know by now Earth's resources aren't infinite ... So I pose to you what could come from Pandora's box should choose to open it.

Wisdom an Experience come from aging, where do we go, and how do we grow, if that aspect of life becomes irrelevant?!

<comment><USER5> But we are also currently attempting to be multi-planetary, and though Earth's resources may be finite, perhaps the solution to living forever is using less resources (doubtful, but can't we cross that road when we get to it)?

We shouldn't try to create an electric self-driving car because it might kill somebody, but people are being killed by non-self-driving cars, so are we really any worse off?

If the limit of Earth's resources means that we will run out and some of us who would live longer will die earlier than we'd hope...well, we're already doing that.

</comment></comment><comment><USER6> Cure death? Or cure the debilitating diseases that occur in later life?</comment>


Pricenoia - compare prices at every amazon site worldwide - <AUTHOR> https://pricenoia.com pretty simple, cool and useful site.. compares prices of a product on every amazon store, in your currency, including shipping costs. <comment><USER2> It would be nice to have a browser extension (or Greasemonkey script) and a setting for choose currency manually (not based on geo- or language settings)

<comment><USER3> I saw it just adds a param when you change country, like:

<https://pricenoia.com/htc-one-32gb-silber?country=US>

And also looks it understands amazon codes diretly:

<https://pricenoia.com/B00BFUS8C6?country=US>

Easy to add in a greasemonkey script.

<comment><USER2> But my point is exactly that the country and currency tied together too tight. I want to choose my country (non-US) for delivery calculation _and_ USD for payment - because the card I use for Amazon is nominated in USD and because currency of my country is just too volatile.</comment></comment></comment>


Mars Attacks - <AUTHOR> http://blog.cloudflare.com/mars-attacks

<comment><USER2> shouldn't public DNS servers ignore packets from IP addresses that shouldn't appear in the public internet ?</comment>


I made a ruby library for accessing hacker news - check it out! - <AUTHOR> http://github.com/bolthar/ruby-hackernews

<comment><USER2> It might be fun to scrape and index all HN stories; and perhaps create a way to download links/comments to a local machine automatically . There is a lot of really great information provided via this place.

<comment><AUTHOR> The idea is interesting indeed - and easily doable as well: Entry.all gives you all the links on the front page, you'd just have fetch the main page between regular intervals of time (say, once every hour) and then save the entry information to a database.

Could you elaborate on this? If you can provide better "specifications" I'll implement this and add it to the library.

<comment><USER2> I imagine this:

-DOWNLOAD HN pages locally OR to another site

This is to make a permanent copy of the site and its discussions locally, so you'll have the knowledge of the articles and discussion forever.

Either download the linked site itself, or just the link, folowed by comments. Automatically grab comment updates once a day for a week, or whenever discussion statistically tapers off.

In other words, here are the options:

-Submission titles, dates, and links to HN page

This is to provide a searchable database for HN links, and perhaps (if this were done on a separate website) you could implement a "favorites" system for people to login and bookmark those topics of discussion they liked most, ala Server Fault.

Downside: I don't know how long HN articles persist. If they disappear, this is largely useless.

-Linked sites themselves, URL to HN page, and comments

Much more permanent; a complete mirror of source sites and HN discussions, searchable. Similar login/favorites iface could be put in place.

Downside: More information is cached, more complicated scraping (source sites and HN).</comment></comment></comment>


Show HN: Cryptogami – Social trading and analytics for cryptocurrency trading - <AUTHOR> https://www.cryptogami.org <comment><AUTHOR> Hey everyone (or no one :) )—I built this over the weekend because trading in the dark causes you to miss a lot of information and opportunities that you may have found otherwise. Would love to get some feedback and/or opinions. etc! Thank you!

<comment><AUTHOR> Better luck next time I guess! :-)

</comment></comment><comment><USER2> Hi Nik, great idea! Will be good to see it in action before asking to register, too little info yet to overcome the friction to register.

<comment><AUTHOR> thank you so much! I was hoping the info cards displayed would make it kind of obvious what the interface will be like. Do they not provide enough information? Or how do you think that could be improved? Thank you, I really appreciate your help.</comment></comment>


Ask HN: What's the difference between apps subdomain and the news subdomain? - <AUTHOR>

http://news.ycombinator.com/
vs.
http://apps.ycombinator.com/
since when there is this apps sub-domain?
what's the point of the apps sub-domain? <comment><USER2> Last time that this was asked (with an answer from pg): <http://news.ycombinator.com/item?id=1181897>

<comment><AUTHOR> weird, I HNsearched it [http://www.hnsearch.com/search#request/all&q=apps.ycombi...](http://www.hnsearch.com/search#request/all&q=apps.ycombinator&start=0) and didn't find that thread.

<comment><USER2> I searched for "apps.ycombinator.com" instead of "apps.ycombinator"

\- "apps.ycombinator.com" (64 results): [http://www.hnsearch.com/search#request/all&q=apps.ycombi...](http://www.hnsearch.com/search#request/all&q=apps.ycombinator.com&start=0)

\- "apps.ycombinator" (2 results): [http://www.hnsearch.com/search#request/all&q=apps.ycombi...](http://www.hnsearch.com/search#request/all&q=apps.ycombinator&start=0)

I don't understand why there is such a big difference. Perhaps the search engine parses the domains in a special way.</comment></comment></comment>


Ask HN: Production Lisp in 2020? - <AUTHOR> I have gone through initial chapters of "Practical Common Lisp"[1] and "Loving Common Lisp" [2], and have a bit of intuition on lisp, and the power of macros. Haven't done any projects yet, but was also researching on real issues faced by adopting lisp, and ran into articles about abandoning lisp [3], adopting lisp [4],[5]. Could not find anything more recent; but what they mention in these articles - even the ones that are adopting lisp talk about issues like:
* poor ecosystem of libraries - few gems, most other half-baked
* poor community coordination
* Dependency management limitations with quicklisp
And some specific red flags like:
* poor support for json[6] * poor support for async
* have to restart the server every 20 days because of some memory leak [3]
* hack to tune GC [5]
If you are using lisp in production for non-trivial cases,
do these issues still exist? is there a way you can quantify effort is resolving them, and if yes, what is it? and, finally, if you had to re-do your project, would you chose lisp or something else?
[1]: http://www.gigamonkeys.com/book/
[2]: https://leanpub.com/lovinglisp/read#quicklisp
[3]: https://lisp-journey.gitlab.io/blog/why-turtl-switched-from-...
[4]: https://lisp-journey.gitlab.io/blog/why-deftask-chose-common...
[5]: https://www.grammarly.com/blog/engineering/running-lisp-in-p...
[6]: https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/#s4... <comment><USER2> Yep, I've used Common Lisp in production. Several times. I'm in the middle of writing a new app with Lispworks right now.

Common Lisp is generally the first thing I think of for any new work I undertake. There are exceptions, but usually my first choice is Common Lisp. It has been for a little over thirty years.

I've often worked in other languages--usually because someone wants to pay me to do so. I usually pick Common Lisp, though, when the choice of tools is up to me, unless some specific requirement dictates otherwise.

The objections you list might be an issue to some extent, but not much of one. Certainly not enough to discourage me from using Common Lisp in a pretty wide variety of projects. I've used it for native desktop apps, for web apps, for system programming, for text editors, for interpreters and compilers. When I worked on an experimental OS for Apple, the compiler and runtime system I used were built in Common Lisp.

I'll use something else when someone pays me enough to do it. I'll use something else because it's clearly the best fit for some specific set of requirements. I'll use it when there isn't a suitable Common Lisp implementation for what I want to do. I'll even use something else just because I want to get to know it better.

I've taken various detours along the way into learning and using various other languages. I like several of them quite a bit. I just don't like them as much as Common Lisp.

The pleasure I take in my work is a significant factor in my productivity. Choosing tools that offer me less joy is a cost I prefer not to bear without good reason. That cost often exceeds the advantage I might realize from using some other language. Not always; but often.

There was once a language I liked even better than Common Lisp. Apple initially called it 'Ralph'. It evolved into Dylan, which, in its present form, I don't like as much as Common Lisp. If I or someone else invested the considerable time and effort needed to write a modern version of Ralph, then I might choose it over Common Lisp.

For now, though, I'll stick with the old favorite. It continues to deliver the goods.

<comment><USER3> Care to elaborate on how Ralph was different from cl/dylan? Or at least point me to some resources to read more about it? I don't seem to find anything specific on the internet. Thanks

<comment><USER2> When Ralph was new, it was essentially a hybrid of Common Lisp and Scheme. It was very much a Lisp--not just technically, or in matters of surface syntax, but down in its bones.

The surface language was basically Scheme, with some special forms removed and others added or renamed. The type system was basically a simplified Common Lisp Object System; all values were instances of CLOS classes.

The compiler, runtime, and development environment were built on Macintosh Common Lisp. Ralph inherited MCL's design and aesthetics.

Like Common Lisp, it was designed for writing software by interacting with it and modifying it as it ran. That's the essential point.

The project I worked on, bauhaus, was running basically all the time we worked on it. We worked on it by interrogating and hot-modifying the running system, in the time-honored tradition of old-fashioned Lisp and Smalltalk systems.

Later Dylan was not like that. It evolved into just another batch-compiled application language. You edit some files. You batch-compile them. You run the resulting artifact for testing. Rinse and repeat.

That's how OpenDylan is today. That's why it lost me.

It's also what's wrong with some newer Lisps, from my point of view. They aren't designed for building programs by modifying them from inside while they run. They don't know how to handle existing data in the presence of redefined types. They don't provide interactive debuggers and inspectors that can be used to rummage through the memory of the running program, edit it while it runs, and conitnue execution.

Common Lisp provides these features, and has done for decades. Ralph provided them. Smalltalk does, too. If all the Common Lisp implementations in the world suddenly evaporated, I could get along fine with Smalltalk, after a brief period of adjustment. It's probably purely an accident of history that I'm a Lisper rather than a Smalltalker, anyway.

But Dylan doesn't have those essential features anymore, and nothing that lacks them is likely to win me over--not OpenDylan, not Julia, not Clojure or Haskell, or F#. I like all of those languages, but not nearly as much as I like my livecoding.

<comment><USER4> Strongly agree with that viewpoint and the central paradigm it describes, it's what's made my 15 year investment into Lisp more than worth it. It's also what makes every newly emergent language not measure up to Lisp: None of them focus on interactive development. In fact, the only one I'm aware of that (partly) did that was Slava Pestov's Factor but ultimately, it was more a proof-of- concept than anything that could be considered practical and is now languishing.

Later, Slava went to Apple to work on Swift, which turned out to be another mediocrity, lacking any sort of originality / vision and having a firm expiration date. There used to be a time when programming languages focused primarily on end-user empowerment and paradigm-centered computing was the norm (e.g. Seymour Papert's groundbreaking research in constructionism and incremental learning / development). There is precious little left of that now.

<comment><USER5> Hmmmm...PharoSmalltalk, 8th (same rough family as Factor), Mathematica, Dyalog APL, J, K...lots of tools that are fully interactive in their bones.

<comment><USER4> I wouldn't characterize Pharo/Mathematica/Dyalog APL as newly emergent, they've been around for a long time. I can't say anything about J and K since I've never used them but my superficial impression is that they are focused on a specific niche, not as general purpose as most Lisps. They've also been around for a long time.

8th I have actually looked at and it's both _not_ particularly interactive (certainly nowhere near as interactive as Factor) and has a very strange license [1] to boot which makes it a total nop for me. It has been criticized before [2].

[1] [https://8th-dev.com/com-license.html](https://8th-dev.com/com- license.html)

[2] [https://news.ycombinator.com/item?id=15672361](https://news.ycombinator.com/item?id=15672361)

<comment><USER5> New is pretty relative, but yeah they've definitely been around for a while. I'd say the array languages (APL/J/K) can be used in far more areas than most people think, but I understand your point and am on the fence myself.

What is wrong with 8th's license? It is basically a Forth, so extremely interactive...mostly just messing with a stack...not sure about metaprogramming. I think a production license costs you $200 as a one time fee and you have to pay no royalties or anything for apps (better than many tools out there). Upgrading to a later version comes at a discount too. Most of the runtime is proprietary/closed-source if that is what you were saying (def understandable if you had a problem with that). Also, being a 1-developer project, progress is rapid, but I'd be worried about what happens if the maintainer wins the lottery.

<comment><USER4> The second link I included goes over some of the issues but regarding interactivity, just look at the videos its author produced to show it off. He's writing code in either VIM or the shell. That's a long way from Factor's image-based interactivity and a long long way from Smalltalk and Lisp Machine- paradigm Lisps.

Any language with a REPL can be described as "interactive" but that's not what having a strong focus on interactive development means. As Mikel Evins wrote, it's really about the entirety of a language being geared around interactive development.

<comment><USER2> It's "mikel evins".

I can't blame you for parsing it the other way; it's a more likely spelling. You can blame my eccentric father for the odd spelling of my first name, but he inherited the surname fair and square.

It's pronounced exactly the same way as "Michael Evans."

<comment><USER4> I'm always grateful when the map-territory distinction comes along and slaps me in the face. It's a signal that I should re-calibrate.

It's been a while, thanks for making it happen!

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> I think Reddit's decision to move from Common Lisp to Python is interesting and their reasoning (ecosystem) is still valid 15 years later.

The historical timeline is especially interesting because Reddit's cofounders Steve Huffman & Aaron Swartz were alumni of Paul Graham's first YC batch and PG is the author of the well-known Lisp essay "Beating the Averages":

\- 2001-04 Paul Graham : Lisp essay _" Beating the Averages"_ [1]

\- 2005-07-26 Paul Graham : [https://groups.google.com/forum/#!topic/comp.lang.lisp/vJmLV...](https://groups.google.com/forum/#!topic/comp.lang.lisp/vJmLVd9lJyk)

\- 2005-12-05 Steve Huffman : [https://redditblog.com/2005/12/05/on- lisp/](https://redditblog.com/2005/12/05/on-lisp/)

\- 2005-12-06 Aaron Schwartz : [http://www.aaronsw.com/weblog/rewritingreddit](http://www.aaronsw.com/weblog/rewritingreddit)

The takeaway from the Reddit case study is this: Yes Lisp macros and language malleability gives it superpowers that other languages don't have (the "Blub Paradox") -- but other languages also have _other superpowers_ (ecosystem/libraries) that can cancel out the power of Lisp macros.

You have to analyze your personal project to predict if the ecosystem matters more than Lisp's elegant syntax powers.

[1] [http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html)

<comment><USER7> I would like to consider Python a common lisp alternative. But it's one or two orders of magnitude slower and is not really standardized. I think there is a lot more that's attractive than just macros.

<comment><USER8> > and is not really standardized

What do you mean by this ?

<comment><USER7> My understanding is the Python standard is essentially whatever C Python chooses to do. They do write the changes to a specification separately, but essentially its one moving implementation, with alternatives that have compatibility limitations.

<comment><USER9> Indeed. I'm curious what Python 4 will do to Python 3.

</comment></comment></comment></comment></comment><comment><USER10> Rigetti Computing is a company that builds quantum computers.

We have used Common Lisp in production at Rigetti Computing for 4 years both in cloud deployment as well as for a downloadable SDK. Common Lisp is used to build what is currently the best free optimizing compiler for quantum computing [1, 2] as well as one of the most flexible quantum computer simulators [3]. They're both open source, so you can actually see for yourself how we version, deploy as binaries, and deploy in Docker containers.

> If you are using lisp in production for non-trivial cases, do these issues > still exist?

Before getting into the specifics, any large, non-trivial product that customers use will need tweaking. Especially languages that have runtimes, including languages like C. This is usually a result of leaky abstractions that just have to be dealt with in The Real World (TM).

> * poor ecosystem of libraries - few gems, most other half-baked

You have libraries for most things you need. Some are lacking, like in scientific computing. But all your usual stuff to glue things together is there and works.

Some people confuse "half-baked" with "no commits for 5 years". Lisp libraries are older than many in vogue languages, and Lisp doesn't change, so "5 years no commits" shouldn't be worrisome.

At Rigetti, the biggest weight we had to pull that we wouldn't have needed to do in, say, Python, is bind to a bunch of FORTRAN code, specifically LAPACK. That was a pain because you need to do FFI with complex double floats.

* poor community coordination

The community all agrees on one thing: Lisp is standardized.

Lisp lacks a sort of "centralized community" like Go or Clojure. I like to think that Common Lisp is more "democratic". We have a "constitution" (the Common Lisp standard) that we all agree on and we all make our own contributions atop that.

With that said, #lisp on Freenode is attentive. SBCL, for example, responds to bug reports almost immediately. Several library ecosystems are kept up to date, etc.

> * Dependency management limitations with quicklisp

With Quicklisp, I personally realized a lot of other dependency management solutions are overblown and don't actually solve problems. Maybe QL gets away with it because the ecosystem is smaller than others.

Xach, the creator of QL, does a lot of community diligence for free to ensure things work.

For production code, I've had 0 issues.

> * poor support for json

We use YASON [4] and it works fine.

> * poor support for async

This is true now but wasn't true years ago. Lisp implementers have not been interested in implementing a runtime supporting async programming. Little in the Common Lisp language itself prohibits it. Before the world of threads and SMP, Lisp implementers _did_ implement async runtimes.

Why aren't Lisp implementers interested in async? I'm not sure. Maybe they see it as a passing fad?

> * have to restart the server every 20 days because of some memory leak

Memory leaks can happen but they're usually the programmer's fault for not understanding symbol interning, weak pointers, or finalizers. Writing long- running applications does require know-how.

> * hack to tune GC

I don't consider it hacking. In SBCL we tune the GC to our application. This seems reasonable; different programs have different allocation patterns. But you wouldn't need to do this out of the box.

> is there a way you can quantify effort is resolving them, and if yes, what > is it?

Big applications that are customer products require care and feeding. The benefits of writing in Lisp in the first place largely outweigh some of the extra work needed to productionize it.

I will say that writing production Common Lisp code is greatly benefited by having at least one experienced Lisper on the team. If a team would, for some reason, write an application in Lisp but not really have a good understanding of the language, then productionizing and hardening will be difficult.

> and, finally, if you had to re-do your project, would you chose lisp or > something else?

Common Lisp allows something that never existed before (a completely automatic, optimizing quantum compiler) to exist. If Lisp weren't there, that wouldn't exist.

My parting advice is this: The biggest difficulty in writing an application is to actually write it. It takes a lot of hard work to get requirements, listen to feedback, articulate a direction, etc. In Common Lisp, SBCL or LispWorks or whatever else, dumping an executable is so easy and you can have a deployable "production app" in 5 minutes. So the good news is that you won't be held up trying to figure out how to dockerize your Python app.

I definitely agree that before embarking, doing an objective and relevant comparative analysis would be good (we did this at Rigetti), but ultimately you just need to sit down and write.

Almost every programming problem is solvable these days with enough glue and elbow grease. I wouldn't be too worried.

[1] [https://arxiv.org/abs/2003.13961](https://arxiv.org/abs/2003.13961)

[2] [https://github.com/rigetti/quilc](https://github.com/rigetti/quilc)

[3] [https://github.com/rigetti/qvm](https://github.com/rigetti/qvm)

[4] [https://github.com/phmarek/yason](https://github.com/phmarek/yason)

<comment><USER5> How complete are your LAPACK bindings?

<comment><USER10> They're complete in the sense that all standard functions are exposed. However, there's only a modest "high-level" interface.

The library: [https://github.com/rigetti/magicl](https://github.com/rigetti/magicl)

Comparison with NumPy: [https://github.com/rigetti/magicl/blob/master/doc/high- level...](https://github.com/rigetti/magicl/blob/master/doc/high-level.md)

</comment></comment></comment><comment><USER11> I'm using Lisp in production, our browser and all of our infrastructure is in Lisp [https://github.com/atlas-engineer/next](https://github.com/atlas- engineer/next).

TO address some of your points;

poor ecosystem of libraries: many great libraries, some incomplete. you must not be afraid to look at the source code to understand and edit

poor community coordination: true, there are few large scale community lisp projects. be the change you want to see

dependency limitations with quicklisp: like what? quicklisp works great. if you are talking about loading several versions of the same library at the same time in a single image, this is being researched and developed

poor support for json: no, there is good support

have to restart the server every 20 days: not familiar, I have had lisp servers running for years now

hack to tune GC: no

if I had to redo my project would I choose Lisp? I would choose lisp, yes. there is no more powerful language than this, and believe me, I have tried many

<comment><AUTHOR> The post [1] (though old) - hints at no good libs for json (mentions a workaround for one he picks)

      > For me, the most important quality
      I need in a JSON library is an unambiguous,
      one-to-one mapping of types. For example: some libraries
      will deserialize JSON arrays as Lisp lists,
      and JSON true/false as t/nil. But this means [] and false
      both deserialize to nil, so you can't reliably round trip anything!

Although this post is from 2018, wondering if it has improved since then.

[1] [https://stevelosh.com/blog/2018/08/a-road-to-common- lisp/#s4...](https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/#s48-st- json)

<comment><USER12> This just works:

        USER> (yason:parse "{\"null\" : null, \"false\" : false, \"empty\": []}"
                           :object-as :plist
                           :json-arrays-as-vectors t
                           :json-booleans-as-symbols t
                           :json-nulls-as-keyword t)
        ("null" :NULL "false" YASON:FALSE "empty" #())

Null is mapped to the :null keyword, false to a symbol named false in the yason package, and the empty vector to an empty lisp vector (in Lisp #(1 2 3) denotes a vector, whereas (1 2 3) is a linked-list). All threes can be distguinshed from the others.

All those options defaults to special (dynamically scoped) variables, so you don't have to pass them everytime.

Encoding prints to the standard output (you can redirect it to an http stream, if you want), so you don't see double-quotes being escaped, but the string is equivalent (modulo spaces):

        USER> (yason:encode-plist *)
        {"null":null,"false":false,"empty":[]}

The defaults in Yason just returns list for vectors, and map both null and false to nil, but this is not a problem: if you expect your field "items" to be a vector, then nil will denote the empty list, if you expect another field "enable-debug" to be a boolean, nil be good enough too. But in cases where you need to handle them differently, the library can help you distinguish among all kinds of value.

See [https://phmarek.github.io/yason/](https://phmarek.github.io/yason/)

</comment></comment></comment><comment><USER13> Clojure has a good ecosystem and you can fall back to Java's ecosystem if needed. It has excellent support for json, and acceptable async support (I use manifold + aleph, but there are other options). It runs on the JVM which has world class GC.

<comment><USER14> I want to understand the complementary picture. Assuming Clojure as a good default, what would be some specific kinds of tasks/problems for which one might wish to avoid Clojure? And what alternatives would you recommend, for those cases? (be it another lisp, or otherwise)

<comment><USER15> I wouldn't use Clojure if fast startup time is important for you. So it's okay for servers, but not okay for (in general case) for command line tools. With GraalVM this is changed a bit, but then compilation of non-trivial projects with GraalVM is also non-trivial.

If you need a low memory consumption then Clojure is also not a great choice.

We've built an ecommerce site on Clojure though and it's been great. :)

<comment><USER16> SCI or Small Clojure Interpreter is a subset of Clojure meant for quick startup.

Babashka is a library on top of SCI and is particularly suited to building command line tools. It doesn't need the JVM, starts up in milliseconds, has access to a large part of clojure.core (including core.async) and can be downloaded as a 13mb binary.

[https://github.com/borkdude/babashka](https://github.com/borkdude/babashka)

</comment></comment></comment></comment><comment><USER17> I delived a service in 2019 that was written 100% written in clojure. ReactNative app + SPA Web app + Server all sharing the same code.

The developer experience was great. I get subsecond hot-reload on all plataforms (app emulator/app on-device/web/server).

The same UI components was shared between ReactNative and ReactDOM. All App issues are reproducible in Web, then I fix in web and I'm sure that App is working.

Even SSR was possible, with some tweaks.

<comment><USER18> Got a public repo to share that would show how you pulled this off?

Barring that, as a sibling comment asks, what specific framework and/or libraries did you use to achieve the holy grail of sharing-all-the-things? (thought ReactNative required implementing separate UI for iOS and Android).

Sub second hot reload sounds amazing, btw.

<comment><USER19> Not sure this will help: ClojureScript RN app: (I think has desktop and all that as well) [https://github.com/status-im/status- react](https://github.com/status-im/status-react)

</comment></comment></comment><comment><USER20> CircleCI is mostly Clojure, and some Go.

The only problems we are seeing is the significant startup time cost (hence the Go bits, where it matters).

Memory usage also isn't always great, but that's more a JVM problem, as it's not releasing reclaimed memory as quickly as you'd like it to. Fine on servers, annoying on a 16GB laptop.

The Common Lisp problems you outlined don't really apply to Clojure, it's a modern lanaguage and has been stable and versatile for us.

<comment><USER21> Is the new frontend also written in ClojureScript? Seems you've closed sourced the frontend (old source is here [https://github.com/circleci/frontend](https://github.com/circleci/frontend)) but you used to use CLJS, but maybe new one is written in something else?

<comment><USER20> I'm on the backend, but all I've seen of the new frontend is TypeScript. There has been a decision to switch languages for reasons that someone else can probably explain better than I could, a lot of us lurk here.

</comment></comment></comment><comment><USER22> Perhaps you didn't mention it for a reason, but I am sure I won't be the only one to bring up Clojure in this thread, and others will argue for and against more eloquently. Obviously it lacks much of what makes people love Common Lisp, but it's more Lisp than not Lisp, and specifically addresses all of your points via the JVM and its ecosystem.

</comment><comment><USER23> First, thanks for linking my Living Common Lisp book. Common Lisp is my preferred language, but only for projects where I need/want an environment that support rapid experimentation of new ideas. If I know how to implement something and I want to deploy at scale, then I might not choose Common Lisp.

I am a happy LispWorks customer but I also use SBCL (efficient code, easy to package standalone apps) and Clozure Common Lisp (fast compiler for development).

</comment><comment> dan-robertson I've not used lisp in production. But I sometimes wish I did. In particular, whenever there's an issue with a production process (think a batch job rather than some kind of online processing), I wish I could attach a debugger, inspect some variables, and invoke a restart. I don't know how of any language that makes it more convenient to do that sort of issue-resolution.

I don't really care about libraries. I think generally it's not very hard to write an ffi binding to a C library and most of the time you don't need a library anyway. Most of the time you can just write your own library from scratch as you probably only need a few functions.

But maybe this is more a statement of the sort of programs I work on and if you worked on different systems you would want to use lots of external libraries that you don't control.

I think the biggest issue with CL is how tightly attached it is to an outdated standard. It makes it harder to have things like good Unix support if your interface is through pathnames and streams.

Other thing which may be annoying about CL are the lack of a good way to consistently go from source code to a binary and that compiler optimisations can be unpredictable

<comment><USER7> > consistently go from source code to a binary

Can you talk more about this?

<comment> dan-robertson Let's say I have a big repo full of lisp. I want a program that uses some subset of this lisp. Similarly to if I had a big repo full of C programs and libraries and I wanted to build one of those programs (statically linking all the libraries it used). In CL, it is annoying and tricky to go from those files to an executable I can deploy. Typically you'd write some script to (use ASDF to) compile/load your various files and then dump the image specifying a binary. It's a bit messy and not very portable.

<comment><USER24> I will never understand how people have such a rosy view of C development. Is it just that today people think there is only GNU make, and only GCC or clang?

Autotools used m4 because it was the most portable Unix tool, not because it's a good language to write your build scripts in...

<comment><USER7> I have had problems with C, but building my code was never one of them. You are right that I have only used GCC, Clang, and Visual Studio.

I thought they use M4 because they were doing sophisticated preprocessing?

<comment><USER24> I misremembered; M4sh (which uses m4 to generate portable bourne-ish shell scripts) is what was the lowest-common-denominator for autoconf.

</comment></comment></comment></comment></comment></comment><comment><USER25> Can't speak for SBCL (I use it exclusively for development and haven't deployed anything non trivial and user facing with it) but I have used Clozure CL (CCL) successfully to develop back end services without horror stories regarding the GC. If you end up needing huge heap sizes, in theory with ABCL you get access to state of the art GC algorithm implementations and (IMHO) a much nicer, less dogmatic language than Clojure.

I recently switched to LispWorks after struggling a bit with CCL's Cocoa bridge and I wish I had done that sooner. A much younger, idealistic me would scream at the thought of it but sometimes you just need to throw some money at a problem. CAPI is really a killer feature.

</comment><comment><USER26> We use CL for production (embedded/distributed system). CCL and Lispworks on low end ARM32.

We do use JSON but mainly for the product's Websocket API towards higher level SCADA system. As we have control over both ends there isn't much trouble really.

The project has soft realtime component also implemented with Lisp, and at least Lispworks exposes a substantial degree of control over GC. We however didn't need to tune anything thus far.

The system has perhaps a dozen direct dependencies to the libraries, luckily few of them posed any challenges in use.

<comment><USER27> If you don't mind my asking, what company is this? I'm a Lisp hobbyist working for a SCADA integrator, and while I'm not in the job market right now I might be in a few years.

<comment><USER26> It's norphonic.com, based in Norway. The product is not on the webpage yet though.

<comment><USER27> Ah, pity. I'd love to visit Norway sometime (I've heard great things), but my family won't move across the ocean.

Anyway, thanks for the reply.

</comment></comment></comment></comment><comment> foobar-xk Apple has been using Clojure in production for years, and is hiring: [https://jobs.apple.com/en-us/details/200000986/apple- media-p...](https://jobs.apple.com/en-us/details/200000986/apple-media- products-software-engineer-core-services)

Excerpt from the description: "These are the people who power the App Store, Apple TV, Apple Music, Apple Podcasts, and Apple Books. And they do it on a massive scale, meeting Apple's high expectations with high performance to deliver a huge variety of entertainment in over 35 languages to more than 150 countries."

</comment><comment><USER28> I use lispworks, the CAPI works well on allmost all platforms. They know what they are doing. Books: common lisp recipes, PAIP, ANSI COMMON LISP. The few libraries you need are very good.And you need Quicklisp. I stopped using C, C++, pascal, fortran, javascript. Altough they all are just fine. You still have to learn the craft of programming. Just go for it.

<comment><USER29> I'm going to second the recommendation of Common Lisp Recipes. The others too, of course (especially PAIP).

</comment></comment><comment><USER30> Not really production because the traffic is low, but I run [http://ichi.moe](http://ichi.moe) on SBCL (Hunchentoot web server) and I never had to restart it because of memory leak or a crash. I usually hot-swap the updates and the same server process stays up for months. It also heavily uses JSON and XML and the libraries for them (jsown and cxml) are perfectly adequate.

</comment><comment><USER31> I'm starting a new project in Lisp in 2020. That's rolling my own CAD tools for learning hardware development.

Lisp makes sense because it's a comfortable environment for interacting with my data. I'll be running the Lisp code "offline" so I'm not worried about runtime aspects like GC pauses and most of my I/O will be generating data for external tools (e.g. KiCad) in their own esoteric formats.

Coming back to Lisp it's nice to see that all my favourite software is still available and working fine, and there seem to be more active open source Lisp developers than ever. (Far fewer than Javascript, for example, but that's not my yardstick.)

</comment><comment><USER32> I am running a web app in production, with live reloads, no issues so far.

> * poor ecosystem of libraries - few gems, most other half-baked

I actually had the _choice_ for my libraries: DB interface, email sender, HTML template, data structure helpers… these ones with good documentation.

I have observed and explored the ecosystem for the last 3 years and I still find hidden gems. There are way more libraries than we can see at a quick glance.

We do a selection on [https://github.com/CodyReichert/awesome- cl](https://github.com/CodyReichert/awesome-cl)

> * poor community coordination

It looks like the oldest ones don't coordinate much and the youngers do (and push the established players, such as the CL foundation).

> * poor support for async

Maybe not for a full async runtime (cf Turtl feedback), but there is a good choice for all sort of async stuff (bordeaux-threads, lparallel, lfarm, channel, SBCL built-ins etc)

</comment><comment><USER33> I use Clojure and ClojureScript in production. The developer experience is a real pleasure: there is good library support, libraries are typically easy to use, and you can always interop with the underlying JVM/js if the need arises.

Clojure also has the core.async library. This can be used along with Reagent to build React-based apps; core.async allows you to do what Redux does but in fewer lines of code.

[https://github.com/deckeraa/OpenStainer](https://github.com/deckeraa/OpenStainer) is an example of building apps this way.

</comment><comment><USER34> Clojure is a production Lisp in 2020

<comment><USER35> Our health benefits startup has been using Clojure in production for some time. Efforts are ongoing to migrate the last bits from other JVM languages to Clojure, but ClojureScript is already ubiquitous.

</comment></comment><comment><USER36> I used to work in Common Lisp (SBCL).

The ecosystem problem meant something different to me than most. Sure, when new tech came out (Kafka to pick a random example) there wouldn't be an open source library ready for me. But I had stable infrastructure so I didn't really care much about that.

The ecosystem problem for me meant that if something went wrong I was on my own. It's a pretty unfortunate feeling to search for a bug and find _nothing_ on Stack Overflow.

<comment><USER37> > _It's a pretty unfortunate feeling to search for a bug and find nothing on > Stack Overflow._

Par for the course in embedded. So isn't going to tell you why the kernel driver for the ABC123 chip is locking up on the XYZ15 eval board from Such- and-Such vendor.

You debug it yourself, whipping out JTAG debuggers and oscilloscopes, if necessary.

Because I work in embedded, I don't understand the whole ecosystem fuss.

I mean, joy of joys, you have the darned source to almost everything nowadays. That makes everything so easy, that all else is a footnote.

<comment><USER38> I'm coming at this from the opposite side. Currently, it feels like most of my programming skills are really just Googling skills and remembering what a particular error message means. The market emphasizes this kind of programming by combining existing libraries and hoping things work, so it's really hard for me to break away from doing that and start to learn the way that stuff works internally. I think that this was the reason that they stopped teaching SICP in Scheme [0].

I can read source code (I do some security research for fun) and use a debugger, but I still feel like I'm programming by poking. What would you recommend to younger programmers to get out of this rut?

0: _In this talk at the NYC Lisp meetup, Gerry Sussman was asked why MIT stopped teaching the legendary 6.001 course, which was based on Sussman and Abelson's classic text The Structure and Interpretation of Computer Programs (SICP). Sussman's answer was that: (1) he and Hal Abelson got tired of teaching it (having done it since the 1980s). So in 1997, they walked into the department head's office and said: "We quit. Figure out what to do." And more importantly, (2) that they felt that the SICP curriculum no longer prepared engineers for what engineering is like today. Sussman said that in the 80s and 90s, engineers built complex systems by combining simple and well-understood parts. The goal of SICP was to provide the abstraction language for reasoning about such systems.

Today, this is no longer the case. Sussman pointed out that engineers now routinely write code for complicated hardware that they don't fully understand (and often can't understand because of trade secrecy.) The same is true at the software level, since programming environments consist of gigantic libraries with enormous functionality. According to Sussman, his students spend most of their time reading manuals for these libraries to figure out how to stitch them together to get a job done. He said that programming today is "More like science. You grab this piece of library and you poke at it. You write programs that poke it and see what it does. And you say, 'Can I tweak it to do the thing I want?'". The "analysis-by-synthesis" view of SICP — where you build a larger system out of smaller, simple parts — became irrelevant. Nowadays, we do programming by poking._

<comment><USER39> Edit-[optionally compile]-Run-[optionally step in Debugger] is addictive because the feedback loop is so tight, and it always feels like work. The way to break the addiction is to start working in a domain where there's significant friction to that process.

Work on a heavy-ass C++ GUI application that takes forever to load, with a big-ass code base that takes forever to compile, and you'll be thinking deeply about code in no time, because you can't program that sucker by poking when poking takes 40 minutes.

</comment></comment></comment></comment><comment><USER40> I really hope that Lisp will get a comeback in the space that is now occupied by XML and YAML. It's always the same story: Narrow minded engineers chose YAML (formerly XML) as the trendy simple configuration language and it works fine for a while. 3 years later they inevitably hit the ceiling with YAML and either start badly implementing new language features on top of YAML (see Gitlab CI's `when`, `only`, `except`, etc. syntax) that are never flexible enough or write hugely complicated templating tools (see Kustomize and Helm for K8S) for things that would amount to a simple if-expression in Lisp. This is the use case where Lisp can really shine. Configuration is almost always untyped and doesn't start out with a library ecosystem. Most of the time you just need a way to write a simple nestable DSL that is human readable. There's probably no language that makes this simpler than Lisp: Any college freshman could write their own interpreter. But it is also extremely flexible if it turns out that you need more power than YAML offers.

<comment><USER41> I don't think XML has been 'trendy' for ages :)

XML is totally fine for storing structured dumb data. Don't program in XML.

I would not be so bullish about implementing your own interpreter - as the best obvious choice every time.

Numbers especially are hard to get correct unless you know what you are doing.

<comment><USER7> I don't think this user is advocating using home grown interpreters. Rather it's easy to understand how they work completely.

The point is complex configurations tend to grow into a poor programming language. They would be far better as a lisp DSL.

</comment></comment></comment><comment><USER42> > poor ecosystem of libraries - few gems, most other half-baked

Definitely no longer an issue for Common Lisp. Quicklisp is da bomb.

> Dependency management limitations with quicklisp

Never had any issues. It Just Works for me.

> have to restart the server every 20 days because of some memory leak [3]

You can get memory leaks in any language. You're much less likely to have a leak in a GCd language than a non-GCd language. But seriously, if you can't easily restart your server whenever it's needed, you have bigger problems.

> hack to tune GC [5]

I've run CL in production for many different applications. I've never had to tune a GC.

</comment><comment><USER43> ITA software's account of using CL may also be of interest,

[http://www.paulgraham.com/carl.html](http://www.paulgraham.com/carl.html)

</comment><comment><USER44> try hy - [https://docs.hylang.org/en/stable/](https://docs.hylang.org/en/stable/)

Most of my production code is python, but I also wanted to create a dsl so I used hy. You get to enjoy both worlds

<comment><USER45> I tried to get hy but I just got confused.

</comment></comment><comment><AUTHOR> Thank you for your responses. I was interested in learning about these concerns for Common Lisp only, and not the other dialects including scheme, clojure, racket ...

</comment><comment><USER46> This may not squarely answer your question, but when I was investigating this for a production project, the following tools seemed to be both essential and well-supported.

SBCL, SLIME, SLY, ASDF, quicklisp, and ultralisp

Other tools and solutions are available, but familiarity with this seemed to be what was required for comfortable use.

</comment><comment><USER47> My very early stage startup, whiplash.gg (tune in today at 2pm PT to see us in action) uses Clojure on the backend.

Ladder Insurance is a full stack Clojure shop and Watchful has a bunch of Clojure in prod too.

</comment><comment><USER48> I made a few hobby projects in different Lisps, but in the end for my field (REST backends) I would chose Erlang and today I also started looking towards Kotlin. Lisp's macros while being powerful are still creating a lot of trouble in terms of understanding the system, working with other people and finding support online. Also I personally didn't meet many developers who have solid understanding of FP, not even talking about macros - they are simply too complicated and don't allow human scaling.

<comment><USER49> Why Kotlin and not Elixir + Pheonix for web backend?

<comment><USER48> I have some experience with Elixir, you can think of it as nicer Erlang. Kotlin is interesting because it gives you access to Java (Android & Desktop) world and is closer to functional languages while still being widely usable.

</comment></comment></comment><comment><USER50> The problem with malleability of programming languages, is there is no upper limitation of how malleable it can be.

I experienced this in both Clojure and Ruby as well. The fact that developers can spend countless of precious time, cycling through a loop of malleability, reforming an already functional product in production. It costs precious time and money, it is expensive. And more importantly, it is non-stop.

Other programming languages like Go are very conservative with feature changes, and imposes hard limitations by choice, the team/company behind it thinks the same way, that a cycle of O(n) is destructive.

And nowadays, you can't expect a developer to stay on a company for so long, so a sureball tooling to hit it hard, and precise, with less time and tinkering around is much needed than ever.

On the future of programming languages, we will see languages being used not because it is malleable, but because it is sure, precise and right for the job.

<comment><USER51> I tried Go and didn't like its opinionated nature. As a beginner, I disliked,

\- I have to use every variable I declare, otherwise it won't compile (b/c golang authors decided this produces better code)

\- Official docs confusingly suggest I structure imported files with the root as github.com/ (b/c golang assumes all code will be open sourced)

\- I can only import one file per folder

\- There is no built in map or reduce function. You're expected to use for loops everywhere because it is more explicit

Once I discovered the last point I noped out.

<comment><USER50> > \- I have to use every variable I declare, otherwise it won't compile (b/c > golang authors decided this produces better code)

> \- There is no built in map or reduce function. You're expected to use for > loops everywhere because it is more explicit

Go is an imperative language, where no implicit magic happens on the background, like auto creation of resources on runtime, every sequence needs to be manually defined by the programmer. "With imperative code, you're telling your program how to do something. And with declarative code, you're telling your program what you want to do. - Tyler Mcginnis, React Fundamentals", depends on the programmer, but I like to be in control.

<comment><USER51> Yeah I get that. I prefer declarative code. I _really_ enjoy constraint programming, for example, which is anything but imperative. I had no idea there were folks who preferred imperative languages until I discovered the Go community. I always figured people choose imperative languages for lack of familiarity with more declarative ones.

</comment></comment></comment></comment><comment><USER52> Your questions are well answered by Paul Graham in [http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html).

There are many Common Lisp and Scheme environments. Many have excellent JIT compilers. They all have their relative strengths and weaknesses. So it really depends on your specific use case as to which environment has the best support. For me the biggest factor is that Lisp is very productive for use by a small and competent team. In those situations they tend to create a DSL and evolve the system. PG's essay describes the reason Lisp fails many projects in the section "The Blub Paradox".

<comment><USER53> I'm a big PG fan but to be honest, him building viaweb in Lisp is 99% because: "Robert and I both knew Lisp well, and we couldn't see any reason not to trust our instincts and go with Lisp.", and not because of a competitive advantage in the language.

There are so many things that can go wrong in a startup, it's not the time to pick a stack or database you know nothing about.

</comment></comment><comment><USER54> I use CCL and a set of helper functions (that take continuations) so I can quickly and easily generate bits and pieces of HTML from my shell. I have previously written the same helpers in JS, Python, and Ruby, but there was a certain elegance about the LISP version and that's the only version I use and maintain anymore.

I doubt anybody knows how often I'm using LISP with this little tool because they only see the resulting HTML, but it's been a big help to me.

</comment><comment><USER55> Low traffic, but [https://rl.gl](https://rl.gl) is running production on SBCL (on kubernetes). Common Lisp is a joy.

</comment><comment><USER56> Clojure direct tackles most of these problems and it seems to me (subjectively) that it's one of the most widely-used Lisps for actual production systems.

</comment><comment><USER57> Have you considered lisp dialects? I've been working with Clojure/Clojurescript for a while and it addresses most of those concerns. It's been a real pleasure to work with.

\- There are lots of high quality libraries, but you also have access to the entire Java and/or Javascript ecosystem with very easy interop

\- Not too sure what you mean by "community coordination", but I've found the clojure community to be exceptionally friendly, welcoming, and responsive. The core team is active and I've even had some questions answered directly by them in slack!

\- There is some tooling built and maintained by the core team that makes managing dependencies painless

\- There's a library (transit) that's widely used and well suited for marshalling data in and out of a clojure app. There's a library that's part of the core which implements the CSP (communicating sequential processes) concurrency model, similar to Go. It works in both Clojure and Clojurescript and is a very sensible way to manage async operations in a system.

\- GC is managed by the JVM (for clojure), which is state of the art

</comment><comment><USER58> I'm using Hy[0] for some API-accessible "glue code" (basically doing high level stuff with scipy.sparse and friends as building blocks).

[0] hylang.org

</comment><comment><USER59> We use Clojure + ClojureScript for just about everything where I work. There are a few older applications that are in Javascript with NodeJS and we have one that is C# and .NET but the rest of the company pretty much runs on Clojure. As mentioned elsewhere, Clojure doesn't really have any of the issues that you mention.

</comment><comment><USER60> Usually using Lisp in production means making use of either LispWorks or Allegro Common Lisp, and not the FOSS offerings.

<comment><USER61> You can run applications on the Web now.

<comment><USER23> Another good solution is to make a command line app with SBCL or CCL and use Radiance [https://github.com/Shirakumo/radiance](https://github.com/Shirakumo/radiance) or something similar that opens a new browser window for your app.

</comment></comment></comment><comment><USER62> I am using CL in pre-production to avail myself of its ability to compile & load at runtime. I haven't used Lisp in production in a while (dating back to Zetalisp!), and the decades of perspective lead me to some surprising conclusions. I have encountered neither ecosystem issues (due to quicklisp) nor community issues (due to "addition by subtraction" in the Lisp online community). However, I have encountered plenty of issues due to dependency- hell issues in the non-CL software I'm using: Python 2 vs 3 vs Python package incompatibilities; Python 2 vs 3 Ansible/Vagrant container/VM/distro incompatibilities; node.js vs npm vs inter-node-package version incompatibilities; etc. CL has been gloriously stable, and given me substantially less heartburn and fewer headaches.

</comment><comment><USER63> Oracle used Lisp [1] in the UIs for their gen-2 cloud product. They eventually hit a wall hiring the kinds of people Oracle wanted to hire (few of whom wanted to learn an esoteric language), and made the tragic decision to move new development over to TypeScript (and port many of the key existing surfaces for ongoing maintainability). Mixed results on that. Many who were around for both the old and new code bases report that, while the old one took more effort to pick up, it was easier to trace data flow and is less prone to creating weird state bugs.

[1]: [https://www.linkedin.com/pulse/building-cloud-choosing- lisp-...](https://www.linkedin.com/pulse/building-cloud-choosing-lisp-because- nobody-told-me-i-mason-browne/)

</comment><comment><USER64> I'm not a lisp programmer, but I have used emacs in the past.

For people w/ lisp dev XP, can I ask this: Is the ".emacs/config bankruptcy" issue a general problem? Specifically, when you use so many powerful devices, macros etc; but with little predictable code structure, then further development that sits well with existing code becomes pretty difficult.

<comment><USER14> I'm not an experienced lisp programmer, but Emacs bankruptcy is imho avoidable. You must understand that people often configure their editors by the worst of Stackoverflow-driven coding... copy-pasting random snippets till things work, and accumulating cruft over time. Also, Emacs lisp is not particularly great (compared to other lisps) and Emacs configuration is typically done through a bunch of exposed global variables. YMMV.

A production codebase hopefully merits very different attitudes :-)

<comment><USER65> Also, frameworks seek to claw back some structure from the morasses.

It's kinda fine if every library you use is _slightly_ different if you can have a unified interface for how to use them (spacemacs layers system for me).

It is annoying figuring out which invocation of variables sets the tab-width for _this_ new language though...

Also, most libraries in the emacs ecosystem have become more standardised in their interfaces, so things aren't too different nowadays.

</comment></comment></comment><comment><USER66> Yazz Pilot ([https://github.com/zubairq/pilot](https://github.com/zubairq/pilot)) was originally written in Lisp (Clojure) but we switched to Javascript, simply because it was easier to get third party developers on board with Javascript compared to Lisp

</comment><comment><USER67> > have to restart the server every 20 days because of some memory leak

Hmm this seems like something super specific to their async setup, rather than 'common lisp leaks memory'

</comment><comment><USER68> I just would like to add to all the great comments, that clojure also has access to the python ecosystem via libpython clj.

</comment><comment><USER69> > * poor ecosystem of libraries - few gems, most other half-baked

Specific to common lisp: I don't find the ecosystem to be poor but I notice that many are turned off by the look and feel of library landing pages which do feel dated. In same cases I have felt the libraries lacked documentation, like Caveman2, but in the end I found there was little to document after reading some of the source code.

Specific to Clojure: I don't think this criticism applies to Clojure at all and the popular Clojure libraries usually come with great documentation as well.

IMO, JavaScript is also littered with mounds of crappy half baked libraries as well but people still use it for server side stuff even though they have a choice to use something else.

> * poor community coordination

Which lisp community?

> * Dependency management limitations with quicklisp

What limitations? Also, if you don't like quicklisp or common lisp in general, I think Clojure really nails dependency management and find it very easy to use.

> * poor support for json[6]

Specific to CL: I can understand this because there are a number of libraries and no obvious winner. JSON isn't the only data serialization format though. Guess it depends on what you need. [https://www.cliki.net/serialization](https://www.cliki.net/serialization)

> * poor support for async

Specific to Common Lisp: There is cl-libuv: [https://quickref.common- lisp.net/cl-libuv.html](https://quickref.common-lisp.net/cl-libuv.html) and wookie.

Specific to Clojure: core.async is great and if you don't like it you are also free to use node.js as your runtime with clojurescript.

> * have to restart the server every 20 days because of some memory leak [3]

If I had a dollar for every node.js production app that suffered this very same problem I could probably retire today. I thought it was interesting that the author of that article says the service was re-written in node.js given node.js is hardly immune to these sorts of problems. IMO, async is just a pain to work with and these types of issues are a manifestation of that.

> * hack to tune GC [5]

Users in JVM land also report having to resort to tuning the GC or selecting the optimal GC for their use case. I don't think this is a reason to shy away from lisp.

> If you are using lisp in production for non-trivial cases, do these issues > still exist?

I have not personally encountered these issues in Clojure or CL. That is not to say they do not exist. But they also exist in plenty of other popular platforms to varying degrees. See my responses above for examples.

> and, finally, if you had to re-do your project, would you chose lisp or > something else?

I would still choose lisp, either Clojure or Common Lisp. I generally favor Clojure to CL.

</comment><comment><USER70> I've used Lisp for a production system I delivered one year ago. I used CCL as an implementation and had a lot of success.

Here i'll cover your points:

> poor ecosystem of libraries - few gems, most other half-baked

I'd say the ecosystem is high-quality. There are relatively few libraries (around 2000+) compared to other ecosystem, but on the other hand most of them are either interesting, or unique (wouldn't exist in languages that lack certain features), or really well-written. Or many of those qualities at the same time.

In the absolute sense, there are enough libraries, IMO.

If you need something that isn't available, you have at least three options:

1\. Bind to a C library; for this, Common Lisp has many facilities/libs for this, some of them make this task rather easy.

2\. Same as (1) but Use ECL (Embeddable Common Lisp) for integrating a C program with a Lisp program as a whole, easily calling C from Lisp and Lisp from C, etc.

3\. Use the java ecosystem and use the Armed Bear Common Lisp (ABCL) implementation. This implementation makes calling java libs a piece of cake, basically you call a java method with just one line of code. Or instance a class with just one line of code, etc. Really easy.

> poor community coordination

That's a bit meaningless. There are really good quality books and resources, i think that's what counts.

> Dependency management limitations with quicklisp

Quite the opposite. Quicklisp is awesome, better than PIP or NPM. It "just works".

> And some specific red flags like:

> poor support for json[6]

The opposite, many libs for JSON. The one I use, I like a lot.

> poor support for async

What does this mean? You can use cl-async, but i wonder what would be the benefit when in CL you have actual threads and great libraries for concurrency like lparallel (which introduces parallel processing constructs) or chanL (which gives you an easy to use channel implementation).

Cl-async allows you to leverage the whole power of libuv (just like Node does), but why? I'd rather use threads.

> have to restart the server every 20 days because of some memory leak [3]

Never heard about such things.

Perhaps you are confusing the "condition - restarts system" (which is the Lisp exception handling system) with having to restart something?

> hack to tune GC [5]

The URL you cite says "We had to tune the generation sizes".

Any respecting developer who wants to release a high performance production quality service NEEDS to tune the GC. Tune the GC is not a "hack", is just configuration parameters. Ask any Java developer who has had to "tune" the JVM for best performance.

By the way, everybody raves about Golang but it has a GC system that is comparatively outdated to the ones in most Lisp implementations (or the JVM). For example CCL has a very good generational garbage collection.

</comment><comment><USER71> KDB+ is Lisp under the hood. Please count as highly successful Lisp used in production.</comment>


Google's Project Owl – a three-pronged attack on fake news and problematic content - <AUTHOR> http://searchengineland.com/googles-project-owl-attack-fake-news-273700 <comment><USER2> I'm surprised that this isn't seeing more discussion; it's not a pleasant area to think about, but it's definitely one that needs thought and consideration: the "Miserable Failure" issue, but on a grand scale and in some dangerous spaces.</comment>


Show HN: Jobr for Android (Private Beta) - <AUTHOR>

Hello! Jobr (http://jobrapp.com) is one of the most popular job search apps on iPhone.
We've been hard at work on our first Android app. We've built a completely native experience for Android. So we'd love for you to try it and give us your feedback.
Please signup to our Google Group to download the beta! https://groups.google.com/forum/#!forum/jobr-android-beta <comment><USER2> Links: [https://groups.google.com/forum/#!forum/jobr-android- beta](https://groups.google.com/forum/#!forum/jobr-android-beta)

[http://jobrapp.com](http://jobrapp.com)

</comment><comment><USER3> Been waiting for the Android love for some time... FINALLY!

</comment><comment> enahs-sf Where do I report issues?

<comment><USER4> You can report issues from within the app through "Settings -> Feedback", you can post to the Google Group, or you can send us an email directly: firstname.lastname@example.com. Thanks!</comment></comment>


Moscow to Play Weather God to Save Money on Snow Removal - <AUTHOR> http://www.themoscowtimes.com/business/article/luzhkov-takes-snow-fight-to-the-sky/387446.html

<comment><USER2> Beijing's been doing this for a while too, though they're typically aiming at drought or hailstorm prevention [http://en.wikipedia.org/wiki/Beijing_Weather_Modification_Of...](http://en.wikipedia.org/wiki/Beijing_Weather_Modification_Office)</comment>


Ecuador's strange journey from embracing Snowden to turning him away - <AUTHOR> http://www.washingtonpost.com/blogs/worldviews/wp/2013/07/02/ecuadors-strange-journey-from-embracing-snowden-to-turning-him-away/?tid=rssfeed

<comment><USER2> Looks like he leveraged Snowden's asylum to get some convicted bankers back who are hiding in the U.S.. I wonder how long before they arrive in Ecuador.

</comment><comment><USER3> Gotta say, it's better than Ecuador welcoming Snowden into their country and then throwing the handcuffs on him as soon as he lands and being escorted straight to a private jet waiting to take off to the US.

</comment><comment><USER4> In the end everyone's looking out for themselves.</comment>


Nicobar: Dynamic Scripting Library for Java - <AUTHOR> http://techblog.netflix.com/2015/02/nicobar-dynamic-scripting-library-for.html

<comment> guard-of-terra Seems like just enough amount of rope to hang yourself.

In addition to cumbersome setup you're goind go have wild amount of fun with dependency graph between scripts. Development will be fun as well.

I understand such system might have some specific uses but I expect an app made out of interdependent interchangeable scripts to be 10x times harder to develop than a monolithic one.

<comment><USER2> I used to work on a system that had Drools-based coupon and promotions. Drools was like this at its core.

Those were some fun stacktraces. They look like compiled JSP output, with about as much usefulness unless you're on the server digging around in the template's generated java code.

This system once gave products away for nearly nothing. Another it repeatedly stack overflowed trying to recurse down a rule. This was unfortunately easy to do with this system.

The example they show is a pretty trivial one, but maybe it's only used in trivial cases where the effects would be minimal.

I'll still follow the development of this project to see if there's some improvement over my (admittedly sour) experience.

also: is groovy normally written in the 'fluent' style?

</comment></comment><comment><USER3> wish this existed a long time ago!</comment>


The Blackbird – fully adjustable car rig that creates photoreal CG cars - <AUTHOR> http://www.themill.com/portfolio/3002/the-blackbird%C2%AE <comment><USER2> I believe this was covered in a discussion a few days ago.

[https://news.ycombinator.com/item?id=11964582](https://news.ycombinator.com/item?id=11964582)</comment>


Life in the deadpool - <AUTHOR> http://www.coloradostartups.com/2006/11/22/life-in-the-deadpool/

<comment><USER2> > I learned way too much from this experience to explain here.

Too bad ... that's what I want to read about!</comment>


Automated Support Tasks: 7 Things Bot Can Handle - <AUTHOR> https://thinkrelay.com/blog/automated-support-tasks/ <comment><USER2> The automated data collection didn't surprise me, but somehow I hadn't thought about using bots to actually automate the analyzing, predicting, and actions that come next.</comment>


GitHub goes off the Rails as Microsoft closes in - <AUTHOR> https://www.theregister.co.uk/2018/08/16/github_rails_microsoft/ <comment><USER2> This headline is terribly misleading. GitHub uses and continues to develop in Ruby on Rails extensively for its web UI. All that's happening is that GH is breaking off pieces of its overall infrastructure (or building new features/services) and using lower-level/higher-performance languages well suited to those types of services.

Shame on The Register for totally botching the intro to what was otherwise a very interesting piece about GH's technical evolution.

</comment><comment><USER3> A pity, it thought Ruby to Elixir might be more of a logical progression re: scalability.</comment>