Hacker News Reader

"understanding ancient texts written by lots of different authors in their original historical contexts, often which has been deeply redacted over time"

That's brilliant and obviously useful for software engineers. Don't forget that you've probably also studied holy wars in considerable depth, too.

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

tabs v spaces may be an even greater conflict.

Still ongoing with no end in sight

And on a lesser note, The Cult of Vi vs The Church of Emacs

Here is a pretty good explanation of why tabs are superior: https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...

I'm a bit worried that both the coworkers, the writer of that comment and everyone else in that thread all somehow don't know to put one line of sed in a githook to fix that problem?

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.

https://githooks.com/

It’s not a conflict. A huge portion of the population is just still in denial.

I felt a disturbance in the force. It was as though 1000 angry hn users cried out in pain.

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?

I often used to do this to save myself from sinking feeling of how I made a bad choice and wasted precious time that I could never get back. But let's face it... You can make this argument pretty much with any degree, let it be art, humanities, literature or whatever. But, no it didn't prepare you better than actual CS degree. All those things you described could be perfectly done as part of CS degree as well. Most good CS programs are much more than just code and equations and these days even includes bit of ethics and humanities. However, the point is that the time you could have spent in learning actual CS material, strengthening the foundation and acquiring advanced skills was instead spent in memorizing and rationalizing virtually unrelated minutia about largely outdated and mostly unverified beliefs. It's one thing if you loved this field and wanted to study anyway but quite another if you ended up there without knowing what you are getting in to. It's better to understand this so if someone comes to you for advice or if you are making these decisions for your child, you don't repeat the same mistakes again.

I would say it prepared you differently. The argument is between specialisation and generalisation. It could be argued that a large proportion of a CS degree is useless for one particular application. Who cares about assembly when you do python all day? Or how does that computer graphics module help you with a back end server? Especially when most people have forgotten it when they did it 5,10, 20 years ago. Ah but one might argue there is transferable knowledge in these areas! Your knowledge of assembly helps you to know what’s actually happening to the computer and why that bug happened; or that algorithm for graphics is very similar to this one for a server. These are very valid arguments, and a similar thing is true for an even broader education. Deciphering ancient religious texts gave him a similar skill set as needed for programming, and potentially a different one to most other programmers. So much of life is learning how to reason in different ways, often they come in handy, and different experience leads to a diversity in thoughts, which gives an edge in solving new problems. I am very much a proponent of generalisation and then specialisation (along with variety in this path) for optimal performance.

> instead spent in memorizing and rationalizing virtually unrelated minutia about largely outdated and mostly unverified beliefs.

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.

I repeatedly encounter engineers who struggle to write even the most basic JIRA tickets. It was a real eye-opener on how many technical people, while brilliant, tend to take writing skills (or communication skills in general) for granted.

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.

A lot of technical people don't care to be good at writing.

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.

Many are bad at communicating in general, e.g. selectively ignoring/missing parts of an email, incomplete sentences, typos. Some also have the nasty habit of skimming stuff and replying to what they thought they read.

I've seen this from interns to CTOs and remain baffled by its prevalence.

Well, it's human nature to try and efficiently summarize. You may have to adjust your communication methods to account for that. For example, I almost always try to write emails that contain one central point.

> Many are bad at communicating in general, e.g. selectively ignoring/missing parts of an email, incomplete sentences, typos. Some also have the nasty habit of skimming stuff and replying to what they thought they read.

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.

Maybe they are used to compilers telling them all the typos before it actually compile.

I have a colleague who's a brilliant developer, but trying to wade through his codebase is literally like going through a session of Chinese water torture. And the 'comments' in his code are more mind-boggling than explanatory.

My philosophy degree has been extremely helpful throughout my software engineering career, for many of the same reasons. Clear, concise writing is crucial in code reviews, documentation, product requirements documents, and all sorts of ad hoc communication (Slack, emails, wiki comments, Jira cards, etc). This is doubly true for remote work.

Just like writing code, written communication is a difficult skill requiring lots of practice and feedback. A liberal arts degree provides that in spades!

philosophy degree here too. in general, the ability to approach a problem from multiple angles is helpful, not only in software, but (imo) for life in general.

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.

wow, now wondering what that accident might really be.. ;)

long time followup. i'd programmed (basic, a touch of z80 machine code, etc) since the early 80s, and after school just started applying (via newspaper classifieds) to anything that sounded vaguely computerish. I got a letter back saying "I've never met anyone with a philosophy degree before - come on in for an interview". And I started doing low-end work for a company reselling OS/2 stuff...

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

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.

Funny, I'm similar. I have an English Degree (Fiction Writing emphasis) and minored in Religious studies. It's proven to be a positive in so many ways, mostly because I am an excellent communicator and able to explain complex subjects to non-tech folk. I've also been told that I stand out as totally different from every candidate they've interviewed, prior. I started programming on my own at age 11 and have been passionate about coding my entire life.

What is your opinion of Inform 7?

I just posted some rambling thoughts in this thread about not having a CS degree (or any real degree) and being successful as a self-taught software engineer.

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

From my (limited) knowledge, CS as a formal academic discipline largely emerged from the renamed Applied Mathematics departments of universities.

Yes. But cs degrees are not about learning coding. We have coding schools for that. It’s about learning the intersection of computing and math. But having science in the name sounds cooler so people take that instead.

Anyone with a CS degree will be able to tell you there's a huge difference between being a programmer/coder, and being a Computer Scientist.

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.

> I had no trouble understanding object oriented programming

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.

Do you have a tl;dr you would care to share?

Well, my attempt to summarize OOP:

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

because

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.

Frankly and in retrospect, I consider this difficulty a sign of the unsoundness if OOP. While with typed FP you can get entangled into some seriously complex mathematical models, in OOP it’s just a bunch of metaphors and mental models you have to convince yourself are true. The effort poured into memorizing one rarely transfers to unrelated frameworks or different languages, or at least does so to such a high level that it doesn’t help that much anyway.

OOP is easier to use when describing a mental model as-is, without the analytical deconstruction that (typed) FP would demand.

>1+2*3=9

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.

You could certainly see it that way, but I found that it is a good example to illustrate the intention of having a very simple syntax and processing logic (up to the point where arithmetic expressions are not what you expect them to be).

These programming paradigms are really all about impedance match with a model that's already in some human's brain -- going from the brain-space model to code with the least amount of transformation. So if you're struggling to get to the mind-model, something is wrong! It definitely doesn't make sense to begin looking at the implementation details. They're only there to facilitate that simple transformation from thoughts to code.

I dunno I think it might be kinda like quantum mechanics. If you think you understand OOP, then you definitely don't understand OOP.

That's really interesting! Want to do an interview?

I have a degree in New Testament studies. I totally agree. Learning Koine did the most to help me

Well, Paul Graham did write in "Beating The Averages" that programming languages are "half technology, half religion".