[pasta]

I have the feeling that knowledge about bits is lacking by a lot of younger coders. And I also think this is what causes bloatware.

CPUs are powerful enough to use a naive fade transition. But coders who are aware of the internal workings can make it even faster on todays hardware.

Great article and imho still relevant on todays much more powerful computers.

[Illniyar]

Why? I mean if you look at the majority of work that programmers do today - frontend/backend web development and apps, there is no need to have knowledge about bits.

In fact, if I see someone using binary operators in languages such as Java,JS,Ruby etc... I'll immediately consider it bad code, regardless of context - it's just not the right tool for the level of abstraction in these languages.

The fact is that in these products (frontend/backend web development and apps) the performance profile is dominated by bad algorithms, wrong data structures, slow libraries, missing db indexes etc... which knowledge about bits help absolutely zero with.

Large binaries are also not dominated by code you write but rather by using too broad libraries or simply from huge assets.

The only thing I'd consider knowledge of bits to be of any help to a run of the mill developer these days is the knowledge that floating point numbers don't multiply/divide well - but that kind of knowledge can be imparted without really diving into how bits work.

[ajuc]

> In fact, if I see someone using binary operators in languages such as Java,JS,Ruby etc... I'll immediately consider it bad code, regardless of context - it's just not the right tool for the level of abstraction in these languages.

Clojure is written in java (and clojure). It uses bit operations to implement Software Transactional Memory and persistent collections. Is it a bad code?

You seem to think a programmer should always code on the same level of abstraction. I'd argue in many applications often you find no suitable abstraction, and have to implement it yourself.

Also linear feedback shift registers can be used without any knowledge about bits other than the fact that integers loop over when they reach maximum value (and every programmer should know that anyways). And these registers are useful for some very nice algorithms (like in-place pseudorandom permutations' generators - for example for shuffling songs in a media player, or for some ai algorithms).

[Can_Not]

> It uses bit operations to implement Software Transactional Memory and persistent collections. Is it a bad code?

I don't know anything about clojure, but it sounds like you're clobbering in the suggestion that because bitwise operations are bad in high level business code, they must also be bad in low level language implemention code. At best you're not paying attention, at worst that's an intellectually dishonest counter argument.

[Illniyar]

I don't know enough about Clojure, but I think you are saying that Clojure itself is using bit operations behind the hood - of course it's ok for a language implementation to use bit operations.

But if any of your Java code for applications or libraries used bit operations, I'll call it bad code.

[ajuc]

But clojure is a java application, and its libraries (written in java) are also java libraries, you can use them from java (and some people do).

There's nothing wrong with writing your own library implemented using bit operations.

[open_bear]

Conway's Game of Life can be implemented naively in C/C++/Java/etc, using a boolean for every cell's state (on/off). This will require at least n*m bytes (probably more in Java). Using bits to store that data will require 8 times less, which will most likely greatly increase the performance because of the data locality and the amount of data that will fit into a CPU cache.

[vardump]

You could probably have better savings by taking advantage of the fact 99%+ of game of life state is static between iterations.

Maybe quadtree division of space etc. Only touch nodes that had no short period objects, like honeycombs, boxes or blinkers.

You wouldn't even need storage for completely empty nodes.

I'm sure best/fastest GoL engines have even more interesting strategies.

[Illniyar]

Conway's game of life is at best school homework, it does not correlate to any programming done in a real job.

[tripzilch]

I'm frankly a bit offended by the type of computer science and computer programming that you dismiss as not a "real job".

Sure, Conway's Game of Life is a toy problem, but the optimizations used to make it run fast (which go way beyond mere bit-twiddling, btw) are useful tools and practice in a programmer's mental toolbox, for solving real problems.

Certainly, a programmer who "merely" plugs frontends into backends with databases or whatever it is that you consider a "real job" in programming[0], doesn't need to know about bit-level optimizations to do that job. But I would argue that even then, it makes a better programmer, knowing about that sort of thing, broadening your bases, versatility and well-roundedness.

Doesn't mean you have to use it on problems where it's not supposed to, or premature optimization.

Elsewhere in this thread you say you don't need low-level optimizations because Redis handles this for you. But you wouldn't say that the people researching, designing and building Redis weren't doing "real jobs", would you?

I think broadening your bases is actually a pretty good reason for learning about these (or other) things. Because you seem to have a pretty narrow view of what a "real job" is in programming. In particular that you can't seem to come up with any good reasons for knowing about bits, except IEEE floats.

What about graphics programming, usually pixels are packed into a 32-bit RGBA word, you need some basic bit operations for this. Most situations abstracting that away kills performance.

If you need to read out sensors from a device, you're probably going to come across bits (and many other ancient programming lore) somewhere along the line.

If you write code for small / low powered hardware (like Arduinos or equivalent) you are going to need to know your way around bits and bit-manipulation code is very welcome there.

Knowing about these techniques is also important because sometimes they suddenly become useful in a whole new or modern context. Take antirez's Feistel network approach to this fizzling-problem, for instance. That's a cryptographic primitive now used in a graphics context. You can make exactly the same point about it, that a programmer who is supposed to do frontend/backend/db work, should never write code like that, and indeed this is true, you most definitely should NOT be coding your own versions of crypto primitives in a context like that (I'd argue that's even worse than bit-twiddling).

[0] I'm kidding, I respect the work that goes into it. I think it's boring as hell, but it's a lot of work and not all trivial either.

[tentaTherapist]

But if a standard library implementation is allowed to do something why can't I?

[bitexploder]

This just seems wrong to me. There are plenty areas of programming where knowing a little bit about internal data representation, either in memory or in your data store can help you make better choices. Not everyone needs to be a system programmer, but folks still need general computer awareness. We just aren't far enough from the CPU yet. Sufficiently advanced understanding of algorithms implies computer architecture awareness to me.

I get what you are writing about here, that higher level concepts dominate programming many common apps today, but it seems like a weird place to allow yourself to have a knowledge gap.

[deanCommie]

It shouldn't feel wrong to you. In today's connected big-data world, the vast majority of your performance latency is from querying your data (if you structure your db incorrectly), followed closely by client to server communication.

That's the p90 use case for development people are doing.

[bitexploder]

So many simple things are only easy if you know bits. Interpreting a packet capture, poking at memory, designing cache friendly data structures, ... It is like second nature to me. If it isn't required (obviously it isn't, it must at least be a strong competitive advantage). I am not that old. I don't have get off my lawn moments. I grew up (really learned at least) on a processor (P133) where bits started mattering less, but they still mattered.

