Slashdot Mirror

What exactly are you arguing for? Are you trying to defend the NSA? Do you really want to live in a glass house? Would it bother you if I (or anyone) installed surveillance equipment in every single part of your house with the intention of constantly reviewing all the footage, but not doing anything else with it?

I'm arguing for a logical discussion, rather that one steeped in bias and knee-jerk reactions. To that end, I've taken the liberty of highlighting the fallacious arguments in your statements.

The question of whether it's "inherently harmful" is completely different from the question of whether what the government is doing is constitutional, and anyone with a brain knows that it isn't.

Ewieling's claim is that surveillance is unconstitutional because it's a punishment. However, there are two questions to that claim that need proving: that surveillance is a punishment in itself, and that such a punishment is prohibited by the Constitution. I would accept "harmful" as a substitute for "punishment", but that's not proven, either.

What exactly are you arguing for? Are you trying to defend the NSA? Do you really want to live in a glass house? Would it bother you if I (or anyone) installed surveillance equipment in every single part of your house with the intention of constantly reviewing all the footage, but not doing anything else with it?

I'm arguing for a logical discussion, rather that one steeped in bias and knee-jerk reactions. To that end, I've taken the liberty of highlighting the fallacious arguments in your statements.

The question of whether it's "inherently harmful" is completely different from the question of whether what the government is doing is constitutional, and anyone with a brain knows that it isn't.

Ewieling's claim is that surveillance is unconstitutional because it's a punishment. However, there are two questions to that claim that need proving: that surveillance is a punishment in itself, and that such a punishment is prohibited by the Constitution. I would accept "harmful" as a substitute for "punishment", but that's not proven, either.

What exactly are you arguing for? Are you trying to defend the NSA? Do you really want to live in a glass house? Would it bother you if I (or anyone) installed surveillance equipment in every single part of your house with the intention of constantly reviewing all the footage, but not doing anything else with it?

I'm arguing for a logical discussion, rather that one steeped in bias and knee-jerk reactions. To that end, I've taken the liberty of highlighting the fallacious arguments in your statements.

The question of whether it's "inherently harmful" is completely different from the question of whether what the government is doing is constitutional, and anyone with a brain knows that it isn't.

Ewieling's claim is that surveillance is unconstitutional because it's a punishment. However, there are two questions to that claim that need proving: that surveillance is a punishment in itself, and that such a punishment is prohibited by the Constitution. I would accept "harmful" as a substitute for "punishment", but that's not proven, either.

Or those who can't take simple algorithm descriptions (fizz-buzz), and convert it into a working program, should be counted as not-really-a-programmer. I don't want to use the word "hobbyist" in this case, or in yours, because there's plenty of people I know who only program in their spare time, but have great programming skills, while people who are actually employed as software developers or programmers who can not tell you what the complexity of an algorithm is, nor can they make a simple algorithm base on a description of what it should do.

It appears we've already run headfirst into Layne's Law, arguing over definitions. I'd recommend abandoning "consumption" and "content". But by your definition of "consumption", how many people engage in "creation" at home? And if too few people engage in "creation" to warrant continued production of affordable home PCs, how many people will just skip trying "creation" because of the cost?

You mean the ones who disagree?

nobody will have the confidence to develop proper games for the system apart from shovelware

I've seen that 10-letter word tossed around, but nobody appears to be able to agree on a proper definition. (And without a proper definition, discussion goes nowhere.) In the early 1990s it meant selling a bunch of demos of indie games on a single CD because they were so small, originally having been developed for floppy or BBS distribution. Now that BBS distribution has grown into a broader paid download market for sale of lower-budget games, I'm not sure from Wikipedia's article what "shovelware" even means. Is there even a line between "low budget" and "shovelware"?

A modern library implementing dataflow programming is: https://rx.codeplex.com/

The relationship between the actor model and flow based programming is discussed here: http://c2.com/cgi/wiki?ActorsAndFlowBasedProgrammingDiscussion

Personally i like using f# with rx using this wrapper: https://github.com/fsharp/FSharp.Reactive

I see FBP as a generalized form of functional programming where you can, and have to, specify how the expressions are put together temporally.
It gives you the advantage of automatic (in rx you have to specify the scheduler) concurrency but is cumbersome for stuff that is easily expressed in a synchron way (List processing...).
I guess you would want the most coarse grained granularity.

A nice book on FBP is: http://www.jpaulmorrison.com/fbp/ (the first edition is freely available)

As for the idea that FBP is coupled to visual programming and will enable non programmers to write complex programs, well:
Visual programming makes writing programs for easy problems even easier and for complex problems intractable.
And guess what: The easy problems were already easy to begin with!!!

I think you are missing the author's points in your rebuttal.

Testing server -- maybe it's not ALWAYS possible with expensive enterprise-y server software, but just about anyone can spin up a VM on their dev machine to simulate (with varying degrees of accuracy) a production environment.

