People/companies commonly treating both the same is IMHO one of the major problems of the current industry.

None of the topic you mentioned are fundamental to CS.

They are fundamentals of software development.

Wrt. to computer science they are at most specializations and even then what you might do in a science context of them might differ largely to what you would need to use them for production focused software development. Through they do contain some fundamentals like, e.g. set theory in relational databases and graph theory in network programming and concurrent programming.

You can (rightfully) have a master of computer sience _without having ever written a single line of code_. And going back ~20years that wasn't even that uncommon.

Now today a lot of universities have realized that this mismatch causes problems and are also teaching the fundamentals of software developments additionally to the fundamentals of computer science. Additionally of lot of computer science today requires the use of tooling which requires some programming and SQL.

Still what the "fundamentals of software development" are is a much less clear topic then the "fundamentals of computer science" (and even there people disagree all the time). And for example "relational databases/SQL" is one of the thing people can strongly disagree on weather its foundational to software development or not (anymore).

I may be showing my age but there was a time where companies had new hire programs and OJT where entry level workers could learn the job and learn the job the way the company wants you to learn it. Now there seems to be an expectation that every fresher should have a decade of experience under their belt and know the ins an outs of a job they've never done or at best did for a few week/months as an intern/college hire. This is just another example of companies living on the cheap and pushing the onus training new workers from the company on to the worker. In my opinion it's stupid and short sited.

The vast majority of CS students aren’t interested in the minutia of theory, they’re interested in reliably getting a job in a field that will let them have a family. And schools know it too, which is why a degree can command and justify a six figure cost. All of the saccharine scholarly platitudes aside, the cost of learning about Homer or first year calculus keeps going up every year.

Forcing students to pay for their own vocational training isn’t stupid and short sighted at all. It’s a form of industry-wide tacit collusion [1] and it’s working.

[1] https://en.m.wikipedia.org/wiki/Tacit_collusion

That's why boot camps haven't really taken off: most students can reproduce what they learned but will struggle growing up. They learned the tech before the theory!

I wasn't going insane, I was just going Marxist. (Which sounds like an insult, but isn't.)

More specifically, it seems that you can easily get a load of cash for your startup if you're a Stanford CS grad. Then you grow up, have a couple of liquidity events and put some of your cash in a VC fund managed by a college pal. Then you get asked to listen to a few pitches from young kids and you spend the hour talking about fun times on the quad and in Terman hall. And you vote to give them some cash 'cause they seem like nice kids.

Don't get me wrong. I'm as committed to perpetuating classiest stereotypes as the next guy. But it all seems a bit financially and socially incestuous.

I agree with your sentiment. This was true for a while, but it isn't anymore. Companies would hire you just because you had a college degree, because it showed you were capable of learning. Once they stopped that and required particular degrees, it became a trade school.

If someone is probably going to head somewhere else in a couple years it might make sense to put them through a one week orientation but probably not a 6 month class.)

And hiring a trained worker is overall less expensive than hiring an untrained worker who takes a year to get up to speed and then leaves for greener pa$ture$.

What's more, if you have a brain drain of experienced people leaving for Big Tech, hiring an untrained worker who is able to make messes that won't be cleaned up is sometimes even more expensive than the wages paid to the employee.

The result of this is that after a few rounds of people leaving management is faced with two options. Either contract projects out as the standard approach rather than having software developers on staff or move to "we're only hiring experienced people with all of these qualifications" so that on the job training isn't necessary.

While some will also say "raise your wages to be competitive with Big Tech" - that isn't always practical or able to be justified for budgeting based on the revenue of the company.

The overall industry appears to be bimodal with "Big Tech" and "everyone else". Any employee who can move from "everyone else" to "Big Tech" can out compete any wage offered by "everyone else" (and in boom times this was a much easier prospect).

With that consideration, it was often very poor ROI for any company in the "everyone else" portion of the industry to offer training.

