The following content was written by Pedagang on September 19, 2017, 01:42:21 AM in the thread Why bitcoin wasn’t written in functional programming hence able to scale?. All content is owned by the author of the bitcointalk.org post. (original)
Functional programming in the other hand is already well suited for these challenges, Immutable state, Closures, and High order functions, concepts that lend themselves very well for writing highly concurrent and distributed applications.
But don’t take my word for it, you can find enough proof by looking at the technological feeds of startups like WhatsApp and Discord:
1) WhatsApp was able to support 900 million users with only 50 engineers in their team by using Erlang.
2) Discord in similar fashion handles over a million requests per minute using Elixir.
The following content was written by achow101 on September 19, 2017, 02:13:55 AM in the thread Why bitcoin wasn’t written in functional programming hence able to scale?. All content is owned by the author of the bitcointalk.org post. (original)
What makes you think that it is the programming languages that makes Bitcoin unable to scale?
The following content was written by A1exander on September 19, 2017, 07:03:02 AM in the thread Why bitcoin wasn’t written in functional programming hence able to scale?. All content is owned by the author of the bitcointalk.org post. (original)
Bitcoin scaling problems are not caused by the language choice. Transaction rate is limited by protocol design, not processing power.
The following content was written by coinmachina on September 23, 2017, 08:24:10 AM in the thread Why bitcoin wasn’t written in functional programming hence able to scale?. All content is owned by the author of the bitcointalk.org post. (original)
WhatsApp is a centralized service. That is why it can handle 900 million users in real time. It does not need a protocol for fault tolerant distributed consensus.
Bitcoin on the other hand does need such a protocol because it is decentralized in every aspect. This has nothing to do with the programming language used to implement this protocol.
The following content was written by zonezICO on February 15, 2018, 07:10:12 PM in the thread Why bitcoin wasn’t written in functional programming hence able to scale?. All content is owned by the author of the bitcointalk.org post. (original)
First time posting here but looking to become a fellow, positive contributing member to this forum.
Sorry to bump this older thread but I did want to continue the discussion over using functional programming for blockchain/crypto projects and add that I think the CONTEXT is very important since as Nikisev mentioned, Bitcoin has scaled but doesn’t C++ have BOTH functional and OO attributes?
Unless you’re Satoshi Nakamoto, statistically speaking, why would any programmer NOT use functional programming if they had the option due to the potential future bugs stemming from tight coupling and spaghetti code?
@nikisev – You brought up a good point in that if it works and allows fast bug fixing, then what’s the problem? But that means that the entire system would be DEPENDENT on YOU, right? While the code can scale, what about the physical operations if you also have to run a business, manage other engineers, etc
If you have to hand that codebase over to someone else, much less the open source community (which isn’t that the point of ICOs to support the general community?) adds the possibility that someone else might have more challenges in maintaining that codebase than you since they won’t know all the intricacies and nuances that YOU, the initial architect, had. Versus had they used a functional programming language from the beginning, there would be NO risk of that at all.
Here’s a good video by Uncle Bob of Cleancoders, who uses humor to make his point, that really changed my perspective of using languages/preemptive organizational practices to prevent decreased productivity and lost of morale for the engineers due to “spaghetti code”.
I recommend the whole video for actual business analytics but if you only have 2 min, 29:08 to 31:00 gives a simple description of the potential problems a company can face that non-technical people would never, ever know.
As for TDD, there was actually good Youtube discussion between the designer of Rails, DHH, who thought TDD was crap, Martin Fowler, and the actual inventor of TDD, Kent Beck. It’s a 6 part series so I’ll just paste the link to the first episode:
DHH made very good points that TDD isn’t for everybody and actually decreased HIS productivity. But to my novice thinking, what he failed to convince me of is that his style of working would work for an entire team since not everybody can be a genius like him and Nikisev. If you have to rely on junior programmers on some level, wouldn’t it make sense to have a very EASY way to find bugs and ideally prevent bugs from even happening?
Anyways, looking forward to your thoughts as I’d like to start developing blockchain apps but C++ or Go don’t inspire me as much as Elixir or Clojure. And definitely NOT JS and hope that WebAssembly will someday free web apps from so dependent on it.
The following content was written by Anti-Cen on February 15, 2018, 11:01:28 PM in the thread Why bitcoin wasn’t written in functional programming hence able to scale?. All content is owned by the author of the bitcointalk.org post. (original)
builds single points of failure into the system.
every man for himself does not really cut it on large scale systems and specialized coordinator type nodes are needed but that
does not mean we have to lose control and this also cuts down on useless internet chatter.
The following content was written by zonezICO on February 17, 2018, 04:28:20 AM in the thread Why bitcoin wasn’t written in functional programming hence able to scale?. All content is owned by the author of the bitcointalk.org post. (original)
Erlang is awesome , no doubt , networking performance is just mind blowing.
TDD very useful, i do everything in TDD now. But to a point. If you have to spend 2 weeks writing e2e tests. Well.TDD wont help you.
It allows to pass code to other developers.
Anyhow, i think C++ choice was due to number cranching required for encryption. Cant bit C++ in raw calculation performance in general case on random os with random hardware.
Very cool! So the Clojure project was a blockchain project or something unrelated? Yes, the brackets/parens are a lot but have you watched any of the designer of the language, Rich Hickey, videos on youtube? His view of the world and how the mind thinks are really inspiring. Here are two that I really enjoyed:
Hammock Driven Development (warning, he covers meditation in it)
Here is an interview between him and Brian Beckman. I wish all discussions around programming could be done in this manner:
As for TDD, good to hear you practice it (also with blockchain projects?) but agree with you that there’s a certain point that it becomes too much. I think that was DHH’s point in those videos and of course the infamous Ruby Conf where he fired the initial shots at TDD:
(warning: Tons of F-bombs in DHH vid)
There are situations when a functional language might be better, but the opportunity costs associated with them for bitcoin was simply magnitudes higher.
You make a great point but as I was reading your post, I remembered an article that Paul Graham from Y Combinator said regarding using a Lisp language when everybody was making Java WAS A COMPETITIVE ADVANTAGE. I’ll paste the link below and some of the text:
“Software is a very competitive business, prone to natural monopolies. A company that gets software written faster and better will, all other things being equal, put its competitors out of business. And when you’re starting a startup, you feel this very keenly. Startups tend to be an all or nothing proposition. You either get rich, or you get nothing. In a startup, if you bet on the wrong technology, your competitors will crush you.
Robert and I both knew Lisp well, and we couldn’t see any reason not to trust our instincts and go with Lisp. We knew that everyone else was writing their software in C++ or Perl. But we also knew that that didn’t mean anything. If you chose technology that way, you’d be running Windows. When you choose technology, you have to ignore what other people are doing, and consider only what will work the best.
This is especially true in a startup. In a big company, you can do what all the other big companies are doing. But a startup can’t do what all the other startups do. I don’t think a lot of people realize this, even in startups.
The average big company grows at about ten percent a year. So if you’re running a big company and you do everything the way the average big company does it, you can expect to do as well as the average big company– that is, to grow about ten percent a year.
The same thing will happen if you’re running a startup, of course. If you do everything the way the average startup does it, you should expect average performance. The problem here is, average performance means that you’ll go out of business. The survival rate for startups is way less than fifty percent. So if you’re running a startup, you had better be doing something odd. If not, you’re in trouble.
Back in 1995, we knew something that I don’t think our competitors understood, and few understand even now: when you’re writing software that only has to run on your own servers, you can use any language you want. When you’re writing desktop software, there’s a strong bias toward writing applications in the same language as the operating system. Ten years ago, writing applications meant writing applications in C. But with Web-based software, especially when you have the source code of both the language and the operating system, you can use whatever language you want.
This new freedom is a double-edged sword, however. Now that you can use any language, you have to think about which one to use. Companies that try to pretend nothing has changed risk finding that their competitors do not.
If you can use any language, which do you use? We chose Lisp. For one thing, it was obvious that rapid development would be important in this market. We were all starting from scratch, so a company that could get new features done before its competitors would have a big advantage. We knew Lisp was a really good language for writing software quickly, and server-based applications magnify the effect of rapid development, because you can release software the minute it’s done.
If other companies didn’t want to use Lisp, so much the better. It might give us a technological edge, and we needed all the help we could get. When we started Viaweb, we had no experience in business. We didn’t know anything about marketing, or hiring people, or raising money, or getting customers. Neither of us had ever even had what you would call a real job. The only thing we were good at was writing software. We hoped that would save us. Any advantage we could get in the software department, we would take.”
The following content was written by Kakmakr on February 17, 2018, 07:00:09 AM in the thread Why bitcoin wasn’t written in functional programming hence able to scale?. All content is owned by the author of the bitcointalk.org post. (original)
Satoshi wrote the protocol in the functional language he/she knew. Why should Satoshi have to switch to something new, if he/she could use the tools he/she knew already. You do the best work in the language with the most experience.
There was a similar thread like this, where they critisized Satoshi for targetting the Windows OS for this and most people agreed that it was the most widely used OS at the time.