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...
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 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.
Learn assembly, then learn C, then code up a small OS and learn semaphores and stacks and how a computer actually works.
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.
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.)
What role do you believe lambdas and support for functional programming play in object-oriented programming courses?
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.
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.
https://webmasters.stackexchange.com/questions/27693/should-...
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.
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.
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).
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.
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.
You can do it in Switzerland:
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.
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.
That's the type of condescending, discriminatory bias that having a degree affords, I guess.
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.
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.
This bears repeating.
It's important to learn how to deal with asynchronous and concurrent and parallel programming, but it's more important to have a firm grasp of message-passing and event-driven architectures.
Rote learning the computational complexity of obscure algorithms no one uses does not hold a candle to knowing how to write clean and testable code, and design a component to accommodate changes.
This computer science bullshit starts to feel a lot more like an exercise in ladder-pulling than actually prepare and assess an individual's ability to do meaningful work.
// 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.
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.
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.
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;
}Employers MUST NOT require university degree where trade school is sufficient (99% of positions in industry).
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.
"Programming" in industry has a very narrow definition though.
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).
Computer science involves math, information theory, and other disciplines insofar as they pertain to programs and programming.
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.
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.
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.
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.
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).
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();
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.
The answer is: it runs on dad, poorly :)
Or, you really don't think I can design a logical grammar to formally express the creation of a PB&J?
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).
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, 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 and binary interfaces, process state, environment, alignment, and words.
Geezer reaction:
https://en.wikipedia.org/wiki/Computer_(occupation)
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.
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…
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 that 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.
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.
...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.
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.
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?
Imo I had a very good and broad foundational composition, e.g. also starting the first semester right away with Haskell instead of the usual OOP indoctrination. Also math, calculus, statistics, logic.. only math, math math is imo wrong focused, CS needs to be about the machines too (e.g. also computer architecture, electronics, how a CPU works from the ground up til some assembler).
Systems programming (concurrency, network programming, even a bit of OS in form of Minix hacking) were part of a later elective course that most took.
A lot of this unfortunately doesn't fit anymore into the tighter bachelor schedule.
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"?
Then why almost every semester has some heavy programming course?
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.
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..
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.
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.
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.