Live data from Hacker News

Challenging projects every programmer should try (2019)

austinhenley.com

241–250 of 346 posts

Re: Challenging projects every programmer should try (2019)

#241
post #24

While writing a text editor, a compiler, an operating system, or a raytracer might make you a better programmer, it won't make you a better software engineer. In fact, it might make you worse at software engineering, because it embodies the disastrous "Not Invented Here" doctrine. Hackers like to obsess about Big-O, data structures, HoTT, and other high-theory stuff, yet the following skills, essential for software e…

> In fact, it might make you worse at software engineering, because it embodies the disastrous "Not Invented Here" doctrine

I get your point against NIH, but I don't see how doing such a project on your own in your freetime could possibly make you a worse programmer. If anything, you would likely learn exactly what it takes to go down the NIH path so strictly and be able to make better choices

Re: Challenging projects every programmer should try (2019)

#242

I think a little toy raytracer is another great thing to try out. Just something that outputs bitmap graphics of spheres and does diffuse and specular reflection, couple light sources. Should be a relatively self-limited project if you don't go too crazy with it.

that's listed in the followup post, and a lot of people have done it within a day. it's a pretty amazing cost-to-benefit ratio

Re: Challenging projects every programmer should try (2019)

#243
post #23

For a more UI / Web based slant, I would recommend these (beyond a Spreadsheet - which is incredibly helpful for understanding data flow systems): * Simple video game using Unity or Unreal (understanding perf limitations in a game where 30-60 fps is critical helps make performant interfaces elsewhere - even on Web) * A simple Javascript framework similar to React (again, will help understand data flow & handling even…

maybe godot would be a better alternative to unity and unreal for this? because, quite aside from not having to wallow in proprietary licensing, you can find out what's going on

Re: Challenging projects every programmer should try (2019)

#244
post #24

While writing a text editor, a compiler, an operating system, or a raytracer might make you a better programmer, it won't make you a better software engineer. In fact, it might make you worse at software engineering, because it embodies the disastrous "Not Invented Here" doctrine. Hackers like to obsess about Big-O, data structures, HoTT, and other high-theory stuff, yet the following skills, essential for software e…

> might make you a better programmer, it won't make you a better software engineer

This is the distinction between solving "local" problems and solving problems at scale.

But I think there is a transitional phase where requirements (gathering, documenting), unit testing, UI design (human or programmatical) are essential. Learning these as nuts-and-bolts in any language is essential to becoming skilled in the craft.

Re: Challenging projects every programmer should try (2019)

#245
post #143

Earlier quoted context omitted.

I don’t really see how one could have any hope of performing engineering with any sort of rigor while throwing away big-O. Then again, big-O is useless in many cases because real computers have too many arbitrary performance thresholds. I suspect software engineering is impossible, or at least, nobody has made the model required to do it.

So you say software engineering is not real engineering I will drop this link here: https://youtu.be/RhdlBHHimeM?feature=shared

It is an hour long, he’s a good speaker, but what’s his point or where’s he get to it?

Re: Challenging projects every programmer should try (2019)

#246
post #107

Earlier quoted context omitted.

I don't understand why you think a search engine requires the use of "real engineering skills" like picking and choosing libraries and identifying which opportunities will yield fruitful optimization. Literally all of the listed projects, text editors, compilers, operating systems, and ray tracers, can exercise the exact same activities. I'm more inclined to think that your comment is really more revealing about what…

> Literally all of the listed projects, text editors, compilers, operating systems, and ray tracers, can exercise the exact same activities. In the linked article, these projects are all explicitly described as opportunities to learn about low-level stuff like how to efficiently store editable text. The difference with a web search engine is that nobody today can build such a thing completely from scratch, therefore…

Well, if I’m going to build a web search engine from scratch don’t I first need to write a compiler from scratch? Which means I first need to write an editor from scratch…

Re: Challenging projects every programmer should try (2019)

#247
On the text editor one:

> The biggest challenge is figuring out how to store the text document in memory. My first thought was to use an array, but that has horrible performance if the user inserts text anywhere other than the end of the document.

I guess this is only an issue in low level languages, as I just used a JavaScript string and I don't think it's been a perf issue in 2+ years using my editor full time. Plenty of other things have been, of course - rendering long horizontal lines comes to mind, as my approach to optimisation assumed rendering a single line would be cheap and expanding the logic to render partial lines would add another whole dimension of complexity.

(By "long" I mean an entire minified file, for example.)

Re: Challenging projects every programmer should try (2019)

#248
post #142

Earlier quoted context omitted.

I don’t really see how one could have any hope of performing engineering with any sort of rigor while throwing away big-O. Then again, big-O is useless in many cases because real computers have too many arbitrary performance thresholds. I suspect software engineering is impossible, or at least, nobody has made the model required to do it.

Going from O(n) to O(1) on an operation where n is 10 could be a performance downgrade. That doesn't mean it's useless, it just means there's more to it than the big O. Asymptotic complexity is about how things scale up. You should care about it when you're working with things that scale. Doesn't mean it's useless if your data is static, just means you need to understand when to go for the high scaling solution and w…

It can be useful in general, but it is hard to provide the type of tolerances expressed in physical units you’d expect in an engineered solution when all the constants are ignored.

Re: Challenging projects every programmer should try (2019)

#249
post #24

While writing a text editor, a compiler, an operating system, or a raytracer might make you a better programmer, it won't make you a better software engineer. In fact, it might make you worse at software engineering, because it embodies the disastrous "Not Invented Here" doctrine. Hackers like to obsess about Big-O, data structures, HoTT, and other high-theory stuff, yet the following skills, essential for software e…

There are a few things on this comments that is causing noise in my mind.

>might make you a better programmer, it won't make you a better software engineer

I think it is a short-sighted definition of SE but in any case, there are not any mention anywhere in the article claiming that this was aimed to software engineers.

Also, although I appreciate the concerns of "Not Invented Here" doctrine, we also have the other side of the spectrum, where we don't know how to do a left-pad anymore [1], and introduce dependencies everywhere.

The third point is that I don't think that having more knowledge on how things works contributes with the "Not Invented Here" mindset. I would argue is the opposite. When engineers are hungry on learning, they find excuses to make address that appetite at work, but once they know the tradeoffs and amount of effort to make it work, they will think twice before starting anything from scratch.

[1] https://qz.com/646467/how-one-programmer-broke-the-internet-...

Re: Challenging projects every programmer should try (2019)

#250
post #107

Earlier quoted context omitted.

> Literally all of the listed projects, text editors, compilers, operating systems, and ray tracers, can exercise the exact same activities. In the linked article, these projects are all explicitly described as opportunities to learn about low-level stuff like how to efficiently store editable text. The difference with a web search engine is that nobody today can build such a thing completely from scratch, therefore…

> The difference with a web search engine is that nobody today can build such a thing completely from scratch I'm sorry, but can you substantiate this claim? I've seen no indication that a search engine is not buildable from scratch at all.

Assuming you get the TCP/IP stack for free, you still need to build fully-featured HTTPS and a "webscale" multi-server database for document storage from scratch. The crawler is easy and so is something like PageRank, but then building the sharded keyword text search engine itself that operates at webscale is a whole other project...

The point is that it's too much work for a single person to build all the parts themselves. It's only feasible if you rely on pre-existing HTTPS libraries and database and text search technologies.

Post reply on HN