skysight-inc/HackerNews huggingface dataset:
Part of the reason DQ was "well received" initially was because at face value it appears as though it's for a cause. Plus, (as mentioned by Gamergate) there's an unwritten rule about criticizing anything even remotely appearing "progressive."

It's not hard to find overwhelming posts pointing these facts out: https://www.reddit.com/r/OutOfTheLoop/comments/2dw9hh/why_is...

Any the cherry on top is your last line. "Suspect" Once again, either people are forced to cave in, or otherwise be "suspect" or "problematic" or "misogynist" or just the bad guy.

Am I not allowed to point out the simple fact that DQ has no scientific educational value and as such does not belong on that list? If so, why am I not allowed to state this simple truth? Because it's inconvenient?
You can do it too: https://github.com/shinnn/isogram

Web version: https://isogrammer.com/
On the road: tech tools for summer travel
> Well, I can see that's a factor, but not necessarily an overriding one. As someone who's taught at uni myself (not pure maths) we are not usually that cynical or fond of serving up "detritus". It's not as if we lack for valuable and interesting stuff to teach if we go through foundations too quickly, and we aren't paid just for teaching. Anyway, I think most do benefit from a quite painstakingly incrementalist approach to maths; me taking that too far and sometimes getting stuck is a personal failing.

Possibly so, but I never went in any of the grad programs. Most of the lower classes are taught by AI's and contract-based "instructors" paid by the uni on a per credit-hour basis. And much of the time, the department shovels the syllabus and required areas to them for the students.

And unfortunately, this avenue of teaching very much shows. You have instructors who have some semblance of caring, but not terribly much. They teach weeder classes with the intent of failing much of the class. Whomever is teaching isn't always able to explain what's going on in an area - they can do the process, but can't explain why their actions work.

Perhaps it is a jaded viewpoint. But after spending way too much money in "Higher Ed", along with working at an institution, I know the game. And I'm sure it's better if you're a post-doc with prestige or on that track. But the rest of us are spoon-fed bland crumbs these days, and pumped-and-dumped for excessive scholastic loans to get a job to pay the loans back with.

> If you go to a good uni, at least by postgrad level you do have that kind of access, and, if you get along, you retain it for free after you leave.

Yep, and if you're not on that track, the access isn't there. I'd be willing to pay for it directly. Google had a program quite a while back, of paying experts for direct guidance in specific fields. Too bad they cancelled it.
Sure, let's roll with that.

How would you write a function parameter that takes two arguments, whose type is determined by the seed argument?

Also, with reduce, the return value of the function can determine what the type of the input arguments should be. For example if you pass in a `(fn (x y) (list x y))`, you end up with:

> (reduce (fn (x y)
(list x y))
(list "a" "b" "c" "d"))
("a" ("b" ("c" "d")))

Let's throw in a print statement to print out the `y` parameter:

> (reduce (fn (x y)
(print (str y))
(list x y))
(list "a" "b" "c" "d"))
"d"
("c" "d")
("b" ("c" "d"))
("a" ("b" ("c" "d")))

So `y` starts out as a string, then a list of strings, then a list whose first element is a string and the second element is a list of strings, and so on.

I'm not sure what the type of that function would even look like. And if there's no way to express something as simple as `reduce` without resorting to `f: (x: Any, y: Any) -> Any`, are we certain it's good design?
Is Kotlin the New Java?
> Anyone else dislike the immutability fad? [...] Sometimes I just want to create a map and mutate its structure, and the language saying "no" is constraining me in an unpleasant way.

Immutability does not prevent you from incrementally creating new versions of a map! At this point, you are conflating no less than three different and orthogonal concepts:

A) A convenient way to write code that incrementally creates new versions of a value. This is trivial in most languages using immutable values, but it often requires unfamiliar idioms, giving people the false impression it cannot be done.

B) A performance optimisation that performs such local incremental updates in place. This is a real concern. Any immutable-by-default language should support a safe (!!) way for the programmer to ensure updates happen in place.

C) A mechanism whereby new versions of values can be distributed to other parts of a program. This one is tricky as all hell to do safely, and most good solutions work just as well with immutable values.

"But kqr, why did you take something so simple and made it so complicated?"

It was complicated from the start. Traditional languages have just ignored this complexity and solved it in an "undefined behaviour" sort of way: let's just do wha the metal happens to do, however unsafe!" You'll note tha such languages have no way to do safe in place updates, and value propagation is never sychronised or otherwise guaranteed not to cause partial views. It's a low-level hack that's far outstayed its welcome in the age of huge systems with all sorts of interaction effects.
TDD never worked for me, I believe because of the nature of my work: research code, very explorative in nature. I do not now in advance how the interface will turn up, so it's hard to anticipate the interface in my tests (or it leads to a lot of wasted).