[Illniyar]

Never needed to interpret a packet, I intercept communications at the 7th layer to troubleshoot things - namely http connections.

I don't poke at memory, I use a profiler that tells me what every piece of code and variables I use take in memory.

I don't design cache friendly data structures, I use redis.

I would wager that my experience is closer to the development situation and needs of the majority of programmers.

I don't see why knowledge of bit operations are necessary to do a good programming job.

[tripzilch]

So you're looking at a http request/response pair, from a service that you did not design, and somewhere in one of the headers you spot a string that looks like this:

YmFzZTY0IGFsd2F5cyB0ZW5kcyB0byBsb29rIGtpbmQgb2YgbGlrZSB0aGlz

Some people will immediately know what to do with that string in the blink of an eye, and the reason why they can spot that with a single glance has very much to do with basic knowledge about bit manipulations.

> I don't see why knowledge of bit operations are necessary to do a good programming job.

The programmer that can't do the above will be stuck. Probably they can still do a good programming job regardless, but the programmer that can is a better programmer.

Knowledge that is related to your practical work but not technically part of it, yet it is part of the field of your work. That is very useful because it makes you better and more well-rounded, meaning you have more mental tools to tackle unforeseen problems. It makes you more well-rounded and better at your job.

If you only know the things you strictly need to know for your job, you're going to get stuck as soon as you encounter a problem that requires novel thinking. And I dunno, I also consider that ability to be part of a "real job".

[bitexploder]

These are good points. At some point architecture and systems like Redis will become the only tools that can reliably implement these behaviors if no one ever learns about bits. Similar to how hard it can be to outperform compilers in many areas when writing assembly by hand.

Then again there are programming disciplines where you have to know all of this and more. It ultimately comes back to those capable of implementing the tools/frameworks/compilers and those that just use them. Safe crypto libraries are impossible without bit wrangling.

