Ask HN: Should I pick up Dart and Flutter for my next side-project? - <AUTHOR> I'm between using node.js & React.Native or Flutter. I don't like waisting time but if that's where things going then I'd like to learn. But Google already failed sometimes in making a technology very popular. <comment><USER2> If the side project is for passive income, then Dart and flutter is the way to go. Single code base and mutli platform. Soon industry will also catch up with this logic.</comment>


Show HN: Ask Roboflow, the AI that answers programming questions - <AUTHOR> https://ask.roboflow.ai <comment><USER2> "Does it actually work? Kind of."

Iff "actually works" means "lorem ipsum generator." It generates something that looks superficially like programming answers, but makes no sense whatsoever; it seems to be on par with a simple Markov chain.

Example from "top 1000":

> What is console.log and how do I use it?

> In my configuration model I set up my InFile active output file: > ./DevFine/mysite/ .py

In other words, AI cargo cult. "It sorta kinda works <small>(except for the one problem that it's supposed to solve. That part doesn't work, but all the bells and whistles do.)</small> Perhaps if we can make it look even more like SO, it will magically start working. Any minute now."

</comment><comment><AUTHOR> Hey everyone! Happy to announce the culmination of about a month of digging into ML and NLP.

Ask Roboflow is trained on millions of Stack Overflow question/answer pairs to mimic human responses.

It's learned lots of interesting things including how to insert HTML links and images into its replies, the syntax of several programming languages, and how to link to "relevant" documentation.

One thing it hasn't yet learned is the concept of "correctness" so most of the answers you'll see won't actually be helpful yet... I plan to continue to improve the model as time goes on. Hopefully one day it will actually be able to help new programmers get instant answers to their programming questions.