If someone got an offer from Facebook and puts it on the table, there is no way to compete with that as anything other than another big tech company. There's no way that say... Jack's Links ( https://jobs.smartrecruiters.com/JackLinksProteinSnacks/7439... ) can compete with working at a big tech company.

This also goes for interviewing. I've seen new grads (back in the boomier times) say "I have an offer with {big tech co}" part way through the interview and say "ok" and stop the process since there's really no point in going on - the smaller shop better uses their time interviewing other candidates that may accept.

If you could somehow anonymously go through your company's hiring process you'd be offered more as a new joiner for your skills and experience than someone already there, which is bizarre set-up (even though any new joiner has to spend time ramping up & existing staff have a great level of instituional knowledge).

So companies have created a system where if you want to get a fair market rate, you _have to_ move every 2-3 years. I know a lot of people who stay put in spite of this, as they don't like the friction/effort of interviewing & are comfortable/like colleagues etc. If places paid market rate to existing staff, I'd imagine their churn would plummet.

The University of Bologna, the first university, had faculties of law, medicine and theology. That’s a trade school for lawyers, notaries, physicians and priests. While university has always been an alien place for anyone not of the bourgeoisie or higher it’s always been mostly about getting a good job afterwards. There were never enough people whose family had enough money to support them doing anything or nothing to support that many scholars. College is and always has been in large part about getting its graduates good jobs. Saying it’s not a trade school is primarily about snobbery. One of the ways it makes its graduates suitable for those jobs is by teaching them the habitus of university men (and nowadays women) so that they can’t be mistaken for the kind of people who do go to a trade school.

Wasn't this also a time when people could expect to stay at the same company for 10+ years? Things are different now as total compensation is linked to how your options package is doing. People don't stay at jobs where their options aren't likely to be worth much.

Why as a hiring manager would I waste time with a junior dev that does “negative work” knowing that by the time they get productive they would leave instead of poaching a former junior dev from another company?

(More a comment on how some pedagogical methodologies constrain us and less on whether college CS programs are or aren't trade schools.)

OP needs to hire Computer Engineering grads, not Computer Science grads.

Like you said, that background does have a lot of benefits. But the downside is that a CE grad typically spends less time doing "software" work than a CS grad. When a CE student is taking courses on circuit design, FPGAs, and CPU architectures, a CS student might be taking courses about databases and concurrency. I don't think I touched SQL or a multithreaded program in a university course. Those were all "high level" things that CS students focused on.

This isn't meant as a knock on CE grads -- I just don't think it's wise to suggest them as the solution to OP's problem since they have their own set of "blind spots" to deal with.

Anyone who can figure out timing in a complex digital circuit can learn how threads and mutexes and message queues work, but there’s a good chance a CE grad would not be able to speak to those topics very well compared to a CS grad.

Again, this isn’t a criticism of CE. I just doubt OP would have their socks blown off in the areas they mentioned if they started interviewing engineering students.

My CS degree had digital logic (far too many hours working on Mentor Graphics), machine language programming (from Professor Larus of SPIM fame), compilers (from Professor Fischer), databases (from Professor DeWitt), and networking (from Professor Landweber).

Many classes were cross listed with the engineering department. The ECE degree was much more focused on the "designing a computer" rather than "writing software".

The difficult part there is that some degrees are "build hardware", some are "write software", others are "study the science", and others are "a survey of all things"... and others are "just enough in the business school to write html and do JavaScript."

Here are the foundations of computer science: Sets, Boolean algebra, integers, strings, functions, logic circuits, iteration, recursion, proof by induction, loop invariants, automata, regular expressions, context-free languages, Turing machines, computability, asymptotic complexity, data structures, algorithms, NP-completeness, models, formal logic systems, operational semantics.

But to agree with the OP, a lot of CS graduates may not have learned or have forgotten the mathematical underpinnings of CS. A typical bad "CS" education would be some hodge-podge of algorithm design, hand-wavy analysis, and teaching specific technologies/tools (e.g. CSS, NoSQL).

With the rising popularity of tangential fields, we've taken to calling it 'computation science' to help delineate from disciplines that rely on the application of technologies built using CS that run on "computers".

Also, all of the topics that the OP mentions are areas of study in CS there are entire CS conferences dedicated to them. Your comment reads as some really strange and arbitrary gatekeeping around what CS means.

Also helps work toward justifying the "software engineer" title that many non qualifying people like to use.

Learning how to use SQL is more of a trade school course.

I have a BS, Bachelor of Science. The foundational classes were math, math, math, math, and more math. There were no classes in how to operate a machine tool. I befriended the guy who ran the machine shop that built apparatus for the scientists, and he taught me how to run the machines. But that wasn't a class, it was just something I did on my own initiative.

While SQL the language is more "trade school", the original poster mentioned;

>> Database Systems (relational algebra, SQL)

Certainly I would expect a CS course to cover databases, in the sense of 3rd-normal-form etc, sorting, searching, indexing and so on. I wouldn't expect them to necessarily be proficient in any one database product, but I would expect them to understand different ways of storing data, and how to design a "data layout" based on good practices (again 3rd normal form etc).

But in my long career, I've never encountered anyone who learned math on the job.

Math was my superpower at work.

But since I was not a CS major, I never properly learned the academic side of CS. I run into this deficit now and then, and I'm not proud of it. Andrei Alexandrescu joined me on the D project, and had the academic chops, which was greatly appreciated by me.

Would you have been a CS major if that had been an option at Caltech?

For everyone wondering why CS would not have been an option, at the time Walter was at Caltech they didn't offer CS as an undergraduate major. They did have a CS department which did offer some undergraduate CS classes but it only offered graduate degrees. Undergraduates interested in CS typically majored in math or physics or engineering and took the undergraduate CS courses in addition to the coursework of their major.

I don't remember when they started offering an undergraduate CS degree. I think it was not too long after I graduated (class of '82), which was a couple years or so behind Walter.

No. I wanted to design airplanes, jet engines, rockets, etc. I had a secondary interest in electronics, and a tertiary one in programming. I wasn't that interested in the academic side of computing.

P.S. nice to see other techers here!

There wasn't widespread access to computers at MIT until Project Athena. So CS was historically mostly not hands on. And that's somewhere where CS was in the engineering school. At many schools, it was part of the math department.

So, there's a strong academic tradition of CS being more about math than programming. Even the current CS intro course at MIT is mostly about algorithms and you're pretty much expected to pick up Python on your own.

Authored by Dr. Jan Roskam perhaps?

https://www.amazon.com/Airplane-Design-Part-Preliminary-Airp...

I remember entering a Java course, where the professor specifically said to write Java 6, even though it was EOL and Java 8 had been out for a while, and you would get points knocked off if you used any "fancy" Java 8 stuff they didn't know.

Whether it is the former or latter matters a lot. Oftentimes the people taking the course don't appreciate which it either which is problematic. In your example, someone could be given a really good desktop programming class on Win32 whether they used Windows XP or Windows 10. The success of this is orthogonal to the tools at hand really. It is what the professor and/or students make of it.

What's wrong with that?

You're supposed to cover the basics in intro to programming courses, and typically Java is not outright taught in college, and instead it's object-oriented programming using a random OO language, which more often than not is Java. Do you need to use Java20 to learn inheritance?

Also, unless you expect to work exclusively on greenfield projects, the bulk of any developer work is maintaining legacy applications. I still see an awful lot of projects in java 8 and only a few in java 11. Insisting on the latest and greatest java release makes as much sense as pressing to cover Lombok or Kotlin.

Do you need to prohibit Java 20 to teach inheritance? Working with an outdated version as basis is fine, not accepting newer versions for no reason is something different imho.

> I still see an awful lot of projects in java 8 and only a few in java 11.

Sure, but that doesn't mean knowledge of newer features should be discouraged.

Java20 did not introduced inheritance, nor did it introduced any OO concept. Java20 adds no value to those learning OO. If you're writing java code but are not using any Java20 feature, you are not writing Java20 code.

> Working with an outdated version (...)

It is not outdated. You are not using any feature. You're just succumbing to the misplaced belief that new means more value. It doesn't, specially when the only thing that you get is more complexity.

> Sure, but that doesn't mean knowledge of newer features (...)

Repeat after me: Java20 adds no OO feature. You do not have to use Java20 to learn OO. OO courses are not java courses. Do you understand this?

Sure, technically you can still teach HTML in Internet Explorer 6 and OOP in Java 7 or something, but that has no added benefit and is actually more difficult to set up nowadays. And you can't deny that old versions are outdated when they don't even receive security updates anymore.

> the only thing that you get is more complexity.

What part of OOP basics got more complex in Java? And why teach Java at all if simpler OOP languages exist? Not to mention that avoiding complexity can actually be counterproductive for teaching. As an example, I got more than 5 years of Java-focused programming education and afterwards I still didn't know what a classpath is and couldn't write a single line outside an IDE because nobody wanted to expose complicated stuff to the students. Instead of forbidding students from using a newer Java version one should focus on the actually important part.

Some universities choose a more “exotic” but more stable programming language for that reason (like SML or Scheme or Smalltalk), but then also get criticized because it’s not a major industry standard.

But like, that’s the rule. I took a web class in college and the professor was teaching how to use <i> and <b> tags, which are no longer supported as part of the standard. (Not to mention that these days it’s not really helpful.)

https://webmasters.stackexchange.com/questions/27693/should-...

What role do you believe lambdas and support for functional programming play in object-oriented programming courses?

Most algos classes would probably benefit from streams, and there are many of them being taught in Java for reasons unrelated to OOP. Universities often stick to one language for much of the programming curriculum.

Pointless. They are OO courses, not FP courses. You have FP courses already covering that.

> second that under the hood everything can be shoehorned to object model.

You do not need lambdas or FP for that.

So, what's the point of lambdas and FP in a OO course?

If the intent is actually to teach polymorphism and encapsulation, both of those can be done in raw C.

However, polymorphism and encapsulation have existed for much longer than “OO” languages. What is stdout? Seems pretty polymorphic to me. How does one gain access[1] to a variable declared in a .c file that is not exposed via the header. That’s encapsulation…

[1]: there are of course ways, but they are often also true of private members of class instances too.

Learn assembly, then learn C, then code up a small OS and learn semaphores and stacks and how a computer actually works.

They are not required courses. I agree with GP that DBs are not fundamental to CS in any way. It's trivial with other building blocks of CS though: predicate logic, algorithms, data structures. Set theory. Discrete math basics (also fundamental CS) gives lots of examples of normal forms (prime decomposition, mod p arithmetic, etc).

On top of all that, it’s likely their first (or close to first) time in an interview setting. Nerves have a way of making you forget a lot of things.

I personally don't agree with the purist approach that CS degrees should just be maths. There needs to be some minimal application at the very least and different universities will have different maths-CS-engineering boundaries based on how they've evolved.

I've encountered far too many CS interns and grads who couldn't actually write reliable, non-spaghetti code. They also typically write commit messages that consist entirely of "Updated $THING" (no shit, I can see that from your diff), nothing about the why.

My perspective may be slightly skewed from being called in as a consultant to fix the software these "computer scientists" have been hacking on, but I encountered a lot of these people when I was a undergrad student also.

If you want a trade school grad, hire one from a trade school. There's nothing wrong with that.

I wouldn't hire a Caltech grad to fix my transmission, either. (I could fix your transmission, but AFAIK I was the only motorhead at Caltech, which was pretty disappointing.)

TasTAFE offers a Cert III in Information and Communications Technology. This looks to be one third tech support, one third networking and server operations, and one third python / web / CSS. So not really much programming.

A programming trade school to Mr would look like: four years on the job as an apprentice, full time, at some discounted pay rate.

Two weeks four times a year at a training institution, away from the demands of the job, where theory and practice are taught.

My trade certificate (metal fabrication) is a Cert III, my trade school included a fairly wide variety of subjects, both theory and practical.

The employer would be required to give progressively more difficult tasks, and doing apprentice swaps with other businesses to cover industry experience if in-house doesn't provide opportunities for key requirements.

Is anyone, anywhere doing that?

I help train two apprentices every year here in metal fabrication. It's not that difficult, but few developing foetuses are borth wielding a welder. I mean the trade is not difficult, training people is hard.

When finished you can continue for a master degree at a university, but have to take 1 year to get caught up on the theory you missed by not doing a bachelor degree on a university level.

You can do it in Switzerland:

https://www.berufsberatung.ch/dyn/show/1900?id=7671

If someone wants a person with good CS fundamentals and an idea of how to write code in a non-trivial codebase (so commit messages and an idea of concrete SQL and not just "I've proven this expression is correct but never ran it") they should look at Computer/Software Engineering programs, or at least select CS candidates from schools where the program incorporate real software development.

These usually are the worst "programmers", in my experience. And I was one as I didn't go to CS school and was mostly self-taught. Lacking the basics of CS, you are just a code monkey.

> I've encountered far too many CS interns and grads who couldn't actually write reliable, non-spaghetti code.

An intern is an intern, I guess.

> They also typically write commit messages that consist entirely of "Updated $THING" (no shit, I can see that from your diff), nothing about the why.

You should have a an employee handbook and a coding style. Lazy people are everywhere, however.

But you're right that there should be schools that teach the practical programming skills. But it's the the trade schools that should be developed towards this goal, not universities.

Lots of degrees have no pathway to a job or career.

In Europe where third level is far cheaper, it's more looked upon as continuing education. The way in the US people look at high school. Sure you'd like to get a job after, but it's really just a stepping stone to your career and not a huge financial investment that needs to be repayed.

It's still made for those that want to be educated.

In the Netherlands the have, for example, the Hoger Beroep Onderwijs (HBO), which translates to Higher Professional Education. It is exactly tailored for the job market.

HBO sounds more like a vocational system that provides diplomas vs a bachelor degree in reference to universities in this discussion.

This type of system definitely exists in many places but I just assume it's out of scope as we're talking about in reference to CS graduates i.e. bachelor courses.

This is just a simple misunderstanding of what college is for, expanding one's knowledge for the sake of expanding one's knowledge -being a good programmer is not the intent but it might be a by product.

Sure, but those things can be learned on the actual job. So after a few years, the CS student knows both the theory (because of uni) and the practice (because of work)... Whereas someone who only learnt the practical stuff, well, usually lacks the theoretical foundations.

So a CS degree is useless in industry. By the time you learn how to build things that work, you know how things work.

Employers MUST NOT require university degree where trade school is sufficient (99% of positions in industry).

    // rewrite this function so it's portable and doesn't use uint128_t
    uint64_t lemur64(void) {
      static uint128_t s = 2131259787901769494;
      return (s *= 15750249268501108917ull) >> 64;
    }

Software developers aren't paid to write code. They are paid to deliver value.

Your code delivers no value whatsoever. Many masters and PhD thesis are boiled down to a shareable library or even function call. You might feel clever for coming up with it or by knowing some trivia behind it, but ChatGPT can easily spit it out negating all the value you believe you were able to create.

There is no value in something being hard. There is value in delivering value.

We don’t do it because we’re paid for it[0]. If that’s your primary motivation maybe this is the wrong website.

[0] sure, [too] many people are in tech primarily to make money, but it’s a bit sad.

I'm fairly sure it's the people that pay our salaries and choose to keep us employed while we do whatever they need to, based on their perception of our output and how the needs of the customers/users are met.

Will ChatGPT and other solutions like that be helpful with the complex, low level stuff? Perhaps, sometimes - depending on how explicit you'll be with your prompts, but more knowledge about what and how to ask will be necessary and even then good results aren't guaranteed per se.

But will they help out a lot of developers with common, well known tasks and problems, for the majority of developers whose job consists of creating a few RESTful endpoints, maybe a database migration and hooking it up to React? I'm inclined to say yes a bit more confidently.

For starters, if you can't argue what is the value then none can fill in the void in your reasoning.

Secondly, software developers have as part of their job description the task of finding solutions to problems. If they find solutions to problems that don't involve or require whatever trick you have in mind, that tells you what is it's value.

Thirdly, did you ever saw any job advert explicitly requiring prior knowledge of any trick you have in mind? Or do you see ads for the ability to solve problems with a pre established software stack?

> who can't multiply and shift t

Tell me, how many open positions have you ever saw whose main ask was "can multiply and shift"? Zero.

> That would be like Google hiring engineers who only got good because they're good at using Google.

No, it would be like Google hiring people without any CS or IT degree who were good at software development but rejecting PhDs who had nothing to offer other than their little trivia on stuff no one cares about.

You know, reality.

The person paying for it with their own money.

> Many masters and PhD thesis are boiled down to a shareable library or even function call.

Oh wow... I have to ask, hast thou ever wondered _where_ the nicely-packaged shared library or function call implementation code came from in the first place?

Thank you!

    uint64_t lemur64(void) {
      static uint64_t a = 2131259787901769494ull;
      uint64_t b = 15750249268501108917ull;

      uint64_t a_lo = a & 0x00000000ffffffffull;
      uint64_t a_hi = a >> 32;
      uint64_t b_lo = b & 0x00000000ffffffffull;
      uint64_t b_hi = b >> 32;

      uint64_t a_x_b_hi = a_hi * b_hi;
      uint64_t a_x_b_mid = a_hi * b_lo;
      uint64_t b_x_a_mid = b_hi * a_lo;
      uint64_t a_x_b_lo = a_lo * b_lo;

      uint64_t carry_bit = ((0x00000000ffffffffull & a_x_b_mid) +
                        (0x00000000ffffffffull & b_x_a_mid) + (a_x_b_lo >> 32)) >>
                       32;

      uint64_t multhi =
      a_x_b_hi + (a_x_b_mid >> 32) + (b_x_a_mid >> 32) + carry_bit;

      return a = multhi;
    }

There’s math and science behind concurrency and parallelism, and the coordination thereof.

Network programming is a practical application of several parts, each of having foundations in math and science. From coding/decoding, to state machines. Wires are all about math and physics too.

There’s more that is often left out. Specifically holistic systems and their research. Lisp, Smalltalk, Self etc. These systems reach into math, HCI, compilers, JITs…

How many database programmers do you know who ever did anything involving relational algebra when creating or tuning up a database?

This point is specially pointless with the prevalence of ORM frameworks.

> There’s math and science behind concurrency and parallelism, and the coordination thereof.

Please find me the best example you can come up of what you see as math being put to practice in concurrent programming.

> Network programming is a practical application of several parts (...)

This is too much grasping at straws. Just show what you feel is the absolute best example.

> There’s more that is often left out.

There is nothing. You showed nothing as your best examples, and once you showed nothing you were left with nothing else to show.

Enough with this silly "but it is math" nonsense. You can come up with a math formalization of an egg but that does not mean a degree in math will help you boil one. Enough with this nonsense.

Formalising 3rd normal form and giving it a rigorous definition so that we can test if data is properly normalised is a big deal. Ditto having algorithms in concurrent systems that we can guarantee don't have logic bugs in them.

If those things aren't math to you, then what are you willing to accept? Do you mean programmers have to sit down and draw an integral sign or it doesn't count? You're correct that doesn't happen, and you're probably setting yourself up to be steamrollered by someone who sees a well known pattern that the academics have been researching for years.

The typical corporate database has big tracts that have been "designed" by someone doesn't appear to have thought very much about how to store data in an organised fashion. It raises the question of what fuzzy thoughts go through their brain since they are only interacting with a database because they have a need to store data in an organised fashion. Hopefully their thoughtlessness doesn't matter, but doing better than that is a low bar.

It isn't. Half the world already relies on ORM frameworks that barely require any input from the developer to setup relational databases, let alone knowledge on how to normalize them.

On the rare occurrences a project feels that specialization on relational database design is relevant, more often than not it's far more useful to require expertise on specific RDBMS than trivia tricks.

> If those things aren't math to you (...)

You're missing the whole point. No one is arguing that you have math formalisms. The whole point is that those formalisms do not add any value at all. Don't you understand that?

I mean, I can whip out a web app with multiple services running in the backend and with datastore using both DynamoDB and S3, and build a business around it. We can do this without ever knowing who Jack or Joe or Jim or Jose Cobb was, let alone what he wrote. What does it tell you?

I'm going to go a bit further than just not understanding, I'm actively disagreeing with you. Based on your arguments here, in a workplace I would advocate not letting you make any decisions about database schema.

Sounds like the feeling might be mutual there though. Not saying you're bad at whatever it is you do; just I want to have to have schema designed by someone who has thought deeply about schema design. Databases usually outlive all the employees assembling it, can outlive an entire organisation and getting the design right can save days to months of work.

The academics have got entire classes of bugs that they can demonstrate don't exist in normalised data, there are benefits to everyone coordinating around a standard shared view on how to lay out data and usually drifting away from the standard it turns out not to lead to real benefits long term. You can believe that is valueless or isn't math or whatever, but there is no point aggressively introducing opportunities for bugs when there is no reason for it. And to avoid doing that, the person making the decisions needs to understand the theory.

It's unfortunate that most people these days prefer unstructured blobs of json to formal relational databases. It's impossible to get up to speed in these types of environments because every time you think you "understand" the data, you find out about a random property that gets set in rare occurrences that throws off the whole relational model you intuitively built in your mind.

This also does not hold up well in an operations heavy environment. Like all things in programming, a well balanced approach is necessary. Some combination of formally structured data with some flexibility for future requirements is probably the best course of action here, but that's too much work for programmers these days.

...and this explains why database designs are what they are. It's also why you don't learn SQL and if you do you never admit it: It condemns you to a lifetime of maintaining CRUDs written by people who don't understand relational algebra.

You mean good enough?

Are they, though? Or are you just trying to put up a strawman?

Because I assure you plenty of highly reliable infrastructure is running 24-7 without the faintest concern over normalization.

Writing from personal experience. I can also assure you that a lot of this highly reliable infrastructure works only because a lot of tears and cursing that could have avoided if the designers had any idea what they were doing.

Apart from the fact it isn't; elements have specific order and that order matters.

SQL is SQL, it's not relational algebra or whatever bastardization of it you can think up. In fact when it comes to SQL the only use relational algebra has is to tell you that anyone talking about it has never used SQL.

But it's useful to learn the foundational mathematics of these things as there is a direct relationship between them.

SQL has semantics that can be understood by relational algebra of relational bags. It's of course not a 1:1 translation, but the mathematical underpinnings are explained there. It's useful to learn the simpler, more abstract thinking tool in order to understand the concrete programming tool.

Also wrong for Turing Machines, it really is infinite. That's a big difference to arbitrarily large. The halting problem is undecidable for TM's but not for arbitrarily large (you'll need precise definitions though).

The machine with 7918-states, Z, stops (well, Z cannot be proven to run infinitly long) iff. ZFC is consistent. For this it needs a finite amount of space but we cannot calculate how much. If we could calculate an upper bound we've proven ZFC is consistent.

There's only so many that you can buy.

It's not exactly the same thing, but the underlying lessons and mental model matter.

Of course, the move back towards nonrelational data stores these days may make the point moot.

You must be a delight to work with.

https://www.di.fct.unl.pt/en/education/integrated-master-com...

https://tecnico.ulisboa.pt/en/education/courses/undergraduat...

In two undergrad courses, we programmed in an old language and a very outdated environment, the one the professor had used their entire career - and apparently that continued until the prof retired. The courses were about implementing algorithms, so the language didn't really matter, but I would say the course was probably a net negative from a software engineering perspective.

We had a database course covering the mathematics in good detail. We learned the relational model, normal forms and such mathematically, with a little basic SQL at the end. That was great for understanding, as at the end of the course you'd be able to write out the actual maths performed by a query but it didn't really teach SQL.

Multiple professors wrote typical "researcher code" - I don't necessarily want to say it's bad but it's very different from what you'd see as good industry code. Lots of global state, variable names with 1-2 letters, magic numbers. It's understandable why research code to be like that but it is much more fitting for an implementation of a research paper than for a software product.

On my degree, database classes required both theory, as writing a full blown application in Oracle.

Naturally like everything there are students that work around it, but then they aren't in position to complain about not learning.

We did not truly learn any of those though, it's just that they were used.

The specific languages did not really matter, they were secondary, just some tools. One Theoretical CS professor used some really obscure thing whose name I forgot, really niche, again it was only used to demonstrate some theoretical aspects (provability I think).

Most content was math and formal stuff. Some experiments and low-level stuff, like creating a sound directly from a chip (no computer), in assembler, as part of intro to hardware.

I would have fekt pretty irritated and that I was wasting my time if we had had courses about learning programming languages (designing them, writing compilers etc., is another matter). This is something easily and better done on your own, learning the actual languages.

It’s ultimately a matter of the focus of the major and department.

You can graduate without writing a single line of code, without having ever heard of SQL, and knowing nothing about math.

If you do it right. Or is that "do it wrong"?

Mildly off-topic, but is "BS" the usual shortening of this type of degree where you hail from? If it's United States I would be even more surprised that this would be the case, since who wants a "BS Degree"? In the UK at least we normally refer to them as BSc degrees and there's never really a need to expand.

"CS" on the other hand is not short for "computer programmer job training" so I'm confused by the expectation of the original Ask HN question.

SQL itself is full of problems, but the foundations behind it are definitely not; database theory and database internals is one of the deepest domains of computer science, up there with operating systems. And dismissing this knowledge as "trade school course"work is... sad.

We need, essentially, the divide between chemistry degrees and chemical engineering degrees. That hasn't happened yet for CS, but it needs to.

And that's what the OP is asking for - people who have software engineering knowledge, not CS knowledge.

Though I struggle with leet code quizzes so there's that..

Then why almost every semester has some heavy programming course?

1) We should teach relational database purely from relational algebra without an practical example.

or

2) Relational database is a trade school course too.