I will still argue that having these skills has at times saved order of magnitudes of time for me. Maybe it wasn't worth all the effort I spent if it only saves time once in a while. Then again I haven't been a full time developer in like 11 years, now I break other peoples software for a living and bang bits together on a weekly basis :)

[fundabulousrIII]

These design|use patterns depend entirely on a level of abstraction facilitated by code you don't understand and I have seen this bite people badly.

Using redis or memcache or whatever semi-persistent , network available data store for key value pairs only has middling value (to me) and relies on adopting a data model that is severely limited in scope. If you can't understand the structure of a 'packet' on the network then you can't really troubleshoot network dependent services that provide your L7 function.

[pennaMan]

What are some good resources to learn about bits?

[jeffreygoesto]

There are some quite good pages, I don't remember the exact titles, but the first results are quite ok: https://www.google.de/search?q=bit%20hacks

[lorenzk]

What's a "p90 use case"?

[bitexploder]

90th percentile use case

[roadnottaken]

Ha I thought it was related to P90X somehow

https://en.wikipedia.org/wiki/P90X

[theon144]

>the majority of work that programmers do today - frontend/backend web development and apps

Therein lies your bias, and the rest of your comment just follows.

[Illniyar]

I'm definitely bias towards frontend/backend web development and apps (I.E. mobile/desktop apps).

But that's not to say the premise is bad - I don't think it's wrong to assume the majority of work is in that area, definitely for young developers. There aren't that many real-time and performance-demanding programming jobs compared to web development.

I don't think even game-programming uses bit operations heavily these days- most of the low-level work is done by third party engines.

[kutkloon7]

I remember a recent example. What I wrote was:

    int x = somefunction();
    int x_dividedby16 = x >> 4;

My coworker corrected the second line to something like:

    int x_dividedby16 = (int)Math.ceil(x / 16.0);

[seanwilson]

I'd only ever use a bitshift if the intention of the code was to move the bits left or right (e.g. moving red, green or blue pixel component bits into the right position) or if it was absolutely required for speed as it's less readable if your intention is to divide a number. C compilers will easily optimise simple integer divisions like this for example.

[biesnecker]

