3 ms·

This: "Concepts such as Functor should not be scary. Many engineers in our industry suffer from a kind of dualism where theory and practice are somehow separate

by mihau 10y ago

This: "Concepts such as Functor should not be scary. Many engineers in our industry suffer from a kind of dualism where theory and practice are somehow separate, and formal concepts like Functor, Monad and Applicative (to name a few) are often considered to "not work in practice", and users of such academic vernacular are accused of being ivory tower elitists. Another possible explanation might be that engineers (regardless of their training: formal or otherwise) are simply unaware of the amazing things that have been discovered in computer science to date, and proceed to poorly reinvent the wheel many times over. In fact, I would wager that nearly every hard problem the majority of engineers will encounter in the field has had its generalised case be the subject of at least one study or paper... the tools we need already exist; its our job as good computer scientists to research our own field, and edify ourselves on historical discoveries and make best advantage of the work done by those who went before us."

sotojuan 10y ago
Now you know why programming is not considered engineering. There are plenty of programmers who pride themselves in not caring about "theory" ("I didn't go to school and now I'm making money building cool stuff!!") and thus history is repeated.
- paganel 10y ago
  You don't need much CS theory in order to develop and maintain a CRUD app. I've been a programmer who gets paid to write code for 11 years now, and I'd say most of the code I've seen wasn't that much complicated than a CRUD app. Also, I don't feel the need to be called an engineer. I just write code, hoping that it would work most of the time, under as many diverse circumstances as possible and trying to meet the client's needs. It sounds trivial, there's no "theory" in it, but sometimes is hard as hell to do all these 3 things right.
  - mbrameld 10y ago
    I think this is a case of not knowing what you don't know.
  - eru 10y ago
    Some insights inspired from theory help a lot with writing CRUD apps. (Also of course, inspired from outside and then explored further by `theoreticians'.) The most successful of these are now invisible. Either because they are available libraries or so ingrained in the background of what we are doing. See for example regular expressions, parsers, garbage collection, databases, file systems, CPUs. For CRUD apps, "Out of the tarpit" (http://shaffner.us/cs/papers/tarpit.pdf http://shaffner.us/cs/papers/tarpit.pdf) is an interesting paper that I hope describes how the mainstream programmer will build CRUD apps in perhaps ten years time. (I already used a variant of their techniques in a previous job, and it was rather pleasant.) But yes, in practice knowledge of theory often acts more as a gatekeeper for getting into the likes of Google than you will use it. But when you do spot some opportunities to replace endless workarounds and tedious manual monkey-work with an elegant overarching principle, it often makes all the hours spent studying worth it. As an great practical example: shake (http://shakebuild.com/ http://shakebuild.com/) is a build-system that was born out of our frustrations with Gnu Make at Standard Chartered Bank. Similarly, Bloomberg used to use C++ to describe financial derivative contracts. Those derivative contracts don't fit well into class hierarchies. Switching to an embedded DSL approach embedded in a functional language made the software easier to write and more robust to common errors especially when maintaining.
    - paganel 10y ago
      > See for example regular expressions, parsers, garbage collection, databases, file systems, CPUs. Of course we're all standing on the shoulders of giants. So does the milk-man, who goes door to door using a vehicle of which he doesn't know much about how it was built/what its underlying principles are (is it a Otto-based engine? or a Diesel one? does the milk-man need to know the laws of TD?), but that vehicle is paramount to the milk-man's financial success, so to speak. All I'm saying is that we don't all need to be like Rudolph Diesel, Nikolaus Otto or James Clerk Maxwell, we can still do our jobs as programmers perfectly fine the same as a regular milk-man does, we don't need to know the theory behind CPUs, garbage collection and the like in order to write code that does stuff. Don't get me wrong, I get what you're saying and understand your points, I just think that right at this moment the programming world needs more "milk-man-like programmers", because if we build walls around our profession ("you can only be a programmer if you know CS theory" and the like) then nothing good would come out of it. I mean, we will certainly build some cool, nice programs, but the world right now doesn't needs just some, few "cool, nice programs", the world needs lots and lots of code. In order to have lots and lots of code we need more programmers.
- posterboy 10y ago
  That's not true, technical colleges award bachelors in engineering for applied computer science in economics, media design and, indeed, computer engineering.
- jsmith0295 10y ago
  I don't really think it has much to do with going to school. I think theory gets ignored because some portion of an engineering team has no interest in learning it, so we cater to the lowest common denominator because its the less expensive option, at least in the short term. It's actually the passionate people who managed to get into this without a degree that have been the most interested in new ideas in my experience.

by mihau 10y ago

sotojuan 10y ago

Now you know why programming is not considered engineering. There are plenty of programmers who pride themselves in not caring about "theory" ("I didn't go to school and now I'm making money building cool stuff!!") and thus history is repeated.

paganel 10y ago
You don't need much CS theory in order to develop and maintain a CRUD app. I've been a programmer who gets paid to write code for 11 years now, and I'd say most of the code I've seen wasn't that much complicated than a CRUD app. Also, I don't feel the need to be called an engineer. I just write code, hoping that it would work most of the time, under as many diverse circumstances as possible and trying to meet the client's needs. It sounds trivial, there's no "theory" in it, but sometimes is hard as hell to do all these 3 things right.
- mbrameld 10y ago
  I think this is a case of not knowing what you don't know.
- eru 10y ago
  Some insights inspired from theory help a lot with writing CRUD apps. (Also of course, inspired from outside and then explored further by `theoreticians'.) The most successful of these are now invisible. Either because they are available libraries or so ingrained in the background of what we are doing. See for example regular expressions, parsers, garbage collection, databases, file systems, CPUs. For CRUD apps, "Out of the tarpit" (http://shaffner.us/cs/papers/tarpit.pdf http://shaffner.us/cs/papers/tarpit.pdf) is an interesting paper that I hope describes how the mainstream programmer will build CRUD apps in perhaps ten years time. (I already used a variant of their techniques in a previous job, and it was rather pleasant.) But yes, in practice knowledge of theory often acts more as a gatekeeper for getting into the likes of Google than you will use it. But when you do spot some opportunities to replace endless workarounds and tedious manual monkey-work with an elegant overarching principle, it often makes all the hours spent studying worth it. As an great practical example: shake (http://shakebuild.com/ http://shakebuild.com/) is a build-system that was born out of our frustrations with Gnu Make at Standard Chartered Bank. Similarly, Bloomberg used to use C++ to describe financial derivative contracts. Those derivative contracts don't fit well into class hierarchies. Switching to an embedded DSL approach embedded in a functional language made the software easier to write and more robust to common errors especially when maintaining.
  - paganel 10y ago
    > See for example regular expressions, parsers, garbage collection, databases, file systems, CPUs. Of course we're all standing on the shoulders of giants. So does the milk-man, who goes door to door using a vehicle of which he doesn't know much about how it was built/what its underlying principles are (is it a Otto-based engine? or a Diesel one? does the milk-man need to know the laws of TD?), but that vehicle is paramount to the milk-man's financial success, so to speak. All I'm saying is that we don't all need to be like Rudolph Diesel, Nikolaus Otto or James Clerk Maxwell, we can still do our jobs as programmers perfectly fine the same as a regular milk-man does, we don't need to know the theory behind CPUs, garbage collection and the like in order to write code that does stuff. Don't get me wrong, I get what you're saying and understand your points, I just think that right at this moment the programming world needs more "milk-man-like programmers", because if we build walls around our profession ("you can only be a programmer if you know CS theory" and the like) then nothing good would come out of it. I mean, we will certainly build some cool, nice programs, but the world right now doesn't needs just some, few "cool, nice programs", the world needs lots and lots of code. In order to have lots and lots of code we need more programmers.
posterboy 10y ago
That's not true, technical colleges award bachelors in engineering for applied computer science in economics, media design and, indeed, computer engineering.
jsmith0295 10y ago
I don't really think it has much to do with going to school. I think theory gets ignored because some portion of an engineering team has no interest in learning it, so we cater to the lowest common denominator because its the less expensive option, at least in the short term. It's actually the passionate people who managed to get into this without a degree that have been the most interested in new ideas in my experience.