skysight-inc/HackerNews huggingface dataset:
If tracking changes in the specs, you'd be right, but I'm referring more to the mindset. And I don't mean to imply this is anything sudden --- if pressed, I'd probably roughly gesture in the direction of 1998-2000, possibly related to a slow "changing of the guard". In this incredibly long but fantastic thread, Anton Ertl points to GCC 2.9.5 as the turning point. http://compgroups.net/comp.arch/if-it-were-easy/2993157 (search for Ertl). His rhetoric might be excessive, but he makes a good point that in practical terms, his research on "threaded interpreters" went from being possible to do in C to impossible.

I'm also not referring to syntax --- I think many of the syntactical improvements are fantastic and have no downside. And the reliability of modern compilers is much better, and by-and-large the optimizations produce smaller and faster code. But what I think we're losing is the transparency of being able to reason about code execution by looking at source code. It's still the norm for academic papers to offer source for two approaches to a problem, and use execution time to prove that one is faster than the other because "it has more operations" or "it has more memory accesses", without ever looking at the generated assembling and noticing that one approach has been vectorized and unrolled, and the other has substituted a completely different algorithm that drops all the conditionals because the compiler realized they were never being exercised.

And I don't think it's simply a matter of programmers exploiting undefined behavior without properly considering the consequences. The inclusion of the standard library into the spec for the language creates "spooky actions at a distance" that never existed before, where passing a variable to "print_debug(a)" allows the compiler to remove the later check for "if (a == NULL)" if print_debug() is observed to pass the variable to printf() and if whole program optimization is being used. Whereas if print_debug() is in a compiled shared library, this won't happen, and the null-check will work as intended. I see the reasons compiler writers want this flexibility, but it sure makes development and debugging much harder than it used to be.
Why Apple Failed to Make Sapphire iPhones
That's a matter of personal preference. I have never been in a relationship and don't currently have any friends, and I'm perfectly happy this way. Life is what you make it.
This would be a lot easier to take seriously without the idiotic image macros.
>> how many intro stats book, of the traditional kind, mention MLE, method of moments, biased vs unbiased estimators, etc...? None that I've seen

Oh - there are quite a few. Here's a small sample (no pun intended):

- Probability and Statistical Inference by Hogg & Tanis (we used this in my stats course)

- Modern Mathematical Statistics with Applications by Devore & Berk

- Probability and Statistics by DeGroot & Schervish
It's somewhat higher level than C.

I've always liked to think of myself as a programming polyglot, able to pick up and reason about nearly any standard language. I'm not sure how Rust is doing it, but the more I read and learn about it, the more confused I am. The syntax is just so bizarre and counter-intuitive to me. And yet I seem to be the only person in the world who doesn't "get" it. It's as if the language is being explicitly developed to be my kryptonite.
So, an executable you can just run? Interesting that this is a feature to brag about. Reminds me of apps for Mac OS, in the years following 1984.

Sounds a bit like static-linking plus sandbox.
My comment was out of genuine curiosity. I agree they're not of much technical value and for HN it's closer to "trash" material, however I don't see why we must limit our comments to purely technical concepts.

I find the events surrounding Bitcoin, specifically the criminal aspects fascinating. I mean come on, who doesn't love a good heist? Especially one that's been committed anonymously and thus far turned up completely untraceable. No, the content of the discussion generally isn't very intellectual, however it does incite and bring about thought-provoking and technically interesting arguments.

I never really put forth my thoughts on anything relating to Bitcoin when I posted that comment. I was merely asking if there'd been work done around tracing Bitcoin theft.. I don't think I'm inciting FUD whilst asking a question. I understand that the talk of crime and theft in Bitcoin could become tiresome for you and other technically and academically interested parties, however my fascination with such topics isn't limited to Bitcoin. I just don't think you should accuse me of speculation or inciting FUD when all I posed was a question.

