skysight-inc/HackerNews huggingface dataset:
"Weak willed" was referring to the parents, not alleged sufferers of ADD. Did you read the whole post, or did you just scan for words you don't like?

In context, "weak willed" referred to the fact that parents let themselves be convinced that their children had ADD when they should have known that they were being sold drugs that were merely performance enhancers.

Overall your post comes across as an angry rhetorical rant, while the original post had some interesting content.

The "solution" that I imagine the poster would propose is to recognize that Amphetamines offer advantages to almost anyone, and that either we should be honest about their use as performance enhancers, or find ways to distinguish between a genuine need for them, and their use for enhancement.
Answer to the answer to my comment :-) :

This is exactly the answer I expected. It was a little bit of a trap, I have to admit that.

I didn't ask for any proof of the irrationality of square root 2. I asked specifically for the classic proof. Which I cannot do. So it is not classic mathematics as usual.

An honest answer to this whole thread would have been: "No, you cannot do classical mathematics as you were used too. You have to give stuff up, but I think that you will gain other stuff in exchange, and in my opinion this other stuff is more valuable than the stuff you gave up."
There was this: https://github.com/elitheeli/stupid-machines
But OOP doesn't make programming more difficult. It just makes structuring your code easier.
That's very nice! Thanks! I spent a lot of last night figuring out how to use socketcall, and this should be helpful.
I've never quite got this. Spend any time writing code that's not using classes and you end up reinventing OOP anyway.

"Spend any time" implies substantially more experience than what most beginners possess, hence the term "advanced." "Intermediate" might be a better term in an absolute sense. OO design is something to learn after you understand the basic tools and techniques.

Also, a lot can be accomplished without OOP (for most values of OOP) and even if you're writing de facto OO code, it's not always clear whether using explicit OO language features is a net win or not.
Happy Birthday!

There will always be things that you feel like you should or must be doing when you are 24 or 25 or 65!

Its great that you have found something you enjoy. As you get more experience and explore new avenues, you may find things that interest you more. Be open to change. The peanut gallery will always be there, but the only person you are accountable to is yourself.

The social pressures are a part of the culture, but they are background noise as such and should be treated as much. Focus on what you want to do, and where you are going. The other things will fall into place one way or the other.
I disagree; abstractions are good, and it is more important for students to learn to think abstractly than to learn how a computer works "under the hood." The vast majority of computing tasks involve abstract problems with abstract solutions -- computing account balances, querying databases, cryptography, UIs, networking, etc. Even basic things in a CS curriculum like data structures and algorithms require abstract approaches and gain very little from knowing low-level details.

There is a place for the low-level details: computer architecture, compilers, and operating systems. Students should take these courses to be well-rounded and to see how theory is translated into practice, but elsewhere things should be done at a high level.
Nginx will almost certainly be faster, and is somewhat robust against DoS attacks. I didn't write this to provide benefits. There are situations where this would work better than nginx (where, say, you don't want to spend any time configuring anything) but there are better existing solutions for those cases.
Well, some warnings are valid, but yeah, the "I recognize this is dangerous, but it is correct" makes perfect sense.
I definitely agree that namespaces are a good idea, but if by modularity you mean isolating pieces of functionality, I'd suggest OOP is one of the worst approaches to take, because it results in a lot of implicit connections. Only global state is worse.
This also struck me as odd but for slightly different reasons.
Namely, I don't think the statement takes into account possitive externalities that may arise from 'ethical' investing. Perhaps this lost money is just reallocated with a much longer payback?

Consider investing in renewable energy, perhaps they are not as efficient as fossil fuel power generation methods, but renewables have other positive externalities (lower pollution (arguably)) that may pay back this 'lost money' in the future by way of increased life expectancy, or just creating a greener, healthier, more pleasant world.

The same could be true of other ethical initiatives, including hiring from minority groups. Perhaps the fortunes of poor neighborhoods could be increased if a company set about hiring its staff from such a neighborhood as one of it's business policies. A generation down the line that neighborhood could be producing the next entrepreneurs.

