Topic: Bitcoin source code is a giant mess - page 2. (Read 10724 times)
Isn't this open source? anybody can rewrite the code in any language that they want.
It definitely *is* open source but not just *anybody* can rewrite the code - to do that you would need to understand not just the C++ language (which I don't think anyone here is arguing is easy itself) but also boost (a big library which I actually don't use) as well as the other libraries that are being used in the project.
Even the devs themselves missed the subtleties of BerkleyDB that led to the temporary "hard-fork".
In short - no-one is going to come up with a 100% compatible Bitcoin equivalent in another language without a *lot* of work (a point that has been argued in various other threads - the problem was that Satoshi wrote the spec *after* he wrote the code).
so, anyone with the time, the knowledge, and the desire can rewrite it in any language. as for it being used. I don't see that being an issue. It doesn't mean that it can't be done.
Isn't this open source? anybody can rewrite the code in any language that they want.
It definitely *is* open source but not just *anybody* can rewrite the code - to do that you would need to understand not just the C++ language (which I don't think anyone here is arguing is easy itself) but also boost (a big library which I actually don't use) as well as the other libraries that are being used in the project.
Even the devs themselves missed the subtleties of BerkleyDB that led to the temporary "hard-fork".
In short - no-one is going to come up with a 100% compatible Bitcoin equivalent in another language without a *lot* of work (a point that has been argued in various other threads - the problem was that Satoshi wrote the spec *after* he wrote the code).
Isn't this open source? anybody can rewrite the code in any language that they want.
... but the satoshi client is still official community approved and most well tested client, so nobody gonna use it unless rewrite is very good, or suits there specific needs.
Isn't this open source? anybody can rewrite the code in any language that they want.
+1 CIYAM. To add to your good and explanative post, we could add that the main *good* usage of goto in C is for error handling, or to rephrase : to compensate for the lack of ... exceptions. Exception handling being provided by C++, there's no good reason to use gotos in C++ anymore.
gotoes are directly dangerous in C++. 
+1 CIYAM. To add to your good and explanative post, we could add that the main *good* usage of goto in C is for error handling, or to rephrase : to compensate for the lack of ... exceptions. Exception handling being provided by C++, there's no good reason to use gotos in C++ anymore.
I think goto's are fine, they are just unfashionable
but fast and handy.
but fast and handy.
In C they can indeed make sense - but in C++ they present problems that the language itself does *not* provide guarantees for (in regards to safe exception handling).
So in C++ "goto" really is a "no no" (for error handling as the "goto" in this topic was originally referring to you should just use a "throw").
The *only* reason that *goto* was not *dropped* as a keyword from C++ was to keep backwards compatibility as much as possible with C.
So "fast and handy" they maybe - but in C++ they are 100% *wrong* (as any exception handling would get *screwed* by the *goto* as the language does not cater for this situation).
It goes the same for "setjmp" and "longjmp" (guess most don't remember those) - they can also *not* be used safely in C++ apps.
heretical as it is
I think goto's are fine, they are just unfashionable
but fast and handy.
I think goto's are fine, they are just unfashionable
but fast and handy.
In case of bitcoin quality and performance is high because of high effort of highly capable people committed to it. It however does not have the right patterns and is not well readable.
So then I think that *fundamentally* what we are really looking at identifying is which are the *wrong* patterns and how they should be reworked and also how any *unreadable* code should be changed to make it more readable.
This would be a much more productive direction than just having a "language war" (which never gets anywhere that I've seen in following such things since using Usenet back in the early 90's).
(I also don't think that Bitcoin should be *exclusively* C++ as I do support the idea of eventually there being a Bitcoin protocol RFC type document that *could* be implemented in any decent language).
Whilst I am an advocate of C++ (and don't see any reason to change the language at all) I think in any case the importance is the choice of algorithms and design patterns not the language itself.
Any language that provides the correct semantics with reasonable enough performance and is readable should be acceptable.
+1Any language that provides the correct semantics with reasonable enough performance and is readable should be acceptable.
I do not hate C++.
I think that there are languages that better support good design patterns, readability, code quality and have a performance that is acceptable. That does not mean there would not be any C++ code that has the right patterns, readability and quality.
In case of bitcoin quality and performance is high because of high effort of highly capable people committed to it. It however does not have the right patterns and is not well readable.
I'm just asking, I wanted to try to learn a new language and build a Bitcoin clone with extra features that the language can provide, just extra features or flexibility.
Whilst I am an advocate of C++ (and don't see any reason to change the language at all) I think in any case the importance is the choice of algorithms and design patterns not the language itself.
Any language that provides the correct semantics with reasonable enough performance and is readable should be acceptable.
BTW - all the C++ haters should have a list of bugs that *crash* the bitcoin-qt client (and lose people BTC) - could we have a list please just so we have an idea of how *broken* it actually is?
(and if it is not broken then why are people arguing it *needs* to rewritten in another language?)
Any language that provides the correct semantics with reasonable enough performance and is readable should be acceptable.
BTW - all the C++ haters should have a list of bugs that *crash* the bitcoin-qt client (and lose people BTC) - could we have a list please just so we have an idea of how *broken* it actually is?
(and if it is not broken then why are people arguing it *needs* to rewritten in another language?)
Java was already a step forward.
SBROFL.Java is a terrible step backward, it's a total mess, manages to overcomplicates everything both over modern+higher level languages, AND over C/C++ themselves.
Java was already a step forward.
The next time I would consider Scala as it runs on JVM is OOP and is functional.
The next time I would consider Scala as it runs on JVM is OOP and is functional.
Go.
So what would be the ideal programming language to build Bitcoins succesor?
and of course functional programming is the way forward, not OOP.
so, you like functional programming, hence functional programming is the way to go, and everyone else is doing it wrong.well thought...
C++ sucks.
People who repeatedly type C++ sucks *suck*.
Guys, how many extra hashes you will get programming oo? None notices the irony of things? Indeed, BTC was designed for PC, but "surprise", FPGAs and ASIC too control over it, hashes are today produced with very low level hardware, quite the oposite of "OO"..
lolwut.we're not talking about miners here.
Dude, no patronizing intention, but you always are under scrutinize of miners here., They move the thing around..
Jump to: