-3

I recently asked a question on StackOverflow that was related to string splitting and pattern matching in .NET.

Some beady eyed developers that viewed the question said: "It looks like you're trying to parse a JSON string...why don't you just use JSON.NET or JavaScriptSerializer".

The conversation went off at on a tangent, (and was voted down, most likely because they could not see the point of writing some functionality, which has already been done.)

I have my reasons for writing this functionality...my implementation so far is slick, and super-fast (though suffers a little with string splitting, hence the StackOverflow question).

I think the point these developers were trying to make was, "why reinvent the wheel?"

I might equally argue: "Why bother developing NHibernate, when Microsoft have built a perfectly good Entity Framework?", or "Why bother building Windows 8, when Windows 7 is a perfectly suitable desktop operating system?" The same principle applies, does it not?

When an automobile company designs a new car, they are not re-inventing the wheel; rather, they are improving on the technology that drives it. Similarly, my JSON parser is a nice, neat and fast implementation (although, as states above, suffers a little on string splitting), therefore, when my parser is ready, should I be shunned for writing something that has already been done, or praised for doing it better?

EDIT: Consider the following Q/A : Is reinventing the wheel really all that bad?

  • Your examples really need to be better; at the moment they aren't examples of what you're doing. – AakashM Mar 04 '13 at 09:37
  • 1
    NHibernate came before EntityFramework. "Windows 8 vs Windows 7" is flame bait. Please fix your examples. – Euphoric Mar 04 '13 at 09:37
  • 10
    Is this a question or a rant? – Carson63000 Mar 04 '13 at 09:42
  • @AakashM, OK, so taking a very literal example, The tires on a Nissan GTR are filled with nitrogen because it improves the way that the tire works in certain conditions, thus improving performance and economy. They didn't re-invent the wheel, they just improved its technology. – Matthew Layton Mar 04 '13 at 09:43
  • @Carson63000, it's a genuine question. I'm just trying to work out the morale behind using a proven technology, when my idea may well improve upon it. – Matthew Layton Mar 04 '13 at 09:44
  • 2
    @series0ne To improve on something, you first need to get on same level. If you have source code, or if the library provides necessary API, then improving shouldn't be a problem. But "rewriting" something from scratch to "improve" it would take massive effort, because you have to reimplement existing functionality. – Euphoric Mar 04 '13 at 09:54
  • It's better to re-use someone else's FTP client in your enterprise app. But if your entire project *IS* an FTP client, then go for it. Reinvention is a good thing. I think the line is drawn where you are gluing together many tools into a bigger app, or directly implementing a specific tool. – mike30 Mar 04 '13 at 14:08
  • In my opinion, if you want to create a better mousetrap, you'd better be one of those people answering questions on Stack Overflow, not one of those people asking the questions. – Gilbert Le Blanc Mar 04 '13 at 14:57

1 Answers1

5

There are 2 reasons why this happens:

  1. Someone thinks they can do it better. This is case of NHibernate vs Entity Framework. They were created by different (groups of) people to solve same problems. They both approached the problem from different side, thinking they will be better at solving it. Every time someone does this, they need to be sure, they are able to create something better than what exists. If your JSON parser you wrote in a week cannot do everything existing JSON parsers do and something more, then it is worthless. Or if this JSON parser does it in way that you need but other JSON parsers cannot provide. But JSON parsing is relatively simple and it is hard to believe you would need something other parsers don't provide. Only reason why you would create it is to learn how to write JSON parsers.
  2. The problems change. This is case of Windows 8 vs Windows 7. Win 8 was created for new age, where touch, app stores, locked down platforms and small devices have future, instead of old heavy desktops, keyboard and mouse. This doesn't seem to be your problem, because JSON is still one of the top choices for data serialization. Of course it would be worth it if you came up with a storage format that would be somehow better than JSON. And I hardly doubt that.
Euphoric
  • 36,735
  • 6
  • 78
  • 110
  • Thanks for this answer. This certainly does address some of the points raised. It's interesting that you said "Of course it would be worth it if you came up with a storage format that would be somehow better than JSON. And I hardly doubt that." - as a matter of fact, I do have an idea where the functionality of JSON can be extended in some respects. Whether it would be adopted or not, is another matter (unlikely) - which could make my idea pointless, however "nothing ventured, nothing gained" – Matthew Layton Mar 04 '13 at 10:00
  • The question is if you want to extend JSON. In some cases the lack of features makes a technology great. A famous person once said: 'Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away.' – Tarilo Mar 04 '13 at 10:16
  • 1
    @Tarilo: But then the same argument could be made of Entity Framework and Dapper. The former is complex, heavy-weight and covers pretty much any sensible scenario. The latter is very lightweight, but does the job in 90% of cases. Which one shouldn't exist? – pdr Mar 04 '13 at 10:32
  • 1
    I can think of a third reason - you don't want to rely on third party components where you cannot control the further development, where you have problems withe the licence terms, or where the component, even when open source, is so big or complex that you don't want to get in a situation where you have to search for bugs in that component. For example, that is most probably the real case behind "NHibernate vs Entity Framework". This reason may apply to a JSON parser, too. – Doc Brown Mar 04 '13 at 12:28