Did your coworker correct it with "this is more readable" or "this is the correct way to do it"? The first is arguable (though I don't personally agree with the argument), the second just betrays a real lack of knowledge.

[sammoth]

Don't the two bits of code have completely different behaviour? And the code with the bitshift is undefined on negative integers (in C). So the bottom code could indeed be the "correct way to do it".

[biesnecker]

Fair, with negative ints they're different. They have the same behavior on positive ints, though.

[krzat]

Why not `x / 16`?

[sheldor]

Integer division will give a rounded result instead of floor

[sp332]

I think they're going for the ceiling here, not the floor. Truncation of positive values should be the same as a floor function.

[kutkloon7]

Yes, I wrote the example. Then realized it was different and corrected only half of it.

[jskkk]

Not in C..?

[thechao]

   (x + 15) / 16

[jskkk]

Yes, which is more readable and would be compiled to the same thing

[throwaway2016a]

Just the other day I showed one of our junior devs how they could turn their 10 lines of somewhat slow and obfuscated code into a 3 arguably more readable lines using a bitwise operations. And this was a front-end webapp.

Then again, more readable is subjective and some devs might see "<<" and get thrown off.

[onion2k]

A reasonable 'compromise' of 3 lines of code with 7 lines of comment to explain what it's doing would be my preference.

[throwaway2016a]

Or... and just throwing this out there... developers can take responsibility to know what bitwise operators do the same as they know what "+" does.

The three lines of code were:

for ( ... ) { x = x << y }

The developer was essential using an array of booleans to simulate a bitwise operator.

It is very sad that devs these days need a comment to know what that does. Would we expect 7 lines of comments if it was:

for ( ... ) { x = x + y; }

[onion2k]

developers can take responsibility to know what bitwise operators do the same as they know what "+" does

Yes but they won't. Pragmatically speaking adding a comment to explain a concept the next developer won't use very often means you won't need to answer their questions about it when they next need to modify that piece of code. That's a big win for you, and it means the other developer can carry on being productive.

[viraptor]

> using binary operators [...] bad code, regardless of context

> the performance profile is dominated by bad algorithms, wrong data structures

Do you know how you often implement good algorithms and data structures? You wouldn't implement a bloom filter as a high level array of 1/0 integers, would you?

[Illniyar]

I would definitely implement a bloom filter with an array of booleans, and will not use bit operations to modify the cells.

Whether I use array access or a bitmask will mean nothing performance-wise, since the bloom filter itself is likely already speeds up a different algorithm by an order of magnitude.

[fundabulousrIII]

For most operational purposes there isn't a crying need for optimizations and handwritten assembly outside the kernel but a good programmer must at least recognize where something like this is called for and be able to implement (imo).

[laydn]

I agree. Unfortunately, it feels like there is so many people out there lacking the fundamental engineering background to write software.

I once spent an hour "optimizing" a piece of code that ran in 15 minutes, which tested an embedded system. The resulting code ran in 4 seconds. The root cause was a complete misunderstanding of how microprocessor interrupts work.

I spent a week re-writing a 4000 line C-function, which ended up to be around 50 lines of code, doing the same thing. The root cause was a complete misunderstanding of how state machines should be constructed.

These types of rookie mistakes by itself don't worry me. But the "trend" seems to be that young coders graduate with less knowledge about the underlying hardware on which their software will run.

I feel like just like Mathematics and Physics, low level programming / microprocessors / computer architecture classes should be part of many university curriculum. (Oh and I think they should teach about version control systems in college as well, but that's the topic of another story!)

[LeifCarrotson]

> lacking the fundamental engineering background to write software.... young coders graduate with less knowledge about the underlying hardware on which their software will run.

There's a lot of software being written in Excel macros and Wordpress web development. These tools actually get work done - they automate things that were not automated before, they publish things that were not published before, and they generate revenue and improve productivity.

Young coders, and the authors of these programs, should not be forced or expected to go through low-level programming classes to get work done. The tools are good enough and the hardware is fast enough that for 99.99% of all projects, they don't need this expertise.

I say this as someone with an EE degree (from less than a decade ago) consisting of classes that spanned the entire pyramid of complexity: from analysis and simulation of individual transistors, through construction of a CPU on an FPGA, through writing an RTOS for a microcontroller, up to programming a web server. That understanding benefits me greatly in what I'm doing today.

But I work with plenty of people who don't have that background. For all the business logic that seems to be found in any software project, that's just fine. Most of the work is in translating people's desire for the software to "do what I want" into actual requirements and then codifying those requirements into a database or UI. For construction of state machines, they should use a library or have someone more competent construct the framework and let them implement the actual states, and when the work requires an understanding of how microprocessor interrupts, they should defer to someone who understands that technology.

And yes, they should teach some version control in college as well. It would be enough to give students one major project that ends up with the filename laydn-Project-complete-final-actuallyfinal-3-done-8-29.zip, which just worked a minute ago after which you barely changed anything and now it's completely broken, and that thing that worked once stopped working at some unknown time in the past. Then just mention that git and svn are things that exist.

[nur0n]

I agree with you for the most part. Writing poor code is fine if the code will only be run for a limited use case. But much of the power of software comes from its potential to be easily reusable and extendable. This potential is thrown away when people write poor code. At some point, it becomes detrimental to keep reusing poor code and there is no choice but to rewrite it. So writing poor code is productive work in some sense, but it is useless(almost always, in my experience) in constructing higher levels of abstraction.

The complete disregard for good design I have seen troubles me as a software engineer. When I've had to rewrite code, usually its not because I disagree with its design, but because there is no design to disagree with! IMO code design should be taught better (or at least taught at all...). Only then can someone make the judgement call of what parts can be poorly written and which parts require more care.

This next claim is anecdotal: the people which don't bother to learn even the basics of how actual machines work tend to be the same people which don't bother to properly design their code. Good design necessitates some understanding of how the machine works, it can not be accomplished through brute force pattern matching. I understand that code is becoming increasingly common and that some people have no choice but to interact with it. But if a significant portion of your income is generated through work in software, then I don't really think a valid excuse exists; you should do your job correctly. I'm not saying everyone needs to be an expert. The culture of apathy for the most basic computing principles is what troubles me, and it should trouble anyone who has to read code written by others.

[Retr0spectrum]

I was taught about low-level architecture (and version control too) in the first year of my CS course. Is this not standard?

[lifthrasiir]

You should have said "thinking outside of the abstraction" instead. Bits are implementation details. The very knowledge of linear-feedback shift register is essential in this particular example.

> CPUs are powerful enough to use a naive fade transition. But coders who are aware of the internal workings can make it even faster on todays hardware.

Not really. No one would do the fade transition---or more accurately, the regional alpha blending with a fixed color---in CPU nowadays exactly because GPUs are much more capable in that job, and such a job is actually fairly easy in most abstractions used because it is an integral part of UX and whatever. The ability of leveraging all resources and determining their efficient utilization is a key.

[peteretep]

    > I have the feeling that knowledge
    > about bits is lacking by a lot of
    > younger coders. And I also think
    > this is what causes bloatware

From a management perspective, I wonder if people find older developers miss obvious solutions that involve throwing small amounts of money and/or hardware at business problems, and instead turn to "clever" solutions that are costly in terms of extra developer time needed for developer and maintenance.

Certainly when running technology in an SME I found my gut feelings about many cost/benefit questions were often invalidated by the ever-decreasing cost of computing power, both in terms of physical hardware and cloud resources.

[notzorbo3]

Managers often think throwing more hardware at the problem will fix things. But hardware scales sub-linearly. Solving the actual underlying problems can easily get you exponential payoffs.

Anecdote: One of my managers once spent €70000¹ worth of hardware to speed up an application because he believed it would be cheaper than to optimize the code. Naturally, no-one had done any kind of performance analysis, so while the upgrade made things about 20% faster, it still wasn't enough. It took me all of 20 minutes to figure out that caching was disabled on the database and it had no indexes whatsoever². 30 minutes of work yielded a few thousand percent speed increase.

¹) This was a long time ago before SSDs existed and buying a hardware RAID of fast disks and fast CPUs / memory was extremely expensive.

²) DBAer consultants of a certain large database vendor are not worth the horrendous hourly fee they ask.

