How to Insult a Computer Scientist
cs.purdue.edu
cs.purdue.edu
"Interesting, I'm from industry and this appears very applicable to some of the work we're doing right now."
Extreme theorists don't hate applications, they just don't especially care if they exist.
I've lost count of the number of times a theorist has told me that result -foo- shouldn't be possible during application :)
Countless times over the years I have seen areas where Academia is decades ahead of us so-called industry experts. What is "new", "shiny", and posted all over the place online today is built of theory produced 20+ years ago. In practice, we have gotten our tasks done without some of this knowledge, but theoretically, we have, over time in our ignorance, cost our employers millions of dollars in hours dedicated to bug-fixing and features that could not meet deadlines. It is a hard pill to swallow. The silver lining is that we can recognize this and work to grow, to learn that missed theory, rather than fall into the trap of complacency.
Today's fad is functional programming. In the coming years, we will relearn the weaknesses of functional programming, why OOP was the next stage of evolution. Hopefully we will have learned not to fall into extremist camps again (the notion of a "functional vs OOP" conflict still strikes me as hilarious misunderstanding).
If I were to put a finger on it, I would say that the reason OOP arose was that there was general recognition of the need for a rich type system. I got a hint of this in the first couple parts of SICP. Haskell incorporates a kind of type system that is, itself, pretty interesting. CLOS/Moose makes C++ and Java feel antiquated.
In my experience, a lot of us who learned OOP via C++, Pascal, Java, Ada, and the like generally missed the point: type systems. We tend to treat classes like collections of the language primitives as opposed to combinations of data structures. Specifically, we make do with primitive data types and neglect to constrain them as a type. And "everything must be an object" is an extremist mantra with little value; given that your process image must have an entry point, purely a code-flow issue, was there really a point to the illusion of wrapping the entrypoint main() function in a class (I am looking at you, Java)?
Here is an OOP type example I see in the wild: an ID that is a string of four characters, a dash, and three digits tends to be stored as a string. This is incorrect; that string is not like other strings, and this is a blind faith that somebody is not going to incorrectly use that string. Wrap that in a type that specifically checks that the ID fits that pattern. It is easy to fall into this kind of mistake in the database management world, too, where an ORM pulls in a VARCHAR2 and does not translate values of this type into an appropriate type in the system, perhaps a type with a restricted domain.
Another example: I have learned to always question if my method really needs to accept an "int". This is a smell. Could my value be negative? What is the real min/max range of the value? Could the value have a magic value, such as "Number Not Given" (or NULL)?
Functional programming helps us with code flow. OOP helps us carefully classify the data.
Far be it for me to defend Java (I hate the damn thing), but: main is just a function in a class. The class is the entry point, as specified in the command line; main is just what the OS looks for, by convention. You could have a "main" in each class, but only the one in the specified class will be the entry point.
I remember a long time ago I was watching an online forum on riddles. One of the 'riddles' was how many cigarettes (read as: finite regular cylinders) can you arrange such that each one is touching each other one. I watched the thread go for three days as various theorists claim a maximum number according to mathematical theorem A or B or C. It started out with a max number of 3 and took three days of impassioned debate to work up to 6, with theories floating in and out of favour - and each one claiming to be 'the absolute ceiling limit'.
I then took a matchbox down the pub and asked the same task of my drunk friends (telling them to ignore the bulbous heads/square cross-section). Within five minutes, all of them, even the utterly non-scientific ones, had found a solution for six. Most of them found it within 1-2 minutes. Drunk, untrained, undiscplined folks that actually physically played with the items beat out impassioned, educated enthusiasts.
It highlighted the issue for me that theory is all well and good, but it's not useful in a vacuum. Theory and practice need each other to be efficient.
Similarly I went back to visit my old university. I saw a guy there 12 years into his PhD... and still clueless about the practicalities of what he was recording. He'd spent his whole career in the theory of it and had no idea of the realities of recording his subject, something that 3-6 months in industry would have given him in spades.
So no, it's not as clear cut as 'theory done cleanly in practice would win', as the real world is grubbier and has more edge cases. Theory and practice need each other for efficiency. Thinking of it another way - you don't need to test your backups... in theory... :)
Incidentally, on the cigarette question, I've seen a solution for 7, but I don't know of any higher. The guy who showed the solution for 7 was also the first one to say 'this is a solution, but there may be a higher ceiling out there'.
For infinitely long cigarettes, it is at most 24: http://library.msri.org/books/Book52/files/07bezd.pdf
Is eight attainable? http://portal.acm.org/citation.cfm?id=1450373
Thanks for the links!
It's a good question, but then, it is also a perfect example of why playing around with the real object is sometimes better than applying a theoretical analysis. The question was about cigarettes, and cigarettes do bend / deform. That means that any analysis will need to take this characteristic into account. The problem is, we don't necessarily know all of the factors that need to be modelled to do a correct analysis, which is why empirical testing is still an important technique for problem solving.
Yup - I'm "that guy" and today I'm a grumpy old man. This item is just noise.
ADDED IN EDIT: And yes, I expected to be downvoted, because anything that smacks of criticism of the community gets downvoted. People don't like to be told that they're doing something wrong, especially people who are so damned sure they're right, or clever, or talented, or hardworking.
Yes, the very nature of an entrepreneur is to follow things through in the face of adversity, but when you're criticised you need to stop and see if there's some truth - to see if there's something you should learn.
Before you downvote this comment, ask yourself why? Does this submission as a whole really add value to the site? If it does, then my criticism doesn't, and rightly should be downvoted.
But if this item adds no real value to the site then my criticism is valid and should at least make you pause before looking for an arrow to click.
And if you do downvote, then a reasoned response would add value. But maybe you really are just looking for cheap entertainment. Replying - adding value to the site - would be, you know, like, work.
Even the really good stuff feels familiar. I wonder if I've just seen all there is to see and everything's looking familiar, in the same way that as you get older, everyone reminds you of someone else.
Maybe it's time to move on. Maybe this is a time to get the sense of the community and use that to help guide my decision. They do say - listen to your users. My contributions here on HN mean that you are, in a sense, my users.
(edited "noise-to-signal" typo).
You're probably being an ass-hat. And I probably like you for it. (It's one of my oldest son's finest qualities.)
This just seems to be a good day for it.
Cheerio.
Sure it's no Silence Dogood essay, but you're way too harsh here.
Honestly??
I think it's a cheap joke with no intellectual value. Some people find it funny, and they will upvote it. I'll happily believe that 50, 100, possibly 1000 people here find it funny to think about how to insult computer scientists.
After you've read it - what have you really learned?
Upvotes do not of themselves mean an item meets the guidelines.
I see people having fun and satisfying their creative curiosity by making and building upon jokes inspired by this link. Links which link intellect and curiosity are quite often posted to HN.
To answer your question on what have I really learned... well that's not a question you want to start asking. I can point out quite a few articles that don't belong upon HN when held against that criteria. Take for example almost everything related to the NYT. I usually don't click on those and just wait for the blog post that explains the same thing with more information and less filler.
As for another argument that you will find quite easy to strike down, this is not somewhere where I go do to market research, it is somewhere where I go to entertain myself and find things, preferably about hacking, that I may read. This link does a brilliant job of being related to hacking while also being entertaining.
> this is ... somewhere where
> I go to entertain myself
This submission does none of those. I don't think it's even especially funny or clever, but I've seen it all before.
Thank you for your reply - it has taught me something. There was a time when I would've upvoted you to show that you added value, but these days votes seem to be used mostly to express agreement or disagreement, so I'm disinclined. But I value your comment - thanks.
I've not come across the "Theorists Favor Sophistication, Experimentalists Favor Simplicity" idiom before, and thinking about those people in my life that exhibit one or the other, I see that there's a kernel of truth there.
Though the article is intended to be humourous, I've added a little bit to my understanding of the human condition by reading it. And I got a smile or two while doing so.
They still, however, have the more applied computer engineering department. I think this post speaks volumes about the attitudes of faculty at Purdue, both in CS and outside. There's a lot of stuff this post doesn't explore because of the format, but I'm glad this showed up. Maybe you're removed from academia, or maybe the academic environment in the UK doesn't have these sorts of issues separating applied and theoretical CS, and even with applications-focused universities killing CS entirely.
In short, this is not fluff, it succinctly illustrates a significant divide in the field.
If you haven't noticed, the site is going to hell in a handbasket. Looking at the front page, we have more quadracopter porn (love it!), three stories along the lines of "guess who's quit/joining X" story, more Color trashing (can we say who cares?), a story that promises to teach me to accomplish anything, and, yet again, "Is C++ dead?"
I say if C++ has jumped the shark, it is only a shark iterator, and the sequence is infinite.
That's not even mentioning the new jokey/snide-remark level in commenting...
Sorry. Didn't mean to horn in on your grumpy old guy glory.
1) When he/she says they are a computer scientist, say "oh so you're like an IT guy? Because I recently got this virus..."
2) Call him a mouse jockey
My response was along the lines of "Actually, when I was in grad school I spent most of my time on theoretical computer science and artificial intelligence." A little obnoxious, sure, but he deserved it.
As a side note, Comer is the type that once he's decided you aren't worth talking to, he will do whatever necessary to ensure conversations with you are short, including applying the contents of this essay in spectacular fashion.
The comments back then were.. different somehow.
Anyone has interesting ideas to create a simplest possible insult that would work for both properties ? (yeah ok, i'm no theorist)
A. In theory, there is no difference.
> I note that the systems aspect of this project seems quite complex. Do you think the cause of the convoluted implementation can be attributed to the more-or-less ``simplistic'' mathematical analysis you used?"
This has to be my favorite one :)
Despite all the equations, it seems to me that your work didn't require any real mathematical sophistication. Did I miss something?
Yes.
----
Isn't this just a straightforward extension of an old result by Hartmanis?
Which one?
----
Am I missing something here? Can you identify any deep mathematical content in this work?
Yes you are. Next question.
----
Wasn't all this done years ago at Xerox PARC?
No, only several of the underlying technologies. Can you identify which?
----
Have you tested this on the chip Intel got running last week in their lab?
No, but I'm sure it will work because I helped design it.
----
Am I missing something? Isn't it obvious that there's a bottleneck in the system that prevents scaling to arbitrary size?
Did you miss that function isDebugOn(){ return false; } is O(1)?
If you want to insult an experimentalist, it's there's a much more cutting one - "Didn't Microsoft do something similar when they were working on CORBA?".
To which you'd get a puzzled look while they condescendingly informed you that Microsoft never worked on CORBA - that was the OMG, and Microsoft had COM/DCOM.
Xerox PARC is good, because they probably did work on whatever is being discussed.
Other options include "Didn't Englebert include that in the Mother of All Demos?" and "Didn't Taligent have that running?"
That's hilarious.
There are some interesting points in that list, some can be used against theorists, others can be used against experimentalists.
(I'm not sure if that article has been ever submitted to HN)
Much good-natured jibing was had after that. :)
A paper on this work would be illuminating if ignited.
Congratulations: You have now once again successfully solved one of the one star exercises in Knuth's TACP.
In this work, is your coauthor a professor, post-doc, Ph.D. student, Master's student, undergraduate, or a visitor from a middle school?
So, your new programming language is Turing Machine equivalent. Okay. Beyond that its main feature is that it 'encourages a programming style' you prefer. Just why is that 'style' more significant than, say, style in the rag trade?
Your work has used some theorems from math but has it added any theorems to math?
My CS professor has published papers that are solutions to exercises in The Art of Computer Programming. It's sort of a fact of life for computer scientists that whatever you're doing has probably already been done by Knuth.
A set of problems in the 20s would be a good chunk of work, each taking about 20-30 minutes. By the time you get to 40's, you're dealing with problems that you could write a paper on. In the introduction, he demands proof of Fermat's Last Theorem as an example for 50.