Using No Mocks to Improve Design (2012) - <AUTHOR> http://arlobelshee.com/the-no-mocks-book/ <comment><USER2> One thing I've learned from using immutable, functional languages (Elixir) is:

"Don't tell your computer what to do, tell it how to transform data"

While it may seem obvious, it's been a revelation for me and it has totally changed how I write code, and especially how I test it.

In the example they read some command line arguments, read an input file, and process it. The natural instinct it to implement it exactly as it reads.

You can't do that on a functional language, you need to reframe it into:

1) Transform command line arguments to some symbol representing the action to execute.

2) Transform a file name into a string representing the file contents.

3) Transform a string (file contents) into some data structure generated by processing it.

For example, in an Elixir pseudocode:

        command = parse_command_line(argv)
        case command do
          {:process, file} ->
             contents = read_file(file)
             output = analyze(contents)

          _ ->
             print_usage()
        end

Now each of these functions can be tested by itself and doesn't require mocking. They are just pure functions transforming input arguments into something else.

But there's no error handling: Elixir would solve that very elegantly with both pipelines and pattern matching:

        parse_command_line(argv)
        |> read_file
        |> analyze
        |> output_result_or_error

Each of these functions accepts and returns a tuple of {output, error}, and, if "error" is set, we just don't do anything but pass it down the pipeline. Basically the Either monad from Haskell.

Errors-as-values are much better than exceptions for this exact use case. Exceptions are hard to test, to replicate, to inject, while in this example you can just test error handling by.. passing an error value to the function.

<comment><USER3> Agreed, but I'd like to point out that you can write in functional style in pretty much any language. Most of my professional life involves VB.net which is mostly object oriented (for some value of object oriented) and procedural but I try to write as much of the code as possible as functions with no side effects. The biggest problem is convincing my colleagues to do the same.

</comment></comment><comment> a-priori I really don't understand why this post says that "mocks are a smell".