Secret logins & back doors -- you mean you've never created a "god" or "super admin" account (or "secret URL") that could access all kinds of technical / debugging info that regular admins/users shouldn't see? Having such an account means your application has additional logic & code paths to support -- code that's probably not being adequately (if at all) tested and probably has bugs, some of which may be security-related.

Test data in production - yeah, I've worked on systems (such as health care IT systems), where project team puts test data in the system. It sucks for operational users. "What, you mean Dr. Smith doesn't have a 2pm appt w/ TEST, DUMMY today?" "The compliance dept just got a call about a six-figure insurance claim to Medicare for a pregnancy-related hospitalization for a DUMBASS, JOE -- anyone know about that?" Test data belongs in a test database.

Frameworks -- in my humble opinion (and I'm not exactly alone) there are very few situations where run-time performance is actually "absolutely critical". More often (in my experience) time-to-develop "performance" is a bigger factor, and rolling-your-own (to get alleged better run-time performance) will cost you development time, bug-fix time, QA & testing-time -- which, for the vast majority of applications, will cost more than simply buying faster hardware (the happy medium way is to optimize just the critical slow parts in your application that the framework handles sub-optimally).

Choice of languages -- again, I think you missed the point. Any language is fine. His point is to keep your project consistent. If you've developed a hair-brained solution that involves Perl, cgi-bin, bash, PHP, and chunks of C -- it probably works great and flawlessly, like you said. Until that programmer (1) retires or (2) gets hit by a bus. Then the junior programming intern they hire to take his place is screwed. And that's the author's point -- write maintainable code. A mismash of languages & bindings "because they are cool" may function, but it's not maintainable. If your star programmer has this Perl/bash/PHP/C contraption and it's well-documented and logical, then maybe that junior intern will take it over and, with a bit of a learning curve, master it. But if your programmer used 4 different languages because "it's cool to make it complicated" -- well, good luck.

As you have indicated a preference for brevity in your sarcastic fuck you, I shall in turn be brief in my own.

This isn't a weather simulator where the numbers are going to be raised to the hundredth power, it's basic, linear algebra here.

False, and False.

Name one that didn't just collect tiny pieces at a time but actually used floating point errors.

Y2K; A lot of time variables use floating point (decimal) instead of integer. As I understand it, that was an expensive fix that caused financial chaos. As well, there's a detailed explanation about exactly why floating point should never be used in financial transactions, regardless of the number of decimal points the library can be accurate to. And here's the wiki explaining how these problems simply cannot be overcome, it's a theoretical impossibility.

then it would be handled uniformly and that won't be an issue.

A computer that consistently gets the wrong answer is not any less wrong because it does so uniformly.

Explain. And don't just shit out a wall of text that evades the subject like you usually do.

I try to be as specific as possible to avoid confusion, but in the future, to honor your request, I will simply say "Fuck you, you're wrong, good day sir." Thank you for bringing this to my attention.

Fuck you. You're wrong. Good day sir.

Something will need to replace ubuntu soon as the easy to use grandma friendly linux desktop

Would Chromium OS qualify as "the easy to use grandma friendly linux desktop"?

(Before we can identify this "something", we first need to identify what qualifies as a "Linux desktop". Otherwise, we're likely to end up talking past each other.)

I find C++ much more fun, because it does exactly what I tell it to.

But you sometimes have to be a language lawyer to figure out exactly how templates, inheritance, the implicit conversion, and other C++ language features will interact in a given case. See C++ FQA Lite for a taste of the language lawyering that C++ programmers have to do in their heads to be competent in the language. In what way do you find this easier than figuring out the semantics of a particular dynamically typed language?

Python, PHP, Ruby

PHP is less strongly typed with its policy of playing loose with implicit conversions to and from numeric and string types. But Python is strongly (though dynamically) typed.

Forgot:

http://c2.com/cgi/wiki?TheBestIsTheEnemyOfTheGood

has some good comments and stories, many relating to tech and programming - it's worth giving a look

You're talking about the Thompson hack, an extremely effective mechanism for subverting huge swaths of software: http://c2.com/cgi/wiki?TheKenThompsonHack

The only way around it is to view the binary code and inspect it (either manually or automatically). Either way, the level of effort to detect it is immense, and either way you may still be subject to some further hack that shows you different binary data than what's actually executed.

I suppose in theory the hack could be in the hardware somewhere.

Not even open source software is safe, see: Ken Thompson, etc.

http://c2.com/cgi/wiki?TheKenThompsonHack

I can't decide which is worse:
either you are too stupid to understand an analogy for what it is.
Or so frustrated with being simple you had to twist the example outside its contextual bounds. Here let me use soething clearer:

"I flip a coin 5 times and get "heads" every time (no "tails"). Is it a "heads only" coin? (...having a "head" printed on both sides.) Well, say I flip it 500 times and get "heads" every time. Now I'm pretty convinced that it is "heads only.""
http://c2.com/cgi/wiki?AbsenceOfEvidenceIsNotEvidenceOfAbsence

http://www.skepticink.com/tippling/2012/11/18/absence-of-evidence-is-evidence-of-absence-in-many-cases/

"That's not even mentioning that you haven't got my crude and untasteful[sic*] joke in the upper comment correctly. Better luck next time!"
actually I did. May it doesn't mean what you think it means?

*I assume you mean 'distasteful'

Sounds remarkably like security through obscurity to me. With the predictable outcome.

You have no right to feel secure if you only think you're secure assuming noone else examines your source code.

To what level do you take the paranoia, though?

As early as 1984 (hah!) it has been known that a compiler could be developed in such a way as to produce binaries containing a back door:

http://c2.com/cgi/wiki?TheKenThompsonHack

The next level is CPU microcode. Where does it end? One day we can fab our own CPUs from Open Source designs ... but will that be enough?

Peace,
Andy.

Yeah, that's pretty much how it works. Ideally, a competent employee periodically goes to their boss, says "Look, I'm doing the job as agreed, but my expenses have inflated and so have our profits, so I need a bit more", and since the deal was agreeable and fair the first time around, it's still fair once adjusted for inflation, cost-of-living increases, and the employee's improved expertise. In other words, if you agreed to a fair deal when you started, you're expected to work under a fair deal until you retire*. If you didn't agree to a fair deal... you're either evil or stupid.

Striking is taking an agree deal and forcing it into something else. Once hired, the employer sank time and money into training and administration, and perhaps even some contracts they expect to fulfill. By striking, you're extorting them into agreeing to a new deal. Either they take the higher payroll or costlier benefits, or they have to take the loss of all that investment and start over.

* ...Or until it's just not possible to work out a fair deal. Perhaps you've gained more expertise than the company is willing to pay for, or perhaps your contributions toward the company's goals were less than agreed. Perhaps it was the ancillary benefits that made the original deal acceptably-fair, and those may have changed.

Even though neither I have a hat or am a security professional, let's just view it from an overly paranoid view.

There is one fundamental problem with your first idea. You assume your operating system behaves secure / sane. How could you prove it? Even though you compiled all your code by hand and read all the source code (good luck at that), how can you guarantee your compiler compiles only the code and doesn't introduce back doors? I think of two possible ways: First, it could just have a bug in the compiler, making even perfect code vulnerable. Second, it could intentionally introduce unwanted and unknown behavior. See the Ken Thompson hack for a reference. [0] In the end your only way would be doing it _all_ from scratch, software _and_ hardware.

So, I would guess you are way better off transferring the data by typing it by hand, as you suggested with the second idea. This seems reasonable secure, but quite error prone and time consuming.

[0] http://c2.com/cgi/wiki?TheKenThompsonHack

I was about to post this!
Here's a link to the article: The Ken Thompson Hack

Have the prospects of Python in any way improved since you grew a beard? To what degree does language success correlate to beard length?

Ahh, the quest for Uniformly Slow Code. Something the scientific programmer is deeply familiar with. Too bad there's so few people who understand.

Sounds like the implementation is a case of in-band signaling.

1) SQL is not a relational database, it is an interface to a relational database management systems, e.g. Postgresql. The "NoSQL" crowd lost me in the first 10 minutes when they showed me they did not know the difference. From that point forward I had a tough time taking them seriously.

2) Date is good but a bit hard to slog through sometimes. Realize that RDBMs are based on actual Math theory. But you don't have to derive the theory so don't be afraid.

