lliwta

> tech companies and incubators need to be targeting young black males for immersion and mentoring programs as early as 5th grade.

Unfortunately I have no power in SV. People who do are reading this, and I hope they notice how on-point you are. I'll do what I can in the regions I can effect most greatly.

> A more well rounded approach is needed and that can't begin until we are comfortable with admitting that the job isn't done in regards to young black males

I have a bit more power here, albeit not much. Honestly -- and I'm very ashamed of this -- I've been reluctant to call out the elephant in the room (publicly, using my real identity) for exactly the reason you identify (it's not "sexy" and seems "political" somehow).

Anyways, thanks for contributing. I'm now resolved to finally do the right thing.

edit:

> Areas where they are currently.

I hadn't thought about it like this before, and mostly focused on how to increase AA representation in CS programs. Great idea.

Wow. Are you really claiming Apple gets moral high ground for its salaries even after criminal collusion to keep them low?

As Apple's aptly demonstrated, it doesn't pay those salaries for any other reason than that it must, and even then it will break the law to pay less.

Finally, most US Apple employees are located in California, where cost of living is substantially higher than most of the country. There's far less disparity in your figure when taking cost of living & the common academic pedigree of Apple's employees into account.

I'm so glad to see this post! You hit the nail on the head.

> Black men are being left out of another generation of wealth creation and we need to stem (excuse the pun) the tide of that now.

What's your suggestion, other than the normal stuff (engaging with students in HS etc)?

To be fair, github culture is a far cry from the early days of open source.

If I didn't run in with the first/second generation of OSS developers, I probably wouldn't like the culture either.

Now get off my lawn!

I'm sure it's not intentional, but you don't actually give a source.

I'm not sure why I find the missing citation so funny (probably because the claim is pretty surprising), but I laughed really hard and up-voted you in case it was a joke and not a mistake.

> via high-paying jobs, collecting payroll & sales taxes and income taxes.

In other words, doing what's absolutely necessary and expedient in order to make profit and not flagrantly disregarding certain portions of tax law?

And in the case of tech companies such as Apple, the "high paying jobs" bit comes with an extra bit of irony since they were doing the exact opposite to a criminal extent.

Color me unimpressed.

There's a huge difference between not paying the intended amount of taxes, and executing Herculanean acrobatics through (probably lobbying-induced) loopholes.

Also, these (implicit) appeals to the authority of judges always confuse me. Judges have political opinions, just like anyone else, and land on both sides.

Macros are used pervasively.

To use your analogy, it's like writing a lambda calculus interpreter with an FFI, doing everything via the FFI, and calling it declarative.

But macros are only part of the problem.

> That's part of what declarative programming is.

Sorry, I was constraining myself to the definition from the article.

I'm familiar with this characterization. I just don't think it's representative of realistic spreadsheet programming (edit: or many existing implementations).

Here's an excellent quote from the conclusion of a paper on the topic stating exactly this viewpoint (and they aren't even referring to macros afaict) [1]:

Current spreadsheet implementations do not strictly follow any of the established conceptual models. They rather follow a teleological approach of “what the user probably intends to do”. But phrases containing the word “probably” are problematic as they do not hold for all situations. This poses a challenge for education. If limits and “critical factors” remain unnoticed or misconceived, spreadsheet quality is seriously impacted.

[1] http://arxiv.org/pdf/0801.4274.pdf

> I think you've confused what mutable state is.

Absolutely not.

Macros provide shared mutable state. Macros are used pervasively in spreadsheet programming. You cannot carte blanc ignore macros without some serious explanation.

> The modal of computation of a spreadsheet is pretty much stateless.

Relative references means semantics depend on code layout, which in most hygenic circumstances is an old-school GOTO. In truly awful uses, relative references recover the sort of code layout dependencies which even C avoids. This can definitely be even worse than shared mutable state.

> Spreadsheets are a great example of a declarative ethos.

I kind-of agree. The primitives do have many nice properties.

> You're nitpicking on details which equally applies to prolog too.

I strongly disagree.

When escape hatches exist, I think you have to look at how a language/system is commonly used in order to assess whether it has some of these properties or not. Otherwise everything in which a pure function is definable becomes declarative and the phrase becomes rather useless.

Prolog and spreadsheets differ in a rather fundamental, albeit empirical, way: spreadsheet users tend to make pervasive use of the these imperative features.

So there are two alternatives -- spreadsheet programmers are all completely inexperienced and have no idea what's good for them, or there are fundamental limits to the declarative features of the spreadsheet model, beyond which they become imperative.

I think the answer is a bit of both. Spreadsheet users tend to not be trained software engineers, but they aren't idiots and basic programming is not rocket science. None-the-less, lots of spreadsheets end up with pervasive use of imperative features (which causes real problems in terms of maintainability)

So assuming a huge population of users are at least kind-of competent/intelligent, there appear to be fundamental limitations to the basic model, beyond which it can't be used to solve common problems effectively in a declarative way.

Which of course should be interpreted by those who really like spreadsheet programming as a call to arms (education and/or refinements to the model) rather than a categorical criticism...

> tenuous definition of declarative programming

> declarative programming good, Excel bad, hence Excel not declarative programming.

I didn't choose the definition of declarative programming. I'm taking the article's definition as given.

To name a few:

1. Macros. And you don't get to weasel, because any non-trivial spreadsheet application contains at least a few.

2. relative references, which are basically heap pointers.

3. simulating for loops/iteration is a fairly common thing in spread-sheet programming.

But also see my edit to the original comment.

As an aside, it's absolutely astounding to me that my original reply is down-voted.

edit: most obvious -> a few

edit2: Could someone please explain what's so offensive about these posts? Is there that much love for spreadsheet programming (last I checked everyone understood the downsides of at-scale spreadsheets and how these problems arise from subtle non-declarative features)? Am I being unintentionally abrasive? Should I post example files and links to empirical studies demonstrating how people commonly program spreadsheets in non-declarative ways?

Spreadsheets meet none of the three criteria given in the article:

* Independence: Spreadsheets explicitly rely upon mutable state for <strike>all</strike> some commonly-used operations (i.e., the value of cells).

* Statelessness: Non-independence implies non-statelessness.

* Deterministic: Non-independence implies non-determinism.

The reasoning for the last two point to an underlying problem with the criteria (removing the word "computation" from independence makes the three inter-reducible in any real-world machine). but yeah.

edit: all functions->some commonly-used operations

edit wrt downvotes: perhaps reserve judgement unless you've maintained a very large spreadsheet-based application written by non-programmers. Spreadsheets -- as most commonly used in practice -- do not meet the criteria above, except for the smallest/most trivial of applications. Period.

Now, perhaps the problem is the definition. Or perhaps the problem is that spreadsheets are awful at-scale (even assembly can be quite elegant for small problems or when usage is well-constrained). Or maybe both.

This blog post points out problems with the three criteria given in the article for what "declarative" means: http://existentialtype.wordpress.com/2013/07/18/what-if-anyt...

edit: addresses -> points out problems with.

edit2: the blog post also addresses the "referential transparency" characterization.