Also to be fair, I had labelled my comment offtopic.
No, because writing a VM constitutes a reduction in attack surface. Implement a bytecode instruction properly once, and it's good everywhere it's used. Implement a correct garbage collector, and you don't have to worry about use-after-free anywhere in your Python code. You still have to worry about it in your C, though, and you have to make sure it's done correctly Every Single Place you do it. And if you think programmers are up to that task, go browse the CVEs for a while.

Look, I know lots of people like you think that C isn't that hard to get secure code from. But if you were correct, we wouldn't be living in the security cesspool of memory bugs we are now.
Personal opinions about what you offer aside:

Link to your Privacy Policy doesn't work.

The "get notified when we launch" buttons look odd (I don't like the tab-like look, and the lines below them don't always match the width of the tab). If I click on one the background of the page jumps around.

The first blocks are to short, making the page very busy. Try to combine their looks.
A great reason not to do this, if you are building anything that will ever be touched by end users (or are building anything that is an application on the web browser) is this isolates you from how real users consume internet content.
You can exploit this trick to some extent to name a file in a way that spoofs its real extension. E.g. name an .exe file such that it looks like if it was .doc (and give the exe an icon associated often with .doc to be even more convincing).
The analogy is not chosen merely for being similar, but to fulfill a purpose. It's based on the idea that in the original puzzle what you are faced with is a choice between your original door, or all the other doors. That's why you have a 1/3 or 2/3 chance of being right if you stick or switch respectively - because you are either choosing one door, or effectively two doors. The host showing you whats behind a door is just an implementation detail that causes you to have a stick or switch decision that has that effect. That's why a nice analogy is one that gives you a choice between 1 door or 99 doors, i.e. a chance of 1/100 or 99/100 of winning.

Your variant is a valid analogy too, but the probabilities in your scenario between sticking and switching are so close to each other, it's not going to trigger any new intuition in someone who is already confused.

Don't think of the 100 door puzzle as an analogy with the 3 door puzzle, think of it as a class of puzzle where there are N doors, you can pick one, and then the host (who knows what's behind the doors) reveals N-2 fails. It's clear that the 3 door puzzle is a specific instance of that, and if you have understood something intuitively about that puzzle class through considering N being a large number, that will still hold for N being a small number.

The class of puzzles that you describe is M doors, where you pick one and then the host (who knows what's behind the doors) reveals one fail. The three door puzzle is also a specific instance of that puzzle, but I doubt that you've learned anything from that, since examining M at other numbers probably hasn't given you any insight (still, if it did, those insights are indeed applicable to 3 door Monty Hall).

I've tried a number of ways of explaining this problem to people, and empirically the 100 doors one is the way that seems to work best. Interested to hear any versions you tell that seem to help people understand whats going on.
> console.log(x.size);

This is annoying. Is there some reason x.length wasn't used?
What is the LOC for the CPython interpreter?

Now, what is the combined LOC for all Python code that uses the CPython interpreter (and those LOC are in a higher-level language).

Now compare that to the amount of C code that that would amount to if all of that code was written (or, tried to be written) in C instead.
Mattermark should not really worry about burn rate for this reason. It only has any revenue if the current funding party continues and if it does then they can continue to raise as much money as they like. If the market turns then their income will evaporate to nothing and burn rate will be the least of their worries.
(2013)

First, I think the speed of C relies heavily on the compiler. C is not fast, not if I wrote the compiler. But GCC is very fast, and ICC at least as much.

I was a little confused by the Erlang wariness, but the reasoning seemed sound

> At Couchbase we recently spent easily 2+ man/months dealing with a crash in the Erlang VM. ... ... it was a race condition bug in core Erlang. We only found the problem via code inspection of Erlang.

That does not sound like a fun time, but once the bug is fixed, what's the big deal? Is there good reason to believe more bugs will come? It wasn't my ass that got bitten but I'd forgive Linux even if it had a race condition bug. (or if it crashes touching 1000 files in /etc)
That's so clearly false that it hardly deserves a response. I'm spending more time wondering if you are trolling that why you are wrong. But in case you aren't trolling:

1) A lot of "Python" security vulnerabilities are caused by "C"-problems (overflow errors, etc). [1] and [2] are a couple from this year.