Point being, money doesn't account for everything...yet.
I'd also quite like to know how to do automatic image generation for different architectures once all tests have passed. That would be fun to see.
Some parts of this trend worry me. For instance, Under Armor buying MapMyFitness. People will still buy Under Armor products even if they don't have the post-purchase technology connection. How exactly does owning the app that many people use to log their fitness data help the company that makes the clothing? Are people commenting on MapMyFitness about how their latest cold gear purchase impacted their run this morning? That would be surprising to me. Startups being bought by non-software companies is going to be a bad experience for some people. It's hard to do your best work when your work isn't the focus of management, and by extension, the company.
Well, I think it's better to teach OOP early on to avoid people ending up reinventing it.
Part of the problem is that competition is fairly level these days, thanks in-part to the Internet, easier global communication, changes in production capabilities, etc.

So, to the massive corporations that have been around for centuries now, any time spent playing is time the competition is jumping ahead.

Of course newer, smaller, and more agile businesses see it the other way; play is crucial to innovation and bounding in front of competition.

Creativity and true innovation are a balance, more than anything, between play and nitty-gritty work.

As technology progresses businesses -- and even individuals -- will have to ultimately decide for themselves if the risk of play and remarkable innovation outweighs straight-forward conformity to the status quo and the guaranteed slow wins of steady (albeit non-innovative) production.
Embedded Systems Weekly News Issue 8
I recently encountered this cultural difference (I grew up in Australia) with my wife (we live and she grew up in the US). My daughters vastly prefer my sandwiches to hers because I butter the bread (on the inside, the way God intended), usually using as little butter, or margarine, as possible. When asked why, I say it's mainly because it prevents the moist stuff in the sandwich from turning the bread to mush, but also because it tastes good.

I think a lot of it comes down to the fact that most sandwiches these days are prepared and then eaten right away, whereas I was brought up in a world where sandwiches tended to be prepared long in advance of being consumed.

That said, Americans will cheerfully slather "mayonnaise" on bread.
Agreed. However, it should be safe from buffer overflows, path traversal attacks, XSS, and obviously CSRF. It should be fine other than DoS. Let me know if you find any exceptions.
Nifty. I'm really looking forward to using those in several years.

The need for CSS variables has only been apparent for about forever. What took so long?
Good article. In the US and some other places around the world, you'll find pilots who are equally capable of flying automated Airbus type aircraft as they are 1960's style cockpits using old fashioned radio navigational aids. I take pride in my skills and ability to operate an aircraft safely. Unfortunately, what I know seems to be becoming a lost art, and the state of the piloting profession internationally will likely speed the process of automating pilots out of the cockpit. It's sad, and I've become pretty keen on learning a new skill in preparation for the demise of my job.
Thank you! I'm glad to hear that you found it so readable.
Right, I get it. Your solution is "everyone just ignore it!"

"Big words" really means "too many words" in this case. Sorry for the confusion.
She is because of her irresponsibility.

Radical feminists would make horrible information security consultants, now that I think of it. "Risk management is oppressive. Don't tell me to set up firewall rules and ACLs, tell crackers not to enumerate my services!"

Is the concept of personal responsibility and analyzing the situation really that hard to comprehend for these people? You can't just scream "YOLO, I'll do whatever I want!" and expect to be unharmed.
They seem to be describing an average Chechen family.

Or so many Russians believe, therefore a growing movement to split Chechnya and Dagestan from Russian Federation and seal it with concrete border like US-Mexico.
Creativity is the process of having original thought.

The oft debated aspect of that definition is whether original thought is valuable from a social standpoint, or that it's enough for original thought to merely have value for the individual.

But that's the most concise definition of creativity you'll ever get IMO.
"What is it about "today's world" that makes software require a larger code base?"

