6 ms·

Sorry, this is a terrible article. It reads more as a stream of consciousness about his own mistakes and sad regrets, and does not add any new or interesting in

Sorry, this is a terrible article. It reads more as a stream of consciousness about his own mistakes and sad regrets, and does not add any new or interesting insight into anything regarding databases. There are plenty of new cool things we can do now - and the graph database we're building ( http://github.com/amark/gun http://github.com/amark/gun ) is doing several of those things. Like realtime by default, like what Firebase and RethinkDB are starting to push. Fully decentralized and fault tolerant, like what Riak and Cassandra tried to do. Graph (and not just triples) so you can have relational documents as ArangoDB and Neo4j allow. And absolutely totally offline-first, like what Pouch/CouchDB wanted to pioneer. The truth is the world of databases are only getting better and more exciting - in large part due to new algorithms like CRDTs that push what we can do. GUN is one player in that along with others. But this article? Just depressing and overlooking all the new opportunities.

jmatthews 11y ago
Respectfully, the article is terrible from your perspective. To someone not steeped in the state of the art goings on of modern DB it serves as a reasonable introduction. E.G. - Imagine yourself with a passing knowledge of RDB based on common web development. This serves as an eye opener. You personally, may not be the intended audience.
- marknadal 11y ago
  Fair enough. I accept this critique.
lobster_johnson 11y ago
I often see you plug your project, Gun, whenever someone posts about distributed databases. You always write about how great it is. But every time I look at your repo, it's still the same few hundred lines of, I'm sorry, quite shoddily written JavaScript, with huge chunks clearly being temporary placeholders or even commented out. You even have scratch test data in there, intermingled with your main code. Your web site also make some grandiose claims about how it solves certain synchronization problems, but I can't find any technical explanation of exactly how it is supposed to work. The lack of code or documentation means it's very hard to take your comments seriously. But please correct me if I'm mistaken.
- marknadal 11y ago
  Thanks for the comment but I'm going to provide a hard rebuttal: 1) You assume that you have to have lots of code in order to solve hard problems. If that is your approach to code then I cannot appease you. GUN takes the UNIX/NodeJS philosophy - it is suppose to do one thing well and everything else is solved via extensions and plugins. What GUN focuses on is conflict resolution which you can see demos and learn more about here: https://youtu.be/-i-11T5ZI9o https://youtu.be/-i-11T5ZI9o , https://github.com/amark/gun/wiki/Conflict-Resolution-with-Guns https://github.com/amark/gun/wiki/Conflict-Resolution-with-G... , and towards the end of this tech talk https://youtu.be/kzrmAdBAnn4 https://youtu.be/kzrmAdBAnn4 . 2) I'm sorry you think my javascript is shoddy, however this is either a matter of arbitrary aesthetic opinion or some objective measure. You provide no objective measure. I'll propose one instead - does it work? And it does, however I'll be the first to admit it is not free of bugs. We're actually dealing with some bad bugs that emerge when you do more complicated permutations of commands, to which we're in the middle of a big rewrite. I hope you'll find the new version (0.3.x, not out yet) as less shoddy. However apart from subjective aesthetics, I don't find your comment to have any justification. 3) What do you mean that we have scratch test data in there intermingled with the main code? I don't think this is true, but I'm not sure what you mean. If you think this is an issue it would be great if you raised an issue on the project. Thanks in advance. :) Please let me know if you've actually read through the entire wiki ( https://github.com/amark/gun/wiki https://github.com/amark/gun/wiki ) and if there is anything you need to learn more about (which I'm sure there is) please don't hesitate to ask me and I'd be happy to write documentation on it. In fact, we need people like you to report what parts of the documentation are confusing or incomplete in order for us to know to fill it in. Thanks for your comments, and please don't take me harshly - I just want to be hard on dispelling the terrible assumption that lines of code equates to quality or problem solving. Often times more lines just creates more bloat, monolithism, and increased bug complexity.
  - atombender 11y ago
    My main point is that it's impossible to reconcile your lofty claims about Gun with, frankly, the unreadable mess you have in your repo. It doesn't matter if your ideas are great. You keep putting Gun forward as a kind of shiny, superior successor to Riak, Cassandra and CouchDB, which I'm afraid only makes you look foolish. You seem to have done the branding before you did the code. First you need to demonstrate solid, mature code. Then you can try competing with the big boys. A detailed critique of your code would take a lot of effort, but I've made some notes [1]. I find the code to be unreadable and full of bad code smell. With all the mutation and callbacks and events and what not going on, it's just too hard to tell how the code is intended to flow. I don't see a clean API, even an internal one, nor I see a clean structure. It needs a lot of cleanup [2]. When talking about code, it's rarely just aesthetic. My philosophy is that if one can't even manage the trivially superficial aspects of code (formatting, structuring files, naming variables, and so on), it's not worth talking about its inner workings. Sorry if this comes across as terribly harsh, but I hope you can see I'm trying to be constructive. --- [1] A few examples: * Your code is littered with arbitrary console.log() statements that have no actual utility. They look the kind of temporary logging I insert whenever I need to trace a difficult behaviour. * No code is documented, aside from childish comments like: } // IT WORKS!!!!!! * Lots of what looks like global state. * Lots of anonymously named variables like r, u, n. * Big chunks of commented-out code (e.g., in radix.js). * Lots of what looks like test data. Are you telling me this is part of the project? rad('user/marknadal', {'#': 'asdf'}); * Lots of mutation. E.g., in s3.js you get some kind of event and then you modify the inputs. * Syntax formatting is inconsistent and shoddy. * require() calls in the middle of code. * You have a test folder, but it's barely got any actual tests. You do have at least one commented-out test in the middle of everything (list.js, line 25). [2] You may want to look into replacing callbacks with promises, and restructure it using more classical ES6-based OO, as opposed to the prototype-based, lexically-scoped style you're using now.
