git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.

From
IMIan Molton <ian.molton@collabora.co.uk>
Date
Jun 10, 2010, 19:12 UTC
Message-ID
<loom.20100610T204637-685@post.gmane.org>
In-Reply-To
<4AFD7EAD1AAC4E54A416BA3F6E6A9E52@ntdev.corp.microsoft.com>
Dmitry Kakurin <dmitry.kakurin <at> gmail.com> writes:
Show 6 quoted lines
> 
> [ snip ]
> 
> When I first looked at Git source code two things struck me as odd:
> 1. Pure C as opposed to C++. No idea why. Please don't talk about 
> portability, it's BS.

Word to the wise... you effectively just told one of *the* best known programmers of all time that they are talking BS... nice one. Hope you've got some flameproof undies. Whats that? no? ah well...

I smell a troll, but since everyone else has had a go...
Heres some comments picked out from the thread, in no particular order...
> > You have a very strange way of not meaning to start a C vs. C++ war.
> I honestly didn't. I didn't even think it's possible. In the
> environment of mainstream commercial software development the last war
> on this subj was over 8-10 years ago.

Really? I dont know what planet you're from, but this 'war' has been raging for decades, and will probably continue until one side or the other gets round to using tactical nukes.

And besides, this *isn't* the commercial (closed) software world - we've moved on. We no longer depend on closed companies handing out features like orphans in the Victorian times...

>>> [bitfields in D]
Show 11 quoted lines
>>   Really, I feel this is a big lack, for a language that aims at
>> simplicity, conciseness _and_ correctness.
>>
>>   OK, maybe I'm biased, I work with networks protocols all day long, so
>> I often need bitfields, but still, a lot of people deal with network
>> protocols, it's not a niche.
>
> And strictly speaking, C bitfields are completely useless for that
> purpose since the compiler is free to use whatever method he wants for
> allocating bit fields.  So if you want to write a portable program,
> you are back to making the masks yourself.

Sadly. Thats always been one of the things I found annoying in C. There are times when you want access to the types the hardware itself uses, and there are times when you want to know your int is 32 bits long, and there isnt really a standardised way of doing that. Of course, its worked around in practice, but it all seems so unnecessary.

Show 5 quoted lines
> in the *real world* rewriting Git in assembly would be like  
> painting a house using a single horse hair instead of a paint brush  
> or roller. Your SHA-1 example is a perfect example of where you  
> benefit from doing a tiny embellished detail using the single hair  
> (assembly) and leave all the rest in C.
The above comment is pure epic win :-)
On another note, some people talked about code reuse...

IMHO Sourcecode reuse is something of a myth in any language. Sure, some small algorithms get reused, but thats really not a language dependent characteristic. As soon as you build something much bigger than an algorithm, it starts to need an interface, and at that point you may as well turn it into a library. Thats where the REAL code reuse happens. And as it happens at runtime, its good for users - bugfixes help everyone.

On to language choice...

I have NEVER understood why people seem to think theres some kind of hierarchy in either ease of coding or speed. You see it all the time, people think that:

assembler is faster than c is faster than c++ is faster than perl etc.

WHY? I've seen some truely braindamaged assembler that could be outperformed by BASIC on a BBC micro. I've seen 'handcrafted' C and C++ that looked like it was written during a skydive whilst on crack.

languages are *tools*. Pick the most appropriate. Use two. Embrace the power of and...

