Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Challenging projects every programmer should try (2019)

austinhenley.com

Post reply on HN
Print view View original

141–150 of 346 posts

Re: Challenging projects every programmer should try (2019)

#141

Post by auggierose »

p-e-w wrote: post #130
auggierose wrote: post #122

Earlier quoted context omitted.

This sounds like sensible advice. But there are a few problems with making software purely from ready-made building blocks. Here are two of them: 1) Much more often than not, the ready-made building blocks are crap. Your software will reflect that crappiness, and your life will consist not of writing software, but of maintaining and massaging crap. 2) Even if your ready-made building blocks are high-quality, they lim…

> If you are only using ready-made building blocks, there is a lot of great software you just cannot write. And I think we all see that, because there isn't much great software around. I claim that the opposite is true: The reason there are so few software projects that are really great is because high-level skills, not low-level ones, are in short supply. Every CS graduate can implement Paxos. The number of people w…

I guess it all depends on your definition of low-level. High-level can also be low-level, just with different building blocks, if the building blocks are based on well-specified abstractions.

I am actually currently writing a novel text editor, and I can guarantee you, my requirements mean that an AI cannot help me with that directly, because the underlying mechanisms I need don't exist yet. The AI is still helpful though when researching existing mechanisms, and to pinpoint why they don't work for me.

> AI is actually much better at writing low-level code than high-level code.

> If you tell it to create a simple CRUD application using existing libraries, it will output something that doesn't actually work.

If your low-level code is just a copy or adaptation of something existing, then yes, AI is really good at that. Something novel though, AI cannot help you much here.

On the other hand, simple CRUD applications will all be done by AI very soon. Probably not using existing libraries though, because these are crap.

But there is certainly a role for humans currently in high-level design, I agree with you here. But this high-level design crucially relies on your ability for low-level design, with the ability to imagine and then implement (possibly with the help of AI) the building blocks you need, not just reuse the ones that are there.

Re: Challenging projects every programmer should try (2019)

#142

Post by sfn42 »

bee_rider wrote: post #72
p-e-w wrote: 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…

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 when not to.

Re: Challenging projects every programmer should try (2019)

#143

Post by ozim »

bee_rider wrote: post #72
p-e-w wrote: 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…

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

Re: Challenging projects every programmer should try (2019)

#144

Post by hurril »

p-e-w wrote: 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…

You're making a strawman here, based on a very much false dichotomy. The things you list here are all very important.

But something you learn from writing a larger piece of software yourself is that you get to appreciate complexity and "bulk" (for lack of a better term) that you yourself created. You get to ask yourself questions like:

Is all this code needed? (Why is it 400 lines to do X?!) Why did this get so involved/ complicated?! How do I progress (eat the elefant)? Can I (teach myself to) make small iterative units of progress every day, for instance?

These kinds of katas are very very useful for a 5-7 year beginner (which I use as a label of respect - the longer we can remain beginners, the longer we learn with an open attitude!)

Re: Challenging projects every programmer should try (2019)

#145

Post by mkii »

p-e-w wrote: post #100
bmitc wrote: post #95

Earlier quoted context omitted.

> In that spirit, I offer the following alternative challenge: Create a web search engine. Yea, no thanks. If I'm going to work on something in my spare time, I am going to work on something that I am interested in and find fun. I generally loathe the dirty work often involved in software engineering and debugging all of these dependencies all the time. It's exhausting. Doing things from scratch puts me in charge. An…

> And I mean, creating a search engine is the ultimate "not invented here" project. I'd just pay for and use Google, Bing, or whatever else API to do things for me. So it doesn't even make sense in the context of your objections. Except that none of the established search engines actually does full-text search (anymore). There is no way to prevent those engines from breaking apart and rewriting your query as they see…

> and before long you will have a search engine of real value for yourself (and possibly others)

How much do you think hosting would cost?

Re: Challenging projects every programmer should try (2019)

#146

Post by sfn42 »

carom wrote: post #131
steve_taylor wrote: post #78

Earlier quoted context omitted.

> Who do you think puts systems like a web search engine together? A really good programmer who is free from the tyranny of software “engineering”.

I believe this more and more as I go through my career. There is usually one person carrying progress hard. If you can get three or four of those people and another one to coordinate them you can do truly amazing things. Usually though you just need one unencumbered by bureaucracy.

Not sure what you guys think software engineering means, but it's definitely not the same as what I think it means.

Re: Challenging projects every programmer should try (2019)

#147

Post by Arch-TK »

p-e-w wrote: post #108
tock wrote: post #105

Earlier quoted context omitted.

Yes a software engineer understanding data structures and runtime complexity is akin to a violin player understanding the physics of acoustic dispersion.

Is it not? I can't tell if you're being sarcastic or not.

I would say, given how absurd the statement is, sarcastic.

Re: Challenging projects every programmer should try (2019)

#148

Post by fho »

59nadir wrote: post #138
p-e-w wrote: 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.

Sigh ... Of to the silicone mines it is then ... again /s

Re: Challenging projects every programmer should try (2019)

#149

Post by 59nadir »

qingcharles wrote: post #125
MBCook wrote: post #3

I’m surprised an emulator (especially Game Boy) is considered harder than a little operating system. I guess that would make sense if you’re not familiar with ASM but an OS will force you to learn that too.

Having checked off most of the list, I would agree the Game Boy emulator is far easier than the OS. I guess with the emulator it depends how much you want to do. You'd be foolish to write a console emulator and not import someone else's CPU code. When I wrote a Game Gear emulator 26 years ago I used off-the-shelf CPU code and just mapped all the in/out and did the graphics bits. Took me and a friend a single evening…

> You'd be foolish to write a console emulator and not import someone else's CPU code.

Why? It's part of the learning and it's not particularly complex.

Post reply on HN