Hacker News Reader

A lot of people give theory a lot of crap. But that's normally because they are not comfortable with the material.

If you are comfortable with the material, you see applications for it all over the place, and use it all the time. Sure, you don't have to ground your system in some kind of formal model (you can just code-til-it-works), but when you do I've found it always ends up as a far simpler and more resilient product.

It's kind of like people who complain that math is useless in school and you'll never need it. Sure, if you never really master it, you'll never be able to use it, so you'll make things kinda work in ways that don't strictly require it, and then conclude it's useless. Meanwhile, if you are familiar with it, your prospects are broader, you may have to use it, and you'll see how it was absolutely relevant and important to know...

I found it also helps with the hardest problem in software development: naming things.

Without knowledge of the theory it can be hard to come up with a descriptive name for some data structure/algorithm you created to solve your problem.

With some knowledge of the theory you can more easily put a name to what you have created, making it easier for other people to understand and giving them something to Google if they're unfamiliar.

But loop variables are always i, j and k.

Except in EE.

n for me for a long time but that’s BASIC showing through.

> It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.” - Edsger Dijkstra

He just couldn't imagine a proper language like Perl where you didn't even NEED a loop variable...

  foreach (@lines) {
      next if /^$/;
      ...

You can even change the foreach to for if you seek more brevity in your Perl life (don't we all?).

> naming things

There are two hard problems in computer science: naming things, cache invalidation, and off-by-one errors.

>> naming things

>There are two hard problems in computer science: naming

concurrency

>things, cache invalidation, and off-by-one errors.

What’s wrong with FactoryProducerProxy? /jk

I think people are ready for things at certain times.

I think history class was wasted on me in high school because I was a kid and didn't have much life experience. But years later with a better grasp on human nature I think I would have had a better grasp.

Another example is a foreign language class. I took it in middle school, in high school and later in college. I learned lots and lots of theory for many years. But only when I went to another country did I learn I hadn't learned.

I think theory needs to be combined with: experience and practice.

Agreed. The reason its not that way is that schools are mostly state-run daycare programs, setup so that parents can work, not a genuine implementation of skill building.

If you agree, the logical takeaway from

> I history class was wasted on me in high school because I was a kid and didn't have much life experience. But years later with a better grasp on human nature I think I would have had a better grasp.

would not be

> Schools are mostly state-run daycare programs, setup so that parents can work, not a genuine implementation of skill building.

This is due to the nature of the topic, not its pedagogy.

No, the reason is that the people who teach are naturally of greater experience and age. When you reach their age/experience they are starting to make sense.

I've always sort of wished I could go back and get my CS degree after I had a few years experience in industry, instead of getting it before. I feel like I would have appreciated what I was learning a lot more.

I think there's two things that change in those years. One is practical experience. The other is life.

Perhaps it takes both. I've definitely seen people who have the one but not the other fail to appreciate the value of theory.

There's often a gap in abstraction where you just don't see the point nor the value.. until you do. Follows the usual enlightened 'aah'

E.S.S Schumacher described this very well with his concept of adequatio

"What enables man to know anything at all about the world around him? … Nothing can be known without there being an appropriate “instrument” in the makeup of the knower. This is the Great Truth of “adaequatio” (adequateness), which defines knowledge as adaequatio rei et intellectus — the understanding of the knower must be adequate to the thing to be known.[...]

For every one of us only those facts and phenomena “exist” for which we posses adaequatio, and as we are not entitled to assume that we are necessarily adequate to everything, at all times, and in whatever condition we may find ourselves, so we are not entitled to insist that something inaccessible to us has no existence at all and is nothing but a phantom of other people’s imaginations.[...]

There is nothing more difficult than to become critically aware of the presuppositions of one’s thought. Everything can be seen directly except the eye through which we see. Every thought can be scrutinized directly except the thought by which we scrutinize. A special effort, an effort of self-awareness, is needed: that almost impossible feat of thought recoiling upon itself — almost impossible but not quite. In fact, that is the power that makes man human and also capable of transcending his humanity."

This is a much more pithy and compressed way of saying what I tried to say above, thanks

I empathise with people who go to college to study computer science, mainly with the intent of eventually landing a well-paid programming job, who are then frustrated when they have to learn actual computer science topics instead of just learning to program.

But their anger is usually directed at the wrong institution. The problem doesn't lie with academia teaching the wrong things, it lies with companies requiring CS degrees for simple programming jobs. They treat the theoretical computer science material as nothing more than a raw intelligence/perseverance filter.

We spent entirely too much time on O(this) and O(that)

But that's the stuff that sort of stood up to the test of time.

Also really helpful was symbolic logic, which actually was not a computer science course.

The most interesting computer science topics to me in school were the different computer languages -- but very few of them survived the test of time.

In my bachelor's degree, I spent two weeks of one course, tops on O(this) and O(that).

I suppose I spent two courses studying computational complexity, but reducing it to O(this) and O(that) does not quite do it justice.

I use CS theory all the time in my professional career. Automata, was the most useful class I took (the 2nd most useful was Programming Language Concepts).

What do you do professionally? How do you use automata there?

Web development, embedded systems, and game dev. I use FSMs, pushdown automata, and hierarchical state machines all the time.

For embedded systems and game development I definitely understand automata applications (from experience) but web development has me curious. Are you writing transpilers or perhaps something else (I also try to avoid web dev, so there's that).

Not OP but there are more than a few domains that can be modeled with automata, a shipping pipeline with approval steps is an example.

Ecommerce order/payment/shipping status is a good example. Anything that has a well defined state that can be changed by events is well-modeled as a state machine of some kind. Also anything that has to progress through certain steps and might be interrupted or have exception cases, and you want to proceed/retry idempotently.

Personally I have also found basic graph theory to be immensely useful for representing and reasoning about things.

>Personally I have also found basic graph theory to be immensely useful for representing and reasoning about things.

I agree! The graph theory portion of my algorithms class (more than half of the class) was the third most useful thing I learned in my degree.

Mostly for user interfaces and modeling business processes. But I’ve also done some work on a super simple language for some of our non technical people to use for data transformation, and a templating system for form generation.

What's amazing to me is how uncommon state machines are in software, comparatively. In ASIC and FPGA design, it's so fundamental and ubiquitous. At least with synchronous designs.

I pushed for using state machines and more formal methods in the rewrite of a system that I and a number of other devs were hired for. The idea was turned down in favor of lots of ad hoc state and string constants, even though the system has a limited and distinct set of states on the main domain objects. People don't do it because people don't do it, and they're afraid others aren't going to understand it.

The vast majority of companies essentially code and design to the lowest common denominator so that their devs are fungible cogs.

The problem is that it's extremely easy to violate the boundaries of state machines. For example there's some small edge case, that would normally require you to completely re-create the state machine, but people bypass that by just escaping the state machine. In ASIC/FPGA, it's actually relatively hard to escape the state machine because escaping the state machine causes explosions in timing required and causes race conditions.

Code doesn't have fixed timing requirements, most of the time.

I don't dispute at all that theoretical CS is practically useful, I love it myself and think it offers amazing tools for thought. But my hunch is (and I'm emphasizing that I'm speculating here) that only people who like the material end up retaining enough to see the applications. I feel like some of my fellow students, including ones that I felt were smart (but who were application-oriented learners who have trouble focusing if they didn't see applications right away), had to drag themselves through the theoretical material to barely pass and then promptly forget about it. I imagine their perspective is:

1. They have to work through material that does not particularly interest them and is quite hard, but employers insist that they must master this stuff if they want a good position.

2. In their work environment, no one ever asks them to actually use theoretical CS concepts, and they don't spontaneously see applications themselves.

3. Therefore, they feel academia is out of touch and teaching irrelevant material that has no practical application. With my earlier comment I wanted to point out that I don't believe academia is to blame for their suffering.

That's the thing, it is useful, so I don't blame companies for wanting people who know CS theory.

And when I hire people, even though I hate doing adversarial whiteboard coding, I will probe to find out if people understand a bit of theory.

You can get a lot of work done without theoretical knowledge, (but the end result is often not as good, and it usually takes longer). Combine that with the fact that CS theory is hard, and you get a lot of people complaining about how theoretical CS is useless outside of academia.

It's basically an extension of "no one needs to know math beyond arithmetic in the real world".

There's a bunch of commercial prep courses and coding bootcamps that focus on applied programming.

I wonder how long-term those skills are, reminds me of companies teaching MCSE certification a few decades ago.

The way I've seen it distinguished in colleges is as a separate "Software Engineering" track within the compsci department.

Think it depends entirely on the person. I know someone who went through one of those 6 years ago. He worked a grunt job for a while for experience, and has traded up to a very nice gig today. He also worked pretty hard on the side, teaching himself.

I can't speak for the longevity of the training, but he's doing fine.

For that matter, other than a terrible 101 class, I have no formal programming training and have been doing this professionally for over 20 years so far. But I'm a bit of a broken record when it comes to degrees-as-gatekeepers - the vast majority of programming jobs do not require a college diploma to competently perform. Very, very few people are writing blank-page Paxos implementations or researching "ai" - they're gluing APIs together and writing business logic. Moderate competence, the ability to do basic research and the patience to get past the WTF stage with a compiler are what you need, not a four year degree.

You can say that about many fields. Employers outsource their testing to universities. It saves them a ton of effort and it has the side benefit of shielding them from some potential discrimination claims.

Without university, how is an employer to know you would've spent 4 years working on something reasonably challenging that took a moderate to large amount of effort over long periods of time? They can't discover any of this in an interview. The fact that high school is mandatory robs it of much of its signalling value.

The fact that high school is mandatory robs it of much of its signalling value.

This will very clearly result in the same loss of signaling value for higher education.

There is a lack of a university (or above) level software engineering education that isn't aimed at computer science.

> The fact that one does not need this during their day job is, dare I say it, irrelevant.

I disagree for some of the fundamental things.

Binary arithmetic is fundamental. The number of times I have seen people using addition for logical-or and being confounded by bugs astounds me. I don't expect you to be able to do stupid bit tricks. However you must know how to use and,or,xor,not for masking and you must understand what integer overflow/underflow is.

State machines are fundamental. I'll go so far as to say that if you don't know how to do state machines, you don't really know how to program. You simply have no framework for understanding things like protocols, sequencing, concurrency, etc.

Data structures are fundamental. Sure, I can boil it down to "75% of the time use a hash table; 25% of the time use a vector; .001% of the time use something else". But you won't know when you shouldn't use something.

These are things I see all the time in programmers who I would expect to know better. These also seem to be things that "programming" course often slack on--they're hard to teach and hard to learn. It requires work from both sides to communicate the concepts.

I agree; My personal view is that it's fundamental to know these ideas, just as one can't be a physicist without knowing a decent chunk of mathematics.

On the other hand, it seems that biology majors seem to "get by" [as far as I can tell] without needing to learn much math. Perhaps one can argue that it's better if they learnt more math. But we can't argue that the profession of being a doctor seems to work without them knowing too much math.

It's unclear to me, where in the extremely broad spectrum of jobs known as "programmer" [writing code for the space shuttle v/s bringing up an android app] where the need for mathematics ends. So I hesitate to make blanket statements about this.

What I will never hesitate to defend is the utility of these ideas of theoretical CS/mathematics for all computer scientists and scientist-adjacent folks.

Some people are more inclined to theoretical concepts, some people are more practical. Both have an understanding on how things work and/or an intuition, either by studying theoretical concepts or via practical, hands on experience.

My issue with this, and this is mostly my own personal opinion, is not whether or not this subject is important and that we need to defend it, but whether teaching it to students of that level is the 'right' thing.

Imagine a student that doesnt even know how to program yet, doesn't know any algorithms, or higher level paradigms, heck doesnt even know any computer architecture stuff yet, but has to go through this block of theory and get examined on it.. Is it the right move to motivate more people into this field?

> My issue with this, and this is mostly my own personal opinion, is not whether or not this subject is important and that we need to defend it, but whether teaching it to students of that level is the 'right' thing.

Teaching it to which students? If someone enrolls in a computer science class, it's reasonable to teach them computer science. If instead they want a mechanical introduction to programming, CS probably isn't the right material.

Yeah! And why come we gots to teach kid how to plus and minus if theys just gonna be a plummer?

I think you are not addressing the point, which the GP tried to make. It's not about teaching or not teaching, but about the time when stuff is taught. Surely all these things have their time and place. Perhaps there are gentler introductions to some of these topics available?

If you can't teach theoretical computer science to undergraduate computer science students, you will have to shift it to the graduate level. Which means you won't really every have anyone earning a true masters in computer science because they'll need so much grounding to be able to complete the work they won't have time to do anything novel.

You aren't being serious, but that was once actually a fairly widespread sentiment. In colonial times in America, for instance, arithmetic was generally not taught in elementary school. It was something you would learn on the job if needed.

Amusingly, when it did start getting routinely taught at the end of the 18th century there were complaints from businessmen to the school boards that the methods taught in school were producing students totally unprepared for business.

For more on this, see the essay "What is Mathematics For?" by Underwood Dudley from the May 2010 Notices of the AMS [1]. (A more accurate title, he notes in the first paragraph, would be "What is mathematics education for?").

He makes some interesting points about the usual justifications that elementary and high school math are useful in your career are not really accurate.

[1] http://www.ams.org/notices/201005/rtx100500608p.pdf

If you want people to write mostly CRUD apps, sure.

If you want people to develop programming languages, algorithms, models etc., not really. Computer Science is a subfield of math and trying to "lure" people into the field with flashy graphics and instant gratification will only frustrate them when it gets to the basics. In theory you can complete a Computer Science degree without ever programming a physical computer. To complete my Masters in CS I only had to take an introductionary course for Java, everything else programming related was optional.

Agree. I loved the theoretical side of CompSci (automata, programming language at the meta level, algorithms). Practical was boring to me and I lost interest in the day to day (7 hours of typing in an IDE!? joy). The problems of the practical are a let down if you start theoretical.

Can you handle 1M concurrent in Go to replace a java load distributor? Sure! Crud apps..... oh brain hurts will never finish.

> Both have an understanding on how things work and/or an intuition, either by studying theoretical concepts or via practical, hands on experience.

hands on experience with regular expressions manages to fail a lot of people with practical problems.

https://stackoverflow.com/questions/1732348/regex-match-open...

There are schools which just teach you programming and computer skills and do a good job at it. But companies will still prefer candidates with computer science degrees, or even outright require a CS degree, even for simple programming jobs that really don't need one. The degree is used as no more than an intelligence filter. This relegates anyone who has a practically oriented degree to being regarded as a second class programmer, the perception being that you would have studied CS instead if you had the ability.

This completely sucks for practically inclined people who are forced to trudge through a theoretical degree that doesn't interest them, and where 90% of the material they will never use, just to prove that they're smart enough.

They then tend to blame academia for being out of touch, ivory tower, etc. But academia is not at fault here, they are teaching what they claim to teach: computer science. There are good pratically minded degrees which prepare you just fine for the average programming job, it's employers who constantly signal that they value CS degrees more.

But companies will still prefer candidates with computer science degrees, or even outright require a CS degree, even for simple programming jobs that really don't need one.

I haven’t seen any corporate dev jobs that care about formal computer science during an interview. I only see that from BigTech and BigTech wannabes that think they need “smart people” (tm).

> whether teaching it to students of that level is the 'right' thing

I strongly doubt that any university or educator is teaching so much theory of computation to any level of computer science student who will not be focused on theory of computation. Notice that the OP's video seems targeted towards incoming CS theory Masters/PhD students who will explicitly be working on CS theory and doing research.

Eeh... automata, languages (of all kinds, not just regular), grammars, complexity, etc. are used in computer engineering all the time.

If a computer engineering degree does not have those, then it is a pretty bad one.

One of the best books I ever read was a book that implemented a large number of algorithms in Pascal. This served me well both when implementing things as well as when studying papers about algorithms. The gap between theory and practice in computer science is as small as it gets across many domains.

I'm seeing 'Computer Science knowledge is not necessary to be a better programmer' statements more often nowadays, even from those who have CS degree(Degree != Education).

Here's one example, who is in Kaggle 1% - https://twitter.com/bhutanisanyam1/status/120900088154848051....