Should a cs teacher teach non-scientific methods?

My opinion, which seemed to work pretty well while I taught, is that in-class examples should never be "best practice". Learning ComSci is like learning to drive in a big empty parking lot, then on empty streets; or hammering nails into just a board at first -- it's better to learn the basics without a lot of distractions.

One problem is that "real world" examples blow up with details until they take too much time and make no sense. I've seen textbooks with try/catch error-detection around every example, or preferring member function examples over plain functions. Here's a decent example of a cascading-if which would never be used in practice:

if n==1 print("one") else if n==2 print("two) else if n==3 { print("three") } else ... 

We could search for a real example, but it might use enumerated types ( which haven't been covered in class yet) and maybe the real thing it deals with is tristrips vs. quads vs. quadstrips in GPU graphics - making it very long, hard to read and impossible for students to try it on their own.

Another problem is that best practices change plenty over time and place. Time-wise we went from needing to know Design Patterns in an interview to "Design Patterns are Ruining Code". We went from checking pre-conditions to try-catch to adding a new "throws" annotation. And for style (how to name variables, etc...) -- who knows. Place-wise you'll see programming Q's here where one person's solution is another's "I'd be fired if I wrote code like that".

But most important, I feel, is programming is more like math. Maybe we drill on things like 7x4, but there aren't flash cards for "4x^2+5x-6". You learn the factoring trick. Once you know how to factor, integrate by parts, and so on, you can attack new math problems with a combination. And those tricks are learned using abstract non-real-world examples. Many programming problems are the same. Once someone has used simple examples to learn if's, loops, lists, nested loops, classes... they'll know how to break up a big problems into "use a list for this" and so on.

Put another way, coding bootcamps emphasize solving real-world problems. And a criticism is that their graduates can only do those exact things, and aren't so great at new stuff.

There is a misunderstanding here: The "scientific method" has nothing to do with "methods" taught in CS.

The scientific method, in the shortest possible explanation, means that statements about reality need to be falsifiable - and that all those statements are only to be considered "true" until falsified.

Methods in CS are practical precepts of how to solve whatever problem at hand. These kinds of problems are (for sure in an environment where there is a teacher in front of a class) not unsolved problems of how the universe works, but simple tasks designed to allow pupils to practice whatever toolset they have been taught so far.

Asking whether a CS teacher is being "scientific" is a category error - it simply makes no sense.

As to your underlying question: no, your teacher has to prove nothing to you. He is there to enable you to learn facts and practices which give you a tiny, initial peek into what CS is about. What that is is not like following a tutorial on the 'net or some web site. Whatever he is teaching is very likely structured more along didactic lines then what is "best practice". It is most likely mostly designed to get you thinking in CS terms to be able to come up with your own solutions later. It is very unlikely that you will actually use anything you learned in school verbatim later in your professional life.

From a business perspective, if I employ someone fresh out of school or uni, I would not expect them to know even the tiniest bit of practice relevant to what we are doing in the real world. We are also not solving scientific problems; we are creating software, or building technical solutions (cloud stuff etc.). There is very little science involved.

If you use CS for actual science work (i.e., building some simulation as a physicist to work out some theories), then the science is what you are going while writing your paper; not the software you are building. The software is, at best, a practical application or demonstration of your theory, not even a scientific proof (that can only come from observing reality).

If the science you are working on is actual CS, for example, you want to invent a new sorting algorithm or something along those lines, then of course the programm you write after thinking long and hard about it is more "scientific" in that it may be the actual experiment which proves or disproves your new theory, but then again I can think of only very few instances where such a program would be considered a scientific proof for anything - actual proofs are, even in CS, mostly something you do with your brain, pen and paper. Importantly, this kind of stuff is not part of any curriculum where a teacher stands in front of a class; this would be PhD material.

All of this is for practical CS courses (where methods are actually taught). If you are in a Theoretical CS course, you will mostly be learning math-like definitions, axioms and proofs based on them - they also do not follow the scientific method per se, but build a mathematical/logical building which is open to inspection for everyone. If you believe, in a Theoretical CS course, that something is wrong, then your best recourse is to ask the teacher to explain it again. It is incredibly likely that you simply misunderstood (partly due to maybe missing some facts still).

"but not the best possible practice"

And you of course know what the best possible practice is. On a side note you might want to look up the dunning kruger effect.

There are best practices... and there are best practices.

Engineering best practices.

Always use library methods instead of making your own. Don't reinvent the wheel etc...

None of which are followed in CS classes because you want students to learn how to write a bubble sort, quicksort, merge sort, binary tree, etc... because the experience of building those algorithms makes for a better programmer.

style best practices

Such as using descriptive names for variables, and methods. And not using magic numbers... And yes const int FIVE = 5; is still a magic number. where as const int WEEK_WORK_DAYS = 5 is not a magic number. Because FIVE doesn't have a meaning attached to it.

Some of those don't really matter such as:

• Spaces instead of tabs (unless you think tabs are better, in which case Die Heretic Scum).
• Or how to place curly brackets.
• The number of spaces in an indent (3,4... just be consistent).
• snake_case vs camelCase vs CamelCase (again just be consistent).
• This list is really long...

The biggest style best practice is of course what your customer IE the professor tells you to do. As long as your code is readible and maintainable...

The customer is "always right on matters of style" after all

There are good design practices, or perhaps best known method:

I would read stuff by Robert C. Martin for a better answer then I want to put in a here... But basically it boils down to decouple your stuff. Write unit tests where possible. Write integration tests. Write functional tests. Don't have code behavior rely on hidden state (avoid global variables) if at all possible... Etc.

Use design patterns that make sense for the problem you are solving. E.G. don't hammer in screws.

I agree with the others that if someone tells/teaches you something and you think there's a flaw in that, ask/challenge them about it. That is valid about anything in life and not limited to classes in university.

As Owen Reynolds had said in their answer, there is often merit in doing things not the optimal way. A good example for this is bubble sort. Bubble sort is an extremely inefficient sorting algorithm and I can't think of any real life application at the top of my head. But, it is relatively easy to understand and to code. The next step is then to evaluate your code. Is it up to standards, are there better ways to do it? This is called refactoring. In real life, you rarely end up with the best solution on the first try. Often you discover hidden edge cases or other things along the way that require you to update your solution.

I would say that refactoring skills are one of the most important skills you can have as a programmer, because you need to be able to understand code, its implications and come up with a better solution that doesn't have those shortcomings.

From this perspective, I think it's a fruitful lesson to teach and talk about bubble sort. If you start with e.g. merge sort right away, you might discover bubble sort later and think "oh, this looks much simpler" and just use that, because you never learned why it's inefficient.

All in all, we can just speculate because there's no information from you, but I'd give your professor the benefit of the doubt.

From what I get in the comments that has nothing to do with "being scientific" and more to do with "industry standards".

The truth is in pure CS you're technically just supposed to learn the general concepts, ideas and ways to tackle problems. So if that is about the mathematical or logical basis and your teacher doesn't explain them or elaborate why they are optimal and in what circumstances, you should definitely ask follow-up questions.

While if it's just about style and preferences or about the quirks of specific programming languages and whatnot (not the level of paradigms but implementation details), then those are elements that are changing rapidly, might be subject to personal or domain specific preferences, generally differ between programmers or whatnot. So unless the code is broken just go along with it and later do it as you prefer or as your internal style guide and whatnot advices.

Also you should keep in mind that "optimization" is not an objective criteria. It's just "the best (with respect to a set of condition)". So the fastest code is likely just a list of binary commands, cutting all the unnecessary stuff and making use of all the specific quirks of the hardware that you actually work on.

Now if you design simulations which should really be optimized for speed or work with a fixed unalterable set of hardware where you try to get the most out of what you have, then that might make sense.

On the other hand if you don't have these limitations, the code may end up being hard to read, comprehend and maintain and a pain in the ass to port to any other system. So an update is likely going to come in the form of new hardware and a new software basically from scratch.

So with modern tech and the requirements being not about nanoseconds, but rather about "not-looking-like-it's-frozen" you could trade absolutely optimized time, for developer friendliness, maintainer friendliness and maybe even user friendliness. So rather than wd you might be able to write "week_days" and waste a few bits of memory for the extra chars of the name, but ultimately probably safe a lot of time with regards to documenting the code and have other people be able to comprehend it without a glossary.

On the other hand what is considered the "best style" and the best approach of doing something with respect to all these fuzzy objectives that aren't computable by hard science, well these could change over time anyway so you probably just need to keep up with the development anyway so zoning in on one thing might not be the best idea.

So from a CS perspective it's more important to know what is happening on a conceptual level and what the advantages, drawbacks and pitfalls of various methods are. So are you optimizing for memory, stability, best case, average case, worst case and so on and if you know what they do and how they do it, finding out what the best practice of implementing that is, is just looking it up.