nmrm

I have a feeling that the problem is students show "If the equation is true, then 0=0" instead of "Note that 1=1; now, we derive P".

Even if all facts used in the proof are true "in both directions", it's still a serious breach of modern mathematical style to start with what you're trying to prove.

It's also possible that they don't explicitly note that the facts they're using are "true in both directions". edit: to be explicit, in that case I'd still consider the proof wrong

Anyways, if a student presented a proof like that, I would at least take a couple points off for the awkward style unless it was explicitly justified somehow.

It's also kind of a weird proof technique to start with 0=0 or 1=1 and bother to explicitly state this fact...

Shouldn't be too difficult. I haven't done much teaching and could write a short list. Unfortunately, I don't think it would be very surprising to most people (just as this list probably isn't surprising to most math majors, since we've all made at least one of these "stupid mistakes" before, even when we knew better, especially in the early years. The difference -- and this is reiterated several times -- is that good/smart students notice their error and debug their math/program, instead of just going with it or fudging their result).

Here are a few:

* Not actually thinking of a solution to the problem before starting to write a program; not soliciting requirements.

* ALL of the mistakes covered by this article. Struggling CS majors are often (not always) really, really horrible at math, and this -- more than anything else -- really holds them back from writing correct programs.

* Off-by-one and the functional equivalents

* Infinite loops in exception handling

* not enough input validation; too much input validation

* Reinventing bad versions of existing algorithms (Dijkstra's algorithm is a good example) and in general not enough research before implementation.

* The other side of that coin is taking stack overflow upvoted answers as gospel (basically our equivalent of trusting the calculator)

* Fundamental incomprehension of boolean algebra, which gives rise to all sorts of errors:

incorrect paren placement

Obscenely complicated conditions and/or absurd if conditions because they don't understand boolean algebra (e.g. I've seen conditions that eventually simplify to a || !a)

Complicated programs and grandois bug-hunting because they couldn't figure how a simple boolean expression (there was a post on HN a while back about Javascript == vs === where the developer basically wasted a day going down a rabbit hole he attributed to == vs === but was actually completely avoidable if he had taken an undergraduate discrete math course that hammered home boolean algebra.)

* This page contains a very useful implementation details section which describes some common errors implementing quicksort: http://algs4.cs.princeton.edu/23quicksort/

* As a general rule, any program written by a student containing concurrency is always wrong, unless concurrency was explicitly taught (many schools just have a short unit in a course or two, instead of integrating the topic throughout the curriculum).

First of all, your statement is meaningless. What exactly does it mean to "know math"?

Here's an alternative explanation: math students do lots of computations, and sometimes make mistakes which they would be able to identify immediately if someone told them "you made a mistake on this line".

Kind of like how all programmers occasionally drop a paren or a semicolon. Does that mean no programmers "know programming"? Of course not.

In fact, if you've never made a stupid mistake programming, odds are you're not a very good programmer because otherwise, you'd have done enough programming that one of these mistakes became inevitable.

The only difference is that most programming is simpler than university-level mathematics, so with a few decades of research we figured out how to use computers to prevent us from making a lot of mistakes without impeding our productivity too much.

For example, from the article:

"In fact, the great mathematician Leonhard Euler published a computation similar to this in a book in 1770, when the theory of complex numbers was still young."

So another way of wording your post: Euler doesn't know math.

Similarly, many of the examples (e.g. calculators) could be interpreted as students knowing too much math, and excepting their tools or others to know the same "math" they know.

No, it doesn't.

I thought this was clear from context, but: these are not constants. They are functions of many, many variables, many of which are probably shared; and probably also their dynamics are non-trivial.

For instance, changes to prices could be perfectly captured because all three variables are functions of price, and each of them probably has at least a first price derivative. I actually talk about this in terms of the model in my post, so I'm not sure where you got the idea that the model can't capture price change.

Also, demand for higher education is fairly inelastic compared to other variables within fairly coerce regions, so sacrificing fine-grained analysis of demand in exchange for more important variables isn't the worst exclusion.

> Although I contend that the two really aren't that different as government spending is just the aggregate of individual spending on government itself.

America has a progressive tax system, so this sort of aggregation argument is over-simplistic.

> You are suggesting that subsidizing something can make the sum total of all spending on that thing go down?

Yes, absolutely. Even operating from your premises, spending more can decrease costs.

In the case of no/low-interest loans, as long as the cost of defaults doesn't exceed the amount saved in interest paid to banks, everyone is spending less money on education.

Combining no/low-interest loans with increased state funding for education significantly decreases the risk of default.

