lliwta

What general techniques are you using? Perhaps another way to put it: which Wikipedia article is most related to your methodology?

This is the most clever comment I've read on HN this week.

It's just like having to systemically lie about or not mention any other part of your life. We all do this about a variety of things every day.

Do strangers come up to people and ask about their religion, and is the problem that you have to lie? There are certain situations where it can get awkward. E.g. if a boss or friend asks which church you attend.

I usually just elaborately lie and say I'm religious but "can't find a church I like".

That's actually pretty easy for me, because I grew up in a religious house and understand enough christian theology that I can pick something about any given church and maintain internal consistency in my complaints.

People sometimes think I'm pedantic, but usually don't know much systemic theology or church history, so I can just escalate the discussion to a point where they're unsure of themselves and come out looking a bit pedantic, but at least religious. They get to feel smug about the "emotional depth" of their belief, and I get out of the conversation without having make any dangerous lies (e.g. saying you attend a church you don't... bad idea).

That's way easier for me than the alternative, which usually involves an annoying and endless litany of invitations to the person's church or their friend's churches.

and it's kind of a social taboo to even bring it up during dinners etc.

It's not formally acceptable to ask in a work setting, but depending on the part of the country, it's often informally acceptable (not talking about church-related things would be kind-of akin to a "no personal conversations at work" rule for much of the south and parts of the midwest).

Do you have a point, or are you just being pedantic? That is, is there some essence of your position which I haven't adequately addressed? If so, what is that essence?

FWIW Your original statement is referentially transparent wrt the meaning of 'writing' an algorithm ("I specifically referred..."). You were clarifying what you meant by this phrase. So the substitution of your intended meaning into your original statement is justified; in fact, is the entire purpose of your clarification. Otherwise you're just giving a definition with absolutely no context or purpose.

Where did I say that the focus should purely be on programming?

If you'd be okay with teaching a CS course without programming, we might be talking past one another.

I do not understand, and there are four statements, not two.

I'm confused. Maybe you posted the wrong link?

Here are the two comments from the linked post:

If you cannot code, you cannot check that your ideas work out on a computer.

This is only true when it just reduces to "if you cannot code, you cannot code".

Taken literally, the statement is just blatantly false. You could use a computer to figure out properties of your algorithm or for designing an algorithm without actually implementing and running the algorithm; e.g. for getting closed forms of sums, or for finding/verifying the convergent behavior of a series which the algorithm relies on.

So the statement really is only true if it's a tautology.

I don't see how that relates to my comment, I specifically referred to 'writing' an algorithm, as in implementing the algorithm in code, not devising the algorithm in the first place.

'writing' an algorithm = implement the algorithm in code

So, substituting into your original statement:

"I fail to see how you could implement the algorithm in code if you don't know how to code."

which is a tautology.

Both of the statements in that link are just tautologies...

You can teach computer science without teaching coding. And you can write algorithms without testing them on a computer.

So the tautology that "you can't code if you can't code" isn't a particularly important pedagogical insight when it comes to teaching CS, since CS != coding.

Of course it isn't a stumbling block, logical thinking is required for both, which would also explain why they are both difficult.

Right. And I'm saying that, in my experience teaching, it's better to teach CS and then let programming be something that kind of just falls out of that naturally, as opposed to focusing on programming itself.

These are extremely superficial reasons to criticize git

They are use cases which matter to the author. That's basically the opposite of superficial.

If you want a single folder within a repo, why isn't that folder its own repo?

The author addresses this -- because the folder is not significant enough to warrant the overhead of placing it in a separate repo.

No one is denying the notion that coding can be helpful when writing algorithms.

But it doesn't follow that programming a machine is necessary for writing algorithms.

The machine can be and often is as much of a distraction as it is a tool when teaching CS.

Why is that surprising?

The problem isn't that everyone doesn't learn it, but that noone learns it.

It wouldn't be a big deal if the elective were available but not taken by everyone. The problem is that in most cases, there isn't a programming class. Period. Ever.

"why aren't we teaching children how to grow turnips?".

Why wouldn't we want to teach kids the basics of gardening? I was taught in elementary school, as part of our unit on "Biology" in second and third grade.

Harold Abelson, yeah? I was wondering what an assembly programmer would say to this.

Taking my comment within the wider context of the conversation, and the general conflation of "writing an algorithm" with "copying down into a programming language from existing pseudocode", I like to think most notable computer scientists would agree with the sentiment that we should be prioritizing the teaching of algorithms over the teaching of programming.

edit: Most importantly, no one is claiming that these two are somehow mutually exclusive. Only that the latter should be in service to the former, and not the other way around.

