Hacker News Reader

Comment by TeeWEE | Hacker News Reader

Language|Framework X vs Language|Framework Y... I'm getting tired of this.

Its the concepts and fundamentals that are important. I bet you that most javascript and ruby developers dont know what an AST is and how a regex can be transformed into a state machine. Not even to mention how lambda calculus influenced lots of languages.

Anyway. Languages come and go. Frameworks come and go. However the problems associated with computer science, like distributed computing, scaling, mobility. They will stay.

The best software engineers are the ones that understand the basics. And most importantly: know how to use them in practice.

A good software engineer will choose a framework language depending on the domain / problem that needs to be solved.

Not because they like it.

View on HN

Observation:

Scaling, mobility, and distributed computing are all problems for the electrical engineers--theoretical computer scientists likely already have the answers.

The bridge between theory and practice is where most of us find work.

EDIT: changed "true computer scientists" to "theoretical computer scientists" and hedged bets slightly.

> true computer scientists already have the answers.

And the answer is .. 42?

No, really. When did the distributed computing issues become "solved" in computer science?

How many of those issues go away with infinite storage, atomic storage operations of arbitrary length, instantaneous computation and communication, completely deterministic executions of operations, completely reliable machines, etc.?

My point was more that the parent posts examples were problems that really are more engineering than theoretical in nature.

Probably sometime between when Erlang was developed and the first MapReduce paper was written. There isn't "One True Way", but there are plenty of solutions.

We don't need to re-invent MapReduce or message passing. There are ready made solutions/frameworks like Hadoop and Storm that are fairly easy to implement. There are also a number of databases that are designed for distributed computing. You don't need to be Google to have a fault-tolerant distributed computing setup. It's really a matter of choosing the appropriate technologies, rather than re-inventing the wheel. Because of that, I'd consider it a "solved" problem, even if a particular implementation might need some thought to match up with appropriate technologies. It's not necessarily trivial, but it's probably as "solved" as it needs to be.

Interesting that you effectively use an engineer's definition of "solved" rather than that of a theoretician.

Message passing is effectively the assembly language of distributed computing: very low level. Mapreduce and the various NoSQL databases are effectively the next level up, but we still have some time to be able to have a proper theory for designing and implementing effective scalable distributed systems.

In short, we have many bits and pieces that can be brought together with a bit of luck to be able to attain the scale that we are currently seem to be happy with. So I can accept that the engineering definition of solved is there. But from a computer science point of view, we certainly are far from having a satisfactory theory. So we definitely do not have the answers.

Computer science != Theoretical computer science.

Fair enough. :)

Reply on news.ycombinator.com