For the last few years I've been mostly a Java developer and I've settled on a style of using a very mock-heavy testing style focusing on unit testing the interactions it has with other objects in the system. I use Mockito ([http://mockito.org/](http://mockito.org/)) to automatically generate mock objects from a class/interface.

When you combine it with dependency injection you get a testing workflow where you can fully isolate the unit-under-test from the outside world and rigorously verify its interactions with its peers.

</comment><comment><USER4> This article starts with the assumption that testable code is better code. Its primary point against mocks, that mocks let you write tests without changing your code, is dependant on that assumption. Without the assumption, there is no reason to believe that changing your code for the sake of tests is good or bad.

I claim that that assumption is faulty. Code being easily testable indicates that it follows a certain set of good rules of thumb for writing good code. You're unlikely to find 500 line functions that encompass half of the program's logic. You're likely to find well delineated inputs and outputs of functions. The vast majority of the time, these are _good things_ , and it's tempting to say that since writing testable code gave use these good thing, that only testable code is good. Or maybe you'd rather not leap that far — perhaps you'd rather only claim that as a rule, code should be written to be testable.

It's not that it's an unreasonable rule. I'd be inclined to embrace it for novice programmers, since their judgement for what is and is not good code is lacking and they have to write tests regardless. Their code will probably come out better if they write for testing than if they try to use their best judgement. But once a programmer develops their judgement, they must use it. Programming is an art — a controversial statement, I know. It is not an art like music or painting or writing, it is more like architecture. Programming is about communicating simultaneously with humans and computers. Good code is that which achieves its technical requirements of reliability, performance, security, etc. in the way most accessible to a human. Good architecture is that which achieves its technical requirements of structural stability, cost- effective layout, energy efficiency, etc. in the way that best meets the needs of the people who will be seeing and using the space.

There's nothing about testing in that definition. Optimizing code for tests is like optimizing a building for government inspectors. Yes, making all of the piping and wiring easily accessible via a hatch in the wall is a good thing because it will allow easier repairs and upgrades, but splitting the toilets into three different parts connected by rubber hose so that the inspectors can verify that the flush mechanism and the trap and what-have-you are all working properly independently would be inadvisable.

I'm not going to attack the examples presented in the article because they are clearly a strawman. They serve to demonstrate the ideas the author sponsors rather than as a case study in how the author is right.

<comment><USER5> When we use the term "art," we're adapting the Latin term "ars" to English. "Ars" also translates as "craft." Using "art" probably worked well 100 or more years ago when most educated people had taken Latin and, thus, had more ready access to such nuances, but today I think "craft" is the better word.

"Programming is a craft" communicates the idea that its practice is not constrained to a set of hard and fast scientific principles; but, rather, that it's an endeavor that requires much experience to fit theory into practice, and that there are even certain aesthetic components to its practice.

Programming is a craft in the same way that non-fiction writing -- or architecture, to use your example -- is a craft. We can of course say "art," but then we get distracted by the thought of men wearing hair buns and skinny jeans.

<comment><USER4> "Art" and "craft" aren't synonyms though. Art is a subset of craft. A craft can relatively easily be defined as something which is produced by applying skill.

Defining art is notoriously hard, but the most terse definition offered by anthropology is the "transformation-representation" definition, wherein art is anything that alters the beholder's experienc of an idea by way of its representation. This means that all communications with a human in a way where the representation is considered (so excepting casually chatting with someone) are an art. Source code communicates with humans using a representation that mind-numbingly explicit, and a person's mental-model of how a procedure or algorithm conceptually functions is transformed by viewing source code.

So I agree that describing programming as a "craft" is more generally useful, in the specific case I addressed in my comment, it is the respect in which programming is an _art_ that is relevant.

</comment></comment></comment><comment><USER6> I've been thinking about this for a while; change code vs mocking. I think what I've been looking for is a justification for doing the first and I agree with the design argument here; it feels strange reaching into underlying code so supply plugable paths for not just tests but all code to be able to change the part that you were about to mock. It'll lead to a more flexible system overall and one that the tests are more explicit and use less magic.

</comment><comment><USER7> I'll give my 2 cents (which may or may not be worth it ;-) ).

Mocks are useful when you are doing TDD. At some point you have to build something which will need several collaborators, but the collaborators have not been built yet. You're not sure yet what final shape the design should take, so it's great to build an object, mocking the collaborators. You can then build the collaborators. This allows you to refactor your design easily and quickly when you are in this early stage. It's easy to change the interface of an object that hasn't been written yet ;-) Then when you implement the mocked object, it's easy to write because you just implement the bits that were mocked.

At this point, I tend to replace my mocks with real objects. The reason for this is almost exactly the same reason for using mocks initially (ironically): mocked objects make your design hard to refactor. If I change the interface for an object, then anything that has mocked that interface needs to have its tests updated. This is not hard, but is crappy enough that it stops people from refactoring their interfaces. When you are using real objects all the way through, you often only need to change the production code and the unit tests for the object whose interface you changed.

Real objects in tests are also really useful for documentation purposes. When you use real objects you have to show how to build the objects and how all the collaborators work. Some people tend to think that this is "integration testing" and should not be done in unit tests. I disagree fairly strongly with that idea, but I would be remiss if I didn't acknowledge that some of the anti-real-objects-in-unit-test people are pretty smart people ;-) Obviously real objects are safer to use as there are ways to confuse yourself with mocks so that you don't actually test anything meaningful.

The main downsides with real objects is: sometimes you have to build the world to make them, and sometimes the real object has some external dependency which makes testing with them infeasible. The first issue is often a sign of poor design and should be rare -- but of course life happens. The second issue is usually not something you can control. In these circumstances, I will prefer to use mocks. In some circumstances you end up having to make mocks of mocks, or reaching down into structures you shouldn't know about. In those cases I prefer to use fakes.

All of these techniques are valid and useful techniques. In any non-toy problem you will have to use all of them to have a good test system. The trick is knowing when you should be using each. That requires some experience.</comment>


Ask HN: Facebook.com missing from Google? - <AUTHOR>

I searched for "facebook" on Google, and the top result is now the Wikipedia article. I do not see a result for the homepage either. Anyone else seeing this? <comment><USER2> Certainly not the case for me. Facebook shows up as the top result.

<comment><AUTHOR> Now it is for me too. That was weird!</comment></comment>


Temple Operating System V1.00 Released - <AUTHOR> http://www.templeos.org/

<comment><USER2> Skimming the source code files I really wanted to play his game: <http://www.templeos.org/Wb/Apps/Pilgrims/Pilgrims.html#l1>

Fortunately he made a bunch of videos showing himself playing the games, with a voiceover containing his own quirky humour:

<http://www.templeos.org/Wb/Accts/TS/Wb2/Games.html>

Wow.

NSFW: I noticed some bigoted comments on the blog.

</comment><comment> kostya-kow Reddit discussion:

[http://www.reddit.com/r/programming/comments/1aqdxn/temple_o...](http://www.reddit.com/r/programming/comments/1aqdxn/temple_operating_system_v100_released/)

This guy has schizophrenia, and a some of things he says is really weird.</comment>


Plano, Texas ranked as best city for building personal wealth - <AUTHOR> http://money.cnn.com/2008/06/30/real_estate/personal_wealth/index.htm?section=money_topstories

<comment><USER2> Interesting title: _small-town life may mean big money_.

Plano is anything but a small town, at least by the American perspective. It is the quintessential suburb of a top-ten city, and thoroughly enmeshed in the metropolitan area. Only someone from one of the top five cities could think of Plano as a "small town". Consider the 5A high-schools: my brother graduated from Plano Senior High School in 1984 in a class of 1200. I hear they are even bigger now. That school is not the only one at that scale, and it would be considered 6A in some states.

Having said that, I think Plano is one of the 3 cities in the Dallas Metro area that have a decent shot at becoming a technology hotbed that resembles the well-known ones (The Valley, Boston, Austin). Plano actually resembles Austin in some ways.

Rockwall and Richardson are the other two Dallas suburbs that I think make for decent technology areas. We'll see how that shapes up.</comment>


Recursion, Refugees and Me; Why I Started a Code School in Athens for Refugees - <AUTHOR> https://medium.com/@chrisowen/recursion-refugees-and-me-36e4105f68b7 <comment><USER2> This is an interesting article. It gives a perspective on, and out of, the experiences of the author, the underpinnings of his choice to come (to Athens) to try to build a structure to assist others, the exchange that happens within the interaction of giving and receiving; and on how receiving a gesture from another, one may be left with the spirit of this gesture with him, and may chose to support it.</comment>


Bitcoin Price Will Go to Zero as Bitcoin Will Struggle To - <AUTHOR> https://www.cityfalcon.com/blog/investments/bitcoin-price-will-drop-zero/ <comment><USER2> User kofk, 2 submissions 0 comments. Both submissions point to cityfalcon.com.</comment>


Deep Learning: An MIT Press book in preparation - <AUTHOR> http://www.iro.umontreal.ca/~bengioy/dlbook/ <comment><USER2> Why is "deep learning" so hype nowadays? They seem like just another AI tool that will be prone to over-fitting datasets and provide an analysis that is difficult to mathematically characterize and understand in a reliable way.

Not here to be cynical/negative -- they might be of great value, this is not my expertise. Can someone explain why deep learning articles are receiving attention rather than, say, Support Vector Machines / kernel-based methods of pattern analysis? Or other nonlinear analysis? Are they related?

<comment> shock-value I think you are right in your sentiment that deep learning is becoming over- hyped. I've written before that it's mostly a method of brute forcing the problem of AI that happens to work very efficiently on modern GPUs and other parallel processing units. That being said, for the tasks it does well on (mostly facial and other types of simple image recognition), it does extremely well compared to everything else out there. (And it may very well end up as a part of a future architecture that better simulates general intelligence.)

However, I don't think it is reasonable to assume that AI tools can only be valuable if they can be rigorously mathematically characterized. The "holy grail" of intelligence -- that is, actual human intelligence -- certainly can't or at least hasn't been mathematically characterized, and I don't think anyone will ever offer any "proof" (mathematical or otherwise) that the biological brain is inherently wired to arrive at or at least tend to converge to correct solutions to intelligence problems. And of course no one will argue that human intelligence isn't valuable!

<comment><USER3> >The "holy grail" of intelligence -- that is, actual human intelligence...

When people talk about human-level AI, are they referring to specific beneficial subsets of human intelligence, like holding a conversation or interacting with the world around them, or does it literally include all of human cognition? In other words, would the "holy grail" include AI that acts extremely irrational and makes poor decisions based on temporary chemical imbalances in the body? Does the perfect human-level AI get depressed and commit suicide some of the time? Are we trying to replicate all of the parts, or only the good parts?

<comment><USER4> Good point. I would compare it with human speech. Human speech is a powerful mean to communicate and for this reason it is thus very tempting to develop artificial systems that can communicate in the same way. But human language is far from optimal. In the same way, I believe that human brain is powerful but far from optimal.

The strength of human brain is its ability to adapt to fast changing context. The solution (function) it finds is however usually far from optimal.

I also think that the future of computing is the development of systems that can efficiently adapt their rules of actions according to execution context evolution. The programmers of today will then become trainers.

</comment></comment></comment></comment><comment><USER5> See also Michael Nielsen's book Neural Networks and Deep Learning

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

<comment><USER6> Unfortunately, the chapter(s) on Deep Learning haven't even been written yet.

</comment></comment><comment><USER7> This looks like it has the potential to be a great resource! Not to mention it's coming out of one of the big name schools of deep learning (along with UToronto and Stanford).

I imagine, though, that anyone not well versed in college mathematics may have issues with the explanations. If you want a good introductory resource, but either haven't covered or have forgotten some of the math in this book, I would recommend one of two resources:

[1] MetaCademy: [http://metacademy.org](http://metacademy.org) [2] Neural Networks and Deep Learning (In Progress): [http://neuralnetworksanddeeplearning.com](http://neuralnetworksanddeeplearning.com)

The first will take you through all the math first through some online courses and textbooks, and the second is a good general purpose introduction that I recommend to anybody interested in neural nets.

</comment><comment><USER8> Sigh. The authors have taken a PDF and generated HTML out of it. I can understand the desire to maintain copyright, but this is ridiculous.

</comment><comment><USER9> Question: Does anyone have updated information about Hinton's 'trillion parameter network' progress ([http://deeplearning.net/2013/05/20/g-hinton- wants-to-train-n...](http://deeplearning.net/2013/05/20/g-hinton-wants-to- train-neural-nets-with-trillions-of-parameters/)) from almost a year and a half ago?

It's been quite a while and even Ng has demonstrated that a billion parameter setup could be built for $20k using commodity hardware ([https://news.ycombinator.com/item?id=5896684](https://news.ycombinator.com/item?id=5896684)).

I wonder what's happening at Google labs as of August 2014.

</comment><comment><USER10> Here's a talk by Geoffrey Hinton back in 2007 about Deep Learning neural networks:

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

</comment><comment><USER11> Pages look ok in Firefox, borderline unreadable in Chrome. I wonder what that's about.

<comment><USER12> They've converted a PDF to be shown in HTML. Possibly using PDF.js or something.

<comment><USER13> Looks like they used pdf2htmlEX ([https://github.com/coolwanglu/pdf2htmlEX](https://github.com/coolwanglu/pdf2htmlEX))

</comment></comment></comment><comment><USER14> Hrm ... there has got to be a better format for soliciting edits. Github, Google Doc, ???

</comment><comment><USER15> I hear O'Reilly's coming out with a book soon as well.

</comment><comment><USER16> this is great, I hope the authors keep a .pdf version available for dl once its done

</comment><comment><USER17> First it was data mining, then machine learning, and now deep learning. What's the next name? Clairvoyant learning?

<comment><USER18> The latter is a subset of the former and refers to particular architectures/strategies for doing machine learning/data mining. Think deep as in hierarchies not deep as in "whoa, man". Some ideas in deep learning are new; some are old. It's not entirely a rebranding.</comment></comment>


Show HN: Tunnel Vision – See your next Trello tasks everytime you open a new tab - <AUTHOR> https://tunnelvision.xyz <comment><AUTHOR> (reposting this, because my previous submission didn't have a URL – whoops!)

Hi HN, this is my first browser extension. Curious to hear what you guys/gals think.

I personally love Trello, but I've got so many boards these days it's hard to keep track of it all and I'm often left wondering what I should be working on next.

I've found having a clear sense of what to work on next is very crucial though if I want to stay focused and get things done.

That's why I decided to create this extension that replaces your 'new tab' page with an overview of all your boards/project and the next task for each of them.

Support for Safari coming soon.

From a technical standpoint I think it's interesting to note that the extension connects directly to Trello using their official API and Client.js[1] – This way your data stays secure and I don't have to manage any servers :)

[1] [https://developers.trello.com/clientjs](https://developers.trello.com/clientjs)</comment>


Self-host the web with ArkOS - <AUTHOR> https://arkos.io <comment><USER2> The real solution is a distributed hosting and traditional interfacing system. Like YaCy but genetic.

People participate in it like in SETI@Home, Tor, or the mersenne prime number search.

"Site" code gets deployed in a git/bittorrent mashup with a web-of-trust system of signed certificates.

Code can be federated and distributed and not rely on a single point, ie github.

People access it by running their own modified DNS server that gets updated with the serving "exit nodes". (Part of the hypothetical client)

It is essentially Tor but no crazy onion URLs, direct connections, and divestment at the back end.

The user downloads the client, runs it and that's it.

Pick some TLD that sounds safe for the taking, like .!com and we're good to go.

There's even a trendy new currency that makes ecommerce viable using this system. ;). It's all there.

I've implemented bits and pieces over the years. But never gotten the full model working.

Everything from domain registration to fair load balancing all have hard, but feasible solutions.

And what do you get for it? The same freedom that bittorrent and bitcoin give you, but for everything. You get it all.

<comment><USER3> So basically Freenet?

<comment><USER2> Yes. There's lots of examples of this... Just none doing all the parts I'm thinking of

</comment></comment></comment><comment><USER4> Having run a similar setup (self-configured) on a Raspberry Pi I see one major issue - the Pi has an ability to damage your file system after prolonged use. I've had this consistently happen every 60-90 days of use. There are hundreds of reports of it in the forums. (Search for Raspberry Pi corrupt filesystem on Google)

My question is - how do you plan to account for this?

<comment><USER5> Several ways - arkOS already has a tool ([https://github.com/jacook/logrunner](https://github.com/jacook/logrunner)) for buffering logs in RAM before they are written to disk, thus reducing probably the top cause for SD card wear on webserver Pis. Its RAM footprint is lightweight, and it makes a huge difference over time. Secondly, with a successful crowdfund campaign the project will be able to install both to SD card AND to a USB-connected drive. Meaning that boot gets written to SD and data is stored on an external device, something more hardy than a cheap SD card. :) Finally, backup services (plural because there will be a couple different options for people to choose from) will be made a part of the core framework, making regular backups easy and data loss less of a nightmare.

<comment><USER4> Logrunner seems very useful, will try it out.

With a powered USB drive it would be a nice setup!

But I feel that Drydock and arkOS CONNECT do not fit your model. Setting up central backup and a VPN for your Pi is essentially just another service. The point of this was to get rid of the middleman, yet you conveniently introduce yourself as one?

<comment><USER5> I totally understand the impression. But the goal with arkOS is to help people securely self-host with as much stability as possible. Since self-hosting is a complex and occasionally troublesome thing, some people may need help in getting properly connected. So the only reason we consider hosting those services is to help with these ends. If someone needs the services in order to self-host, I think it is better that they use them, rather than not being able to self-host at all. Any services will be 100% optional and up to the end user.

<comment><USER4> I appreciate you taking the time to write informed answers!

</comment></comment></comment></comment></comment><comment><USER6> I think "secure" and "cloud" are pretty misleading. In terms of security (if it's about my personal mail/calendar) my bigger concern would be that my data is lost, e.g. not backed up properly, deceptible to hardware failures. As for "cloud" \- I can't see much on the page that would have remotely the same properties as a "cloud" solution. Maybe that's why they put it in quotation marks? Still, very misleading imho.

<comment><USER5> There are steps taken to address security and stability concerns. See my other commends on this item. Also you may need to look beyond just the front page - can't put everything we want to do and plan to do on the front page at once. :)

</comment></comment><comment><USER7> What about ISPs that block port 80? Does arkOS handle that? I don't see how it could.

<comment><USER8> [https://github.com/cznweb/deluge](https://github.com/cznweb/deluge) \- Server for DynDNS/request tunnelling to arkOS nodes [https://arkos.io/deluge](https://arkos.io/deluge)

^ is in the works

<comment><USER9> I've made ngrok completely open source and permissively licensed, I'd suggest using it rather than reinventing your own. Feel free to contact me about it.

<comment><USER5> Thanks -- we are checking it out and definitely considering working it into our implementation</comment></comment></comment></comment>


Doug Comer: How to Insult a Computer Scientist - <AUTHOR> http://www.cs.purdue.edu/homes/dec/essay.criticize.html

<comment><USER2> I once witnessed a wily 40-something Master's student torturing one of the department's young star PhD candidates. The PhD student had caught one of his mistakes and was taking it back, as any honorable academic should. The Master's student continued on, pretending as if the PhD student was insisting on the correctness of his earlier assertion. You could see the urgency with which the PhD student was trying to roll over and expose his belly, and his perplexity at that not working.

Never have I seen someone so distressed at being told he was right.

<comment><USER3> I've read this comment about ten times now and I still can't quite understand who was doing what to who. Am I going crazy?

Edit: I think I see now. The master's student was the distressed one.

<comment><USER2> Nope. The PhD was the distressed one.

<comment><USER4> Please rephrase. It sounds like an interesting anecdote if it were understandable.

<comment><USER2> M = Master's student P = PhD candidate

M discovers P is wrong and says why.

P realizes his mistake and admits it like any honest academic would.

M keeps on going on like P is sticking to his guns.

P relents again, embarassed, since sticking to his guns would be anathema to his being.

M keeps on going on like P is sticking to his guns.

P tries harder to make it clear that he's relenting.

M keeps on going on like P is sticking to his guns...

I wish I could remember what they were talking about. M kept the other guy going for quite awhile and got him pretty riled up.

In essence, it was Trolling, but in person. (There is a good chance that this thread is trolling of the more common online variety.)

<comment><USER3> Ah, okay. It was just the last sentence that threw me for a loop:

 _"Never have I seen someone so distressed at being told he was right."_

From the anecdote I understood that the PhD candidate was being told he was wrong. Anyway, I promise I'm not a troll, at least not on purpose.

<comment><USER2> It's a bit subtler than that, even. The M doesn't tell P _that_ he's wrong, he says _why_ he's wrong. He never comes out and says P is wrong, he just lets everyone around "get it." P gets it too, and tries to back off. M keeps spinning the illusion that P is sticking to his guns.

I never realized how evil M was until I thought about it again.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> Would a computer scientist be insulted if you suggested he had wrapped a small amount of useful functionality in multiple and unnecessary levels of abstraction?

What if you suggested the same of his essays?

</comment><comment><USER6> Is referring to engineers as "experimentalists" part of the joke?

In any case it was a good, light read that I'll take to heart in the next version of my insulting library.

<http://insults.rubyforge.org/>

</comment><comment><USER7> In theory, there is no difference between theory and practice. In practice, there is.

I think it was Kissinger who said that academic politics are so intense because the stakes are so small. These kinds of essays get old after a while.

</comment><comment><USER8> Doug Comer seems to be quite disillusioned with academia - he has posted several similarly wry CS 'essays' on his website: <http://www.cs.purdue.edu/homes/dec/>

<comment><USER9> Comer is just a straight out character. He's one of the few people who can legitimatly point at the internet and say "I made that".

Yes, he knows where to point to be pointing at the internet.

With that kind of work behind him it's hard to do anything else as important, and it's hard for anyone to criticize him.

</comment></comment><comment><USER10> Last-Modified: Fri, 01 Dec 2000 21:15:34 GMT

<comment><USER11> Oh gee, you're right. It wasn't posted last week, so it must be irrelevant and worthless, right?</comment></comment>


Why Is Concurrent Programming Hard? - <AUTHOR> http://www.stefan-marr.de/2014/07/why-is-concurrent-programming-hard/ <comment><USER2> Concurrent programming is hard because "concurrent programming" usually means "concurrent programming with mutable states and imperative control constructs". So concurrent programming is hard because imperative programming is already hard, and then multiple threads with unpredictable scheduling order are let loose on it.

Also, due to variation in scheduling order, concurrent program's bugs may be only sometimes reproducible, even when the input between the working and failed cases are identical. It's as if all concurrent programs have an implicit real-time input source that perturbs their behavior.

The bugs in concurrent programs are an entirely new class, like "race condition", "lost wakeup" and "deadlock". Even a great programmer who understands N levels of pointer dereferencing and "leaps complicated algorithms in a single bound", but has no concurrent experience, may well be defeated by concurrency bugs.

<comment><USER2> I'd like to expand on this just a little; indulge me.

When we write programs, we normally keep them tidy by taking advantage of scoping. Data is localized using local variables. We use parameter passing to communicate among modules and avoid globals. However, imperative concurrent programming is all about globals: the "shared variables" that have to do with the concurrency of the program, violate scoping: necessarily so, because to be shared, they have to be accessible from multiple scopes.

In imperative programming, there is an important reassurance: namely that variables retain their last stored value. If you put 42 into x, then x keeps holding 42 until you put something else in x. If x is globally visible, and you call some function, forgetting that it has a side effect of changing x, it wrecks this assumption. Suddenly, x has mysteriously changed: you could swear you put in 42, but now it somehow has 43. Why? All you did was call foo; that has nothing to do with x. Oh, but someone committed a change, and foo now calls bar, and bar makes several other functiosn calls which end up back in this same unit in another function that frobs x.

In concurrent programming, you are opening the doors to this type of problem: and what is worse is that shared variable x can change at any time, not over some predictable action like calling a function. When you assign 42 to x, x could turn into 43 even before control passes out of the assignment statement and to the next statement.

All the surprises arising from multiple scopes having visibility over the same shared data become worse thanks to the asynchronous nature and unpredictable scheduling order.

If you keep programming in the same way that you are used to, you are _guaranteed_ to have a problem. Simply to have the same assurance that "x is holding the value I put there in the current thread of control" you need to take special steps, like locking a mutex (consistently, from every user of x) whereas in non-concurrent programming, the assurance comes from good design, like making x local, or simply not branching into any code which might change x for as long as you need x not to change. I.e. you can achieve the basic assumption quite _passively_ in the absence of concurrency (based on what you don't do), whereas you have to be proactively cunning in concurrent programming.

<comment><USER3> _> imperative concurrent programming is all about globals: the "shared variables" that have to do with the concurrency of the program, violate scoping: necessarily so, because to be shared, they have to be accessible from multiple scopes._

I may be nitpicking here but "accessible from multiple scopes" is not the same as being "all about globals". Data can usually still be localized to the routines that use it without throwing it in the global scope. The inherent problem of two threads sharing data is also something that will _have to_ be dealt with on some layer of the implementation if you want the threads to communicate, regardless of programming paradigm. Some languages provide really nice abstractions to deal with this in ways that don't explicitly have the programmers invoke locks. Among imperative languages, Go provides a really useful and sensible such abstraction with channels.

 _> In concurrent programming, you are opening the doors to this type of problem: and what is worse is that shared variable x can change at any time, not over some predictable action like calling a function. When you assign 42 to x, x could turn into 43 even before control passes out of the assignment statement and to the next statement._

Still nitpicking, but you should separate the concerns of parallel programming that don't necessarily have anything to do with concurrent programming. Imperative concurrent programming can be implemented by having routines explicitly yield control to other routines (e.g. protothreads, greenlets), making the execution order entirely predictable.

<comment><USER2> Explicit yielding of control is not concurrent programming, almost by definition. The execution order is entirely predictable precisely because it is serialized by the yield calls. The software specifically relies on these cooperative threads not being concurrent, such as "if I don't call anything which can yield, then nothing changes in a surprising way". Also, because it is not concurrency, it won't run on multiple processors.

(There can be a loose order in cooperative threading in not knowing which thread will be run next when yield is called. It's still not serialized.)

<comment><USER3> Again, note the difference between parallel execution and concurrent execution. The software specifically relies on these cooperative threads not being _parallel_ , which is not an inherent property of being concurrent, most certainly by definition.

Reading the first part of the article is a good start on understanding the distinction. Maybe this sort of lack of a basic understanding of the concepts is why concurrent programming is hard.

<comment><USER2> There is no substantial difference between "parallel" and "concurrent". Bot mean "running side by side" except that by "parallel processing" we usually exclude _simulated_ concurrency.

However, simulated concurrency requires asynchronous behavior: an external event, such as a timer interrupt, or the arrival of input, can come in at any time and change the control among the tasks (preemption). This looks a lot like true parallelism and must be programmed with the same care as real parallelism, which is why we dare call it concurrency.

Tasking without preemption is not concurrency. The tasks know that they cannot be preempted and rely on that assumption for their correctness. This approach falls into the same domain as the use of coroutines, or dispatch queues of lexical closures, first class continuations, generators and such: none of which represent concurrency.

I do not believe I require any correction in terminology or concepts; I've been programming for 33 years, and I'm the person who invented and first implemented glibc's PTHREAD_MUTEX_ADAPTIVE_NP mutex back in 2000.

</comment></comment></comment></comment></comment></comment><comment><USER4> There are only 2 hard problems in Computer Science: naming things, concurrency, and off by one errors.

<comment><USER5> And date/time handling... actually, those three you mention are quite easy to me, I just hate working with date/time stuff.

</comment></comment><comment><USER6> Concurrent programming would be hard even if we had great _abstractions_ because concurrent programming means maintaining exponentially many possible states. If you go down that route then there are few good tools for handling or even _conceiving_ of such problems[0].

The other route is, I think, less well described as "abstraction" and more around _restriction_. For instance, Erlang's model simply ensures that while you're dealing with exponentially many program states, the kinds of interaction between those states means that you basically are able to pretend like they don't exist for most problems. (This is also the mechanism of things like Bloom and LVars which are whole models of commutative/convergent programming that _happen_ to be executable in parallel).

[0] Here's a good one: combinatorial topology! [https://www.elsevier.com/books/distributed-computing- through...](https://www.elsevier.com/books/distributed-computing-through- combinatorial-topology/herlihy/978-0-12-404578-1)

</comment><comment><USER7> I was lucky enough to ask Leslie Lamport some questions about TLA+, which is a programming language of his creation based on the Temporal Logic of Actions: basically predicate logic with some reasoning about Time thrown in. With it, you specify concurrent algorithms in terms of possible state transitions and assertions which should hold in all program states (or subsets of those states). A model checker then runs through all the states, checking your assertions (this can understandably take quite a while, so there's a distributed model checker for large systems).

A really good takeaway from the talk is a point he made on software testing: for sequential algorithms, conventional software testing is likely to find most of the bugs you really care about. For concurrent algorithms, however, finding those bugs through software testing is extremely unlikely; an Amazon paper on TLA+ usage[0] details a bug found which required a 35-step trace to reproduce. Given the speed of computers today, it's only a matter of time before these bugs are hit and your system implodes in a confusing and impossible-to-reproduce way. Software testing by itself just isn't good enough anymore.

[0] [http://research.microsoft.com/en- us/um/people/lamport/tla/am...](http://research.microsoft.com/en- us/um/people/lamport/tla/amazon.html)

</comment><comment><USER8> My personal gripe is the dual fight between segmenting out our domain abstraction along with our concurrency abstractions.

That is, what makes your domain most understandable is not necessarily what makes it most amenable to concurrency. Indeed, it may be directly opposed to this.

This is particularly obnoxious in models where folks try to have a single Foo object that is used everywhere anything representing even part of a Foo is used.

</comment><comment><USER9> Answer: Because you're not using Erlang/Elixir.

This sounds flippant, but it's not. The erlang BEAM VM is the only system designed to do concurrency correctly. Unfortunately, I think that many people think that concurrency can be done in a library, or on non-concurrent systems like the JVM. I understand fully why Go would like to claim to be concurrent, and all the other languages would like to claim it, because the reality is we're in a multi-core multi-node distributed world. But don't fall for it.

Worse, there are some simple low hanging "concurrent" fruit like go-routines that make it seem like you've solved the problem.

I would have no problem if someone had made a language and VM or compiled-to- binary like go, that was truly concurrent, and that copied the erlang solution (no mutable state, supervision trees, let it fail, etc.)

Seriously, steal from the best if you're making a new language.

So far, nobody has. And since we live in a multi-node, multi-CPU world, you really should learn erlang (or elixir- which adds some features and has an easier syntax).

Seriously, I know it's much easier to go with flavor-of-the-month and pretend that there is no downside. But sooner or later-- hopefully sooner, because it will be much more painful later-- you have to pay the piper for not being concurrent. We've seen massive failures and re-architecting of systems as a result-- twitter survived years of fail whales because of their poor initial engineering. Can you count on enough VC money to do the same?

PS- not to pick on Go. Go has several features that are really bright choices. I am just using it as an example here, but I've heard of everything up to and including node.js being claimed as making erlang unnecessary.

<comment><USER10> > The erlang BEAM VM is the only system designed to do concurrency correctly.

That's a fairly bold claim. Erlang is good at the actor model. It's not an all-around winner in concurrency.

Another shining example is the Glasgow Haskell Compiler runtime system. It has an exceptionally fast and efficient green thread system that (in the latest version of GHC) can scale almost-linearly up to 32 cores, even with some resource contention, and can easily handle millions of concurrent threads. I suspect you could emulate Erlang actors with very little loss of efficiency. (And, of course, you're also free to use a thread-based model.)

And being a language with type-system-encapsulated mutability (and very nice resource contention management mechanisms like STM), concurrency is often "free" and very safe. An example of how concurrency is "free":

        main = do
            forkIO (putStrLn "thing1")
            forkIO (putStrLn "thing2")
            threadDelay 1000

Anything that is IO typed can get free concurrency like this. I need make no change to my putStrLn code: as long as it returns IO, I can use it concurrently.

A few interesting things to look at:

[http://benchmarksgame.alioth.debian.org/u32/performance.php?...](http://benchmarksgame.alioth.debian.org/u32/performance.php?test=threadring)

[http://haskell.cs.yale.edu/wp- content/uploads/2013/08/hask03...](http://haskell.cs.yale.edu/wp- content/uploads/2013/08/hask035-voellmy.pdf)

edit: Added thread delay so code example works out of the box.

<comment><USER11> Not a user of Haskell but interested in it.

What makes my spider-sense tingle in Haskell is lazyness. It's all cool until you unexpectedly hit that lazy unroll (not sure what the correct term is) in a time-critical system.

Are there ways to control lazyness in Haskell, just like there are ways to control mutable state?

<comment><USER10> Laziness is just the default (and most likely to terminate) evaluation strategy.

You can use a number of techniques (the simplest being Bang Patterns) to enforce non-lazy evaluation strategies (including strict evaluation, parallel evaluation, sequential evaluation, etc.).

However, there are _very_ few activities where Haskell's laziness will cause disruptive timing variations. Any language that you might use instead of Haskell is probably heavily heap-oriented, and likely garbage collected, which means that you're already dealing with unpredictable timing variance.

</comment></comment></comment></comment><comment><USER12> Concurrent programming is hard because:

1\. Reasoning about systems with multiple concurrent series of events which can interact with eachother is harder than reasoning about a single, serial chain of events, and

2\. For a long time most programming environments (languages and libraries) -- and this is still true of many that are still widely used -- have only rudimentary support for concurrency.

Progress in language facilities and libraries is mitigating #2, but #1 is fairly fundamental.

<comment><USER13> Agreed. All the talk about language constructs and better abstractions ignores the reality that reasoning about time is one of the hardest things that humans can do. It is one of our most fragile abilities, and we routinely fail to do it correctly when thinking about a single temporal sequence much less multiple temporal sequences interacting with each other.

No languages nor tools will ever entirely fix this. The promoters of Erlang and Haskell in this discussion are optimists. I'm particularly amused by the notion that Haskell threads only yield on memory allocation, which is the worst kind of imperative programming heuristic, forcing the programmer to worry a great deal about the ordered sequence of operations and the way in which it will change the state of the system in exactly the way Haskell is supposed to not to.

I don't think this is a fault in Haskell: it is just a pragmatic language designer bowing to the inevitable (although I'd argue that having the potential to yield as a side-effect of allocation is a sub-optimal choice for a side-effect-free language... I presume there must be an explicit instruction also that permits a yield to take place?)

<comment><USER12> Strictly speaking, the issue of Haskell threads only being preempted on memory allocation isn't a "language designer bowing to the inevitable", since its not a language feature, its a feature of the GHC implementation of Concurrent Haskell [1] (you have to have some heuristic like this if you are using green threads, but there's no reason Concurrent Haskell _couldn 't_ be implemented with native threads, but M:N green threads have advantages in practice, even with pathological cases that rarely occur in real programs.)

> although I'd argue that having the potential to yield as a side-effect of > allocation is a sub-optimal choice for a side-effect-free language...

Preemption isn't a side-effect in the sense in which Haskell is side-effect free even in the single-threaded case, since timing isn't guaranteed to start with (and, particularly, a single-threaded Haskell program can be preempted by the host OS at any time, based on any heuristic applied by the host OS, and for any amount of time), and to extent that preemption effects semantics, it only effects the semantics of things like IO actions which are _not_ , by design, side-effect.

> I presume there must be an explicit instruction also that permits a yield to > take place?

Yes, Concurrent Haskell includes an explicit yield.

[1] [https://hackage.haskell.org/package/base-220.127.116.11/docs/Contro...](https://hackage.haskell.org/package/base-18.104.22.168/docs/Control- Concurrent.html)

</comment></comment></comment><comment><USER14> We have a great, widely used, highly successful model to handle concurrency. Processes and pipes! It has been used for over 40 years, and it is the base of UNIX. Why do we look for something else? I don't know.

</comment><comment><USER15> Because concurrency in imperative languages is generally a euphemism for non- determinism.

Now the problem can be correctly rephrased as:

Why is it hard to get non-deterministic programs to do deterministic things.</comment>


Ask HN: Do you read book reviews? What do you look for in a good one? - <AUTHOR> <comment><USER2> The biggest mistake non-professional book reviewers make is summarizing a book instead of reviewing it.

A good book review is not a summary. It's a discussion of what is good and bad about the book. (Just as a good product review is not a description of the product and its features. It's an assessment of in what ways the product succeeded or failed at achieving the user's goals.)

A good book review should leave the reader with a clear sense of who will and won't enjoy (in the case of fiction) or get value from (in the case of non- fiction) the book in question.</comment>


The Story of an American Inventor Denied a Patent Because He Was a Slave - <AUTHOR> https://paleofuture.gizmodo.com/the-story-of-the-american-inventor-denied-a-patent-beca-1828329907 <comment><USER2> The other day a poster criticized A16Z's Cultural Leadership Fund targeting African American entrepreneurs because a majority of the LPs were of the entertainment business (athletes, musicians, actors). I've seen this criticism of the black community many times: "Why are all your icons in entertainment? Why not scientists, engineers, etc.?" Well, this one story helps to illustrate why. This guy was obviously talented enough to influence steamboat design but could not capitalize on his work by getting a patent because of institutional racism. Imagine what his life would have been like if he got this patent? Maybe he would've started an engineering firm, maybe he would've gone on to study at a formal college or teach? Who knows what influence he may have had?

The opposite to this story is that for many reasons, including the fact that white elites liked to view black artists as entertainment, many successful black people in the 19th & 20th centuries had to make their way out through entertainment or sports. When you have a history of segregated schools (PS. they are still segregated), school values tied to home prices, and other factors, its not hard to see why there are not as many intellectual African Americans at the forefront of American society.

<comment><USER3> > maybe he would've gone on to study at a formal college or teach?

Seems unlikely as he would have been fairly busy running his plantation and being the local JP. He was pretty successful, at least for the next 10 years, so it's not clear that a patent for a minor improvement to propeller design would have affected his life significantly.

> there are not as many intellectual African Americans at the forefront of > American society

Are there not? I don't get the impression that this is true in fields such as history and the social sciences but I could be mistaken.</comment></comment>


Ask HN: How can I use my web development skills for space exploration/tech? - <AUTHOR> I'd like to work as part of the space exploration industry, at least in some way to contribute however I can. I don't have a scientific or engineering background in the professional sense, but I have programming experience, mostly in web development. I'm more interested in getting a job in it, than participate in open source projects. How can I apply these skills to join a company that is doing work related to space exploration and its related technology?<p>Edit: I want to add that web development is not the only kind of programming that I do. But this is what I've done for 90% of my work. <comment><USER2> You can come work for us at Blue Origin! My team members do a lot of web development and we're recruiting heavily right now. We hire everyone as Software Engineers, but there are a variety of specializations people come in with and focus on -- web development included.

[https://www.blueorigin.com/careers](https://www.blueorigin.com/careers)

<comment><AUTHOR> That's pretty great to hear. I'd like to know what your web development team is doing for the purposes of your company. Incidentally I have been been through the hiring process with Bezos' more familiar company before. What is the hiring process like on the technical level at your company?

<comment><USER2> The web development that happens is typically for:

* Systems that analyze flight or test data

* Systems that enable manufacturing, supply chain, or other supporting business activities

* Systems that are considered to be "customer experience" related

* Infrastructure systems that support the other software engineering teams

Our hiring process is straightforward. The dev teams review resumes for a fit based on experience and skillset. Next comes a phone screen where we'll ask a series of basic programming questions. If you're in the Seattle area we skip the phone screen and invite you in for a tour and ask you the same questions in-person. Next we do a full interview, which occurs on-site at our headquarters and typically lasts most of the day. You'll interview with multiple software engineers from different teams. The questions you get asked will be deeply technical and are usually real world problems we have had to solve.

<comment><AUTHOR> Most of my more recent experience has been in web agencies, and SaaS. For SaaS in particular CPQ software to help business clients quote product prices for many arbitrary configurations. I don't have as much experience with infrastructure in the large scale, however. I also had a short contract job as a game developer so maybe that can be useful for applications that require real-time performance.

I live in the Midwest. I know that with Amazon they had offered me a paid round-trip flight from my city to go to their final round interview. I declined only for personal things to handle at the time. If I ever get to that point with Blue Origin, would that company be able to do the same?

<comment><USER2> Absolutely, we pay for travel expenses to come interview with us.

</comment></comment></comment></comment></comment><comment><USER3> Feel free to check the SatNOGS ([https://satnogs.org](https://satnogs.org)) project. It is a satellite open ground station network coordinated via the web. Especially as a web developer you might be interested in the SatNOGS Network [https://network.satnogs.org](https://network.satnogs.org) and the SatNOGS Database [https://db.satnogs.org](https://db.satnogs.org) sub projects Lots of documentation of the project can be found at [https://wiki.satnogs.org](https://wiki.satnogs.org) and an active community forum at [https://community.libre.space/c/satnogs](https://community.libre.space/c/satnogs)

</comment><comment><USER4> I wonder, in ten or twenty years, how many rocket scientists will have been inspired to that calling by spending way too much time fooling around constructing rockets to try to escape Kerbin's atmosphere?

<comment><USER5> at least 1 i hope

</comment></comment><comment><USER6> Spacecraft generate tons of telemetry that needs to be ingested, normalized, and visualized -- there's room for web dev in this space (no pun intended).

I spent some time working for a company that builds imaging satellites. My role was working on the UI team, building real-time telemetry monitoring and alerting software using web technologies for ground control. It was definitely one of the more interesting places I've worked at.

<comment><AUTHOR> That's one of the areas that I've considered or entertained about, interpreting telemetry data, visualizing it, or even delivering it in real time. I am not as familiar with satellite companies as I am with companies that create launch systems. Do you know of any that would be good to look for?

As an aside, I would probably need relocation assistance, and that would be a desirable point to have for a company.

<comment><USER6> You could check out DigitalGlobe, Planet Labs, etc. You can also look at companies that take data from the satellite mfgs/operators and repackage it for customers such as Orbital Insight.

</comment></comment></comment><comment><USER7> I built [http://www.asterank.com/](http://www.asterank.com/) and still maintain it after its acquisition by Planetary Resources. It is open source and its code has been used in a surprising number of space-related projects. If you're interested in getting involved, you might help modify the Asterank engine to be a better general-purpose framework for 3D space visualizations. This would benefit the space community as a whole by making the project a lot easier to adapt for commercial and educational purposes. Code: [https://github.com/typpo/asterank](https://github.com/typpo/asterank)

I'm also on an open-source NASA grant where we're implementing web-based asteroid data analysis tools. It's a bit earlier stage but still room to get involved. Code: [https://github.com/typpo/astrokit](https://github.com/typpo/astrokit)

Email me (email@example.com) if you want to talk about either of these!

<comment><AUTHOR> Hey typpo, data visualization and space exploration sounds like a great combo for me!

I will email you shortly. Your website is pretty great I think has lots of potential. I have experience programming in 3D graphics too, and have tried to find another project for use in the web.

</comment></comment><comment><USER8> All NASA centers have a need for web front-end designers and data visualization interfaces. [source: I work at JPL]. Feel free to apply, we could use you.

To "build chops" I'd suggest doing some side projects in displaying data, especially using data sources like [http://stuffin.space/](http://stuffin.space/)

<comment><AUTHOR> Would I need experience working with large scale systems to have a chance? My web experience is mostly in small startups for SaaS, and web agencies that build e-commerce sites and blogs for small-medium businesses. I have not worked on anything that gets used by the millions, or requires fine calculations. Will I be at a disadvantage?

</comment></comment><comment><USER9> I was also thinking about creating a community around this. I was thinking about creating a Slack for folks interested in the webdev + space exploration/tech scene. Anyone interested?

Afaik, this is the only thing close right now: [https://spacehack.org/](https://spacehack.org/)

<comment> 52-6F-62 I'd be interested in such a thing if that's a plan.

Maybe a Keybase group to try and avoid [purely] shitposting types, and a board for persistent posts that maybe aligns with similar rules?

<comment><USER9> [https://github.com/spacehackersclub](https://github.com/spacehackersclub)

<comment><USER9> Site is up, hosted by github pages: [http://spacehackers.club/](http://spacehackers.club/)

Would love feedback on how to organize [https://github.com/spacehackersclub/awesome- spacehackers](https://github.com/spacehackersclub/awesome-spacehackers)

Things I'd like to add * jobs section like the ones mentioned in this post? * open source projects involved in aerospace that are looking for contributors?

Would love to hear other ideas, join the keybase chat for spacehackers.

<comment><USER9> Also on Twitter if anyone wants to follow there: [https://twitter.com/spacehckrsclub](https://twitter.com/spacehckrsclub)

</comment></comment></comment></comment></comment><comment><USER9> Had a phone interview with SpaceX recently, they do have some web dev positions: [http://www.spacex.com/careers/list](http://www.spacex.com/careers/list)

<comment><AUTHOR> I remember applying to SpaceX in February, for a Full Stack Enterprise Software Engineer position, and got a rejection letter. I'm not sure what the reason for rejection could be, but it may be that I don't have enough experience with large scale systems.

</comment></comment><comment><USER10> My company (spire.com) often has a variety of software positions open depending on your level of experience. You can drop me an email (in my profile) if you're curious.

</comment><comment><USER11> I'm in a similar situation. You could look at working on your own Remote Sensing projects perhaps.

I've also plan to make something akin to Asterank, yes it is there and working, but I think it is an amazing idea and would just love to do something similar in my own way:

[http://www.asterank.com](http://www.asterank.com)

</comment><comment><USER12> I'm in basically a similar situation right now and I'm honestly wondering if going back to school for a more engineering focused degree would be the best move.

Does anybody know how a Software+Aerospace engineer would be valued at an aerospace company? Most job listings I find are basically one or the other.

<comment><USER10> There's a few areas that these would overlap in, like ADCS and AOCS. That said, I wouldnt call both necessarily mandatory to work in that space, more often you find people who have gone deep in one and picked up enough of the other to contribute.

Software engineers (in my personal experience hiring), especially senior ones, are harder to find and hire than aerospace engineers today. Depending on an area of focus, you can be just as involved with key decisions in the spacecraft design as a software person.

Feel free to drop me a line, I'd be happy to talk for a few minutes about your experience and what you want to do and give you what insight I have into the industry.

<comment><USER12> >Depending on an area of focus, you can be just as involved with key decisions in the spacecraft design as a software person.

This is really interesting to me and I'd love to hear more. While it seems obvious that spacecraft rely heavily on software I've been under the impression that much of that work is done by aerospace/avionics engineers and is more driven by the hardware teams and hardware requirements (which is all fascinating to me but I am stumped on how I would transition into a career focusing on that). What sort of areas of focus are you thinking of?

I think I'll drop you a line to chat, thank you for offering!

</comment></comment></comment><comment><USER13> Below is an excerpt from something I posted in 2003 to an Slashdot article on "Jeff Bezos' Shot At Space": [https://science.slashdot.org/comments.pl?sid=62113&cid=58211...](https://science.slashdot.org/comments.pl?sid=62113&cid=5821178)

While it is excellent to see multiple billionaires pursuing cheap access to space (CATS), this seems like a problem that will be much easier to solve as new materials and processes come along (diamondoid jet nozzles, fusion, etc.) in the near future. Several of these entrepreneurs are of course already using newer materials and processes (composites, active dynamics, small ground crews augmented by fancy computers and software) relative to what NASA is stuck with in maintaining an aging Shuttle. While I would never say such innovative effort is wasted, it would seem that launch technologies, while sexy, might really deserve somewhat lower priorities than the issue of what to do when we are in space. The fact is, we can launch people now, and relatively off-the- shelf technology (e.g. Ariane or Saturn V equivalent rockets) if manufactured in large quantities are probably Cheap-enough Access To Space for the next ten to twenty years (until nano-tech makes far better launch systems possible) especially if we are willing to accept 5% human casualties for launch (which is probably a far lower casualty rate than most human settlement travel activities historically).

There is also an issue of focus -- people focus on reusable vehicles, but the reality is that it is so costly to get things into space that there is not much point in returning either people or equipment after they have been launched. At best, Apollo era reentry capsules for people who want to come back to earth are good enough. For example, the space shuttle costs so much to launch relative to its production cost it should really be left in orbit as usable equipment (since anything in orbit is worth its weight in gold), and people returned in a small capsule if at all. Even if launch costs are greatly reduced, I think that a general outward trend of humanity will still reflect some of this economics (short of a space elevator). For example, in the USA, most people who went "West" during the 1800s probably never came back East.

So where is a key area of research that should be a priority among NASA and Billionaires, but is not heavily pursued? The issue is what to do in space once you have gotten there. Because if there is a reason to be in space, then people and collectives will work to get there. And the reality is, that right now, if we could get there, there is nothing to do there short of look around and come back. And if that were the case, Space would not deserve much more investment than say tourism to Mt. Everest. The reality is that we don't know how to support human life in space -- in large part because we have only spent a pittance on thinking about that issue systematically compared to the issues of CATS and Planetary Exploration. Frankly, while we support human life on earth, we have very little meta-knowledge formally about how to do even that. And, most of figuring out how to support human life in space at a nuts and bolts level requires non-sexy activities like sitting around and staring out the window, talking, sending emails, building databases, building software tools, building some small physical prototypes on tabletops and outdoors, and just plain thinking (the hard stuff). This is all the preparation needed for the spiritual voyage into the (physical) heavens. Biosphere II was an excellent start in some ways, although the science mission was a bit dodgy at first and it seems Columbia (the recipient) seems about to abandon that effort for cost reasons --- and in any case, Biosphere II focuses on the wrong question -- we know biospheres can work and replicate (although scale is an issue) -- what we don't know is how to replicate the mechanical infrastructure (e.g. glass pane making machinery) behind them. A lot more money has gone into studying ecosystem food webs than industrial ecologies of pipe webs and assembly line webs (and frankly, a lot of people don't want their "proprietary" manufacturing processes studied or gossiped about by academics.)

Almost everything proposed as a reason to launch into space doesn't make sense, as much as people have touted various suggestions. The closest might be He3 mining for aneutronic fusion if we otherwise had that technology, but even that issues (energy) is probably more easily solved through conservation, energy efficiency (e.g. R60+ home insulation), and photovoltaic and wind etc. alternate energy modes (which are rapidly proving cost effective for many applications, and will be only more so with new processes and materials over the next twenty years). Asteroid mining turns out to not be that useful, since recycling is a much better idea. Zero gravity turns out to not be so valuable after all for manufacturing, since most of the processes can be done on earth, or alternative materials used. And so on for various other issues.

Exploration is noble and important as a long-term spiritual quest, but it is a dubious priority in the short term considering how much ground based telescopes can do quickly on earth, how valuable cheap robot probes are, and how we are already slaughtering the other terrestrial intelligences (Muslims, Aborigines, elephants) and extraterrestrial intelligences (whales, octopods, etc.) we know of without much concern or attempt to communicate and pursue any sort of cosmic brotherhood.

The only really sensible thing to do in space is to live there under various social and technical systems. People like Freeman Dyson, Gerard K. O'Neill, and Marshall T. Savage and many others have discussed these issues. We aren't able to pursue this because we don't know much about how to support human life on earth. We have little understanding of the Comprehensive Anticipatory Design Science Buckminster Fuller proposed back in the 1930s or so. Economics is a multi-trillion dollar joke, with economists having about zero knowledge on how technical economies really work or develop (otherwise, why have no developing nations left that category in one hundred years?) We need to better understand how life is supported on earth both biologically and technically so that we can replicate it out there, and so we can then use asteroid resources, sunlight, and empty space to support quadrillions of conscious souls pursuing diverse ends in some sorts of diverse collaborations (such as J.D. Bernal proposed in the 1920s). [See also NASA dreams under Carter: [http://www.islandone.org/MMSG/aasm/](http://www.islandone.org/MMSG/aasm/) ]

As a bonus, once some people live in space, mine asteroids for their own purposes, capture solar energy for their own purposes, use self-replicating manufacturing systems for their own purposes, then CATS really becomes CATE (Cheap Access To Earth) and for spacers who might be 1000X more wealthy than groundhogs in terms of materials and energy and innovation and cooperation, CATE would be easy, and CATS then piggybacks as a slight imbalance in CATE tourism (although why most spacers would want to go anywhere near a gravity well would probably be a deep psychological question with profound moral overtones like "spacer's burden" and all that rot).

So, while it is great to see all these billionaires pursuing CATS, it would be great to see more people pursuing DOGS (Design Of Great Settlements). Since NASA is stuck running an obsolete space ferry it has little attention left over for DOGS. Since Billionaries are doing the sexy CATS stuff, that leaves the rest of us to go to the DOGS.

And disclaimer: DOGS is essentially what I am working on with the Pointrel Foundation and related activities, but unlike Jeff Bezos (a sort-of classmate from Princeton -- Hi Jeff!) what I am working on with just my own spare time (not being a billionaire, and frankly, realizing even a billion bucks is not even a bone to throw to the DOGS) is how that issue of what to do if we got into space could be pursued the same way Debian GNU/Linux is pursued. And, I find, when you pursue such a space settlement design science in the right spirit, the work is also immediately applicable on Earth as sustainable technology (such as our garden simulator -- intended to help people grow food wherever in the cosmos they live). My wife and I published a paper on how an open source / free software collaboration style approaches could be used to make DOGS happen in the 2001 Space Studies Institute symposium on Space Manufacturing and Space Settlement. ... The OSCOMAK site [http://www.kurtz- fernhout.com/oscomak/](http://www.kurtz-fernhout.com/oscomak/) is a much earlier vision along these lines [and includes a link to that 2001 paper]...

<comment><USER9> Mmmm, very interesting points to think about. The priority of space exploration is always a topic that comes up. Although I don't think I've heard the argument for focusing on DOGS (Design of Great Settlements). :) DOGS vs CATS, ha!

I think what I'm trying to do with [https://spacehackers.club](https://spacehackers.club) is to get more folks interested in hardware/software problem-solving in the context of what may be pervasive in the coming decades, which is increasing the human reach into the solar system.

Your post here has me thinking about how I might categorize things on this list: [https://github.com/spacehackersclub/awesome- spacehackers](https://github.com/spacehackersclub/awesome-spacehackers)

Maybe more DOGS related resources? Would love contributions and further discussion about what focus should be.

<comment><USER13> Thanks. A couple resources to maybe add:

[http://www.islandone.org/MMSG/aasm/](http://www.islandone.org/MMSG/aasm/)

[http://www.slate.com/articles/technology/future_tense/2017/1...](http://www.slate.com/articles/technology/future_tense/2017/12/space_isn_t_a_void_it_s_a_canvas_for_human_imagination.html) (Discussed here: [https://science.slashdot.org/story/17/12/14/1639204/space- is...](https://science.slashdot.org/story/17/12/14/1639204/space-is-not-a- void) )

Definitely would encourage you to keep going with this to form a supportive community of interested people.

Some ideas on making groups work well that I've collected (often easier said then done): [https://github.com/pdfernhout/High-Performance- Organizations...](https://github.com/pdfernhout/High-Performance- Organizations-Reading-List)

A group I was involved in from 2008: [http://www.openvirgle.net/](http://www.openvirgle.net/)

I had some other links here (an archive of the OpenVigle wiki from 2008) but some are out-of-date: [http://oscomak.net/wiki/Main_Page](http://oscomak.net/wiki/Main_Page)

Another group maybe of interest (but no recent posts): [https://en.wikipedia.org/wiki/OpenLuna](https://en.wikipedia.org/wiki/OpenLuna)

I'd encourage you to explore links with the maker movement. That is sort of what became of the 2008 OpenVirgle effort -- at that time, it seemed to make more sense to think about the early maker movement and "Open Manufacturing" because increasing that capacity was a big win for everyone in both the short- term on Earth and long term in space. [http://openmanufacturing.net/](http://openmanufacturing.net/) [https://groups.google.com/forum/#!forum/openmanufacturing](https://groups.google.com/forum/#!forum/openmanufacturing)</comment></comment></comment>


Sequoia's Jim Goetz: Shocking More Startups Are Not Building For The Enterprise - <AUTHOR> http://techcrunch.com/2012/09/12/sequoias-jim-goetz-shocking-more-startups-are-not-building-for-the-enterprise/ <comment><USER2> I've been on the other end of the enterprise purchasing process for tech products and services many times and given my experiences as oftentimes the only technical person involved a fundamentally broken process, I would not recommend that anyone go into producing enterprise technology solutions with the exception of those products that solve problems impervious to bikeshedding.

You want to solve problems that business people are capable of understanding are problems that are worth solving, but which are sufficiently complex enough that the business side of things has no other option than to defer the decision to purchase or not to those within the enterprise that are technologically competent. If bikeshedding can occur in the purchasing process and that is not a pleasant process to deal with.

If you're willing to put up with bullshit, then there is money to be made, but then again many entrepreneurs left a career in entreprise because they were sick of dealing with those problems.

</comment><comment><USER3> Enterprise is boring and has terrible deficiencies such as a long decision cycle and a heavy dependency on salesmanship.

<comment><USER4> Also, arguably unlike social media, it requires domain expertise that many potential founders do not have.

<comment><USER3> That's a great point. You can't really consider addressing enterprise needs until you've done a tour of duty in the cube farm gulag.

</comment></comment></comment><comment><USER5> Makes plenty of sense to me.

If you actually sit down and think of it from a entrepreneur point of view as opposed to a corporate point of view, it's pretty clear that more often than not, the risk proposition is just not worth it, and the odds are already stacked against you as an entrepreneur without bringing the enterprise into the equation.

</comment><comment><USER6> I agree with geoffschmidt - domain expertise is difficult to acquire if you don't work in a large company and understand where the pain points are. Sales cycles are always going to be a hassle though and a fundamentally different skill set to acquire than building the tech.</comment>


Sequoia's "RIP Good Times" presentation (on SlideShare) - <AUTHOR> http://www.slideshare.net/eldon/sequoia-capital-on-startups-and-the-economic-downturn-presentation

<comment><USER2> Duplicate of the one just above?

<comment><USER3> I can see this one better. I have FireFox 3.0.1</comment></comment>