Math, big-O, and proofs are programming concepts. If you want a shallow understanding of whatever programming languages and frameworks are in vogue this year so you can be handed down constrained requirements in a code mill where you are evaluated on how many lines of code you write per day, take a coding bootcamp. But know that after a few years your skills will be out of date and you will have a hard time keeping up with the field. If you want to solve hard problems that haven't been solved before, pay attention to that math and those proofs. I'm honestly just sick of people complaining about CS degrees for not spending enough time teaching React JS or Ruby on Rails. CS degrees are for people who want to solve problems that are actually hard and new.
Seriously, do we ever hear physics majors complaining that they have to learn all this math that they're never going to use, in order to study the foundational cosmology of the universe? Why don't they just show me how to work the damn telescope!?
No; not any more than theoretical-physics degrees are for people who want to solve "hard and new" automotive-engineering or pharmacology problems. That there exist lessons from a given academic discipline that have practical application within a given profession, does not mean that you need to become an academic of that discipline (i.e. someone who can advance the state of the art in that discipline — which is what "getting a degree in X" means, if you're doing it right) in order to become a professional in said profession; or even to advance the state of the art of the profession (rather than of the associated academic discipline.)
In schools for professional (rather than academic) disciplines — e.g. medical schools, law schools, trade schools, etc. — the lessons from academia with relevant practical application to your field are taught together with the more practical material. For example, in learning to be an optometrist, you learn optics. That's physics! But it's only a certain part of physics, and it's presented through the lens (heh) of the problem domain that you care about.
Coding boot camps are shit, I'll agree. Software Engineering programs aren't. I'll take a professional Software Engineer over an academic Computer Scientist any day — especially to have on my team when working on entirely-novel problems. The professional has been taught the problem space, whereas the academic only knows the solution space. It's a lot easier to have a professional read a few books and papers to learn about the solution-space relevant to solving their problem; than it is to fix an academic's lack of appreciation of the constraints imposed by the problem being solved.
Teachers mostly don’t think their education degree made them better teachers and there’s no evidence they do[1]. It’s widely agreed that at least the third year of USAn law school is useless[2] and there are testing providers whose entire thing is teaching graduates what their law school didn’t but should have if it was professional training [3].
Professional schools are run for the benefit of the staff, so they teach what the admins and teachers want to teach. It has to have some relationship to the field but it can be completely attenuated. People learn to do their job at work, not on a university campus.
[1] It's easier to pick a good teacher than to train one: Familiar and new results on the correlates of teacher effectiveness
https://www.science-direct.com/science/article/abs/pii/S0272...
[2] https://www.businessinsider.com/third-year-of-law-school-is-...
https://forgottenattorney.wordpress.com/2013/02/01/the-usele...
[3] https://abovethelaw.com/2017/05/teaching-you-what-law-school...
It's likely pretty easy to measure that lawyers from professional law schools win more cases than self-taught lawyers. Or that doctors from medical schools have higher patient satisfaction / produce higher average QALYs in their patient cohort than self-taught doctors.
I think a more closely analogous question to the one of CS vs SWEng might be: if a group of psychiatrists (professionals) and psychologists (academics) switch places, who performs better in the other context?
The psychiatrist is an MD who can prescribe drugs. The psychologist wouldn’t have that kind of authority, so they can’t do the job of the former. A psychologist can actually do therapy, which a psychiatrist isn’t trained for. These are very different professions.
> Conclusions and Recommendations of the Interdivisional (APA Divisions 12 & 29) Task Force on Evidence-Based Therapy Relationships
http://societyforpsychotherapy.org/evidence-based-therapy-re...
> The therapy relationship makes substantial and consistent contributions to psychotherapy outcome independent of the specific type of treatment.
> The therapy relationship accounts for why clients improve (or fail to improve) at least as much as the particular treatment method.
Prof does a 'study' where they teach a class with both hands vs with one hand tied behind his back. Each class has 200 students, and he finds that the one-handed class outperforms the two handed class with p=0.045 with N=200...
And I'm like NO! This is basically an N=1 study because the teacher is common across both classes. Have you never heard of pen-effects?!?!?!
Unfortunately, fixing the problem in the study design means convincing a bunch of your friends that one-handed teaching might be better and engaging in an experimental study together... But that's obviously way too hard.
Fully, 100%, whole-heartedly agreed!
I'm leading a multi-disciplinary machine learning R&D team comprising multiple experienced Computer Scientists, Software Engineers and one Electrical Engineer who jumped from EE to SWE to ML research.
All of them are efficient in their own way, but the EE blows everyone else out of the water in sheer _effectiveness_. He may not be the strongest programmer, but his solutions have an elegant simplicity, take the right trade-offs and solve the damn problem.
The CS members are exact opposite: they care about the solution more than the problem, leading to hard-to-maintain / partial / sometimes outright wrong approaches. If they don't find the problem mentally stimulating, they redefine it to make it so, and then solve that problem instead.
Problem: display one point in an image
EE/SWE solution: calculate the xy pixel location and pass it to the renderer
CS solution: define a novel normalized coordinate space, so (0,0) and (1,0) are two specific locations in the image (not center, not corner, but two content-sensitive locations); for every image in the database, calculate a 4x4 "normalization" matrix to map pixel coordinates to normalized coordinates; now calculate a 4x4 "location" matrix with the location of the object in this normalized space; problem solved.
Note how this not only fails to solve the original problem, but it also creates multiple new ones.
Our team then had to point out that all of our user data, generated data, rendering code, user interface, user manual are standardized in pixel coordinates (_industry_ standard, with strict regulations), and that no, defining a new coordinate space, migrating terrabytes of data, and convincing the industry to switch over is not going to happen.
So yes, give me an EE/SWE problem-solver over a CS academic any day of the week!
What about tech debt? Are they writing shovelware or something? Over time, as requirements drift, how do they even know their stuff is way off of being a reasonable solution?
CS doesn’t even start to scratch the surface of reasonable solutions though. CS programs don’t teach you anything about architecture, technical debt, testing, source control, bug tracking, etc.
Bug tracking you can learn in a day. It's more about which tool your company is using than anything fundamentally difficult to understand.
Source control you can learn in three days, and I was (briefly) introduced to git in my CS degree. How source control systems work under the hood with diffs, Levenshtein distance, etc. -- that's the kind of thing CS covers. A CS major understands source control way better than someone who's just been using it for a while.
Testing is more of a habit or practice than a subject to learn about. And you absolutely learn to test your own code if you don't want to fail your assignments, because the professor sure is going to test it.
"Technical debt" is a communication term that was invented to help business people correct misconceptions about how software engineering works. If you mean they don't learn how to make maintainable software, I agree that's not a focus. Maybe it should be. But of course nobody in the industry seems very good at that either.
"Architecture" is a tremendously vague term. Are you talking about large-scale, multi-system architecture? The MVC architecture? A web tech stack? Most of those things are either just putting together things you already know, or a subject that you can learn about in a CS degree if you want.
No you can’t. You can learn how to use a specific bug tracking tool in a day. That’s not related to learning how to write/use/organize/prioritize bugs.
This is something that all of my junior engineers sucked at at Google and it took months of prodding to get them to write useful bugs and years before understanding how to prioritize bugs.
> Source control you can learn in three days, and I was (briefly) introduced to git in my CS degree. How source control systems work under the hood with diffs, Levenshtein distance, etc. -- that's the kind of thing CS covers. A CS major understands source control way better than someone who's just been using it for a while.
This is completely wrong. Knowing how a diff is generated is completely useless when learning how to use git, perforce, whatever. 99% of learning source control is about the concepts of that particular tool and how to manipulate them (e.g. branching, rebasing, squashing, merging, cherry-picking, etc).
> Testing is more of a habit or practice than a subject to learn about. And you absolutely learn to test your own code if you don't want to fail your assignments, because the professor sure is going to test it.
This is what someone who knows nothing about testing thinks testing is. Running code before you submit it is a specific type of test, and it’s a pretty bad one. Making code testable involves architecting your code in specific ways and knowing when to use fakes, mocks, functional tests, unit tests, fuzz tests, performance regression tests, etc.
To claim it’s just a habit or practice you follow just right before you submit is a joke. This is one of the hardest thing to train new grads on when they join a company. Part of it is they have notions like yours implanted by completely out of touch CS professors and grad students.
>Technical debt" is a communication term that was invented to help business people correct misconceptions about how software engineering works.
CS doesn’t teach people how software engineering works either. That’s the point.
> Most of those things are either just putting together things you already know, or a subject that you can learn about in a CS degree if you want.
No, you cannot reasonably learn about these things in a CS degree because they are completely uninteresting from a CS academic perspective so the professors don’t care about it. A professor who teaches you about the lambda calculus is just as qualified to teach you about making a maintainable and scalable service as the professor who taught you newtons calculus.
The whole point is that CS only has a small intersection with writing software at the leading tech companies and an even smaller intersection with writing software at normal businesses. It’s useful for distinguishing between new grads but it’s garbage compared to industry experience.
I say this as someone who got a phd on the CS side and then went to Google. They are just completely different universes.
By "problem domain" I mean the things that impose constraints — for a structural engineer, that'd be e.g. building materials, soil, weather, etc. The things that have tolerances.
By "solution domain" I mean the space of human ingenuity that we can apply in our designs, in order to make something possible that wouldn't be possible with a naive approach. For a structural engineer, that's things like "suspension-bridge cabling" (more general principle: tensegrity) and, I dunno, "flying buttresses."
The problem domain of building software — the parts that impose constraints — are things like what factors lead to robustness (or lack thereof) of a language runtime under production load; programming-language error-rate as a function of language-syntax UX design; evidence-driven software project scope analysis; the trade-offs involved in attempting to scale a process horizontally vs. vertically; the effects of state on ability to scale; etc.
Someone who understands these things knows how to engineer software, the same as someone who understands material tolerances knows how to engineer a structure. If they only know that, then they can't draw you a building (that'd be an architect) — but they can take that architect's blueprint, and tell you whether the building described by it will fall over, and whether there's any simple thing you can do to solve that, or whether you need to draw a different building.
But note that you learn the solution space naturally, over time, as you're exposed to the solutions people use in the field. A machinist will learn the tools of their trade as they run into them in the shop, and as other machinists demonstrate them, and as books refer to them, and as job-lots demand them. None of this requires academic rigor. It's just learning on your feet.
A SWEng might not be aware of the academic result proving some more-optimal data structure exists for something. Just like a machinist might not be aware of a not-yet-commercialized maser CNC lathe. But they don't need to be, either. Very rarely does solving novel problems require novel tools. You can build the part you want to build with the machines you already have in your shop, and maybe one new one you buy off eBay. You can write the code you want to write with your not-so-optimal data structures, and maybe one new one you find in an ecosystem library.
Every once in a while, getting things done might require you read a journal paper written by an academic. But let's be very clear: it doesn't take a degree in some field, to be able to read — and make use of! — journal papers from that field. We've got educational vloggers — people who perform on camera for a living — operationalizing stuff they saw in journal papers all the time! If they can do it, a professional in an adjacent field to the academic discipline can certainly do it.
It's surprisingly how little actual fundamental, theoretical Physics you need to know to do Physics! I'm not saying it's not important, the point of being a Physics major is not only to train you to be a researcher, but for the sake of the knowledge itself.
It's very similar to CS in that regard; almost none of formal CS is useful when doing software engineering, and when it is useful, the skills are in knowing to recognize a problem and how to research it, just like Physics!
"Computer science" is a term that no longer fits the mental model of the general population's idea. Basically nobody is thinking "Computers? Of course! You mean the lambda calculus, Turing machines, how these theories relate."
Most People are thinking about about the internet, websites, games, apps, robots, and so forth. Indeed one can build all these things without any concept of how busy a beaver really is.
Then you have a smaller subset of people who (allegedly) understood what "computer science" is from the outset, and they turn their nose up at anyone who misunderstood what this "Computer science" was. Even worse, they often feel somehow superior. How dare you be ignorant?
Practicality and value: these things can exist outside the realm of dense theory. Anyone who says otherwise is trying to feel better about the years and/or money spent on a very challenging and painful degree.
It is like the difference between a person who pours concrete foundations, and a person optimizing concrete formulas. Society needs both, but the skill sets are different.
I did take design patterns classes and such in college, but imagine taking 200,300, and 400 level design patterns classes and learning how to architect scalable systems in the cloud or on-prem.
Of course there would be programming classes too, but I think there's some room for a program that I'm imagining. Boot camps don't cover the engineering and architecture parts so it would be somewhere between a bootcamp and a CS degree where you're writing operating systems and big endean and Big O notation
You are right that these people will have a hard time later. What also needs to be understood is that paying attention to something in which you have no curiosity is hard. I never paid attention to Maths / Stats / Probability and now I am having a hard time trying to learn machine learning / AI. But now my curiosity for these technologies is dialled up all the way to 9 and in my free time, I am relearning all these concepts I missed.
And what I have discovered is that these concepts were easy. The university presentation of it was done without any motivation. It took a useful and easy subject of math and made it hard.
Amen!
I like the way you have worded this. In particular for first-year math courses, they are super useful and should be seen as "basic science literacy" and much more people should have access to this knowledge (not just people who take 3-4 years of courses in a STEM major). I've been working on products to make this happen. Links in profile.
The "basic science literacy" I can see everyone benefitting from (in particular devs): (1) math modelling skills from high school math functions, (2) vectors because EVERYTHING, (3) PHYS101 (mechanics) for the predictions-using-models skills, (4) CALC for understanding concepts of rates of change and accumulations, (5) PROB because important building blocks for modelling data, and (6) STATS so you learn how to infer model parameters from data.
It's not a coincidence the above list of 6 are part of most UGRAD degrees (either in first or second year). These are the basic tools that everyone benefits form knowing. I am really enjoying the "unbundling" that is happening of the basic science literacy teaching and the credentialism.
This totally depends on what type of engineer you want to be. It's quite possible to be very successful, have a great career and make a ton of money as a software engineer without ever tackling problems that are "hard" or "new".
What you call “shallow”, others might see as “practical”.
It’s possible that this person has chosen study path that isn’t the right one for them. That’s a tricky spot to be in especially in these times. I suggest a little more empathy, and a little less venting.
Oh… I just need to know the basics? Damn, such a great use of my time.
CS degree in a nutshell.
Usually I find proofs are what you bring in the consultant for.
I'm not going to hand on heart vouch for anything like that as a generalist.
Combinatrics, Big O and set theory absolutely. Everyone is far better off with those.
1. The definition has no bearing to what's happening in the real world, or
2. "Computer programming" ceases to exist as a productive activity and you need to invent a new name for AI-assisted programming.
Oh, and there is nothing tautological about it, at least as far as most programmers seem to work.
Pretty sure you missed a couple news articles recently...
https://news.ycombinator.com/item?id=30179549 https://news.ycombinator.com/item?id=27676266
They're not exactly reliable, but you probably could say the same for the earliest compilers (from programming languages to asm/machine code).
I'm not saying they will definitely be usable in the short term future, but that future is probably coming sooner or later, and I don't think a fragile definition (programming==="applied formal logic") is worth reiterating over and over again as if it were some fundamental truth.
If I'm reading them right, urthor's point is that the average programmer doesn't directly benefit from being skilled in developing formal proofs about code. (I rambled at some length on this topic recently. [0]) Very few software development workplaces value correctness so highly that they invest in formal methods.
That said, I think the case can be made that learning about formal methods is useful in instilling a sense of how rigorous software development can be, and perhaps to develop a healthy contempt for hand-wavy sloppiness. Perhaps it's also helpful to learn that informal requirements, formal specifications, and implementations, are three different things. I think this may be true even if we rarely use formal specifications in practice.
If we could strip out of reality the bits that can be understood as a practical application of the basic branches of math there wouldn't be anything left. Nevertheless most people get a long way in life without needing to engage with that (which is lucky because there is too much to learn in one lifetime).
Looking at code as applied formal logic is not a useful view outside of some rather obscure communities. Even code as a recipe is more useful view in practice.
But that is almost the polar opposite of treating a program as applied logic. If there is one thing that is not reasonable when dealing with logic, it is "proof by multiple test cases that seem to work, I think".
And I don't clear the low bar for de Morgan’s laws, I've completely forgotten what they are. And on looking them up, that doesn't look like an important component of programming. A programmer could reasonably get away with not knowing them. Probably going to learn them by rote over a few years, but that is hardly "applied logic" in any sense that is worth talking about.
If people came for the science, everyone would ride off, discover something, and get a PhD.
I just see formal proofs as something you get a genuine scientist to do. If you're someone focused on rigorously correct proofs, you get a rigorous PhD.
I don't pretend that I'm up for that, or that I'm qualified to produce quality work in that space.
But I also don't believe any of my fellow terminal undergraduates are the right sort of people to do this work.
Let's face it, we all had a close encounter with the mathematical proofs, and ran in the other direction as fast as we could!
A lot of modern entry-level programming is the same as builder-work... take a brick, take some cement, spread the cement, put the brick in the right place, and in the corners, cut a brick to size. Yes, sure, we need a lot of those people doing random programming jobs too.
But, if you want to build something bigger than a doghouse, you also need a lot of math and calculations, before you even touch the first shovel, to calculate if the whole project is even theoretically feasable. Stuff that works in low scale, sometimes breaks horribly, with larger amounts of data, and i'm not talking facebook scale, but going from 10 to 500 users. If you want to go higher, things become even more broken for someone who just "lays bricks", and a lot more thought and math is needed to make things actually work (and scale).
I'm sorry to break it to you, but your personal belief on the virtues of ivory tower feats doesn't hold any water in the real world. At all.
The most important competency, by far, is being able to onboard. Whether it is onto projects, frameworks, programming languages, architectures... Being able to jump in and get up to speed and fix things and implement features is what matters.
No one cares at all if you know an algorithm by heart. Plenty of critical services are built upon crude O(n²) brute force implementations that are good enough, and no one bothers to waste 5mins to even switch the underlying container.
You're talking about a field where premature optimization is recognized as one of the worst and most fertile sources of problems. And who exactly is behind this problem? Precisely these short-sighted theorists, who believe big O musings has critical importance when it has close to none beyond superficial analysis of "should I use an array, a linked list, or a hash set"?
I know people with a boot camp and experience with a framework who landed jobs in FANGs, and I know PhDs in computer science that can recite inconceivable algorithms who can't get a job in the industry. How do you explain that, if waxing lirically about computer science is supposedly so critical?
Also, runtime analysis isn't that difficult of a skill to pick up.
Runtime analysis isn't that difficult of a skill to pick up if you have a decent university-level math background. You can be a productive programmer without that.
It's a really narrow mindset to put math specifically on a pedestal. A lot of hard problems with computers don't involve heavy pure math. A lot of those problems get categorized as "software engineering" and as such it is often claimed not relevant for "computer science". But given the importance of software in today's world, academic institutions seem woefully disinterested in setting up "software engineering departments", and woefully disinterested in promoting "software engineering" degrees as an alternative to the typical CS degree as a entry ticket towards a software engineering career.
You must learn this (mostly) useless skill to do enter a profession that where you're probably not going to use the skill. It's classic gatekeeping.
You might argue that research universities are not supposed to be vocational colleges, but that's a hypocritical lie too -- they basically have to be, otherwise they'd be out of an important source of funding (tuition). The existence of bootcamps are evidence that these fancy "math" people pretending to be computer scientists are basically incapable of teaching anything useful to people wanting to learn to program computers. If bootcamps are so trivial, why couldn't universities offer (for example) summer courses that do the same thing? We're not talking about CS majors here -- we're talking about non-CS non-math majors who might want to learn more about programming. Is it reasonable to force feed them CS type pure math as well ? (read the parent posts again -- Quote: 'I went to the University of Waterloo and took a "Intro to CS for non-math students" course.'
Physics majors are called physics majors, not "telescope science" majors. If there's a "telescope science" department I expect them to teach, in addition to theoretical physics, practical courses on how to operate telescopes. My not so humble opinion is that CS departments are a misnomer, but they kept the name because CS degrees are popular, the field is flush with research moneys, and they're happily eating the profits from the software engineering cake while having their math cake too.
The pure math specialists in CS departments churn out starry-eyed students who in turn perpetuate the myth that CS is (only) math, and the impression that hard problems in software engineering is not a worthy intellectual endeavor for a research university. This attitude is going to hurt us in the long term. No amount of strawman arguments about ReactJS bootcamps is going to change this fact. Those bootcamps are evidence of a total failure of academic institutions to actually do research on and teach software engineering.
------
In case it matters, I learned all those Big-O and algorithms shit in high school, and I'm not criticizing it based on ignorance of what they are and how useful they are. If anything, those concepts are too trivial to deserve so much "screen time" in the curriculum. I have friends who work in CS departments and publishes on FOCS (you know what it is, right?) etc. I'm reasonably informed about what I'm talking about, and I'm aware that many CS researchers just happen to like to research on math-ish topics (which is of course not their fault). But what I'm trying to say is that there is a fundamental, institutional problem with people snobbishly brushing off real world software engineering problems as if they are somewhat inferior. Get off the high horse already. You don't really need to learn the concepts of limits of sequences to infinity to count 3 nested for loops and know that maybe it will be slow for large inputs. Math will actually not tell you how slow it will be -- FYI sizes under 100 is usually acceptable for O(n^3). Claiming that "trust me, this math thing is so much more fundamental" is a really poor excuse for teaching (mostly) irrelevant concepts while pretending the degree is relevant to industry.
And yes, I don't have a CS degree because I already saw through this bullshit 20 years ago when I was in high school. I made sure to learn the stuff I needed to know and skipped the kool-aid. Got a degree in law (it's an undergraduate degree here), and surprise, I actually learned a few things about law -- and they didn't shove pointless math down my throat. I mean, if they wanted to, they could model precedents as an directed acyclic graph and make a couple theorems out of it, right?
Your claim about gatekeeping is later contradicted by the fact that you actually didn't have to obtain that degree at all. I didn't have to either.
I do agree that "Computer Science" is a somewhat misleading name though. It's pretty much as if we called astronomy "Telescope Science" and then wondered why people that come studying it expect to learn about building telescopes, with others arguing that you need to know a fair share of physics in order to build a good telescope anyway (which of course is true, but...).
And biology is just self-replicating organic chemistry.. and chemistry is just the physics of outer electron shells.
No it's not about react or ror.
It's about solving actual real life problems. 99% people don't do CS to do academical research, but to work on life change products(and that's more likely to come from user research and fast prototyping, than from theoretically perfect fundamental research).
Some people build millions dollars software products, solving real life problems, without having a clue what big-O, quadratic functions, or even a lot of actual theoretical programming concepts are. And I personally know a bunch of those people. Some people know almost everything there is know about CS theory and never build anything useful to anyone.
Physics have literally nothing to do with CS or SWE. I think this is just pointless elitism.
Personally, when I chose electives I chose systems electives: Operating Systems, Databases, Networks, Programming Languages, Graphics, etc. In these classes the bulk of the work consisted of programming in C.
I suppose it could be systems if you are building a compiler or vm, but that to me is different that programming languages.
You had an (mostly theoretical) Automata and Formal Languages course, which had regular/context free languages (including regexs), grammars, and pumping lemma. lex/flex/yacc/bison, recursive descent, and LL(1) LR(n), LALR were in a Compilers course. Programming Language exposure to a functional language (ML) and a logic language (Prolog) plus some other stuff was the Programming Language course.
Type Theory, lambda calculus, and so on is relegated to advanced graduate courses that are given when a faculty member feels like it.
The theory and practical realms are very tightly intertwined in programming/computer science/whatever you want to call it as long as it isn't "information technology".
On the other hand, the portion of "math" that is applicable computer science/software development/whatever is pretty distinct from much of the "math" in math departments.
The goal is to be able to efficiently solve non trivial problems.
-- https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD103...
Some comparisons are just literally true, for example Honda vs Acura is the same as Lexus vs Toyota. Their both high end car brands owned by a parent company that also puts out mass market cars. That’s a description of strategy not trying to extract meaning from caparison between dissimilar things.
Anyway, a farmer can build a shack without talking to a structural engineer, and a banker can muddle through coding an excel spreadsheet. But trying to muddle trough via trial and error isn’t enough to build the Burj Khalifa or a modern OS. Thus we want to use formal methods to minimize risks, costs, etc. That’s what gives rise to CS and engineering disciplines, not simply trying to staple math onto a field.
The course described doesn't seem to match your description of comp sci either.
Which matches my experience of a technical course in Waterloo. They need to update their pedagogy.
I agree simple math problems may not be the best exercises to program, but the point is you should be doing a lot of such specific (but diverse) exercises to get the general idea.
I think that some of the paradoxes of CS vs programming have to do with a single academic discipline trying to serve conflicting needs, such as:
1. Teaching programming to students who have never programmed before. This is handled differently by different fields. For instance math majors are expected to have a fair amount of high school math in the bag before starting college, but psychology majors have rarely taken psychology in high school.
2. Students with an actual interest in CS itself as a field of study.
3. Students who know that they want to get a college degree in something but are hoping for a career in programming.
4. Competitive students who know that CS is the "hot" major right now.
And high school guidance counselors are pretty much in the dark about it. On the other hand, every college major teaches you more stuff than you will use at your first entry level job. "Why do we need to learn this" is a constant refrain. For instance most engineers will never use their college math after college.
For me, way back in 1982, I skipped CS altogether and studied applied programming by majoring in math and physics.
Classes like Computer Organization, Operating Systems, Networking, Databases, Software Engineering Fundamentals, the first year programming sequence, etc. could hardly be considered math courses.
so a math degree has to have every single course be a math course? do they not take literature?
Networking had me prove the theoretical limit of networks using calculus and other things, databases had us using relational algebra and other proofs... it certainly wasn't `select * from users;` kinda course. it's a math degree at least at my university and most reputable ones it is. are all classes 100% pure math? no of course not but the emphasis is math.
They’re not math degrees, and neither is CS. The emphasis isn’t math in a CS program at any reputable university; the emphasis is computer science.
When you say, "the emphasis is computer science" what exactly does the term "computer science" mean to you? I'm not trying to be a jerk here. I think the term "computer science" covers several related, but distinct, disciplines so it's helpful to know exactly what the other person is referring to.
General electives like a math major having to take a literature course is very different from a core required piece of the major being literature.
to be frank that doesn't sound like a very rigorous school for computer science... that sounds more like an information science curriculum instead of a proper computer science one. I'm talking university of california style learning or the equivalent.
Oh give me a break. CS 122 from UCI is exactly a “select * from users” kinda class. Sure, it has some sparse elements of theory sprinkled in, but pretending it’s some form of math class is outrageous.
But then UT Austin may not be a reputable university, computer science-wise.
[Certainly, they've redone the curriculum since I was there, and I don't like what they've done.]
1 of these things isn't like the others.
There are places where theoretical physics and applied math are put together, and places where CS is put with math.
Upstream comment mentions Waterloo, where CS is as far as I know still part of the math faculty (e.g. multiple departments), not engineering. In that specific sense, every CS degree they give is a math degree - but other places give B.Math also.
This isn't just pedantry, the reason is that the boundaries are pretty fuzzy, and don't really work with the sort of absolute line you are hoping to apply.
Except that those details seem to require a considerable amount of work.
The third category is mostly, if not all, implementation details. The fact that this is most of the work doesn't change that. I'd argue that most of the second category is implementation details as well.
You also compared CS to physics and chemistry which is a bad comparison. Physics and chemistry don't have an equivalent foundation to theoretical comp sci. I'd also argue that comp sci isn't a science at all. What I do on a daily basis as a programmer is closer to plumbing than it is to science.
Either that's not true, or there are an awful lot of physicists and chemists out there wondering why they took so many math courses.
But my experience was that you can get a long ways into a Computer Science degree before anyone tells you that you're studying the wrong thing for career prep. It reminds me of a student I saw who was in Electrical Engineering because he wanted to be an electrician. The university was happy to take his money, and nobody told him he was in the wrong place.
It's important for teenagers to have guidance when choosing the educational path that's right for them. I know that at 17 I was extremely ignorant about Computer Science vs Software Engineering vs Computer Engineering. They all sound the same when you're inexperienced, just know you like computers, and don't know anyone who understands the difference.
The truth is computer science is the science of computation not how to perform specific computation. General CS education follows the line of most STEM degrees, minus the degree for more advanced math like PDEs except when you're in a specialized scientific computing sub-degree. We all had to take 3 semesters of calculus, 2 semester of discrete math, and one semester of probability. ALL of these are important to various fields of CS.
Programming is rarely discussed. Most ABET programs give you one to two semesters warm up and that's the last time you see programming except for a few elective courses. Programming is a means to an end for a CS major. Once your algorithm is verified mathematically on paper you head over to the terminal to implement it and play around. Programming first then designing is like a mechanical engineer building a car and then drawing the blueprints.
The vast, vast majority of computer science even today can be done on paper (with enough paper, of course). programming is a means to an end. If you want to be a programmer get a job out of high school because it takes virtually nothing except drive to succeed. Getting a CS degree for the purpose of being a programmer is like getting a mechanical engineering degree to be a machinist. Sure, you can do machining. Just like you can do programming as a CS major. But the CS degree is so, so, so much more than programming.
Everything your daughter is learning w.r.t. math, logic, proofing, etc is CRITICAL to the generalization of ideas into algorithms that are language and implementation dependent. A mathematically verified pure algorithm can be implemented anywhere, by anyone, at any time not unlike a complicated math formula. This is why the weed out is a good thing. People who just want to be programmers leave the program and become programmers. No sense in wasting time in a CS degree if your aspirations are to become <language> expert.
Programming is secondary.
Source: Comp Sci major
My daughter is studying comp. sci. right now and there seems to be a ridiculous amount of math and math proofs and very little programming in her program (she’s still in her first year). The spend a considerable amount of time proving stuff using big-O (and theta and omicron etc…) and surprisingly little time applying those ideas.
I think what you wanted (and what should be offered to everybody) is a course designed to teach programming and programming concepts.