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.

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.

Why not set the goal to 'make something that works'? You'd get the whole 'experience of writing code' with it for free

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.

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.

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.

> 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?

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

“[A] quotation is a handy thing to have about, saving one the trouble of thinking for oneself, always a laborious business."

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?

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.

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.

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.

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.

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".