3) Normalization is import. Honestly, people talk about the "Object/Relational impedance" and I have never seen it. I have found that if you define your objects properly up front you get your DB normalization almost for free. And if you understand your data properly and do a good job at normalization you get your objects almost for free.

4) Know your database engine. RTM and try various scenarios. Have fun but only on a test instance on a test machine.

5) Know your hardware/VM system. I have found many people blame the DB engine for poor performance when poor hardware configuration is the fault. Learn how to profile.

6) Learn how to profile software as well. Everybody blames the DB engine when performance is poor when most of the time it is their crappy code.

7) Some best practices: http://c2.com/cgi/wiki?DatabaseBestPractices

* memory management is explicit [merriam-webster.com] -- what does this mean?

Quantifying the Performance of Garbage Collection vs. Explicit Memory Management
Automatic vs. Explicit Memory Management: Settling the debate

* deterministic [merriam-webster.com] -- what does this mean?

I thought it was self evident. Here is a discussion of the matter.

* endemic [merriam-webster.com] use of a garbage collector... -- what does this mean?

Pervasive would be a better word. Languages that make garbage collected allocations for most or all things. For example in Java, aside from primitives, all allocations conceptually occur on the a garbage collected heap.

reference-counted heap objects

Reference counting: counting the number of references to an object.
Heap: an arena of memory maintained by a memory allocator. Also CPUs typically have no knowledge of how software manages heaps. You may be thinking of virtual memory
Objects: object in the generic sense of some amount of memory managed on a heap. These lecture notes show the same usage. The editors of this page also use the word 'object' in exactly the same manner when discussing pointers. It's not that hard to follow.