So the "right answer" to minimizing spending is just a matter of simply arithmetic:

    C_f = Cost of state Funding
    
    C_d = Cost of Defaults

    B_i = Total money saved on interest payments (let's assume 5% rate with 20k load, probably higher if the entire market is unsubsidized) 

Then we want to maximize B_i - C_d + C_f.

Since we have some amount of state funding and some subsidized loans, it's entirely plausible that increasing C_f could decrease C_d, because the loans are smaller and therefore risk of default is lower. Furthermore, decreasing C_d increases B_i since higher-interest unsubsidized loans will meet the new demand.

Of course, there's a degenerate optimization: you can always just have zero subsidies. Most first world countries rightly give a shit about educating the non-independently-wealthy.

But also:

    * I don't think "minimize cost" is a wise philosophy wrt education. Nations that do this tend to be sucky places to live/work.
    * America has a progressive tax system, so the aggregate reasoning of your first response is at least disingenuous.

This premise is also faulty; this isn't the calculus of most consumers of higher education. The calculus is more like "I need a college degree to get where I want in life. Period."

> I don't see the logic of both complaining that we spend too much on something while at the same time advocating more subsidies for those who want to borrow to buy more of it.

"we" the government, or "we" the individual consumer? It's possible for the individual to spend too much money on something precisely because the government isn't spending enough.

> I do think, as we look at the for-profit sector, there are a lot of best practices there. The support systems they’ve had, the student tracking. The way they use capital assets.

This presupposes that these aren't present in the non-for-profit sector, which in my experience isn't the case.

And if we're going to use outcomes as a measure, it's clear for-profits are absurdly dysfunctional. Except:

> The way they take a much tougher cohort of students, on average, than most institutions.

The "we take on more difficult students" line makes no sense. With failure rates so high, it's not at all clear that they're doing anything other than taking on more students, failing those students, and thereby generating unnecessary debt and pocketing the federal grant money.

More-over, favorable analyses of for-profits almost always compares for-profits to flagship state schools or private non-profits, ignoring the class of institutions most similar in terms of prestige and quality -- local and regional state-run colleges and universities. Which are -- in my experience -- similarly prices and vastly superior in terms of learning community and outcomes.

> And, so, while there are certain practices that are not good to adopt there, seeing the challenges they face and seeing the things the way they have done well, bringing that into all of education, will be important.

Yeah, but it's kind of a tautology. "Good practices are good".

Anyways, I'm interested in specific examples. Because I really don't see any innovation per se in private higher ed. It's all stuff everyone else has been doing for decades, but with more marketing and unfounded claims to novelty.

> I don’t believe that a measurement system should simply apply to them and not apply to the broader universe. And, getting those things right is very, very difficult.

Yeah, I'll agree that performance-based funding structures don't make sense in education generally, and make even less sense in higher ed.

That said, it's kind of a misnomer -- if laws end up looking like what's been proposed so far, private institutions will always have the option of not taking federal grant money or subsidized loans.

IF performance measurement takes hold -- which it shouldn't -- I don't understand why the public should be expected to subsidize a for-profit industry and not have carte blanc to regulate. If you don't like the regulations, don't take the subsidy.

> Ok, http://www.iqcomparisonsite.com/occupations.aspx

Ironically, software engineers aren't even listed here except for in an aggregate group (possibly many) which undoubtedly includes many other occupations.

It's pretty lucky I don't make sweeping generalizations about your intelligence based upon a single data point :-)

Just to be clear, negative stereotyping "backed" by statistics is still wrong. There's plenty of scientific evidence "justifying" racism. Even if that scientific evidence were completely correct, racism would still be morally abhorrent.

> Doesn't feel like anything at all

I think you've profoundly missed the point (point: empathy).

Anyways, when your hobby project is upheld as fantastic research by physicists and leaders of national labs, you can be condescending toward other occupations.

end troll feeding

> if the student had done some rote learning of algorithms, they wouldn't have come up with 1.5 at all.

When you see "7/12 is 1.5", is your first thought "one sec, let me calculate that and see if the answer is correct"? Or do you just know, without any computation, that the statement must be false?

If you understand division, it's far easier to explain why this answer is wrong without appealing to an algorithm than by appealing to an algorithm.

And besides, the very example we're discussing proves this isn't the case!

The student was able to use the algorithm correctly; his error was at the boundaries of the standard algorithm -- correct input and interpreting output properly.

Simply practicing arithmetic will not prevent you from ever making a silly (or not-so-silly) mistake. Rote practice of the algorithm without also acquiring an intuition for the meaning of division won't help.

With correct guidance, practicing the algorithm can help students form this intuition, but that requires an a priori realization that we need to teach something other than just the rote algorithm, even if we teach it by discussing executions of the algorithm on specific inputs and outputs.

