Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Mako – a full Bitcoin implementation in C

github.com

Post reply on HN
Print view View original

111–120 of 129 posts

Re: Show HN: Mako – a full Bitcoin implementation in C

#111

Post by noxer »

isitdopamine wrote: post #40
noxer wrote: post #30

Can't help but shake my head over this incredibly impressive waste of time.

Hacker news values intellectual curiosity, so why dismissing something so interesting as a waste of time? Moreover, the code is beautifully written, the project is useful and the rules of HN ask you not to dismiss project just the way you did.

I said its "incredibly impressive" in case you missed that. Other than that my post represent only my opinion and my opinion is that the result of this project is not worth its time.

Feel free to have another opinion but dont tell me I dismissed something when I did not. You did with my opinion for no reason. Have your own opinion, express your disagreement, do whatever but dont dismiss mine and come around with some BS rules I didn't break.

Re: Show HN: Mako – a full Bitcoin implementation in C

#112

Post by b20000 »

cantrevealname wrote: post #81

Call me old school, but I like looking at the number of lines of code to get a feel for how big of a project something is. Mako[1] is 265,618 lines of code. The most widely accepted Bitcoin implementation[2] is 639,074 lines of code -- that's 2.5x bigger and written in a slew of languages. Mako looks like a super-impressive amount of work (and by a single person no less). [1] https://github.com/chjj/mako [2] https://…

last week i got attacked here on HN for suggesting it is not bad to stick to one language and get BETTER over time rather than screwing around with new languages and fads every year. i think this sort of project illustrates what i meant.

Re: Show HN: Mako – a full Bitcoin implementation in C

#113

Post by b20000 »

chjj wrote: post #17
zackham wrote: post #8

This looks like a herculean effort over just the past few months. Congratulations on hitting this milestone and hopefully you can take a breather and tie up loose ends at a more comfortable pace. As much as HN has changed over the years I still think this is a place where there are a lot of people who can appreciate how you feel right now. Nicely done!

Thanks. This was definitely the hardest project I've worked on in my life. I fear I may have shaved a few years off my life with all of the all-nighters I pulled with this, so it's good to hear recognition for the work. :)

congrats on your hard work. why did you choose C89 instead of writing this in C++11 or 17? just curious, no criticism.

Re: Show HN: Mako – a full Bitcoin implementation in C

#114

Post by b20000 »

sanderjd wrote: post #65
chjj wrote: post #62

Earlier quoted context omitted.

I disagree. The function name gives context as to what they're meant to represent if you understand the convention. One of the conventions in mako is something like: int btc_tx_import(btc_tx_t *z, const uint8_t *xp, size_t xn); This function deserializes a raw transaction of `xn` bytes at `xp` and stores the result in the transaction `z`. Zero is returned on failure. What would be the alternative here? I suppose I co…

Your english language description of it gives some good clues to the alternative: int btc_tx_import(btc_tx_t *transaction, const uint8_t *raw_transaction, size_t raw_transaction_size); Or since clearly `tx` is already a convention for "transaction", it could be `tx`, `raw_tx`, and `raw_tx_size`. And sure, I have no problem with the `p` and `n` stuff, so it could be `txp`, `raw_txp`, `raw_txn`. But from your descripti…

agree with raw_tx etc.

Re: Show HN: Mako – a full Bitcoin implementation in C

#115

Post by b20000 »

basedbase wrote: post #63
sanderjd wrote: post #56

Earlier quoted context omitted.

This is a bad convention. Instead of `x` and `z`, you should describe what those pointers are meant to represent. I get that everything is subjective, but some things are actually just bad due to illegibility, and I think it is worth being frank about this.

Quality C code is descriptive in the function name and simply organized, the functions are usually doing one or two things and fairly obvious without many values being passed; you're going to glean a lot more from the function name than the variables. The measure for good C code is extremely different than higher level languages you may be more used to writing.

if someone needs to review this code and only has a few days to do so, it will be impossible without comments.

Re: Show HN: Mako – a full Bitcoin implementation in C

#116

Post by defgeneric »

chjj wrote: post #62
sanderjd wrote: post #56

Earlier quoted context omitted.

This is a bad convention. Instead of `x` and `z`, you should describe what those pointers are meant to represent. I get that everything is subjective, but some things are actually just bad due to illegibility, and I think it is worth being frank about this.

I disagree. The function name gives context as to what they're meant to represent if you understand the convention. One of the conventions in mako is something like: int btc_tx_import(btc_tx_t *z, const uint8_t *xp, size_t xn); This function deserializes a raw transaction of `xn` bytes at `xp` and stores the result in the transaction `z`. Zero is returned on failure. What would be the alternative here? I suppose I co…

> I don't think it adds any value and it just takes up extra space, making the code less readable.

I agree here. What they want is to be able to get a superficial understanding at a glance of what the code is doing--in other words they want to give the absolute minimum effort in terms of reading. But when you actually read/write the code and understand it, the shorter names are an advantage. IMO it comes down to who the names are really important for--the reader/reviewer who will likely move on to something else in the next hour, or the person who has actually given some attention to the meaning of the code?

I think the short names also have the advantage of making the logic of the function body understandable at a glance.

Re: Show HN: Mako – a full Bitcoin implementation in C

#117

Post by defgeneric »

sanderjd wrote: post #68
basedbase wrote: post #63

Earlier quoted context omitted.

Quality C code is descriptive in the function name and simply organized, the functions are usually doing one or two things and fairly obvious without many values being passed; you're going to glean a lot more from the function name than the variables. The measure for good C code is extremely different than higher level languages you may be more used to writing.

I believe that this is a cop out, an excuse for a culture of poor conventions. In all languages, good functions should be named well, simply organized, and doing only one or two things, and without many arguments passed in. Also in all languages, parameters and variables should be named expressively. There's no reason C should be exempt from this.

Not really. It's because the interfaces in C tend to follow a common pattern that verbose variable names can get in the way. If we have

  int alter_struct(some_struct_t *s, void *xp, size_t xn);
then it's pretty obvious that the data pointer xp with size xn is going to modify whatever struct object we have at pointer s.

The variable names can be shortened because the function interface follows a common convention.

The really important thing here is a good function name, not a good name for the data pointer argument (a descriptive name could even incorrectly suggest it has a specific type rather than simply point to bytes).

Re: Show HN: Mako – a full Bitcoin implementation in C

#118

Post by __vim__ »

nynx wrote: post #9

This is very impressive, but I’ll be honest, I wouldn’t want to expose any new software written in C to the internet.

I feel this comment is misguided. Plenty of new code is written in C, particularly in the scientific computing space. If the code in question doesnt do lots memory management and expects the user to provide a memory block to be populated with values, then I see no issues. C code tends to be faster than other implementations even without optimizations. Moreover, lots of interpreted languages have good interoperability with C so a C compiled code can be called in many languages using simple high level interfaces.

Re: Show HN: Mako – a full Bitcoin implementation in C

#119

Post by slmjkdbtl »

bluejekyll wrote: post #91
cantrevealname wrote: post #81

Call me old school, but I like looking at the number of lines of code to get a feel for how big of a project something is. Mako[1] is 265,618 lines of code. The most widely accepted Bitcoin implementation[2] is 639,074 lines of code -- that's 2.5x bigger and written in a slew of languages. Mako looks like a super-impressive amount of work (and by a single person no less). [1] https://github.com/chjj/mako [2] https://…

Tokei is my go to for counting lines of code in a project: https://github.com/XAMPPRocky/tokei

I usually line by line count by hand, you get a good count, and learned the source along the way
Post reply on HN