Legend Chapter 69

Look how lucky you all are, I actually managed to finished the weekly chapter, Chapter 69.
Considering I have exams tomorrow, Monday in Australia, I’m amazed that I still managed to crank this out……
Anyhow, I hadn’t had much time to translate and edit the chapter, so if you find any mistakes, drop a comment.
I will get around to fixing it when I’m not dying from revision.

P.S. Anyone studying a Com Sci related course here? Semaphores and shared memory.
If you haven’t done them, I wish you the best of luck with the Linux command line.

My bachelor’s in comp sci (followed by a master’s degree in computer engineering), and let me tell you, even if you end up going into higher level languages (as I have), knowing those concepts is gonna help you a great deal.

Shared resources, pipelines, forks, semaphores… They’ll be wrapped in friendlier, safer packages and given different names (count the number of things called “async”-something), but they’ll still be there. Difference being that you’ll know what things like race conditions are, and that’ll make your life a lot easier.

Hey how do you like computer engineering compared to computer science. Im a senior in high school and 100% going into one of those to at least a masters though i if have the money i want a phd. Whats the major differences between the two.

I’m actually in Electronics and Robotics, but my Robotics section requires me to do a variety of mechanical and software topics.

Where I am, ComSci is the course you get into if you are not sure about what specialisation you want to go into. It’s relatively easy to transfer into other courses within engineering from ComSci. ComEng, from what I know, will probably involve quite a bit of programming topics and will possibly deal with computers at a higher level than what I have to do in electronics.

Either way, I suggest the course rules of the course you want to study at the relevant tertiary institution. It’s best to know what you will be studying ahead of time rather than picking a course based on its name only.

Both two fields will have considerably different interpretations depending on your university (as in, different interpretations of the fields themselves, not just between the two of them), but in general, both of them cover a lower-level take on computer systems (i.e. core concepts that make software and hardware work at all and why they work that way) as opposed to more general IT studies (where you’ll be more focused on direct practical application of what you learn).

In my case, computer science focused largely on software architecture and design (i.e. when it came to actually programming), and a great deal of embedded systems engineering, which helped us really consider how our software was interfacing with the hardware (on a memory and instruction level).

Computer engineering took that “interfacing with hardware” side even further, focusing on kernel and driver-level stuff, as well as designing the hardware itself. (Letting us make our own integrated circuits.) And while computer science had me consider designing for maintainability and solving problems within certain constraints, engineering also went into designing solutions to even lower level problems (such as addition, addressing memory, producing random numbers, etc.) and doing so with efficiency and/or performance in mind.

Basically, between computer engineering, computer science, and software development, each introduces another layer of abstraction, where you’ll just have to assume certain things “just work”. For the record, I also got a bachelor’s degree in electrical engineering, though at a lower level of education (there are several different tiers of higher education in my country), I suppose you could consider that an even lower level (albeit broader) take on the subject.

Your choice should depend on just how interested you are in the nitty gritty details, in figuring out how things work, rather than outright making them work. Which isn’t to say it’ll be all theory all day, but it does mean that most of the practical stuff you get to work with is mostly there to show you how to apply that theory, rather than anything you could directly turn into a marketable skill. Which is to say that both fields will require you to learn a lot more and put in more effort even as you enter the workforce: “Computer scientist” and “computer engineer” aren’t exactly job titles, you’ll have to turn that knowledge into something that lets you be an Embedded Systems Engineer, or Software Architect, RTL Designer, or… you know, just a Software Developer.

Realistically, you’ll get some leads (and practical knowledge) as you do internships, and many companies do want junior computer scientists and computer engineers (provided you didn’t just wing it), but it’s still not as smooth a process as simply having studied for a particular line of work and applying for the relevant position. (Though for the record, most students from my university (TU Delft) got work straight away, and I was already working (and earning quite a bit) at the place I did my CS internship at while I was getting my computer engineering degree.)

And since this has turned into a wall of text, I think I’ll stress the thing I said at the start once more: different universities have (sometimes wildly) different interpretations of what the fields entail. I’ve even seen universities offer “computer science” programs that were basically just system administration, and universities that treat computer engineering programs that are basically just what I learned at computer science.