Which Programming Languages Are Functional? - <AUTHOR> http://blog.jenkster.com/2015/12/which-programming-languages-are-functional.html <comment><USER2> Erlang currently is probably the most practically used functional language. It has been in production for decades. It manages probably 50% of world's smartphone <-> internet traffic. There are many database built on it, message processing backends, handles hundreds of millions of connected device (WhatsApp).

Yet most people forget it about when talking about "functional", and end up comparing Python to Haskell basically. Maybe with F# thrown in there for good measure.

Erlang has solid closure support, tail call elimination, immutable data structures and variables, encourages using recursion instead of for loops, in practice folds/maps are common constructs instead of an oddity etc (like say in Python).

It even has an optional success typing system:

[http://learnyousomeerlang.com/dialyzer](http://learnyousomeerlang.com/dialyzer)

EDIT: Elixir is using Erlang's VM as well and almost everything about language features above apply to it. If you don't want to give Erlang a try, check out Elixir. It also has one of the friendliest communities for new-comers.

<comment><USER3> It's weird, I always kind of wondered why Erlang gets left out of the FP discussions. It's not as dogmatic as Haskell or something, but functional-ness is kind of its bread and butter.

<comment><USER2> I think the answer is that Erlang's creators are not academics and they sort of never went out of their way to tout functional properties of their language. Functional properties fell out of their requirements for simplicity, fault tolerance, concurrency and reliability. In other words the goal of Erlang was never to be functional but to be useful for fault tolerant distributed systems.

Someone down the line probably mentioned to them "Hey, btw, did you know you have a functional language?" And they probably shrugged and said "Oh, cool!"

I would guess Joe, Robert or Mike never went about reading papers on type theory, thinking about meta-circular evaluators, or y combinators etc and said "We need that, let's implement it!". Instead, they started with stuff like "let's minimize state" so made state explicitly passed in. "Let's minimize mutable state", so make data immutable. So then need recursion instead of for loops, so let's think about tail call elimination. They played with Prolog so language inherited the base Prolog syntax which has a functional taste to it, that helped as well.

The same thing kind of happened with the actor paradigm. They never started with a goal of implemented an actor / message passing programming paradigm. It just fell out of fault isolation property. Someone later told them "Oh btw, did you know you have implemented the actor paradigm?" and they probably shrugged and said "Oh, cool!" and went back to doing whatever they were doing.

<comment><USER4> I've talked with Robert at some length and listened to his talk on LFE, and that's more or less the way of it, plus Robert himself was an old Lisp buff from way back (hence Lisp-flavored Erlang). It was basically a combination of "this is what we need to do what we want" and occasionally bits of "well of course you do it that way".

That was actually how he described tail call elimination in his LFE talk: "of course you have TCE/O, why the hell wouldn't you?"

Which was a refreshing perspective to me, considering how many programmers _still_ seem to have been heavily indoctrinated to the idea that recursion is automatically bad.

</comment></comment></comment></comment><comment><USER5> I'm not sure if I like this definition of "functional". Don't get me wrong, I'm a Haskell guy and think Haskell is fantastic for production use, but this definition of "functional" almost seems to rule out everything except Haskell. Even if I try to maximize my Haskell fanboyism I can't with a straight face choose a definition for "functional programming language" that of the today's production-viable languages only includes Haskell. A definition that narrow just isn't very useful. I don't have super strong opinions about how it should be defined, but I tend to be drawn towards a more fuzzy definition. One that seems attractive is: "functional programming languages are languages that focus on functions as the basic unit of abstraction".

<comment><USER6> > I'm a Haskell guy

Don't ever be a 'programming language 'x' guy or girl'. Be yourself, know some tools and skills and be prepared to switch those out for whatever works best in that particular application. If you limit yourself to a certain programming language, no matter how great it seems to be today you've built in your own obsolescence.

Better to be a guy or a girl with x years of Haskell experience and a whole bunch of other stuff besides.

<comment><USER7> On the one hand I think that's reading too much into the phrase "Haskell guy", but on the other I disagree in the sense that being a dilettante is no good either. I think people should be "T-shaped", deep on one to a few languages/platforms and some experience with many others. Spending a long time with one language/platform will teach you deeper lessons over time than switching every 6 months.

</comment></comment></comment><comment><USER8> But why would you want a "functional programming" language when you can have a modern multiparadigm language (JavaScript 6, Swift, Java 8, C#)?

The author seems to believe that no side effects is the key property of a functional language. But for me most problems I deal with (user interface, various business domains, integration with other systems over network etc.) are filled with state and procedures. Sure you can deal with that in a purely functional way but to me it is a bit like doing object-orientated programming in C with macros and a lot of conventions. Why not simply use a programming language with suitable primitives? In particular now that multiparadigm languages are the most widely used in our industry.

<comment><USER9> The value of functional programming is not in what it brings, it's in what it takes away.

It is easier to reason about functional programs because they maintain certain properties. These could be types, an absence of side effect, etc. This is the point of the entire article.

You get none of those benefits if your "multi paradigm" language allows you to break those guarantees.

For a multi paradigm language to derive benefits from functional programming, it should allow developers to explicitly write guarantees that can be enforced at compile time. This is a promising direction but, to my knowledge, it's not available in any of the languages you mentioned.

<comment><USER10> I think this is exactly it.

If you had a multi-paradigm language, you'd need not only just some way to break the rules easily and have that bubble up, you'd also want this rule- breaking behavior to be exposed up the chain from any libraries. You'd also have to enforce the benefits of immutability and such through social pressure in order for users to see large parts of the benefits of side-effect isolation.

A lot of the choices FP languages make that are less about side-effects (like strict typing systems) are also often an all-or-none proposition. Optional typing systems have very limited benefits if libraries aren't well-typed. The static analyzers can only do so much.

<comment><USER11> Oh, they can do surprisingly much. See how Erlang works with its optional typespecs and dialyzer.

</comment></comment></comment></comment><comment><USER12> Why not just call the post: "Which Programming Languages are Pure?". What's the point of redefining Functional Programming in a way that is at best controversial?

<comment><USER13> A language can be purely functional, purely object-oriented, purely garbage- collected, ...

The sole specifier 'pure' is meaningless without context...

</comment></comment><comment><USER14> Maybe I'm missing something, but what does implicit "this" arguments have to do with functional programming?

> public String getName() { return this.name; }

> How would we purify this call? Well, this is the hidden input, so all we > have to do is lift it up to an argument:

> public String getName(Person this) { return this.name; }

> Now getName is a pure function.

Isn't that just syntactic sugar? I would say that a real functional programming language enforces that functions cannot have side effects, not just that you have the ability to write such functions.

<comment><USER15> How is it syntactic sugar? In the second version the function is now accessing an argument rather than something outside its scope. That's pretty much the definition of a pure function (besides having no side effects).

<comment><USER14> I would agree if getName was accessing a global variable but I don't see how getName(person) is any more functional than person.getName(). OCaml features objects with similar syntax for example: [http://caml.inria.fr/pub/docs/manual- ocaml/objectexamples.ht...](http://caml.inria.fr/pub/docs/manual- ocaml/objectexamples.html)

<comment><USER15> Because you can write person.getName() like this:

def getName():

. . this.setName('foo')

. . return this.name

There's nothing in principle preventing you from doing that in the "functional" approach but if your data is immutable then you can't do it.

<comment><USER16>
      def getName(person):
        person.setName('foo')
        return person.name

The problem, from a functional viewpoint, isn't the implicit argument, it is the fact that you can write _setName_.

<comment><USER15> Really? I thought implicit arguments were a strict no-no in functional programming.

<comment><USER16> Implicit arguments are still arguments. It is just syntactic sugar, and I think syntax changes cannot change a functional language into a non-functional one.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> Friendly reminder that all programming languages are just tools and it's not productive to get worked up about which one is better than others or which arbitrary label makes them more valuable.

Except PHP. PHP still sucks.

<comment><USER18> I half agree. A hammer and a screwdriver are both just tools, but they're good at different things. It's good to know about the variety of available tools and the sorts of tasks they're good at.

<comment><USER17> Sure, but in many situations the tool you already have and understand trumps the theoretically better suited tool you have to pick up at the hardware shop and train your team to use.

The logical extreme would otherwise be to switch to a new tool whenever one comes out that is objectively better at a given task and retrain every team member that was previously using the old tool and rewrite the code that relies on the old tool to use the new tool.

This balance is called pragmatism and it's more important in the real world than the objective quality of tools you don't already have in your toolbelt.

</comment></comment></comment><comment><USER19> Standard reminder: please remember OCaml and F#.

OCaml may be a little obscure in the mainstream programming community, but there are a ton of folks using F# out there.

<comment><USER20> There are a ton of folks using f# out there? Would be nice to hear about them.

<comment><USER19> Some testimonials: [http://fsharp.org/testimonials/](http://fsharp.org/testimonials/)

Don't have time to do the full internet report for you, but if you're interested, the way to tell is simply google various programming problems with F# instead of C#.

Five years ago you could mostly find C# code and convert in your head. Now about 80% of the time you can find what you're looking for in F#. That's a ton of people.

</comment></comment></comment><comment><USER15> Its worth mentioning Elm when talking about making Javascript functional. To me Elm is like the fun sibling in the Haskell family.

Signals are way easier to understand (for me personally) than monads. I just wish it had better Javascript interop. Making ports for everything to talk to an existing API (like three.js) is a deal breaker.

<comment><USER21> I feel the same way about Elm. I am curious regarding your comment about ports though. I will admit, I haven't used ports for connecting with three.js, but I have used them to tie in with existing Javascript code during our conversion process and I thought they were pretty nice. What makes the combination of three.js and Elm ports a problem. Is it just the number of them you have to write, or is there some other pain point?

<comment><USER15> Yea essentially its a matter of scale. three.js is not a small library by any means and I'm using a lot of the features. I tries to use:[https://github.com/seliopou/elm-d3](https://github.com/seliopou/elm-d3)

as my guide. I think it just comes down to "I don't have time to rewrite bindings for an entire API right now" because ports require you to really understand what's going on. There's no shotgun method of converting an entire API.

Another reason I gave up is that Purescript does have three.js bindings.

<comment><USER21> Yeah, that makes sense. Thank you for the information.

</comment></comment></comment></comment><comment><USER22> "Functional" is just a word, and I don't think it's particularly helpful to declare "language X is not functional". map/reduce, lambda, types, and control of effects are all valuable, and no single one absolutely characterizes functional vs. not.

</comment><comment><USER23> Hmm I've always felt the true nature of FP is having higher order functions. That's what starts to make things fun. If you need a long keyword to introduce a lambda, or if partially applying and passing functions around is ugly then you lose a lot of the benefits and cannot truly embrace HOFs. In a typed language, no generics or other type limitations puts a major cramp on this too.

Yeah this means C function pointers allow some FP. Except they're clunky and have a hard time bundling info with them (no closures). This makes HOFs sort of a pain.

Controlling state, or at least immutability, is just a generally good idea. Even in rather non-FP code I wish I had easy immutability.

</comment><comment><USER24> I take issue with the critique of Java not being functional. Old style Java uses mutable objects and yes code is not functional. However, it is now (a good) standard) practice to make immutable objects.

</comment><comment><USER25> IMO the essence of programming is the definition of abstract interfaces and the composition of components within a context according to those interfaces. The essence of _functional_ programming is the composition of components that create their results without modifying their execution context in any way that could be detected by a failure of referential transparency.

With that definition, functional programming is a style, not a class of languages. An assembly routine that computes a cosine is a functional program. I typically write C/C++ code in a functional style, constructing and returning new data structures rather than modifying arguments in place, because it's so much easier to test, use in parallel code, and reuse later.

So I don't think that strong typing, higher kinds, higher order functions, algebraic types, pattern matching, anonymous closures, polymorphism, or garbage collection, e.g., are necessary to functional programming (although they're all wonderful and Haskell seems to have collected just the right mix of features together into a language that I love using whenever I can). It's about whether or not your components have interfaces that are like mathematical functions.

</comment><comment><USER26> > [Perl] has a magic argument, $_, which means something like, "the return > value of the previous call".

What?!

<comment><USER27> I don't know whether you recognize this as wrong, or are surprised at the thought of such a thing (which doesn't actually exist like that).