[peteretep]

    > Managers often think throwing more
    > hardware at the problem will fix things

It often will...

    > no-one had done any kind of performance
    > analysis

... is the moral of this story

[nur0n]

I think we agree on the basic point: you can't decide what the most cost effective solution is until analysis is carried out. But an effective performance analysis can't be executed without an understanding of the machine.

Lacking low level knowledge can only create blind spots in the analysis.

[chillingeffect]

Nice work! This is where legends of 10x programmers come from.... they're 2x programmers in a world of 0.2x programmers ;)

[laydn]

That almost physically hurts to read!

The performance modelling teams working for the large CPU makers get several code traces from major database vendors to optimize the execution of critical pieces of database code. They do a cycle-by-cycle analysis.

And then people run the databases with caching and indexing disabled. Go figure

[xorcist]

> I wonder if people find older developers miss obvious solutions that involve throwing small amounts of money and/or hardware at business problems,

I regularly see the exact opposite: People throwing money and hardware at problems instead of doing the simple and obvious thing. I guess that makes me officially old.

[peteretep]

    > People throwing money and hardware at
    > problems instead of doing the simple
    > and obvious thing

There are (almost) no technical problems, just business decisions. Programmer time for development and maintenance is expensive. Hardware is decreasingly so (also it's CapEx, so nobody cares if you literally light it on fire).

[wmccullough]

I find this too. Even the so-called proprietary algorithms many companies tout aren't even that complicated because 90% of their business runs on a REST over CRUD in SQL web service with a slightly different bootstrap theme on the frontend.

[xorcist]

See, now you fell for the same fallancy. Something that is smart must surely be more expensive, but this is seldom true. A method that is simple is easier to describe, easier to implement and could very well be more performant than a more complicated one.

[eru]

You can often see a bit bump in complexity when going from single computer to some kind of cluster environment (be that hadoop or similar). That complexity also often decreases efficiency.

So it can be useful to think a bit to be able to stay on one machine.

But making those trade-offs is exactly what engineering is about, and what's hard. So talking in the very abstract is seldom useful.

[afpx]

It depends on the person, obviously. But, I hope you sprinkle in a few of those types of analysis questions in your standardized interviews so that older people like me even have a chance.

It hurts (both emotionally and financially) to be rejected by younger teams because they assume things about me that aren't true. I now get the dreaded "has too much experience and would be bored" rejection line all too often.

[fundabulousrIII]

There is only one way to go there. Start a consultancy and be your own boss. That is about it for us older folks. Most of your customers don't want stellar code: they want you to fix what is broken (which is simple enough).

[seanwilson]

> From a management perspective, I wonder if people find older developers miss obvious solutions that involve throwing small amounts of money and/or hardware at business problems, and instead turn to "clever" solutions that are costly in terms of extra developer time needed for developer and maintenance.

Why do people feel the need to generalise about things developers of different ages do...?

Knowing when to save on developer time by spending money in some form definitely seems to be a learned skill though.

[peteretep]

    > Why do people feel the need to
    > generalise about things developers
    > of different ages do

Mostly it was a tongue-in-cheek reply to a comment doing the same...

[mighty_bander]

You'll find a lot of people of all ages that get lost in the problem instead of considering the cost/benefit and going with a good compromise between cheap and "perfect."

Of course you'll also find a lot of kids who overestimate the maintenance cost of 3 lines of weird code sitting in a corner doing their thing for 20 years ;)

[fundabulousrIII]

This is where some knowledge as a syseng or SA comes in very handy. Programmers tend to come up with cool solutions to a problem in their wheelhouse but it may not be the most cost effective or efficient solution. Having domain knowledge is very important.

[dakom]

Anecdotal evidence - I cut my teeth on C and a dabble of asm as a kid (even writing z80 opcodes directly for fun!). I vaguely remember wrangling bits to drive logic. I also wrote webpages as Apache C modules with binary logic to parse requests :D

That was a long time ago in tech terms (~15 years). In the intervening gap I spent most of my time in scripted languages (as3, c#, etc.).

Result? I don't know how to wrangle bits anymore. The added speed increase I'd add almost definitely isn't worth it (for example, flash and unity games, web services, etc.). That doesn't mean it isn't worth it for the end product - I rely on Unity, Adobe, Google, etc. to worry about those optimizations so I can stand on their shoulders and benefit.

But in terms of cost/benefit, getting into that stuff myself (again) just didn't make sense for most of my professional needs.

[ksk]

>I rely on Unity, Adobe, Google, etc. to worry about those optimizations so I can stand on their shoulders and benefit.

It seems to me like they might be doing the same thing! For all the supposedly smart people they hire, TBH I can't think of a single product that feels fast/performant to me.

[dakom]

Ultimately that's a subjective call. If I had to write the Unity Editor and enable it to hit the targets they do - man I don't even know where to start. Seems like voodoo to me, personally I'm extremely impressed but I admit it might just be my lack of knowledge of what's possible now (last time I did low-level graphics stuff was amateur mucking around with mode 13h and SDL)

[afpx]

Recently, I started helping out data engineering teams improve performance of their big data processing pipelines.

Man, was I shocked. Very smart, highly educated, mid-level and even senior software engineers seem to know very little about bits these days. When they'd run into a memory issue, their natural response was to just spin up a few more servers and throw another terabyte of memory at the problem. Makes sense, I guess - until their CFO saw their pretty exponential curve in infrastructure costs.

[hasenj]

It's lucrative for SaaS providers to convince developers that they don't need to care about performance. Just throw more memory at your problem. We'll be there to provide you all the hardware you need. wink wink.

[Illniyar]

And did knowledge of bits help solve the memory issue?

[MichaelGG]

I've done stuff where memory usage shrank from 30-60GB to under 2GB, and load times went from many minutes to essentially instant (mmap on the bits Vs needing to build objects).

[afpx]

That was implicit. Of course it did! :-) And, cut server costs in half, too.

[auggierose]

I like bits, too, but cutting it in half means it is still exponential ;-)

