4 ms·

First anything I've contributed to the community. As a 16 year-old just getting into software development, it'd be amazing to get feedback from hn.

by knrz 12y ago

qubyte 12y ago
You should ditch CoffeeScript and do it in vanilla JS, if for no other reason than to avoid people like me telling you to ditch CoffeeScript and do it in vanilla JS. ;) In all seriousness though, far beyond anything I was doing at 16. Kudos.
- mercer 12y ago
  I second this. I use and like CoffeeScript, especially if I'm pretty sure nobody else will touch my code, and especially if I'm just tinkering or exploring. But after doing a lot of mostly CoffeeScript, I had to do some 'plain' JS work, and it took me a while to get back into it. And that can be a problem if you just need to get stuff done sometimes. (PS: kudos for submitting this! I'm more than a decade older than you are, and I get nervous just thinking of sharing my code with this crowd!)
  - knrz 12y ago
    Repo updated, pure JS now :D.
batuhanicoz 12y ago
Some feedback: - Vanilla JS would be cleaner - Make it useable with Node. (Check if "window" variable exists, if not, do export CSV as a module. Should be this easy AFAIK) - You have some typos on the README.md - Put this on bower and npm Good work. I was writing software at 16 but I wasn't doing it open source, I wish I did.
- untog 12y ago
  Vanilla JS would be cleaner Depends on your definition of 'clean' - IMO CoffeeScript is much cleaner than JS. But yes, more difficult to work with.
- knrz 12y ago
  Vanilla JS is up :) It's now usable with both Node and AMD. Typos should all be fixed. I'll put up on bower and npm once I become RFC4180 compliant. Thanks for the feedback!
  - cabbeer 12y ago
    What's AMD? I keep seeing that acronym but searching it just returns "Advanced Micro Devices"
    - batuhanicoz 12y ago
      Asynchronous Module Definition[0]. [0] http://en.wikipedia.org/wiki/Asynchronous_module_definition http://en.wikipedia.org/wiki/Asynchronous_module_definition
danso 12y ago
The fact that you're 16 and getting into software development is cool, but not particularly exceptional. I don't know how much more exceptional it is that you're already into OSS, as that was less of a concept when I was at that age...though I'm going to say that as someone much older than you who is just now slowly contributing to OSS, you're probably ahead of the curve. But what impresses me most is that you're only 16 and you care enough about something as "boring", yet bread-and-butter as CSV parsing. CSV-parsing is not particularly sexy, and there are a lot of libs that do it...but tackling it as a problem to solve, nevermind open-sourcing your solution, is really cool...even if you decide you don't want to be a full-time software developer, your experience (and tolerance) for this kind of data-munging is going to make you a valuable person to work with in any field. The fact that you're taking the time to write readable documentation for this puts you even farther afield. In terms of criticism/feedback...what was your reasoning for returning an Object with certain domain-specific properties (i.e. `data` and `fields`) rather than just an Array of hashes? I think the CSV constructor call works fine, and that being the case, maybe add an option in the options hash to return a CSV-object-with-metadata...but by default, `csv.parse()` should return a plain array of objects, so that other programs that utilize it don't have to remember that the data is actually in the Object's `data` property. Also, you've probably seen D3's implementation, which is designed with the mindset that the CSV-to-be-parsed is likely an external file: https://github.com/mbostock/d3/wiki/CSV https://github.com/mbostock/d3/wiki/CSV
- knrz 12y ago
  I had some inspiration from PapaParse, which is why I went with a returned object. However, after reading your comment, remembering how Ruby does it, and some thought, I decided to default to a returned array but provide the option for a more 'detailed' response.
- Monkeyget 12y ago
  I wish there had been a github when I was his age. I remember writing a .ini file parser in Java. I showed it to my friends who couldn't care less and... that was the end of it.
  - 12y ago
