That's brilliant and obviously useful for software engineers. Don't forget that you've probably also studied holy wars in considerable depth, too.
This prepared him/her to understand the great conflict of vim and emacs users no doubt.
Easily the most trivial objection I've ever seen in the never ending spaces/tab debate.
Many people I know customise their local environment to suit.
It is amusing to see how directly those skills taught in a religious context apply towards being a good engineer. Perhaps they're more universal than many realize?
That’s not what my religious studies degree was about. It wasn’t expensive Sunday school. They didn’t teach apologetics. They taught scholarship, empiricism and critical inquiry. Philosophy and theology were taught from a historical/critical/contextual perspective, not a devotional/didactic one.
I remember one asking a RELS professor about his internal religious beliefs once (in private) and got a stern talking to about how deeply inappropriate that was.
I appreciate and agree with your comment generally, but your characterization of my degree is not factual.
Funny thing is that it's deemed unimportant when they have to do it themselves, but appreciate it when presented with well-documented tooling/libraries.
Not that they actively want to be bad at it, but they do not see it as a priority, they hate doing it, and they are unwilling to put effort into being decent at it.
In more extreme cases, they will even make somewhat absurd excuses to justify it. My favorite is, "We shouldn't write documentation. It's harmful because it just goes out of date." True, documentation gets out of date, but you can plan to maintain it, or you can just mark it as out of date so people aren't misled.
I've seen this from interns to CTOs and remain baffled by its prevalence.
I've seen this as well. It really makes one wonder how they're able to code properly since programming is, in a sense, also the expression of ideas as text.
Just like writing code, written communication is a difficult skill requiring lots of practice and feedback. A liberal arts degree provides that in spades!
I'd started with software well before university (5th grade - maybe 6th?) and there were not many resources. Our school had a computer, but no classes as such - the staff weren't really even sure what to do with the 3 we had. HS - there were some "computer classes" - intro to BASIC sort of things. I'd already been programming (mostly BASIC, a bit of z80 and 6502) by the time those classes were available.
CS was a thing in university, but just taking one class (some Pascal class), I was generally put off doing it "professionally" by the difficult social nature of the people in the main computer departments. I was not the social butterfly, and they were really offputting (and I may have been not very helpful as well) but I never clicked in that class or the lab, and so dropped that idea as a profession, but fell in to it years later accidentally.
IMHO the worst bottleneck in both practical computing and even much of computer science is the struggle to explain/document the work in, say, English.
I briefly mentioned how my non-formal studies of religion and philosophy have helped to inform me - mainly in the context of "machine learning".
Your thoughts about how such studies apply to CS in general, though, are interesting. I noted that there are extreme overlaps between CS and many, many other areas of study that I believe both informs and is informed by those areas (whether known consciously or not).
We may actually be doing a disservice to ourselves (and perhaps for the world) by having (though rightly, I suppose) tying Computer Science so tightly with that of Mathematics.
Of course, that could just mean that mathematics also in turn informs and is informed by those subjects, I suppose...? Which is arguably true from what I understand of mathematics and the history of mathematics!
I guess, though, is what I am getting at is that we - humanity that is - have somewhat "enclosed" CS as a subset or adjunct of mathematics. Many don't seem to understand or "see" that so many other subjects and topics are involved. Not having that understanding may be hindering our advancement (both in CS and perhaps even as a species).
Yes, most people can learn to code without a degree but to be able to fully understand the scientific/mathematical foundation of why things are the way they are, and to use those skills to create something scientifically new, probably requires a degree.
Indeed, Object-Oriented Programming is harder to learn for programmers who have experience with other languages already (no pun intended) ;-)
When you know a language like C/C++/Java and you learn about OOP you think you understand, but in fact, you don't. So while functional programming was probably the easiest course for me in university, it took me 1,5 semesters to actually understand OOP. In the end, it is not that complicated, it is just that you have to think more on the meta-level than on the implementation-level and I think, for someone who doesn't have access to the implementation-level, it is easier because it doesn't get in the way.
OOP is a concept. It doesn't care about the implementation and neither should you. So if you are talking about integers, don't care about the implementation which might have limitations like MAX_INT, care about the idea of having a number which you can increase and decrease. That is a concept and it can be implemented in different languages and with different limitations.
Next, understand the idea of 'Everything is an Object'. This means that you have a class hierarchy and at the top is the class 'Object' (so everything can do, what 'Object' can do). Objects can receive so-called 'Messages'. When an Object receives a Message, it calls the corresponding method. So for example, in Smalltalk (the mother of Object-Orientation) the expression '1 + 2' means, you have an Object '1' (always the first thing) which receives a message '+ 2' and when the method '+' is being called, it returns an Object ('3').
This leads to some odd situations like
1 + 2 * 3
= 9
Object 1 receives message + 2 returns object 3. Object 3 receives message * 3 returns object 9.
I think that is part of the secret sauce that many tutorials are missing. You can read a lot about the class hierarchy (inheritance, class variables, instance variables, ...), but few seem to care to explain what 'Everything is an Object' really means.
So your OOP program is basically sending different messages to different objects.
Finally, what makes OOP so powerful is that there are some attributes which are being enabled by placing your classes in the right spot of the class hierarchy, so that an object of that class does not just inherit all the attributes, but can also be used as one of its superclasses (polymorphism). That way you can write code that works with a wide variety of objects.
I am sure I missed a few things, but for me, understanding the clean syntax of Smalltalk and the implications of 'Everything is an Object' changed my perception of the OOP concept.
OOP is easier to use when describing a mental model as-is, without the analytical deconstruction that (typed) FP would demand.
I think this is a failure of Smalltalk, not OOP. I tried it in Ruby and Python (languages where everything is an object), both return 7.
I wonder if it’s prepared me better than a CS degree for the actual work I do.
What did I learn with my RELS degree? Hermeneutics— understanding ancient texts written by lots of different authors in their original historical contexts, often which has been deeply redacted over time. Anyone who’s worked on any production code can see the benefit of being trained in that kind of thinking.
The classes I took on theology and philosophy helped train my brain to organize ideas. I had no trouble understanding object oriented programming — Plato would’ve loved it too, I think.
Classes on ethics have come in handy too.
Oh and just, we did a TON of writing in college. Lots and lots of writing, lots of research papers. I had to learn something new, read all about it, and put together a document carefully explaining the idea, with lots of evidence and citations. That skill has come in SUPER handy for everything from bug reports to API clients, to customer-facing documentation, to internal memorandums.