Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×

Comment Re:Could Amazon, Azure, others, ever be compromise (Score 1) 55

It helps to actually read the thing someone's replying to. Here's the whole thread up to your response, with my emphasis added:

Could public cloud providers be penetrated in such a way that all your data and activities belong to NSA, China, etc?

They probably already are. The reason you won't hear about it is because the people that break in to systems like that are very careful to go unnoticed. Hacking those systems is worth billions of dollars.

Tinfoil hat much

But to your inference, the intelligence community also sees monetary value in their interception and exploit programs, obviously, which is why they've invested in those programs. Bang for buck, investing in electronic intelligence almost certainly pays bigger dividends in aggregate than investing in human intelligence—at least that is what they must assume.

And with that said, if you were more preoccupied by the mention of China, and for some reason assuming corporate, rather than imperial, espionage... I'm even more at a loss at your accusation of paranoia.

Comment Re:Could Amazon, Azure, others, ever be compromise (Score 1) 55

Right of course. The intelligence community was exposed for intercepting every electronic communication they could and were allowed to continue doing so until private businesses were able/compelled to do it for them, and continually compromise and publicly undermine encryption. But imagining that they're actually using the power they've accumulated... that's paranoid and anyone suggesting it should be mocked.

It's not like the old days where you had to pay attention and make inferences, the stuff is public record now. Now it rightly sounds delusional to suggest that any important system escapes compromise.

Comment Re:Oh no! (Score 1) 149

I didn't know either. Then something I use (clojars.org) was affected. Then I looked it up. Then I was less ignorant.

If it doesn't affect you, it's okay to be ignorant about it, because why should you care? But do you really need to broadcast that ignorance every time you notice it? Unless you run your own news source, you know there isn't a news source specifically designed to cater to your tastes and whims right? It must be exhausting spitefully trying to curate every web page you visit instead of just scrolling past it.

Comment Re:Why? (Score 1) 149

Maybe the attackers have a point, even though I disagree with their actions. You don't need to consider an action acceptable to identify a motivation for the action, or even to share some or all of that motivation.

One of the reasons it's so hard to combat ideologically motivated crime is that, as a society, we do a terrible job either identifying legitimate grievances behind those crimes, or providing a sanctioned and effective alternative for redressing them. Instead, we tend to create an escalation feedback loop by saddling the moral character of grievances with the actions, however irrational, taken in their name.

Comment Re:Oh no! (Score 1) 149

Anonymous is a terrorist organization. Anonymous went after ISIS only because they don't like competition.

You're kidding right?

Disclosure: I'm not a particular supporter of Anonymous, I just find this kind of reasoning ignorant and dangerous.

Comment Re: Scrum Was Never Alive (Score 1) 371

I never said there was No True Agile.

AC was referencing the No True Scotsman fallacy, which works like this:

- Agile is XYZ
- But on my Agile team, X and Y are compromised and Z is practically nonexistent
- If it were true Agile, it would be XYZ

Unfortunately, as it can be important to define terms and then to evaluate conditions against those terms, mention of the fallacy can devolve into recursive bickering.

Comment Re:Because it was written in Seastar or C++ (Score 2) 341

Your characterization of functional programming is pretty astonishing, to me as a person who was most recently employed writing and maintaining software in Clojure. The following are all surely idioms, features or possibilities of one or another FP language/approach, but none of them are essential to FP:

1. "creating a list of items and combining operators, then magically evaluating those combinators all at once and getting a cake" — I think the reality is that this can be overdone (and sometimes it is), but for people who live and breathe the abstractions that come with a FP language, it tends to reflect the expressive qualities of core concepts and operators-as-functions. (reduce + 0 args) is just a whole lot more expressive, when familiar, than total = 0; for (val in args): total += val; return total.

2. "lazy evaluation" — I'm not really sure this needs to be specific to FP, but it does really shine with abstractions often associated with FP (e.g. map, reduce, filter, and so on).

3. "macros" — I cherry-picked this away from the C preprocessor reference to contrast with lispy/homoiconic macros, which are hardly the nightmare of metaprogramming in languages with every-which-way syntax, but even when macros are sane they tend to be strongly discouraged.

4. "monads" — I see monads far more in imperative code than functional, so I don't even. (I'm talking about the lovely Promise pattern, which is excellent.) Then again, I don't write Haskell.

I'd characterize FP differently: a function of a given set of arguments should always return the same value, without side-effects; in non-pure languages, add the caveat unless you have a good reason, which should be identified clearly in code; with that caveat, you can kinda do FP in any language (though it may be horribly inefficient).

In other words, stateful code is hard to reason with, and the greatest care should be taken to making it clear when it cannot or must not be avoided. This should be true in any programming environment.

You're right that people tend to mentally model in terms of objects—that is, the combination of data and action. But it doesn't have to be stateful by default, and there's a lot to gain from reversing that.

- - -

A little anecdote: for kinda silly reasons, I've been doing some one-off work in Node.js after spending a good long while in Clojure. It came time for me to reverse an array, and I wrote code like the following: var foo = bar.reverse();. With almost no real JS work for over a year, I could not recall the following:

1. Will bar be reversed?
2. Does Array#reverse actually return a reversed array value, or something else?

I couldn't know what that very simple code does, simply by reading it. I had to go evaluate it! It turns out that Array#reverse is a bit unusual in JS as it is both stateful (it reversed bar) and it sort of looks like it returns a value (it returned a reference to bar). That code which should do an obvious thing actually caused a bug, because I had to make guesses about state, and I guessed wrong.

- - -

There are reasons to choose a stateful implementation—performance, expressiveness, interop with stateful environments or libraries—but it's not a given, and not even always consistent with a normal mental model, for statefulness to be assumed.

Slashdot Top Deals

As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality. -- Albert Einstein

Working...