</comment><comment><USER3> I just looked at the first most recent [https://ask.roboflow.ai/question/30954728](https://ask.roboflow.ai/question/30954728) and the answer is total nonsense. Left unimpressed.

</comment><comment><USER4> I get a [http://localhost:5000/question/4743730](http://localhost:5000/question/4743730) when I click on a top question

<comment><AUTHOR> Aw shoot. Fixing! I "cached" the top questions before deploying and forgot to update the URLs.

Edit: fixed!

</comment></comment><comment><USER5> Looks cool, but after the 5th refresh, and whitelisting even more botnet domains, I had to give up testing it.

<comment><AUTHOR> Not sure I understand. The only external dependencies are cdnjs, Firebase, and google fonts.</comment></comment>


Project idea: Bucket List Social.  Hot or not? - <AUTHOR>

So pretty soon I might be looking for a new project to build, and I've always wanted to work with graph databases.
How about an app that allows you to compile a list of things you want to accomplish before you die.  You can share your items and browse those of others.  Each item can be commented on by anyone.  There could be a list of popular items, powered by the HN algorithm iteself (http://amix.dk/blog/post/19574).
I have a pretty good idea on how it would be designed, both in interface, and technologically.
Tech:
 RoR, Coffeescript
 Neo4j
 JRuby (required for neo4j)
 Heroku (see http://blog.heroku.com/archives/2011/08/25/java/)
 oauth2, FB Canvas, twitter connect
 Twitter Bootstrap
Also, jquery mobile is a piece of cake if we want a mobile site.. <comment><AUTHOR> Anyone who wants to help with this, feel free to drop me a line at firstname.lastname@example.com and I'll put everyone in touch there..

The idea is attractive to me a developer because I want a lightweight way to use a graph database, and the social integrations seem extremely self-evident! (Make a fb app, share when you add something to your list, collaborate with friends to get things done, win points, blah blah, etc etc). All dev help is welome!

As a business person, my getting anyone to use it might be a small miracle. All biz help is welcome!

Bottom line is it can be done in a very lightweight and fun kind of a way. I see no reason a beta couldn't be made and given to testers in a week!

</comment><comment><USER2> [http://www.makeuseof.com/tag/100-die-6-sites-create- bucket-l...](http://www.makeuseof.com/tag/100-die-6-sites-create-bucket-list/)

It seems like websites already that allow you to create and share bucket lists. Using the HN algorithm is good, but that's not something that people going to the website are really going to notice. As far as the user's concerned, they don't care one bit how your website is implemented, just that it works. That said, if you can create something that offers a novel take on the idea, feel free to surprise us :D

</comment><comment><USER3> This is what people use Pinterest for so this site might be a bit too specific to attain a large enough user base. Might want to make it Pinterest for travelers or something instead rather than bucket list... make it broad.. there's already plenty of social sites for traveling, so that means there's a need.

<comment><AUTHOR> Pintrest has to do with things, such as this cream lace pencil skirt: <http://pinterest.com/pin/154248355957226784/>

Where on the contrary, ZenBucket (As its now known - <https://github.com/ZenBucket/ZenBucket-web>) has to with goals: such as quitting smoking or learning how to clean a carburetor.

</comment></comment><comment><USER4> Some friends of mine (I actually did a very very little bit of work on the front end myself) built something similar called <http://dreamkumo.com>

Not sure where it's at now but sounds similar to what you're doing.

</comment><comment><USER5> Good idea I would recommend adding features that transforms it into a problem- solving tool beyond being just a social app. For example, Go visit the Taj Majal, Click here to reserve the ticket or something like that. I could really help you with this

<comment><USER6> As well as allowing users to find other people to travel with / split travel costs. This could be anything from group booking a hotel or tour guide. "Click here to find other people interested in visiting the Taj Majal" ?

<comment><AUTHOR> There could certainly be some interesting possibilities for fundraising with/for your group (those sharing a goal or goals) as well.

</comment></comment></comment><comment><USER7> This makes me think of Schemer ?

</comment><comment> saiko-chriskun sounds cool to me :). If you're lookin' for help I might even be willing hehe

<comment><AUTHOR> sweet! What kind of stuff do you like to do?</comment></comment>


New startup Pracly: Connect to timely expert advice on demand - <AUTHOR> http://www.pracly.com

<comment><USER2> Great idea!

Personally I don't think "Sound good?" is the right text for a button and making potential users click a button only to scroll down and need to click another button is probably going to mean losing some users in that extra step.

Generally I think your landing page needs some work. I've heard pg say in a couple places that you need to make sure every single word on your home page is there for a reason. Make sure every button takes users closer to where you want them to be (paying you I assume).

Maybe just take a look at the homepages of all the YC startups' home page - this should help: yclist.com/

Also it might be more impactful to give examples of how people used your app instead of testimonials.

One more idea: maybe play around with the pizza delivery idea of "if it's not there in 39 minutes, it's free". So what i mean is I post a question and the price I pay for the answer decreases, the longer I wait for the answer</comment>


Comparing React to Vue for dynamic tabular data - <AUTHOR> https://engineering.footballradar.com/from-a-react-point-of-vue-comparing-reactjs-to-vuejs-for-dynamic-tabular-data/ <comment><USER2> At Discord we've actually spent a bit of time optimizing around frequently updating tables of data.

On the extreme end of things, we have lists that contain several thousand items that update a few elements that are potentially updating up to ten times a second. The biggest being the member list on a server. One of our servers has ~6500 online right now, with people coming online/offline/away every second, changing their current game, typing, etc...

Few lessons we've learned: 1) Don't use ImmutableJS for small objects with a few keys containing scalar values, it's too slow. It's actually faster to just a) copy objects ({...oldValues, newKey: newValue}) or b) re-use objects and power shouldComponentUpdate in another fashion. In some cases, we use an "object version" that is incremented every time the object is actually updated. Then compare that in shouldComponentUpdate. 2) Only render what's visible. In our lists, each item has a fixed height, so we only render elements that are visible. This cuts down from having to render 6500 items in that list, to a good 20-30.

<comment><USER3> Hey, author of Immutable.js here,

You're definitely right to point out that Immutable.js is really not always what you want for small values that change all the time. Immutable.js collections are best used for just that: collections. If you have to copy an array or map with a ton of entries to make a change, it's going to be super slow - Persistent Immutable data structures can help with that.

But I agree with your conclusion that any JS objects that are being used as small tuples are definitely better off staying plain JS objects.

You also don't have to use all Immutable.js or nothing at all. Similar to how using an ES6 Map collection means you don't have to stop using JS objects. Use Immutable collections where they offer benefits, but spreading it everywhere is not a performance panacea, as you rightly discovered.

<comment><USER2> Love your work on Immutable.JS.

When I was typing out the original reply, I meant to say "Don't use Immutable.JS for small objects" but ended up putting a period in the middle... which could have led to some confusion. I've edited it to make it more clear.

We've also had some perf issues with using Immutable JS for even larger arrays. I think paying the cost of shallow copying the entire array when modifying it ended up winning in the long run as our render functions could loop over the array much faster.

</comment></comment></comment><comment><USER4> Using the production build of React changes the outcome significantly:

[https://github.com/footballradar/VueReactPerf/pull/3](https://github.com/footballradar/VueReactPerf/pull/3)

<comment><USER5> fwiw - i love the quality of the screenshots and comments and the conversation after that ensues after

<comment><USER6> Christopher Chedeau (vjeux) is a core react contributor. It's cool that his feedback was thoughtfully accounted for.

</comment></comment></comment><comment><USER7> A bit off-topic, but this is what my folder looks like after `npm install`:

      Dev du -h -d 1 VueReactPerf/
        1,2G    VueReactPerf/node_modules
        2,0M    VueReactPerf/dist
        52K    VueReactPerf/src
        1,7M    VueReactPerf/.git
        1,2G    VueReactPerf/

=> 1.2 GB of dependencies. What is happening to the JS ecosystem, where displaying a table in HTML needs 1.2 freaking Gigabytes ?

<comment><USER8> And this, children, is why we do a proper job. Because the JS landscape nowadays looks like a house of cards, with people who can't code treating modules like Lego to build things.

Web dev has exciting things going on in it, but it feels mostly like a bunch of children with no concept of consequences running around desperately re- inventing wheels, rather than caring about quality, efficiency, diligence and professionalism.

It's fucking disgraceful, and we should be ashamed of it.

</comment></comment><comment><AUTHOR> I'd left React in development mode during these tests. See this PR [https://github.com/footballradar/VueReactPerf/pull/3](https://github.com/footballradar/VueReactPerf/pull/3) for some results with the issues fixed.

We'll re-run the tests in the morning (uk) and post the updates.

<comment><USER9> You're unfortunately not the only one that doesn't use prod for doing benchmarks and potentially also not for actual production. If you have ideas on how we could better educate people about the difference, I'd love to know. [https://twitter.com/Vjeux/status/735178192651063298](https://twitter.com/Vjeux/status/735178192651063298)

<comment><USER10> I don't have any suggestions regarding education, but it would be helpful for me (and I'm sure others) if there was a non minified production build available via bower; My build process isn't using npm modules right now, so I've been stuck using the dev version.

</comment></comment></comment><comment><USER11> One of my coworkers wrote and maintains an amazing library called react- virtualized [0], which can be of help for certain similar cases in which you have to render huge amounts of data. You just avoid rendering anything outside of the viewport.

[0] [https://bvaughn.github.io/react- virtualized/](https://bvaughn.github.io/react-virtualized/)

<comment><USER12> Thanks for sharing that project. I've implemented similar things, and I have to say, this seems to be very thoughtfully implemented.

</comment></comment><comment><USER13> FWIW, the time spent in JS is only telling half the story. In that first example, React spends half as much time painting and rendering as Vue; the DOM diffing is more js-time intensive but results in less DOM thrashing. Interesting to watch how poorly it seems to scale; I'm wondering if web workers in future React versions will change that story.

<comment><USER14> In case you missed it, the author confirmed the tests were accidentally using the development version of React, which is significantly slower due to the additional warnings and sanity checks. The actual results seem to be much less surprising.

</comment></comment><comment><USER15> You should compare a plain JavaScript object (use shallow or deep compare if you must) version against Vue.

I'm sure Immutable is pretty well optimized, but you still have overhead from all those function calls and iterating through the array of keys manually.

<comment><USER16> Exactly this. Immutable is for collections, e.g. maps, sets, lists. The objects in the example are just objects, they are not maps. Using Immutable is just a pointless complication.</comment></comment>


How to Speed Up Code Review Process with Code Review Time - <AUTHOR> This is a chapter from an upcoming book Team Lead 101: Manage and Grow Engineering Teams in Small Startups. Check it out here https://gumroad.com/l/team-lead-101 (clickable link in comments)
<comment>=====
Good decisions are those that remove the need to make repetitive ones – James Clear, Atomic Habits
In one remote team that I led, there were repetitive problems that were obvious from looking at the agile board. Tasks spent the most time in the "In Review" column. They piled up in a heap in this column while waiting for initial review or or re-review. In our retrospectives, we discussed the reasons behind this problem week after week, but the problem hit the team on an almost constant basis.
My decision was to try holding a specific code review time every day at the same time. We started with 30 minutes just before the daily meeting and then extended it to 45 minutes, which was a good length for the team of 4 developers.
Here's what the code review time solved for us:
Developers knew that we needed to review code daily and that we couldn't skip it for the day and catch up later. Having a specific time for reviews allowed everyone to be prepared for the code review meeting and plan their day accordingly. We were all in the same meeting room and could discuss all the issues much faster than in async mode when you wait hours for a review, then respond, then wait hours again for an answer. As a result, we no longer faced the problem when tasks were implemented but not finished during the week. And the "In Review" column never piled up again.
Make a requirement for everyone to be at the code review meeting. If it's optional, then you lose all the benefits of the practice. </comment><comment><AUTHOR> Link for the book [https://gumroad.com/l/team- lead-101](https://gumroad.com/l/team-lead-101)</comment>


Ask HN: How to change the username on Hackernews - <AUTHOR> I remember around 2 years before when i had created my account on Hackernews and i just choose a random crazy name , i didn't realise that i would get an urge to change my username. So just wondering if there is any way of changing the username on Hackernews <comment><USER2> Um, you have 2 karma, 1 submission, and 1 comment... I'm sure creating a new account would be possible. You don't really have much to "start over" from.

<comment><USER3> OP account is 19 hours old, so I'm assuming he is posting from a throwaway.

Anyway this is the correct answer, just make a new account. Karma points don't matter and people won't know its you anyway if you are using a completely new name.

<comment><USER4> One could want comment history preserved, but a link in each profile to the other doesn't seem a terrible solution.

</comment></comment></comment><comment><USER5> There is no public option for this, it might be possible if you poked an admin, but I'd not hold my breath.</comment>


Hitler's Drug Addiction - <AUTHOR> https://www.guernicamag.com/daily/andrea-maurer-high-hitler/ <comment><USER3> "Morell has documented 800 injections given to Hitler over 1,340 days, the first in 1943 ..."

Not possible; Hitler committed suicide about 850 days after Jan 1 1943. There are some issues in this article.

<comment><USER4> If it were 1340 injections in 800 days, it would better fit and possibly support the story, especially the begin:

"At the end, when he was already hiding in his wet and dark Fuhrerbunker and his beloved Eukodal was no longer available, the dictator was in a frail state."

But the statement "the first in 1943, when the Americans landed in Sicilia" gives us the begin date: 10th of July 1943, only 660 days before the famous suicide.

</comment></comment><comment><USER5> Oxycodone aka Eukodal is not a "preform" of heroin, period. Hydrocodone, aka Vicodin, has nothing to do with heroin either. This is seriously bad drug information. they're just opiates.

If you don't know, now you know. Nothing I dislike more than bad drug information being passed off as researched fact.

<comment><USER4> The author probably based it on the fact that oxycodone is a (semi-?) synthetic opiate produced from one opioid found in poppy, just like heroin is. They are of course not the same.

But heroin was synthesized in 19th century in England and oxycodone in 20th century in Germany, therefore it can't be considered "pre-" heroin, at least not globally. But maybe heroin wasn't common in Germany and therefore oxycodone was pre- in Germany?

<comment><USER6> > But maybe heroin wasn't common in Germany and therefore oxycodone was pre- > in Germany?

Heroin was first marketed by Bayer, a German pharmaceutical company in 1898. That's where the name 'heroin' comes from so oxycodone was definitely not pre- in Germany.

Now, in nazi Germany, opium and products derived from it might have been harder to come by because of import sanctions (that's why methadone, a fully synthetic opioid, was developed in Germany in 1937). But that would apply to oxycodone just as much as heroin.

So no, the author is just full of shit and trying to impress his uninformed readers.

<comment><USER4> Wow, thanks for that, I've never read the Wikipedia article on Heroin and I didn't know:

"The head of Bayer's research department reputedly coined the drug's new name, "heroin," based on the German heroisch, which means "heroic, strong.""

</comment></comment></comment></comment><comment><USER7> Is this a legitimate article? There are few factual errors mentioned here in other comments[1][2] that have my internet bullshit detector primed, and then I see this quote from Ohler highlighted in the article:

 _"I have a good friend, a Berlin underground DJ, who told me once that the Nazis took loads of drugs. I couldn't believe it."_

That seems like a very spurious source of knowledge about Nazi drug use.

[1] [https://news.ycombinator.com/item?id=10355245](https://news.ycombinator.com/item?id=10355245)

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

<comment><USER8> The fact that Hitler was a serious addict is true. He was also bipolar, and it is quite likely that the combination has contributed a lot to the beginning of the end of Operation Barbarossa in 1943 (through his faulty decision about not attacking Moscow in 1941, before winter, and before Stalin realized what is really happening). The thing to remember is that amphetamines were way more acceptable in the early 1940s (because the bad side effects were not yet that obvious), for example Wehrmacht soldiers had "superpower chocolate bars" beefed up with amphetamine. They were allowed to consume it in a dire situation. There is a lot of unnecessary buzzing happening in the article though.

<comment><USER9> I think you're on the right track... From what I've heard as well was that in the later stages of the war, the army largely marched on a stomach full of meth (so to speak). Facts like those could bolster the rumor mill in propping up semi-gossip style information.

I did also have a history professor say that Hitler actually went blind for a couple of days when he heard that the Americans landed on European shores.

</comment></comment></comment><comment><USER10> The third reich seems to have developed a relationship with Ephedra and Poppy (plus tobacco of course). And we saw the consequences of that.

I've always been fascinated by the impact of various drug-containing plants on humanity and it's history. Plants, because most drugs are extracted or synthesised from them.

Shamans say that it is the 'essence' or 'spirit' of the plant that is psychoactive - you're 'inviting' another 'being' into your consciousness.

Those who smoked pot have probably noticed the alternative or alien 'voice' which appears in your head and makes you think and say funny things or think paranoid thoughts. This happens with all drugs - the drug (or, in shamanic terms - the spirit of the plant) becomes one's invisible councillor - <USER2> interlocutor in the user's internal dialogue.

Take tobacco - the act of smoking a cigarette is an act of 'conversing' with the plant, an act of thinking and taking decisions. Notice the impact that tobacco has had on the development of the human race - it's impossible to claim that it was responsible for all our progress, but somehow it was present in the pipes of Einstein and Oppenheimer and in the cigars smoked after a successful space mission.

It was also present in the trenches of wars.

Today our world is more drugged than it has ever been. Besides all the classes of illegal drugs, we also have people eating tens of thousands of various synthetic chemicals - prescription drugs - and of course making all sorts of combinations between them.

What will the consequence of this chemical experimentation end up being ?

Time will tell. Clearly we're doing some radical changes to how our minds and bodies work and this has a direct impact on how our society looks and behaves and what decisions are being made.

<comment><USER11> >Those who smoked pot have probably noticed the alternative or alien 'voice' which appears in your head and makes you think and say funny things or think paranoid thoughts.

I have never experienced this. Marijuana can exacerbate existing schizophrenia or expose it. If you hear voices after consuming it, I would talk to a doctor. It can be a quite strong drug, but it does not typically cause clear, audial hallucinations. (I would more describe it as distorting and/or decomposing the audio perception, kind of like the visuals you get from lsd. Pretty, but certainly not meaningful by itself.)

But, I've watched someone go through a psychotic breakdown when smoking weed the first time. They were not aware of their family history of schizophrenia until after that happened and they asked around. Be careful. :)

<comment><USER10> It's not necessarily 'that' kind of voice. We all have a little voice in our heads. If you haven't noticed it, it's the voice that said 'what voice?' right now. It's the voice we're in a perpetual dialog with all the time.

Somehow 'that' voice is not you - it's something you're talking to, it examines and comments everything you do, it gives you advice, but you are not it.

When you use a drug, 'you' stay the same, it's 'that' voice which is affected by it.

<comment><USER11> God, so complicated. Just say weed makes you paranoid. No need to anthropomorphize our thoughts.

</comment></comment></comment></comment><comment><USER12> If the sources have basis in truth, even if not to the extremity put forward, it's worth keeping in mind in the context of the person's worldly outlook. That noted, when talking about the effects of drug addiction on the mind, I find it relevant to point out Ayn Rand was an amphetamine addict for 30 years[1]. As a writer myself with an alphabet of substances consumed over the years, I can attest to different drugs having different influences on what gets put to paper...the most common in the field being alcohol. There's a long tradition of people saying things they wouldn't otherwise when their inhibitions are lowered, and that seems to hold true with the written word as well in many cases.

[1] [http://theweek.com/articles/493764/ayn-rand-speed- addict](http://theweek.com/articles/493764/ayn-rand-speed-addict)

<comment><USER13> As well as a number of the Beat authors. When I found that out, "On The Road" suddenly made more sense.

<comment><USER14> Wasn't at least one guy's amphetamine use described in _On the Road_? I think it was, but it has been a while since I read the book.

<comment><USER13> It mentions benzedrine use, but it didn't come off as omnipresent (to my naive self).

</comment></comment></comment></comment><comment><USER15> Fascinating book "A First Rate Madness" goes into detail on Hitler, JFK and other leaders drug use/abuse and mental illness.

<comment><USER16> JFK's drug history is fascinating. The amount of drugs he was on during the Bay of Pigs alone is alarming.

The world was so close to nuclear annihilation, and JFK was on a half dozen drugs, including steroids, antipsychotics, and amphetamines, from the doctor the secret service called "Dr. Feelgood."

It's fascinating what presidents could get away with pre-Lewinsky.

[http://www.theatlantic.com/magazine/archive/2013/08/the- medi...](http://www.theatlantic.com/magazine/archive/2013/08/the-medical- ordeals-of-jfk/309469/)

<comment> at-fates-hands >> It's fascinating what presidents could get away with pre-Lewinsky.

I've seen several documentaries that comment if people thought JFK was bad, LBJ was much, much worse when it came to women. There's a famous rumor about him getting caught in the oval office having sex with his secretary and afterwards, installing a buzzer so the secret service could warn him if he was wife was on her way to his office.

I can only imagine how the tabloid journalists would have a heyday with this nowadays.

<comment><USER17> When LBJ heard people talking about JFK's affairs, he "would bang the table and declare that he had more women by accident than Kennedy ever had on purpose."[1] It got worse:

 _At his Senate office, his female workers were fondled, ogled and overworked. Though his own figure was flabby, he was quick to berate any of his "girls" who put on weight. He wanted to make sure the view was good when they walked away from his desk. "I don't want to look at an Aunt Minnie. I want to look at a good, trim back end." He boasted of his sexual prowess and had long affairs with at least two women, as well as casual flings with members of his staff. Robert Caro, who is a dogged researcher, has uncovered the story of LBJ's previously secret relationship with Helen Gahagan Douglas, one of the few congresswomen in Washington during the 1940s. A former actress, she was an attractive blonde whose political career came to an abrupt halt after she failed to join her lover as a member of the Senate. In a dirty campaign for an open seat in California, she was defeated by a Republican newcomer who spread rumours that she was a Communist sympathiser. His name was Richard Nixon._[2]

[1] [http://www.theatlantic.com/magazine/archive/1998/04/three- ne...](http://www.theatlantic.com/magazine/archive/1998/04/three-new- revelations-about-lbj/377094/)

[2] [http://www.telegraph.co.uk/culture/4728473/A-lewd-crude- Mast...](http://www.telegraph.co.uk/culture/4728473/A-lewd-crude-Master.html)

</comment></comment></comment></comment><comment><USER18> This brings into question how bad the drugs actually are. Hermann Göring, lauded fighter ace, rose high up in the Nazi command. He was addicted to morphine. He didn't perform well enough in the war, but apart from the whole being-a-Nazi thing, one would say he had a rather successful career. So it really kills the whole "injected opiates will ruin your life" line. Same for Paul Erdős and amphetamines. Though amphetamines might have more long-term damaging issues (psychosis or heart issues) whereas opiates are _relatively_ benign.

This should just re-enforce the truth that the real problem with many drugs is simply legality (which causes high prices which leads non-wealth users into a spiral). With an open market, anyone with a minimum wage job could afford to be on opiates.

And in a military? Seems like a given. If you have soldiers that are feeling bad or otherwise having a crisis of confidence, opiates are a fairly good way to assuage that. To make them feel everything will turn out OK. Along with speed to give them lots of energy, and an environment conducive to actually doing stuff, it seems like a good military strategy (ignoring long-term effects on soldiers).

The only real question is if they made large strategic mistakes due to the opiates and thinking things will be alright no matter what. Though this article indicates a late date for Hitler's use, and it was much earlier he decided to attack the Soviet Union, so...

</comment><comment><USER19> The article makes it seem like there's a lot of news, when in fact most of what we can learn from the article about drugs in the Third Reich has already been published in the 2002 title "Nazis On Speed. Drogen im Dritten Reich." \-- two volumes with a wealth of information, of which she makes zero mentions in the article.

I distantly remember attending a book reading and discussion about above book in 2003 with Werner Pieper, Friedrich Kittler and others providing a good overview, a lot of serious points and some fun facts.

For instance, at some point, in Paris under German occupation, Pervitin pills were a legitimate currency in Paris brothels.

It can also be shown that there was an unusually high amount of animal studies performed all over the country, testing the effects of Pervitin on all kinds of species and sub-species, that don't seem to make much sense academically, but did provide steady Pervitin supplies for the research team.

</comment><comment><USER20> What is the lesson to be learned? Is drug use correlated with high- performance?

"People felt like they always wanted to: splendid, completely calm, clearheaded; it was a golden feeling." That sounds good! I'd like that...

All I've seen in drug users is wreckage and death. Maybe I haven't seen the whole picture. Is there an upside to drug use? If there was a safe performance pill maybe I would try it.

<comment><USER21> > All I've seen in drug users is wreckage and death.

Drug use is illegal and is taboo. Many people who take drugs are not going to talk to you about it.

You won't have seen a lot of drug use. You'll only have seen the worse end of drug use.

You have seen plenty of people who can have a few alcoholic drinks a week? That's drug use that doesn't end in wreckage and death, even though alcohol is very harmful and very addictive. (And physically addictive, not just psychologically addictive.)

<comment><USER22> > Drug use is illegal and is taboo. Many people who take drugs are not going > to talk to you about it.

Indeed. As has been well known in the addiction literature for a long time now, the overwhelming majority of addicts just sort of... get over it. The addicts that show up more prominently are a very selected subgroup. To give an example that will doubtless be familiar to many HN commenters personally, modafinil is used more widespreadly than it is acknowledged; in the survey I'm running now, most respondents just use it practically with no drama or mess.

</comment></comment></comment><comment><USER23> Dude. The guy lost. You don't have to propagandize against him now. Let it rest.

<comment><USER24> I thought it had a huge slant as well. I get it, the Nazi's did cruel things, but I'm a little leery of articles like this that are so demonizing. Can't we just talk about them as a facet of history?

<comment><USER25> It is a facet of history. It's a new fact about one of the most reviled and studied individuals in human history and it places his words and deeds in a new light. It is new information about not only Hitler but the entire Third Reich including everyone from the top down to the troops and as such means that historians might need to reframe everything that's been written about the time period up to this point.

Also yes, articles about Nazis _tend_ to have a demonizing slant, for as yet unknown reasons.

<comment><USER21> The problem with demonizing Nazis is that it makes them seem uniquely evil.

But they're not unique. There have been many genocides since the holocaust.

And while what they did was certainly evil many of the individuals involved were just regular people.

<comment><USER26> > The problem with demonizing Nazis is that it makes them seem uniquely evil.

"In the air strike, witnesses said patients were burned alive in the crowded hospital of medecins sans frontieres. Among the dead were three children being treated".

War crime, last week. Almost 200 patients and employees in the hospital.

To talk about how crazy was Hitler this week seems really convenient. Very pleasant and distracting exercise of history.

source: [http://www.reuters.com/article/2015/10/05/us-afghanistan- att...](http://www.reuters.com/article/2015/10/05/us-afghanistan-attack- idUSKCN0RW0HC20151005)

</comment></comment></comment></comment></comment><comment><USER27> This was posted about a week ago: [https://news.ycombinator.com/item?id=10306399](https://news.ycombinator.com/item?id=10306399)

<comment><USER28> From [https://news.ycombinator.com/newsfaq.html](https://news.ycombinator.com/newsfaq.html)

        If a story has had significant attention in the last year
        or so, we kill reposts as duplicates. If not, a small
        number of reposts is ok.</comment></comment>


Getting Started with Tokio - <AUTHOR> https://lukesteensen.com/2016/12/getting-started-with-tokio/ <comment><USER2> I've been following futures since the announcement blog post came out (and had been using rust for several months before that) and I've never found a group of crates that intermix so well together. Simple stuff like tokio-tls implementing the Io trait from tokio-core so it can easily be used in bind_transport to secure the connection makes working with tokio and futures so nice. Thanks so much to the people working on this!

<comment><USER3> When I can add some of these libraries to my projects, it's like a late Christmas gift for sure!

Thank you for the whole team.

</comment></comment><comment><USER4> Thanks for writing this. I often find it difficult to wrap my head around some of these crates if I'm unfamiliar with the problem space. Often times if you haven't tried building a server before you won't know why you would use a crate like this. Having a high level overview of what you might use it for and a simple walked through example is really helpful.

</comment><comment><USER5> The whole tokio stack is having an initial 0.1 release soon. It's incredibly highly anticipated.

<comment><USER3> I'm waiting to refactor four of my services to use tokio + hyper + amqp as soon as possible. It'll be fun...

<comment><USER6> Are you expecting to see any benefits from the async stuff in particular?

<comment><USER3> I'm mostly doing IO in these services and now I scale them up with threads and processes. I'm not using CPU so much so I could live with a small amount of threads doing async IO, because I don't need to process the messages in sync anyways. I have plenty of RAM to spare and could live with bigger memory usage.

</comment></comment></comment></comment><comment><USER7> >You can ignore all of the Box stuff; the reasoning behind that isn't terribly important right now.

What is the reason to box the futures? futures::finished and futures::failed both return FutureResult.

<comment><USER5> In general, Future is a trait, which means if you want to return a Future, you have to either create a trait object, or use the nightly-only "-> impl Trait". Boxing is the most straightforward way of creating a trait object.

(I haven't dug into the specifics of this specific example; that's what I assumed when I read that line. Maybe the author also knew this rule of thumb and did it unnecessarily...)

<comment><USER8> > use the nightly-only "-> impl Trait"

Can someone point me to more info on this? Possibly akin to existential types in Haskell?

<comment><USER9> It's not really existential types in the general sense. A function returning `impl SomeTrait` can still only return values of a single type, it's just that the compiler infers that type from the function body and then restricts the caller to accessing that value via the methods in `SomeTrait`.

<comment><USER8> Yeah that's what I was thinking; e.g. in Haskell you can use existential types to refer to "some type which implements this type class", and then an object of that type will have the functions in that type class available to it and no others (more or less). Cool that rust has this as well, I'm excited to learn about it.

<comment><USER9> Rust has something else more general that's much closer to existentials- you can use trait objects to erase a value's type and restrict methods on it to those in the trait.

The difference between trait objects and `impl Trait` is that trait objects can hold any value that implements a trait, since they're implemented via dynamic dispatch.

</comment></comment></comment></comment></comment></comment><comment><USER10> Very happy to see this, Tokio is still so primordial that it's sadly underdocumented. Looking forward to seeing that change in the coming year. :)</comment>


Ask HN: SQL; to prepare or not to prepare, is this blog correct? - <AUTHOR> I just ran into this blog post https://joshduff.com/2011-05-10-why-you-should-not-be-using-mysqli-prepare.md
This goes against everything I've been taught. I've always thought you should always use prepared statements for security. While it's possible to make sure you escape well, your best to rely on prepared statements doing that for you.
But is this guy correct? Is the performance hit a big enough problem? <comment><USER2> I wouldn't trust anything written in 2011, I'd research newer analysis before coming to an opinion.

There are many details to cover such as emulated prepares, or not emulated prepares -- for some examples of more recent opinions on the matter:

[https://stackoverflow.com/q/10113562/1491507](https://stackoverflow.com/q/10113562/1491507)

</comment><comment><USER3> It's garbage, ignore the post.</comment>


Slideshow: What vendors consider sexy design - <AUTHOR> http://www.itworld.com/hardware/76767/slideshow-what-vendors-consider-sexy-design <comment><USER2> Does anyone else find these terminally unattractive? They're super-ellipsoids with the occasional meaningless chunk cut out.

What happened to my sixties future, where the supercomputers were shiny slick hospital white or the nineties when desktops were okudagrams, or at least the 80's when computers _surrounded_ you with information and controls? Or how about the streamlined future of the thirties, when things at least looked fast.

Sexy design of racks ought to make me trust that the machine will run until the year 5421, possibly in zero-g while tended by a woman in Velcro booties and a spherical hat.

Sexy design of user machines ought to make me feel like a genius because of the obvious power at my disposal, to be used with bravado because it's clearly too smart to be broken. I won't want to let it out of my sight because I'm afraid it will find a new user. Withdrawal symptoms probable.

<comment><USER3> As I said a couple hours ago, I like the z9. It looks powerful. The HP is futuristic. The desktops are either dated or Mac-ish. Macs are pretty, but don't look powerful or sexy. As for the rackmounts, they are all boring. Very boring.

The problem these days is conformity. Desktops must run Windows, so, they have to be x86s - and those are boring chips - and have a certain number of keys and a certain set of ports. They can't differentiate much. The farthest I saw was a couple Macs with notebook-style keyboards. No F13~24, no Sun-like added keypad to the left. Conformity castrated industrial designers.

And servers must be rack-mountable, so that limits what a designer can do with it. Not even Frog Design can save us now. Even Sun, who had good taste by the early 90's was selling an atrociously ugly 22" LCD with their boxy überPCs.

Meh... These are utterly boring times.

</comment></comment><comment><USER4> Original article with bigger pictures:

[http://www.computerworld.com/s/article/9014161/Slideshow_Wha...](http://www.computerworld.com/s/article/9014161/Slideshow_What_vendors_consider_sexy_design)

</comment><comment><USER3> The IBM z9 is very interesting and the HP BladeSystem enclosure could be enclosed in an air-conditioned tube in the front lobby of any company.

But sexy servers are a hard sell. We will see a lot of rack-mountable dull- looking boxes. Any attempt to make them pretty is little more than lipstick on a pig.

There could be some space for good looking computers on the desktop. Where is Sun and NeXT when you need them? ;-)</comment>


Brian Kernighan on Associative Arrays - <AUTHOR> https://www.youtube.com/watch?v=qTZJLJ3Gm6Q <comment><USER2> The first language I encountered that used associative arrays was Snobol. Today I still use Snobol4 and Spitbol. Despite Perl, Python, etc. Other than sed, I have never found another scripting language for text processing that was more effective than Snobol.

Bruce Barnett, co-author of UNIX Power Tools, on his website grymoire.com (highly recommended) states that the first language he encountered with associative arrays was AWK. (The K in AWK is Brian Kernighan, the man in this video.) At the conclusion of his AWK tutorial on grymoire.com Barnett recommends that readers should consider using Perl instead of AWK.

Snobol preceded AWK by about 10 years and Perl by about 20 years. Am I incorrect to assume that Snobol was the first language to use associative arrays?

Cheers.</comment>


The Currency That's Up 200,000%  - <AUTHOR> http://www.smartmoney.com/invest/stocks/the-currency-thats-up-200000-1307029053200/?link=sm_newsticker

<comment><USER2> it's bitcoin, not sure why they didn't put that in the title

</comment><comment><USER3> ZorbaTHut's response on reddit is spot on. It's going to burst sooner or later. <http://bit.ly/lziLMv></comment>


The 2020 Guide for White Men in Tech - <AUTHOR> https://modus.medium.com/the-2020-guide-for-white-men-in-tech-23c9c5b57e82 <comment><USER2> Another lame writeup full of false assumptions (that are being provided as an absolute and immutable truth) that has nothing to do with tech.

I've seen better examples of graphomania, karma and attentionwhoring tbh.</comment>


Show HN: Listener Approved - Reddit for music all in node.js - <AUTHOR> http://ListenerApproved.com

<comment><USER2> Few issues

* no way to bookmark or forward a link to song or filter to a friend. If this is to help sharing, then it fails that.

* clicking a song moves the rest down, making it less consistent

* no way to put filter in url bar. Reddit is great with their concatenation of two subreddits in one address: reddit.com/r/programming+technology . Please do it so I can see top songs from /m/Goa+Psychedelic

* no way for curators. A lot of art industry follows a system of 'stamps of approval' through publishers / producers or labels. I am a fan of music from Ninja Tune label who represent artists like Amon Tobin and Skalpel. I don't see a way to discover other music from same label. I understand this could be done through playlists maybe?

* registration requires a lot of information that I am not fan of giving out. Redit creates account with just username/password. I hate giving out personal information. Location is created with 'undefined, undefined'. Location is required. Location doesn't even accept my default places like Kualalumpur. It did find Warsaw.

* registration doesn't go forward. I click 'Lets do it', nothing happens

as I can't register couple other points of interest:

* A lot of people like to add own tags to music, like decades (sounds like 80s), or moods (cheery), or languages (Polish).

* how are comments differentiated from general song comments vs 'at 1:45 the drop is massive' (soundcloud way)

* linking with other data sources: please think about reading last.fm / musicbrainz / discogs to get list of known genres/styles/moods.

* as you are starting, the reddit way is to add stuff yourself as tons of users. Try to link content from elektoplazm , and other places where you can find out the public / create commons status

cheers

<comment><USER3> Reddit was a very bad analogy for us to use. We're so much more, especially for musicians....

All the content is submitted by the artists themselves under a creative commons license. We don't add any content ourselves.

You able to share any track you like, we just don't display it's pretty link in the url, yet.

As our future plans unfold you'll see why we need some of your personal information. :)

Thanks for your suggestions!

</comment></comment><comment><USER4> I like that this is a streaming music player for the independently produced. Spotify and its ilk is a lot of fun, but it's still a glorified jukebox for music you've already heard a million times anyway. Streamers like this are what's going to help rid this world of the RIAA.

</comment><comment><USER5> NEVER, EVER, start ,music without me pushing some button. even if it's a music site. NEVER

<comment><AUTHOR> Honest opinion, how do you feel about <http://www.pandora.com/> auto playing?

<comment><USER5> i cannot access it because i am in the uk, if i am not wrong, i hheard a couple of days ago from another thread that it's a radio right? well i would probably feel the same. The fact is that the user usually does not expect it, therefore it might create awkward moments in the office or else, i think it's not a good thing for the website. You risk to loose an user even before he sees you homepage.

</comment></comment></comment><comment><USER6> If you want to be like Reddit please don't require anything but a username and password for account creation

</comment><comment><USER7> Nothing at all like reddit. Way too overdesigned and glitzy.</comment>


Designing a Mobile Experience – Text VS Icons - <AUTHOR> https://www.magnet.com/text-vs-icons/

<comment><AUTHOR> One of our resident designers/UX gurus at Magnet just penned a very interesting blog post, first in a series on design considerations for mobile apps.</comment>


PHAP: Mobile Apps in PHP - <AUTHOR> http://phap.landingpage.io/ <comment><USER2> "Simple & Safe – Synchronous programming keeps apps simpler and safer. In Objective-C, Swift and Java, asynchronous programming is very error-prone and requires callbacks. Synchronous nature of PHP makes bug-free developing a breeze." Seriously??

</comment><comment><USER3> > PHP is the best language for mobile app development

I am ok with you using any language you want. But best language?

What you entirely miss is the explain me how the system works. As far as i can tell you embed a webserver, php engine and present this in a webview?

Edit:// I saw the native. PLEASE explain. HOW?

</comment><comment><AUTHOR> I'm not sure if this is a joke...

<comment><USER4> PHP gets a bad rap because of the way many of the people who use it program. The language would be very good, in my opinion, with just a few standardization tweaks to the standard library.

It seems this project has retconned the standard library. I'd say this is a perfect application for this sort of language.

Weak typed, simple to read, simple to write prototyping.

Anyone can pick up PHP, that's its beauty.

<comment><USER5> But wouldn't it be better to have a language/environment where prototyping is simple, but writing complex apps is also simple?

<comment><USER4> Writing complex apps in PHP is just fine. You just need to respect the better parts of the language, just like everything else.

<comment><USER5> I fix PHP apps for a living, and sometimes I write them from scratch if a client is set on using PHP. I strictly follow PSR standards and have tons of mess detector and sniffing rules that keep me mistyping or being less disciplined. I use all the new type hinting features in PHP 7, and before that I was heavily using PhpStorm's excellent support for inferring types from doc blocks.

It's still way, way more painful to write large, complex apps in PHP than in a better-designed language like TypeScript. I actually just rewrote an entire API in TypeScript, and it was like breathing clean air.

I actually realized that having better typing totally eliminates 90% of the tests I was writing for my PHP code. With static typing, you just make sure your inputs conform to the right type, and then you always seem to end up with bug-free code. That's simply not possible with PHP without bending interfaces to suit your needs. You end up with an insane number of unnecessary classes/interfaces instead of simple types that you get in other languages.

It's definitely _possible_ to write complex apps in PHP, especially if you have excellent discipline, but there's a really good reason Facebook created Hack. PHP = Blub</comment></comment></comment></comment></comment>


Ask HN: Advice needed; drop out of university or not? - <AUTHOR> So essence of the situation is this:
- I have about 1.7 years of studies remaining for my master's degree.
- For diagnosed mental health reasons, I have taken both more and less voluntary breaks in my studying, sometimes to work, sometimes to rest.
- I have always been described by my environment as unusually intelligent, my grades are generally very good, and I'm normally good at solving problems and finishing assignments quickly.
- For family planning reasons, I want to be done with school and start my career for real at most a year from now, so that requires me to study at a higher pace than normal.
That's the background. Studying at a higher pace has worked well before, but as of two weeks ago, it doesn't. I haven't been able to identify what changed -- all I know is that however hard I try, I have failed every single assignment since then.
It is infuriating to me and it affects my close relationships badly.
I can't go on like this, but I'm afraid I will regret dropping out.I also don't think it makes sense to drop out of individual classes because if I'm not finished a year from now, that degree isn't happening anyway.
I know I'm already very employable after many successful study breaks spent working. Either way, I'll have a Bachelor's.
Opinions? <comment><USER2> I think the most important thing to bare in mind is the "Sunk Cost Fallacy" ([https://en.wikipedia.org/wiki/Sunk_cost#Loss_aversion_and_th...](https://en.wikipedia.org/wiki/Sunk_cost#Loss_aversion_and_the_sunk_cost_fallacy))

Don't make your decision based on what you've already done/paid. Make your decision based only on looking forward. Try considering: \- What's my goal? (Make a family, take over the world, have a masters) \- What actions get me toward my goal most efficiently? (Start making money, steal the moon, keep head down)

At the end of the day, it's a highly personal and contextual decision.

If you do decide to drop out, it'd be worth talking to staff about ways to keep credit for things you have already done - perhaps in a few years you could finish your course with Open University?</comment>


Sweden distributes 'be prepared for war' leaflet to all 4.8m homes - <AUTHOR> https://www.theguardian.com/world/2018/may/21/sweden-distributes-be-prepared-for-war-cyber-terror-attack-leaflet-to-every-home <comment><USER2> This reminds me of a recent Netflix show called "Occupied", whose premise runs something like this,

> In the near future, Russia initiates a "silk glove" invasion of Norway to > restart oil production, but soon uncertainty, chaos and danger erupt.

More here [1]. That show gave a really interesting look into how a Russian invasion of a Scandinavian country may look like.

[1] [http://www.slate.com/blogs/future_tense/2016/02/02/occupied_...](http://www.slate.com/blogs/future_tense/2016/02/02/occupied_a_political_thriller_on_climate_change_now_on_netflix_reviewed.html)

<comment><USER3> The Russians had a go at Finland in 1939.

* [https://en.wikipedia.org/wiki/Winter_War](https://en.wikipedia.org/wiki/Winter_War)

<comment><USER4> This example is often used to convince people that the Russians aren't a scary adversary but this isnt a good example.

In 1940 the Soviet army was in a pretty bad shape, the Russian committed a fairly small number of personnel and equipment during the Winter and Continuation wars in comparison the initial defensive force in operation Barbarossa was 3 million soldiers, the battle of Leningrad seen about 6 million Russian troops in total and out of those Russia lost about 2 million.

While winning is winning Finland faught against an inexperienced, poorly trained, poorly equipped Russian army that at the time was fighting for essentially nothing.

Also that link isn't the whole story Russia was fighting a trench and guerilla war in Finland until 1944 the Finns were very well equipped, well armed, and heavily supported by the Germans fighting while dug in on their home turf in a region where logistics were a nightmare and more importantly they faught against a very preoccupied enemy for those 3 years as Russia was invaded in 1941.

I also find it pretty amusing that people always mention the Winter war but not what came after I guess the time when Finland sided with the Germans, providing support and logistics including naval and air bases to the Germans and invadded Russia in 1941 which made the seige of Leningrad possible isn't as foundly remembered.

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

<comment><USER5> > I also find it pretty amusing that people always mention the Winter war but > not what came after I guess the time when Finland sided with the Germans, > providing support and logistics including naval and air bases to the Germans > and invading Russia later which lead to the seige of Leningrad isn't as > foundly remembered.

I don't envy the Finns of the 20th century. They were wedged in an extremely awkward spot for much of it.

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

<comment><USER4> Don't get me wrong I don't blame them the Germans were their only real possible ally it's just amusing to me that people always seem to forgo that period. That said the Finns weren't as passive as one might think they sought out to gain the territory they lost and they went into the alliance with Germany quite willingly and even proactively.

<comment><USER6> You seem to have quite an axe to grind against Finland.

Since Soviet Russia was an ally of the USA and UK for the second half of WW 2, and Soviet Russia had already attacked Finland, still occupied large territories, and intended to take the rest of the country -- what were the Finns supposed to do in order to survive against the Soviets? objectively, why start a fight against the new enemy of their enemy?

Similar question for the people of Poland, attacked by both Nazi Germany and the Soviet Union at the outset of WW 2. Do you denounce them because some resistance eventually worked along with the Red Army when they pushed out the occupying Nazis? what about the resistance who fought against the Red Army?

<comment><USER4> What exactly in my post indicated that I have any axe to grind with Finland of all places? Finland and Russia have a pretty long and complicated history dating to the napoleonic wars. In more "recent" history Russia and Finland were at odds since the Russian civil war and the Finnish civil war that followed.

During the Finnish civil war the "Whites" which one were already supported by Germany with Mannerheim which remained the commander of the Finnish forces through WW2 having a pretty close relationship with Germany. Overall even prior to the winter war Finland was not exactly "neutral" or to be more exact passive and the whole concept of "greater finland" after the Finnish civil war wasn't just a shrug.

During WW2 the Finns acted in their own best interest and they were not coerced into every action by either Russia or Germany as they had a pretty clear agenda of their own even if they could not act on it all the time due to well them being Finland.

To their credit they are the only country that managed to fight both the allies and the axis with the same government as after Finland broke the Ryti–Ribbentrop agreement by negotiating a separate peace with Russia (or well the Soviet Union) they had essentially to spend the next 7 months "fighting" the German forces with Russian troops supporting them nonetheless but for all accounts the "lapland war" had only a few engagements.

Finland also gave us the only known recording of Hitler outside of his speeches where he bitched about losing [https://en.wikipedia.org/wiki/Hitler_and_Mannerheim_recordin...](https://en.wikipedia.org/wiki/Hitler_and_Mannerheim_recording).

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> It's pretty crazy to see Sweden preparing for war against Russia, while a much bigger threat to both native and non-native Swedes resides in the streets of major cities like Stockholm or Malmo.

Or at least I can't seem to think of a single city in Western Europe where _throwing actual hand grenades_ around is a pretty usual crime other than Malmo. [1][2][3][4]

[1] [https://en.wikipedia.org/wiki/List_of_grenade_attacks_in_Swe...](https://en.wikipedia.org/wiki/List_of_grenade_attacks_in_Sweden)

[2] [http://www.bbc.com/news/world- europe-43667367](http://www.bbc.com/news/world-europe-43667367)

[3] [http://www.euronews.com/2018/04/10/sweden-has-a-problem- with...](http://www.euronews.com/2018/04/10/sweden-has-a-problem-with-hand- grenades-and-here-s-why)

[4] [https://www.spectator.co.uk/2018/02/violent-crime-in- sweden-...](https://www.spectator.co.uk/2018/02/violent-crime-in-sweden-is- soaring-when-will-politicians-act/)

</comment><comment><USER8> As someone living next door. I am curious what Swedes actually think of this? Do you see the current Russia as a credible threat? As your country's biggest security threat?

Denmark had the strategically well located island of Bornholm occupied by the soviets after the end of the 2nd world. But most Danes today would see the chances of a Russian invasion more remote than ever.

We are a NATO member I suppose that makes a big difference.

<comment><USER9> I don't think many people see it as an immediate threat. But between unpredictable American policies affecting regional politics or the global economy, the Chinese bullying countries like Norway and the Russians trying to affect politics in other countries this could all change relatively quickly.

PS. The brochure can be downloaded here: [https://www.msb.se/en/Tools/News/The-brochure-If-Crisis- or-W...](https://www.msb.se/en/Tools/News/The-brochure-If-Crisis-or-War-Comes- is-available-to-download/)

</comment></comment><comment><USER10> > "we will never give up. All information to the effect that resistance is to > cease is false."

That seems like a rather dangerous philosophy.

<comment><USER6> Swedish military doctrine was (and I expect remains) that: a) it is impossible to prevent the enemy from attempting an attack; b) we can make it as painful as possible to them, and our goal is to repel the invader from Swedish soil within days; and c) we will immediately mobilize all resources in the country to fight back, bringing hundreds of thousands of soldiers into their pre- assigned positions within 24 hours, abandoning all economic activity for the sake of total defense, so that whatever the enemy thought was a benefit in attacking Sweden, it will have been completely nullified.

Switzerland had a similar doctrine, and communicated it explicitly to potential invaders in the 20th century: try to invade the country and we will destroy all means of transportation in the plains, withdraw the army into mountain fortresses (e.g. air bases literally built inside mountains with tunnels serving as landing/take-off strips), and keep attacking you until the ends of time. Also, Swiss men keep their military rifles at home, with sufficient munition to fight their way to their assigned base in case of war.

It is interesting that neither country has been attacked over the last several hundred years, even while surrounded by fighting parties during WW II. I think armed neutrality is a beautiful thing.

<comment><USER5> IIRC, Swedish military doctrine assumes that much of their main military infrastructure will be quickly destroyed in an attack, so their forces are designed to disperse and operate from with minimal resources in difficult conditions. For instance, their main fighter is designed to operate from public roads with a small maintenance crew:

[https://en.wikipedia.org/wiki/Saab_JAS_39_Gripen#Usability_a...](https://en.wikipedia.org/wiki/Saab_JAS_39_Gripen#Usability_and_maintenance)

[https://en.wikipedia.org/wiki/Highway_strip#Sweden](https://en.wikipedia.org/wiki/Highway_strip#Sweden)

[https://www.youtube.com/watch?v=49L9BlYQSjw](https://www.youtube.com/watch?v=49L9BlYQSjw)

<comment><USER11> Yet instead of new Gripens, Croatian government decides to buy old used F16s from Israel.

</comment></comment></comment></comment><comment><USER12> It's as if war occurs when too many resources are sitting idle not being mass deployed for some common goal.

<comment><USER13> Traditionally war has been the only socially acceptable way of getting rid of excess male population.</comment></comment>


Bicycles for the mind have to be see-through [pdf] - <AUTHOR> http://akkartik.name/akkartik-convivial-20200315.pdf <comment><USER3> No comment about the Mu itself but:

> Our approach to keeping software comprehensible is to reduce information > hiding and abstraction, and instead encourage curiosity about internals

YES! Precisely. Most "bicycle for the mind" or "tool for thought" approaches go the completely opposite direction accidentally. Many programming languages and communities nowadays too.

In reality, if you wanna teach, you have to unveil the guts of the system. Sure, it's "scary" and all, but still, initial hand-holding & letting newcomers see the internals, rather than presenting an overly polished surface at the expensive of everything else, is a much better designed learning process. Design is "how it works" after all. *

Related: a common misconception when folks defend abstractions & encapsulation is to raise the issue that letting newcomers explore the internals causes too much trouble. That's an obvious strawman; these methods are not championing everyone writing anything everywhere. They can stay read-only, but public. E.g. an interface can expose its internal data types, without allowing consumers to actually leverage that (enforced through types or something else). This is easily doable, and you don't sacrifice learnability in the service of team programming sanity.

* This point seems to get dismissed quickly by folks who only care about visual polish nowadays. Imo this is naive. I care about visuals a _lot_, and we should definitely aiming for both learning polish and surface polish. But you can't let the latter calcify the former.

My advice for all the "tool for thought"/"bicycle for the mind" projects: all your opaque designs and small interface flourishes falter in the face of a properly exposed and clean-ed up paradigm, in the long run. This applies on a smaller scope to modern libraries too. That boilerplate generator you mega- fine-tuned to the point you delight yourself in guessing the user's mind, ultimately is a roadblock in the learner's thought process. Expose the boilerplate and document how you're automating it instead. You're trying to teach fishing, not to show off your own fish.

Another good analogy I've heard elsewhere is to ask whether you're teaching people how to cook, or just building a microwave. For a tool for thought product ask yourself if you ended up accidentally making "an appliance".

<comment><USER4> I think it's more like confusing people who just want to cook by expecting them to learn hob design and maintenance. The Jobs "bicycle for the mind" line was about the user experience, not the developer experience.

So the fallacy in the argument is that implementation details are relevant to everyone.

They aren't. They're relevant to system builders and people who like tinkering _because that is a separate domain to the user domain._

Most users just want an appliance, because a good appliance - like Hypercard, Excel, and maybe VBA - allows them to concentrate on the things that interest them, not on the things that interested the appliance designer when they were building their product.

This is fine for products in the the app store - it's a mark of good design that it reveals exactly as much complexity as it needs to, but no more - <USER2> it breaks down when the user domain and the tinkerer domain overlap, as they do in professional software development.

The reason it breaks down is because there is no general solution. No library is ever going to be a perfect snap-in tool that solves your problem for you, no language is going to hide OS-level and library-level abstractions with perfect elegance, and no OS is ever going to have perfectly elegant abstractions for file and network operations, simultaneous and synchronous operations, and so on.

Everyone has opinions about how software should be designed, the problems are essentially open-ended, tinkerers have a tendency to turn everything into an excuse for tinkering instead of a streamlined product/service pipeline, and the result is the mess we have today.

And this is probably how it has to be, given the limitations of human reason.

<comment><USER3> Argh, I promised myself I wouldn't come back to this thread actually; debates around this particular subject I've been part of have been tiresome =)

I can assure you that I'm not conflating simple things like user experience vs developer experience. That was the point of the asterisk.

I'm also very positive that the creator of Hypercard and Excel do _not_ think of their creation as appliance.

The whole point of the discussion around computer and computer languages/systems as tool for thought, is presuming that computing can be another form of mass literacy. Let's also not get into whether this should be the case (and my opinion here is less naive that one might think); I'm just saying that this is the debate. At the risk of exaggerating and drawing an imperfect parallel, the medieval monks also considered human language literacy as a "developer" thing, e.g. "reading the Bible is a separate domain to the everyday life of a consumer". And yes, they did make beautiful books as products/appliances. Again, I'm not saying programming languages will ever be useful to learn for the masses; that's another topic of discussion.

I agree very much that there is no general solution, and that tinkerers gotta tinker. Though this is orthogonal to the discussion (FYI I absolutely despise language tinkering/golfing these days; that's why I made sure to talk about this topic without talking about Mu earlier).

<comment><USER5> > The whole point of the discussion around computer and computer > languages/systems as tool for thought, is presuming that computing can be > another form of mass literacy. Let's also not get into whether this should > be the case (and my opinion here is less naive that one might think); I'm > just saying that this is the debate.

Exactly right. The Jobs line is a half-baked and perhaps half-understood take on the thinking of people like Kay, Papert, et al. Anyone curious about this line of thinking -- which has fallen way, way out of the popular computing discourse -- might want to check out Andrea diSessa's "Changing Minds" for a decent summary.

</comment></comment></comment></comment><comment><USER6> I know very little about "mu" specifically, but the title is a highly under- appreciated point. I often notice a tendency to abstract complexity in clean looking interfaces. While that's convenient for simple projects with pre- envisioned use cases, when using the tool in some novel way often results in bugs due to the abstraction being leaky. For that reason, I personally prefer designs that are transparent, rather than one that attempts to paint a pretty exterior on top of internal complexity. (Obviously correct, rather than not obviously wrong)

This leads to a subtle but crucial distinction between software "automating processes" without needing any humans in the loop -vs- amplifying the (expert) humans in the loop to do more stuff.

Another subtle (but arguably more important) effect comes from McLuhan's insight that the medium strongly influences the message. If the medium/tool is not transparent, then so are the biases imposed on the tool user. While that doesn't lead to obvious bugs, it leads to strutting blinders on human thought processes and creativity.

BTW, one last point, in case it isn't obvious: this goal of transparency in software can be seen as underpinning the free software movement.

<comment><USER7> I'm looking forward to reading this paper. I feel like I've found my kind of people. I've had this half baked idea about how people should be able to see what's going on in their computer, and trying to picture what that would look like. At the simplest level it's the difference between seeing a trace of what the computer is doing when it boots up vs being shown a pretty screen which freezes up. Another is just the way so many software products are like "let us worry about the details". I want to be able see everything from the bytes in memory to what's going on in every level of the system and want a user interface that lets people do that.

<comment><USER8> Check out the work of the MetaCurrency Project

[http://MetaCurrency.org](http://MetaCurrency.org)

</comment></comment></comment><comment><USER9> "Our approach to keeping software comprehensible is to reduce information hiding and abstraction, and instead encourage curiosity about internals."

This sounds rather vague, "encourage curiosity about internals". If I don't need to understand the internals why should I spend time trying to understand them? Isn't it better to "hide their details" into another compilation unit or module, which only exposes its API through an interface so I can easily understand WHAT it is doing, without having to understand HOW it does that?

It sounds like they suggest instead of sub-routines/procedures/functions I should have a single big main program, because those sub- routines/procedures/functions would be hiding information from me.

<comment><USER10> No, I use functions: [https://github.com/akkartik/mu#readme](https://github.com/akkartik/mu#readme)

I just propose to not maintain 3 levels of functions where one will suffice, just to preserve some "interface" for "backwards compatibility".

You aren't forced to understand internals. But it is an explicit design goal to make the internals comprehensible against the day you want to learn about them.

<comment><USER11> Are you proposing to break backward compatibility?

<comment><USER10> Well, it's a new computer so there's no notion of compatibility.

But yes, I'm proposing to rely a lot less on compatibility going forward. A big reason for building a new stack rather than building atop existing interfaces is precisely to avoid backwards compatibility. A big reason to keep the codebase comprehensible is to shift the social contract, so that people can fend for themselves in the face of incompatible changes. By the same token, a big reason to avoid compatibility is so that we don't have to indefinitely make the task of future readers more difficult.

I think the age of computers is just starting. 99.999% of computer use is yet to happen. It seems shortsighted to hamper the future for the sake of the miniscule past. You wouldn't want to force the adult to hew to the short- sighted decisions of the toddler.

<comment><USER9> > Well, it's a new computer so there's no notion of compatibility.

> It seems shortsighted to hamper the future for the sake of the miniscule > past.

These too statements seem somewhat contradictory to me. If we don't provide means for making systems where it is easy to validate their backwards compatibility then it becomes difficult to EVOLVE the system incrementally. That would seem to me to "hamper the future".

This is how biological evolution became a great success, not by "starting from scratch" every time but by making sure that new individuals were always more or less "backwards compatible".

Yes sometimes it makes sense to rewrite something from scratch but forsaking the idea of reusability, which is very closely related to the idea of "compatibility", just seems to me as hampering the future.

Not preparing for the future by not making sure you can easily ensure and validate backwards compatibility, is "hampering the future", in my view. :-)

<comment><USER10> We'll have to agree to disagree.

You're right that there's a tension between present and future. But that's always true. My statements aren't contradictory in isolation, they just reflect this underlying tension. You have to navigate it no matter what point you choose on the spectrum.

> If we don't provide means for making systems where it is easy to validate > their backwards compatibility...

This begs the question of _why_ you need to validate backwards compatibility. What benefits do you get? If we have a list of benefits we can start working through them and figure out if something else may substitute for compatibility.

> This is how biological evolution became a great success, not by "starting > from scratch" every time but by making sure that new individuals were always > more or less "backwards compatible".

This analogy isn't helpful, because evolution is constantly testing lots of different approaches all at once, extremophiles and bacteria and cheetahs. While many lessons are shared between simple and complex life forms, there is also a lot of branching where different organisms come up with disjoint solutions to the same problems. Human supply chains are not nearly so redundant. Lessons from evolution don't always apply to something that's 'intelligently' designed.

> ..the idea of reusability, which is very closely related to the idea of > "compatibility"..

It's worth separating these two ideas. You can have reuse without compatibility (reworking an existing codebase to fit an entirely new interface) and compatibility without reuse (cleanroom implementations of protocols).

Reuse is a difficult word to wrap my head around because it encompasses so much:

a) Calling a function at a new call-site.

b) Selecting a library for a use case it was designed for.

c) Mangling a library to support a use case it was not designed for.

d) Deploying copies of an AMI.

e) ... and much more

I'm very supportive of post-deployment reuse (e.g. d above) which is usually entirely automated. But I'm suspicious of large-scale reuse during the development process. We've been trying to make it work for decades now, and it just hasn't panned out. At what point do we reframe a goal as a delusion? I think we're way past it in this case.

<comment><USER9> > But I'm suspicious of large-scale reuse during the development process. > We've been trying to make it work for decades now, and it just hasn't panned > out. At what point do we reframe a goal as a delusion? I think we're way > past it in this case.

Software Reuse is not a "goal" but common well-understood practice. Call a function from more than one location, instantiate a class more than once and call its methods from several locations. We do that because it is helpful for development and maintenance, not because that would be our "goal".

I would think most software written say in Java uses that approach, in practice. Create multiple instances of a given class. So what would be the evidence that this approach has not "panned out" and is "delusional goal"?

Maybe your "avoid reuse" is a better approach. But I don't think there's a lot of evidence that would prove it to be so, not at least yet.

<comment><USER10> I'd argue there isn't a lot of evidence either way. What you call "common well-understood practice" I strongly suspect is just cargo culting. As evidence: it doesn't seem to make any projects turn out better. All projects eventually suck over time, no matter how well they follow "best practices".

If you're copy-pasting code everywhere rather than creating a function, that's obviously terrible. But on the other hand we've all also seen functions with twelve arguments and 3 boolean flags that are trying to do too many things at once. Is there any "practice" that gives us good guidelines on at what point to fork a function into two? I haven't heard of any such. The fact that our "best practices" are one-sided is a strong sign that they're more religion than science. Science reasons about trade-offs.

Software isn't yet much of an evidence-based science. There's just too many variables. We don't know how to reason about the interactions between them.

Here are some writings on the dangers of over-abstraction. At the very least they're evidence that I'm not alone in these suspicions.

[http://www.sandimetz.com/blog/2016/1/20/the-wrong- abstractio...](http://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction)

[http://programmingisterrible.com/post/139222674273/write- cod...](http://programmingisterrible.com/post/139222674273/write-code-that-is- easy-to-delete-not-easy-to)

[http://bravenewgeek.com/abstraction-considered- harmful](http://bravenewgeek.com/abstraction-considered-harmful)

[http://dimitri-on-software- development.blogspot.de/2009/12/d...](http://dimitri-on-software- development.blogspot.de/2009/12/disadvantages-of-code-reuse.html)

<comment><USER9> > All projects eventually suck over time, no matter how well they follow "best > practices".

Yes they (often) "suck" but many of them work as well, produce widely used software.

I would not call subclassing a "best practice" but a widely used form of reuse. It is a useful feature to have in your toolbox, in my experience, having programmed in Java and other OOP languages.

I think it boils down to "There is no Silver Bullet". Reuse is not a Silver Bullet. But it is "a" bullet. :-)

<comment><USER10> If we've gone from thinking of it as essential to just "a" bullet, I'm happy. Now we can have a productive conversation about what other bullets this bullet displaces in your toolbox, and whether that's worth it.

I'm not claiming functions are bad, or classes are bad, or inheritance is bad (there is evidence of the last, but it's orthogonal to this discussion). I'm claiming freezing interfaces for compatibility guarantees is often a bad idea. There needs to be far broader awareness of what you give up when you freeze an interface and commit to support it indefinitely.

It's about minimizing zones of ownership within a single computer. Right now our computers have thousands of zones of ownership, and it's easy for important use cases and bugs to fall through the cracks between zones of ownership. Freezing an interface fractures what used to be a single zone of ownership into two.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> The paper name-drops Ivan Illich and "Tools for Conviviality". If you are intrigued by his ideas, you might be interested in the blog by L. M. Sacasas, The Convivial Society. His writing holds plenty of insight on the intersection of technology and society.

[https://theconvivialsociety.substack.com/](https://theconvivialsociety.substack.com/)

</comment><comment><USER13> I love the effort to make the stack fully transparent and learnable. This seems so important! I wish more people had the ambition to re-invent the basics of our computing platform to see how things could be different.

Now my question is does this learnability hold as the code grows? For example, would the transparency enabled by the stack be reflected in the codebase for a word processor built on this stack? I'd expect _not_. For one, I'm thinking about how the original program in my Marilyn Maloney demo ([http://glench.com/MarilynMaloney/](http://glench.com/MarilynMaloney/)) had good primitives, grammar, and a visual representation, yet the code is still hard to understand and can be made much easier to understand with depicting behavior (the interactive UI I made).

Secondly, I'm thinking of the Alan Kay-ism "architecture dominates materials" i.e. the invention of the arch was much more effective than the invention of the brick. Mu seems like it could be a great, transparent material, but more important to how software is understood and modified is the architecture of how the material is organized (and personally I think this has a lot to do with UI design and human communication more than the technical foundation).

<comment><USER10> These are good questions! It may well be that there's an architectural breakthrough out there that will obsolete this whole approach. It's one of very many ways it can fail. Think of it as a hedge, at a societal level. What if we aren't able to come up with a technological breakthrough? After all, software has lagged Moore's law for decades now. I think there's a very real danger in the next few decades that software will get regulated like other fields before it, killing the intrinsically motivated aspect of it entirely. That would be a huge loss to society.

We'll have to see how higher levels of the stack develop. I started on this quest building a Lisp, so believe me when I say I can't wait to get to the high-level side of things. There doesn't seem any reason to imagine that we can't have good primitives, grammar and visual representation. My claim is merely that in addition to these interface properties the implementation for them is also important. And it gets short shrift in the conventional narrative.

That said, let's imagine that there's a strong case that we need to give up parser generators (or something similarly high-level) in order to give everybody the ability to understand their computers. I'd take that trade in a heartbeat.

</comment></comment><comment><USER14> I'd like to read this, but it's triggering my BS radar by the amount of gobbledygook and sentences like "Creating an entire new stack may seem like tilting at windmills, but the mainstream Software-Industrial Complex suffers from obvious defects even in the eyes of those who don't share our philosophy."

<comment><USER10> I wrote it for an academic conference ([https://2020.programming- conference.org/home/salon-2020](https://2020.programming- conference.org/home/salon-2020)) which had as its theme an essay by Ivan Illich ([http://akkartik.name/illich.pdf](http://akkartik.name/illich.pdf), pdf, 67 pages)

But in the end, your BS radar is your own.

<comment><USER14> That's fair. But academia is often full of BS, pardon the language, and so the radar needs to be cranked up. With, say, Medium articles, one can skim if it's good or not within seconds. Academic papers can take hours, if not weeks to discover if it's complete BS or whether I'm just not smart enough, and so I can only go off minor cues.

It's generally better to read hard things. They're hard because they have a lot of information density or a lot of gaps. But that also makes people confuse poor readability for quality. Something that has no content tries to be hard to read by stuffing it full of gobbledygook. Whereas something that is trying to communicate an idea often goes through a few revisions trying to simplify the idea. If you have great ideas, you want the user to be expending their brainpower trying to comprehend the idea, not translating it into simple English. (exception is using jargon that's common to people at the right level)

<comment><USER8> > Academic papers can take hours, if not weeks to discover if it's complete BS

Did you see this recent thread? It is a paper on how to read papers and it was very useful and insightful for me.

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

From the linked pdf:

"Researchers must read papers for several reasons: to review them for a conference or a class, to keep current in their field, or for a literature survey of a new field. A typical researcher will likely spend hundreds of hours every year reading papers.

Learning to efficiently read a paper is a critical but rarely taught skill. Beginning graduate students, therefore, must learn on their own using trial and error. Students waste much effort in the process and are frequently driven to frustration.

For many years I have used a simple 'three-pass' approach to prevent me from drowning in the details of a paper before getting a bird's-eye-view. It allows me to estimate the amount of time required to review a set of papers. Moreover, I can adjust the depth of paper evaluation depending on my needs and how much time I have. This paper describes the approach and its use in doing a literature survey."

</comment></comment></comment></comment><comment><USER15> I really wished such papers had double spacing, or better still, the ability of adobe reader to allow you to adjust such spacing - that would be an amazing feature as for some layouts, they are easier to read with better spacing between the lines - at least for me.

</comment><comment><USER16> My bicycle has been Ruby on Rails for over 10 years and i think it is hard to beat. most all of the underlying framework is easily inspectable and changeable to suit needs, while still providing sharp knives that one could use to cut themselves if not careful.

But I think this push for "stimulating curiosity" is academic wank. That's not what bicycles of the mind are for - they're tools for building, not naval gazing. It sounds like Mu was built more for ego or prestige than to actually do anything meaningful.

Show me Mu as a bike I want to ride - not as a philosophical introspection on why Mu is in some way superior. Reading this PDF it's clearly more ideal than practical. And while it may be "see through" it's shape, interfaces, interactions and surface area are convoluted and poorly presented.

Maybe I am wrong to expect humanities out of this, but humans are who have to use this stuff/ride these bikes.</comment>