4 ms·

> More times than not the above exercise leads me to a problem that I then can go off and solve. For example, a few weeks ago I sat down and decided I wanted to

> More times than not the above exercise leads me to a problem that I then can go off and solve. For example, a few weeks ago I sat down and decided I wanted to write a web server in go (think nginx/apache). I knew going into the project I wanted a really nice and easy to use configuration file to define the settings. So, I did what most people do these days I and used json, but that didn’t really feel right to me. I then tried yaml, but yet again didn’t feel like what I wanted. I probably could have used ini format and made custom rules for the keys and values, but again, this is hacky. This spawned a new project in order to solve the problem I was having and ended up being forge, which is a hand coded configuration file syntax and parser for go which ended up being a neat mix between json and nginx configuration file syntax. You make a persuasive argument for why someone should not write code every day, but instead step away from the keyboard occasionally and get a sense of perspective. No, your mix between json and nginx configuration file syntax is not "neat". It's pointless, and doesn't solve any real problem. In fact, if anyone ever uses your idea it will cause problems, by adding another random pointless format for the rest of us to have to support. And did you miss the beginning of what you said? You set off to write a web server and instead you got bogged down in parsing the config files. Your efforts did not produce a web server. Writing code every day has apparently not taught you how to focus. In short, quantity of code does not beget quality. Quality code isn't just code that's nicely formatted, clear, terse, etc., it's also code that solves a real problem that you've set out to solve. And just writing more code isn't going to help you learn what a real problem is, let alone how to solve it.

furyofantares 11y ago
The goal, as stated, was to have the experience of writing code. Bringing another web server into existence was not the goal, it was a potential means to the goal.
- hoers 11y ago
  Why not set the goal to 'make something that works'? You'd get the whole 'experience of writing code' with it for free
  - furyofantares 11y ago
    For the same reason athletes have practice routines that are not "play a game of <sport>" -- it allows you to focus your practice. If OP wants to practice writing nontrivial code, re-implementing something is a good way to avoid the MORE difficult problem of having to invent a product. It allows him to concentrate on having a nontrivial coding experience. As an aside, I personally code just for fun. Not for practice, and not to make something. I write a lot of code nobody but me will ever see because I enjoy doing it. Putting pressure on myself to turn each thing into a product can ruin the joy of experimentation. I'm doing it for the joy of doing it, for the same reason I might watch TV or play a video game or do a sudoku puzzle.
    - copsarebastards 11y ago
      Who said anything about a product? You can solve real world problems with code without creating a product. Things don't have to be monetizeable to be useful (and indeed many things that are monetizeable aren't useful (except to make money)). And experimentation is totally a necessary part of solving real-world problems. I'm not sure where you get off representing "solving real problems" as being anti-experimentation.
      - furyofantares 11y ago
        The reason I responded to someone else rather than you is that you do not appear to be making much of an attempt to understand the things you are replying to. You are, to my best estimation, simply being argumentative. For example, in your previous post, you said you could just write echo "Hello World" over and over, which clearly does not give you any practice at writing code and is clearly not related to the conversation. In this post you talk about monetization, something I didn't mention at all, and while "product" may not have been the best possible word I could have used, it makes me think you didn't make much of an attempt to understand my point.
        copsarebastards 11y ago
        > For example, in your previous post, you said you could just write echo "Hello World" over and over, which clearly does not give you any practice at writing code and is clearly not related to the conversation. No, it definitely is practice at writing code; it's just not useful practice. My point is that not all practice is useful. If you're going to accuse me of not making much attempt to understand my point, maybe don't dismiss what I said so easily?
- copsarebastards 11y ago
  If your goal is to have the experience of code, you can achieve that goal by writing echo "Hello, world" in your terminal over and over. Obviously the author's goals are larger than that.
tomjen3 11y ago
As an employee, yes. As a hobby, who cares what he makes? Maybe his config parser is shit, maybe it is the shit. Either way it wouldn't exist without his efforts.
- copsarebastards 11y ago
  It existing is at best no better than it not existing. If you're advising other people to change their behavior (i.e. code every day) then the "why" of the advice certainly matters. It's true that I have no reason to care, if he wants to bash his face into the keyboard and call the results code, that's fine, but if he comes and posts on hacker news about how everyone should bash their faces into their keyboard, I don't feel the need to pretend what he's doing is great because "it wouldn't exist without his efforts".
iamwil 11y ago
"Sometimes, we reinvent the wheel not because we need more wheels, but because we need more inventors."
- copsarebastards 11y ago
  “[A] quotation is a handy thing to have about, saving one the trouble of thinking for oneself, always a laborious business."
  - iamwil 11y ago
    Sometimes people make things that already exist for practice, rather than to have the thing itself. Does that make it more clear for you? Or do you want to troll some more?
    - copsarebastards 11y ago
      It was clear to begin with, thanks, it's just wrong. Practice does not make perfect, perfect practice makes perfect. If you practice doing things wrong, you're just reinforcing a bad habit. And make no mistake: solving solved problems and losing focus on the problem you set out to solve are bad habits, every bit as bad as writing code that segfaults or leaks memory or throws exceptions.