That is, when teaching CS, we should teach concepts, and include instruction on how to implement programs because it's a useful tool for learning CS. "Turtle Geometry" is a fantastic example of this, BTW. The focus is on the concepts, with programming as a tool for understanding them. But -- to the refutation of your core argument -- it's definitely never insinuated in TG that the ideas don't exist independently of the programming. Such an insinuation, that geometry does not exist independently of a programming environment, is as absurd as the notion that algorithms can't be written without a machine.

But anyways, your initial claim was that you need to be able to program in order to write algorithms. Which, aside from your highly non-standard use of the phrase, is just clearly not the case.

Also, of course programming has its own set of hurdles. But there's a difference between writing highly optimized assembly and copying an algorithm into Python.

Getting someone to put themselves 'in the shoes of a computer', is just as difficult.

In my experience teaching, this isn't the case.

If you can teach the student to think precisely and unambiguously about a single algorithm, the unrelenting logic of the machine is no stumbling block; quite the opposite, actually.

It's far more effective and less degrading than having students fight with the machine and get confused about why it won't "do what they want it to do".

(this comment was massaged, sorry for the edits.)

My point was that "copy an algorithm into programming language X" isn't something which needs to be taught in the first place, and isn't an economically valuable skill because literally anybody can be taught this skill in a few weeks.

If I had to choose between teaching why an avl balanced binary search tree works and forcing students to implement in a chosen programming language from pseudocode, I would choose the former every time. The intellectual maturity is far more valuable -- and harder to acquire -- than the rote skill.

But without the notion of "programming," you're missing an entire style and class of algorithms.

And if you focus on programming, you miss the forest for the trees.

You can teach CS without teaching programming, and it will still be valuable.

You can teach programming without CS, but the skills you end up teaching will just be skills -- they're non-transferable and aren't going to be useful in 10 years.

Generally, algorithms are described in terms of pseudo code using programmatic language as well as terms of set theory or graph theory.

I think the latter semantic descriptions are almost always the more important ones.

Not the algorithm, the data. Anonymized user ids and their votes, together with relevant meta-data.

I suppose the fact that there's already a detection algorithm biases the data, but it'd still be better than nothing.

It's easy to find people who could create an algorithm but can only target a specific architecture, human grey matter.

"Programs should be written for people to read, and only incidentally for machines to execute."

The key difference is that if the skill of implementing an algorithm in <insert programming language> code can be learned in a few weeks max. It's a matter of whether you've bothered to learn the skill, not whether you're capable of learning the skill.

Learning the problem solving skills to create new algorithms is not so trivial, and often can't be self-taught.

Computers was an available subject in the nationwide standardised exams

This would certainly help.

If you cannot code, you cannot check that your ideas work out on a computer.

Believe it or not, it's possible to write provable correct algorithms without writing a single test case :-)

Of course implementing is a useful sanity check. But it's not the important part -- it's not the skill set we should most emphasize in education.

as in implementing the algorithm in code, not devising the algorithm in the first place.

Is there a particularly pressing reason to teach students who to translate pseudo-code from Wikipedia into <insert favorite language>? Sounds like a perhaps useful but pretty menial skill to me. Not the sort of core skill you'd organize a curriculum revision around for sure.

Well, a committee of scientists that know better than you think results will be worthwhile and disagree.

The article stressed that green lighting the research was a hugely controversial decision. I'm also pretty certain there are a huge number of scientists who do research on animals are wouldn't be comfortable with this research.

Also, I think the parent was rejecting the deontological framework in which the decision was made, rather than calling into question the resulting calculation by the ethics board. So an appeal to the expertise of the panel doesn't make much sense.

> In the general case, it's really easy to detect

Why do you say that? I've worked hard on this problem and would not call it easy.

Are there reference data sets for this problem? If not, you or reddit should publish data sets.

I might be completely wrong in generalizing but haven't the schools in US picked up on this trend?

There are lots of reasons, but I think the largest contributing factor is that these teaching staff doesn't exist.

In most high schools, there is no dedicated "programming" or "CS" teacher. Often these courses of off-loaded to a business-y person. In my experience, these were pretty useless and sometimes worse than useless. E.g. in one case this person was a retired math teacher who was tenured but awful, and "computer class" seemed like a low-impact place to put them.

If a Math or Science teacher wanted to teach a programming class and had been around for a few years (and got along with their administrators), they could probably get away with teaching one section a year. Maybe scale up if there's demand and the department isn't under-staffed. But that's fairly rare, because lots of math people don't really "get" CS.

I fail to see how you could write an algorithm if you don't know how to code.