Nowadays I mostly test with "redundant random generation testing": generate random but coherent input, run logic, then... Either I can reverse the logic, and I do that and verify that I get back the original input. Or I can't and then I simply write a second implementation (as simple as possible, usually extremely inefficient). This finds bugs that classical unit and integration testing would never find.
I frequently get to watch Red Tailed Hawks in Downtown Dallas floating brilliantly on the air pockets. Big birds.

http://dfwurbanwildlife.com/2011/12/21/uncategorized/red-tai...

https://lh6.googleusercontent.com/-kE6nP4Cogvs/VMb9uqWxgaI/A...
I don't understand this idea you're putting forth. Well actually both ideas.

1. That there is a high risk here.

2. That the outcome could be bad.

Neither of these seem true. I dislike Python the way I dislike wearing shoes that stealing too small, but I don't regret learning it. I regret working in it more and more over time.
Helping journalists tell stories with data
The forty years of a teaching language comes with a cost: zillions of incompatible implementtions and a language which was designed for teaching, retrofitted with more advanced stuff on top which integrate not very well.

Common Lisp was designed early as a more practical language.

Take for example error handling: Common Lisp has a nice error handling system integrated into the language since the mid 80s. Scheme never had something comparable specified in its standards. Sure you can add error handling on top, but it won't be integrated well into the wider language.

There are many aspects where Scheme was underspecified for decades and efforts to redesign the core language were slow, controversial and not really providing nice results. Many Scheme designers wanted the language to be kept as small as possible (R5RS level). The R6RS design was controversial and R7RS 'large' is a very slow effort...

In many ways, Common Lisp is as a practical Lisp language better designed than the average Scheme and Racket is just another Scheme going in its own direction. Actually if you read the Racket docs, it is a very complex system.

One also could use the excellent Chez Scheme (which now is open source) or Chicken Scheme.

The ideas of Racket onboarding beginners is also confusing: multiple languages with some integration mechanism with various degrees of different features and semantics. Much of that is not really needed, but a nice experiment in language modularity. Added to that an IDE which favors batch programming for beginners... In a teaching setting it helps reducing side-effects ... each 'Run' is a new program start.
The speed of sound through air is effectively the speed of shockwaves through air. The way that the air responds to being pushed around at speeds faster than its shockwaves can respond results in something that behaves more like a liquid than a gas.
- read "starting strength" and get a weightlifting routine
- meditate everyday
- dont be normal, be you
- dont study what everybody is studying, study what you really like doing
- dont believe in fairness, but karma may be true
- read "the gervais principle" before stepping into a cubicle
- if you force yourself to never be an employee, in the long run you will make it on your own, just follow that rule
- learn about investing, yes you may lose money, but is not that hard to make money on it, and it turns out the way the world works is that you can be very rich without ever producing anything or working just sitting in a good investment
I like ruby's rspec and Rake. Very powerful.
You're right -- it takes a long time for most media companies to get off the ground, and it's often near-impossible to raise money in the early days. But how many youtube channels that get ~7,000 weekly unique viewers are able to convert ~1,200 into paying monthly subscribers?

Consider this: you might not already know everything there is to know about my business by skimming one blog post!
Blockchain and Renewable Energy Are Utterly Disrupting Society as We Know It
My day job is teaching TDD.

Just like other agile rhetoric I've found the benefits are not what the proponents advertise.

I teach it through pairing and here's what I find.

TDD provides two things.

1. Focus

Focus is something I find most programmers struggle with. When we're starting some work and I ask, "ok what are we doing here" and then say "ok let's start with a test" it is a focusing activity that brings clarity to the cluttered mind of the developer neck deep in complexity. I find my pairing partners write much less code, and much better code (even without good refactoring skills) when they write a test first. Few people naturally poses this kind of focus.

2. "Done"

This one caught me by surprise. My students often tell me they like TDD because when they're done programming they are actually done. They don't need to go and begin writing tests now that the code works. They like the feeling of not having additional chores after the real task is complete.
I'm picturing workers who have never spent time on wikipedia reading about nuclear accidents, much less in any books.

The list of nuclear accidents is hair-raising. The thought that a co-worker might assemble a near-critical mass nearby is... beyond hair-raising. Where the heck are they getting these guys, and what are they telling them?!
If someone can't pirate "X in a Nutshell", they'll pirate "Learning X". Either way, nobody is getting their money. No point losing customers over it.
This is something we're going to have struggle with as a society for quite a while -- the pervading reach of technology makes enforcement of privacy rights and constraints on government ever more important. I wonder if it can go all the way to childhood. I've tinkered with the idea of doing a children's book on privacy -- I think you learn about VPNs along with your alphabets haha.

In all seriousness, anything that helps people be educated about security in the digital age is a massive plus.
TDD is waterfall
If I'm worried about that, Chef is performing those tests.

