I learned the nuts and bolts of engineering on the job, and from reading the (absolutely delightful) Boeing design manuals, where they distilled the lore of how to design airliners in a series of manuals.

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.

> But since I was not a CS major, I never properly learned the academic side of CS.

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.

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

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!

By way of context, at MIT (which I'm much more familiar with), there was effectively a CS major out of the School of Electrical Engineering and Computer Science, but there weren't PCs and computing was pretty much limited to Multics in the AI lab. (There was a mainframe with punch cards that you could get a limited account for using with the other branches of engineering. I took a Fortran course then I don't think I touched a computer for the rest of my time as an undergrad.)

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.

> reading the (absolutely delightful) Boeing design manuals

Authored by Dr. Jan Roskam perhaps?

Are these available anywhere public?

Amazon has the ones I was referring to.

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

I didn't see an author. But the different sections were clearly done by different people.

Roskam's books are decades newer!

Thank you, this is indeed what I meant and was covered by our curriculum in the third year. SQL was merely a practical example.

SQL was probably only one semester’s course over a 4+ year college career. They probably continued to interact with SQL here and there in some other classes, but would rarely encounter needing more than cursory, googleable knowledge to get the job done.

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 don’t think top CS programs teach that. Maybe they’ll have a course on implementing databases.

In the spirit of the above poster, I have to say as an undergrad we spent a lot of time on relational algebra rather than SQL, even though the latter is surely more practical.

Honestly, a lot of university curricula are, at best, out of date, since often academics are not necessarily incentivized to learn the latest and greatest of programming.

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.

Programming really hasn't changed much fundamentally in the last 20 years. I think its a good thing university doesn't chase the current trend. The knowledge would be quickly outdated. They should teach the stuff that isn't flavour of the week but common to everything.

Some things do change, though, and courses which involve specific technologies should at least be up to date to a point where people aren't required to use Windows XP when every laptop runs Windows 10.

I kind of get what you mean, but you don't provide a good example. The first question is what are the specific technologies and why are they involved? If you take some outdated version of Java, this could be interpreted as teaching you to be a Swing developer, or how to apply Java for user interfaces and learning some fundamental design patterns.

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.

In general, I find that many fresh college folks (new hires and interns alike) struggle with Java streams. Streams and stream adjacent things like Optional remove a lot of tedium and footguns from older Java code styles, and unfortunately learning them tends to be a speed bump for anyone onboarding to the code base from college, because it’s just not covered, even in a Java algos course where I believe they’d be fairly relevant.

Had a similar thing with a guy who taught Android programming and was stuck on Android 2, while Android 5 or so was out. He did not know about specifying button handlers in the XML of the view and all kinds of stuff. They did not manage to set up the IDE properly for the exam, so that logging and installing the written app on a phone did not work either. Got out of it with a bad grade, because he did not see his Android 2 shit in my solution.

This is why courses should focus on fundamentals not flavour of the month stuff.

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

> even though it was EOL and Java 8 had been out for a while,

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.

I mean, Java 8 had the lambdas and FP which I would argue are pretty important in modern Java.

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.)

> I mean, Java 8 had the lambdas and FP which I would argue are pretty important in modern Java.

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

To prove two points: First that forcing objects everywhere makes things really complicated compared to FP, second that under the hood everything can be shoehorned to object model.

> First that forcing objects everywhere makes things really complicated compared to FP

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?

Frankly if you want to teach object oriented languages, you should be teaching Smalltalk or Objective C, not things derived from C++. Message passing is the defining feature of object orientation.

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

The question is then, why should object oriented languages be taught? It seems to me that for last 25 years or so the true object orientation has been a historical curiosity that inspired polymorphism and encapsulation and only interest for people who want to argue that this and that language aren't true object oriented languages.

Indeed: I wouldn’t bother. Teach procedural and functional programming to undergrads as primary focuses.

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.

Good point. I was thinking about the C++/Java meaning of the words because that way of doing things has proved to be useful but they're not the only way indeed.

Aren’t lambdas implemented as objects with common interfaces in Java?

I don’t just see this behavior in OOP style 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.

As an aside, they are once again part of the standard.

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

> Do you need to use Java20 to learn inheritance?

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.

> Do you need to prohibit Java 20 to teach inheritance?

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?

> It is not outdated. [...] You're just succumbing to the misplaced belief that new means more value

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.

The reason is it creates extra work for the teachers (having to keep up with newer features, bigger diversity of solutions they receive) without much benefit regarding the substance of what they need to teach.

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.

My CS curriculum (15+ years ago) offered Databases as an upper-level elective. Another upper level elective was Compilers. Another was AI. There were other upper-level electives, and any student in the program had to take a few but not all of them. Any student in the program had the option to take the Database class, but not all did.

My CS undergrad in the UK circa 2001 covered the items you mentioned in the first course. The second course was similar to http://www.inf.unibz.it/~artale/DB2/db2-course.htm. With UK degrees there is limited ability for students to pick their own adventure and miss these when they choose a CS degree at a reasonable university.

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.

There is some overlap between programming and CS, sure. But Computer Science is more a branch of mathematics than programming.

In UWaterloo CS there's at least two database courses. One covering SQL/querying/normal forms, another looking at how DBs are implemented.

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 think this is an important point. Knowing how to specifically create a table in X flavor of SQL is something that a new grad can easily look up. Knowing when to consider normalizing data, why one would want to normalize, and why one wouldn't want to normalize, is more of what I would expect someone to learn in college. It isn't something that can be looked up using a quick google unless one already knows it and just forgotten the details.