If 1), maybe it makes sense for in academic sense, but I personally would rather to work with an intern who doesn't know database at all than someone who knows a bit of relational algebra but not SQL.

If 2), how about operation systems? Compiler? Networking? Are these all just implementation details and not belong to a CS cirriculum?

Hum, allow me to disagree strongly.

Maybe the vast majority of those you read, but not overall. My experience is that most research papers look like math, or linguistic, etc, while the annexes show example use cases that relate to actual pragmatic applications.

From my friends that did PhDs and regularly write research papers, here is what it looks like:

- One of them works on detecting or bypassing virus signatures. The papers look like high level linguistic theorems to prove that some grammars respect some constraints. It's mainly algebra and language theory.

- An other works on watermarks that can resist compression. These ones are 100% algebra and analysis. The applications on watermarking are only mentioned as possible use cases, and a proof of concept was done in his thesis.

- One work on transactional memories. I don't think she even know herself how to program, her papers are hardcore math in some intricate vector space. She has no idea what transactional memories are used for, she's just interested in the underlying math problems to be solved.

Programming is just a way to write down a mechanism. A mechanical computer would be "programmed" quite differently than by writing code in a text editor.

It was stated above that 'a function is effectively calculable if its values can be found by some purely mechanical process'. We may take this statement literally, understanding by a purely mechanical process one which could be carried out by a machine. It is possible to give a mathematical description, in a certain normal form, of the structures of these machines. The development of these ideas leads to the author's definition of a computable function, and to an identification of computability with effective calculability. It is not difficult, though somewhat laborious, to prove that these three definitions [the 3rd is the λ-calculus] are equivalent.