I'm saying, you're putting it in the wrong place. It's not a monitoring problem, it's a configuration management problem--"I have defined a policy, am I in compliance with that policy?". And, from experience consulting with a pretty wide range of clients, putting it in the monitoring stack encourages manual work instead of automation. Instead of having active and self-correcting systems, you create passive and manually reactive ones. Monitoring is for stuff you have to react to. Automation and automation testing is for stuff you should never be reacting to.
> changing blade pitch

When the wind is blowing really, really fast the controller will change the pitch of the blades to prevent them from spinning too fast. Prevent that and it redlines, resulting in anything from worn parts to catastrophic failure of the structure.
right, but not everybody lives in the us. and of course, their spy agencies dont spy :P

it's also interesting hearing the outrage about russian hacking, and the outrage about the cia having the abilities to hack. I hope it's not the same people complaining.
As an Italian, I am constantly amazed by how my country's legislative initiatives are constantly misreported and misrepresented on HN.
Thank you for removing. It did not add to the conversation.
Show HN: This website finds for you the best way to learn a language
Developers are wrong about LinkedIn
A.k.a: no methodology will turn a coding monkey into a great developer. What a surprise :-)
Does it really matter if it's ethical or not? I mean, we're not talking about the ethics of, say, killing a tyrannical despot or allowing a terminal sufferer to commit assisted suicide. If it were me, I'd keep on collecting that paycheck while picking up a second job and double my pay. Again, is it ethical? No. But who cares? This person's mom is right, he has a free lottery ticket. Keep cashing it in. You can keep your ethics while I laugh my way to the bank. Just don't get caught :)
Lyme disease has been around Maryland for years. I have known people to get it in the DC suburbs, one in his own back yard, one in a park.

The US Park Service has culled deer in Rock Creek Park (Washington, DC) the last two or three winters. The neighborhood email list gets an invitation to join a candlelight vigil against this each fall. (No, I don't join.)
They want the regulations banning overland supersonic flight removed, and are trying to frame it as a fuel efficiency issue rather than the "we will make people's lives miserable with noise" issue that led to the ban.
Isn't the vast majority of the flooding danger due to climate change during storms anyway?
The radiation dosage section of that article is a mess and I think shows a limitation of wikipedia. The writers managed to not use the same unit in any two consecutive sentences and sometimes not even with in the same sentence and don't bother providing any way to relate the different units.
Secure and cheap please!

What you should be saying is that secure software isn't cheap, and management doesn't see a point in spending extra money
Don't Include Social Engineering in Penetration Tests
Turtl: A secure, encrypted Evernote alternative
I sometimes feel like the whole ORM thing hasn't made progress or been settled.

The object and relation impedance mismatch is not a new concept. The feeling of progress in ORM was just the act of bringing ORMs to ecosystems that hadn't had good libraries for it, introducing ORM to a generation of developres that had never used it, and improving the libraries.
I couldn't. There's plenty of actually interesting and useful articles cited here, and then discussed (esp. if you're a programmer, but there's lots of non-programming topics discussed as well).

I can't say the same for Facebook. At best, you'll see cat photos and videos, which are OK, but not exactly intellectual, and I can get that stuff on Reddit's /r/aww anyway. More likely, you'll see a bunch of insane alt-right-wing "news" and memes and conspiracy theories passed around by your dumb relatives.
This is an under-appreciated point. We've forgotten all the old hard Cold War lessons about escalation.

What we are seeing now is a huge expansion of deniable and proxy warfare. Everyone is still (I hope) clear that sending an actual tank division across the Polish/Ukraine border would be met with nukes. So the question is, what is the largest most damaging attack that can be carried out without reprisal, and how do the participants find this out?

And of course, the ultimate in deniable attacks is one carried out by the enemy's own forces. Did cyberwarfare crash a US destroyer into a cargo ship? (Almost certainly not, but maybe next time). SWAT-ing is already established as a tactic; could suitably forged communications or "fake news" disseminated via the President lead to the SWAT-ing of a country? There are some suggestions that this applies to the Qatar situation.
"A scheme to strong arm the adoption of BCP 38 is key to stopping these attacks from growing. IoT has shown us that expecting device updates to disable these UDP protocols is a lost battle."

Easily done: "Follow some standards and RFCs or get put on a global blacklist of companies to not do business with."
> The CIA doesn't work for me. It works for Americans.

Correction, it works to maintain the current status quo.
> The tests are an executable to-do list that guides development

So what generates the to-do list when you're building out the tests (arguably the harder of the two tasks, when the tests drive the design).

> Provides a record of the experimentation taken to accomplish a goal

If you're doing a proper refactor cycle, those tests will vanish (or change) as the code evolves. You're back to relying on your source control, which provides the benefit with or without tests.

There are benefits to TDD; these two are not among them IMO.
Reading automated tests and doing extensive searches in the codebase (with recursive `grep`s) is often helpful. If you use an IDE with a go-to-definition function, it can replace grep.
This inspired me to try harder with my learning of VIM: https://vimebook.com
or a stick. but you have to be pretty brave:
https://www.youtube.com/watch?v=6fGdZ-nu7zo
With SNI, what's the advantage of having a cert with 100 domains on it ?
How many millions... billions... would it cost to line all the roads? and then all the lost electricity due to inefficiency? All to give cars a little extra distance?

And then... when Road v2.0 comes out and it all has to get replaced? v3.0? Then flying cars and no one uses roads?
So they are as naive and shortsighted as they seem.
PBT-centric TDD has worked very well for us.
Regarding Focus, I have to agree mostly that pairing is amazing for focus. I've found that I never lose focus when I pair. And we almost always come up with better solutions when we think out loud.

Regarding being done, often this works for more cut and dry elements, which are increasingly more like boilerplate. But this doesn't hold up for what I nowadays spend most to my time on, which is UX and the experience of using the application.
I'd say a better summary is that TDD won't transform OK programmers into great programmers.
"Cyberweapons" should be treated like bioweapons: there should be a framework of international law to decommission them, because they are simply too prone to spreading on their own and too dangerous to civilians. The US does not have a defensive anthrax capability (I believe), because it's too much of a liability.
Gonna throw the baby out with the bathwater because bad programmers write bad tests.
I disagree with the assertion that TDD takes more time. TDD takes less time if you factor in the reduction of errors TDD helps prevent.

This article should be renamed, “TDD doesn’t work if you don’t do it right.”

This article seems to argue for Big Design Up Front. Ok, if you do that, then why not write the tests for those designs after you make the design – then the code you write confirms to the design.

I don’t think anyone advocates that writing tests is the same as the design process. Tests are the result of design not the other way around. The gray area is not design up front – but how much design up front.
> this idea that TDD is a panacea where no bugs ever survive

I don't think I've heard many people claim that. Rather the point I've seen made is that it not only ensures you've got tests, doing them up front encourages developers to write code in a way that is easy to test, which usually happens to be higher quality, more loosely coupled code.

When it comes to writing code there are no silver bullets, TDD included.
Show HN: Real-Time Front-End Updates with React, Serverless, WebSockets, AWS IoT
This is a good and cool post. TDD is less susceptible to "sucky code" for two reasons:

1) It should be a direct port of your specification. If you don't have a specification, you can't do TDD.

