Theoretical Computer Science – An Introduction [pdf](www-cc.cs.uni-saarland.de)
www-cc.cs.uni-saarland.de
Theoretical Computer Science – An Introduction [pdf]
http://www-cc.cs.uni-saarland.de/media/lectures/W1415/L-Grundz%C3%BCgederTheoretischenInformatik/ti_FfSJlCM.pdf
18 comments
> And I can actually not remember a single time when this was actually useful [..]
This tells a lot about what is wrong with software development and why industry is constantly plagued with security issues, misbehaving systems, buggy behaviour on edge-cases, etc.
There was a thread on HN some time ago about software engineering, and I remember mentioning that if "software engineering" was really to be taken seriously, we'd be using theorem proving to guarantee software is correct.
The best analogy is the bricklayer vs structural engineer: you can build something simple very quickly without really putting too much thought about soundness, but once you go past a few floors the risks are too big to be ignored - which is why we have the latter.
It usually boils down to cost - some people like to spread the idea that formal methods are sorcery or are limited in scope, specially people outside of computer science that have no strong background on mathematical methods, which sometimes do a disservice to the efforts of researchers and the ones that had exposure to the theoretical foundations of CS.
In any case, I don't want to go on a huge rant here - so if you don't know, it doesn't hurt to spend some time reading about modern tools and applications for this, maybe even playing with available tools, and.. who knows, maybe learn something new.
This tells a lot about what is wrong with software development and why industry is constantly plagued with security issues, misbehaving systems, buggy behaviour on edge-cases, etc.
There was a thread on HN some time ago about software engineering, and I remember mentioning that if "software engineering" was really to be taken seriously, we'd be using theorem proving to guarantee software is correct.
The best analogy is the bricklayer vs structural engineer: you can build something simple very quickly without really putting too much thought about soundness, but once you go past a few floors the risks are too big to be ignored - which is why we have the latter.
It usually boils down to cost - some people like to spread the idea that formal methods are sorcery or are limited in scope, specially people outside of computer science that have no strong background on mathematical methods, which sometimes do a disservice to the efforts of researchers and the ones that had exposure to the theoretical foundations of CS.
In any case, I don't want to go on a huge rant here - so if you don't know, it doesn't hurt to spend some time reading about modern tools and applications for this, maybe even playing with available tools, and.. who knows, maybe learn something new.
I think a better analogy would be
modern languages : software development (applications)
linguistics : theoretical computer science (theory)
Latin : Turing machines (classic models)
If all you are interested in is applications, you can mostly ignore the theory, but sometimes theoretical considerations help you think more abstractly about your application to gain more insights.
The classic models are mostly only relevant to theorists who can use them as objects of study, if they so choose.
modern languages : software development (applications)
linguistics : theoretical computer science (theory)
Latin : Turing machines (classic models)
If all you are interested in is applications, you can mostly ignore the theory, but sometimes theoretical considerations help you think more abstractly about your application to gain more insights.
The classic models are mostly only relevant to theorists who can use them as objects of study, if they so choose.
I think it's closer to think of it in terms of
Software Engineering = Mechanical Engineering
Computer Science = Science/Physics
A lot of the mess we have in software development comes from thinking that you can build massive bridges without understanding of physics. Or by imitating other massive bridges without understanding why they are the way they are. Yes, you will work 99% of the time on other things that physics, like building materials and design and use cases, but it can get really really nasty without the foundation.
Software Engineering = Mechanical Engineering
Computer Science = Science/Physics
A lot of the mess we have in software development comes from thinking that you can build massive bridges without understanding of physics. Or by imitating other massive bridges without understanding why they are the way they are. Yes, you will work 99% of the time on other things that physics, like building materials and design and use cases, but it can get really really nasty without the foundation.
I disagree. I think many of the problems in software development as practiced today originate from thinking that the theory is all that is necessary.
To take your analogy, my view is that in practice it is considered that we should hire physicists or mathematicians to design and engineer bridges. "Engineering" is almost sneered at as being somehow inferior or a trivially learned skill.
To take your analogy, my view is that in practice it is considered that we should hire physicists or mathematicians to design and engineer bridges. "Engineering" is almost sneered at as being somehow inferior or a trivially learned skill.
The mechanical engineers I know did have to learn quite a lot of physics. That doesn't mean a physicist could easily do their job, because they'd lack the domain experience and wouldn't know the best practices. But on the other hand, you also shouldn't hire someone who has no grasp of the underlying physics to do some novel design where rules of thumb don't cut it.
To transport the analogy back into software engineering: Someone who has only done theoretical computer science is probably not going to write the best code right off the bat. But you also shouldn't put someone who has no grasp of the underlying theory to work on scalable, fault-tolerant distributed systems, constraint solvers, or any number of other problems that had a lot of theoretical consideration put into them before someone came up with the current best algorithms.
Just like mechanical engineers need to know some physics, software engineers should know enough theory to have an idea of where to look for a solution to their problem.
To transport the analogy back into software engineering: Someone who has only done theoretical computer science is probably not going to write the best code right off the bat. But you also shouldn't put someone who has no grasp of the underlying theory to work on scalable, fault-tolerant distributed systems, constraint solvers, or any number of other problems that had a lot of theoretical consideration put into them before someone came up with the current best algorithms.
Just like mechanical engineers need to know some physics, software engineers should know enough theory to have an idea of where to look for a solution to their problem.
> I disagree. I think many of the problems in software development as practiced today originate from thinking that the theory is all that is necessary.
This is such horseshit. Computer Science gives you the intuition needed to guide you to making more correct decisions you make in building your software rather than wrong. When you have these practitioners hitting the scene all of a sudden who just simply learn xyz latest framework/tool/fad and then are faced with a new and interesting complex challenge (for example, computers all of a sudden now have multiple cores! surprise!), they do not have the background to adapt and spend much time cutting their teeth, creating many bugs in their wake.
If you think that having the theory makes you write worse software, I feel bad for you because your computer science education must have been shit and you probably wasted your money. In that sense I understand the bitterness that a lot of people have.
This is such horseshit. Computer Science gives you the intuition needed to guide you to making more correct decisions you make in building your software rather than wrong. When you have these practitioners hitting the scene all of a sudden who just simply learn xyz latest framework/tool/fad and then are faced with a new and interesting complex challenge (for example, computers all of a sudden now have multiple cores! surprise!), they do not have the background to adapt and spend much time cutting their teeth, creating many bugs in their wake.
If you think that having the theory makes you write worse software, I feel bad for you because your computer science education must have been shit and you probably wasted your money. In that sense I understand the bitterness that a lot of people have.
I write "engineering is more than theory" and you conclude "he means theory is useless."
Here's my view, as a person who has formal education in engineering, physics, and mathematics: there are an awful lot of CS grads looking for nails to apply their textbook theory hammers to without understanding that simply knowing theory is not enough. I think you need to reconsider why the bitterness exists.
Here's my view, as a person who has formal education in engineering, physics, and mathematics: there are an awful lot of CS grads looking for nails to apply their textbook theory hammers to without understanding that simply knowing theory is not enough. I think you need to reconsider why the bitterness exists.
They: you will work 99% of the time on other things [...] but it can get really really nasty without the foundation.
You: I disagree.
Do you see how someone could make the mistake of thinking you meant "theory is useless"?
FWIW, I agree with you both.
You: I disagree.
Do you see how someone could make the mistake of thinking you meant "theory is useless"?
FWIW, I agree with you both.
I wasn't clear: I was referring specifically to the analogy drawn between engineering/physics and this industry. The analogy is an ideal that I don't think reflects the practice. In practice this industry focuses on theory, and sometimes quite intricate theory, as the absolute most important knowledge to have almost to the exclusion of other things.
The bitter and vitriolic comment I responded to is a reflection of this.
The bitter and vitriolic comment I responded to is a reflection of this.
Common dude, tell us how you really feel. I don't disagree with you but I think your response could be less aggressive.
Maybe I was unclear about what I mean with "most of". I meant that in a qualitative way.
I would say that the "99% of the time" implies that the quantity of issues comes from engineering problems of all kinds, and I would agree with you that many educational systems tend to forget to teach people simple craft while focusing on theory.
On the other hand, I would say the 1% is more damaging in nature. That's why I said 'a lot of', because these things will really hurt in the long term, rather than the ton of small bugs that are caused by bad engineering.
I would say that the "99% of the time" implies that the quantity of issues comes from engineering problems of all kinds, and I would agree with you that many educational systems tend to forget to teach people simple craft while focusing on theory.
On the other hand, I would say the 1% is more damaging in nature. That's why I said 'a lot of', because these things will really hurt in the long term, rather than the ton of small bugs that are caused by bad engineering.
Can't get the document to load. The webserver is probably down due to HN's hug of death.
Anyone has a copy mirrored somewhere ?
Anyone has a copy mirrored somewhere ?
archive.org has a copy: https://web.archive.org/web/20170707011101/http://www-cc.cs....
I downloaded it but I'm currently on mobile. I'll link to it when I get back to my desktop in an hour.
[deleted]
This document stretches a little over 200 pages and it would be helpful if it included a table of contents so we can get a feel for what it's all about.
it's a theory of computation/formal languages textbook. thw canonical reference is sipser's intro to theory of computation but i like hopcroft, ullman's intro automata, languages, computation much more.
It's the computer science analog to latin for modern day languages... Perhaps less than.