[afpx]

To be fair, the savings are way above 50%, honestly. But, I didn't want to claim a bigger number without digging in more, and 50% was a very conservative upper bound. But, yeah, you're right.

[keithnz]

there's still the whole other world of coders doing "embedded" software. They are still happily bit fiddling in blissful ignorance of web development fads. I only do a little bit these days, but one of the micros I program only has 20bytes of RAM to work with and requires bit magic. :)

[digi_owl]

Sadly many these days conflate "embedded" with RPi, Beaglebone or some other SoC on a board...

[eru]

Even the chips you find on your credit card have quite a lot of RAM these days, don't they?

[spatulon]

In the automotive world (with the exception of infotainment and assisted/autonomous driving systems), ECUs have amounts of RAM measured in kilobytes, not megabytes. I've left the industry now, but I /think/ the powertrain ECUs I worked with usually had around 256KB of RAM.

[fundabulousrIII]

That is a fascinating world to me. I've about 25 years C, rudimentary intel x86 asm and good ability to understand new hardware. Seems to me that at 40+ this is an industry that I could still be of use in. Any pointers?

[i_cant_speel]

I think that working with bits is still a standard part of a Computer Science program. I took a class last year dealing with logic gates and bits. I also have a couple of friends that went to other schools that also took the same kind of class.

