41–50 of 346 posts
For a fun challenge, implement space invaders in Verilog (i.e. purely in hardware)
How would you suggest going about the display? Driving an LCD or generating an NTSC/PAL signal? Or maybe a giant array of LEDs? Is there a good tool to simulate Verilog so you can test without hardware?
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…
What if we don't want to be "software engineers"? I'm still not totally convinced that "software engineer" is even a thing , frankly.
And sure, use of the word "engineer" will cause angst among some - because it used to have a precise meaning which has been diluted (and in the case of software, ignored.)
Indeed the list of projects runs the gamut of where a programmer might go in life. They might do user UI, or games, or work on an OS or compiler. More likely they'll work at some random company doing databases and reports. Or they'll be Web focused doing lots of JavaScript. Or they'll be deeply involved in the field of Advertising (Advertising Engineer anyone?)
Of course wherever you end up, you can still have some fun. And if you're just starting out then it can help you understand your desires, and limitations.
So don't worry too much about the "engineer" word. It's pretty irrelevant. Even the title of the thread is "programmer" not "engineer".
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…
-
This will be a wonderful feature for copilots, to allow for the human to provide a verbal narrative of the logic/process or even the environment and of others in the room commenting on why a such-and-such is being done, and the copilot elegantly documenting the narrative.
Wait until we have "Thick Code" (where an app comes with an AI generated Mini-Documentary-Series on the creation of the piece (as an optional function of your enterprise Copilot Agent (With the [Security Assistant] [Compliance Assistant] [Legal Assistant] [Media Assistant] and whatever Alignment Agents are required and inform the narrative of the project.
EDIT: @Tao3300 - I do that all the time. You just need to be a better MeatPT and infer "like, my, opinion, man"
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.
Here's the emulator I made not so long ago: https://github.com/grishka/miscellaneous/tree/master/GBEmula...
I would really love to try my hands on something much more physical, like a robot; or a drone with autopilot; maybe accurate simulation of flight dynamics of a spaceplane with programmable GNC parameters? I have a copy of "Fundamentals of Astrodynamics" by Bate, Mueller et al and I would love to do something with it this holiday season. I say simulation because all the rest of the stuff seems to cost a lot. I am real…
You'd need a microcontroller, an IMU, a stepper motor controller, a motor, some LEGO wheels, and maybe a block of wood.
I haven't tried this, so my guesses are probably way off.
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…
Deciding when to optimize isn't too hard when nobody is ever going to use it (only optimize run time if something really takes too long, otherwise don't do anything tremendously stupid, but optimize for less development time because this is taking forever)
Readable code would be nice, because sometimes it takes a long time to get back to it, but I've also designed in a real reason to come back and retouch everything (x86 -> amd64; aarch64 as a stretch) and maybe I'll make things reasonable then... Although it's not my strongest skill.
Even most simple OSes become complex. Maybe the dependency chain isn't too long though.
Seems to tick all your boxes, IMHO.
Earlier quoted context omitted.
What if we don't want to be "software engineers"? I'm still not totally convinced that "software engineer" is even a thing , frankly.
Who do you think puts systems like a web search engine together? It's certainly not people who are lost in details like string matching or how ACID is implemented in distributed databases. Of course you need all these things in order for the search engine to work – but if you write them yourself, even if you think about them excessively, you will never finish. Software engineering is knowing that you don't need to kn…
Overflow attack, (sql) injection attack, and maybe something like using wireshark to see what a http request actually looks like.
I took two capture the flag classes which changed how I look at some of my day to day dev work.
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…
What if we don't want to be "software engineers"? I'm still not totally convinced that "software engineer" is even a thing , frankly.
But these points raised by GP... are basically self-evident.
> - Deciding what to write yourself and what to take from a library
> - Identifying high-quality libraries and frameworks that meet your project needs
> - Deciding where optimization is worth the effort and where it is not
> - Writing code that will still be readable to you (and others) a few years from now
> - Thinking about the project as a large-scale, complex system with software and non-software dependencies
... But since they don't have immediate effect (along the tune of "look I made this shiny thing myself in a weekend!"), it's hard to brag about it and perhaps even hard to establish causality that your skills in the areas above contributed to the software/business' success. But you can always brag about how you implemented a Fibonacci heap or something and made your heap operations 0.2ms slower.
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.