Does Functional Programming Replace GoF Design Patterns? - <AUTHOR> http://stackoverflow.com/questions/327955/does-functional-programming-replace-gof-design-patterns <comment><USER2> Looking back, I'm amazed at how long it took me to awaken from the dogmatic OO slumber. One of the things that snapped me out of it was realizing how mechanical and low-level the GoF patterns are. Combine that with the tight coupling you get in object models (a foo has a bar and a collection of bazzes, each of which has a bizzat, and they each tell two friends, and so on and so on) and you end up with very rigid code. That medium is concrete and concrete hardens awfully quickly.

Nowadays, my programs are orthogonal sets of functions that I can combine any way I want to, with no object model to wrestle into submission, and my world is blissfully design-pattern-free.

Freud said sometimes a cigar is only a cigar. I say sometimes a function is only a function.

Edit: I exempt Smalltalk from this generalization about OO. I've met too many smart, well-informed people who prefer Smalltalk (at least half a dozen!) to believe that what Smalltalk programmers do is OO of the kind that I experienced. Alan Kay's writings on the subject confirm that.

<comment><USER3> If you're exempting Smalltalk from your generalizations about OO, then your observations probably aren't even about OO so much as the fallout from C++ and Java's attempted graft of it onto C. That's like exempting Haskell from generalizations about functional programming.