While the information is nice to know and helps every once in a while (like understanding these articles better), I just don't think it's nearly as necessary to know as it used to be.

[throwaway2016a]

I find it incredibly hard to believe that any young code with a freshman level Computer Science education would now know bits inside and out. Then again, I went to college 10 years ago and I went to one of the better schools so maybe they don't teach that anymore?

I also acknowledge that with the invention of "code bootcamps" a lot more coders have never been to college than before. Effectively, I think, creating two types of programer that has nothing to do with age. Both types have their applications they are good at.

[seanwilson]

> I have the feeling that knowledge about bits is lacking by a lot of younger coders. And I also think this is what causes bloatware.

I don't think this is true. I used to code in assembly and knowledge of bits is largely irrelevant the vast majority of the time now outside of graphics algorithms and low-level number crunching. Algorithmic growth and memory usage are always going to be important though.

[wmu]

I'm a low-level programmer and it's the first time I come across the linear-feedback shift register. I would say it's rather a part of digital circuits design.

Now, when FPGAs become more and more popular, people will be forced to learn VHDL languages and then different lesser-known techniques will surface. (It's a naive prediction, I know.)

[thesimon]

>Now, when FPGAs become more and more popular, people will be forced to learn VHDL languages and then different lesser-known techniques will surface.

Isn't that already part of a normal CS degree? We needed to learn VHDL to program a Atmel ATTiny for class.

[maffydub]

Are you sure you learnt VHDL? As I understood it, the ATTiny isn't an FPGA but an 8-bit microcontroller.

Learning some form of assembly language at university is (probably) reasonably common.

Learning VHDL (for programming FPGAs) is less common - I did for my Computer Science degree, but this was about 15 years ago, so I don't know if it's still common.

[ctw]

Just one data point, but I'm currently at school for Computer Engineering and we learn and use VHDL and Verilog for several courses. We use it to program Altera FPGA's.

[maffydub]

Glad to hear it's still being taught! I was using Altera FPGAs too, although I suspect they're quite a lot higher gate count now. (My second year project was an FPGA implementation of the EDSAC computer from the 1940s - https://en.wikipedia.org/wiki/Electronic_delay_storage_autom...)

[mysterydip]

Agreed. There's plenty of applications even today where this kind of mentality is helpful (embedded or real-time systems, for example).

It's not even necessarily about squeezing cpu or memory performance, but finding a solution that is "native" to how computers work: binary bits.

[oblio]

> I have the feeling that knowledge about bits is lacking by a lot of younger coders.

I optimize for what they pay me for now. I also optimize for what I think they will pay me in future.

The super efficient C solution might be an salary dead-end when management also accepts a huge Hadoop solution :)

[smnscu]

Agreed. I like this list of somewhat common bit hacks (the popular Bit Twiddling Guide): graphics.stanford.edu/~seander/bithacks.html

[maccard]

I dont particularly care for your generalisation about younger coders, as a younger coder. There are many of us who do care about the low level details of our code, and take extra care to write good performant code. To make a generalisation about "older" programmers - I have the feelings that older coders are stuck in their ways and aren't willing to change their behaviours, and when a younger coder tries to suggest improvements, they're hand waved away because we have less experience.

[pasta]

Well I was not trying to blame. And I 100% agree there are loads of good coders of all ages.

But knowledge about inner workings helps to understand what is going on and what can be improved.

So I don't say you should use a non GC language for example. But knowledge about memory management can help to understand memory leaks.