Bitcoin source code is a giant mess

[jdbtracker]

So what would be the ideal programming language to build Bitcoins succesor?

[hf]

Go.

[grau]

Java was already a step forward.

The next time I would consider Scala as it runs on JVM is OOP and is functional.

[Lohoris]

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.

[CIYAM]

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?)

[jdbtracker]

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.

[grau]

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.

+1

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.

[CIYAM]

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

[jubalix]

heretical as it is

I think goto's are fine, they are just unfashionable

but fast and handy.

[CIYAM]

I think goto's are fine, they are just unfashionable

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.

[hf]

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

[kokjo]

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

[Trongersoll]

Isn't this open source? anybody can rewrite the code in any language that they want.

[kokjo]

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.

[CIYAM]

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

[Trongersoll]

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.

[Aido]

   
[ANNOUNCE] picocoin and libccoin -- C-based bitcoin library and client

[razorfishsl]

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

And a Jump table is what?

[Trongersoll]

Ok, this is getting nuts. there is nothing inheritantly wrong wrong with goto. the problem is that not everyone uses them responsibly. there once was a time in history when poor use of goto created what was called "spaghetti code" where people used goto's to jump into the middle of functions and such all over the place. this made the code hard to read and costly to return. This caused the stigma on goto. Structured Programming using accepted constructs becae the norm.

For any company paying to have code developed, Maintainability became the mandate. Arguing about goto accomplishes nothing. if you are coding for free, do what ya want, go ahead, develop bad habits. Somebody will make you confrom sooner or later.  the US Gov. spent hugh sums getting ADA developed and used to encourage a common structured, readable language. Today, ADA isn't so popular, i suspect because the rebels couldn't do what ever they wanted.

The thing to do if you are coding for public consumption is to write and document your code as if the next person isn't as smart as you and what is clear to you may not be clear to them. Do this and you'll be a successful Professional Programmer/Software Engineer.

[CIYAM]

And a Jump table is what?

It is not part of the C++ language (so not relevant to this discussion).

Understand that the main evil in coding goto is the possibility of it leading to undefined behavior which does not have to be reported by the compiler (same as something like a[ i ] = i++; which compilers are not likely to give you any warning about).