Juliet: "Yea, noise? then I'll be brief. O happy dagger! This is thy sheath; there rust, and let me die."
[fade to black]
Priest called emergency services to transport teenagers to Great National Hospital. Doctors sewed wounds, attached blood bag, and administered antitoxin. Teenagers enrolled at Great Social Camp, where they learned to love country. The End.
Hm, yes and no, but mostly no.
Here's one grain of truth for this line-of-thought - e.g. in the past, the Facebook/HHVM/Hack folks talked about how PHP 5.x was difficult to parse because it didn't have a good *spec*, and so there would be some wonky/ill-considered edge-cases in the spec (such as it was). If you don't have a good spec, then the only way to address ambiguities is to poke and prod at the canonical implementation.
It is also true that the `php` runtime gives some parsing functionality like `token_get_all()` - and if you don't want to write or maintain a lexer/parser, then you can re-use the one built-in.
But those aren't computational properties of PHP as a language. They're two sides of the universal "re-write/re-use" trade-off: if you re-write, then you need a good spec. If you re-use, then you need a copy of the thing you're re-using.
However... I think this thread is advancing a stricter argument that *dynamism* prevents parsing. But pretty much every dynamic language is parseable to some degree - even bash and Javascript and LISP. The real question is, "How much useful/actionable information do you get out of the parse-tree?" PHP certainly has abilities like "require $file" or "eval($code)" or "if (...) { class Foo... }" which will frustrate the effort to get useful information. Then again, C/C++ have macros and dynamic linkers; Java has classloaders and reflection APIs; and I can't even count the number of languages with "eval". Dynamism has a role in most ecosystems, and dynamism always creates a blindspot for the tooling.
But... you can still parse all the non-dynamic stuff meaningfully. If the downstream folks are moderately disciplined, and if the IDE/tooling is moderately attentive, then you still get a lot of utility.
Example: in PHP, it's *possible* for a codebase to have 3 files with 3 competing definitions of the same class - with different variants dynamically-loaded based on configuration/environment/input. That's not common, but it can happen, and it is non-determinism from a compiler/metaprogramming/IDE/tooling perspective. Now, an IDE like PhpStorm offers drill-down (click a symbol to open the underlying code). How can it open the right file if there are 3 candidates? Easy work-around: *count* the candidates. If there's only one candidate file (normal case), drill-down on that. If there's 2+, then ask the user which one he wants to see.
I suspect that most HTTP client implementations bundled with languages aim to be stateless by default. For anything that looks like state, the buck gets passed downstream. There is merit in this -- it gives the downstream developer a lot of flexibility. But then we have the problem: several standard HTTP behaviors that we usually take for granted are unworkable by default (i.e. HTTP cookies, HTTP caching, and CRL/OCSP -- which needs caching to perform reasonably).
Typically, a developer wants to say something simple (http.get("http://example.com/the/data")) rather than
cookieStore = new FileCookieStore("/var/lib/my-app-dir-that-someone-has-to-configure/cookies");
cacheStore = new FileCacheStore("/var/lib/my-app-dir-that-someone-has-to-configure/cache");
certValidator = new CachingCertificateValidator(cacheStore, {crl => true, ocsp => true});
httpClient = new HttpClient(cookieStore, cacheStore, certValidator);
httpClient.get('http://example.com/the/data');
Who wants to be responsible for administering/documenting/supporting all those fiddly bits of state?
eco-comunism
The word itself is priceless.
Honestly, those are terrible books. If nothing else the signal-to-noise ratio is extremely disproportionate. I mean there are nuggets of good information in the books, but a 1100+ page language tutorial is unnecessary. It would be a stretch to call the series programming books -- let alone "influential" programming books.
Speaking from my experience with the Deitels' C++ book in my first-year programming course, I'll agree that the book perhaps lacked some academic artfulness, that it might not help an already-skilled practitioner, and that I wouldn't read it again. But I loved it at the time -- it was fun to read, it had a sort of progression or flow that was easy but rewarding. More importantly, all those lengthy code snippets help the reader become *conversant* in the language. It's one thing to learn the grammar and basic vocabulary of a new language (which you can do quickly); it's another thing to read a novel, write a poem, watch a movie, or chat up a stranger in a new language.
Ah, but this is Slashdot. Nothing goes without being said.
For example, cheese-whiz.
I was wondering about that -- how much did the office of the minority whip spend to put together this program?
Well, it turns out that the House publishes their expenses every three months at http://disbursements.house.gov/ . "YouCut" doesn't appear to be explicitly budgeted. (Congress could learn a lesson from the NSF about transparency -- the NSF publishes expenditures for particular projects.)
So that leaves us to do some sleuthing and guesswork. Here are some puzzle-pieces that I found with about 10 minutes of searching:
If the above facts are indicative of the project and its decision-making, then the project operates on a low-budget basis. Kudos for that.
Of course, "low budget" isn't good enough -- we need to get a return on investment. So what do we get? If the project produces an actively-engaged public which critically and broadly considers the costs and benefits of the national budget, then that would be a good return. If the project elevates the national discourse, then that would be a good return.
But I don't think we'll get that return. Look at the format of the site: each week, a Republican operative edits a list of 3-5 items that he thinks should be cut. This list includes options like "Prohibit Hiring New IRS Agents to Enforce Health Care Law" or "Terminate Taxpayer Funding of National Public Radio." Next, the list is published, and "the public" is asked to vote among these biased options. A week later, the tallies come in and -- surprise! -- the winning option is a Republican talking-point!
So what return will the public get on its investment in YouCut? Well, I guess we'll have some fodder to toss into the Republican machine, and that might help the Republican machine manufacture more outrage.
To recap, the public is investing an unknown (but relatively small) amount in the YouCut program to manufacture Republican outrage. Is that a good investment?
Or, a comment next to a loop would state:
"You spin me right round, baby right round like a record, baby Right round round round"
That's not weird, this guy is just an idiot who can't be bothered commenting his code.
I'm fine with the occasional clever witty comment (I've done it myself) as long as the code makes sense and that everything is documented (e.g. This method does x, y, z and also takes over the world).
I agree with your reaction to the article on "earthweb" -- it's a thin argument. Like you, I also thought about occasional, odd comments that I've put in code, and I tried to judge the listed examples. Of course, there's not enough information to reach my own judgement, so I emoted and projected a little... and now I give this unnamed, undefended developer the benefit of the doubt. He's my comrade in arms and spirit. Surely "Right Round" makes sense in context. Perhaps he was commenting a spinlock in a multithreaded media player with visual animations. The visual animations kept drawing tiedyed ellipsoid upon overlapping, tiedyed, dizzying ellipsoid until the loop finally, mercifully terminated. In this case, his comment is multi-layered, beautiful, astute.
There's a very strong norm against publishing phone numbers, addresses, etc in journalism (esp. criminal and political journalism). I readily agree with this norm -- it seems that publishing such information can invite vigilantism and generate life-long problems for the accused without the benefit of a fair trial. I would generally expect journalists to abide this norm in news reports on robbery, drug trafficking, arson, embezzlement, etc.
Never-the-less, I felt a twinge of satisfaction while reading phone numbers and street addresses in TSG's article. I wouldn't mind if these serial harassers received a series of harassing phone calls.
Then again, TSG accuses Pranknet of systematically violating the informal norms that their victims rely on; is it proper for TSG to turn around and break an informal norm of journalism?
I'd like to better understand the ethical question here. Perhaps TSG's approach is the only way to deal with Pranknet? Perhaps it's poetic justice? Has TSG made a special ethical judgement regarding Pranknet? On what basis? Does TSG habitually violate journalistic ethics? Do the participants in Pranknet deserve worse treatment than anyone else accused of crime? How would our opinion change if TSG had presented the story differently?
I was once solicited by a firm that sold a wrapper for email-to-SMS gateways. Their sales team said that they'd been relaying a high volume of traffic for few years without incident. The claim seemed credible (although I felt the firm was slightly shady).
In any case, there's a lot of issues with email-to-SMS that can be resolved by negotiating a relationship with a gateway/carrier. As you mentioned, the content provider needs to maintain information about the user's carrier. Other differentiators:
Don't get me wrong. The carriers' price structures are extor-- ridic-- not favorable to content providers. But they do offer more functionality.
If the human brain were so simple that we could understand it, we would be so simple we couldn't.
