Author

Topic: Why bitcoin wasn't written in functional programming hence able to scale? (Read 723 times)

legendary
Activity: 3542
Merit: 1965
Leading Crypto Sports Betting & Casino Platform
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.
newbie
Activity: 13
Merit: 1
Was just working on project in Clojure. JVM man.And all this brackets ...cmon.
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)
https://www.youtube.com/watch?v=f84n5oFoZBc

Here is an interview between him and Brian Beckman.  I wish all discussions around programming could be done in this manner:
https://www.youtube.com/watch?v=wASCH_gPnDw

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:
https://www.youtube.com/watch?v=wASCH_gPnDw

(warning: Tons of F-bombs in DHH vid)

I think the best programming language for an open source project especially at the scale of BitCoin is how strong the community is in that programming language. You don't want to scare people off by making some wierd language choices.

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:

http://www.paulgraham.com/avg.html

"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."





jr. member
Activity: 31
Merit: 1
I think the best programming language for an open source project especially at the scale of BitCoin is how strong the community is in that programming language. You don't want to scare people off by making some wierd language choices.

There are situations when a functional language might be better, but the opportunity costs associated with them for bitcoin was simply magnitudes higher.
full member
Activity: 266
Merit: 101
Im the very decease you pretend to be
Was just working on project in Clojure. JVM man.And all this brackets ...cmon.
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.

member
Activity: 210
Merit: 26
High fees = low BTC price
Bitcoin on the other hand does need such a protocol because it is decentralized in every aspect.protocol.
No it is not and the miners would soon be up a gum tree without pool sites and you seem to forget Lightning is very centralized and
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.

newbie
Activity: 13
Merit: 1
Hello all,

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.  

https://cleancoders.com/episode/clean-code-episode-1/show

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:

https://www.youtube.com/watch?v=z9quxZsLcfo&t=2s

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?

I think that's what Elixir (based on Erlang) is good for since it tells you the exact error a lot of the time and Clojure (which still offering OO programming to attract Java guys) has the best practice of relying on the REPL.  I've never worked with F#/Haskell or Ocaml but seems to me like they'd all be better choices than a language such as Javascript

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.

Z
full member
Activity: 266
Merit: 101
Im the very decease you pretend to be
After 22 years in High Tech. Here is my humble opinion
All this functional, declarative, streaming, test driven, code last, object oriented bullshit does not matter.
If it works and allows fast bug fixing and feature addition - go for it. If its not, no functional programming will help you.
Who said Bitcoin wont scale? Its distributed computer that works better than Visa and controls more money than some countries annual budget.
For open source project- its very much successful project. Everything they did - was awesome from technical perspective.
Does not scale its when you write pilot for 1000 customers and than it does not work for 100K customers, so you have to rewrite it completely.
newbie
Activity: 28
Merit: 11
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.
full member
Activity: 336
Merit: 102
Bitcoin scaling problems are not caused by the language choice. Transaction rate is limited by protocol design, not processing power.
staff
Activity: 3458
Merit: 6793
Just writing some code
What makes you think that it is the programming languages that makes Bitcoin unable to scale?
newbie
Activity: 10
Merit: 0
Quote
Objected Oriented Programming is simply not cutting it anymore, specially when it comes to concurrency and parallelism; trying to add concurrency and parallelism to this languages adds lots of complexity and more often than not leads to over engineering and poor performance.

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.

Jump to: