[AstixAndBelix]

Developers should be force fed nothing, because they "chose" to not follow a formal education. Almost everything I see in these blog posts is stuff I was already taught at college (or very adjacent).

If you want developers to know about this stuff stop encouraging people to go to code bootcamps and start making SWE curricula more palatable and end this idea that college is a scam that teaches you nothing

[dgb23]

I'm an autodidact and a big fan of state machines (specifically mealy machines).

They can easily be expressed as plain data structures of three layers that map the name of a state to possible inputs/events to the appropriate name of the subsequent state. Then you only need code / functions for each transition (from state, to state) to generate effects. This data driven pattern is very straight forward to implement and easy to reason about.

I learned it from hobby game programming, especially its application and usefulness. It comes up in lectures/books, sure, but generally people tend to vastly underestimate its applicability and instead smear state control all over their code, regardless of their education.

[plaguuuuuu]

do you know any examples of code that showcase this pattern really well?

every example I've seen (probably toy examples from articles) felt like way too much abstraction had been applied over the problem.

[dgb23]

This response is a bit late sorry. I fully agree. Most programming languages already give you enough tools to write very simple and powerful state machines.

This works best with languages that have first class support for data literals and maps (or equivalent), such as JS, Clojure, etc.

But if you care a ton about performance you can encode the same with say enums and switch statements or similar. It's just a bit more work and you can't change the machines on the fly or generate them from data, which is a very powerful pattern you can put on top of this. But in many cases that's not needed.

---

You first define a map of states, where each key is the name of the state and each value is a map from event names to state names.

Say you have an on off toggle (very simple example):

On => Toggle => Off

Off => Toggle => On

Where On/Off are state names and Toggle is an event name.

Then, you define a map from two states to a function. We call them transition functions. Like so:

[On Off] => func()...

[Off On] => func()...

Inside the functions you would put side-effects directly (such as activating a light or changing a color, sending an email etc.), or maybe just describe side effects so another part of your program can handle them (which can be useful with larger programs as it makes testing easier).

Lastly, you define a state machine function that runs your program like so:

func(state, event) => if event is handled: trigger transition function and return new state, else: return current state

In many cases you want to simply ignore events that aren't handled in the current state of your state machine (like described above).

Sometimes though, you want to buffer events that are currently not handled in a queue and handle them later; that's a niche use-case in order to manage async events in a specific order.

[redeux]

I’m glad this was your experience, but your school’s CS curriculum isn’t universal.

I was once chatting with a jr sw engineer that had recently graduated from a respectable state university with a CS degree about which database would be optimal for our upcoming project. He confided in me that he hadn’t taken the DB course in school because he heard bad things about the professor who taught it. I was absolutely blown away.

The moral of the story is that your shouldn’t assume that just because someone has a CS degree that they have knowledge of all the fundamental areas.

[lightbendover]

Databases were not part of my CS curriculum until I took an elective web development course at the very end. People struggled. I had been doing hobbyist web development since I was quite young so the whole class was a breeze for me, but I understand that for those who are only taught the fundamentals and theory, anything pragmatic can feel daunting. I'm sure curriculums have changed greatly since I went through (KV/graph stores were not yet adopted, distributed DBs were merely a thought), but it still doesn't feel quite right for faulting a student for choosing certain classes or not being perfectly suited for learning a given domain instantly.

[redeux]

My point is about not assuming people know specific topics in CS just because they have a CS degree. So, I feel like we agree here. There were no problems with his attitude, and it was a quick fix. I just assumed he knew, having recently gotten a CS degree and I was wrong.

[Version467]

Were you asking him about what kind of db would be best suited for your project (i.e. relational, document based, graph, etc.), or were you asking about specific products, like Postgres vs. Mariadb?

If it was the latter, then I doubt he could have answered that even if he had taken the db course at his college. And that's probably fine, I don't think the differences between specific db products counts as the sort of fundamental knowledge that should be taught at a university.

[redeux]

We were talking about kinds of DBs, not specific products.

[Version467]

Oh okay, yeah that makes more sense then.

[rs999gti]

I would take a CS degree with no experience over a boot camp or for profit school's fresh graduate.

At least I know the CS degree has standards and academic rigor, with mathematics and some problem solving, which to me means they can think and adapt.

Once both groups get experience though they are pretty much the same resume wise. Then it is up to the interview process and probation period to shake them out

[redeux]

I don’t think this is a very controversial take, and I’m not arguing against the value of a CS degree. You just can’t assume that someone knows even foundational topics because they have one.

[govolckurself]

No, but it makes it fairly likely that they were exposed to the fundamentals, like a lack of a degree makes it likely they weren't. "Well, actually, not EVERY CS major knows their fundamentals!" is not nearly as strong of an argument as people seem to think.

[bluefirebrand]

One example I can think of: A CS major is likely to have at least been exposed to the idea of Big-O estimating algorithmic complexity.

A non-CS grad is much less likely to have. They may not even have a concept that estimating algorithmic complexity is even possible. They may have zero understanding why a massively nested loop structure is slow.

[gpderetta]

If you can learn this stuff in college it is great, but you can also learn it on your own.

[ly3xqhl8g9]

Certainly doesn't help that colleges that aren't at the MIT/Stanford level have as specified purposes only to provide employment and generate profit through state subsidies, education is a side effect, if at all. It is just luck if at one of these colleges you find a passionate teacher/professor/mentor who has enough time to pay attention to you.

The future of education will be the personal artificial mentor, such as GPT10+ will be able to provide, and then the question becomes: how do you generate internal motivation for the children/people to be interested in knowledge and power over nature instead of being mindlessly entertained by whatever the ad-driven feed displays.

[govolckurself]

Vegetables aren't as great as ice cream, but you need vegetables, even if they aren't "palatable". Let's end the notion that everything in computer science is easy and hip and fun. No, recurrence relations probably aren't the most exciting, but they're important fundamentals. I expect developers to be adults and learn difficult things, even if they're not "palatable".

Agreed, though. We need to stop pretending 12 weeks of JavaScript is at all equivalent to four years of rigorous theory and practice.