brettlangdon 11y ago
If we are always expected to write new, different, useful, quality code that solves real problems, then no one would ever start programming in the first place. Everyone needs to start somewhere and maybe for a veteran coder the expectation is to solve new real problems, but for those just starting out, writing and re-writing basic conditionals and loops are more important than solving real problems. Each project should end in learning something new. For me this config parser (whether anyone actually finds it useful or not) was learning how to write a scanner/parser from scratch. To try and fill a void in my knowledge, rather than solving real problems.
- copsarebastards 11y ago
  If we aren't expected to write new, different, useful quality code that solves real problems, then there's no reason anyone should start programming in the first place. Everyone needs to start somewhere and maybe for a complete beginner expectations are low, but if you're not veteran enough to solve real world problems then you are in no position to be giving advice like "code every day" on the internet. The nice thing about solving real world problems is that you'll inherently learn something new, not just to you, but to humanity. And lets be clear here: you didn't learn how to write a scanner/parser from scratch, at least not a good one. To do that you would have to read literature and/or look at production code. It's unlikely that you've figured out decades of parser research with your lexer/parser--it's much more likely you've just reproduced a bunch of mistakes that were made and solved in the 60s without even realizing they were mistakes. You could actually learn how to write a good lexer/parser by reading a handful of academic papers or reading through the code of, say, PLY or working with a parser toolkit that exposes its workings like Parsec.

furyofantares 11y ago

The goal, as stated, was to have the experience of writing code. Bringing another web server into existence was not the goal, it was a potential means to the goal.

hoers 11y ago
Why not set the goal to 'make something that works'? You'd get the whole 'experience of writing code' with it for free
- furyofantares 11y ago
  For the same reason athletes have practice routines that are not "play a game of <sport>" -- it allows you to focus your practice. If OP wants to practice writing nontrivial code, re-implementing something is a good way to avoid the MORE difficult problem of having to invent a product. It allows him to concentrate on having a nontrivial coding experience. As an aside, I personally code just for fun. Not for practice, and not to make something. I write a lot of code nobody but me will ever see because I enjoy doing it. Putting pressure on myself to turn each thing into a product can ruin the joy of experimentation. I'm doing it for the joy of doing it, for the same reason I might watch TV or play a video game or do a sudoku puzzle.
  - copsarebastards 11y ago
    Who said anything about a product? You can solve real world problems with code without creating a product. Things don't have to be monetizeable to be useful (and indeed many things that are monetizeable aren't useful (except to make money)). And experimentation is totally a necessary part of solving real-world problems. I'm not sure where you get off representing "solving real problems" as being anti-experimentation.
    - furyofantares 11y ago
      The reason I responded to someone else rather than you is that you do not appear to be making much of an attempt to understand the things you are replying to. You are, to my best estimation, simply being argumentative. For example, in your previous post, you said you could just write echo "Hello World" over and over, which clearly does not give you any practice at writing code and is clearly not related to the conversation. In this post you talk about monetization, something I didn't mention at all, and while "product" may not have been the best possible word I could have used, it makes me think you didn't make much of an attempt to understand my point.
      - copsarebastards 11y ago
        > For example, in your previous post, you said you could just write echo "Hello World" over and over, which clearly does not give you any practice at writing code and is clearly not related to the conversation. No, it definitely is practice at writing code; it's just not useful practice. My point is that not all practice is useful. If you're going to accuse me of not making much attempt to understand my point, maybe don't dismiss what I said so easily?
copsarebastards 11y ago
If your goal is to have the experience of code, you can achieve that goal by writing echo "Hello, world" in your terminal over and over. Obviously the author's goals are larger than that.

tomjen3 11y ago

As an employee, yes. As a hobby, who cares what he makes? Maybe his config parser is shit, maybe it is the shit. Either way it wouldn't exist without his efforts.

copsarebastards 11y ago
It existing is at best no better than it not existing. If you're advising other people to change their behavior (i.e. code every day) then the "why" of the advice certainly matters. It's true that I have no reason to care, if he wants to bash his face into the keyboard and call the results code, that's fine, but if he comes and posts on hacker news about how everyone should bash their faces into their keyboard, I don't feel the need to pretend what he's doing is great because "it wouldn't exist without his efforts".

iamwil 11y ago

"Sometimes, we reinvent the wheel not because we need more wheels, but because we need more inventors."

copsarebastards 11y ago
“[A] quotation is a handy thing to have about, saving one the trouble of thinking for oneself, always a laborious business."
- iamwil 11y ago
  Sometimes people make things that already exist for practice, rather than to have the thing itself. Does that make it more clear for you? Or do you want to troll some more?
  - copsarebastards 11y ago
    It was clear to begin with, thanks, it's just wrong. Practice does not make perfect, perfect practice makes perfect. If you practice doing things wrong, you're just reinforcing a bad habit. And make no mistake: solving solved problems and losing focus on the problem you set out to solve are bad habits, every bit as bad as writing code that segfaults or leaks memory or throws exceptions.

brettlangdon 11y ago

If we are always expected to write new, different, useful, quality code that solves real problems, then no one would ever start programming in the first place. Everyone needs to start somewhere and maybe for a veteran coder the expectation is to solve new real problems, but for those just starting out, writing and re-writing basic conditionals and loops are more important than solving real problems. Each project should end in learning something new. For me this config parser (whether anyone actually finds it useful or not) was learning how to write a scanner/parser from scratch. To try and fill a void in my knowledge, rather than solving real problems.

copsarebastards 11y ago
If we aren't expected to write new, different, useful quality code that solves real problems, then there's no reason anyone should start programming in the first place. Everyone needs to start somewhere and maybe for a complete beginner expectations are low, but if you're not veteran enough to solve real world problems then you are in no position to be giving advice like "code every day" on the internet. The nice thing about solving real world problems is that you'll inherently learn something new, not just to you, but to humanity. And lets be clear here: you didn't learn how to write a scanner/parser from scratch, at least not a good one. To do that you would have to read literature and/or look at production code. It's unlikely that you've figured out decades of parser research with your lexer/parser--it's much more likely you've just reproduced a bunch of mistakes that were made and solved in the 60s without even realizing they were mistakes. You could actually learn how to write a good lexer/parser by reading a handful of academic papers or reading through the code of, say, PLY or working with a parser toolkit that exposes its workings like Parsec.