jchrisa 11y ago
I take issue with the use of past tense for the Couch ecosystem. Things in our neck of the woods indicate the hockey stick is kicking in for offline first, especially with the Internet of Things. Example: http://www.couchbase.com/nosql-resources/presentations/offline-first-and-how-ge-integrated-couchbase-mobile-in-less-than-90-days.html http://www.couchbase.com/nosql-resources/presentations/offli...
- marknadal 11y ago
  Thank you for correcting me. I obviously have not kept up with the ecosystem (I jumped ship sometime in 2011), so pardon me. I'm excited about the progress!
- jchrisa 11y ago
  In the consumer apps space we are seeing airline booking and other location critical verticals pick us up. Here's Ryanair's story. http://www.couchbase.com/nosql-resources/presentations/how-ryanair-reduced-booking-time-from-5-to-less-than-2-minutes.html http://www.couchbase.com/nosql-resources/presentations/how-r...

jmatthews 11y ago

Respectfully, the article is terrible from your perspective. To someone not steeped in the state of the art goings on of modern DB it serves as a reasonable introduction. E.G. - Imagine yourself with a passing knowledge of RDB based on common web development. This serves as an eye opener. You personally, may not be the intended audience.

marknadal 11y ago
Fair enough. I accept this critique.

lobster_johnson 11y ago

I often see you plug your project, Gun, whenever someone posts about distributed databases. You always write about how great it is. But every time I look at your repo, it's still the same few hundred lines of, I'm sorry, quite shoddily written JavaScript, with huge chunks clearly being temporary placeholders or even commented out. You even have scratch test data in there, intermingled with your main code. Your web site also make some grandiose claims about how it solves certain synchronization problems, but I can't find any technical explanation of exactly how it is supposed to work. The lack of code or documentation means it's very hard to take your comments seriously. But please correct me if I'm mistaken.