In any case, i've suggested a correction here: [http://blog.jenkster.com/2015/12/which-programming- languages...](http://blog.jenkster.com/2015/12/which-programming-languages- are-functional.html#comment-2432154798)

<comment><USER28> $_ isn't really global though:

        perl -e 'for (1,2,3,4) { for (5,6) { print "  $_\n" } print "$_\n" }'

<comment><USER27> It may look like it is not in loop constructs, but it is. `for` and friends just apply `local` scoping to `$_` internally.

</comment></comment></comment></comment><comment><USER29> > Lisp is the oldest functional programming language, and the oldest dynamic > language.

But Lisp is not a functional language! It's based on the concept of CONS which is mutable and allows for shared structure. Lisp is #1 language that everyone thinks is functional when it's actually not. I'm surprised this article out of all made this mistake.

<comment><USER30> Well, Lisp is based on the Lambda calculus, which is what we've come to know as the basis for functional programming. Things are much more overtly functional when you look at certain members of the Lisp family such as Scheme.

</comment></comment><comment><USER31> Would Scheme count as a functional programming language by this definition?

On one hand, the idiomatic emphasis on tail calls (supported by tail call optimization in the language) makes it easy to avoid stateful for and while loops.

On the other hand, most nontrivial code has plenty of `set!`s.

<comment><USER30> Scheme is a multi-paradigm programming language. Functional is one such paradigm that it supports. It also supports imperative, object-oriented, relational, and probably others that I don't even know about.

In Scheme, one can build functional systems on top of imperative building blocks. For example, memoization can be implemented as a higher-order procedure that uses a mutable hash table as the cache. A memoized function is still pure, despite the use of local state, because it retains the crucial property of referential transparency.

Anyway, I guess my point is that the use of 'set!' or 'hash-table-set!' or whatever else doesn't mean that a program is no longer using the functional paradigm. To quote from a Clojure web page[0], "if a pure function mutates some local data in order to produce an immutable return value, is that ok?"