— Turing (1939) in The Undecidable, p. 160

Computer science is most definitely the science of programming machines (computers). It seems ridiculous to me to say CS is not the study of programming. Does CS involve other disciplines like math and physics? Yes. Of course. But it uses math and physics towards the end of programming a machine to carry out the programs.

Let’s consult Wikipedia:

Computer science is the study of computation, automation, and information.[1][2][3] Computer science spans theoretical disciplines (such as algorithms, theory of computation, information theory, and automation) to practical disciplines (including the design and implementation of hardware and software).[4][5][6] Computer science is generally considered an academic discipline and distinct from computer programming which is considered to be a technical field.[7]

It directly contradicts the narrative you’re peddling. Please, listen to people trying to explain the nuance to you and actually engage. Don’t just keep repeating the same misconception ad nauseam.

“A computer is a machine that can be programmed to carry out sequences of arithmetic or logical operations (computation) automatically”

“Computation is any type of arithmetic or non-arithmetic calculation that follows a well-defined model (e.g., an algorithm)” AKA a program.

So computation is executing a program. And computers are machines which execute programs.

Turing and the Church-Turing thesis define computability as whether something can be expressed as a program (an algorithm).

So computer science is about programming. The science of programming, programs, and the machines that run them.

Nobody is arguing that computers don't compute. Why are you stuck on that minutia?

This is patently incorrect. An algorithm is an idea, whereas a program contains a concrete representation (implementation) of one or more algorithms executable on a computer.

"Programming" in industry has a very narrow definition though.

Computer Science is the study of how we design algorithms to process data. We do computer science using grammars that allow us to describe abstract operations on data. We categorize the different types of algorithmic solutions to problems. We study the limits of efficiency and prove things about the various classes of algorithmic problems and their solutions. We generally work with discrete structures and type systems (like our beloved lambda calculus, origin of the Y combinator).

You can design algorithms without ever compiling a single piece of code just like you can add numbers without ever using a calculator. In computer science we talk about abstract syntax trees, higher order functions, context free and regular grammars, finite state automata, logic, and numbers. You can even get meta and modify your own algorithm’s data as part of the algorithm itself. All this happens independent of a particular instance of a physical machine.

Programming means “issue instructions to a given instance of a machine so that it behaves a certain way”. We take all our theory and apply it to an electrical device that has a physical processor and fixed memory. We program a microchip by writing chains of instructions to its memory. We measure performance in cycles per second. When programming we talk about machine instructions, loadable images, calling conventions, binary interfaces, program counter, alignment, and words.

TL;DR: just go read the Wikipedia page on Computer Science, it’s quite clear.

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

Geezer reaction:

https://en.wikipedia.org/wiki/Computer_(occupation)

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

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

With a sound type system, you can do things like compose a new type out of other types, and it will work consistently (not produce weird edge behaviors).

For example, C's `void` type introduces anomalous behavior. A function returning `void` is not composable, e.g.:

    void foo();
    void v = foo();

As has been pointed out to me several times by CS academics, I could stand taking a course in type theory. I have a good intuitive sense about it (likely from my math background), but have no idea how to prove something about it.

A CS courseload certainly doesn't (and certainly not in the required selection of courses) cover soundness of a language. Even my theory-focused classload only covered automata up to proofs of regularity etc. This is, sort of, step 0 in soundness-proving methodologies, but it's only step zero.

The whole reason we want to prove a type system sound is so we can prove certain things about the programs that use that type system.

Typed lambda calculus was formalized before the first programmable computers, and it's relation to programming wasn't clarified for another 20+ years (and real type systems don't really start to appear in programming languages for another decade after that afaik).

We use type systems to help abstract patterns of data into logical constructs that can be reasoned about. They are logic systems with grammar that describes relationships between axioms and constructs.

Seriously, go read a textbook and then we can pick this discussion up. Wikipedia has a good overview.

https://en.m.wikipedia.org/wiki/Type_theory

We don’t call set theory and category theory “computer science” unless it’s about programming computers.

Much as how people who study computability are computer scientist, even though none of the asymptomatic improvements to matrix multiplication since 1990 are even remotely relevant to any kind of real-life program.

But there is computer science not applied to computers: Operations research for instance is basically a branch of CS: it is not about programming and it has applications in business, logistics, etc.

My computer science degree covered a lot of topics that didn't require a computer, for example relational algebra, discrete mathematics, and introductory formal logic. Of course, the practical usages of these are often best done through a computer and programming, but it's not a requirement.

In reality all computer science degrees I'm familiar with make an attempt to expose students to relevant programming languages, it's simply practical and students demand it, but the details of coding style, how to use git, or similar topics may not be relevant in a computer science degree. That stuff isn't so hard to learn if you have clear guidelines and they have some baseline amount of intelligence which is one thing a degree tries to validate.

A computer is a machine which runs programs (it computes). That's literally the practical and theoretical basis for computing. Instead of running the program in our heads, we have designed machines to do it for us.

We can calculate SHA256 with a paper and pencil. But we created machines (computers) to compute for us, according to the instructions we give them (the program, the algorithm).

not sure what you mean by this, because there's no such thing as programming without computers. (actually, the first computers were invented before programmable computers were invented)

    1. take two slices of bread,
    2. apply peanut butter to one side of one slice, 
    3. apply jelly to one side of the other slice, 
    4. place the slices together with the coated sides touching, and
    5. enjoy.

Or, you really don't think I can design a logical grammar to formally express the creation of a PB&J?

The answer is: it runs on dad, poorly :)

They should know systems programming, databases, operating systems, web app development, security, basic logic, data structures, algorithms, JavaScript, and some backend languages. Add some ability to interview users, design at least basic UI, organize tasks, release your product and monitor it.

Math, physics, statistics, calculus, proofs, theorems, and computability should be the interest when you decide to pursue PhD. For someone who's going to build ERP systems in Java, Oracle ad Angular these things are completely useless. Most of the developers are like this.

The more important question is: Are you explicitly mentioning databases, concurrency and networks in your posting? If not, then it explains why candidates are not filtering themselves out.

To answer your question: we don't. I have no expectation around this. Primarily asking for my own curiosity in terms of differences in CS degrees.

At some level, we had SQL and network programming in my degree, but only for that level that we knew it exists and how to do it in very basics. We did not have concurrent programming at all as mandatory course.

The most of your deeper expertise comes from the project work here, and depending on which project you end up or choose, they might or might not include above.

  Exposure to computer architecture and organization, information management, networking and communication, operating systems, and parallel and distributed computing.

  It seems most are exposed to them partially through project work but without the base knowledge.

Why don't they know database systems? They might have taken a database course for 4 months 3 years ago and never touched a database again because it's not a trade school. School just validates that you can learn a series of related skills over a few months when necessary.

What's the last thing you started and dropped after a few months just before the pandemic? How comfortable would you be if you interviewed for a job exclusively on that skill?

21 year olds won't know very much of anything in general.

A 21 year old 3rd year college intern is... 21 years old

Three quarters of a four year computer science degree doesn't change the fact they're a 21 year old.

Even in the topics they have covered, the knowledge won't be very deep.

A true mental model of concurrent programming is not something easily obtained.

Frankly, most 35 y/o engineers don't truly appreciate the intricacies of intra-thread concurrent algorithms, unless it's their specialized area.

Frankly, most engineers in the industry are too lazy to learn SQL well.

Lower your expectations of 21 year olds. Lower your expectations of the workforce in general. Hackernews is a self selecting community of tech works who study their job in their spare time as a hobby.

Most people I've worked with go home and watch football after 5pm.

It's worth noting that if you're in the position of interviewing then you probably have 10+ /years/ of industry specific experience.

The applicant's prior ten years included 2 years of covid prison, a fractured high school experience, and learning basic life skills.

Also, usually what you're learning in class are the fundamentals that undergird what you need to know for software development in the job. The basic underpinnings and context to understand what you're learning those first two weeks on the job.

And if you're going to be that dismissive about what you learn in a college course, I'll tell you most of what I learned the first two weeks on the job: how to use the specific IDE the team I was hired onto preferred, how to build their specific project (barely applicable outside the project), how to contact IT to get a ticket to get them to install the IDE because I didn't have permission to, how to use the timecard website to log my hours, where the people on my team prefer to go out for lunch, a few hours of HR sexual harassment and cybersecurity training, how to set up my 401k and medical benefits, etc. etc. Basically, nothing to do with "computer science" which is what the original post was about.

Assuming your semester is twelve weeks long (as is the case at my university), that's less than 4h/week. I'm guessing you're only counting lectures as learning. If you only go to lectures for learning and don't do any kind of work on your own, no tutorials, no office hours, no revising for exams, no practice exercises, no homework, no discussions with your peers, nothing... Yeah, you'll probably feel like your first two weeks at the job is a crash course. But I'd say you failed at taking advantage of learning at a university to its fullest.

They are still only 21 years old, and just literally haven't had as many afternoons to spend tinkering.

When I was in school mostly the poor kids and lower middle class had jobs, but I wonder if that's still the case.

Those 45 hours of lectures are usually condensed material with little to no time to practice. It's expected that you practice during the other 90 hours (and on your own time if you plan on having straight A's).

While you may get more hands-on experience in a few months of working full-time, you usually learn much fewer concepts.

I genuinely don't think most of workplace actually reassemble this ideal. Sometimes you learn ... plenty of times you do something repetitive. Sometimes you don't even learn about own bugs (hello agile). And sometimes they give you great advice and plenty of time they just don't.

In CS, we regularly had courses worth 300h in a semester, fe. analysis, system architecture or software engineering.

In practice, students start to complain once a course tries to enforce their full "hour contingent".

Related: one of the faculties here recently announced the introduction of a threshold grade. If you were bad at school, you are not taken into consideration, even if there are available places.

I had a couple coworkers who were in the same classes as me and as part of trying to improve my time management I'd ask them how long the homework took and would get ridiculous answers like 'an hour' (2+ week assignments usually take tens of hours). I couldn't tell if they were smarter than I thought, braggarts, or liars, but after I switched from a support role to a coding role, in the space of a semester I was doing my homework in 2-3 hours. Often those homework problems are just a bit harder than an interview question, but without practice you're improvising the whole thing and that's a lot of effort.

Before we started talking about 10,000 hours, I already had a rule of thumb that your competency as a developer tends to ratchet up at 100 hours, and rather substantially around 1000 hours. An internship will definitely hit 100 hours, but 1000 is still easily achievable in a year. 10k hours might as well be an imaginary number. That's longer than they've been in school and so feels like an unreachable finish line. Demotivating for sure. 1k just means "work hard for a bit".

There were certainly a lot of people who didn't really understand the question, and I couldn't really help them much without risking the poorly worded guidelines on what would earn you an expulsion, but there were a lot of people spending a lot of time banging their heads against typos and simple structural errors.

I learned early on that the facts and tasks I biff on are often the things I remember the clearest later on, but also that most people are not like that. They remember the things that they got right easily on the test. I'd wager that for most of them, that time spent wrestling with the computer provided very little to no growth opportunities at all. 10 hours on a homework assignment might have yielded at most 90 minutes of actual progress.

For the more difficult classes, that number can be even higher.

So for a class that has 3 hours of lecture time per week, that's 9+ hours per week on that subject alone.

On the job training only works for certain types of skills

This whole “gaps” argument is just people who’ve bought into a system. People coming out of uni have “gaps” as well just different gaps… gaps rich kids have so it’s ok with Google.

That is optimistic

Now I feel obliged to work even harder to make a few million dollars out of it before I'm 35.

I spent so long just jamming my brain full of Vim shortcuts and functional programming theory...

I need to make some money out of it.

Hard to enjoy my hobbies when I'm in debt to the bank and my mortgage isn't paid.

35-year-old here, with a similar box of CS knowledge floating around. Comfortably sub-million, but with a nice house and a couple dogs.

You really aren't obliged, and you don't really need to "make some money" out of it. More money would be nice, don't get me wrong. But you said you learned it because you enjoyed it. Which I did, too. I got my money's worth out of the learning.

You are not obligated to financialize everything you enjoy. It's super important to understand that.

The mortgage anxiety--I get that too. YMMV, but for me, all it took was practice. I don't think about the mortgage on my house. I've owned it for about five years. The money goes out every month. I work on renovating a room or building some furniture or going for a walk with my dogs. It need not be a terrifying specter; it'll either get paid in due course or I'll die and won't have to worry about it.

I think there are a lot of brains (and mine is definitely one) wired to make a bigger deal of things than necessary to provide a sense of direction and meaning, but this one is so abstract and so luck-based that, for me at least, it was deeply valuable to fight against it. I kicked it into the back of a closet, and for me it's a lot easier now to just live.

Again, YMMV.