Algorithms have existed for centuries. Computer programs have meaningfully existed for 100 years, if we're generous. And for a lot of that time, you had to design the entire algorithm correctly before running to code, or else you'd have to wait a day or two and try again (unless you were important).

Even today, if you're designing a truly novel algorithm, you're very likely to spend the bulk of your time not coding, and then coding only at the end as a sort of check to make sure you ideas work out. Of course everyone has different processes and YMMV, but mt general impression is that most people who design significant (read publication worthy) algorithms do the bulk of their work away from the keyboard.

And honestly, having taught high school cs students, the best students have this process: 1) try a niave solution, notice it won't work before they even compile. Maybe finish the program just to confirm their suspicion that it's wrong; 2) go to the white board for a while, and probably talk with their friends about potential solutions and pitfalls; 3) design the algorithm, and then code it up. Usually there's no pseudo-code before they start programming, but they have a pretty clear idea of the general structure of the algorithm; 4) test on inputs that they identified as reasons the niave solution(s) discussed at the board didn't work.

edit: the very worst students are the ones who sit in isolation hacking away at iterative improvements on a fundamentally flawed idea. Usually they're trying to get their for loops sorted out and working correctly so that the program actually gets around to giving them any answer, and don't even get around to noticing their solution is completely and fundamentally broken until the end of class.

Which is to say, from my observation, coding-as-problem-solving is not very effective until after you've thought things through in more general, mathematical terms.

Certain parts of software engineering research are moving in this direction, psychology as a the primary toolbox for research.

Not sure how I feel about that. As far as science goes, Psychology isn't exactly the epitome of rigor. On the other hand, the problem really boils down to asking hard-to-investigate-scientifically questions, mostly about humans.

could be sumarised by saying many suburbs have taxes that are too low

In some areas of Minnesota this could most certainly be the case.

I think that making a consistent experience absolutely destroys the unique culture and history of places

To be fair, the unique culture of the place used to be "industrial farming corn field" is most cases. It's not like anyone is tearing down 100 year old neighborhoods to build big boxes to serve suburbs (actually, the suburbs are far more likely to save those places than destroy them).

For me, this is the biggest difference. When I live in a city, I know my neighbors just because. Running into each other on the bus turns into a beer and a long chat.

In Suburbia, you know a lot of your neighbors, but there's almost always some sort of reason or structure. The social network is the same size, but lots of those relationships are somehow not intrinsic (which isn't to devalue them, even comparatively, but imho there is a qualitative difference).

The latter works great for family life because there are so many more structural incentives to interact; the former is probably preferable for younger or non-child-raising people.

That I might find out one of my neighbours is a kidnapper?

The far more likely scenario is that you find you have some common background, and waste an evening relating stories that you would probably never dredge up again otherwise. The world really is a surprisingly tiny place.

I don't like to talk to everyone I meet or even be in a city for too long as it overstimulates my senses.

It takes all kinds :-)

I generally agree, except that the not being able to get around without a car bit is really True in my experience.

edit: It's easy to know your neighbors in suburbia if you're outgoing, and things vary from street to street. But there generally is way less interaction than if you were to have a neighborhood pub at the end of your street, or side-to-side porches everyone lounges on during summer nights.

It tends to be that you know the neighbors you get along with and ignore everyone else. In city environments, it's more like you interact with everyone because, well, no choice.

and two car starts?

That's a great way to have your dinner interrupted or end up waiting forever for your car.

* Most 'traditional cities' couldn't be built for anywhere near the same cost as a modern development.

Why is this? E.g. The author points out that narrow streets should be cheaper to build and maintain.

I grew up in suburbia, lived in a typical American city, and now live in a traditional city abroad. My best guesses as to why building a traditional city is more expensive are 1) construction might be more expensive because of the constrained space; 2) lots of roads are cobble stone rather than pavement; 3) maybe infrastructure (e.g. fire hydrants etc)

Are there other more important reasons? I really can't figure it out.

It's possible you under-appreciate the amount of nuance in the underlying theory on fascism which the author is extending. Even though the author avoids mentioning who he's extending, anyone familiar with the literature on fascism knows immediately.

That theory can be dense, and this is by far the best description I've seen which is simultaneously accessible to someone unfamiliar with the literature, and also doesn't compromise on correctness.

It comes down to whether you consider not compromising on correctness important. Unfortunately, the norm in journalism is to tell the most neutered version of the story possible, correctness be damned. You can see this in most science journalism. So when someone puts the effort into a piece like this -- which explains ideas in lay terms but does not throw out correctness to the point of rendering the description of the work meaningless -- it mostly passes unnoticed as "a bit too dense" or "not TEDy enough".

Thanks. That's hilarious. If I ever decide to kill a man, I guess I now know where :-)