2) It should be written by someone who won't be writing the code. Or, at minimum, checked over by someone who won't be writing the code.

Writing tests after you've written code strongly encourages you to write implementation tests rather than specification tests. Both are important and useful, but for separate things (if you have to change your specification tests it's probably because you need to bump a minor or major version number for your software).
> The problem win TDD is that we flawed humans are writing the tests in the first place.

A general AI could have the same kind of problem, and if we had specialized AIs, we could presumably create the target software directly anyway...
Maybe the title should be: TDD did not live up to my expectations?

I too, like the author, have been practicing TDD for > 10 years. Test, implement, refactor, test... that's the cycle. If you follow that workflow I've never seen it do anything to a code base other than improve it. If you fail on the refactor step, as the author mentions, you're not getting the full benefit of TDD and may, in fact, be shooting yourself in the foot.

I've read studies that have demonstrated that whether you test first or last doesn't really have a huge impact on productivity.

However it does seem to have an impact on design. Testing first forces you to think about your desired outcomes and design your implementation towards them. If you think clearly about your problem, invariants, and APIs then you will guide yourself towards a decent system.

The only failing I've seen with TDD is that all too often we use it as a specification... and a test suite is woefully incomplete as a specification language. A sound type system, static analysis, or at the very least, property-based testing fill gaps here.

But for me, TDD, is just the state of the art. I've yet to see someone suggest a better process or practice that alleviates their concerns with TDD.
Not in order to post their distribution! Approval for usage in critical infrastructure.

Critical infrastructure, IMO, should:

- not use general purpose operating systems

- maybe not use general purpose computers (just build custom FPGA logic to control power grids and stuff)

- not use internet connected computers

- maybe not use computers at all when possible
So, should these lanes be painted like the recharge areas in F-Zero?
It always startles me when people assume that one programming technique either works for every type of programming or doesn't work for every type.

Working on Perl 6 compilers, an extensive set of tests was our best friend. It was (probably still is, I haven't had time to help the last few years) utterly routine to write tests first and then write the code to make them work. It was a perfect way of working on it.

On the other hand, one of my personal projects in Perl 6 is abc2ly. It has lots of low level unit tests, great. But almost everything really interesting the program does is really hard to test programmatically. How would I write tests to make sure the sheet music PDF generated has all the correct notes and looks nice? That problem is significantly harder than generating the sheet music in the first place!