3 ms·

This code makes me feel like I'm not even a real software engineer, I'm just a guy playing with kiddie languages working on kiddie problems. Anyone else think t

This code makes me feel like I'm not even a real software engineer, I'm just a guy playing with kiddie languages working on kiddie problems. Anyone else think that after reading it?

deleted 15y ago
[deleted]
chime 15y ago
Languages are just tools. What one person can write in Erlang or raw C, someone else can write that in JS or QBasic. What matters is what your code does. Having working on projects ranging from large ERP systems to audio DSP to video startup to joke sites like cakesy.com and iwannamarry.com, I can say that what matters most is how much you enjoy working on the project. That's it. If the twitter-feed-importing-app makes you happy and your users happy, don't feel bad that you're not contributing to OpenSSH.
beej71 15y ago
Codecs are complicated and mathy and optimized for speed. So you might find a line of code that says something like: val = SHOW_UBITS(re, gb, bits) - (1 << exp_order) + (switch_bits + 1) << rice_order); and you just don't have a clue what it really means (I don't--even though I can easily read the line of code) because the answer is buried in the details of the codec design. But trust me--if you go through a complicated spec and implement it yourself, you'll end up with a lot of similar stuff as this guy did, with his mighty-fine-looking piece of work.
- daeken 15y ago
  This is especially true when you're reversing a codec. I helped out reversing ALAC (Apple's answer to FLAC), and I didn't know what 99.9% of the code did, I just knew how it needed to do it. Certain things fit common patterns with simple changes (e.g. modified Rice coding), but most of the time you're just matching code behavior directly. I will say, building an encoder based solely on the reverse-engineered decoder (didn't want to reverse out the encoder as well -- total mess) is a really fun challenge. Good way to dive into codec work.
  - kierank 15y ago
    Having done the same thing I would agree entirely. There are lots of similar patterns in decoders from a similar family.
- baddox 15y ago
  Would it be possible to write the same code to make it more readable without incurring a performance penalty? If not, then I guess it's okay, since these people have decided that performance is more important than readability (although there should be comments).
mdaniel 15y ago
I get what you're saying, but want to remind you that this kind of math is a skill just like juggling or swallowing swords. Just because some folks train more in web applications, ORM, crazy legacy file formats, whatever, does not automatically make them less of a software engineer. I also quite often draw the distinction between "programmers" and "software engineers", with "computer scientists" sometimes being their own category, and sometimes a subset of the first two.

This code makes me feel like I'm not even a real software engineer, I'm just a guy playing with kiddie languages working on kiddie problems. Anyone else think that after reading it?

deleted 15y ago

[deleted]

chime 15y ago

Languages are just tools. What one person can write in Erlang or raw C, someone else can write that in JS or QBasic. What matters is what your code does. Having working on projects ranging from large ERP systems to audio DSP to video startup to joke sites like cakesy.com and iwannamarry.com, I can say that what matters most is how much you enjoy working on the project. That's it. If the twitter-feed-importing-app makes you happy and your users happy, don't feel bad that you're not contributing to OpenSSH.

beej71 15y ago

Codecs are complicated and mathy and optimized for speed. So you might find a line of code that says something like: val = SHOW_UBITS(re, gb, bits) - (1 << exp_order) + (switch_bits + 1) << rice_order); and you just don't have a clue what it really means (I don't--even though I can easily read the line of code) because the answer is buried in the details of the codec design. But trust me--if you go through a complicated spec and implement it yourself, you'll end up with a lot of similar stuff as this guy did, with his mighty-fine-looking piece of work.

daeken 15y ago
This is especially true when you're reversing a codec. I helped out reversing ALAC (Apple's answer to FLAC), and I didn't know what 99.9% of the code did, I just knew how it needed to do it. Certain things fit common patterns with simple changes (e.g. modified Rice coding), but most of the time you're just matching code behavior directly. I will say, building an encoder based solely on the reverse-engineered decoder (didn't want to reverse out the encoder as well -- total mess) is a really fun challenge. Good way to dive into codec work.
- kierank 15y ago
  Having done the same thing I would agree entirely. There are lots of similar patterns in decoders from a similar family.
baddox 15y ago
Would it be possible to write the same code to make it more readable without incurring a performance penalty? If not, then I guess it's okay, since these people have decided that performance is more important than readability (although there should be comments).

mdaniel 15y ago

I get what you're saying, but want to remind you that this kind of math is a skill just like juggling or swallowing swords. Just because some folks train more in web applications, ORM, crazy legacy file formats, whatever, does not automatically make them less of a software engineer. I also quite often draw the distinction between "programmers" and "software engineers", with "computer scientists" sometimes being their own category, and sometimes a subset of the first two.