The fact that we are still not using the high-level languages we have available to us. Vast amounts of new C, C++, and Java code are written each year. We are solving bigger problems, but we are using languages that are still catching up to the state-of-the-art of the 1970s.
Great post, I kinder learnt some similar lessons with a part time project I was working on. Similar concept, get people in Africa to sell stuff online. You wouldn't believe the payment processing issues I encountered and trying to cater for users to sell "anything".
Thank you! About the time you wrote this, I discovered that the strlen code was incorrect in a different way as well, and then I went to sleep. Sort of embarrassing.
Personally I like OOP and I think a lot of its criticism is flawed, since the OOP flavor that most people are exposed to nowadays is Java's OOP. And personally, whenever I see class names suffixed with "Executor", "Manager", or anything really that ends with "er" and "or", I feel like puking.

Besides, the state in which we are in is rather healthy. Back in the late nineties, early 2000, everybody was into class-based designs described with UML.

And I do wish people were forced to use functional programming, because that's the only way many people end up learning something new. OOP is not the best choice for every problem. Sometimes a function is better than an ExecutorManager. Sometimes a Map or a type-class are better than an inheritance chain. Sometimes a monad is better for manipulating data streams instead of iterators. And so on and so forth.

Also, the Gang of Four is seriously outdated.
Kevin Flynn uses vi - 'nuff said:

http://i.imgur.com/rMdKYde.jpg