mholt 12y ago
Where did you get your inspiration? This is pretty similar to a library I'm actively working on called Papa Parse: http://papaparse.com http://papaparse.com
- knrz 12y ago
  It was actually your library that inspired me :). My reason for making this was a mix of "hey let's try making this", let me make something even shorter and (hopefully) sweeter, and "no jQuery".
  - mholt 12y ago
    Okay, cool. I'm surprised--but pleased--since inspiring others to code is one of my ambitions. Your parser is off to a good start: you nailed the general idea of good API design. In other words, it's easy to use, which is immediately appealing. For other things, I think there's been great feedback in the rest of these comments. (By the way, Papa Parse only uses jQuery for convenience in interacting with the DOM for things like file input elements. The core parser, including the file streamer, is vanilla Javascript.)
- gav 12y ago
  Note that it fails to parse CSV like: "x",""x"",,"x x","x" "y",,,,123
  - knrz 12y ago
    The previous commit (probably) failed at that. However, with the latest commit, parsing that malformatted CSV returns: [ ["x","x\"","","x"], ["x","x"], ["y","","","",123] ] I can't see anything wrong with it. Am I missing something?
    - gav 12y ago
      It should parse as: [ ["x","\"x\"","","x\nx","x"], ["y","","","",123] ] It's valid CSV, inasmuch as it's accepted and generated by a lot of tools and RFC 4180 ABNF: escaped = DQUOTE *(TEXTDATA / COMMA / CR / LF / 2DQUOTE) DQUOTE
EvanPlaice 12y ago
Don't cast by default. It unnecessarily slows down the parser when the input is purely string data. Don't hesitate to look at how other CSV libraries work. They've likely solved most/all of the issues you're currently having. Do add the ability to cast scalar values (ex ints, floats). Do verify RFC compliance using tests. Do use vanilla Javascript. Niceties like Coffeescript are good for one-off webapps but add unnecessary dependencies/problems if you're targeting a larger audience. Do have a solid plan for versioning. Only add backwards-incompatible changes to major versions (ie 1.0, 2.0). Do have your users try the code in different browsers/platforms. Differences in Regex implementations can cause problems and using streams in Node will be completely different than handling them in the browser. You win the million dollar prize if you can manage to figure out how to write a CSV stream reader that works in the browser.

First anything I've contributed to the community. As a 16 year-old just getting into software development, it'd be amazing to get feedback from hn.

by knrz 12y ago

First anything I've contributed to the community. As a 16 year-old just getting into software development, it'd be amazing to get feedback from hn.

qubyte 12y ago

You should ditch CoffeeScript and do it in vanilla JS, if for no other reason than to avoid people like me telling you to ditch CoffeeScript and do it in vanilla JS. ;) In all seriousness though, far beyond anything I was doing at 16. Kudos.

mercer 12y ago
I second this. I use and like CoffeeScript, especially if I'm pretty sure nobody else will touch my code, and especially if I'm just tinkering or exploring. But after doing a lot of mostly CoffeeScript, I had to do some 'plain' JS work, and it took me a while to get back into it. And that can be a problem if you just need to get stuff done sometimes. (PS: kudos for submitting this! I'm more than a decade older than you are, and I get nervous just thinking of sharing my code with this crowd!)
- knrz 12y ago
  Repo updated, pure JS now :D.

batuhanicoz 12y ago

Some feedback: - Vanilla JS would be cleaner - Make it useable with Node. (Check if "window" variable exists, if not, do export CSV as a module. Should be this easy AFAIK) - You have some typos on the README.md - Put this on bower and npm Good work. I was writing software at 16 but I wasn't doing it open source, I wish I did.

untog 12y ago
Vanilla JS would be cleaner Depends on your definition of 'clean' - IMO CoffeeScript is much cleaner than JS. But yes, more difficult to work with.
knrz 12y ago
Vanilla JS is up :) It's now usable with both Node and AMD. Typos should all be fixed. I'll put up on bower and npm once I become RFC4180 compliant. Thanks for the feedback!
- cabbeer 12y ago
  What's AMD? I keep seeing that acronym but searching it just returns "Advanced Micro Devices"
  - batuhanicoz 12y ago
    Asynchronous Module Definition[0]. [0] http://en.wikipedia.org/wiki/Asynchronous_module_definition http://en.wikipedia.org/wiki/Asynchronous_module_definition