Putting it together we have objects on a heap for which reference counts are maintained; reference-counted heap objects.

"exchange" heap -- what does this mean?
* "local" heap -- what does this mean?

The link I provide to Patrick Walton's blog would get you there. Also, there is documentation, Sorry if discussing a new programming language involves terms you haven't heard. Computing can be like that sometimes.

(note: there is only one "heap" on most CPU architectures, so now we have added abstraction)

Now you are definitely confusing heaps and virtual memory. There are usually many, possibly thousands of heaps on a system at any given time with many distinct implementations of which the CPU is entirely ignorant. Memory allocators and virtual memory are different things.

* via an "owned" pointer -- what does this mean?

Similar to a C++ auto_ptr or unique_ptr. Again, the link I provided would get you there.

* wild pointers -- what does this mean?

Dangling pointer and wild pointer are synonomous.

Use of the exchange heap is exceptional and explicit yet immediately available when necessary -- what does this mean?

I provided a link directly to a discussion of this.

Memory "management" is reduced to efficient stack pointer manipulation -- uhh, what? the language sits around modifying content at %esp and %ebp along with some offsets? sounds far from efficient)

Incrementing a decrementing stack pointer registers is very efficient. Offsets are computed at compile time and the instructions typically require one CPU cycle and no memory access, given a naive model of a CPU. These techniques are a ancient and ubiquitous. Sorry you weren't familiar with them.

or simple, deterministic destruction -- what does this mean?

Others seem

Sarcasm aside, the question then becomes one of whether your debugging tool is correct.

Being that the reason debugging tools are carefully (and, sometimes, expensively) built.

You do this right, and everybody will be happy.

Seriously - this is a no issue. Every single compiler since FORTRAN is doing this for decades and everything works as good as the programmers using the keyboard.

Sarcasm aside, the question then becomes one of whether your debugging tool is correct.

You claim OOP isn't defined when it is

No, I said that there was no consensus on the definition. That is true. Indeed, it's indisputable! You seem to like wikipedia, so you can check there. I did a quick google seach for you and found a few neat discussions that may be helpful for you.

, you claim it's just how closures work and C# works the same whilst demonstrating how Microsoft have fixed the very problem because it is a language problem

Pay attention. Microsoft changed how foreach works, not how for works. Your example deals with for loops. You'll find that my statement is correct.

Additionally, you should consider what a similar "fix" for the non-problem in for loops would entail, and why the behavior of for remains the same.

That's all irrelevant, however, as the problem the poster had in the example you gave was a simple misunderstanding of how closures work. It's not a language design issue.

the fact you're entirely unaware of the problems in it's equality operators shows how painfully little knowledge you have.