(this is in jest but no doubt I'll be downvoted...)
I haven't measured, but I'm pretty sure you're right.
Show HN: A Gesture Based Calculator for iPhone
Thank you very much! This is the nicest comment in this entire thread!
Writing a sex blog isn't evidence of mental illness. You know what Michael O. Church meant when he wrote that she might have been mentally ill, but you pretend that his point was ambiguous, because the reality of what he said is inconvenient to your argument.

I wouldn't call my concern about him "casual".
> the only way people can be at ease is in the context of a larger environment where losing one job doesn't ruin one's life.

one of the best comments i've seen in a while
You'd be surprised what kids can achieve with little more than global variables, gotos and if statements. Structure speeds things up and prevents stupid mistakes once you understand the basics, but before that point it can be overwhelming. Far more important, in myexperience, is the "programming mindset".
Which is a great boon, as I've edited the latex and recompiled it to fit perfectly on my Kindle.

I really wish more people would open source their books.
Autonomous drones could’ve helped contain riots in Singapore and Thailand
My real point is that there is nothing to be gained by modeling circuit components or even circuits as objects

Then I still find your point unclear. Why would you choose them as an exercise to introduce classes, which is what we were talking about? I agree, it's odd. Mammals and dogs, however, are a concept people can understand. As are windows and doors.
Obviously. I strongly disagree. There are many more important things to learn first. OOP can be introduces little by little as it gradually becomes relevant.
Now regarding NixOS in general; its a smashingly good system, I use it on a daily basis, but proper documentation is in dire need.
"Maybe I could interest you in another page?
There are a lot out there that are pretty neat, they say,
although none of them were put on my server, of course."

Marvin lives!
It's also kind of dickish to send letters to people's homes saying "you watched porn".
HM...

class Hello {
public static void main(String args[]) {
System.out.println("Hello, world!");
}
}

Versus:

(print "Hello, world!")

Yes, this is a deliberately extreme example, but the point is that object-oriented code does not make it easier to structure CS101-level programs. All it does is introduce a bunch of keywords that students have trouble understanding until they are sitting in a much higher-level course.
Well, I'd introduce classes after dictionaries and functions, because that's all they are, really.
It's funny how, for some things, you tend to be more comfortable with whatever you're used to even if nothing newer is objectively better. I used an HP-55 for years and then an HP-41. The newer HP graphic calculators never did a lot for me and I still use an HP-41 emulator on my iPhone for most of my calculating--though I'll pull out a physical HP calculator is I need to do a lot of calculating.
The downside of this (unless I'm missing something) is that these variables need to be evaluated on the client side and inevitably slow down CSS processing (at least for the first time that is). I really like the fact that you can preprocess both LESS and Sass (and others) to just plain CSS and hide all of the dynamic behavior (far more then just variables).
It makes it more difficult for a beginner because it is yet another concept to learn when you are at a stage at which they are not yet comfortable with variables and loops. It's also a pretty vague concept where different languages and different developers have different ideas about how objects should work.

I find that it only really makes sense from a code structure point of view once you have got to programs that are significantly bigger than the average beginner is likely to be writing. Even as somebody who understands OO I don't tend to use it for programs that are less than at least a few thousand LOC because I find that it just gets in the way.
I would like to see less stigma attached to ADHD, and more attached to advocating unhealthy diets. The consensus by experts is that dietary saturated fat and cholesterol are bad for your health.

I would ask anyone trying to cure their ADHD, cancer, etc. to take a look at

http://en.wikipedia.org/wiki/Saturated_fat_and_cardiovascula...

and "Dietary Guidelines for Americans"
http://www.cnpp.usda.gov/DGAs2010-PolicyDocument.htm
You're saying that in Java you're forced to use OOP for every problem and then you exemplify with "hello world". Well ...

1. function definitions being constrained to classes has nothing to do with OOP

2. static functions or members have absolutely nothing to do with OOP

I see a lot of criticism of OOP, but when I get to reading the details, it's all about Java's flavor of OOP.
This is what I immediately thought of. They've built a nice small library that can be used as a framework for something more detailed and involved, which is fantastic.
Yeah, I didn't mean to imply they were making it up. I'm for medical marijuana and marijuana research. It just seems that this gets inflated into "Did you hear about [name of fringe researcher]? He cured [every disease] with just marijuana!"

Sorry to make light of this.
I think it can help once you've dealt with dictionaries and functions. Classes are handy for storing a bunch of variables and functions together, and that's how I'd teach it.
Sorry, no. That sort of thing really isn't a problem these days with services such as Amazon. Developers aren't typically the sort of market that will easily pay for things - especially when they're just starting a new project. If you want to target developers, and you want them to pay, do something they don't want to do. Testing, Operations, Marketing - finding actual customers for a new product is something I'd pay for.
> But in practice, if you know all your targets support the right "#pragma pack" and "__attribute__((packed))" and other markers that you use - what's wrong with making use of them?

You know that at this moment they all support the right __attribute__((packed)) et co.. Bonus points for endianness crap.
A little bit more info about the internals of the recognition engine would be welcome. It seems that one needs to manually supply sets of keywords and key phrases?
Hey AlisdairO, great work!!
Any way to get in touch with you? My email is in my profile.
Types As Specification
thanks for the pointers. I gave up with Martin-Löf type theory reading other texts, so I'm looking forward to trying again with this book.
Note that fmap writes: "Equality of rational numbers is decidable, which means that classical reasoning is provable. And yes, even if it wasn't, it would still work."

What is meant by "even if it wasn't, it would still work" goes back to something he said earlier: type theory embeds an infinite hierarchy of axioms of choice and laws of excluded middles. If you want to do propositional-like reasoning in homotopy type theory, you can assume AC or LEM for homotopy (-1)-types, corresponding to propositional logic.

In type theory you are encouraged to drop the law of the excluded middle and the axiom of choice, because of the fact that doing so gives you potentially more expressive ways of doing things as we have said, but you have gotten the impression that you have to, which you don't.

Also, the claim in this thread was that the results from classical mathematics are provable using homotopy type theory, not that they are provable in the same way (though that holds as well, as I've said above; it's just that the mathematics might not look as clean as if you did it in a more idiomatic way). This kind of a value proposition is not exactly new: category theory loses certain axioms over set theory and mathematicians adapted to the point that category theory is now the language of modern algebra.

I want to point out that I suggested that you read the introduction to the book because it provides these same answers to the questions you are wondering about. I still suggest you do so, as it goes into more detail on what we have said here in a way that I am not able to quite as well.
Where is vi? I only see two shell sessions and top.
I'd love to hear you highlight a few of the unexpected challenges.
Someone already made a song out of this topic: http://www.youtube.com/watch?v=9hBpF_Zj4OA (this is the original scientific video this song was based on: http://www.youtube.com/watch?v=k6M-h5g3PwI).
As a non-lawyer, is this kind of clause even legally enforceable?
Hi, I'm the author of this post.

The initial purpose of this test is to compare the different ways of connecting Nginx to Go.

It doesn't makes sense to test against a heavy task in Go instead of this single static string. Nginx in front of Go will not perform better under this circumstances. It will only perform better if static content is being served directly by Nginx or if caching is enabled, which is not the purpose of this test.

Following what some folks suggested, I also made some recent changes, like swapping ab for wrk and tuning nginx to disable gzip and enable keep-alive connections.

The results are very different now.
On a related note, if you're using new and delete you can simply delete a pointer-to-const without jumping through any const_cast hoops, though I often wish I had a way of blocking that for APIs where the callee doesn't take ownership of a const Foo*.
you make it sound like being able to ship one binary that's backwards compatible with previous processors was a bad thing.
Arguably a more maintainable technique would be to use multiple classes and define, e.g. a "brand" class just for this color, so you can have a simpler standalone rule:

.brand {
color: #bada55;
}

See OOCSS for more details.

While that's good practice, it's a challenge to get it right on a large legacy systems, so I still find variables useful in practice. Also, it's nice to be able to perform functions involving variables, e.g.

.brand {
color: lighten($link-color, 20%);
background: ($link-bg + $page-bg)/2;
}
Anecdotal experience deploying in the lab with NixOS and/or Nix:

1. At the time, I was maintaining several heterogenous RPM-based systems, so that was the comparison. I can say with some limited authority that it's easier to make NixOS packages than RPMs, but harder than (say) tweaking /usr/ports in a BSD or Gentoo.

2. Being able to send closures between machines -- i.e. a reproducible recipe for the user's current environment, including all installed and user-acccessible packages, libs and binaries -- is eerie, like alien technology. Think of 'nvm' or 'virtualenv', but granular, and for everything. Once you get used to it, you will never be happy with any other package manager.

3. Nix' independence from NixOS is both a blessing and curse . On every OS except NixOS, Nix is necessarily a third-party add-on, and it necessarily uses slightly different versions of everything. Thanks to some insanely clever environment management, this never causes things to go plink, but it does mean that I often had a choice between a fresh Fedora RPM -- on a Fedora machine -- and a slightly stale Nix package. Guess which worked better. Guess which I chose most of the time. (But if you guessed that I was a bit OCD about package freshness, you'd be right.)

4. Final drawback, and the reason NixOS hasn't yet made it into production at our company: NixOS itself obviously has to use the same slightly stale packages that Nix does.
That said, how upset can you really get? These guys don't have the dev-hours that Canonical or Red Hat do -- or even Debian, for that matter. What they have achieved with the resources at hand is mindblowing. What this project needs to really be useful to me is about two dozen new FOSS contributors and like maybe half a million dollars of investment. Any more than that, though, and I'd worry they'd lose their game ;D -- so much of it is based on doing immense amounts with almost nothing, using cleverness as the amplifier. Isn't that what it's all about?

5. Oh, and also, the devs are responsive. Hi guys! ;D
I read on pprune earlier this year that the instructor who had the most hours on the 777 was junior in rank to the pilot transitioning, and due to the way Korean society is regarding rank, might not have wanted to overrule a "senior" officer.

Sounds unlikely in this day and age, but 20 years ago other air crashes from Korean airlines were apparently due to the same thing with junior pilots not wanting to overrule or speak up against a senior pilot who had made a mistake or overlooked something, so who knows...