danso 12y ago

The fact that you're 16 and getting into software development is cool, but not particularly exceptional. I don't know how much more exceptional it is that you're already into OSS, as that was less of a concept when I was at that age...though I'm going to say that as someone much older than you who is just now slowly contributing to OSS, you're probably ahead of the curve. But what impresses me most is that you're only 16 and you care enough about something as "boring", yet bread-and-butter as CSV parsing. CSV-parsing is not particularly sexy, and there are a lot of libs that do it...but tackling it as a problem to solve, nevermind open-sourcing your solution, is really cool...even if you decide you don't want to be a full-time software developer, your experience (and tolerance) for this kind of data-munging is going to make you a valuable person to work with in any field. The fact that you're taking the time to write readable documentation for this puts you even farther afield. In terms of criticism/feedback...what was your reasoning for returning an Object with certain domain-specific properties (i.e. `data` and `fields`) rather than just an Array of hashes? I think the CSV constructor call works fine, and that being the case, maybe add an option in the options hash to return a CSV-object-with-metadata...but by default, `csv.parse()` should return a plain array of objects, so that other programs that utilize it don't have to remember that the data is actually in the Object's `data` property. Also, you've probably seen D3's implementation, which is designed with the mindset that the CSV-to-be-parsed is likely an external file: https://github.com/mbostock/d3/wiki/CSV https://github.com/mbostock/d3/wiki/CSV

knrz 12y ago
I had some inspiration from PapaParse, which is why I went with a returned object. However, after reading your comment, remembering how Ruby does it, and some thought, I decided to default to a returned array but provide the option for a more 'detailed' response.
Monkeyget 12y ago
I wish there had been a github when I was his age. I remember writing a .ini file parser in Java. I showed it to my friends who couldn't care less and... that was the end of it.
- 12y ago

mholt 12y ago

Where did you get your inspiration? This is pretty similar to a library I'm actively working on called Papa Parse: http://papaparse.com http://papaparse.com

knrz 12y ago
It was actually your library that inspired me :). My reason for making this was a mix of "hey let's try making this", let me make something even shorter and (hopefully) sweeter, and "no jQuery".
- mholt 12y ago
  Okay, cool. I'm surprised--but pleased--since inspiring others to code is one of my ambitions. Your parser is off to a good start: you nailed the general idea of good API design. In other words, it's easy to use, which is immediately appealing. For other things, I think there's been great feedback in the rest of these comments. (By the way, Papa Parse only uses jQuery for convenience in interacting with the DOM for things like file input elements. The core parser, including the file streamer, is vanilla Javascript.)
gav 12y ago
Note that it fails to parse CSV like: "x",""x"",,"x x","x" "y",,,,123
- knrz 12y ago
  The previous commit (probably) failed at that. However, with the latest commit, parsing that malformatted CSV returns: [ ["x","x\"","","x"], ["x","x"], ["y","","","",123] ] I can't see anything wrong with it. Am I missing something?
  - gav 12y ago
    It should parse as: [ ["x","\"x\"","","x\nx","x"], ["y","","","",123] ] It's valid CSV, inasmuch as it's accepted and generated by a lot of tools and RFC 4180 ABNF: escaped = DQUOTE *(TEXTDATA / COMMA / CR / LF / 2DQUOTE) DQUOTE

EvanPlaice 12y ago

Don't cast by default. It unnecessarily slows down the parser when the input is purely string data. Don't hesitate to look at how other CSV libraries work. They've likely solved most/all of the issues you're currently having. Do add the ability to cast scalar values (ex ints, floats). Do verify RFC compliance using tests. Do use vanilla Javascript. Niceties like Coffeescript are good for one-off webapps but add unnecessary dependencies/problems if you're targeting a larger audience. Do have a solid plan for versioning. Only add backwards-incompatible changes to major versions (ie 1.0, 2.0). Do have your users try the code in different browsers/platforms. Differences in Regex implementations can cause problems and using streams in Node will be completely different than handling them in the browser. You win the million dollar prize if you can manage to figure out how to write a CSV stream reader that works in the browser.