OO systems can be simple and incredibly useful when solving some problems (without needing tremendous amounts of boilerplate code), but many things claiming to use OOP are doing so for buzzword-compliance. You _can_ , of course, write good OO code in C++ and Java (or even C), but many people working in them do not understand OO design very well (overusing inheritance is especially common), and you will have to write complex and verbose workarounds for fundamental differences in language semantics (e.g. the lack of Smalltalk-style blocks, C-style static typing's requirement for explicit casts).

If you want to understand OO, look at Smalltalk (_Smalltalk-80_ is a good book). Post-Smalltalk prototype-oriented languages such as Io (<http://www.iolanguage.com/>) and Self (<http://research.sun.com/self/language.html>) also have numerous interesting ideas in them* , but writings about them generally assume familiarity with Smalltalk. Also, read Alan Kay. Whether or not you agree with his conclusions, he writes lucidly about many language design issues.

My favorite OO example from Smalltalk is that the language doesn't need a primitive for "if", you just pass an object that calls one of two blocks, depending on whether it receives true or false. A Smalltalk block, by the way, is an anonymous function which is not evaluated until its result is needed. Sound familiar? :)

* Prototype-based programming is also easily done in Javascript and Lua, FWIW. Steve Yegge is big on the former ([http://steve-yegge.blogspot.com/2008/10/universal-design-pat...](http://steve-yegge.blogspot.com/2008/10/universal-design-pattern.html)), I prefer the latter.

<comment><USER2> Note: I mostly wrote the following before I had my coffee. Consider yourself warned :)

 _your observations probably aren't even about OO_

I programmed professionally in OO for years, have trained many people in OO design and domain modeling, and know what the fuck I am talking about. I know what Smalltalk blocks are, I know what Smalltalk "if" is, and I happen to have read Alan Kay, which you might have seen had you read my post properly instead of just dumping out a pile of predigested tutorial boilerplate.

My critique of OO comes from struggling to build serious production systems with it, not from programming language parlor games.

 _exempting Smalltalk from your generalizations about OO ... [is] like exempting Haskell from generalizations about functional programming_

No, it's not. Kay coined the term OO, but it hasn't meant what he meant by it for a long time. I'm talking about OO in the sense that the overwhelming majority of people now understand it: roughly, the organization of programs into classes that bundle state and behavior in ways that attempt to model the problem domain. Whatever makes Smalltalk great, it isn't this, as the subsequent history of OO makes clear. People thought that this was the contribution of Smalltalk and they tried to abstract the paradigm out and improve on it - but what really happened is they threw the baby out with the bathwater, and now we have static bathwater. I have a hunch this is because they paid too much attention to the Simula strain in Smalltalk and not enough to the Lisp one (<http://news.ycombinator.com/item?id=288786>). Had they listened to Alan Kay they wouldn't have made this mistake; there's no question which he emphasizes more.

 _OO systems can be simple and incredibly useful when solving some problems (without needing tremendous amounts of boilerplate code)_

Anything is simple and useful when you're working on a simple problem. What matters is how it works on complex problems. The claim made about OO for a generation now is that it helps to build complex systems, and this mantra has been repeated and taught so often that most people just believe it. It's not true. In my experience, you _do_ typically end up needing tremendous amounts of boilerplate code when working that way (whether or not you see it as such is a different matter). Worse, your system starts to fight itself because the way you need to organize it over here doesn't work over there, and so on; time to factor out the code you need into a static "utility" class - poof, there just went your OO paradigm.

Ultimately, I'm exempting Smalltalk from my critique because of the respect I have for the Smalltalk programmers I know, who can't possibly only be doing OO in the majoritarian sense. I haven't used Smalltalk enough myself to have a clear idea of what they're really doing, and Bob Dylan said not to criticize what you don't understand.

I'm not, however, exempting CLOS, which I have used enough to experience several of the limitations I'm talking about, enough so that I don't bother with it anymore. Perhaps that will persuade you that I'm talking about more than C++ and Java?

<comment><USER3> First, I saw that you said that you have read Alan Kay, but I'm speaking to the general discussion audience. And, ok, you know what you're talking about; I'm used to reading people who think that _all_ OO systems necessarily suffer from the same problems as e.g. C++'s, and, not knowing your programming history, had few impressions to the contrary based strictly on what you said. Nothing personal. Be civil, have your coffee.

> What matters is how it works on complex problems.

Agreed. I don't believe pure-OO (or pure-FP, pure-declarative, etc.) is an ideal approach for _anything_. OOP is a technique that works well for _some problems_ , and is best understood so you can use it when it is a good fit.

I think that the best way to _learn_ OO is via studying Smalltalk. I think the best way to learn FP is via either Haskell or ML, etc. I do real work in OCaml, Lisp, and Python (though I am coming to prefer Lua over Python), but use a multi-paradigm approach based on what I've learned in other languages.

<comment><USER2> _Be civil, have your coffee._

That made me laugh! Actually the coffee kicked in as I was writing, which you can probably tell. I don't know why I didn't go back and edit the first part... I compulsively edit everything else.

</comment></comment></comment></comment></comment><comment><USER4> Most OO languages are based on no theory, while every FP language can trace its roots to the lambda calculus. Functions compose and abstract very well, leading to simpler and more expressive designs. In OOPLs the unit of abstraction is the class, usually these aren't even first class citizens, the syntax is usually too heavyweight for casual use (imagine a FPL where it takes as many lines of code to declare an anonymous function as it takes to declare an anonymous class in Java). Even Smalltalk and Self use blocks (i.e. closures or lambdas) instead of providing some lightweight class/object literal notation. GoF patterns were created to solve these problems of OOPLs. If you're trying to do FP in a language without higher order functions and algebraic data types you'll have to come up with dozens of design patterns to express simple things as folds or pattern-matching. OTOH a hypothetical OOPL with higher-order classes and a lightweight syntax for anonymous object/class literals would provide combinators for almost (if not all) GoF patterns and this wouldn't be an issue. It's not FP that replaces GoF patterns, good languages with a solid theoretical basis replace GoF patterns, independent of the paradigm.

<comment><USER3> > Most OO languages are based on no theory

Smalltalk is based on the same computational theory as Lisp. See: The Early History of Smalltalk ([http://gagne.homedns.org/%7etgagne/contrib/EarlyHistoryST.ht...](http://gagne.homedns.org/%7etgagne/contrib/EarlyHistoryST.html)), search for " _to really understand LISP_ ". (It's a scanned and OCR'd article, so there are strange typos.)

Unfortunately, you're ultimately correct: "most [popularly used] OO languages" these days seem to be based on tearing off a handful of Smalltalk's object- based theory of computation, duct-taping it on C, and seeing what happens. You can have OO languages with very elegant theoretical foundations (Smalltalk, Io, Self), including systems handling Classes as first-class objects (sometimes called a "Meta-Object protocol"), but most people associate OO with C++ and Java.

> Even Smalltalk and Self use blocks (i.e. closures or lambdas) instead of > providing some lightweight class/object literal notation.

This really is key: the language doesn't require you to create a full anonymous class when sending a message/anonymous function would do. Also, blocks aren't evaluated unless their message is sent, which means you get a good syntax for lambdas and basic lazy evaluation for free. Those, along with dynamic typing, make most of C++ OO-style awkwardness vanish.

</comment></comment><comment><USER5> Amusingly horrible question. Functional programming languages don't typically have class-based or prototype mechanisms, so why on earth would a named set of object interaction mechanisms be relevant - let alone displaceable?

I also think it is funny the status quo in language design is to effectively combine objects and functions but programmers and writers are not acknowledging this fusion. Ocaml, Javascript, F#, Scala, Ruby, Nemerle ... with varying ease, these languages all let you create lambdas, compose functions, functions as values. Even mainstream languages like C# and Java are awkwardly moving in this direction.

Scala does some crazy stuff to make "fusion" interesting. They allow objects in pattern matching by providing a specific mechanism for allowing an object to expose encapsulated behavior (extractors). Functions all belong to a parametric set of classes and have an "apply" method e.g. def add(x:Int,y:Int) = x+y is really Function2[Int,Int,Int]{ def apply(x:Int,y:Int):Int = x + y }. Likewise, any class or singleton object can invoked as a function by providing an "apply" method implementation.

<comment><USER6> I think it's because you can easily make your own object system in a functional language.

Make yourself a function (representing an object) that takes in a parameter that it uses to dispatch a function contained in it. Return the function, and the user can then call that with their args. And you still maintain encapsulation, too, because the returned function may access stuff that was only available inside the containing closure (where it was dispatched).

Put all of this together in a nice "class" macro, and bam, you've got objects.

Though, yeah, I guess this would be really tedious if your functional language didn't have good macros.

<comment><USER7> "And you still maintain encapsulation, too, because the returned function may access stuff that was only available inside the containing closure (where it was dispatched)."

That only works if your functions can maintain state and if they can, well they're basically _objects_ aren't they...

<comment><USER6> That's my point. You don't need to have a separate special construct for objects, or any kind of support for them, when you have first-class functions.

As for state information, you could just put a 'let' inside there with your variables, and call mutators on them from inside the "object"'s functions.

Hmm, I think all these Scheme-centric classes I've taken have warped my mind. I should seek therapy.

<comment><AUTHOR> > when you have first-class functions.

This isn't enough without the ability to close over the lexical environment. See Python pre 3.0, without the dictionary/list "hacks".

</comment></comment></comment></comment></comment><comment><USER3> What is the difference between a design pattern and a language idiom?

From common usage, a "design pattern" seems to be a way of organizing part of a program that cannot be directly expressed _once_ in the language and then pushed into a library, but instead needs to be mostly rewritten whenever used. (Polyglot programmers usually recognize this as a kind of language weakness. (See: [http://weblog.raganwald.com/2006/01/finding-signal-to- noise-...](http://weblog.raganwald.com/2006/01/finding-signal-to-noise-ratio- in-never.html)) ) If one could just say,

      require "visitor.lib";

and move on, then would people make such a big deal about them?

Along similar lines, FP has currying, pattern matching / destructuring-bind, higher-order functions, and monads, among other things. The only one of these I've heard referred to as a design pattern is the monad. Most FP languages just let you do all of the others, but monads require rewriting some (relatively small) infrastructure code. In Haskell, the compiler (via typeclasses) _recognizes_ that you are writing an instance of a _known general concept_ , though, so you don't need to duplicate most of the infrastructure.

If this isn't the case, then why aren't general OO design concepts such as e.g. delegation or inheritance considered design patterns?

<comment><USER8> > What is the difference between a design pattern and a language idiom?

A design pattern is simply a name given to the obvious solution given to a common problem. By giving it a name it becomes much easier to talk about / understand the code. Once you know that a class is a proxy class, you don't really care what the methods do anymore, you just dive in and see to which classes the real work is delegated. So one word "proxy" tells you exactly what 400 lines of boilerplate does.

A language idiom is different. The purpose of language idioms is to clearly and succinctly express common concepts. The language designers think of a "best" solution, and give it a name.

So, really, when you have a bunch of people writing the same code to solve the same class of problem, you give that code a name and call it a design pattern. Patterns emerge AFTER the language is used. Language idioms try to capture the essence of the problem, such that no patterns are necessary.

At least, that's how I look at it.

</comment></comment><comment><USER9> Its not functional programming per se but higher level languages in general. Most scheme and lisp environments already come with high-level abstractions which completely obviate the need for any obvious design pattern (like visitor, etc...) and lisp is by no means a functional language (though it does incorporate many aspects of functional languages).</comment>


Stack Overflow is currently offline for maintenance - <AUTHOR> http://stackoverflow.com/

<comment><USER2> This plus HN being under a DDos attack this morning makes me think someone is trying to get under the skin of programmers all over the world.

edit: bitbucket down as well. Geek Armageddon!

<comment><USER3> It's working.

<comment><USER2> I am getting either the offline message or an error that says there was an error and the error page also had an error.

" An exception occurred while processing your request. Additionally, another exception occurred while executing the custom error page for the first exception. The request has been terminated. "

</comment></comment></comment><comment><USER4> How can one work "efficiently" with stackoverflow being down and HN being slow? _You can 't._

<comment><USER2> I was just thinking how terrible it would be if I had to read actual documentation again.

</comment></comment><comment><USER5> MongoHQ (CircleCI, Buffer and definitely others because of it), Hacker News, stackoverflow, Bitbucket... Is this a big coincidence?

<comment><USER2> Not a chance it is coincidence. The only common thread may be usage of some cloud service provider though I don't think there is anything common between them all.

I would be curious if other popular tech/programmer sites are under attack and just thwarting it better?

<comment><USER5> The common in-between is the users. I hope this isn't the case, but if hacker was able to get access to any MongoHQ db there probably is so much time needed, until you find a db holding full-text passwords.

Still, in order to do any damage to the application/platform the hacker should be aware of procedures for remote work (administration/support/development) in order to log-in and make a mess.

</comment></comment></comment><comment><USER6> Why sites are publishing their downtime on HN? Hacker News is better than that.

</comment><comment><USER7> Great opportunity for a natural experiment on productivity relative to availability of tools. Track internal commits relative to prior Wednesdays.

</comment><comment><USER8> We failed over to our secondary load balancer and are investigating what went on. We've disabled realtime websockets for now.

</comment><comment><USER9> A lot of programmers may actually have to take a break and go outdoors today. It's the code monkey apocalypse!

</comment><comment><USER10> Seems like its back up at 11:08</comment>


Show HN: We Opened Up Our Transcription Tool - <AUTHOR> Audio/video transcription tools are quite rudimentary. The audio player is separate from the editor which makes it very cumbersome cross-reference between the audio and the text.
Our transcription editor solves this problem. It provides the audio and a fully featured text editor on a single interface and tightly couples both of them. Jumping to any position in the audio causes the cursor to move correspondingly, and vice-versa.
https://scribie.com/tools/transcription-editor
The editor is built on Ace Editor and the audio player flash or native.
All standard features are there, with some advanced ones. One feature is text analysis. It performs a trigram match followed by a TF-IDF analysis which highlights the new terms and phrases in the transcript. Those are the most likely places for mistakes.
We have been using this tool for the past two years internally and now have opened it up for everyone. Please do try it out once.
Thanks in advance! <comment><AUTHOR> clickable: [https://scribie.com/tools/transcription- editor](https://scribie.com/tools/transcription-editor)</comment>


Warren Buffet: How to Minimize Investment Returns - <AUTHOR> http://www.wallstraits.com/main/viewarticle.php?id=1373

<comment><USER2> This subject is a serious hobby (approaching business) of mine so I'll comment.

Warren Buffet is an investor, namely a value investor. And he does very well with his strategies. But there are other more speculative strategies that work and do provide greater annual returns than his company.

The returns for certain strategies, however, diminish when you increase your capital for a certain strategy.

There is a difference between what he does and financial speculation. W.B. actively goes out to seek and _create_ value, whereas speculators are scalpers, not actually creating value but by exploiting market inefficiencies.

There is also a difference between the value of a company and the supply and demand of the stock of that company. W.B. follows the former with the expectation that the latter will follow (it most often does).

His last paragraph is probably the most interesting in this essay. It shows that past returns are certainly not indicative of the future. My guess is that U.S. domestic equities will not have the greatest return as a securities class for a while.

See: [http://bespokeinvest.typepad.com/bespoke/2008/06/shrinking-u...](http://bespokeinvest.typepad.com/bespoke/2008/06/shrinking- usa.html)

<comment><USER3> Reading your comment, it made me think of Yahoo! and the "value" that is in Yahoo! but just isn't seen in it's stock price. Warren Buffet should buy Yahoo! and turn it into the company it should already be but for some reason, isn't.

<comment><USER2> W.B. refuses to invest in internet companies. He feels that they are overvalued.

And there is a difference between stock price and the value of a company. Of course, I also believe that the efficient market hypothesis is bullshit.

<comment><USER4> I though the argued that they were hard to understand, not intrinsically worth less than the price at which he could buy them.

</comment></comment></comment></comment><comment><USER5> Isn't this the pot calling the kettle black? Warren Buffet manages money on behalf of his investors via his investment vehicle: Berkshire Hathaway. He is a "Helper." Granted, he's a giant leap above the hedge fund world zero-sum game. But, he's still a stock picking "Helper."

<comment><USER6> His incentive structure is different from the mainstream financial industry. Buffett invests his own money and doesn't sell his stock: he started the Buffett Partnership with $100K of his own savings. His gains or losses are proportionally equal to that of his investors. I guess maybe the original limited partners had it different (Buffett probably got a larger share of Berkshire for his $100k than the limited partners got), but I doubt any of them are complaining now.

Investing in Berkshire Hathaway is "Heads we both win, tails we both lose. Hope you like betting the same way I do." By contrast, investing in a hedge fund is "Heads I win, tails you lose" and investing in a mutual fund is "Either way I win, tails you lose."</comment></comment>


Studio Ghibli movies will stream exclusively on HBO Max - <AUTHOR> https://www.theverge.com/2019/10/17/20919325/studio-ghibli-stream-hbo-max-spirited-away-kikis-delivery-service-my-neighbor-totoro <comment><AUTHOR> [https://news.ycombinator.com/item?id=21259697](https://news.ycombinator.com/item?id=21259697) made it to the front page of hackernews. Title of the post was "You may never see Studio Ghibli's movies on streaming services". Today we have this news.</comment>


Multicore OCaml: May 2020 update - <AUTHOR> https://discuss.ocaml.org/t/multicore-ocaml-may-2020-update/5898 <comment><USER2> For those of us (like me) who have never heard of MultiCore Ocaml before, here is the github page with a brief overview. [https://github.com/ocaml- multicore/ocaml-multicore](https://github.com/ocaml-multicore/ocaml-multicore)

</comment><comment><USER3> Will this always be a compiler extension, or is intended to be an evolution of the language?

<comment> dan-robertson It's not a compiler extension. It's currently a fork of the compiler and patches are slowly being upstreamed.

<comment><USER3> Should people write programs differently than before, or just use existing concurrency constructs and things will execute with better parallelism?

<comment><USER4> There will be some new differences. Multicore is bringing in some new concepts–e.g. domains (an abstraction for system threads). Perhaps down the road the existing concurrent programming libraries like Lwt will abstract all that away and preserve their existing interfaces. Remains to be seen.

</comment></comment></comment></comment><comment><USER5> Assuming this works without major regressions, this is a fantastic step forward for OCaml, opening it up to use cases that require parallelism.

<comment><USER6> We have a preprint up of our paper that details the design of Multicore OCaml along with a range of performance comparisons: [https://arxiv.org/abs/2004.11663](https://arxiv.org/abs/2004.11663)

In terms of performance it varies. The benchmarks in that paper it ranges from a 20% slowdown to a 20% speedup - most macro benchmarks are <10%. There's also still some more performance work we can do to chip away at that further.

</comment></comment><comment><USER3> What is an example of a simple, serial ocaml program and how you would change it to use parallelism?

<comment><USER7> This always depends on context if parallelizing anything actually helps with performance but my most common usage of F# (essentially Ocaml on .net) parallel features are using the .net parallel library[1]. Easy way to introduce parallelized loops into your processing if what you're doing is heavy enough to warrant them. In my particular usage this was used for data transformations that were heavy enough to warrant the parallelization overhead.

[1] [https://docs.microsoft.com/en- us/dotnet/api/system.threading...](https://docs.microsoft.com/en- us/dotnet/api/system.threading.tasks.parallel.for?view=netcore-3.1)

</comment></comment><comment><USER8> Now we just need modular implicits and OCaml would be _the_ ideal language for non-ML projects. Without them, OCaml is a little crusty.

<comment><USER9> Now, my understanding of ocaml is rather rusty, but shouldn't modular implicits be pretty straight forward to implement? Do you know of any good reason why it hasn't been implemented other than inertia? I don't remember missing them other than for generic arithmetic. What would be your use case?

<comment><USER8> Typeclasses. With typeclasses, we could get a collections api, monads, etc. Basically everything that Haskell has, except without the academic purity obsessed bullshit.

Right now, OCaml is very... concrete. You have to call different functions to find the length of a string, a list, or an array. Modular implicits would get rid of all that bullshit. We could do more type-level programming, instead of the "earth-bound" kind of stuff we do now. Here's a 2014 paper on it: [http://www.lpw25.net/papers/ml2014.pdf](http://www.lpw25.net/papers/ml2014.pdf)

The only problem is that, well, it's from 2014. OCaml moves unbearably slow compared to any other language (except maybe Python). It seems like there's a lack of knowledgeable contributors, which is a shame. But maybe if OCaml was rewritten from scratch using LLVM IR, more progress could be made. But I don't really know, I'm not an OCaml internals expert.

<comment><USER10> > Typeclasses

Modular implicits are not typeclasses.

> With typeclasses, we could get a collections api, monads, etc.

OCaml already has that through parameterized modules modules and inclusion. Modular implicits would not fundamentally change that. It would make calling a bit less cumbersome (but with local opening, it's already not that bad).

Sadly, implementing modular implicits properly is a tremendous undertaking.

> OCaml moves unbearably slow compared to any other language (except maybe > Python).

I personally find Ocaml to move quite fast. Actually I think it has never been that fast. There is a release every six months and the last few releases have seen significant improvements on every fronts: performance (flambda), the standard library (notably with regard to collections) and syntax (let+ and let*).

> But maybe if OCaml was rewritten from scratch using LLVM IR, more progress > could be made.

One of the most enjoyable part of writting Ocaml is how fast and efficient the compiler is. I personnaly fail to see what porting it to LLVM IR would bring (apart from more compilation targets). I mean, no one would complain if someone did the port but that seems like a lot of work for meagre returns.

<comment><USER8> Of course modular implicits aren't typeclasses, but they would allow functionality very similar to typeclasses: function polymorphism.

Maybe we have a different idea of cumbersome, but I find that having to explicitly find the right >>= or >> to be cumbersome, and it feels bad. Having to implicitly pass modules around or using local open is simply inelegant.

I've found that there's a surprisingly large number of OCaml users who defend the status quo no matter what. OCaml seems to be perfect for them, even though everyone else can see its flaws. I've introduced OCaml to quite a few Haskellers, and _all_ of them have been shocked to learn about the lack of flexibility OCaml provides. OCaml doesn't get anywhere close to providing the kind of "type-level" programming that Scala and Haskell do.

Most of the interesting kind of programming you can do in Haskell is simply not possible with OCaml. While OCaml will never be Haskell and probably shouldn't, modular implicits would go a long way in helping.

Here's a concrete example: ppx_let. ppx_let is a very nice library and makes monadic code a lot nicer. It's fantastic, even if you have to find the right Let_syntax module. I use core, so it's relatively easy to just import the correct one. The problem is when you're using other libraries. For example, angstrom (a parser combinator library) doesn't have a Let_syntax module. So I either have create my own or not use ppx_let with it. Modular implicits could solve this problem.

Another problem is that very few OCaml users are actually using stdlib bundled with OCaml. Personally, I think stdlib should be ditched and replaced with Core_kernel, but this is never going to happen. It's too late to make updates to the collections library, the biggest industrial user, Jane Street, is never going to use them.

About the LLVM IR, it's not what LLVM IR would bring exactly. It's that time and time again, the reason for why so and so is taking so long is that there aren't enough compiler experts. Not enough performance experts for multicore, not enough type experts for modular implicits, etc etc. I am ignorant on OCaml internals, but why are there so few people who can contribute? New masters students who've never touched the Scala compiler, for example, make pretty significant changes all the time. I suspect there is something about how the compiler is written that makes it very hard to understand.

Perhaps if OCaml used LLVM IR, it would simplify things. LLVM can do some pretty impressive optimizations on IR, has a JIT, includes a number of backends, etc etc. There's a reason why almost all new languages use it: because it's easy. Hell, you could create a compiler for a very simple imperative dynamic language (like Python, say) in a weekend that would have pretty impressive performance.

Look, I love OCaml. I like that it produces native executables, I like the practicality, I like the clean syntax, etc. But the language has some _major_ problems: fractured ecosystem, weak type system, strange module system, etc. OCaml does things differently than other languages, and that's fine. But being different has a price, and sometimes, it actually has no benefit. I understand the core language will not change, but I think things modular implicits could be a game-changer in terms of usability. OCaml wouldn't look so weird anymore. Maybe it could even be used for scientific computing.

</comment></comment></comment></comment></comment><comment><USER6> With previous months, happy to answer any questions people might have.

</comment><comment><USER11> wha's the end goal here?

<comment> dan-robertson Currently the ocaml runtime has a global lock on running ocaml. Like python you may have multiple OS threads but only one may have this lock at a time. Non-ocaml code may release this lock while e.g. doing blocking IO.

The goal is to remove this lock in a way that is safe and allows programs to continue being fast.</comment></comment>


How to improve the odds of getting into YC as a solo founder? - <AUTHOR>

<comment><AUTHOR> [http://www.paulgraham.com/startupmistakes.html](http://www.paulgraham.com/startupmistakes.html)

 _What 's wrong with having one founder? To start with, it's a vote of no confidence. It probably means the founder couldn't talk any of his friends into starting the company with him._

I don't have many friends. I definitely could talk people into starting with me but I prefer maintaining control and direction of the startup.

 _Starting a startup is too hard for one person. Even if you could do all the work yourself, you need colleagues to brainstorm with, to talk you out of stupid decisions, and to cheer you up when things go wrong._

I hired a Personal Assistant that I get along well with pretty decently. I can build a team around me. I have just enough funds to hire a contractor for additional part time help.

I want to be a solo founder maintaining control over the startup with a team of employees around me. Is this bad?

<comment><USER2> Is your goal to get into YC or have a successful startup?

If your goal is to get into YC, go find yourself a warm body to be co-founder or join numerous others looking to get into YC but don't have teams. Of course, as a YC alum (Nikkey or someone from Australia, can't recall exact detail) wrote in the blog post, be prepared for the situation when co-founder bales out on you after getting YC stamp.

If your goal is to have a successful startup and business, focus on growing your business, gaining traction, gaining customers, building product, getting revenue and not on getting into YC. You don't need a co-founder or YC stamp to start a business or have a successful business. While working on your startup, if you meet someone who fancies as a potential good co-founder, explore to bring them onboard, otherwise continue focusing on growing your startup.

IME, more successful people become, more tunnel vision they get. There is more than one way to any destination.

<comment><USER3> Your goal should always be to have a successful startup. Even if you get into YC, it's no guarantee of success by far.

The reason why YC wants co-founders is that in the space of everyone that is a single founder, proportionally very little of them can actually do it alone. Compared to teams with two people.

Being able to convince someone else to work with you on a crazy idea is a proxy that there's some merit to the idea.

</comment></comment></comment><comment><USER4> I know of a couple single founders who made it into YC. Some of them are very successful. Try to bring your business to a point where it doesn't matter whether you get into YC or not, and you should be ok.</comment>


Contest: Hack my bitcoins and keep them - <AUTHOR> http://linja-aho.blogspot.com/2013/03/small-contest-hack-my-bitcoins-and-keep.html <comment><USER2> It's like a nano X Prize, seemingly aimed against pass phrases.

Bitcoin wallet hacking is a really fun test case, because it begs people to acknowledge the opportunity costs involved in cracking. Cracking a wallet password can always be baselined against mining.

Cracks should happen whenever: operations_per_password / wallet_size < operations_per_coin

(You can increase security either by growing your passwords or shrinking your wallets. There's some ideal inflection point in there somewhere...)

There are opportunity costs to cracking passwords in all other scenarios too, they're just harder to observe. ie, whenever it's cheaper to bribe one of your employees than crack their password, then, congrats, your passwords are officially "secure" (even if your business isn't).

<comment><USER3> this is not cracking, the guy has brainwallets and told all the clues to get into to them.

</comment></comment><comment><USER4> For generating memorable passphrases with high entropy, I like the "diceware" system:

<http://world.std.com/~reinhold/diceware.html>

Use it to generate the one password that you use for unlocking your password manager, where all of your randomly generated passwords are kept.

Since most people don't do that, this post makes me think that my idle CloudCracker cycles spent mining BTC would actually be better spent mining brainwallets. =)

<comment><USER5> I thought you meant Andrew "Dice" Clay so that it makes a phrase like Hickory Dickory Dock...

</comment></comment><comment><USER6> There are many ways such little cash bonuses can be left 'in the blockchain' for people to discover. Imagine a video/podcast which offers various obscured glimpses of a private key's QR code... the first viewer to freeze-frame and stitch-together collects the prize.

Or imagine any other riddles/puzzles with a solution space resistant to brute- force search. The prize for the first solver can be left in the blockchain, with a private key derived from the solution.

After 'easter eggs' (in real life or software), these could be called 'eggcoins'. (I find a prior use of that term related to a geocached souvenir coin.)

</comment><comment><USER7> Fantastic idea actually. Comments on this page are fascinating.

This too: "The fourth address was robbed in 7 hours"..."I did not tell anyone about my test"! LOL, nuts.

<comment><USER8> Basically people scan brainwallets for weak passwords. Kinda obvious but still food for thought.

<comment><USER9> I wonder what the best convention for generating secure brainwallets is. They seem much more prone to dictionary attacks if you're not careful. Is inventing words and nonsensical phrases the norm?

<comment><USER10> Using a brain wallet in any form is reckless. You're better off storing your private key on paper or using SSSS[0].

[0]: <http://point-at-infinity.org/ssss/>

</comment></comment></comment></comment><comment><USER11> Dang it, I was hoping this didn't make it on HN :) I've been working on this for a few days!

Currently I'm porting SHA256, RIPEMD160, and ECDSA key pair generation to CUDA. ECDSA is giving me some trouble though...

<comment><USER12> Why Nvidia (CUDA)? It it the only hardware you have access to?

If you have access to AMD graphics cards, you should have written your code in OpenCL to target this hardware. Nvidia cards are a lot slower per $ and per Watt than AMD ones when running SHA256/RIPEMD160/ECDSA. That is why vanitygen was done in OpenCL.

<comment><USER11> > Why Nvidia (CUDA)? It it the only hardware you have access to?

Yep. Also, learning CUDA would be a benefit for my graduate research, so it's not a complete loss :)

</comment></comment></comment><comment><USER13> If you follow best practice and generate a new address for each tranaction, brainwallets don't scale. At least not until <https://en.bitcoin.it/wiki/BIP_0032> is implemented.

One bitcoin is a lot of money (about $40). He created five wallets, so he's giving away $200. That's not a trivial amount of money for such a test.

<comment><USER14> It's not a "best practice", it's only something you should to if you want to remain as anonymous as possible.

It's perfectly acceptable to use only one address if you don't care much about anonymity.

</comment></comment><comment><USER12> One more private address was just brute-forced, and coins were moved: [https://blockchain.info/address/1ECM1W1ZWtWDvTm3yWYWJA9mKn4D...](https://blockchain.info/address/1ECM1W1ZWtWDvTm3yWYWJA9mKn4Dwaaz1o)

3 out of 5 remain to be found :)

</comment><comment> w-ll I actually modified a Bitcoin address tool to generate brain wallets in python specifically for brute forcing week brains.

<https://github.com/willwharton/pybrainwallet>

</comment><comment><USER15> "Hack my bitcoins and keep them"

So, everyone with bitcoins is always running this contest?

</comment><comment><USER16> If you'd like to use a mnemonic (a nice long sentence) but need some extra gibberish to prevent it being easily guessed, you can try this :

<http://eksith.com/experiments/passwordencoder/>

Basically takes the first letter of every word in your sentence and adds its position in the alphabet (plus rotate if you like).

If the sentence you choose is sufficiently unique, the password will also be harder to crack.

<comment><USER17> Since the last half of the password is partially determined by the first half, this doesn't add much additional entropy (an attacker only has to guess your phrase, and which options you've selected).

In practice this may help in a security through obscurity way, but now your method is public.

<comment><USER16> It's been public since 2008 :)

This may work better for me since I've used phrases from out-of-print books and some are latinized phrases in Sinhalese. I prefer to use random passwords that I can add to a master file that's PGP encrypted, but in the absence of that, I can tailor this to a site and add character rotation.

<comment><USER18>
        phrases from out-of-print books

Less secure now that there's massive book scanning going on.

</comment></comment></comment></comment><comment><AUTHOR> FINAL ANSWER: [http://linja-aho.blogspot.fi/2013/03/bitcoin-brain-wallet- cr...](http://linja-aho.blogspot.fi/2013/03/bitcoin-brain-wallet-cracking- contest.html)

</comment><comment><USER19> openssl rand -base64 50 ;-)</comment>


You Probably Don't Need a Blockchain - village-idiot http://ashtonkemerling.com/blog/2018/02/21/no-you-probably-dont-need-a-blockchain/ <comment><AUTHOR> Okay, I don't want to come down too hard on this article, but I think it's nearsighted. Sure, it's true that _today's_ blockchains have many downsides the article brings up, but it's written as if those won't change or improve.

It feels to me a bit like claiming in the 90's that the internet isn't the future because you can't download that much stuff at 56k speeds.

They mention "immutability" being a problem - so much so that it somehow disallows typos or undos. That's just not true - you just represent the updates as changes in their own right (which better reflects reality than literally altering history). There's nothing about "the blockchain" that can't record human error or corrections.

They go on to talk about how proof of stake doesn't solve all problems by mentioning, "The Bitcoin blockchain is currently 157GB in size, and that's at a very low transaction speed. The idea of everyone mining on their phone is just laughable."

Once again, they are talking about current implementations - I don't see how this is inherently a restriction in the technology, and there are (reputable) companies working on this exact thing.

The amount of money I have in cryptocurrencies can basically be rounded to zero, so I don't have much skin in this game - I just think blog posts like these aren't really making compelling points other than "the current technology today has many flaws", which I think is uninteresting to most.

<comment><USER2> Well, he has a point. Unless you use a cryptocurrency, I can't think of anything that needs the blockchain. I have seen plenty of people trying to shoehorn the blockchain into areas that don't need it - goods distribution, electricity supply, you name it and someone is trying to do it. Almost all of those things would actually work better with a centralised database.

The Blockchain is an awesome technology for an incredibly niche market. So his article is right - in most cases, you probably don't need a blockchain.

<comment><USER3> Anything where chain of custody is important is a great application in my humble opinion. Currently a huge problem in engineering is guaranteeing the legitimacy of parts. Everything from electronics to commercial jet parts have knockoffs being made and passed off as legitimate. If you have unique QR codes for each part from the manufacturer you can use a blockchain to track chain of custody of the part.

Beyond that you can make something unique digitally and hash it and someone can "own" that digital thing, instead of money it can be items in a game or art or anything really. A musician can make a song for a single person and sign it into a blockchain and you can prove who it was for. Lots of neat applications that haven't been created yet just like the internet when it was new.

<comment><USER4> How is this any better than the manufacturer just maintaining a database of legitimate parts (identified by QR codes) and then contacting the manufacturer when you want to know if a part is legitimate? About the only thing a blockchain would do is insulate you from the manufacturer's API going down. But even that can be solved by having the manufacturer simply send you a copy of the database periodically (and then contacting the manufacturer if your database copy doesn't have the part, in case it's newer than your database, although even that can be solved by having the manufacturer generate the codes in advance, so the database they give you can already contain the codes that will be used for parts manufactured over the next month).

Heck, you don't really even need a database for this at all, come to think of it. Just have the QR code contain a signed copy of the part identifier. You can validate that the signature matches the manufacturer's public key and that will be just as good as asking the manufacturer if it's valid.

Also, now that I think about this, this whole scheme (including using a blockchain) has the fatal flaw wherein a knockoff can just copy the QR code from a valid part. There's nothing stopping anyone from reusing the QR codes, and the knockoff will appear just as legitimate as the original.

<comment><USER3> With a blockchain the end user could tag the part hash as being installed and you could see exactly who each supplier had the part at what time. A database could go offline and stop a part from begin installed into a jetliner but a blockchain would be always available. The manufacturer could track which parts the end user has in stock and installed and make production decisions easier. A consortium of manufacturers could use the same blockchain for all their parts. I am not claiming it's more efficient for all use cases just that there are some distributed trust applications that seem to make sense.

<comment><USER4> The only interesting part here is the behavior when the manufacturer's API goes down, and that's solveable just by having the clients maintain a queue of their failed modifications and retry them later when the API goes back up again. And of course the manufacturer can even provide the software that does this to the client so the client doesn't have to do any work for it.

<comment><USER5> The blockchain solution can gives more benefits more than "when the manufacturer's API goes down".

So there are 3 actors in supply chain: manufacturers, retailers, and consumers. In your solution (centralized database and API), you rely on the goodwill of the manufacturers which is fine (I guess) in most cases. But retailers and consumers have good reason sometimes not to trust the manufacturers. Vice versa.

Okay, let's consider this case: the manufacturer produces milk packaged in a bottle. So they put QR code in the milk, and put some information in their database. Let's say they put the production date into this database.

QR code: Abbbccc Information: produced on January 5th 2018

They send the milk to the warehouse A. Warehouse A keeps the milk for a night before sending to the retailers. But alas, there is a storm preventing the warehouse sending the milk to the retailers. So 1 week later, it delivers the milk to the retailers. Warehouse A informs the manufacturer about the incident. But let's say this milk only has 10 days before it hits expiry date after the production. Manufacturer decides to lie to the retailers. They updates the database.

QR code: Abbbccc Information: produced on January 11th 2018

In blockchain, this corruption can be prevented.

<comment><USER6> The blockchain is not what prevented that; the manufacturer publicly publishing that information is what prevented that. The fact that they did so to a blockchain is irrelevant.

Say the manufacturer instead just has an RSS feed on their site, where they publish that information (digitally signed, of course) as the milk is produced. The retailers just have to keep a local copy of that feed, and so they can detect any later tampering.

<comment><USER4> And if you really love the blockchain, you can always run your own blockchain that simply records snapshots of the manufacturer's RSS feed!

</sarcasm>

That said, this does bring to mind one genuinely useful aspect to the blockchain I forgot about, and that's the fact that Keybase uses the bitcoin blockchain (IIRC) to periodically record the Merkle tree roots that they use to verify their own information. The only reason to do this is as proof that they're not tampering with the Keybase history that they publish, and so fundamentally this is just the same thing as digital notarizing that I did mention before (except in this case it doesn't matter whether the courts recognize it as being valid). And you could still accomplish this without a blockchain simply by having a neutral third party agree to keep a record of the merkle tree roots, but this is one of the few cases where the 'trustless' aspect of the blockchain actually is useful.

Though of course even with a 'trustless' blockchain you still have to trust the chain itself. With Bitcoin, you can assume nobody's managed to execute a 51% attack against the chain (at least, for the time being; AIUI with the way things are going it looks like the Chinese government might be able to do it by exerting pressure on all the Chinese miners), but if you're running your own chain, how do you make mining the chain popular enough to prevent attacks?

In fact, to my mind, the only real benefit of Bitcoin at this point is the fact that it's so popular it's hard to attack (well, except by the Chinese government).

<comment><USER6> Yeah, as long as the cryptocurrency speculators are paying for it, getting a public timestamping service for almost free is nice.

I'm not actually a Bitcoin/blockchain hater; I can't avoid having a soft spot for any tech that makes me feel like I'm living in a cyberpunk world :) What I dislike is the mania. Bitcoin is a cool experiment, not a production-ready solution to anything.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> I got downvoted the last time I said this, but cryptocurrencies are actually pretty nice for doing exactly what their purpose is: sending money over the internet. Do you know how hard it is to get Stripe or Paypal to approve you for international credit card processing? If you're a "hacker" working out of your apartment, they automatically assume you're trying to launder money and shut you down, even if you've worked hard to provide solid documentation that you are who you say you are and you're doing what you say you're doing. Even if they do approve you it can take months to integrate into their system. And that's _with_ Stripe and/or Paypal, _without_ Stripe and/or Paypal it's impossible. Until crypto. With crypto you can set up a transaction system _in a day, by yourself_. I think that's great value.

<comment><USER8> Well, of course something that skirts around regulations will require less red tape. Once the government catches up, you'll be required to do similar hoop jumping for cryptos. Exchanges suffer this problem already, don't they?

<comment><USER3> The cat is already out of the bag its just like bittorrents of copyrighted content. Yeah It's illegal but that doesn't stop anyone. Also, with how easy it is to change one crypto for another how would you even regulate it? I am not asking that retorically and am genuinely interested in this if anyone has an idea of how cryotocurrency regulations would work.

<comment><USER9> You regulate the fiat onramps and offramps which are the exchanges. Nobody uses bitcoin to actually pay for things, so once you take away the ability to exchange it for fiat, the whole scheme collapses. The US government could end most of this tomorrow by simply shutting down a handful of exchanges.

<comment><USER10> This is very shortsighted. In the positive future, you aren't going to need to exchange into fiat currency, youll just exchange in crypto.

</comment></comment></comment></comment></comment><comment> c-cube Very interesting, and mostly right imho. Still no killer app for any blockchain so far, but lots of problems already well known. I'm almost disappointed the author didn't mention the ecological disaster that goes with the energy consumption, instead of just talking about the price.

<comment> village-idiot Yeah, I totally forgot that.

<comment><USER11> If you compare the energy consumption of traditional banking systems to Bitcoin, you will realise how very efficient blockchain is.

<comment><USER2> I hardly think so. Try scaling up Bitcoin to the world's current volume of transactions and you'll find it uses _vastly_ more electricity than traditional banking systems use.

<comment><USER11> We are working on it, so watch this space. The power consumption will not increase linearly, because of tier 2 & 3 solutions. The key is that blockchain is automated. With traditional centralised trust systems, you need buildings full of people running everything.

<comment><USER12> Buildings full of people are a joke compared to the massive amounts of power wasted on mining.

</comment></comment></comment></comment></comment></comment><comment><USER13> With the bitcoin price drop articles like these have been popping up on HN quite frequently. previous discussion:

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

What I feel has never been discussed is not whether blockchain or decentralization is a good idea rather how does decentralization will work? The issue is not whether immutability is bad idea rather how will it work in case of disputes?

The only answer I keep hearing is - well, game theory can take care of it. This misses the point that if people are aware of the rules, they will find ways to break it.

We saw a good example of how "we need 51% for manipulation" works in real life during Status ICO. F2pool which held 25% of the mining power was able to manipulate the ICO holding back ethereum transactions:

[https://steemit.com/ethereum/@dhumphrey/f2pool- manipulates-u...](https://steemit.com/ethereum/@dhumphrey/f2pool-manipulates- usd1-2-million-on-the-ethereum-blockchain-during-the-status-im-ico)

It wont be long before people come to realize the rules and start exploiting it.

</comment><comment><USER14> Opening this article, I was hoping to get a technical discussion as to why an application might or might not need blockchain. Unfortunately, I was met with a ranting article with a few straw man arguments about why blockchain is flawed.

The first point the author makes is the disadvantage of immutability. Claims that few systems benefit from immutable transaction records. First of all, I don't think that's true. Many systems do, not just financial systems with double entry bookkeeping. Event sourcing is a well defined architecture pattern in back end systems, and it turns out that immutable event logs are actually incredibly useful. It's also pretty well known that you don't erase history in financial systems. That is one of the pillars of double entry bookkeeping.

A more balanced article would point out the pros and cons of immutable systems, but to flippantly argue that immutability is useless? That's just lazy.

Tracking shipment of goods on a blockchain has many advantages. Namely, you can create a shared protocol for the data of shipment tracking, and you can open that blockchain up to certain parties to sign as the good moves along the supply chain. It doesn't have to be "trustless". A particular app's blockchain might only be open to a few trusted parties to write to. Not all transactions have to be written to a single, global, immutable ledger. There are still great benefits to sharing a common blockchain among specific, trusted, cooperative entities.

On POW and the electricity argument, I think we waste electricity on lots of frivolous things. I'm willing to bet Christmas lights also consume more than the state of Delaware. However, it's not the processing of transactions that the electricity is being spent on, it's the creation of new coins.

POS is a good alternative. I think many coins are starting to leverage POS. Ethereum will be switching to that soon.

Still, POS vs POW has nothing to do with "why you probably don't need a blockchain". These are implementation details that vary per blockchain/coin.

Scale also varies dramatically among coins. Ripple already processes 1000s of transactions / second. Lightning network on BTC is growing rapidly. Ethereum has scaling solutions in the works. Other chains have completely different properties than the top two and have different answers for the scaling issues. These issues will be solved with time.

As for rants on ICOs and scams, etc. I mean, do you know how many people have been scammed from phishing e-mails? Does that mean we should not use e-mail? No. As always, caveat emptor, do your own research, and don't take unnecessary risks.

<comment><USER15> I would not bother if I were you, I've never seen a coverage so negative of blockchains as the one we have on HN. Every week you have a new article looking like this, full of straw man arguments, never any pro/cons. "You Probably Don't Need a Blockchain", yeah you probably did not need a website in 1999 as well, and web technologies were crap. Cryptocurrencies are completely new field which needs time to mature, basing the potential future of it on current technologies isn't very wise.

I remember the Dropbox post on HN full of people asking why they would need it when they can use USB keys and ftp, I feel cryptocurrencies are clearly underestimated the same way here on HN.

<comment><USER16> I think HN is responding to the almost hyperbolic proliferation of "blockchain" as some digital panacea and social zeitgeist. It's cool to talk about "crypto" at dinner now. Every time I hear some suave new BTC owner at the table next to mine undressing his two lady friends with technically inaccurate explanations of how crypto currencies work I die a little.

But I think you're right. Time will tell. I would love to see more distributed software that empowers participants to grow stake in the digital systems they depend upon. And having well-curated frameworks and working knowledge for operating blockchains will help us grow our digital gardens. The renaissance has only just begun. Patience is a virtue.

</comment></comment></comment><comment><USER17> A better title for the content might be: blockchain scaling issues

A better case against blockchains would be exploring the reasons why we shouldn't care about trustless properties that blockchains give us.

</comment><comment><USER18> I think the focus in the article and in the comments is all wrong. The benefit of blockchains is on the businesslevel. If you have several manufacturers, of course you can integrate with all their databases, but that requires an enourmous amount of managements and hours in meetings and implementation. The next step, which i guess some banks have done is to cooporate on a common solution which is operated and run by a commonly owned entity. This also requires tons of management and a whole new organization which eventually becomes its own business area. A third option is like uber for transporting goods, a huge independent third party which is efficient, but eventually gets too powerful, so people revert to one of the other solutions. Blockchains on the other hand has a model for distributing trust and operations. It provides a more general solution to a mexican standoff than months of meetings and long contracts. Your contract is embedded in the blockchain. Of course the blockchain needs to be updated and maintained, so i think the real issue with blockchains would be that people cannot agree to using a single one for a specific purpose. But then it is much easier to agree to using a blockchain than to use solution x provided by company y because of all the organizational overhead it could abstract away.

<comment><USER19> Most companies will adopt permissioned blockchains if they decide to use blockchain technology. It's just not common to expose your data and logic to people outside your organization even if encryption is involved. Right or wrong it's a culture thing. Because of that it's just another technology option like an API server backed by a relational database.

Blockchains and smart contracts are complicated. There have already been a large number of security issues. There is also a lot of research into making the technology performant. Picking a centralized authority is much less risky because the organization is betting on proven technology.

</comment></comment><comment><USER20> Distributed systems are ideal for many applications. Distributed systems verified by many 'miners' is even better, but at some point, we have to admit that the technology is flawed in key points: \- power consumption, considering global warming, is a huge waste; \- the speed all nodes communicate between each other (not even counting the great firewall of China) can't be improved after some point (BTC lightning network is NOT a real solution - read an article about how exactly it works)

Proof of stake is a VERY BAD idea that creates more problems than it solves. All I have to do to take over the chain is buy 1 coin more than anyone else on the chain..

All other problems could be solved in the future (reversible transactions, regulation/privacy etc), but with these 2 major drawbacks, blockchains are not feasible, in my opinion.

</comment><comment><USER11> It would be nice if this was called, "Why would I need a Blockchain?" or something. It's pretty clear the author hasn't gone deep enough to tell other people how relevant Blockchain might be to their lives. A change in title/tone would avoid the crimes of confidence.

<comment> village-idiot Someone didn't read all the way to the disclaimer....

<comment><USER11> I read the article. The disclaimer is both inadequate and a poor substitute for a humbler article.

Disclaimer: Just saying.

<comment> village-idiot So the disclaimer and the word "probably" wasn't hedging enough for you?

Maybe you just already had your own conclusions and don't like it when people disagree.

</comment></comment></comment></comment><comment><USER21> If you're not in an adversarial environment, you don't need a blockchain. Sometimes you are though.

</comment><comment><USER22> The growth of the blockchains will slow drastically, as the flaw in 'Metcalfe's law' \- which states that the number of potential connections in a network is proportional to the square of the number of participants-becomes apparent: most people have nothing to sign for each other! By 2020 or so, it will become clear that the blockchains' impact on the economy has been no greater than the fax machine's.

</comment><comment><USER23> > On smart contracts: _" Of course, writing programs that produce permanent > financial consequences gives me some pretty serious anxiety, and I would > hope that most senior engineers would feel the same."_

I don't believe most senior engineers would feel the same. It's hard to imagine our world today _without_ programs that produce permanent financial consequences. They are everywhere.

<comment> village-idiot Okay, go write a "smart" mortgage and put all your money into it. Let me know how you feel about this.

Of course every bug has financial effects, software is designed to make money in the vast majority of cases. But to write software that can literally drain every single last dollar from your clients or yourself in an unrecoverable fashion just because _any_ programming error is insanity to me.

</comment></comment><comment><USER24> And yes, the writer probably may buy bitcoins after other people who read an article like this sold them.

<comment> village-idiot Nope. I don't do speculative bubbles.

</comment></comment><comment><USER25> At some point in the article they mention that an alternative to the proof of work could be to use the proof of stake: the oldest stake build the next block. Did I understand correctly? How can that work? Doesn't it create multiple problems to do that?

</comment><comment><USER26> My less romantic, medium-term outlook on this is that all of these thought- police projects are trying to enforce a combination of nonstate binary answers and an (informational) monoculture to a messy capitalist world with the single technological argument of a distributed/anonymized/encrypted/irreversible database that has little relevance for the actual underlying idea. Looking at the past eight+ years, and other than opening up speculation and dubious activites for a new group of people, we have not seen a single project that would ever highlight the usual required 10x benefits, let alone the promise to change the behavior of the regular user. It's merely porting a fraction of existing stuff behind cumbersome UX — With all respect for infancy of technology but what if porting my contacts, having one single login, a distributed social network or to-do list aren't just that important as the proponents are arguing for? Obvisouly all of these attempts have already failed several times. This is not the equivalent of killing Gopher through HTTP by a new experience, making information available for the first time, introducing a new socially acceptable interaction or killing industries and middlemen by means of __raw__ technology (In each case there was always more to it). Even torrenting is already more or less dead in favor of OTT because people are lazy bastards that don't care how the content gets streamed to their TV. And what if customers actually like collecting flight miles, having someone who picks up the phone when their CC was compromised, when the taxi driver harassed them, their car title got lost or their 401k was hacked off their account? IF breaking up the power consolidation in whatever industry with blockchain tech being the primary method, the starting line is at what's already out there and then offering real advantages and incentives (other than coins) that can only be achieved through a public ledger — Obviously there are potential and often cited areas like real estate, voting and medical records but all of these seem to me as an admistrative job for a missionary movement to enforce standards and not a private startup. And yes, I get the argument for using it in adversarial areas but we're talking business here.

</comment><comment><USER27> > Blockchains typically use the "Proof of Work" system, where multiple > participants try to solve a difficult problem in order to certify a block to > be valid.

Apparently no one has told him that a blockchain is just a data structure and has nothing to do with proof of work.

[https://youtu.be/fOMVZXLjKYo?t=21m40s](https://youtu.be/fOMVZXLjKYo?t=21m40s)

<comment><USER6> No, that's just a hash chain, and it has existed for decades, long before the blockchain ever appeared. For example, every POS software in my country was legally required to implement that before the Bitcoin paper was published. The blockchain is a particular implementation of an hash chain, designed to work well for transactions using some sort of distributed consensus algorithm (of which proof-of-work is a category).

</comment></comment><comment><USER28> If an author does not understand what he is talking about, then his conclusion should be ignored. This article is laughable, I would suggest doing your own research before listening to baseless prose. Below, we see why this might not be a sound article:

> The first miner that solves the problem is rewarded with a few Bitcoins, > hence the unkind comparisons to Ponzi or MLM schemes.

Author clearly does not understand what MLM and Ponzi schemes are, likely throwing them out as buzzwords to associate mining with scams.

> Actually trying to make computers in general reflect the real world is a > very hard task, and the blockchain does nothing to solve this issue.

Black and white statements are a red flag; it's likely this guy does not know much and was hired to "write posts about bitcoin". Blockchains and other emergent structures may trigger tons of research into automata theory. Blockchains do get us one step closer to representing globally unique objects. Seems like the author didn't ponder at all.

> One of the most common proposed usages of blockchain is to track the > shipment of real world goods, including everything from food to diamonds. On > the surface this sounds great, you could easily and trustlessly prove that > the shiny rock in your beloved's ring wasn't mined by children in a war torn > region, fantastic!

The author's sarcasm here is very telling of his lack of imagination. To swiftly denounce technology that doesn't exist in its full form yet is incredibly presumptuous.

> Ebay purchaser did not deliver? Tough. Someone held you hostage until you > sent them bitcoin? Tough. Private key hacked, or hard drive destroyed? > That's unfortunate for you.

As if these problems are not applicable to fiat currency...

> The only way to recover bad bitcoin transactions is to convince everyone to > do a hard fork

This is possible with smart insurance contracts with two user segments: insurance providers, and insurance seekers.

> [Refunds due to faulty transactions] would rapidly clutter up the chain full > of "oops" transactions, which would pretty quickly make you wonder why > you're bothering at all.

Did this guy just forget that faulty transactions make up almost no relative volume? This is a moot point. Even if _every single_ transaction was faulty, it'd only be a factor two more in size according to the Author. The author thinks that a factor of two is a worthy point here. I am really starting to question the validity of these points.

> It turns out, that there's very few systems that truly benefit from an > inability to amend or update transactions.

Okay, I can say that too. Where's the source?

> The idea of everyone mining on their phone is just laughable.

The idea of everyone carrying around a device that computes faster than the supercomputers Feynman was playing on is just laughable.

> On top of that, as best I can tell a _large_ percentage of Ethereum > contracts are literal Ponzi schemes and ICO tokens

So, you _can 't_ tell very well? AFAIK the logic here is also flawed; even _if_ most of the ICOs were scams, it says more about the people doing ICOs than it does about the concept of the ICO itself. Again folks, this article contains a lot of misinformation. I highly suggest doing your own research before making decisions.

<comment> village-idiot Aaaand we finally have the first post accusing me of being paid to write this. Bitcoin fanatics are wonderfully predictable.

<comment><USER28> Out of all the points I mentioned, you decided to comment on the least interesting one. This is also very telling. This article seems to have been written by someone who read a single Forbes article on blockchains. Many of your points are obsolete, but readers will figure that out on their own.

I'm appalled at the number of articles in this space that are aimed at confusing laymen more than informing them. It's a shame.

<comment> village-idiot The moment you start accusing people of being paid shills, the rest of your comment is literally pointless. It's hard to ignore the paid shill part. Complaining about this is like calling someone IRL an asshole and then being surprised that they totally skipped right by the rest of your treatise on the state of politics today.

</comment></comment></comment></comment><comment><USER29> while I agree with most points I don't see what new value this blog article provides. There is no indepth analysis, only opinion. And not even new ideas. This is exactly what we criticise about most blockchain lovers.

<comment> village-idiot The same could be said of your comment.

<comment><USER29> In case you are new here: The polite parts of the HN community consider it best practice to explain why they flagged or downvoted something so that the corresponding content provider has an opportunity to improve their results if they choose to do so.

<comment> village-idiot I disagree with your analysis and find it rude and pointless. Good day.</comment></comment></comment></comment>