Immediately means "without executing an entire algorithm".

> Can you provide some evidence regarding intelligence of truck drivers?

Sure. This very article. Some non-truck drivers were apparently pretty impressed with the truck driver's book:

The review, written by the eminent atomic historian Robert S. Norris, began, “For many years, Coster-Mullen has been printing his manuscript at Kinko’s (adding to and revising it along the way) and selling spiral-bound copies at conferences or over the Internet.” Norris clearly considered Coster-Mullen’s understanding of the bomb superior to his own.

My own copy of “Atom Bombs” soon arrived in the mail, along with a sheet of testimonials from Harold Agnew, the former director of the Los Alamos Scientific Laboratory, who was aboard the Enola Gay when it annihilated Hiroshima (a “most amazing document”); Philip Morrison, one of the physicists who helped invent the bomb (“You have done a remarkable job”); and Paul Tibbets, the commander and pilot of the Enola Gay (“I was very much impressed”).

Incidentally, can you provide some evidence regarding the intelligence of software engineers?

See how that feels?

I think "type safety" is one of those things that's so well-defined in theory that there's always a huge disconnect between people who know the theory and people who don't. Therefore, I always like to explain the "progress + preservation" view whenever describing type safety, because it illustrates the term really has a pretty precise meaning at least in the simple cases.

In the simplest case, think of your 'interpreter' as a program that translates programs into values. For example, 1 is a value and \x.x+1 (the lambda expression) is a value, but (\x.x+1)1 is not a value because it evaluates to 2 (or, at least, to 1+1).

Let's say that your interpreter does this a single small step at a time; so for instance, if you have* f(x,y) = x+y, then f(1,2) |--> (x + 2)(1) |--> (1+2) |--> 3.

Type safety goes like this: If x has type T then either x |--> x' or x is a value. Also, if x has type T and x |--> x' then x' also has type T.

The first property is "well-typed programs don't go wrong" and the second property closes a loophole ("if you're a well-typed program, then you're never going to evaluate to anything that isn't also well-typed", so we never escape from the first property by evaluating)

* using the product syntax because some people will get confused by f 1 2, but that's in fact what I mean.

Another committee of scientists -- another IRB board -- probably would have not allowed the study.

Therefore, the parent's appeal to the IRB process as the harbinger of ethics is misguided.

If any IRB would deem a study ethical, then there's probably consensus among the scientific community on the cost-benefit tradeoff of the study. If one IRB deemed the study ethical, and if there're probably a lot of other potential IRBs that would not, then appealing to some sort of scientific consensus on the matter is a misnomer.

> Next step: Buy good shoes and convert some of that walking distance into running distance

I highly recommend going to a running shop and getting fitted. They'll watch how you run and give you the correct sort of shoe. If it's a quality shop, they really aren't trying to up-sell you or anything (most high-quality running shoes are about the same price anyways).

If you have the money, you can buy the shoes there too (I would feel guilty if I didn't, but that's just me). Otherwise they're typically 10-30 dollars cheaper online.

The #1 item on Aida specifically mentions breaking backward compatibility is an option.

The #1 item on Don Giovanni is "clean up syntax".

> I could give a trivial example

Please do, because this thread is hard-to-read deep and the only examples you've given were discussed at length in other subthreads before you even posted them.

> but do you mean the material advantages for you, or for some other person?

I would prefer "here is a problem" and then "here why bitcoin is the best available solution to the problem".

Rather than the more common "here is a problem" and "here's a way that bitcoin could solve the problem", and then completely ignoring hundreds of other less-complicated, safer and some-times even already well-established solutions.

Or solutions that are actually just ways to circumvent regulation, and probably aren't legally sustainable or financially scalable (see post #1).

> I wouldn't be so presumptuous as to insist that bitcoin must be good for you personally.

If you re-read my original post, my reasoning is explicitly selfish. The reasoning goes "I want X to happen because that's best for me."

> but then you've dismissed all other people's possible pleasure at bitcoin's growth as being purely politically motivated[2]

Um, yeah. In the post I'm responding to, you started with the assumption that bitcoin is good, and then reasoned from that assumption that we should use bitcoin in specific circumstances while ignoring arguments that it's not the best technology for addressing those specific problems.

But this reasoning is really silly. Because then every time I point out there's a better technology for solving problem X, you say "yeah, but Bitcoin solves lots of problems! So if we use it as the solution for X, then there's more adoption and we solve all these other problems."

But of course the only "other problems" you've mentioned all have better alternatives. And if even a significant portion problems have much better alternatives, then your argument falls apart and becomes "use bitcoin for X because bitcoin is inherently good", which is a political judgement and not a pragmatic judgement.