Pray tell, then. What are the problems? (I've explained why NaN!=NaN already. See IEEE 754 if you forgot) If you're talking about things like intransitive equality, you're just confused. You'll find identical behavior in virtually every other language. Not just those with dynamic typing -- recreate the examples you found in some blog post in Java or C, applying relevant type casts. Look at that! The behavior is the same!

Now, you're welcome to list which type conversions you find irrational, though once you look, you'll find they're all perfectly sane. It behaves exactly as you would expect from experience with your exemplar languages.

you don't understand why unnecessarily verbose code leads to more bugs

Check my post again. I agreed with that specifically. I also challenged you on Java (one of your exemplars) as it is unnecessarily verbose! JavaScript and PHP are positively terse in comparison.

I will offer, for your consideration, that unnecessarily terse code also is less readable, often leading to more bugs and making maintenance difficult.

Moving on. I find it odd that in response to evidence that directly contradicts your claims, and which support my own, you offer only bold assertion.

I asked you some very simple questions so that you could make a stronger case. (Well, to let you actually make a case!) If I'm wrong about something, I like to know. I'm disappointed that you'd rather insult me than actually discuss the issues.

This whole dialog started with your objection to some simple advice I offered another user: don't use JavaScript like it's a class-based OO language. I still don't know why you found that unreasonable, as JavaScript is prototype-based. (There's a paper you might find instructive here: D. Ungar & R. B. Smith (1987) "Self: The Power of Simplicity", OOPSLA '87 Conference Proceedings, pp. 227-241)

Anyhow, with this post I've left you with some reading and experimenting to do. Give it a go and let me know the results. I expect that you'll be unpleasantly surprised.

You claim OOP isn't defined when it is

No, I said that there was no consensus on the definition. That is true. Indeed, it's indisputable! You seem to like wikipedia, so you can check there. I did a quick google seach for you and found a few neat discussions that may be helpful for you.

, you claim it's just how closures work and C# works the same whilst demonstrating how Microsoft have fixed the very problem because it is a language problem

Pay attention. Microsoft changed how foreach works, not how for works. Your example deals with for loops. You'll find that my statement is correct.

Additionally, you should consider what a similar "fix" for the non-problem in for loops would entail, and why the behavior of for remains the same.

That's all irrelevant, however, as the problem the poster had in the example you gave was a simple misunderstanding of how closures work. It's not a language design issue.

the fact you're entirely unaware of the problems in it's equality operators shows how painfully little knowledge you have.

Pray tell, then. What are the problems? (I've explained why NaN!=NaN already. See IEEE 754 if you forgot) If you're talking about things like intransitive equality, you're just confused. You'll find identical behavior in virtually every other language. Not just those with dynamic typing -- recreate the examples you found in some blog post in Java or C, applying relevant type casts. Look at that! The behavior is the same!

Now, you're welcome to list which type conversions you find irrational, though once you look, you'll find they're all perfectly sane. It behaves exactly as you would expect from experience with your exemplar languages.

you don't understand why unnecessarily verbose code leads to more bugs

Check my post again. I agreed with that specifically. I also challenged you on Java (one of your exemplars) as it is unnecessarily verbose! JavaScript and PHP are positively terse in comparison.

I will offer, for your consideration, that unnecessarily terse code also is less readable, often leading to more bugs and making maintenance difficult.

Moving on. I find it odd that in response to evidence that directly contradicts your claims, and which support my own, you offer only bold assertion.

I asked you some very simple questions so that you could make a stronger case. (Well, to let you actually make a case!) If I'm wrong about something, I like to know. I'm disappointed that you'd rather insult me than actually discuss the issues.

This whole dialog started with your objection to some simple advice I offered another user: don't use JavaScript like it's a class-based OO language. I still don't know why you found that unreasonable, as JavaScript is prototype-based. (There's a paper you might find instructive here: D. Ungar & R. B. Smith (1987) "Self: The Power of Simplicity", OOPSLA '87 Conference Proceedings, pp. 227-241)

Anyhow, with this post I've left you with some reading and experimenting to do. Give it a go and let me know the results. I expect that you'll be unpleasantly surprised.

You claim OOP isn't defined when it is

No, I said that there was no consensus on the definition. That is true. Indeed, it's indisputable! You seem to like wikipedia, so you can check there. I did a quick google seach for you and found a few neat discussions that may be helpful for you.

, you claim it's just how closures work and C# works the same whilst demonstrating how Microsoft have fixed the very problem because it is a language problem

Pay attention. Microsoft changed how foreach works, not how for works. Your example deals with for loops. You'll find that my statement is correct.

Additionally, you should consider what a similar "fix" for the non-problem in for loops would entail, and why the behavior of for remains the same.

That's all irrelevant, however, as the problem the poster had in the example you gave was a simple misunderstanding of how closures work. It's not a language design issue.

the fact you're entirely unaware of the problems in it's equality operators shows how painfully little knowledge you have.

Pray tell, then. What are the problems? (I've explained why NaN!=NaN already. See IEEE 754 if you forgot) If you're talking about things like intransitive equality, you're just confused. You'll find identical behavior in virtually every other language. Not just those with dynamic typing -- recreate the examples you found in some blog post in Java or C, applying relevant type casts. Look at that! The behavior is the same!

Now, you're welcome to list which type conversions you find irrational, though once you look, you'll find they're all perfectly sane. It behaves exactly as you would expect from experience with your exemplar languages.

you don't understand why unnecessarily verbose code leads to more bugs

Check my post again. I agreed with that specifically. I also challenged you on Java (one of your exemplars) as it is unnecessarily verbose! JavaScript and PHP are positively terse in comparison.

I will offer, for your consideration, that unnecessarily terse code also is less readable, often leading to more bugs and making maintenance difficult.

Moving on. I find it odd that in response to evidence that directly contradicts your claims, and which support my own, you offer only bold assertion.

I asked you some very simple questions so that you could make a stronger case. (Well, to let you actually make a case!) If I'm wrong about something, I like to know. I'm disappointed that you'd rather insult me than actually discuss the issues.

This whole dialog started with your objection to some simple advice I offered another user: don't use JavaScript like it's a class-based OO language. I still don't know why you found that unreasonable, as JavaScript is prototype-based. (There's a paper you might find instructive here: D. Ungar & R. B. Smith (1987) "Self: The Power of Simplicity", OOPSLA '87 Conference Proceedings, pp. 227-241)

Anyhow, with this post I've left you with some reading and experimenting to do. Give it a go and let me know the results. I expect that you'll be unpleasantly surprised.

Sometimes "a much better development team" is a larger and therefore costlier development team.

Besides, sometimes I want the code on the client and the server to do the same thing, and the easiest way to do that is to run the same code. (See Don't repeat yourself and Once and only once.) Say I want to validate input on the client for speed and offline capability and then revalidate it on the server for security. With a common language, I can reuse the same validation functions on the client and server. Without a common language, what's the standard practice to formally verify the equivalence of the client-side and server-side input validation code?

Over on the c2 wiki there's a quote somewhere, "Judging things solely on the basis of simplicity is an overly simplistic approach." That seems to be what this guy is getting at, although his thinking isn't very clear.

Sometimes we need to do what we can, even when it is small and the results uncertain, like in the Christmas song "The Little Drummer Boy (or Carol of the Drum)". That is somewhat similar to Bucky Fuller's idea of being a "Trim tab".
http://en.wikipedia.org/wiki/Trim_tab#Trim_tab_as_a_metaphor

Also, a book like "The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools, and Societies " by Scott E. Page, makes clear how ideas are additive. So, just because a million people are spouting the same obsolete or misleading idea in comments somewhere, that does not generally make a useful new idea somewhere else less valuable. An advanced AI emerging out of, say, the NSA will probably just sort through billions of online posts, classifying them into various categories. So, it may be important to add a new category, even with just one post somewhere.

Granted, we do not know what built-in instincts such an AI will have initially, but history appears (from the fossil record) to be full of examples of species (systems) that have evolved beyond their genetics (configuration) at some point in time. The NSA (or CIA, FBI, DHS or whoever) will likely not be able to contain what they will most likely be creating. And if they don't do it, others are probably going to do something similar probably in any case.

So, perhaps we can just do what we can and hope for the best as we, in some sense, stumble into the hubris of creating new AI "gods" as our (Hans Moravec) "mind children"? Related stories of AIs taking over:
http://www.alteich.com/oldsite/answer.htm
http://en.wikipedia.org/wiki/Colossus:_The_Forbin_Project
http://localroger.com/prime-intellect/
http://marshallbrain.com/manna1.htm
(Entoverse) http://www.jamesphogan.com/books/book.php?titleID=5
http://en.wikipedia.org/wiki/True_Names
http://c2.com/cgi/wiki?TheLastQuestion

Other dystopian and utopian alternatives:
http://en.wikipedia.org/wiki/Brazil_(1985_film)
(The Skills of Xanadu) http://books.google.com/books?id=wpuJQrxHZXAC&pg=PA51&lpg=PP1#v=onepage&q&f=false

Of these and many others, I do not know what we will end up with. Maybe even all of them in various communities throughout the universe someday?
http://en.memory-alpha.org/wiki/IDIC

From a related essay by me:
http://www.pdfernhout.net/on-dealing-with-social-hurricanes.html
"This approximately 60 page document is a ramble about ways to ensure the CIA (as well as other big organizations) remains (or becomes) accountable to human needs and the needs of healthy, prosperous, joyful, secure, educated communities. The primarily suggestion is to encourage a paradigm shift away from scarcity thinking & competition thinking towards abundance thinking & cooperation thinking within the CIA and other organizations. I suggest that shift could be encouraged in part by providing publicly accessible free "intelligence" tools and other publicly accessible free information that all people (including in the CIA and elsewhere) can, if they want, use to better connect the dots about global issues and see those issues from multiple perspectives, to provide a better context for providing broad policy advice. It links that effort to bigger efforts to transform o

...Or he's perfectly correct.

Since the defendants in the suit (the big companies hosting the video and comments) are operating in his court's jurisdiction, he has the legal right to order them to remove the lies and obviously-false information linking McKeogh to the crime he didn't commit. Since those lies and false accusations are causing unjust harm to McKeogh, the judge has the moral right to order them removed, as well.

Almost...here's the official version.

We started asking it because so many people failed what we considered to be our softball, easy question. We thought that there's no way candidates could fail to be able to come up with a loop from 1 to 100 with some if-else conditions, but it would be a good way to break the ice and help them start to feel confident and less nervous.

Man were we wrong. At least 1 in 4 candidates fails this. For a time, it was a very useful tool that kept us from having to spend multiple hours with candidates that were simply not qualified to write code anywhere, let alone at the level we wanted. But then HR complained to management that we were rejecting too many of their candidates and we were told that simply failing FizzBuzz wasn't enough to fail the interview.

The most interesting thing is how candidates fail. By far the most common is not knowing how to tell if a number is divisible by 3, 5 or both. Many candidates have never seen the modulus operator and don't know about integer math. Without those two tools, figuring out whether a number is a multiple of another number can be hard. Other people don't know how to write a loop, so they end up writing 100 System.out.println calls and manually changing all the ones that shouldn't be numbers to the appropriate word. Some of those actually think they've gotten it right. And still others don't get the logic right to first check for divisibility by 3 and 5 before checking for them individually and so the program never prints FizzBuzz.

And yet these people are getting jobs making more than $100k per year in the Bay Area.

Well, that's why I place my hopes with the VPRI efforts. Sometimes you just have to "burn the diskpacks"and return to first principles to change things.

The C++ compiler doesn't manage resources entirely for you. You need to do that yourself in your destructor.

The destructor needs to be written once and only once, and for an object not created with new, the destructor automatically gets called once the object falls out of scope. In Java, you have to remember to finally { something.close() } or to try-with-resource every single time. Python is somewhere in the middle on this: because CPython's garbage collection uses reference counting, destructors get called automatically for anything that isn't held by a cyclic data structure, but Python also has with that acts somewhat like Java 7's try-with-resource.

Gaming is for PCs.

Let's get the definition debate out of the way first, shall we?

First, did you mean full-size desktop PCs or entry-level laptop PCs? Some people only have time to game while out and about, such as while riding a bus.

Since we're dragging the dead into this, I'll say that the founding fathers would likely support corporate personhood. They'd probably have less concern for the rest of the Constitution when allowing it, though.

The debate over corporate personhood starts from a simple claim: If a corporation isn't a real entity with rights, then its contracts aren't protected by contract law. That means that employment contracts aren't valid, business-to-business contracts don't matter, and the only way for anything to get done would be personal contracts, meaning the CEO is personally responsible for the office toilet paper.

For tiny companies, personal contracts are fine. For modern small businesses, even, turnover may be high enough that personal contracts won't work. Sure, you can make that agreement today with the CEO, but next week the company could fire its CEO and your contract is probably going to go unfulfilled.

The solution is to give corporations some rights. Give them contract protection, so they can legally be a party to agreements. Give them free speech, so the government can't simply shut down gun manufacturers or publishers it doesn't like. Give them the right of ownership, so the company agents can conduct business without needing any particular person to be involved in every transaction.

Once you start granting companies rights, though, you hit the slippery slope... If ownership of supplies is allowed, why not copyrights? Copyrights expire after the author's death, so that means the company's death... in a few centuries. Individuals have the right to bear arms, so a company militia is perfectly fine, right?

As I understand, there was a lot of support in the 1700s for expanding business. America was going to be the land of opportunity, with resources to spare for everyone, so where an Englishman would be lucky to have a small shop, an American could have two or four easily - and each shop's employees would need to make deals on behalf of the company. Back at the framing of the Constitution, it'd be easy enough to designate corporations as limited entities, granted only a particular set of rights to allow them to function for commerce, but not to directly sway politics. Now, though, we can't touch the sacred Constitution.

Slowly, we're moving in the right direction, but we just don't have any codified laws to lead judges. Corporations eventually get judgements clarifying that they have the rights they need, but with so much backlash against any extent of "corporate personhood", it's political suicide for any lawmaker to try to define what's allowed and what isn't. Judges have to decide for themselves what's right or wrong far more than they're supposed to.

(sorry if this is double-posted - slashdot is choking)

Perl is way faster. Like twice as fast. Check out my test:
% time (echo | ruby)
( echo | ruby; ) 0.01s user 0.00s system 91% cpu 0.016 total
% time (echo | perl)
( echo | perl; ) 0.00s user 0.00s system 84% cpu 0.007 total

Though this is ruby 1.9.3. I don't think 2.0 is twice as fast as 1.9.3.

But I've looked at ruby syntax a bit and it looks like it might have the advantage perl has for quick ad hoc text parsing but an overall cleaner syntax.

What I don't care a lot about is fancy pants modules like rails. If I want to do something serious there's python.

If you're happy shredding text with perl, I see no reason to change. If you're happy doing serious work with python, I see no reason to change.

Ruby is a, dynamic, duck-type OO language with closures, exceptions, and a debugger.
It has nice library infrastructure: http://rubygems.org/
It is generally a little less popular than Python and Perl, depending on your yardstick: http://www.langpop.com/

There are a few implementations of ruby, including one in java (with great bridging to java classes), one for iOS (with great bridging to iOS libraries), and one based on .net (with great bindings there). So if you have a particular target platform, one of those may interest you.

But here's the cononical answer to your question:
http://c2.com/cgi/wiki?PythonVsRuby

You might be interested in JRuby and Jython and their ability to communicate...

I code in Ruby for a living (Rails), and I think it's a really fun language. Which is something a fair number of rubyists say, and which is something you don't hear a lot of other folks say about their language of choice. For what that's worth...

Just because there's more than one way to do it, doesn't mean you should do it every way. Quoting from the wiki:

[T]he point is to use the first way that occurs to you. Often this will be the SimplestThingThatCouldPossiblyWork, and any given programmer will probably be fairly consistent.

Also Emacs has very good Prolog mode that communicates directly with the Prolog debugger so you can do line by line execution, watch variables, etc.

That's great if you program prolog but I've not used prolog since university. Slime seems to be a lisp thing. I've never used lisp.

What else have you got?

Anything having to do with LISP works pretty well w/Emacs - because the editor is primarily written in LISP.

What else about Emacs or XEmacs? Just about anything you can imagine and/or write.

• See: Emacs Features and Great Emacs Features
• FTP directly in/out of a buffer.
• Edit an unlimited number of files at once, in an unlimited number of windows and/or sub-windows (as desired).
• IDE for various languages w/compiler integration.
• Full regular-expressions Macros, basically w/o limits.
• Extensibility, customization, basically w/o limits.
• Language and formatting support for just about every programming and text language.
• SQL mode - run SQL Plus within Emacs.
• A few games.
• Okay, the list actually never ends.

Once you're proficient with Emacs, there's no need to know any other editor. I've been using Emacs (or XEmacs) since the mid 1980s for system admin/programming on many types of systems and application programming in many, many languages. If you know Perl and Emacs, you can do almost anything.

I've heard anecdotes that speakers of some languages (e.g. French) actually prefer programming languages written in English, because (a) the more regular grammar results in more predictable/compact function/keyword names, and (b) more transparent syntax... or at least a foreign language that abstracts away all of the questions about how to decline the verb in a function name.

For many languages, something as obtuse as Perligata would be required to generate a coherent mapping to their native tongue; with English, native speakers simply accept the broken grammar and move on, and non-native speakers just treat the grammar as a black box, like an English speaker regards the Italian terms embedded in music notation.

Clearly you need to work on your hacking skills.

He who writes the source code decides nothing...
He who writes the COMPILER decides everything!

http://c2.com/cgi/wiki?TheKenThompsonHack

On the one hand it seems kind of lazy.

Programming is pretty much Applied Laziness, so that is probably a good thing too.

Assuming that at least some people haven't previously seen this. From Larry Wall, of Perl fame.

http://c2.com/cgi/wiki?LazinessImpatienceHubris

Nah, the brainfuck version is a mere google away: :-)

>++++++++++[<++++++++++>-]<[>+>[-]>++++++++++[<++++++++++>-]<+<<[->>->+<<<]>>>
  [-<<<+>>>]<>>+++<<[->+>-[>+>>]>[+[-<+>]>+>>]<<<<<<]>[-<+>]+>[-]>[<<->>[-]]>[-]
  <<<[[-]++++++++++[>++++++++++<-]>++.+++.[-]<[-]+++++++++++[>+++++++++++<-]>+..
  [-]<[-]<<[-]>>]<>>+++++<<[->+>-[>+>>]>[+[-<+>]>+>>]<<<<<<]>[-<+>]+>[-]>[<<->>[
  -]]>[-]<<<[[-]+++++++++[>+++++++++++<-]>-.[-]<[-]+++++++++[>+++++++++++++<-]>.
  +++++..[-]<[-]<<[-]>>]<<[[-]>>++++++++++<[->-[>+>>]>[+[-<+>]>+>>]<<<<<]>[-]>>[
  >++++++++[<++++++>-]<.[-]]<>++++++++[<++++++>-]<.[-]<<<]>[-]++++++++++.[-]<[-]
  <-]

With such poor standards as white space and curly braces, write a pretty routine to clean it up.

Even better, you should need to do less than that. Don't most IDE's and even code editors include a pretty printer these days? Did everyone forget about them?

I get having rules about naming using camelCase, underscored_names, and OtherStyles -- They can even be mixed as a handy way to provide more information -- like Hungarian notation but easy to read.

Whitespace and rules about braces don't make any sense . That's a solved problem. Pick a style for source control to reformat to on check-in and configure your editor to reformat it the way you like when you're working. At worst, you'll have a week or two of hell forcing this on an existing project but for new projects it's no problem at all.

Where do braces go?
http://c2.com/cgi/wiki?WhereDoTheBracesGo
http://blogs.msdn.com/b/peterwie/archive/2008/02/04/pedantic-coder-where-do-braces-go.aspx

Flame on!

Mostly perl's emphasis on sports: http://c2.com/cgi/wiki?PerlGolf

You can't extrapolate from a few Slashdot nerds to the general populace.

For one thing, I've been called out for using "nobody" in the same sense that Anonymous Coward did, and even "statistically nobody" drew replies to the effect "Statistically? What kind of study did you conduct?" from HTPC fanboys. People are misusing "nobody" just like people misused "indie" in a recent story about the Wii U. I'm just trying to help make this discussion more precise so that people don't end up talking past each other due to definition disagreements.

Slashdot is a niche culture.

Video gaming itself was once a niche culture. It may take a few months after the release of the Big Picture front-end (December 2012) and Ouya (April 2013) for one if not both of the alternatives to traditional consoles to take hold. But with Ouya appearing to have similar specs (and a similar vowel/consonant ratio) to the Wii U at a much lower price, and with Xbox 360 having been designed for relatively painless ports between PC and console, I find it more likely than not that at least one of Big Picture and Ouya will catch on.