2) You'd expect interpreting python to be more secure than C because the interpreter acts as a filter over input reducing the attack surface, meaning that potentially vulnerable paths are minimised are better tested than if an entire program was in C.

[1] http://www.cvedetails.com/cve/CVE-2014-7185/

[2] http://www.cvedetails.com/cve/CVE-2014-1912/
Hmmm. I work on a pretty large scientific computing project written in C++. Complex numbers in C++ are much, much better than they are in C. In general, I'm very happy it isn't in C.
> you are supposed to be paying tax to the US for any money earned from the US (even if you aren't in the country)

Just note – this can be overridden for some cases in US-<your_country> income tax treaty. For example certain kinds of remote work can often be taxed in the country where the remote worker is located, not US.
So your assessment is that 98% of the homeless have drug/alcohol problems or are homeless by 'choice' ?
They're already accepting scams like bitcoin, why not accept the crytpocurrency that doesn't try to pretend it isn't a joke
Ya, me too. It's also a very funny talk. :)
Relevant:

The Oracle: We can never see past the choices we don't understand.
You can export org mode files as HTML, PDF, LaTex, even iCalendar. Try C-c C-e to see options.
Go is garbage collected though, and a lot of people using C don't want a GC'd language. (It's up for debate whether GC actually matters for most of them, but that's the feeling nonetheless).

Edit: also, not sure why you were downvoted, since your question at least deserves a reasonable answer.
The Independent and Other Sites ‘hacked’ by the Syrian Electronic Army
OCaml might be mainstream to armchair FP developers on HN and language theorists at Facebook, but it remains a fairly unpopular choice for developing software outside academia. Even Haskell is pretty unpopular relative to the amount of software developed daily.
I've written articles and scripts with it.

In grad school, its support for LaTeX was clutch in Algorithms class where all the assignments were laden with mathematical symbols.
> It's always annoying when you attempt to click a link only to find it won't work unless Javascript is enabled.

Ah, the number of times I've asked colleagues to stop doing this! If you want a JS-powered link/button/whatever on a page, insert it using JS; then you're guaranteed that it will only show up for those who can use it.

Likewise, all togglable content should begin visible, and selectively-hidden by JS during page load; that way, it only gets hidden for those users capable of showing it again.

Also, although this is rarer, all work should be done in small, isolated event handlers. That way, when some unexpected situation arises (eg. the user is blocking your chosen spyware platform), that particular handler dies, but all of the rest keep working (eg. the button handlers, the slideshows, etc.).
My impression of Rust is that it focuses too much on safety at the expense of making it hard to do what you want, especially when dealing with low level things.
This sounds very interesting. Any more details?
This last bit is so true:

> I always have it in the back of my head that I want to make a slightly better C. Just to clean up some of the rough edges and fix some of the more egregious problems.

I'm always mulling over that. "Maybe just namespaces, better macros, function overloading and member functions (eg this->) would work." Yet I'm sure Bjarne Stroustrup was thinking the same thing when he started on "C with Classes." The power to add features must be so overwhelmingly corruptive. So justifiable in each and every case, in the moment. And then you just can't stop. "Closures would be helpful. I'd love to write generic containers. Inheritance would save so much typing.", and the next thing you know, you're working on virtual inheritance, concepts and user-defined literals. :/

In my opinion, C really does need just a bit more to be great, but it would need someone with a will of steel to stop and leave things be after that.
Nice - confuses XFCE as well: http://oirase.annexia.org/tmp/hackernews.png
I agree. Not had chance to try eww yet.

One step up from Dillo is Netsurf, which seems to handle more CSS than Dillo but is still pretty snappy.
> for some values of "king" perhaps - perhaps it's faster to compile, but no arrays of varying ...

Well, let's not change the goalpost - your initial assertion was that C has faster compile times. Then chances are that something's got to give, whether that is in the grammar, declaration order, etc.
VimOrganizer also REQUIRES a Emacs install for most interesting things.

https://github.com/hsitz/VimOrganizer/blob/master/INSTALL.tx...
Rust seems to me much more like Haskell than C or C++. Try thinking about it that way and see if it makes more sense.
Historical accident. People choose C, because nowadays it happens to be everywhere, which eases porting but there are lots of languages that could be used instead, if people valued safety.
Language wars in a nutshell. However, there is a significant contingent of C practitioners who delude themselves into thinking that they are good at writing secure code, when all the world's evidence militates against them. Hopefully one day "C Considered Harmful" is a meme and we only use C, and its memory-unsafe friends, in hopefully increasingly rare places where absolutely nothing else will do.

We need to be realistic and admit C/C++ is part of the problem. The sooner everyone accepts that, the better.
Did anyone notice a popup box asking you if you "didn't find what you were looking for"?

it appeared almost automatically after I moved my mouse to close the tab... Are they doing some mouse tracking and looking for rapid movement off screen (to the top of the page)?

If so, that's really cool. If not, nevermind
The gender imbalance in IT is real, ongoing and ridiculous
Or... 365 days...
See http://www.talk-polywell.org/bb/index.php for info on his design, and other fusion news.

http://en.wikipedia.org/wiki/Polywell
Only if speaking of original Pascal, neither Extended Pascal nor Object Pascal suffer from those limitations.

When I learned C, after a few years of Pascal dialects C just felt like a stone age language.
length implies an ordered sequence.
My understanding was that a lock free algorithm could still wait for an unbounded time, and what you're referring to are called wait free algorithms.
Chernobyl’s Hot Mess, “the Elephant’s Foot,” Is Still Lethal (2013)
I really doubt jruby will ever become the main ruby implementation, as awesome as it is. The fact is that too much of the ruby ecosystem is built on calling out to C, and jruby officially abandoned cext shimming a while back. And while ffi is good, it's often not nearly as flexible.

There's also the fact that because of slow startup times, the modify/test cycle can be quite frustrating compared to working with MRI.

The truth is that the vast majority of ruby applications never reach a point where the steady-state post-warmup performance of jruby with pure ruby outweighs the fast-startup moderate performance of mri+cexts. And ones that do reach that point often have a better case for moving to something else anyways (including other jvm technologies that can now be shimmed on via jruby and eventually replace the whole thing).
Uber suspends operations in Nevada after ruling
They're doing that too, with opportunistic encryption where self-signed certs are trusted if DNSSEC says they are:

https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
No it is not. Go is only "like C" in the sense of the most superficial syntactic similarities and that it is primitive. It isn't even in the same world as C, it is just another high level garbage collected language that compares poorly with the rest of the languages in that group. Go was not brought to us by the people who made C. It was brought to us by Rob Pike and Russ Cox. Dennis Ritchie gave us C.
I agree totally, my top level comment in this thread has my version of what a great C replacement would be. I'm slowly working on it.
We wouldn't be better off, no. The newer OS would likely be less secure, less reliable, and probably less performant. It would also require all of the tools we take for granted to be ported to the new OS, which would be difficult since the above proposal is to change the API of the new OS.

It doesn't seem like there's anything wrong with libraries.
If that really is the only barrier to using this then I'm sure a simple email to the sole copyright holder asking for an MIT/BSD/etc license to the code would solve your problem.

The author put together what looks like a nice library, let's not make an issue out of something so trivial to solve.
Trivial to get an newer version though, for example through homebrew.

Here is what I have, currently (haven't updated in a while)

$ git --version
git version 2.0.3

For windows, it is another matter, seems officially stuck at 1.9.4 since forever (http://git-scm.com/download/win)
No, C is fast, even tcc which does essentially no optimization except for constant folding is about half as fast as gcc -O1 I think. Basically no special work is needed to be 50 times as fast as python.
In that case, how about throwing here just a quick list of features/tools you're using for this?
You may have a very long python-path and/or script loading a lot of modules initially if it is taking so long to start up.

For example, in a recent script I deferred loading the requests module and startup improved a few tenths of a second. Rinse, repeat.
Even today, you shouldn't need to write code like that. Just bind functions to the current scope. That looks something like this (imagine this code is in the context of some object):

element.addEventListener('click', function(e) {
this.foo();
}.bind(this), false);

Notice the call to "bind" which binds the click handler function to the current object, so that inside it can call this.foo().
Using pkgsrc on Mac OS X
that may be true, but that time was the only time that I tried to purchase Bitcoins online with USD... I ended up using some local options
Memory safety can't guarantee security or correctness. If you guys want to have a better discussion, you need to be even handed about the complexity of security. Languages can solve some classes of security problems.
Newest Tech Trend: Angels Joining the Teams They Invested In
The boring response would be that different languages have different strengths. C is indeed capable of being very fast, mainly by virtue of letting the dev have fine control over memory. But execution speed isn't the only metric. Sometimes you just need something to be done quickly and you know you aren't going to hit the constraints (time, space) of the system, so you might as well go with something like .NET to reduce your development time.

The point about the tooling I'm not so sure about. There's a lot of languages out there with well developed tools. And the tools tend to address the pain points: you have GC profiling in .NET, and you have Valgrind-type tools in c++.
Found it Today too and started following it.
Thanks for the link.
19 JQuery Slider Plugins with Comparison
Languages which don't have pointer aliasing, but use gcc back ends are probably the fastest around. So I think gcc based fortran.

C can work around this using restrict keyword though.
He kinda did. He writes that they changed from Erlang to C because of problems in Erlang. He wanted some safety or tools to help him find problems easier (actually problems in the language or libraries they used). They might develop slightly faster now in C than they did before in Erlang but I doubt it and the rewrite took time that probably cost them 2 months of inproductivity compared to not rewriting it. As for running speed they of course want that. Can't remember if they actually thought that low speed was problem with the earlier Couchbase.
with the print as a keyword, you can't have modules defining a print function (for example, APIs where print makes sense as a function name ([he]xchat's py support comes to mind))

additionally, if you want to override print in python2, you need to replace the stdout stream with your own inbetween buffer object, which also has the downside of being global
Interesting, that could well be it. Languages I pick up very easily (in rough order): C, C++, PHP, C#, Java, Scala, Perl, Python, Ruby, Javascript, Lisp. Haskell is definitely one that gives me trouble as well. It's not the functional aspects: I've no trouble writing recursive descent parsers and the like in C++. I can't stand the parentheses, but I can understand and reason with Lisp.

I think in Haskell's case, it's just doing too much with too little. Like how they can implement quicksort in three short lines of code, and to me it's just so much to unroll in my head at once; but it's hard to be sure for obvious reasons.
His nervous breakdowns were attributed to ingestion of chemical substances (he was experimenting with alchemy) http://en.wikipedia.org/wiki/Later_life_of_Isaac_Newton#1693
The real reason unlimited vacation policies work
It shouldn't surprise anyone to find multiple jquery libraries to make the effect, such as https://github.com/toymakerlabs/kenburns
This book is pragmatic, fun, and thorough. It also provides a nice introduction for people new to thinking in a functional way and applying it to the real world.
Agreed. But memory safety is really such low-hanging fruit right now. Given that memory bugs still produce massive quantities of severe vulnerabilities, it seems appropriate to hammer on that aspect of languages.

If memory safety ever becomes a practically solved problem (e.g. somebody's running an OpenBSD-style count of how many days since a new memory bug popped up and it gets past, I don't know, hate to be greedy, how about 3?), then I'll be merrily banging away on the other aspects.
(without so much as glancing at the source, ) in emacs at least you should be able to make it work with flymake-mode to update the preview every time you stop typing for 100ms or whatever you configure it to.

The downside of course is if you're in the middle of some big change, the preview is useless and a bit distracting.