> From your comments here, you do believe that, I think?

I think bitcoin-as-exchange-medium is reasonable.

I think bitcoin-as-a-currency or bitcoin-as-money per se is not workable, or at the very least is a solution in search of a problem.

> Is that really how you feel?

If it were, I simply wouldn't read bitcoin stories.

> I think you've made some very broad assumptions about cryptocurrencies, which differ from reality somewhat.

What are the material advantages to using bitcoin for anything other than as an exchange mechanism?

All of the pain points of the modern banking system you and others have proposed are mostly about currency conversion and sending money across international borders, and my original post addresses what I believe the likely outcome for this use case is (although, see the thread with baddox as well).

I didn't claim you cannot use bitcoin in other capacities. I just stated the extra intermediate currency doesn't make any sense because there's no competitive advantage to existing (safer) mechanisms. Maybe I'm missing something?

> I've tried to explain how I think reality is more nuanced than these assumptions.

What would really convince me to let go of this assumption is a compelling reason to use bitcoin as money.

I absolutely agree.

edit/justification: given the length of this thread and other interactions, I think this 'agree' post is a non-trivial recognition of consensus on a point rather than a non-contribution.

> In other words, the costs of making mistakes is internalized. I think externalities are a bad thing.

"undo" is a pretty important, nearly mandatory feature for a transfer mechanism. Especially if you're talking about large sums. And we've known how to do it at scale since the 70's.

> Insurance and regulations (and by that, I assume you mean government regulations) are not the same thing.

Both create transaction costs, and those costs become significant at scale. edit that's why I group them together.

> How's that?

Firm holding my BTC or handling my transaction makes a mistake, is hacked, etc. If my money is tied up in their system when this happens, too bad for me.

> What do you mean by that?

Only that escrow is not unique to bitcoin, and you can escrow other currencies (or anything). One of your grandparent comment's argument only makes sense if escrow is unique to bitcoin.

> Maybe that's where we're talking past each other.

I think we are :-)

I was referring to legal regulation and oversight, which is there for very good reasons and is the primary reason most banks/cus have someone whose job includes handling international wires. But also, talking with someone who really understands the legal and financial landscape before firing a few grand off to another country is enormously helpful (but not worth the $60 per xfer!).

I agree there's fat that could be trimmed, as well as just unnecessary charges for the sake of making money off of market position. But for me, the best case scenario is getting rid of that without the extra intermediary. But really, I suppose if the crypto currency is mostly used for bank-to-bank, I don't much care about the back end as long as it works and it's cheap.

edit: I'm not sure what got touched, random bits needed improving.

I thought through this some, and your comment resonates -- it's not right to set aside scientific code from other code with a complicated domain.

But I think complicated program segments related to business practices etc. also deserves comments, even just "see spec xyz" or "see section 1.2.3 of code xyz" (similar to how you might say "See Smith et al. '14" in a scientific setting)

> I'm not conflating them, they go together.

No, they really don't.

> Cryptographically secure algorithms are better than goons with a printing press.

Again, technology cannot solve political problems.

There are two scenarios: the government provides a cypto-currency to provide its practical advantages, or a private currency overtakes usd.

If the government proves a crypto-currency (not terribly likely, but the more likely of the two alternatives), then probably it would retain the same amount of control it has now. Technology cannot solve political problems.

The latter presupposes the government wouldn't shut down the currency and that there's political will for your preferred monetary policy anyways. In which case technology didn't solve a political problem, politics solves a political problem.

Anyways, I prefer my democratically elected "goons" to an algorithm chosen by a small group of people.

That's an interesting hypothesis about why the dominant rhetoric has changed.

I think another one is that people are starting to use bitcoin for real-world use cases, and finding and addressing specific pain-points is far more likely to generate revenue than trying to convince others of your take on monetary policy.

edit: TL;DR: I think the only interesting non-technical discussions about Bitcoin start with a specific use case. We should latch on to technological solutions because they solve problems, not because we agree with the dominant ideology of early adopters. Setting aside politics, if the problems Bitcoin solves are easier and cheaper to solve with a simpler solution, then we should use the simpler solution.

> Bitcoin is not necessarily an 'intermediate' currency

I mean, I started my post acknowledging these claims exist.

So, you can interpret my comments as "suppose that the only justification for bitcoin is its utility as a transfer medium..." and leave political discussions in other threads.

edit: also, this is totally appropriate for this thread, because in most states of the US, actually paying employees in bitcoin would not be legal and employees would need to convert back to usd to pay taxes, rent, food/bar tabs in most situations, etc. So, USD -> BTC -> USD is pretty clearly the intended use case for this product...