[0] [http://clojure.org/transients](http://clojure.org/transients)

</comment></comment><comment><USER32> I can find points I disagree with on every language here, but this author seems to have quite the bias against Java, so I'll make a few counterarguments.

"If you write Java code that has no side-effects, that doesn't read or change the local object's state, you'll be called a Bad Programmer."

No you won't.

"Java thinks that localised side-effects are cornerstone of good code"

Java doesn't think anything. It's a tool.

"Unfortunately, in practice Java doesn't just try to encapsulate side-effects; it mandates them"

No, it doesn't.

I will say I've worked in Java shops and seen the language used in this way. I've also worked in Java shops and seen people who have read and internalized the messages in Effective Java, especially with regard to handling state, and the codebase looked nothing like what is described in this article. I recommend the author take some time to read that book and keep reminding himself that Java is a generalized tool that can be used in many ways.

</comment><comment><USER33> All the ones that aren't dysfunctional.

<comment><USER34> Argh. _One second_ after clicking downvote, I got the joke...

<comment><USER33> Jerk :-p</comment></comment></comment>


Ask HN: Your take on The best way to predict the future is to create it,for 2030 - <AUTHOR> <comment><USER2> Step 1: Watch Alan Kay's talks at Stanford: How to Invent the Future I - CS183F (2 parts, 2 hours)

Step 2: Realize that in the last 40-50 years there hasn't been many huge revolutionary inventions/ideas like those in computing. Sure we have made things smaller and faster computationally but those are just iterations on a foundational thing that already existed.

Step 3: Try to create something like PARC: gather a lot of bright minds together from different fields in a research setting. Fully fund them for 5 years (maybe this is step 2a - get $50-100 million together).</comment>


Geocoder.ca sued by Canada Post for their open database of postal codes - <AUTHOR> http://geocoder.ca/?sued=1 <comment><USER5> Things are changing. Technology is cheaper, internet is prevalent and small organizations disrupt the ways of the dinosaurs. We've seen that with newspapers, we are seeing that with Hollywood and we'll soon see it in education. The dinosaurs are big and powerful, but we all know what happens to them eventually. Sooner or later technology wins. Always.

Having said that I hope Geocoder gets help with PR. I'm no PR expert but the fact that this post is not on their front page is the first bad sign. And the media, which always loves a David & Goliath story, apparently hasn't covered this; that's another bad sign. Swaying public opinion to your side is the way to win this, not litigation. If Geocoder lets Canada Post drag them to court they've already lost.

As a Canadian I'm one of the owners of Canada Post and I hope I lose.

<comment><USER6> Canada Post is pretty stupid on this one. Even if you type a postal code into Google Maps you get a result.

I could imagine how old and stupid the gov't official is who filed that claim. Canada's a broke country, and the latest government budget has cut a tonne of government jobs, slashed R&D credits, etc.

<comment><USER7> _Canada's a broke country_

On what basis do you make that claim?

<comment><USER8> I think the (ignorant) right wing in the States assumes that Canada has its early 1990s fiscal problems because it is has lots of successful social programs that would considered leftist down here. Idiots.

<comment><USER9> Based on the level of detail mentioned in the OP, it's pretty clear the author is Canadian.

<comment><USER10> ...of whom some 39 percent voted for a Conservative candidate in the last election. The blinkered Sun Media worldview is alive and well here in Canada, and even if it doesn't represent a majority opinion, our first-past-the-post electoral system means it can carve out a majority in the House of Commons and form the government.

<comment><USER11> As that system has done with six exceptions since confederation (Laurier in 1900 and 1904, Borden in 1917, Mackenzie King in 1940, Diefenbaker in 1958, Mulroney in 1984). In fact ruling parties having over 50% of the votes in Canadian election is the exception rather then the rule.

The only way to make sure the general populace vote = ruling party is to have an American style two party system, and frankly, I've heard very few good things about that. IMO Canada has a decent balance; parties on the fringe either adapt or assimilate, and all parties gravitate to the political centre if they want success. It saves having two powerful parties for long, and prevents the dog breakfest of some countries where there's 15 different names on the ballot.

<comment><USER10> > The only way to make sure the general populace vote = ruling party is to > have an American style two party system

I offer as counterexamples all the industrialized liberal democracies with various forms of proportional representation, in which the composition of the government actually does reflect the general populace vote. They may not be countries in which a single party forms the government, but there's no reason a single party has to form the government, particularly if no party receives more than 50% support among electors.

I have a lot of respect for the parliamentary system, in which voters elect the House of Commons, the House appoints a Prime Minister, the Prime Minister appoints a Cabinet, the PM and Cabinet are accountable to the House. I appreciate that this system has historically included parties, or formal associations among members of the House of Commons to vote more or less along party lines.

However, the parliamentary system also has a long tradition of coalitions among parties, and even of governments being formed by parties that did not win a majority of seats. The basic unit of legitimacy for a parliamentary government is that _the government enjoys the confidence of the House_.

I was really frustrated during the 2008-2009 constitutional crisis over the widespread public ignorance over how the parliamentary system works. It's frighteningly clear that most Canadians don't understand their own government, which makes the system a ripe target for abuse. Since the 1970s, Canadian ruling parties have steadily concentrated power more narrowly in the PMO, to the point that Canadians have forgotten that they vote for the House, not for the Government.

As a result, governments have increasingly snubbed their nose at the House of Commons - to the extent that the Harper government actually deployed a handbook for disrupting and marginalizing parliamentary committees and absolutely refused to share budget numbers with MPs, triggering an election over their Contempt of Parliament.

During the constitutional crisis, and following the lead of the Conservative Party, far too many Canadians argued with straight faces that a government appointed by a coalition of parties representing more than half the seats in the House and more than half the votes cast would be somehow anti-democratic, while an appointed government that refused to face a confidence vote - <USER2> most fundamental litmus test of legitimacy in a parliamentary system - <USER3> somehow upholding democracy.

We can no longer afford a system in which a single party with a minority of votes can enjoy a majority of seats and more-or-less absolute power to pass legislation during its term in control of the government. You write, "all parties gravitate to the political centre if they want success", but the current government is busy passing one-sided ideological legislation - <USER4> the omnibus crime bill and the new copyright bill - that most Canadians oppose.

If they held seats proportional to their popular support, they would have to cooperate with another party to achieve majority support in the House and we would see more balanced legislation.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><AUTHOR> I came across this while researching postal code data. I was first shocked to learn that this data set wasn't freely available from Canada Post ($5,000/year to access it), then pleased to find geocoder.ca's data set, and then pissed to learn they were being sued for it.

So far there has been absolutely no media attention on this.

<comment><USER11> Which sadly isnt' surprising. The combination of it being something that would only affect a small group of people (basically anyone in the IT industry building location-aware applications), and the media's ADD-like ability to concentrate on issues will keep it from ever seeing the light of day.

I don't know what this government has against the tech industry in this country, but it must be some serious loathing with all the BS coming down the pipes

<comment><AUTHOR> This goes back a long way. Amazing amounts of GIS data for the U.S. was available from tonnes of vendors sliced and diced in all sorts of interesting way on a CD-ROMs for < $100 way back in 1996. Canada, not so much. $3,000-15,000 for similar data. Because StatsCan and other organizations were selling it to big corporations who could pay that price tag... the result of that policy? Google maps could never have started in Canada.

<comment><USER12> It's not _too_ bad these days, though. I'm involved with a Candadian company doing GIS, and finding free layers getting easier.

E.g. <http://www.geogratis.ca> has a massive amount of freely available data for Canada.

There are some ridiculous bits, though, such as being unable to get the Alberta Township grid, which is a necessity for a lot of property related stuff, without paying.

</comment></comment></comment></comment><comment><USER13> For those curious, the US government releases geocoded zip codes openly:

<http://www.census.gov/tiger/tms/gazetteer/zips.txt>

<comment><USER14> Do you know how accurate that is? Every time I've seen census zip code data it comes with a big disclaimer that its only accurate as of the last census. The USPS changes zip codes at will.

<comment><USER15> TIGER is the Census geo data set. This is "zip code tabulation areas," not strict zip codes. The Census does update its maps more frequently than every 10 years though.

</comment></comment></comment><comment><USER16> How can this data not be public domain?

<comment><USER17> Canada law is weird. They have "Crown copyright". As for Canada Post, they are required to make money, and are not required to not exploit publicly funded dataset like the postal code database. This is called monopoly.

<comment><USER18> _Canada law is weird. They have "Crown copyright"_

I don't know about Canada, but the UK has 'crown copyright', and it's essentially the same as regular copyright, but the copyright is owned by the government. Places without a crown still have governments that have copyright.

There some weird things, The King James Bible, the Book of Common Prayer, and the Peter Pan stories are under perpetual unending copyright. (Well Peter Pan will go public domain when the Great Ormond Street Children's Hospital ceases to exist)

<comment><USER17> US law mandate that data created by the tax payer money, ie the government, be Public Domain.

</comment></comment></comment></comment><comment><USER19> So what are the Canadian copyright laws like? I was under the impression that you can't copyright facts.

<comment><USER11> Depends on how you interpret it. You are correct in that you can't coyright facts, but I'm sure the lawyers that Canada Post has hired will argue that since Canada Post created/authored the postal codes, it has ownership of that data and therefore can be copyrighted. The rest is just a combo of spin and waiting for the sued parties to be bled dry.

If a country that is more capitalist and copyright mad then we are has no issue providing postal data, that our crown corporation has their panties in a twist is a cruel joke. Just adds another reason why I'd never use Canada Post for anything anyways.

<comment><USER20> The other question is whether the postal code data falls under Crown Copyright ([http://publications.gc.ca/site/eng/ccl/aboutCrownCopyright.h...](http://publications.gc.ca/site/eng/ccl/aboutCrownCopyright.html)). There all all kinds of restrictions and freedoms that come along with that.

Of course, it might not be the case that Canada Post data is under Crown Copyright, since it's a Crown corporation and not a government department. IANAL.

</comment></comment></comment><comment><USER21> Is there a link to the C&D or the court case details? I'm sure we can agree that helping people with zipcode data for free is laudable, but reading only one half of an argument isn't a good way to make decisions.

</comment><comment><USER22> They charge $500 for their data set. An easy way to combat this litigation would be to release the set gratis. Let the information flow.

<comment><USER17> 5000$. Missing a zero.

<comment><USER22> As has been pointed out, I was referring to Geocoder's rates. I had the same confusion though. The request for donations certainly makes it seem like they are beneficent, but they are themselves selling the data. Not that that's legally or morally wrong (certainly not) - it's just a different position to be in.

<comment><AUTHOR> They are only selling it if you want it without the ODb licence. I.e. you don't want to share-alike or attribute.

Seems perfectly reasonable to me.

</comment></comment></comment></comment><comment><USER23> i guess somebody should put their database on bittorrent pretty quick

my cousin works in PR for canada post. i emailed him to get the scoop. will post here when i do.

</comment><comment><USER24> The issue with these postcode databases is that once they're released to a customer there's no real way of tracking if they get reused elsewhere. The contract I had with the Royal Mail in the UK mandated destruction of all media and backups of the database once the contract period expired. As we know, getting individual tables out of old DB backups isn't necessarily easy but that's what the terms state. It's easy to see why they do that because it's not really a complicated "product" and very easy to duplicate.

That said, Canada Post should have tried to talk before litigation as all this does is make a crown organisation look like a bully in front of Canadians and now the world.

</comment><comment><USER25> I wouldn't worry about this getting anywhere. And if it does, I'm pretty sure the current gov't will smack Canada Post silly as retaliation.

</comment><comment><USER26> I'm likely speaking from the wrong culture, but the phrasing "You haven't made it until you get sued" on their home page sounds like Geocoder are attempting to spin a bit of a complement for themselves rather than going for the image of a David being bullied by a Goliath.

I hope I'm write in suggesting that such a phrasing may not the best way of getting support.

</comment><comment><USER27> This has strong echoes of the Astrolabe/Olson case, only is possibly even more nutty, somewhat better funded and a hell of a lot less excusable on the part of Canada Post.

Legally it should be a walk for Geocoder, but I wouldn't like to make a wager on it.</comment>


Watch an elephant 'count' simply by using its sense of smell - <AUTHOR> https://www.sciencemag.org/news/2019/06/watch-elephant-count-simply-using-its-sense-smell?rss=1 <comment><USER2> The beauty of having such a long "nose" :-)</comment>


Low-carb diet may make you unhealthy, shorten your life - <AUTHOR> http://www.abc.net.au/news/2014-03-05/low-carb-diet-may-shorten-your-life-study-finds/5299284 <comment><USER2> If you are a mouse.

<comment><USER3> right, most people are pigs

I'm a dog and only eat bone marrow...</comment></comment>


Earth's magnetic pole is on the move, fast - <AUTHOR> https://www.news.com.au/technology/science/earths-magnetic-pole-is-on-the-move-fast-and-we-dont-know-why/news-story/341c92307a6b19d25b38836c6097be9d <comment><USER2> This is normal..

"There have been 183 reversals over the last 83 million years. The latest, the Brunhes–Matuyama reversal, occurred 780,000 years ago, and may have happened very quickly, within a human lifetime."

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

</comment><comment><USER3> The HAB Theory by Allen W Eckert !

</comment><comment><USER4> I think it's interesting that the speed-up coincides with the proliferation of personal computers and the internet. Imagine all the magnetic moments generated by every electronic device on the planet. I wonder where the magnetic poles will end up?

<comment><USER5> I don't know enough to have an informed opinion but I'd have thought all the electronics on earth would still be an order of magnitude to small to have an impact on something as massive as the earths rotating core.</comment></comment>


Nobody has to be vile - <AUTHOR> http://www.lrb.co.uk/v28/n07/slavoj-zizek/nobody-has-to-be-vile <comment><USER2> (2006)</comment>


FCC Commissioner to China: 'Could you un-disappear them so we could speak?' - <AUTHOR> https://www.theblaze.com/news/fcc-commissioner-twitter-thread-china-undisappear <comment><USER2> Brendan Carr's tweet referred to a nypost article[1] which referred to a 60 minutes Australia tweet[2] claiming Dr. Ai Fen is missing. I've read news from other sources that eventually linked to [2] but no other supporting facts. Is there any substantial evidence anywhere that Ai Fen is actually missing? Or is there no reporter on the ground who can confirm if that's the case?

Let's look at her weibo: [https://www.weibo.com/u/2662574464?is_all=1](https://www.weibo.com/u/2662574464?is_all=1)

The cryptic message on March 29th was accompanied with a picture of Wuhan, and the message itself described the geographic features of this city. Any Mandarin speaker won't find it that cryptic.

On April 10th she posted a picture of her and a retired teacher coming to Wuhan for volunteering.

So.. is it so easy to report fake news about China because people love to hate China and most official Chinese statements/sources are in Mandarin so not many English speakers can verify?

1\. [https://nypost.com/2020/04/01/whistleblowing-coronavirus- doc...](https://nypost.com/2020/04/01/whistleblowing-coronavirus-doctor- mysteriously-vanishes/)

2\. [https://twitter.com/60Mins/status/1244211674439016449](https://twitter.com/60Mins/status/1244211674439016449)</comment>


Personal observations on the reliability of the Shuttle – R.P. Feynman - <AUTHOR> http://www.ranum.com/security/computer_security/editorials/dumb/feynman.html <comment><USER2> > It appears that there are enormous differences of opinion as to the > probability of a failure with loss of vehicle and of human life. The > estimates range from roughly 1 in 100 to 1 in 100,000. The higher figures > come from the working engineers, and the very low figures from management.

Am in business with someone many years older than me. It has always struck me how little tolerance he has for risks to my safety. The natural reaction is to have more lenience for situations that wont directly impact your personal safety. Wheras this guy will do potentially dangerous tasks that would otherwise be my responsibility. His kids are grown up, mine are young.

It is the kind of attitude that would be near impossible to enshrine in a larger organisation (like NASA) but refreshing to see all the same.

</comment><comment><USER3> Feynman argues for unit tests:

> For example, cracks have been found in the turbine blades of the high > pressure oxygen turbopump. Are they caused by flaws in the material, the > effect of the oxygen atmosphere on the properties of the material, the > thermal stresses of startup or shutdown, the vibration and stresses of > steady running, or mainly at some resonance at certain speeds, etc.? How > long can we run from crack initiation to crack failure, and how does this > depend on power level? Using the completed engine as a test bed to resolve > such questions is extremely expensive. One does not wish to lose an entire > engine in order to find out where and how failure occurs. Yet, an accurate > knowledge of this information is essential to acquire a confidence in the > engine reliability in use. Without detailed understanding, confidence can > not be attained.

<comment><USER4> > Feynman argues for unit tests

I'm not sure that would be my takeaway from that quote. In the analogy of Unit testing, the test would have found the cracks in the turbine blades. It seems to me that Feynman continuously argues for deep investigation into any problems encountered, rather than (seemingly) ignoring them or making up excuses for why they're not problems.

He regards independent code verifications and testing highly, it seems:

> The software is checked very carefully in a bottom-up fashion. First, each > new line of code is checked, then sections of code or modules with special > functions are verified. The scope is increased step by step until the new > changes are incorporated into a complete system and checked. This complete > output is considered the final product, newly released. But completely > independently there is an independent verification group, that takes an > adversary attitude to the software development group, and tests and verifies > the software as if it were a customer of the delivered product. There is > additional verification in using the new programs in simulators, etc. A > discovery of an error during verification testing is considered very > serious, and its origin studied very carefully to avoid such mistakes in the > future.

I'd consider this quote a clear argument for unit testing though:

> There is additional verification in using the new programs in simulators, > etc.

In the end, it seems to come down to the simple concept of: spending more time on verifying code results in better code. Whether it is through automated testing, code reviews, independent (and competent) user acceptance testing, etc.</comment></comment>


Ask HN: Any US based company interested in an EE/CS Bachelor for free?  - <AUTHOR>

TL;DR: My friend is searching for a US-based company to write his master's thesis. You do NOT have to pay him a single dime. He will be available from 4/1/13 to 8/31/13 to work in the US. He has all the required permits to enter and work in the US. - you need to be US-based
- no payment towards him - five months total - he's really good - DEADLINE to get in contact with him: 2/24/13 23:59 UTC +0100
Details:
He was already interviewed and selected by a well-known company in the FPGA-industry based in San Jose, CA. He is a student at the University of the German Armed Forces in Munich (Germany) and studies Applied Computer Technologies (A mixture of Electrical Engineering and Computer Science).
He is among the five best students in class.<p>His main fields of interest are FPGA- and Microcontroller-programming. He is 25 years old and an officer in the German Armed Forces.
However, due to legal concerns on the companies part, the gig fell apart at the last minute. The company was concerned about him NOT getting any payment (legal concerns about minimum wages in CA).
If you are interested please write an email to firstname.lastname@example.com - DEADLINE to get in contact with him: 2/24/13 23:59 UTC +0100 <comment><AUTHOR> FAQs: (more readable version here: <http://pastebin.com/Y6QzCEpc>)

What is in it for me?

Get a very good Bachelor of Engineering for free. He'll be working five months for you, you pay him nothing.

What's the catch here?

The biggest points seem to be: a) you are NOT allowed to make any payments towards him b) you will have to sign a cooperation treaty with the Bundeswehr (German Armed Forces) - you can get an english translation of the treaty upon request c) He is not allowed to sign any contracts with your company. You will have to accept the cooperation treaty :-(

Why doesn't he want money?

Because he is an officer in the German Armed Forces and already gets a full pay. He is simple not allowed to receive payments

Who will pay for this?

The Bundeswehr will pay for his expenses (air travel, lodging, food)

When will he be able to work?

The time frame is 4/1/13 to 8/31/13. He will be able to stay in the US for a total of 5 month

Does he have full legal rights to enter/work in the US?

Absolutely. He will enter the US with a military ID and a NATO travel order. While in the US, he will not work for you. He is still employed by the Bundeswehr and is just an "external employee" at your company. This procedure has been done about a dozen times in the past two years and is covered by NATO-status of forces agreements. For more information: [http://germany.usembassy.gov/visa/niv/visacategories/diploma...](http://germany.usembassy.gov/visa/niv/visacategories/diplomatic/) (scroll down about 80%)

Why do you ask on HN ?

Because the previous agreement with another company fell through and he's running out of time/options.

What projects are suitable for the thesis ?

Anything in the following realms: \- FPGA programming \- Microcontroller programming \- Mixed hardware/software development projects

The perfect project should be reasonably challenging (i.e. worthy of writing a master's thesis about the topic) and ideally be self-contained (so he can work on it all on his one - with supervision of course)

Where can I get a hold of him / Where can I get the cooperation treaty ?

Write an email to email@example.com \- DEADLINE to get in contact with him: 2/24/13 23:59 UTC +0100

<comment><USER2> _you will have to sign a cooperation treaty with the Bundeswehr (German Armed Forces)_

Can a U.S. corporation legally sign a _treaty_ with a foreign military?

<comment><AUTHOR> That is an excellent question. Thanks for asking it. !!!I am not a lawyer!!!

The contract reads:

"The Federal Republic of Germany, represented by the Federal Ministry of Defense, the latter represented by The Bundeswehr University, Munich 85577 Neubiberg" (yada-yada-yada)

The contract is between a U.S. corporation and the federal government. It has to be legal, because the German Army uses some American Weaponry (e.g. the M82 sniper rifle).

And as stated in the FAQ: This has been done before - numerous times.

<comment><USER3> I think that the GP is calling attention do the word "treaty" versus "contract".

<comment><AUTHOR> Oh... I see. Thanks for pointing that out.

That's just a wrong translation. Sorry for that. The German word is "Vertrag" - which can be translated as "contract" as well as "treaty".

EDIT 1: I'll update the FAQ regarding this.

EDIT 2: Then again... I won't, because I am no longer able to :-)</comment></comment></comment></comment></comment>


Ask HN: Implementing stuff, learning new things.Depth first or breadth first? - <AUTHOR>

Hi HN!
I am implementing a toy project, and experimenting with Go, XML, web services and other stuff.
I reached a point where I need to do XPath stuff, and looked around the internet for documentation (XML itself, XPath/XQuery/X<things>, and Go libraries).
I have downloaded "documents", some of which are quite extensive and detailed.
So here is the dilemma: is it better to just skim the documentation on things I don't know and get things working (``get shit done'') or is it better to sit down and read most or all of the documentation?
The advantage of reading most or all of the documentation would be mastery of the topic, but the threat is to delay the implementation of my project by a lot, possibly losing interest in the project (possibly finding something else interesting).
While this may sound as a situation-specific question, I think it may be way more general, and I'd like your opinion on the topic.
Thanks in advance, -- <AUTHOR> <comment><USER2> I personally prefer looking at the relevant parts of the documentation and getting shit done.

Advantages:

1\. shit gets done 2\. concepts that you learn get applied immediately, so the concepts stick in the brain better 3\. harder to lose motivation since shit is getting done 4\. it is harder to understand certain concepts abstractly, after all we are talking about programming, not theoretical physics; most programming concepts are better understood in practice esp. web based stuff. So reading and applying immediately is most often the right way to go.

Disadvantages:

1\. there might be advanced functionality that you might miss if you skim through and apply, however most advanced functionality are optimizations and as we all know 'premature optimization is the root of all evil'. Donno who said that but it was someone famous. So this isn't a real disadvantage at all.

In summary, I would recommend a depth first approach, with the caveat that you go really deep into the things that you do need in the project and ignore the things that you don't need at the moment.</comment>


SPIR-V: Intermediate Language for Graphical Shaders and Compute Kernels [pdf] - <AUTHOR> https://www.khronos.org/registry/spir-v/papers/WhitePaper.pdf

<comment><USER2> An interesting article about it: [http://www.g-truc.net/post-0714.html](http://www.g-truc.net/post-0714.html)

I wonder in general will Apple and MS support SPIR-V or they'll play nasty and not support it just to make life harder for everyone?

Also, will Apple push Metal to OS X, or they'll support Vulkan going forward? Their support for OpenGL was very much lagging behind.

<comment><USER3> I suspect Apple's lagging OpenGL support is mainly due to their reliance on Intel GPUs and their reluctance to fragment the Mac hardware platform. They don't like it when users of their low-end or ultraportable machines complain that games won't run at any speed.

On the other hand, they _created_ OpenCL and they obviously want their developers to have access to this kind of hardware capability. Their problem now is getting developers to actually make use of it, and for that they'll have to implement SPIR-V if that's what catches on. (Provided again that _all_ of their hardware can support it.)

<comment><USER2> At least for Vulkan it seems you need Haswell and up in case of Intel (i.e. what supports OpenGL ES 3.1).

</comment></comment></comment><comment><USER4> So SPIR-V is completely unrelated to the previous attempt at a portable IR layer for compute kernels, named SPIR? This is crazy. Why is Khronos trying to be confusing?

<comment><USER3> SPIR-V is clearly intended to be the successor and replacement for SPIR, and the name seems to be different enough to allow for breaking compatibility. (By one reading, it's incrementing the major version number by 3.)</comment></comment>


Lessons learned from rewriting code - <AUTHOR> http://huseyinpolatyuruk.com/2019/02/04/lessons-learned-from-rewriting-code-in-my-10-years-as-a-developer/ <comment><USER2> "Rewriting a system from the ground up is essentially an admission of failure as a designer. It is making the statement, "We failed to design a maintainable system and so must start over." "

Or maybe the domain you are working with was vastly more complex than you imagined, so your nice little system turned out to be more of a prototype than a finished product. Or maybe the features needed was vastly different from what you expected when you started implementing the thing. I'm sure everyone can come up with a million other reasons.

But the problem I have every time with these "Never rewrite your software" stories. Is that they are almost always one-sided. You rarely hear about the stories where a company decided not to do a rewrite and was out-innovated because every little feature took months to implement. Or failed because they could not attract competent developers because their codebase was a complete mess.

Yes, the rewrite might have been a partial or complete failure. But would the patient have survived without the operation anyway?

<comment><USER3> Or maybe your customer base and system load has expanded by an order of magnitude beyond the original design.

<comment><USER4> Writing scalable software is all about being as flexible as possible. If system load expanded by an order of magnitude and the original design wasn't flexible enough to scale with the load, that's a bad software design.

<comment><USER5> A lot of people might disagree, and this is just my opinion, but if you are using object oriented programming than in 99% of all cases you are not being as flexible as possible. Tying methods to data is an inflexibility.

With sufficient complexity under OOP you will always be writing code that feels like it is poorly designed because the paradigm promotes poor design and lack of flexibility.

<comment><USER6> > Tying methods to data is an inflexibility.

Tying methods to data is an inevitability (whether it is on run- or compile- time). Can you give me an example of a function that does not depend on the data it operates on?

What makes OOP wrong is not tying methods to data, but tying data to ontologies. Limiting a function to operating on what something "is" is an artificial limitation. Limiting a function to operating on what something "has" or "can do" is a logical consequence.

<comment><USER5> >Tying methods to data is an inevitability (whether it is on run- or compile- time). Can you give me an example of a function that does not depend on the data it operates on?

I mean tying methods to data via a class. A instantiated class is a structure that has data and has methods specific to operating on said data. Either way, any function that takes void input and with any return type is an example of a function that does not depend on data, but that wasn't my point.

Note that a function is different from a method contextually speaking.

>What makes OOP wrong is not tying methods to data, but tying data to ontologies. Limiting a function to operating on what something "is" is an artificial limitation. Limiting a function to operating on what something "has" or "can do" is a logical consequence.

We may be talking about the same thing. Though I'm not sure what you mean by this: "Limiting a function to operating on what something "is" is an artificial limitation. Limiting a function to operating on what something "has" or "can do" is a logical consequence." Can you please clarify?

<comment><USER6> We might want to agree on what we mean with "OOP", since it's such an abstract term we might be talking about different things.

> Note that a function is different from a method contextually speaking.

I disagree. A method is just a function with an implicit self/this parameter. I see methods as just namespaced functions with syntactic sugar to call them with dot notation from instances.

In Rust this is particularly prominent, since they support UFCS:

        whatever_instance.method(arg1, arg2)

...and...

        Whatever::method(whatever_instance, arg1, arg2)

...do the exact same thing. Other languages are more limited in their syntax, but I don't think it's inherent to OOP.

I think I see what you mean with "contextually speaking" but I can't really see the difference neither in theory nor in practice.

> Can you please clarify?

I'll try :P Maybe with an example.

In TypeScript we can define types as "interfaces" (do not confuse with what Java calls "interface").

        interface Named {
          name: String
        }

Then you can make a function that takes Named things:

        function sayHello(named: Named) {
          alert(`Hello! My name is ${named.name}.`)
        }

My point is all functions are tied to the data they work with, whether explicitly or implicitly (via runtime errors).

This is what I mean with "has" or "can do". I couldn't care less whether that Named was instantiated as a Dog or a Person class, as long as it has a name. (Just to clarify, I don't think TS's interfaces are particularly good either, since they're tied to the actual object shape, what if my object has a field "fullName" instead?)

I agree with you if we only consider traditional OOP class-based abstraction. Modern forms of OOP on the other hand are a blessing for me.

\- Classes should be limited to creating particular object instances that group together a bunch of interfaces.

\- Class methods should only be used to manipulate that particular instance, with its particular idiosyncrasies, never as a means of abstraction. Only the class itself should know about its methods.

\- Classes expose functionality via interfaces (that internally use the class methods).

\- Therefore no function should declare an argument by class ("is"), only by interface(s)/trait(s)/whatever(s) ("has"/"can do").

Why use classes then? Mostly for the namespacing and the syntax sugar. The name "class" is probably not very fitting but it's probably hard to get rid of.

So, in essence: I think we agree on the problem but disagree on the culprit. It's not OOP. It's C++/Java/C#/etc.

> Either way, any function that takes void input and with any return type is > an example of a function that does not depend on data, but that wasn't my > point.

I was sure you were going to say this :P We can agree it's hard to write an useful program with constant pure functions.

Just for fun: I'd argue it still depends on the data it operates on... in this case, the empty set!

<comment><USER5> >Just for fun: I'd argue it still depends on the data it operates on... in this case, the empty set!

Void is not an empty set. It is void. Nothing. I am referencing the category void here. I'm not too familiar with rust but in rust this is just an empty enum.

Note that functions with parameter void can never be called because the void type can never be instantiated. You cannot instantiate nothing. This is a very theoretical concept, but I believe in rust you can actually define (not call) a function of this type.

       fn absurd<T>(x: SomeEmptyEnumType) -> Int { 1 }

It's def hard to write a useful program made up of functions that can't even be called.

>So, in essence: I think we agree on the problem but disagree on the culprit. It's not OOP. It's C++/Java/C#/etc.

Took me a bit to parse what you're saying. I get it and you're right. What is the problem with C++/Java/C#/etc?

<comment><USER6> Void is just another name for the empty set. It's not _an_ empty set, it's _the_ empty set. Since it has no members it indeed cannot be instantiated.

As a Rust library: [https://docs.rs/void/1.0.2/void/enum.Void.html](https://docs.rs/void/1.0.2/void/enum.Void.html) Notice how the empty enum is called... Void.

In Rust you have "!" (never) too, which cannot be instantiated either but coerces into any other type.

> What is the problem with C++/Java/C#/etc?

Is-a polymorphism.

<comment><USER5> Polymorphism? Aren't interfaces a formalization of polymorphism?

<comment><USER6> Notice I said "is-a" polymorphism (I should've said inheritance to avoid confusion: class Person; class Employee is-a Person; class Client is-a Person; etc.). I mean an ontology of classes.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> A pattern I've started seeing with most "bad" rewrites is that "bad" rewrites are probably usually motivated by burnout than actual architectural problems. People get tired of working on the code, and they would rather be working on something else hence "let's rewrite".

When you hear about "good" rewrites it's almost never framed in a way that is "the old code is bad and complicated." It's usually driven by an architectural need - for example it started in Python, but now we have scaled up and in order to avoid $1MM/month a rewrite in Go/Rust/C would be beneficial.

Or, in the case of changing marketing needs, it can be "we now better understand our customers and a rewrite can help us provide a more stable interface and help us iterate faster". However in this case a full 100% rewrite is never the case and it's usually done piecemeal or by the new system simply proxying requests to the old system.

When the excuse is simply the "code is a mess", then not only are you admitting that the original team failed to design a maintainable system, you are also trusting them to not make the same mistake again. And if their whole motivation is "the code is a mess", they will probably fuck up the redesign, as messy code is a symptom of bad design but not the root cause. If the root cause is burnout, and that isn't addressed, the rewrite may be just as bad.

<comment><USER8> Iterational design is a thing.

If the same team that did the crappy code gets a chance to learn from the mistakes and rewrite it part by part now when they have the whole picture, it's easier and the end result might be mantainable and nice.

<comment><USER9> I've heard that the worst code is the 2nd version. You try to fix everything from the 1st version (real or perceived) and over correct as a result.

<comment><AUTHOR> Yes, I've heard that too. But in our rewriting case, it didn't happen. We didn't make that mistake. Usually, developers made a lot of mistake in the first version and they learned many lessons. Now they are experienced about software and they will try to implement everything in the 2nd version. And they will come up with the complex system again. In our case, we cut off many features and we kept our code base small.

</comment></comment></comment></comment><comment><USER10> I've been a developer for almost 10 years and during that time, have been involved in small rewrites and major rewrites. None of them have gone well and there wasn't a single one that we didn't regret starting on. What you think is a mess of legacy code is often less messy than you think and a lot of the odd decisions were often made for very good reasons. When you rewrite a codebase, you often tend to over-engineer it for the vague goals of being "scalable" and "clean" but, while clean on the surface, it often comes out far more complicated and with the a similar number of bugs. Another way to look at it is you're taking what was previously an agile approach of iterative development and replacing it with a waterfall approach which sees a grand end goal (parity with legacy code). Software is complicated and there's no silver bullet. Adopting React over jQuery will not reduce complexity as much as you think. Adopting microservices over a monolith will not reduce complexity as much as you think. The only thing that will ever reduce complexity is careful iterative development of good abstractions which are inserted into the codebase one-at-a-time.

</comment><comment><USER11> > 1\. Are you ready to throw away all that knowledge?

This is a massive fallacy. Rewriting code does not have to throw away knowledge. The old code is a specification for the new. You just have to read it.

I've been involved in several successful rewrites and I always use the old code as a precise description of how the software is supposed to work. You have to take the time to understand it. And if you don't understand the old code, you really shouldn't be rewriting it.

<comment><USER12> The code as "precise" description: The problem is that you can't tell if that weird "if" is correctly handling a corner case, or _incorrectly_ handling a corner case, or is now a "can't happen" left behind after something else changed. _You can 't tell which from the code._

That means that tribal knowledge is crucial for a successful rewrite. And that means that you need to do the rewrite while you still have that knowledge available.

<comment><USER11> I don't agree. The code may not do precisely what was intended but it is deterministic. If you understand the language, you can understand the code.

<comment><USER12> Yes, you understand what it says. You don't know what it _should_ say, though. The code can't tell you that.

[Edit: "Better architecture, but bug-for-bug compatible" probably isn't the goal of the rewrite.]

<comment><USER11> > Better architecture, but bug-for-bug compatible" probably isn't the goal of > the rewrite.

Why not? From there you proceed to fix the old bugs.

</comment></comment></comment></comment></comment><comment><USER13> I've been involved in 3 separate rewrites in different industries, at companies of different sizes, over the course of 20+ years.

Not one of them went well.

I've also been involved in maintaining legacy code during that time.

The code sucked, and changes were slow, but it went a LOT better than the rewrites did. We actually shipped things.

<comment><USER14> I have several experiences with both bad and good rewrites.

A common pattern among the bad rewrites is that they were too late. Rewrites should be early in a project. Expect to do perhaps 2-3 rewrites at the beginning.

Another pattern is that the team was too large. To many chefs and we ended up with an incoherent mess.

The good rewrites I've done were gradual. We agreed on the target state of the code and on the intermediate stages. Perhaps you could call these "big, slow, refactoring", but they were in fact rewrites.

A couple of rewrites were so successful they changed the rules of the game entirely.

People who say rewrites are either all good or all bad are wrong every time.

<comment><USER15> I don't think anybody is opposed to rewriting modules when necessary. The discussion is around "ground up"-rewriting where the whole code base is discarded and starting again from scratch, like how Mozilla did.

You can perform a long series of refactoring so you in the end have rewritten everything. The important difference is if you in all the intermediate stages have a working program with all tests passing.

<comment><USER14> Well, to be fair, the Mozilla rewrite was a combination of runaway ambition/scope, too many cooks and too few of them Michelin class cooks. I wouldn't exactly say that the rewrite itself was the biggest problem they had.

When you look up "second system effect" there's a picture of the Mozilla logo. :)

</comment></comment></comment></comment><comment><USER16> When I hear about rewrites, I always think about this comment:

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

<comment><USER17> So true, the opportunity to leave things better than as you found them is one of the primary rewards in fixing bugs in existing/old/legacy systems.

</comment></comment><comment><USER18> Turning one piece of software into another is something which offers a spectrum of techniques which range from micro-refactors up to full rewrites. If you find yourself reaching for the full rewrite option, you should realize you have suddenly reached to the very far, far end of the spectrum of options and are basically taking an extreme viewpoint. If you haven't gamed out and really tried to rule out options across the _entire_ spectrum, you've failed -- not just because you've been negligent in terms of planning and trying to make the best choice for your organization/team, but also because if you do end up doing the rewrite, you've made a specific choice that, unlike most others, infuses a large amount of existential risk to the organization and product.

In the case of a full re-write, there really must be no other way to accomplish the goal. How many rewrites happen when there was literally no other way? Engineers seem to have a bottomless well of creativity when it comes to solving problems, but that creativity often evaporates when focused on the problem specifically of "How the hell do we get from A to B _without_ a rewrite?" No pain, no gain.

</comment><comment><USER19> Most rewrites are unjustified, either because the old code is good enough, or because the guys in charge of the rewrite cannot deliver better (whether or not the old code is good enough).

But some are.

Arthur Whitney creates each version of the K language from scratch (he is now at version 7). They are not backward compatible, but every single one so far has been better on the metrics that he cares about (succinctness, speed, and revenue).

Everyone says that the Mozilla->Firefox rewrite was unjustified, but ... the Mozilla codebase looked like a dead end to too many people working on it (from first and second hand accounts I heard), it's not clear that it was viable to continue with the old codebase -- and, even if it was, it is unclear that Mozilla would have been better off doing that: Microsoft was the unstoppable juggernaut playing dirty. IE won not based on technical merit (although it actually WAS the better one come version 4) - but arguably because it was integrated into the OS. In fact, it is quite likely that we would not have firefox today at all if they did not start the rewrite back then.

C# is essentially a rewrite of Java; done for legal reasons rather than technical reasons, but IMO the result is a much better technical solution than trying to retrofit and comply with the (legal) legacy of Java.

But ... yes, most rewrites are unjustified and often end in failure.

</comment><comment><USER20> As a general rule you shouldn't rewrite everything from scratch. This does not mean that you shouldn't, on occasion, rewrite some parts of your system. Rewrites are expensive. On the other hand some code you think is bad really is bad, and it will be a net win to rewrite it.

To make a call like this, you really do need a pretty good understanding of your codebase, your business, your testing exposure, the capabilities of your team, and probably some other stuff as well. In reality, your understanding is never going to be as good as you really need it. This doesn't mean you should never rewrite any portion of your codebase, it just means that you really need to reduce the scope a lot to reduce the risk to a manageable amount.

<comment><USER21> At my last job all I ever did was rewrite software from scratch. Sometimes the technical debt has led you beyond a point of being able to continue using the solution you have. For example Flash (soon to be ditched by mainstream browsers!) and Silverlight (no longer supported on modern browsers), and heck Java on frontend as well. I rewrote an entire Silverlight application to HTML5 and JS for the frontend and the backend with ASP .NET Core.

Then I also rewrote a Java servlet that I never directly touched the codebase for but I was told you needed a special VM just to get it to compile, I rewrote it in Python using CherryPy. Sometimes the technical debt is not worth keeping around. I sure could of modernized the Java but Pythons a lot more approachable to the rest of the team and anybody can understand what is going on at a simple glance. I can run Python on Ubuntu without a hassle since its out of the box (our main OS in that office).

</comment></comment><comment><USER22> Am I the only one who will do an initial "proof of concept" implementation of something that I intend to rewrite in another language? E.g. I will write the "first draft" in Python or Racket because I know the language won't get in my way, and then if it needs to be redone in a lower level language or something that I'm less familiar with, then I have a reference implementation to compare it with.

The same concept can even apply without switching languages if you just want a "naive" version that you know is correct.

</comment><comment><USER14> 1) Rewriting code is rarely, as the phrase suggests, about doing all the work over. Usually it is about restructuring the architecture and then adapting the old code gradually.

2) Throwing away code is not the same as throwing away knowledge. Provided that you didn't lose the entire team, the knowledge is still there. The code is just the corpse of knowledge and it is worth just a fraction of what the team that wrote the code is.

A rewrite is a good opportunity to revisit and review that knowledge.

3) With experience you learn to balance two forces: perfection and pragmatism. You should strive for perfection in everything you do, but you have to demand of yourself that you can release in a reasonable amount of time.

4) Every good software project I've been on has viewed the code as something temporary. This forces you to think about how you will replace every bit of the code as you write it. From this, workable architecture emerges unless you succumb to perfectionism.

From your description your CTO's instincts were right, but he might be missing the backbone to put you in your place.

Your team needs a more experienced lead developer to help you guys mature as developers. And you need to pay less attention to articles and blogs, be less worried about what others think and ready to learn from someone more experienced. That's going to be hard since we programmers tend to have huge egos. Even when we're inexperienced.

</comment><comment><USER23> Rewrites, as opposed to refactors, are warranted when they address fundamental architectural limitations that hinder product success. There is a notable exception for cases where the software architecture effectively _is_ the product and customers rely on observable behaviors good or bad e.g. RDBMS. Poor design is not the only source of architectural problems and it is not always avoidable; maintaining unused flexibility and optionality in architectures is often extremely expensive.

In my experience, few companies rewrite systems with legitimate architecture issues. It is vastly cheaper in the short-term to redefine the business in terms of those limitations, which is what most actually do in these cases. The risk to this strategy, which I've seen manifest many times, is that a competitor without these limitations can change the expectations of the market and thereby render your product obsolete in surprisingly short order.

Rewrites are always extremely expensive, along many dimensions, but they are also sometimes unavoidable and can lead to much greater product success than without. It is much more complex than the mere state of your code base. The calculus for whether or not it is worth it doesn't lend itself to simple analysis.

</comment><comment><USER24> I never really got the reason for doing this

        var condn = ...;
        if (condn) {
            return true;
        }
        return false;

<comment><USER25> Because it gives you the opportunity to descriptively name the expression, sparing others from parsing it mentally.

<comment><USER26> Storing the result of a Boolean expression isn't the strange part. Storing it in a well-named variable can make the code a lot easier to read; the name (hopefully) communicates intent, and it can separate a conditional action into separate steps.

The strange part is testing Boolean value... to return the same value as Boolean constants.

Why wasn't the Boolean result simply returned directly?

        var condn = ...;
        return condn;

The if statement isn't necessary. Even if you wanted to explicitly return only "true" or "false" \- using the if statement to convert truthy and falsy results into true booleans - using double not operators removes q potentially mispredicted branch.

        var condn = ...;
        return !!condn;

<comment><USER25> Ah, sorry, I completely failed to realize that was the question being asked. :)

</comment></comment></comment></comment><comment><USER27> He lost me at the very beginning due to clumsy handling of boolean values.

</comment><comment><USER28> I've been through successful rewrites. I think rewrites make sense when your product has scaled very fast with 50x more engineers or 50x more demands on it, so the context in what was made doesn't make sense anymore. You need a faster language, a stricter architecture and code discipline to deal with +100 engineers working on one product vs the previous 3, etc.

Rewrites in that case is more like your old wooden 4 story office is too small, so now you need to build a skyscraper out of steel and concrete. While the steel concrete structure is being built, you still keep an maintain your old office since it's running your business, and you have the budget to simultaneously maintain both. Steel structures require different building techniques than your wooden one.

That kind of hyper scaling is really rare outside of SF venture capital companies, so in most cases, you shouldn't do rewrites.

<comment><USER29> It's also possible that things that grow 50x tend to be newer, meaning less gradual accretion of cruft in the code. Being newer also means more remaining institutional knowledge in the organization about the technology.

For 50x growth, the new thing we are thinking of rewriting probably also has some simple core purpose (like some kind of social network), making it easier to grok the existing code and indeed to rewrite it.

By contrast a decrepit old payroll system will not have the growth dynamic, and will not be at all simple to rewrite - the code will be packed with small fixes and strange little features that are actually critically important, and that it would be disastrous to omit in a rewrite.

These tie in with your last point.

</comment></comment><comment><USER30> I was the main programmer on a web application with 250k lines of code; it handled a single very complex product selection/configuration process. The time came to expand it to handle multiple products in the same family of products.

We ended up, over six months, doing a complete rewrite that, from the outside, looked like refactoring (meaning, from the user's/product owner's perspective, the old stuff continued to work as we wrote the new stuff beside it, switching over as we went).

We launched on time and on budget. My last week was a death march but that was it. There was now only 50k LOC. Where the previous version was tightly coupled to the product specification, we now had an engine that could perform the same selection/configuration process for any product that could be articulated in the new DSL we'd developed; as a bonus, the specifications were standalone modules so we could use them in completely separate web apps.

The whole time we were aware that we were breaking the 'never rewrite' rules spelled out by Spolsky and others, but we were successful, the codebase took a huge leap forward both in speed of development and maintainability, and a subsequent project to add another set of products took half the time that was estimated.

I don't know what we did right, exactly, except perhaps that our rewrite was never about burnout or annoyance at the existing codebase; our decisions along the way were always justified by what we had to deliver and a reasonable feeling of an experienced dev that refactoring the old code would take more effort than starting over.

I'm not sure I buy the articles rejection of the rewrite they did, because he frames it entirely in terms of delay in updating and adding features, without seeming to consider that this was just legitimate technical debt that they had to pay off. The old code got them into a position where they could rewrite it. How many startups fail because their attempts to get it right the first time prevent them from ever launching and getting the customers that will pay to fix it later?

</comment><comment><USER31> > Consider refactoring before taking a step to code rewriting:

Refactoring is only an option for anything but a trivial code base if a suite of automated tests have already been written.

The article makes no mention of tests. I suspect the reason is that there were none. Refactoring would most likely have been impossible until an automated test suite had been written.

Many developers are confused about the purpose of an automated test suite. It's not to make your designs better. It's to allow you to refactor the spaghetti that will inevitably arise.

<comment><AUTHOR> The article is not about refactoring. It's about rewriting the software. So that's why I didn't mention about refactoring in details. Automated testing is part of the refactoring. You will change a small amount of code then run tests to see it works as expected. This is how refactoring works. No need to mention abou that.

</comment></comment><comment><USER32> I'm pretty sure I know the exact product being described. It is Anti-Malware by Malwarebytes.

Being a customer for many years, I saw the downward trend and it corresponds to that described in the article, both chronologically and by meaning.

P.S. I can add up a lot to this story from a customer's point of view. Let me know if you are interested, I will continue in a comment below.

<comment><USER33> Yes please!

</comment></comment><comment><USER34> My favorite strategy for code reuse is, make API configurable. That means instead of coding, you configure the system as much as possible.

Only the core , which is the implementation details could be changed without affect the rest of system.

One benefit/downside is that, whenever you change the core, or everything else works at the same time, or all thing breaks.

</comment><comment><USER35> > Consider refactoring before taking a step to code rewriting

There's got to be a Ship of Theseus argument here, where over the course of time you refactor the whole thing until none of the original code remains. I guess the difference between that and a rewrite is that after each refactor you should still be able to ship it.

</comment><comment><USER36> Wow, I kinda work in a legacy (3-4 years old), not very easy codebase, where new releases affect other parts and bring new bugs, but I cannot imagine the state of yours. Not being able to do an update?

<comment><USER37> How can a 3-4 year old codebase be legacy? That's not a lot of time for the platform or technologies it uses to become crusty and obsolete.

<comment><USER38> In the book Working Effectively With Legacy Code the author defines "legacy" as "code without tests".

<comment><USER37> That's not really a popular or even useful definition. According to that author, a Go microservice I wrote yesterday would be legacy code, while a 25 year old Turbo Pascal scientific instrumentation program running on MS-DOS, which some poor soul still has to maintain is not, because the programmers wrote a few tests for it back in the day?

<comment><USER15> Correct, because the Turbo Pascal program can be safely modified and extended. If the need arises you can port it to a more modern environment. Code without any tests can't be modified without risk of unexpected breakage, so it is basically legacy the moment it is written.

<comment><USER37> Having tests is not a panacea. There's no guarantee that any of the tests are automatically well-written - they could be too narrow in scope, overly brittle, or be so numerous that each minor change requires hours of automated testing, making progress a huge chore.

That's not to say you can even run, let alone compile some legacy code without a large amount of effort. That's the whole point of the term, that they rely on obsolete, unsupported or just ancient OS, hardware or platform, often requiring emulation, special development environment.

Redefining it to mean "code without tests" just confuses things.

<comment><USER15> To me "legacy" means when you are _stuck_ with something outdated. Code is not legacy just because it is old, it is legacy if it can't be adapted to changing requirements. For example old mainframe systems where the source code has been lost.

Code can be brand new and on the most fashionable platform, but if it is undocumented and unmaintainable and the original developer is unavailable - then you have legacy code. Because you are stuck with it and can't keep it updated.

If on the other hand the Turbo Pascal program runs fine and you have test coverage which allows you to refactor and adapt to changing requirements - what is the problem? And if you want to port to a more modern environment or platform you can do that with low risk.

Of course tests can be badly written, that goes without saying. Nothing is a panacea - not even microservices in Go!

</comment></comment></comment></comment></comment></comment></comment><comment><USER39> I recommend reading about Domain Driven Design. For example reading the book: Implementing Domain-Driven Design by Vaughn Vernon

</comment><comment><USER40> Also consider how much time you'd lose by not forking a well-designed, open source codebase.

</comment><comment><USER27> Joel Spolsky wrote a classic piece about Netscape's rewrite in 2000 [1], the article links to it too.

[1] [https://www.joelonsoftware.com/2000/04/06/things-you- should-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never- do-part-i/)

<comment><USER41> This is referenced in the article.

</comment></comment><comment><USER42> > our CTO was handling everything about AntiMalware. He was the main > developer...

There's (one) of your problems. Your CTO (just like managers) should not be coding, they should be defining and leading the technical strategy of the company.

<comment><USER43> If you happen to be part of a two person team without any money you're CTO is going to need to code. At a team of 4/5 the handoff begins by employee 11 they shouldn't be coding perhaps firefighting if necessary.

<comment><USER42> As part of a two person team, there are no CEO/COO/CTO/CFO roles...you're just two people building something.

It's a joke to give yourself a management title when there's nothing to manage.

<comment><USER44> It's not a management title, it's a role.

Being a 2 people company or a 20k+, you still have to manage financial, technical, operation aspects of your business.

Same role name, different implications depending on scale.

<comment><USER45> It's a role (CTO), but not one that exist on a small team.

If you are a small handful of people starting off, you don't need a CFO, you need a bookkeeper and an accountant. You don't need a CTO, you need a tech lead.

All that rest is a mix of confusion and puffery.

<comment><USER44> The puffery is in the inflation of the supposed prestige of such titles (both in puny and large settings).

</comment></comment></comment></comment></comment></comment><comment><USER46> This makes me think of groovehq who just recently forced all their customers on to their new rewritten from scratch product.

This after one full year of their customers begging them not to.

So now they have a new modern (in the 2017 sense) product which is worse in many ways and with a whole set of new bugs. And some very unhappy customers.

Improve your products. Don't replace them.

</comment><comment><USER47> I can not comment unless I see the code(s).

<comment><USER48> And yet you did.

<comment><USER47> Did I really?</comment></comment></comment>


Kano: A computer anyone can make - <AUTHOR> http://www.kickstarter.com/projects/alexklein/kano-a-computer-anyone-can-make

<comment><USER2> This is like copy-pasting commands from the Gentoo wiki so you "learn Linux". You don't learn shit, you just insert tab A into slot B, then play Minecraft.

Look at the list of things you can "build". You don't actually make any of those things:

>Build...

>A computer, powered by Raspberry Pi

Meaning: "stick it in a pre-made case"

> Games like Pong, Snake

Either you're playing the installed games, or writing your own... like you could do with any other computer out there. No kit required.

> Music and sounds

Translation: we have a speaker!

> HD video

Well, you're not going to be rendering any video on that little ARM processor, but I guess you can play HD video just like every other Pi.

> A speaker

Comes with a 1/8" connector just like fucking headphones

> Towers of dynamite (...in Minecraft)

Give me a break.

> A wireless server

Closest you'll get to building anything, although what might you serve? Well, you can serve anything with a package in Raspbian, no kit required.

>A custom case, with stickers, decals, or any printed design

You're not building this, it's built for you. Do they remember what this list was titled? It was titled "Build..." not "Included in the package:"

> Most Debian Linux packages

When I think of "building" a package, I think of compilation. At this point, though, their original concept of a list of things you can build has broken down until it's just a feature list.

Every single thing on this list, except for that bullshit about stickers, is just software that you run on a Pi. Pathetic.

<comment><USER3> I agree with your assessment that this isn't really "building" a computer/etc., but I think your tone is unwarranted here.

This looks like a high-quality RPi starter kit, for which there is still a niche. Their "build" fluff is just for marketing to parents of aspiring hardware hackers, and if it means more kids get to start hacking around on a Raspberry Pi, I'm totally okay with it.

<comment><USER2> I think it's a pretty nice RPi starter kit. Speaker, wifi, keyboard, great! I just don't like the bullshit marketing they've put on it. The kids will probably enjoy snapping together the parts, but then you're done. Now it's a sealed-up Minecraft box.

A bigger focus on, say, a suite of kid-oriented programming tools would have been better.

<comment><USER4> You're right - putting more emphasis on tools beyond Scratch and Codeacademy would be cool. And regarding the marketing I personally appreciate it. It's clearly prepared for nonhackerish people and does the job well - creates the feeling of accessibility and encouragement. That's something the tech world lacks generally (and often is proud of). Kano reminds me somehow what Apple did with iphone - bringing simple, easy solution that ordinary people love. And they were also criticized by pundits at the beginning.

</comment></comment></comment></comment><comment><USER5> A lot of the comments here seem to fall into the line of "Why would anyone use this Dropbox ? - you can just use rsync".

There's a huge gap between a Raspberry Pi which gathers dust in the corner and having a product that parents can buy their kids for xmas which they can use to teach themselves the basics of programming.

Yes, parents could source the components individually, install linux, setup up scratch, download some tutorials for their kids, etc. But realistically only very tech savy parents are going to be capable of doing that and even fewer of them actually will.

<comment><USER6> The comments are closer to "Installing dropbox is not the same as building a cloud based storage solution."

This is a nice raspberry pi starter kit. If it was marketed that way, it would be fine. But it's not. The marketing is simply wrong. This is as much a "build your own computer" setup as plugging a keyboard, mouse, and monitor into a Dell desktop is, and people are very rightly calling bullshit on that.

<comment><USER7> Most non-tech people I know consider "building your own computer" to mean being able to plug together your main board, hard drive, graphic card etc. This is what this kit do.

> This is a nice raspberry pi starter kit. If it was marketed that way, it > would be fine.

This is why techies suck at marketing, no people would get what this is about. Are you aware that most people have no idea what raspberry pi is? To most people, a "raspberry pi starter kit" would sound like a kit containing a cookbook with a few tools to get you started and prepare a raspberry pie.

This marketing is for kids and their non-tech parents. Kids can't obviously compile their kernel from scratch and build their own computer. But it challenges their curiosity, show them how to assemble a computer in a basic way, it makes them want to build stuff and gives them a fun introduction to programming and the command line. Not that bad.

<comment><USER8> This is completely dishonest, from the "What can I do with it?" section:

"Build... A computer, powered by Raspberry Pi"

</comment></comment></comment></comment><comment> wes-exp Is it just me or is anyone else getting tired of the constant onslaught of feel-good "code for the children" stuff?

After discovering at least three different non-profits dedicated to teaching children to code, I am starting to think it is not children that need help, but adults.

<comment><USER9> My only problem is that it feels a little too indoctrinating, but then I'm jaded by my personal experience with a developer who is ushering his kids into programming without giving them any career choice. But then I was forced into piano at a young age (in my dad's hope of following him as a musician), so I can't complain too much.

</comment></comment><comment><USER10> It's a cute idea but the contents of the box isn't really that much different from what you'd find inside the box of an iPad or....Microsoft Surface or any other piece of consumer electronics.

All this seems to be doing is taking most of the burden of having to source a keyboard, mouse and monitor if you want to use the Pi as a dedicated machine.

I'm not knocking that, it's just calling it "building a computer" seems wrong.

EDIT: I was probably being a bit harsh, it does seem like it's aimed at children. It looks like the booklets that come with it explain aspects of the Pi in a language children can warm to.

<comment><USER11> Nah don't be so hard on yourself. This was posted weeks ago and everyone determined it sucks but HN is half just a garbage dump for free advertising of any piece of crummy tech that claims to be part of the maker zeitgeist, so IT'S BACK!!!

<comment><USER12> Ok, definitely out harshed the GP. :-)

I'm surprised the AdaFruit folks haven't yet created a Pi bundle like this, there closest [1] is more HW oriented. The kickstarter is pitched more toward the software development than the 'maker' development (aka controlled LEDs and stuff).

[1] [http://www.adafruit.com/products/1014](http://www.adafruit.com/products/1014)

<comment><USER11> it's nice to just harsh it out now & then! ;)

gotta be polite to the open-source guys but why keep up the facade for these opportunists?

</comment></comment></comment></comment><comment><USER13> Has someone redefined the word "make"? Because plugging stuff together isn't 'making' anything, in fact it's undermining kids by setting the bar for 'making' so incredibly low.

<comment><USER14> make (n):

1) An empty marketing catchphrase that allows a product to join the "maker" bandwagon

</comment></comment><comment><USER15> How is that "Build your own computer"?

This is how to build one's own computer: [http://nand2tetris.org/](http://nand2tetris.org/)

No kit required.

</comment><comment><USER16> What exactly are kids learning with this?

How to connect cables? How to put together a box? Are you preparing them for a life in manufacturing?

<comment><USER17> This is a product for children and people who find computers intimidating. It's meant as a fun introduction to computers and programming.

Your comment is like complaining that a LEGO helicopter isn't a real helicopter, and that kids who build them are simply learning how to follow instructions.

<comment><USER10> I guess it's just in the name.

If someone said to me "build your own computer kit, for kids!" it would invoke a vision of some sort of breadboard/pre printed circuit board, with modules or blocks that you would slot into places the instructions said and told the child what each bit did, even if it was in fluffy language that a child could at least warm to.

So the CPU would go in one slot, the memory in the other etc.

I know this is EXACTLY how people build gaming PC's right now, but I'm thinking a lot more basic, cheaper and "kid friendly"

I'm not an electrical engineer though so I'm not really sure of the limitations of how this could/probably would not work.

<comment><USER17> I agree that that would be more honest, if it's possible - maybe this company could add something like that to their product line. I just think that, although it isn't technically correct, non-tech parents would probably consider this "building a computer", and if their goal is to open their children's minds to computers this will probably do a great job.

</comment></comment></comment></comment><comment><USER18> Reading though the comments, I wish there was an easier way to fabricate electronics. Even etching a basic board is an error prone process involving nasty chemicals, and surface mount soldering can be like threading a needle without hands. I don't know a solution to this, maybe more home pick & place robotic arms and using reflow ovens, and some kind of way to print on the paste, who knows. It is a shame that this has all escaped an easier DIY level of skills. I want to be able to do this sort of thing, but it very quickly approaches the point where the time and cost involved to do it outweighs looking around to have someone build something for me instead.

<comment><USER19> It's not building a computer, but there was a post on here a few days ago about a group creating 'sticker circuitry', which essentially consisted of a set of stickers that you could put together to make simple circuits. Seems like a cool idea that gets down to the fundamentals while taking out the hard- to-approach, error-prone aspect.

</comment></comment><comment><USER20> Without watching the video and just looking over the images, it took a while to notice the difference between getting this and just getting a Raspberry Pi with a keyboard. So the package includes more stuff that makes it interesting for kids and techies to play around with the hardware and the components that come with it; pretty cool, if I had kids I'd definitely want to get something like that.

</comment><comment><USER21> The keyboard looks cute, almost tempted to go in for that. Just almost though -- it seems awfully small for grown up hands, and touchpads greatly vary in quality. Also, waiting for more than half a year.

</comment><comment><USER22> You guys should add an option to gift kanos to schools at a discount. Like "Buy 5 Kano's for the school of your choice." and "Buy 10 Kano's for the school of your choice."

</comment><comment><USER23> The name made me remember Space: 1999 [http://en.wikipedia.org/wiki/David_Kano](http://en.wikipedia.org/wiki/David_Kano)

</comment><comment><USER24> I am curious about the software stack. Google didn't return anything relevant about KanoOS.

Can anyone cast a light on this ?

(and I like that keyboard)

</comment><comment><USER25> $19 "Swag"

$100 for raspberry pi and... a BOX!!

<comment><USER26> From what I can tell it adds to the $35 pi:

\- a case w/integrated speaker

\- a keyboard/trackpad combo

\- a wifi dongle

\- nice manual

That's not too bad for the added $65. The mini keyboard looks nicer than the ~$20 FAVI ones[1] I usually use.

At first I thought they'd figured out a way to add a screen. That would be great. But it looks like you need to supply your own.

I work with students in Uganda and it's hard to beat what you get from a $200 netbook. Much faster processor than a pi, plus the screen is integrated. You can't do GPIO stuff like you can with a pi though, so there are trade-offs. Twice the price of this, too.

Looks like a great project to me!

[1]: [http://www.amazon.com/FE01-BL-Wireless-Keyboard-Mouse- Touchp...](http://www.amazon.com/FE01-BL-Wireless-Keyboard-Mouse- Touchpad/dp/B003UE52ME)

<comment><USER27> I work for an NGO that has IT programs in Rwanda. I would love to see some package similar to this that would somehow integrate a screen with Pi. I just love Pi as a concept and I really want to include it in our programs.

As it stands now, we're in the same boat as you. Second hand laptops / netbooks are a far cheaper and simpler solution for us than getting PIs and figuring out what to do with screens, keyboards, etc...

<comment><USER28> You (and parent commenter, and others) should get together and have a website for "This is the stuff we need, and why we need it".

You'd have a suggestion of a package of RPi, keyboard, screen, etc. You'd give suggestions for what would be good, and what to avoid. You give a total cost, and the amount you can provide to that. You then ask people to donate.

You maybe put the faces of children on your request.

LIKE WATSI BUT FOR TECH.

<comment><USER29> Sounds like we could lean on the OLPC guys for that a little bit, at least in the research stages.

Kickstarter+Watsi+OLPC+Kiva = ?

</comment></comment></comment></comment></comment><comment><USER30> english accents kids are the best! [http://youtu.be/5Tx- JQRxkNw](http://youtu.be/5Tx-JQRxkNw)</comment>


Second paper about Mayak accident - <AUTHOR> https://www.pnas.org/content/116/50/24991 <comment><AUTHOR> Also a summary - [https://news.yahoo.com/russia-appears-kept-major- nuclear-172...](https://news.yahoo.com/russia-appears-kept-major- nuclear-172800686.html)</comment>