marknadal 11y ago
Thanks for the comment but I'm going to provide a hard rebuttal: 1) You assume that you have to have lots of code in order to solve hard problems. If that is your approach to code then I cannot appease you. GUN takes the UNIX/NodeJS philosophy - it is suppose to do one thing well and everything else is solved via extensions and plugins. What GUN focuses on is conflict resolution which you can see demos and learn more about here: https://youtu.be/-i-11T5ZI9o https://youtu.be/-i-11T5ZI9o , https://github.com/amark/gun/wiki/Conflict-Resolution-with-Guns https://github.com/amark/gun/wiki/Conflict-Resolution-with-G... , and towards the end of this tech talk https://youtu.be/kzrmAdBAnn4 https://youtu.be/kzrmAdBAnn4 . 2) I'm sorry you think my javascript is shoddy, however this is either a matter of arbitrary aesthetic opinion or some objective measure. You provide no objective measure. I'll propose one instead - does it work? And it does, however I'll be the first to admit it is not free of bugs. We're actually dealing with some bad bugs that emerge when you do more complicated permutations of commands, to which we're in the middle of a big rewrite. I hope you'll find the new version (0.3.x, not out yet) as less shoddy. However apart from subjective aesthetics, I don't find your comment to have any justification. 3) What do you mean that we have scratch test data in there intermingled with the main code? I don't think this is true, but I'm not sure what you mean. If you think this is an issue it would be great if you raised an issue on the project. Thanks in advance. :) Please let me know if you've actually read through the entire wiki ( https://github.com/amark/gun/wiki https://github.com/amark/gun/wiki ) and if there is anything you need to learn more about (which I'm sure there is) please don't hesitate to ask me and I'd be happy to write documentation on it. In fact, we need people like you to report what parts of the documentation are confusing or incomplete in order for us to know to fill it in. Thanks for your comments, and please don't take me harshly - I just want to be hard on dispelling the terrible assumption that lines of code equates to quality or problem solving. Often times more lines just creates more bloat, monolithism, and increased bug complexity.
- atombender 11y ago
  My main point is that it's impossible to reconcile your lofty claims about Gun with, frankly, the unreadable mess you have in your repo. It doesn't matter if your ideas are great. You keep putting Gun forward as a kind of shiny, superior successor to Riak, Cassandra and CouchDB, which I'm afraid only makes you look foolish. You seem to have done the branding before you did the code. First you need to demonstrate solid, mature code. Then you can try competing with the big boys. A detailed critique of your code would take a lot of effort, but I've made some notes [1]. I find the code to be unreadable and full of bad code smell. With all the mutation and callbacks and events and what not going on, it's just too hard to tell how the code is intended to flow. I don't see a clean API, even an internal one, nor I see a clean structure. It needs a lot of cleanup [2]. When talking about code, it's rarely just aesthetic. My philosophy is that if one can't even manage the trivially superficial aspects of code (formatting, structuring files, naming variables, and so on), it's not worth talking about its inner workings. Sorry if this comes across as terribly harsh, but I hope you can see I'm trying to be constructive. --- [1] A few examples: * Your code is littered with arbitrary console.log() statements that have no actual utility. They look the kind of temporary logging I insert whenever I need to trace a difficult behaviour. * No code is documented, aside from childish comments like: } // IT WORKS!!!!!! * Lots of what looks like global state. * Lots of anonymously named variables like r, u, n. * Big chunks of commented-out code (e.g., in radix.js). * Lots of what looks like test data. Are you telling me this is part of the project? rad('user/marknadal', {'#': 'asdf'}); * Lots of mutation. E.g., in s3.js you get some kind of event and then you modify the inputs. * Syntax formatting is inconsistent and shoddy. * require() calls in the middle of code. * You have a test folder, but it's barely got any actual tests. You do have at least one commented-out test in the middle of everything (list.js, line 25). [2] You may want to look into replacing callbacks with promises, and restructure it using more classical ES6-based OO, as opposed to the prototype-based, lexically-scoped style you're using now.

jchrisa 11y ago

I take issue with the use of past tense for the Couch ecosystem. Things in our neck of the woods indicate the hockey stick is kicking in for offline first, especially with the Internet of Things. Example: http://www.couchbase.com/nosql-resources/presentations/offline-first-and-how-ge-integrated-couchbase-mobile-in-less-than-90-days.html http://www.couchbase.com/nosql-resources/presentations/offli...

marknadal 11y ago
Thank you for correcting me. I obviously have not kept up with the ecosystem (I jumped ship sometime in 2011), so pardon me. I'm excited about the progress!
jchrisa 11y ago
In the consumer apps space we are seeing airline booking and other location critical verticals pick us up. Here's Ryanair's story. http://www.couchbase.com/nosql-resources/presentations/how-ryanair-reduced-booking-time-from-5-to-less-than-2-minutes.html http://www.couchbase.com/nosql-resources/presentations/how-r...