> if a person receives bitcoin and a store

The problem with foreign currency conversion isn't small amounts of cash for consumer transactions, at least in my experience. I can convert currency by using an ATM without thinking about it at a reasonable exchange rate, and the fees are often lower than what I would pay in the U.S.

Ditto for online services, but even more so.

The problem is larger amounts of cash, or transfers to third parties you won't visit in person. Queue discussion below.

> A person who receives Bitcoin in the US actually already has a huge variety of products and services available, without converting to fiat.

> or a company like Bitwage builds some other part of the ecosystem, bitcoin becomes a little more useful.

I suppose this is all great if you want to use bitcoin because of your political persuasion.

I'm -- and I suspect most people in the world are -- more interested in the actual underlying pain points than broad-stroke discussions which invariably ground-out in political, ideological discussions about monetary policy.

Ostensibly, personal opinion on national and international monetary policy isn't the best of standards for choosing a payroll provider. edit: also, that's where companies are focusing. For the obvious reason that political selling points, aren't.

And more importantly, that's not how this product sells itself. Nor should it.

It's uninformative to conflate monetary policy with the underlying material/technology used for currency. The two are totally and entirely unrelated. It's like claiming that changing from paper to (still fiat) coins is good because this would cause a fundamental shift in the nation's purportedly destructive monetary policy and also paper rips which is a bummer. So coins > paper, clearly.

Which is to say, you are really making two totally independent claims. One is at least plausible and the other isn't.

The first is that bitcoin provides a viable alternative to current methods for exchanging fiat currency. This is probably the most sensible argument for cryptographic currency, and I think is worth discussing. The discussion below delves into some specific arguments on this issue.

Your second claim is that decentralized cryptographic currency will or ever could/should replace state-backed fiat currency. I don't think this is a particularly useful point to discuss, since informed prediction is impossible and the prescription mostly amounts to political persuasion.

edit: but also, the US could switch to a cryptographic currency with all of the practical benefits of bitcoin, and still retain basically the same amount of control over its currency. Technology can never solve big political problems.

Thanks, that's a perfect analogy.

> BTC don't need regulations.

Yes, it does. For the same reason that any other mechanism for transferring arbitrary sums of money across international borders needs regulation.

(It's also worth mentioning that I "bank", even international, with a small local credit union. So your choice between huge abusive banks and BTC is false.)

> which has been solved more efficiently in the Bitcoin network.

Except bitcoin hasn't solved the problems with international transfers. Bitcoin's just ignored them. There's a huge difference, and I don't think ignorance is sustainable at scale.

> There is a tangible economic cost

I actually lose a couple hundred usd a month right now. So, I really do sympathize.

> I think what's more likely to happen is that, long-term, banks will either converge around using a blockchain-based mechanism of some sort to transfer funds

Maybe. That would be fine with me. I'm not really sure I understand why banks would do that vs. just using social processes, since those processes still need to exist in order the address the problems with international transfers and have been around a lot longer than bitcoin.

> I think calling it a cottage industry is extremely short-sighted.

I mean cottage industry in the most literal sense of the term, and was referring to the present and historical situation. And I think that's fair -- very few people are employed full-time doing BTC-related work, and I don't imagine the profit margins are insanely high (or even non-red in some cases).

Strawman.

I'm not advocating for large banks, and even specifically mention non-bank fiat->fiat cash transfer companies as a viable and even more likely alternative to BTC.

> There is no reason why banks cannot use BTC

Yes! Exactly! Bad Things Done By Banks is only an accidental benefit of BTC.

If BTC becomes regulated and banks are the better equipped to deal with these regulations, then BTC becomes dominated by banks or de jure criminals.

Financial scandals and banking reform are primarily a social and legal problem, and cannot be solved by technology.

> There is no reason why the payment processor can't implement some security in case of errors.

Sure, and banks already do that. A lot of it, in fact.

My point wasn't that these things aren't possible with BTC. Rather, my point was that these problems don't go away just because you're not using a traditional currency. Which means the overhead associated with these problems doesn't go away, either.

It's just that BTC is really small right now, and so the cost + difficulty of addressing these problems at scale isn't yet apparent.

> with credit cards you are handing out your details every time you do a purchase.

(1) No one makes payroll with a credit card; (2) BTC transfers -- especially at scale -- aren't as fast as CC transfers without someone assuming some risk; (3) CC companies basically exist to assume that risk and mitigate; (4) if you're going to design a new payment processing technology appropriate for POS transactions, creating a new currency is absolutely not necessary.

> In a BTC economy

Well.