246 karma · joined October 7, 2011
I have a cron script that runs every hour that pulls in sat images of cloud cover, the earth, and then the daylight lines and composites them together with imagemagick. I got the script from a lifehacker article where they used it for wallpaper.
I can't comment on the dryness of TKaMB though I would say that it does contain enough elements of typical human drama to be more than "a book about racism".
To start with, the story is predicated on the notion that Eugenics works, or as the saying goes; if it's not outright saying it, it's sure implying it loudly. It's reasonable to say that two intelligent people will probably have intelligent kids, but the novel goes way past that. The three children are freakishly (in the novel's terms, this is another one of my gripes I'll get to) intelligent.
It's not something that could be accomplished without an extremely long and large breeding program, if at all. (also note, you'd be producing an awful lot of pretty freaking smart kids, see my next point) It would mostly be a matter of luck and at that point why have a breeding program at all? Therefore the intelligence of the children is strongly implied to be a result of the breeding program.
In terms of artistic objections, the "freakish intelligence" of the children is accomplished by making most of the other characters in the novel cardboard cutouts or strawmen that Ender can just knock over or tear apart easily. What happened to all the other kids from the breeding program? Surely it produced a bunch of "90% Enders" who are almost as good. It comes off as contrived and inauthentic.
The whole "child soldier" angle is ridiculous as well. Child soldiers are used in conflicts because they are easily manipulated and readily available but that is not always desirable. A rebel fighter in Africa only needs someone who can hold and point a machine gun to replace the last guy who was doing it. The needs of the military in Ender's Game are quite a bit more sophisticated.
Children are also ignorant and dumb. Innate intelligence can only take you so far, it gives you a large "gas tank" but you still need to fill it with gas.
Military Strategy is not necessarily a terribly intelligence-taxing thing. It's mostly a question of learning from the past, taking into account current technology, and trying to anticipate other attacks. If they really wanted to win the war they'd put an experienced General in charge of strategy and have Ender start working on the next great super-weapon, that's what makes decisive victories.
The whole "the enemy's gate is down" thing is a good example of how Ender is not smart, everyone else is dumb and also how the book has a flawed view of military strategy. The "the enemy's gate is down" is a lesson we learned hundreds of years ago at the latest (i.e. the transition from neatly lined up soldiers standing in rows across from each-other firring muskets to modern trench and guerrilla warfare). Is this some bizarre future where we've forgotten all the basic lessons of military history for the past thousand years? Or is this just the worst military academy ever?
Going back to Eugenics, the book's plot requires that Ender is so intelligent that it's more efficient/effective to try and train him up to a brilliant strategist than to just use one of the existing ones. I don't find that realistic.
I also don't buy the whole "He's a kid so he'll look at it from a fresh angle" aspect. Sure kids do tend to be a bit open minded but I find it dubious that they would naturally have the right kind of open mindedness for this application, that is an informed one.
I don't care how new the MD Device is, we're to believe that they have no idea how it works? Not even a guess as to what would happen if you fired it at a planet? Come on... nobody said "let's shoot it at an asteroid or something"? When nuclear weapons were developed pretty much right away nuclear scientists stood around like excited schoolgirls with a puppy coming up with all the super neato places they could set off an A-bomb to see what happens (Underwater! Space! "uninhabited" islands!)
Honestly I could go on and on about all the things I dislike about this book. I realize I might seem a bit worked up, but really it just slightly annoys me that such a mediocre book is so popular. It owes it's popularity mostly to the fact that it's a classic underdog story. A lonely nerdy kid who's smarter than everyone around him kicks ass and chews bubblegum, it's a young sci-fi nerd's wet dream. I know when I was in middle school during tough times I would occasionally spend time daydreaming elaborate revenge fantasies where I showed everyone up, so to a kid like that Ender's Game is very validating. That's good in some ways but I also worry that it can be unhealthy because I think while that sort of mentality is natural is something that needs to be overcome and not indulged.
Overall I find parts of it unwholesome and overall offensive aesthetically.
That would be a useful tool in reverse engineering.
How accurate does the source position information have to be? I don't think the CoffeeScript lexer can output column numbers (at least it didn't last time I checked) and the re-writing stage might give them a little trouble. Should be doable though.
Guess I should head over to github and see how they're doing and start reading the SourceMap spec.
It's a pretty simple but extremely useful idea. To use your example, the CoffeeScript compiler knows exactly which bits of generated JavaScript correspond to exactly what bits of CoffeeScript code, so the compiler can output a mapping that says "these lines of JavaScript are the result of this line of CoffeeScript...so when you step through this CoffeeScript line, execute these X lines of JavaScript, if an error occurs in these X lines of JavaScript show there error as occurring on line Y of the CoffeeScript code.
I haven't done much front-end lately so I'm not sure what if any the CoffeeScript compiler has in terms of generating source maps, but if browsers are supporting it I imagine it won't be long if it's not here already.
However, it always amazes me when people in discussions like this take JavaScript as a done deal or a static target...this is a fatal flaw in this discussion.
JavaScript as a language and community has evolved a lot, and it continues to evolve. We've already seen improvements that make it a better target for compilation, and we'll be seeing more in the future...now that it's clear that that is what the web wants/needs and not just a little scripting language for forms.
My bet is it will be much easier/quicker to work JavaScript into a good target for compiling other languages to than to develop a general VM and convince all the browser vendors to adopt it.
That's not even taking into account which would be better overall, which I think is an interesting question without an entirely clear answer....but I'm a pragmatist and so I think it's not worth worrying about except intellectually.
> people are not defecting away from search to use Facebook's search or Bing or whatever.
You are perhaps missing the point a little.
It doesn't matter what people are doing, it's what advertisers are doing. The fact that everyone still uses Google search won't be worth much if advertisers are only interested in putting ads on Facebook.... Google would be running an expensive, but popular, charity.
I don't think the day like that will come, but it is clear that Google's revenue can be threatened from things like Facebook which don't directly compete with their products.
> Placebo is astonishingly powerful
I would agree that placebo is "powerful", in that it can provide surprisingly powerful subjective effects...however it's mechanism is fairly well understood and it's nothing special.
Placebo is not an effective treatment overall, and the places where it is effective are things like say pain... in those cases it works by releasing endogenous pain relievers. Ditto for things like relaxation etc...
> Placebo usually works really well compared to no treatment
Well of course it works "really well" compared to no treatment...
Positive thinking, receiving attention from people around you, etc are all things that can have a positive impact on your health but these are not part and parcel with "the placebo effect".
Even so, I find the claim that "placebo works really well" dubious, and I'd ask you to provide a basis for support if you wish to make it again.
The fact is in the end, the placebo effect is small, unreliable, requires you to lie to your patient....and you could achieve as good or better results with real medicine.
It's just not a good practice...placebos belong in research as a control, and very rarely in certain situations yes it can be useful to dispense them...but not in an effort to "treat" people with the placebo effect.
That is absolutely not the "point" of modern homeopathy... The point of modern homeopathy is to spread a lot of nonsense about water with memory and other such bunk.
Secondly, you seem to have some funny ideas about the placebo effect. Placebos are used to try and measure peripheral factors. It could be that just going outside is what is curing the patient, and not the new drug you are giving them.... Or maybe spraying anything up the nose will help some symptoms, not the new nose spray you are testing. That's the whole point of a placebo...if your medicine is only working as well as the placebo, it's not working at all.
It so happens that additionally, sometimes you can get what is called "the placebo effect" where just the idea of being treated can help somewhat...but generally only in certain cases and for subjective things, like pain. It makes sense that people feel a little better subjectively when they are treated.
However, not all placebos cause the placebo effect and if a placebo helps it is not necessarily because of the placebo effect. Using placebos in the way you suggest is not good medicine, they are not reliable enough and require some dishonesty with the patient, a serious ethical concern. Furthermore, you should be able to get similar or better results from a variety of real treatments!
Outside of research, there may be occasionally a reason for a doctor to dispense a placebo...but overall they are not good medicine and neither is homeopathy.
> Yeah, it has no medicinal effect. But that does not make it worthless,
Actually, yes...that's exactly what it does. That's the whole point. If something only works as well as a placebo, it's literally worthless.
Psychogenic illness is not "faking it"...it is very real. It simply means the cause of the problems are based somewhere in the "software" rather than the "hardware". The brain is an exceptionally complicated thing, and the interactions between parts of it can result in all sorts of feedback loops, errors, etc.
If you really don't think it's perfectly possible and probable for a group of teenage girls to develop a shared psychogenic illness completely spontaneously without any sort of guile or even conscious awareness on their part, then unfortunately you have a very simplified and inaccurate understanding of just how complicated and fuzzy our brains are.
Most people have a very poor conception of just how fuzzy the line between what lay people call "sane" and "crazy", and just how easy it is for your brain to trick you. Consider this: a sizable portion of your memories are false. I don't care who you are, this is simply a fact of being human. Some of your memories are constructions based on friends/family describing the event to you some of them are just complete fabrications. However, if asked you would swear up and down they are real. It's not hard to create false memories in people...show them commercials of a non-existent product and many will remember having used it at some point. They're not liars....they're not fakers...they're not idiots...it's just that the human brain is not as simple as we like to think.
This attitude is extremely harmful because it creates an environment where nobody wants to be told they have a "psychogenic illness"....and we get people claiming that hamburgers/magnetic waves/whatever are causing their strange symptoms...and since that's not the case they won't get effective treatment. Furthermore, these people are now potentially harassed by the ignorant; accused of "faking" it for attention...so we have a whole class of illness that isn't being treated due to this ignorant idea.
You've actually got it backwards. It's "possible" that they are faking it, but this sort of involuntary tic is not easy to fake under medical examination. The most likely scenario is that to whatever extent the girls are "doing it themselves", they are unaware of it. I'm sure the attention they get is a part of the feedback loop causing the behavior, but it's important to realize that that does not mean this is some cynical plot to get attention. That's possible of course, but there's no reason to believe it's the most likely possibility and many to believe it's not.
Systems like we are discussing can and do exist, I just don't see them as a necessary or particularly effective solution...especially when compared with the necessary trade-offs.
Look at AOL, which during it's hey-day was basically this sort of walled garden. You needed a phone #, name, address, payment combination to register. Many chatrooms were patrolled by moderators...there were even investigations and "stings" of trouble-makers. If you got TOS'd too many times you were permanently banned.
However trolling, illegal activity, pornography, etc thrived pretty well regardless. It was easy to evade the bans and there was a steady flow of new trolls.
I think the best solution in terms of respect for privacy and effectiveness is a combination of crowd-sourced moderation and intelligent detection of likely "trolling" and problem posters by software.
In theory that sounds nice, and to a certain extent there are some similar systems in place already...but I just don't see it working that well overall.
We already have a system like this for sex offenders, and it's got some serious issues. In such a system it would either be up to each site to have a public "troll list" or they would have to have some central repository. In the case of the former, anytime you look at a sites list you won't be able to tell which ones are just someone who made an offensive comment or two on a single site and "repeat offenders" who are on many sites lists. You'd have to collate the lists somehow and even then you'd have troubles of differentiating the various "levels", mistaken identity, etc. In the case of a central repository that's a whole 'nother can of worms.
Then there's the question of what constitutes an "identity" for the purposes of being able to post. A name? An address? Those don't seem suitable to me for such purposes, they're too fudge-able and temporary. A State ID# or SSN seem too personal and permanent. If the former are compromised, you can limit the damage somewhat, the latter less so. There's the issue of proliferation. Even if you use addresses, every single time you put your info out there is the increased risk of it being compromised. It's not unreasonable to want to limit the amount of times you expose yourself to the risk of security breaches.
There's the issue of the practical burden it would place on the sites. This isn't so much of an issue since it would be voluntary, but it's something to consider.
I think the ethical issue of whether it's ok to out someone who obviously has enemies on the internet is a tricky one. Again it gets to the issue of what constitutes an "identity" for these purposes. If it's too specific it becomes dangerous to release, or even store...and if it's not specific enough it becomes dangerous due to confusion, or loses it's sting.
There's also the question of whether it will really deter anyone. As much as they like to try and evoke the image of a deliberate prankster, I don't think most trolls really think things out that much. It strikes me as impulsive behavior. So they get hit on one site after an impulsive trolling and just move to another one.
Assuming that it's specific, I think the possibility of some sort of violent retaliation needs to be considered. You could argue one reaps what one sows, but I don't think that's an attitude that belongs in the consideration of organizing a society. We should value protecting everyone over punishing wrongdoers. A balance needs to be struck between removing the cause of harm from society and not discarding anyone.
Overall I wouldn't be surprised if such a system comes into being. Some walled gardens where members are authenticated based on a one way hash of some personally identifiable information, or a cryptographic key-fob or something...and if they cause a ruckus their access will be revoked. However I think such a system would have enough problems that it wouldn't take off except in isolated pockets that highly value having an exclusive discussion among a verified group, and there I think it would be more about that than preventing trolling.
For trolls, I think measures similar to what is mostly used now will continue to be the main defense. The ability to moderate, vote, etc.
(Seriously though there's a lot of conceivable reasons, and while that's one I doubt it's a major one, a lip prevents it. I think the fact that a circle doesn't need to be "lined up" and that they are easier to move, etc are much more important)
It's implicit in all of these that the concept is explained to you. Nobody would ask you to "implement a X" expecting you to know what X was (be it Pascals triangle, fizzbuzz, map, etc) unless X happened to be a fundamental concept in the field you are working in (not the case for any of the examples so far)
> Therefore you would have to write up your own Array.prototype.map and Array.prototype.reduce to make them work. Is that true?
Yes, that's sort of the point here. Javascript has these functions as methods of arrays (in some implementations), but the idea of the test is to write your own. They're both pretty simple, basically a for-loop and some logic.
On another note I have a hard time believing you work in JavaScript on a day to day basis and are not working with arrays. If you use jQuery or a similar library, you are working with arrays all the time and also using map-like functionality even if you don't know it by that name.
$(".foo").click(function(){})
Takes an array of elements and maps over them.
For this sort of test, all that is necessary is that you understand the basic idea of a for-loop...the basic idea of how to format a string...remember there's a good chance you're writing in pseudo-code.
Presumably however if you are a programmer, there is at least one language where you should be able to complete this task without looking anything up. It requires only the simplest of language constructs/library functions.
The exception of course is if this is a job for say, a Python programmer...and on your resume you say you are a "Python expert". The fact that you have to look up the syntax for basic constructs in Python would suggest you were lying on your resume. That's one of the things this exercise tests for.
If you said in your resume "I have experience with other languages, but I can learn Python"...then just being able to do this exercise in pseudo-code or any language of your choice would show you have basic programming skills and should be able to pick up Python.
If you really have to remind yourself what a for-loop is then yes, maybe you do have to go back to school/hit the books and study harder.
That's not the goal of the exercise however, nor is it a desirable one. The point is to a very loose test of basic ability. You can test the basic ability of a runner by asking them to do a quick sprint; the fact that this is not an accurate simulation of a race is irrelevant.
> do you think that they will be comfortable making those small errors in front of peopl
They should be. Any programmer should be comfortable making errors and owning up to them.
> Do you think that they jump into problems and that small errors are OK to them In this situation it is. In a "real world" situation, those would be caught by the compiler or unit tests. Of course really bad mistakes in this test would count against you.
> They may blank, they may freeze
Of course, this can happen in any type of interview. The point of interviews is to try and get the best balance of weeding out unsuitable people and finding the best ones. No matter what process you use, you will occasionally discard perfectly viable candidates...however this is preferable to accepting unsuitable ones.
> just be the type of person that reflects on an issue for a while before the set out to code.
...and that's fine...I'm not sure why you think this is some sort of "gotcha" test. It's perfectly fine to take some time...nobody is timing you. Again, this is a basic test to make sure you have the simplest skills and to get a little insight into your thinking/working. If you are uncomfortable with some aspect of the test, it is fine to say "well usually I take some time to think" or "I don't like writing on whiteboards"...etc.
You seem to be fundamentally misunderstanding the nature and point of the exercise. Errors are ok and expected because it's a simple test of reasoning and logic ability...likewise jumping in is ok because it's a simple problem.
Do you as a programmer spend a lot of time considering a simple if/else statement? Of course not...you jump in and write it. Again, we are talking about a simple algorithm here...given the description it basically writes itself for anyone with a modicum or programming experience.
The point here is to get a basic assessment of raw ability. The rest of the interview is to determine how well they might fit in the company, and any other gaps can be filled in with training.
> I personally would search for the mathematical formula and a text description that I could put on my second monitor as reference
That's the point you're missing. You don't need to search for that, it's been given to you. The description of the triangle contains the algorithm for constructing it. It's also so simple that you should be able to hold it in memory for the short time necessary, but if needed you could ask for a refresher.
> But first I would search for a standard library and avoid the effort all together.
That would negate the purpose of the test. Again, this is the most basic of basic programming tasks. It tests your ability to write simple logic and flow controls...something fundamental to writing computer programs.
Even if you solve a problem using mostly library functions, you still will need a few simple loops and logic to tie them together, and that's what this is testing.
> I personally never work from verbal descriptions
The verbal here is incidental...the point is you're working form some description or set of requirements. In this instance it's so simple that a verbal description will suffice, perhaps with one or two reminders. If you really can't hold such a simple description in your mind for 20 minutes I'd say you're not suited for any sort of mental work and might need to see a neurologist.
It seems your objections are based on a flawed premise, a fundamental misunderstanding of what the test is, how simple and easy it is, and what it is supposed to be testing.
If you look at want ads for day labor and other physical tasks it will often say something like "must be able to lift 50 lbs". When you went to the job site, they might ask you to lift a bag of concrete weighing 50 pounds. This is an exceedingly simple task and anyone fit for the job will be able to do it easily. It will quickly weed out anyone who is simply unfit for the work required, anyone who is fit will be able to do it easily.
None of those things are necessary to solve the problem. There's no need to search for information...all the information you need is contained in the problem. It's an exceedingly simple algorithm, and if you can't take the verbal explanation and translate it into code, you are simply not a programmer.
What would you search for, how to make a for-loop? If you don't know such basics as flow control and basic logic, you probably need to go back to school. If you can't remember the usage of printf then you either picked the wrong language, or ask for help, or simple explain you'll fudge it a little and a good interviewer wouldn't penalize you. I'd note if you are interviewing for a language-specific position and said you are fluent in it, not knowing such a basic API might count against you though...
I think the important thing you are missing is that generally in "whiteboard" type situations, you are not expected to produce a completely correct/compilable program. Generally pseudo-code or whatever language you please is accepted and if you make some small syntax or logic error it's not a big deal. In light of that, a compiler/IDE/computer is not necessary unless you have some other reason to require them...such as a disability.
The important part is to see how one reasons through the process of taking a described algorithm and translating it into code...that is the essence of programming. If you can't do it, you are ipso facto not a programmer.
Your analogy is false...in your example the person is not being tested on the actual job they are expected to perform. Obviously that's not a good test.
In this case the programmer is being tested on precisely what their day to day job is: taking a verbal description of a process and translating it into code....so an accurate analogy would be to ask an architect to sketch a simple truss structure and discuss it, which is not unreasonable.
The entire point here is to give a drop dead simple problem to weed out the people who are fundamentally unfit for the position.
Pascal's triangle is simple a triangle which starts at 1 and where each number in the next row is the sum of the two numbers above it, with 0 being assumed for numbers on the edge.
A program to produce one is nothing more than a couple for-loops, printf, and some basic logic.
Pascal's Triangle is not some obscure and difficult mathematical formula you are expected to have memorized...This is not "construct Pascals Triangle and if you don't know what that is, too bad..."
It's a very simple concept and doesn't require the knowledge of anything other than simple arithmetic; any competent programmer should be able to write a program to construct one once the concept is explained to them...it's just a couple of for loops, some printfs, and straightforward logic.
That's the whole point the poster was making...really simple programming problems like fizzbuzz etc are useful at quickly weeding out people who lack very basic programming ability.
Constructing Pascals Triangle is obviously not a part of normal programming, but the ability to take an algorithm that has been described to you verbally and translate it into code is at the heart of all programming...that's what programming is basically.
If you can't do it, you are ipso facto not a real programmer.
Should Kotkin be penalized for his friends behaviour? Probably not, but he should be more careful about hiring buds in the future.
This strikes me as a rather poor excuse (if it's intended as such). I agree nobody should expect an opinion piece to be vigorously researched, cited, etc....but all opinions are not equal. There's a difference between someone who is just casually writing their thoughts with the understanding that they are not fully vetting them...and someone who is clearly biased and pushing a particular agenda.
> Wait, they didn't seize his computers because of one particular comment left on his blog by someone unknown?
Well, we can't know all their reasons...but based on the facts so far...no they didn't. They seized them because he referred to a possible hacker as "our old friend" and wrote an article/linked to the hacked emails....AND because a potential hacker commented on his blog, possibly leaving evidence in his account/on the server...then refused to cooperate with the investigation.
Are they justified doing so? I don't know. I think the "old friend" comment is innocent. I also think based on what we know it's pretty frivolous. Unless they have some clear evidence linking this guy, I think they are overstepping their bounds. Of course they might have it...they're not gonna say.
One thing I would also say is that I don't think this guy is being treated any differently than anyone else who gets in the way of any government investigation (that is to say, poorly).... I hope climate change denialists don't hold this up as some sort of proof of their conspiracy theories.
Precisely what I intend to do. Everyone makes little logic errors and whatnot, I was just trying to use this as an opportunity to show that people who are, while not necessarily new, but not super experienced...will have a harder time spotting stuff like this in the language.
This is understandably frustrating, so sometimes it colors some of their opinion.
At the point you do
plate.dirty
In CoffeeScript the construct for foo of bar
Iterates through the KEYS of bar in turn, assigning them to foo...NOT the values
To be more specific, it iterates through PROPERTY NAMES.
Per the JS spec, property names are always strings (you can't use objects...but you know this I'm just being thorough.)
In your example, you do
plate.dirty
You want dishes[plate].dirty
To be absolutely clear, I'm don't want to make this out to be anything other than the sort of stupid error all of us make all the time. I'm simply pointing out that I recognize it much quicker because I have a very intuitive understanding of CS at this point. Where you, who are very good at (and used to) JS have a harder time seeing the error.
Likewise, I'm sure that you're aware of the dangers of for-in, I'm simply pointing out that it does no sanity checks so watch out.
Also to be clear, I'm talking about your example as written in the article. Maybe you have some other version that works. Go back to my other comment, I compiled your CS code with the CS compiler. You'll see the error there. If you like I'll make a JSFiddle that demonstrates the problem.
I think you've getting stuck on the fact that in my original criticism I didn't know if dishes was an Array or an Object because it wasn't clear from your code...to be clear it is wrong both ways...so I simply said "it's wrong, something must be changed" apologies if this was ambiguous. Now that you've clarified, it's still wrong...just a particular kind.
> Like I said in the article, I _feel_ the relationship when I see `!==`, I don't feel it when I read `isnt`.
Sure, I think that's fair. The point that I'm trying to make is that I think this is subjective based on your own personal background/brain/whatever other nebulous factors.
In your article it could be taken to sound like you are making a case that there is some neurological reason that "!==" is more readable, and I'm not prepared to accept that without some more substantial evidence.
I think I get where you're going, you're just trying to draw comparisons...I just want to add that those comparisons are somewhat nebulous and should not be taken absolutely.
> Welcome to my article.
I didn't get a chance to expand on that point because of space limits. What I mostly mean there is once you're in someone elses code, as far as I'm concerned it's basically all bets are off anyway. At this point when debugging other-code it's often JS, so the point is moot anyway. However, even when it's CS I don't find debugging the JS directly very difficult because it's clear enough for that purpose. Usually it's some issue like a value is not being coerced properly, or arguments being passed in the wrong order, and those are pretty easy for me to nail down with a debugger even if the source is a mess of compiled JavScript...then it's easy to fix it.
Re: debugging, I think we are on the same page. We have different styles. Yours is somewhat crippled by CoffeeScript. It may get better in the future, it may not. I just wanted to say I feel no such impediment.
> it's not hand-waving
My main objection is your examples. Like I said they could be construed as making a more scientific-objective case, rather than a more philosophical subjective one.
The comprehension in your article is not valid, you need to change one thing or the other for it to work.
> Dishes is an object of key value pairs
Yes, and you are getting the KEYS, not the VALUES. I doubt I need to say this, but per the spec KEYS are ipso facto strings.
At the point you do
plate.dirty
See, here is the compiled code fresh from the compiler (with added comments):
var plate;
if (meal.status === 'done') {
for (plate in dishes) {
// plate is a STRING, plate.dirty will not exist
// you want dishes[plate].dirty
if (plate.dirty) wash(plate, brush, sink);
}
}
You'll also note there are no sanity checks, so use with caution.
This is precisely what I mean when I talk about not knowing CS well enough. I mean this with all due respect and do not intend to dismiss you. You are clearly very bright and a good coder. Anyone will get tripped up in any language at first.
The point is I've used CS so much I breathe this stuff...I knew instantly that it was an invalid construct.... I'm simply saying (like any language) once you learn it well enough a lot of these sorts of issues fade into the background.
Maybe you don't think it's worth the effort to get to this point, and that would be fair enough. I just think it needs saying that some of the points you raise are related to being relatively new to CS.
I find the proposition that porting a library (no matter the size) gives you "as much experience as anyone" pretty dubious. It's clear the author has some experience with CS, and I wouldn't discard out of hand the input of someone who had only used it for 5 minutes...but I found that particular statement a bit dismissive of people who have been using CS for a long time on a lot of different projects. Too often people confuse the "getting comfortable, I basically know whats going on here" phase of learning a language with "knowing" that language...which is really more "I understand this on an intuitive level".
I found the "We Process Images and Symbols Faster than Words" section extremely dubious and strikes me as very hand-wavy. I see what the author is going for, but it's a completely false analogy and their point is flawed to begin with.
They're trying to compare the acquisition and understanding of new concepts vs the recognition of an already known pattern, entirely different things.
Also, the author is essentially cheating, because they are talking about conveying inherently visual information using pictures. Showing someone a picture of a circle and saying "this is a circle" does not convey what a circle is, it conveys what a circle looks like (or perhaps, it does explain what a circle is, but only visually) which is to be sure useful for some purposes. However, it gives them no inherent understanding of how to properly construct a circle, or what it's relation is to other shapes (such as a line) geometrically (say compared to a triangle which could be called any three non-collinear points).
With the baby picture, again...I see what they are going for but I think it just doesn't actually support what they are trying to assert. Evoking an emotional response is not the same as passing knowledge, and it doesn't strike me as a good objective to have when writing code. Sure, show someone a picture of a baby and they will have an emotional response. However, they will have no idea who the baby is or why you are showing them the picture which would probably be more useful.
All of this does very little to support their assertion that "&&" is somehow more of a symbol and is more visually rich than "and", something I find dubious even disregarding the poor examples. Letters are symbols themselves and "&&" is just as much a "word" as any other, though admittedly more visually distinctive. With syntax highlighting, I would say that there is no objective difference between "&&" and "and".
"That is verbally readable code, but it’s not very comprehensible"
I'd say that less the fault of CS, and more the fault of the fact that the algorithm they are expressing in it doesn't make any sense:
wash plate, brush, sink for plate of dishes when plate.dirty if meal.status is 'done'
Fine, probably an honest mistake. Sure, I just felt the need to point it out, though I think it does potentially suggest that the author is not yet at the "intuitive" level of knowing CS. You are going to have problems like this in any language where you do not yet fully know it, JavaScript included.
Even excepting that, the algorithm doesn't makes sense. You're cleaning your sink and brush after washing each plate? Doesn't make much sense. I suggest a more realistic version:
if meal.status is done
wash plate for plate in dishes when plate.dirty
wash brush, sink
You don't need to know immediately that you are dealing with the dishes array... The code is composed of discrete "pieces" and each depends on the others. I think it's arbitrary to say "oh I need to know I'm iterating through dishes first thing". It's just as useful to say "ok, I'm going to be washing something, a plate...". That provides a context for everything else. The fact that it's a comprehension is pretty obvious immediately so it's just a case of deconstructing it.
So overall I find this a bit of a straw man. It doesn't make sense to begin with, it doesn't need to be so packed, and it's taken out of context which dramatically cuts back readability. If you were writing an app about doing things in the kitchen, the comprehension (even the dense version) would make quite a bit of sense because the context would make certain things more obvious. In my code, this section would probably be prefaced with a comment like:
# cleanup
wash dishes
wipe counter
stow utensils
Now really, I see what the author is going for. List comprehensions get messy fast. Sure, I just don't see this as a criticism of CS per se and I find the example poor.
Remember, just because CS offers extreme conciseness doesn't necessarily mean you have to use it. I'll admit CS users often make a big deal about conciseness, and that can send mixed messages...but I would say in most cases it's about demonstrating that power is there if you need it than saying this is always best practice. The author clearly understand this as they go on to provide more readable examples, but it bears repeating.
I could similarly break down the "one liner", but I'm running pretty long already and don't have forever. Again, what is probably a misuse of "of", and sticking more than is needed in the comprehension. I get the idea that the point is you can do this, but every language has powerful features with which to shoot yourself in your foot.
If the author actually found that in their company's code, I most respectfully suggest perhaps they don't know CS well enough or it may not be their style. At any rate, it would explain their distaste for CS.
"It’s hard to recognize instantly that I’m actually calling $.ajax"
I suppose, but CS uses juxtaposition to call functions, if you see identifier\wvalue or identifier\widentifier...it's a function call. I would say, remember CS's golden rule: when in doubt disambiguate. Feel free to add () to function calls.
I think the next point the author makes it better. I would say that it's just an unfortunate fact that in many languages some constructs will be ambiguous. I think CS does a good job of pushing ambiguity to edge/rare cases.
In the author's particular example I would note the point is a bit moot because CS has implicit return:
getUser = (id) ->
url = "users/#{id}"
dfd = $.ajax
url: url
format: 'json'
method: 'post'
# return
url: url
promise: dfd.promise()
"Now with the fat-arrow, people are encouraged to fat-arrow their way to oblivion"
I find this a dubious assertion. Stupid people maybe, but I doubt very much giving stupid people JavaScript will give you overall less problems...just different ones. At any rate, I don't see any problem with saying a tool should be reserved for experienced users.
"Therefore it will never really be supported natively, and will always be a compile-to-JS language, and will therefore always have a terrible debugging experience."
I disagree. The browsers are working on features to make such debugging much easier. Further, I know a few people working on CS in CS interpreters, so that if you need a richer debugging experience you could run your scripts through the interpreter rather than as JS. Granted it will probably never be as rich as the Developer tools in the browser, but between the two I would say it's enough.
The author noted they feel the need to throw in a lot of logging in to debug. I would say this is a style a lot of CS developers I know use, myself included. I am quite adept with the developer tools, having debugged JS since the Venkman and Visual Studio days, but I just don't feel the need for that sort of debugging very often. For me, it's either a syntax error or a problem with the flow of data through my program. The only time I really break out the debugger is debugging other people's code.
Editor macros make inserting logs dead simple. A good build process removes them except when needed. I can appreciate that some people will find this workflow annoying and a pain, which is fair. I just want to note I find it works superior for me.
So this is getting long. Despite my objections, I like this article. CS is not perfect by any stretch, and it's still relatively new. It needs work. It needs criticism from the trenches. I think most of the stuff in this article is mostly fair.
However, I find that CS suits a particular group of developers...and for them it is a very useful tool. I think that a lot of people criticize it without realizing that really they don't fit into that group.
When combined with other biases, this is why polls routinely show many people still believe some story that was reported even after it has been widely discredited.