Linux make good use of C and assembler, both compiled/assembled seperately and inline. Some stuff like accessing weird registers with oddball opcodes is actually impossible under C. But (say) write a filesystem in assembler? no thanks! (not that it hasn't been done, but for the love of god, why?)

So, anyway, why do these kind of threads never go away? because opinions are like arseholes. Everyones got one. As you grow older, you learn stuff. You hopefully dont repeat the mistakes of ones youth. (theres at least one ill-conceived C string library out there which I'm embarrased to admit is my fault (hopefully it'll never leave the company I was at when I wrote it...). These threads are where the n00bs meet the pros. Usually, the n00bs just need to suck it up and admit it when they've been dumb. Its a very rare day when something truely radical comes along, and its even rarer when its born of total inexperience.

Nothing to see here...
All the best,
-Ian

PS. ironically, in order to post this, gmane required me to enter a word. That word was "restraint". Gotta love karma.

Previous: Syed M RaihanNext: Jakub Narebski
Message 98 of 102 in “[RFC] Convert builin-mailinfo.c to use The Better String Library.”
  1. Lukas SandströmSep 4, 2007
  2. Alex RiesenSep 4, 2007
  3. Pierre HabouzitSep 4, 2007
  4. Kristian HøgsbergSep 5, 2007
  5. Matthieu MoySep 5, 2007
  6. Miles BaderSep 6, 2007
  7. Dmitry KakurinSep 6, 2007
  8. Shawn O. PearceSep 6, 2007
  9. Andreas EricssonSep 6, 2007
  10. Junio C HamanoSep 6, 2007
  11. Andreas EricssonSep 6, 2007
  12. David KastrupSep 6, 2007
  13. Miles BaderSep 6, 2007
  14. Johannes SchindelinSep 6, 2007
  15. Linus TorvaldsSep 6, 2007
  16. Dmitry KakurinSep 7, 2007
  17. Linus TorvaldsSep 7, 2007
  18. Dmitry KakurinSep 7, 2007
  19. Linus TorvaldsSep 7, 2007
  20. Dmitry KakurinSep 7, 2007
  21. David SymondsSep 7, 2007
  22. Theodore TsoSep 7, 2007
  23. Steven BurnsSep 20, 2007
  24. Andreas EricssonSep 20, 2007
  25. Andreas EricssonSep 7, 2007
  26. Dmitry KakurinSep 7, 2007
  27. David KastrupSep 7, 2007
  28. Dmitry KakurinSep 8, 2007
  29. David KastrupSep 8, 2007
  30. Andreas EricssonSep 9, 2007
  31. David KastrupSep 7, 2007
  32. Johannes SchindelinSep 7, 2007
  33. Johannes SchindelinSep 7, 2007
  34. David KastrupSep 7, 2007
  35. Linus TorvaldsSep 7, 2007
  36. alanSep 7, 2007
  37. Walter BrightSep 7, 2007
  38. David KastrupSep 7, 2007
  39. Walter BrightSep 7, 2007
  40. David KastrupSep 7, 2007
  41. Walter BrightSep 7, 2007
  42. David KastrupSep 7, 2007
  43. Walter BrightSep 7, 2007
  44. David KastrupSep 7, 2007
  45. Walter BrightSep 7, 2007
  46. Andreas EricssonSep 8, 2007
  47. Pierre HabouzitSep 9, 2007
  48. Andreas EricssonSep 9, 2007
  49. Wincent ColaiutaSep 7, 2007
  50. Pierre HabouzitSep 7, 2007
  51. Walter BrightSep 7, 2007
  52. David KastrupSep 7, 2007
  53. Walter BrightSep 7, 2007
  54. Pierre HabouzitSep 7, 2007
  55. David KastrupSep 7, 2007
  56. Pierre HabouzitSep 7, 2007
  57. Walter BrightSep 7, 2007
  58. Pierre HabouzitSep 7, 2007
  59. Walter BrightSep 7, 2007
  60. John 'Z-Bo' ZabroskiSep 8, 2007
  61. David KastrupSep 8, 2007
  62. Steven BurnsSep 19, 2007
  63. Wincent ColaiutaSep 7, 2007
  64. Paul WankadiaSep 7, 2007
  65. Nicolas PitreSep 7, 2007
  66. Wincent ColaiutaSep 7, 2007
  67. Andreas EricssonSep 7, 2007
  68. Johannes SchindelinSep 7, 2007
  69. Andreas EricssonSep 7, 2007
  70. Wincent ColaiutaSep 7, 2007
  71. Karl HasselströmSep 7, 2007
  72. Andreas EricssonSep 7, 2007
  73. Wincent ColaiutaSep 7, 2007
  74. Andreas EricssonSep 9, 2007
  75. David KastrupSep 7, 2007
  76. Wincent ColaiutaSep 7, 2007
  77. Walter BrightSep 7, 2007
  78. Andreas EricssonSep 7, 2007
  79. Walter BrightSep 7, 2007
  80. David KastrupSep 7, 2007
  81. Andreas EricssonSep 9, 2007
  82. Bernd JendrissekSep 17, 2009
  83. Wincent ColaiutaSep 7, 2007
  84. Walter BrightSep 7, 2007
  85. Steven BurnsSep 22, 2007
  86. David KastrupSep 7, 2007
  87. Andy ParkinsSep 7, 2007
  88. David KastrupSep 7, 2007
  89. Johannes SchindelinSep 7, 2007
  90. Dmitry KakurinSep 8, 2007
  91. David KastrupSep 8, 2007
  92. Alex RiesenSep 8, 2007
  93. figoSep 24, 2007
  94. David KastrupSep 24, 2007
  95. Steven BurnsSep 25, 2007
  96. David KastrupSep 25, 2007
  97. Syed M RaihanMay 22, 2012
  98. Ian MoltonJun 10, 2010
  99. Jakub NarebskiJun 11, 2010
  100. Dario RodriguezJun 11, 2010
  101. Kristian HøgsbergSep 5, 2007
  102. Lukas SandströmSep 7, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.