Ask HN: What programming blogs do you recommend to read regularly and why? - <AUTHOR>

Older results from HN Search (4-7 years back)
https://news.ycombinator.com/item?id=99426
https://news.ycombinator.com/item?id=3120380
https://news.ycombinator.com/item?id=5709455
Interested in what people think in 2015
[edited - formatting] <comment><USER2> If you're into .NET and Microsoft tech, I really enjoy Alvin Ashcraft's Morning Dew [1], which is updated just about every morning with a curated list of blog articles on .NET topics.

[1]: [http://www.alvinashcraft.com/](http://www.alvinashcraft.com/)

</comment><comment><USER3> I read F# Weekly every week, just to keep in the loop about what's happening with F#: [https://sergeytihon.wordpress.com/category/f-weekly/](https://sergeytihon.wordpress.com/category/f-weekly/)

That's probably the only programming blog I regularly check, though I return to Open Mirage every now and again to see how they're getting on: [http://www.openmirage.org/](http://www.openmirage.org/)

</comment><comment><USER4> Seeing there are no blogs listed for iOS dev, here are my favorites:

[https://www.mikeash.com/pyblog/](https://www.mikeash.com/pyblog/)

[http://nshipster.com/](http://nshipster.com/)

[http://natashatherobot.com/](http://natashatherobot.com/)

[http://oleb.net/blog/](http://oleb.net/blog/)

Also I have a blog: [http://koreyhinton.com/blog](http://koreyhinton.com/blog)

</comment><comment><USER5> I mostly just use HN, but I'm always searching for a longer list of blogs to read.

I went through the links you provided and found this:

[http://prog21.dadgum.com/](http://prog21.dadgum.com/)

I really enjoy his blogs based on his experiences in the industry and probing questions.

<comment><USER6> I really love James' articles, too. They demonstrate very thorough understanding, communicated in a fairly light manner. He also writes in a style that gets you thinking instead of giving you a flat opinion.

</comment></comment><comment><USER7> 'Virtuos Code' by Software Craftsman and 'Ruby Rogues Podcast panelist' Avdi Grim is well worth reading.

He's recently been learning new languages (currently SmallTalk) and does great writeups of new insights he's having and how others can apply these insights too.

[http://devblog.avdi.org](http://devblog.avdi.org)

</comment><comment><USER8> There are too many. HN is the best I can do, letting others find interesting content for me.

</comment><comment><USER9> Are we allowed to suggest our own blogs? ;)

Either way:

[https://github.com/paragonie/awesome- appsec](https://github.com/paragonie/awesome-appsec) \- Everything on this list is at least worth consideration

</comment><comment><USER10> [http://ivory.idyll.org/blog/](http://ivory.idyll.org/blog/) is a good one if you're into bioinformatics and academic programming in general.

</comment><comment><USER11> Embedded in academia: [http://blog.regehr.org/](http://blog.regehr.org/)

</comment><comment><USER12> [https://scotch.io](https://scotch.io) for Angular, Node and other web dev topics.

</comment><comment><USER13> A few of my favoriates from my RSS reader (in no particular order) include:

\- [http://www.kalzumeus.com/blog/](http://www.kalzumeus.com/blog/) I love reading anything by Patrick McKenzie because he writes about incredibly valuable things, usually focusing on how to make sales, lifecycle emails, running his companies, and other general start-up related information. You might recognize him on HN as patio11

\- [https://blog.cloudflare.com/](https://blog.cloudflare.com/) CloudFlare has really excellent content and often writes about SSL/TLS related topics, which personally interest me. They have good technical explanations of SSL/TLS vulnerabilities and discuss how they provide SSL to all of their customers. Also, they discuss how they handle massive scale and other interesting things.

\- [https://aws.amazon.com/blogs/aws/category/week-in- review/](https://aws.amazon.com/blogs/aws/category/week-in-review/) I often find really good articles linked from the AWS blog. I like to stay current on the latest/greatest features and improvements which AWS puts out there and the Week in Review posts are often easy to skim and see if a linked article is worth reading in its entirety.

\- [https://codeascraft.com/](https://codeascraft.com/) Etsy's engineering blog is fantastic. I am always blown away at the passion that comes through from their posts. They seem to have a really sharp set of devs over there and I just enjoy reading their stuff. I especially enjoy the quarterly performance review posts, which show graphs about latencies throughout their stack.

\- [https://strongloop.com/](https://strongloop.com/) The StrongLoop blog has some really great content for NodeJS devs. They often post about their own products, which is understandable but annoying since I do not use them directly. They took over maintenance of ExpressJS, though, which I use daily and they also have great contributions to a bunch of other tools in the ecosystem.

\- [https://www.hashicorp.com/blog](https://www.hashicorp.com/blog) HashiCorp made popular tools like Vagrant, Packer, Terraform, etc. I enjoy using most of their products and I like the way their blog presents things in a straight forward tone without too much marketing BS. Seems like a great company culture.

\- [http://blog.ivanristic.com/](http://blog.ivanristic.com/) Ivan Ristic is seriously awesome. He runs the incredibly useful and educational SSL Labs ([https://www.ssllabs.com/ssltest/](https://www.ssllabs.com/ssltest/)) and discusses really interesting and useful topics on SSL/TLS configuration and management. You should also buy his awesome book: [https://www.feistyduck.com/books/bulletproof-ssl-and- tls/](https://www.feistyduck.com/books/bulletproof-ssl-and-tls/) (no, I'm not affiliated with Ivan. I just think he is awesome and his content is hugely valuable).

\- [https://www.imperialviolet.org/](https://www.imperialviolet.org/) Imperial Violet is the blog of Adam Langley ([http://www.rsaconference.com/speakers/adam- langley](http://www.rsaconference.com/speakers/adam-langley)), a security engineer at Google. He writes about SSL/TLS and many other security related topics. His technical explanation of POODLE and other SSL/TLS vulnerabilities are hugely useful and very digestable.</comment>


Submittable (YC S12) raises $750K to replace email - <AUTHOR> http://pandodaily.com/2012/11/09/submittable-raises-750k-to-replace-email-for-real-this-time/ <comment><USER2> I am finding it really difficult to understand what this tool is or does from the hand-wavy description in the article.

The part where it turns out "replace email" actually seems to be "replace usage of email for an apparently narrow document-editing task" is some good old-fashioned link baiting.

Anyhow, I'll bite.

What does this tool do that SharePoint doesn't? Or other email-integrating document management tools such as (shudder) TRIM?

<comment><USER3>
        it turns out "replace email" actually seems to be "replace
        usage of email for an apparently narrow document-editing
        task" is some good old-fashioned link baiting.

From what I understand of the description the idea is that it becomes a management layer on top of email for submissions (hence submittable) that need some collaborative management. Similar to how google docs forms work, but instead of the results ending up in a spreadsheet they end up in the collaborative document editing system.

After looking at their website the use cases seem clear, the Pandodaily article does seem to lack a simple explanation: <http://submittable.com/>

<comment><USER2> Yes, the website is definitely better at getting the gist across -- a document management tool with email integration.

There's definitely a market here, as the zillions of DMS vendors have demonstrated.

I guess I'm a curmudgeon who feels annoyed when people pass off as REVOLUTIONARY HYPERNEW AMAZING ZING BOOM CRASH things that, upon closer inspection, turn out to be nice implementations of a known genre.

(I hasten to add that the blame, if any, seems to rest with the journalist, not the Submittable team).

<comment><USER3>
        (I hasten to add that the blame, if any, seems to rest
        with the journalist, not the Submittable team).

I went back and read the article again and it really is quite questionable how the company is presented. The author seems to have tried to spin some sort of "email is terrible" narrative and got lost along the way.

I think the author should have tried to explain how Submittable would provide value to a company like Pandodaily and that would have been better at putting across the value. For example Pandodaily has a "tips" email which would be the __perfect __use case for the editorial portion of Submittable, yet that is unmentioned and instead the author tries to explain what seems to be a summary of watching someone use the site for 10 minutes.

They also do not seem to have mentioned any of the other specific _types_ that Submittable cater to, which includes resumes, audio / film submissions and grant applications, all of which have their own systems to enable proper management.

Hopefully Submittable will be covered again by someone else and properly so they have a fair shot at being exposed to the masses, because this article is really doing a poor job of even hinting at what Submittable is about.

</comment></comment></comment></comment><comment><USER4> Why is it taken for granted that everyone hates email? I love it. Its only problem seems to be spam. Otherwise it's a simple, standard way of communicating with great interoperability. If anything will replace it, it most probably won't be a closed ecosystem built by a single company.

That said, as others have already pointed out, Submittable seems to be something completely different anyway, with no ambition to do what email does.

</comment><comment><USER5> We aren't going to replace e-mail. It has been tried countless times and failed countless times. But e-mail is problematic simply because it has stopped evolving as a technology. It is static. It is like HTML/JS back in the IE6 era. Just stuck in a rut.

E-mail needs two things done to it but they're difficult to wrap one's head around.

The first thing it needs is to get more simple. E-mail has a lot of quirks, crust, special cases, and other things. This applies to SMTP but also to addresses (TO, CC, etc). Just as one example did you know that technically almost any character is valid in an e-mail address? Did you also know that EXAMPLE@ and example@ are two totally different addresses (case is as equally differentiating as characters)?

I liken this to the XHTML effort (to make HTML more strict). We need to take e-mail as it is used today, and essentially call the "edge cases" illegal. This would be compatible with 90%+ of existing implementations but would make future e-mail implementations (both client and server) far more straight forward. As it stands today you cannot build an effective client or server e-mail system by just looking at the respective spec's since there are so much strangeness.

Secondly AFTER the above has been done AND adopted they need to develop a new standard to replace HTML as the display format for e-mail (XML based). This should include things like signatures, quoting, in-line pictures, tables, and a small subset of text styling. Essentially take HTML, remove 50%+ of the functionality and then ship it as a standard people can cheaply implement.

<comment><USER6> _Secondly AFTER the above has been done AND adopted they need to develop a new standard to replace HTML as the display format for e-mail (XML based). This should include things like signatures, quoting, in-line pictures, tables, and a small subset of text styling. Essentially take HTML, remove 50%+ of the functionality and then ship it as a standard people can cheaply implement._

Why? People who like HTML emails are happy with it; people who prefer plain- text emails (like me) won't like your solution either, since it's XML.

I think we already have a decent format for lightly formatted email, and it's the plain-text conventions (in which Markdown was based). Or Markdown itself, if you want something closer to a standard.

<comment><USER5> Because the HTML supported by e-mail is too massive. It makes writing an e-mail client too expensive and also means that security issues are more likely to creep in.

Plain text should stay as is. HTML is the problematic format that needs addressing. When they first started using HTML for e-mails it was just the natural thing to do, but with the benefit of hindsight it was a mistake.

So I am suggesting we take a subset of HTML, add a very small set of e-mail specific features (signatures, quoting, etc) and then deploy. This format should be entirely display-able with a single XSL (as the easiest implementation).

<comment><USER4> > It makes writing an e-mail client too expensive and also means that security > issues are more likely to creep in.

I disagree: Libraries to render HTML already exist and will continue to be developed, since they are used in web browsers anyway. The development effort would be greater if we introduce another (new) format specifically for email. Every E-Mail Client that wants to do so already implements HTML display.

Most of the security issues are mitigated by not running Javascript and disabling loading of remote resources, by default. Then it's as safe as a web browser with NoScript.

The problem with HTML mail in my opinion is simply that it is overused. Often it is unnecessary bloat, and plain text works just fine.

</comment></comment></comment></comment><comment><USER7> From what I can see this product wouldn't be replacing email for a single person. Only possibly for narrow use cases of email where you are accepting and managing submissions of some sort.

Also I would assume that the product also uses email, or does the person submitting go through a web app for the whole process.

I think this is purely a case of a link bait title and an article that does a poor job of explaining what the product actually does. Which isn't ideal as the method your startup first gets exposed to a wider audience (first time I have seen it anyway).

</comment><comment><USER8> This has nothing to do with how I use email, but does look like a useful tool on its own. I don't understand the "replace email" branding at all -- maybe it's "replace email for people who are currently abusing email in bad ways".

</comment><comment><USER9> their homepage doesn't even mention email. talk about a linkbait title

</comment><comment><USER10> I think we should pause before having a serious discussion about an interface replacing a protocol.

This is like Google's pitch being "Our search will dominate because we use a single text field, and we have a 'surprise me' button."

If you want to "replace email" you have to replace its infrastructural value to the internet too, not just the superficial day-to-day convenience of messaging. As long as every website requires email to register, messaging is a secondary consideration.

I think that 750k could have been used for a failure-less-obvious.

EDIT: for tone.

</comment><comment><USER11> I don't think there will ever be a single "email killer".

Email is a really general purpose tool, but I think we will continue to see tools that take out a small chunk of email use cases.

e.g. google docs, IM, facebook messaging

</comment><comment><USER12> Sounds like Google Docs?

</comment><comment><USER13> whatever

</comment><comment><USER14> This will NOT replace email, especially in the corporate world. You only need to spend a week at a relatively large corporation to clearly see why.

Look at what we have now - basecamp, all kinds of free instant chats, group video chats, all kinds of organizational SaS, etc etc etc. Yet we still have ridiculously long email chains that often branch off and start to have a life of their own.

Why? Because

1) Everyone knows how to use email. Most employees don't want yet another way to communicate.

2) Your average office employee is pretty... average. And roughly half of the employees are dumber than that.

3) Training is expensive. One quick demo on a projector will not train your employees to use some new software. It's like half-life, 50% will learn after a month, 75% will learn after another month, etc.

4) You will always have employees who don't get this new software, many will probably not give a shit about learning a new tech, while they have a perfectly working way of sending a message. They will realize that when they change jobs, chances are, they won't be using this new software. But email will be there.

5) It is similar to the craigslist syndrome - it's awful, but everyone uses it, because... everyone uses it.

<comment><USER15> > 1) Everyone knows how to use email. Most employees don't want yet another > way to communicate.

This simply isn't true. Most people don't know how to use email, which is why these stupid memes of "everyone hates email" and "email must be destroyed" persist. What people hate is email being used in a dumb way. Or to be more blunt: People hate dumb people. No surprise there, really. So a solution is to get better at getting rid of dumb people. One way to do this is to persist in using email well, and demonstrating (with persistence and persuasion) the better way when rolling across crap use.

This is one of those (rare) situations where the technology and infrastructure is fine; the people using it are the problem. Email can be incredibly effective when used correctly.

Mind you there are certainly email clients which make it far too easy to use email poorly.

<comment><USER16> I think there's a vast sea between "people who don't know how to use email" and "computer literate", and it's disingenuous to make that a false dichotomy. There's a large population of people within biopharma, manufacturing, tech, and financial corporations, software engineers included, who are really fine tweaking and managing their email filters and don't give a damn about "email killer X", the reason generally being that the cost of learning a new "email- replacement" system often outweighs its benefits.

Which is not to say that you don't have a point either, but rather just that your assertion of "simply isn't true" well...isn't true.

</comment></comment></comment><comment><USER17> Is that a wise tag to lead with? Even if it were better articulated or better designed?</comment>


How to acquire 100000 users for an app like BeTickled? - <AUTHOR> Hey all the smart folks with smart ideas willing to help a fellow founder, I need your inputs.
BeTickled is an app we built for local friendships. Details on website https://www.betickled.com.
We launched on App Store 2 months back and have few thousand users. Android is coming next week and will do a full launch in August.
How best to scale it to 100,000 users in 4 months?
Any ideas? <comment><USER2> Social networks are the hardest user bases to build. Just ask Google.

If anyone knew a good, universal, repeatable strategy for this, they'd be a billionaire. It's kind of like asking, "How do you write a hit song?"

Unfortunately the winning formula changes with time, location, and the purpose of the app.

One thing I'll say about your name (not sure if you're in the US or not): it's hard to say out loud with a straight face, and it could come across as creepy to invite someone to it. "Tickle" is just not a word I'd use outside a kids app.

Good luck.</comment>


Ancient people left a frightening message for us, and scientists just found it - <AUTHOR> https://bgr.com/2017/04/25/rock-carving-comet-research-turkey/ <comment><USER2> That article is remarkably low on content --- it doesn't even name the archeological site! It's Göbekli Tepe, of course.

The PDF doesn't work for me either, but here is the Google Cache version:

 _DECODING GÖBEKLI TEPE WITH ARCHAEOASTRONOMY: WHAT DOES THE FOX SAY? Martin B. Sweatman and Dimitrios Tsikritsis_

[http://webcache.googleusercontent.com/search?q=cache:m4rmExq...](http://webcache.googleusercontent.com/search?q=cache:m4rmExq71C0J:maajournal.com/Issues/2017/Vol17-1/Sweatman%2520and%2520Tsikritsis%252017%25281%2529.pdf+&cd=1&hl=en&ct=clnk&gl=kr)</comment>


"This is it." Alien contact – a Twitter thread - <AUTHOR> https://threadreaderapp.com/thread/1088883750857887744.html?refreshed=1548556111 <comment><USER2> I still don't understand what I'm seeing. Was this a choose your own adventure Twitter thread?

Edit: Yes, it was. This wasn't immediately obvious since the Thread Reader site strips out all of the polls. Original Twitter thread is here: [https://twitter.com/vornietom/status/1088883750857887744](https://twitter.com/vornietom/status/1088883750857887744)

</comment><comment><USER3> The Twitter thread format is so awful for this. I saw this on Twitter the day she wrote it, but she was apparently only half done. The last line I read was "Nobody is going to believe your first day in the new job story." which sounded enough like a conclusion that I thought it was over. Went away feeling totally underwhelmed, and if I read it over again now it's just not going to be the same.

<comment><USER4> Agreed. But viewing this on twitter makes me think, maybe they just discovered their product haha.

Best Twitter experience, hands down.

</comment></comment><comment><USER5> Ad for apple products?</comment>


Object-oriented techniques in C - <AUTHOR> http://dmitryfrank.com/articles/oop_in_c <comment><USER2> This seems to just seems to be replicating the functionality of C++ in C. The only reason he gives for not using C++ is lack of C++ compilers for embedded CPUs. I think a better approach for the long term would be to use a C++ -> C transpiler (as much as I hate that word).

<comment><USER3> I'm saddened by the author going to this trouble. Embedded cpu selection doesn't happen in isolation - or at least, it shouldn't. The available tools are a large part of why you would pick chip A over chip B. If you don't have a C++ compiler, and you end up having to re-invent C++ in C, then maybe you should have picked the chip with decent tools.

If this project really did require re-inventing C++ in C, it must be justified by being fairly large. In which case, a low-end ARM (Cortex M based) microcontroller would have been entirely suitable. All ARMs have multiple C++ toolchains which support them.

If this is a microcontroller you end up lumbered with, and didn't choose, then fair enough, but this effort should be labeled for the hack that it is. This is not best or even good practice.

<comment><USER4> > If you don't have a C++ compiler, and you end up having to re-invent C++ in > C, then maybe you should have picked the chip with decent tools.

So the software engineers are the only ones on the project who get a say as to what chips get used?

<comment><USER5> No (and that isn't what he said), but surely they should get a say, right?

<comment><USER4> pslam basically did in his next paragraph:

> If this project really did require re-inventing C++ in C, it must be > justified by being fairly large. In which case, a low-end ARM (Cortex M > based) microcontroller would have been entirely suitable. All ARMs have > multiple C++ toolchains which support them.

ARM is _not_ entirely suitable for any application just because you have complex (for some definition of complex) software.

<comment><USER3> No, but the software impact of choosing a particular piece of hardware should absolutely be part of the system design process. If it is not, then you are part of a project with bad leadership, or very, very old-fashioned architects.

It's not just ARM - there's plenty of other CPU architectures with modern Clang, GCC, or other toolchains with C++ support. Given that this is a large code base (justifying this amount of work), this cannot be a "tiny" microcontroller, as in 8 bit, and needing to run on microamps. I cannot believe that there were not C++-capable microcontrollers available which would have done the job, without breaking the bank.

<comment><USER6> Doing it at lowest cost is the point. Because even if you don't lower your cost, your competitors will.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Isn't there some way to emit C from C++? Wouldn't a capability like that and using C as a host language completely bypass the need for emulating OOP in C, by just letting you write C++? That seems like it would be far more manageable, and since it's compiled, not susceptible to some of the major downsides commonly associated with the technique (in JS).

<comment><USER8> The emitted code is highly name mangled - one of the reasons why you encapsulate the C code in "extern C" [https://en.wikipedia.org/wiki/Name_mangling](https://en.wikipedia.org/wiki/Name_mangling)

<comment><USER7> That seems like a problem that has quite a few possible solutions: deterministic name mangling, hinting in the source as to how the name should be mangled, an external mapping of mangling exceptions and/or rules to be used by the transpiler. None of those are mutually exclusive, all could be used together.

<comment><USER9> It's more than that - there's extra information that's compiled alongside your runtime data structures whenever you write C++. For example, every class with virtual member functions has a vtable, and every object of such a class has a pointer to the vtable. Every time you access a virtual member function, it's indirecting through the vtable to find the particular address to call, and then calling it with the object itself as the first argument.

If you got rid of name mangling (and a few other C++ features that are besides the point), you could certainly call C++ from C. The thing is - your C calls would look exactly like what the article is suggesting. That's why it's important to learn this technique: it is what your C++ compiler is doing under the hood. Indeed, the very first C++ compilers were just preprocessors that transformed C++ syntax into the type of vtable + base class + first parameter indirection that you see here.

<comment><USER7> Yes, so while this technique would be harder to adopt for a library, or at least harder on the users, for an application where you don't really need to worry about people using C calling into your code, it would be fairly useful. A short HOWTO on how to call from C using the necessarily included and emulated C++ vtable bits would make calling in from C possible and easier where required, but you could still reap the benefits of non-C features while sticking with a C toolchain at the lowest level.

<comment><USER9> Usually an 'extern "C" { .... }' declaration is easier if you control the C++ library code.

<comment><USER7> I see what's being talked about now. I misinterpreted meson2k's original reply, so haven't really been on the same page as you or him.

If _current_ C++ to C transpilers don't handle naming well, that's a problem that should be worked on.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> this approach is similar to the one that GObject uses, though stripped down a bit for embedded. i haven't used it in years, but it worked great with GTK+. the only downside i remember is the overhead of the virtual function calls (in contrast, the jvm is able to factor out the virtual call in many cases at runtime)

one advantage of using something like this is it forces you to really think about what makes something OO and gives you a deeper appreciation of it. i'm a java programmer now, but to this day i still prefer object oriented C to C++

</comment><comment><USER11> I've found that, in the embedded world at least, the overhead this adds (in terms of flash/rom and ram) can be fatal. That said, there are some more implementations of this here if anyone is curious: [https://github.com/ryanbalsdon/libr](https://github.com/ryanbalsdon/libr)

<comment><USER12> > the overhead this adds (in terms of flash/rom and ram) can be fatal.

I know you list the resources, but how does this approach add overhead? (how does it use those resources more than a "C" approach would?) Most of the constructs in C++ only cost anything if you use them, so you only pay if you need the feature; further, the runtime costs of most C++ features are pretty much exactly what's required for that feature… so if you were writing C, and you needed the same functionality, how would you avoid paying the same cost?

</comment></comment><comment><USER13> EFnet's infamous Zhivago (from #c) has a great article about OOP in C - [http://www6.uniovi.es/cscene/CS1/CS1-02.html](http://www6.uniovi.es/cscene/CS1/CS1-02.html)

</comment><comment><USER14> How badly does this impact optimizations? First you add an extra function pointer for any member, even if it's not virtual. Then since you're always calling via a function pointer -- do compilers notice when fps are assigned and never modified and do inlining and so on?

Also the first technique doesn't feel like OO in any meaningful way. Defining a state object and passing it to functions is exactly what you'd do in say, a functional programming language, or even in regular old imperative code.

<comment><USER15> > _First you add an extra function pointer for any member, even if it 's not > virtual_

Wrong. If some function is not virtual, there's no point to add it to vtable; so, it's just a regular function.

> _Also the first technique doesn 't feel like OO in any meaningful way._

Really? Of course I can be wrong, but for me, defining a state object and operate on it only through methods (i.e. functions that are given a pointer to state object) is exactly what is called an OO style.

<comment><USER14> Thanks for the correction. I had misread and thought all functions were called with member syntax.

I guess in simple cases like this the difference between OO and other styles are pointless. I'm just thinking that if I were to write it in a functional language, it'd probably a very similar API, though possibly/probably returning a new state vs modifying.

</comment></comment></comment><comment><USER16> Also check out: Simply Object-Oriented C --> [http://www.codeproject.com/Articles/22139/Simply-Object- Orie...](http://www.codeproject.com/Articles/22139/Simply-Object-Oriented-C)

</comment><comment><USER17> Unmaintainable and extra complexity just to emulate a paradigm that C wasn't designed for.

<comment><USER15> Again, if we use it correctly, the resulting thing is much more maintainable than the code with switch-cases instead of virtual methods, and so on.

By the way, similar approach is used across the Linux Kernel: check, for example, the book "Linux Kernel Development" by Robert Love, especially the discussion on the virtual filesystem.

<comment><USER17> Every solution feels great and neat in the beginning until you wake up one day and feel sick to your stomach from the mess it has created.

Most vtable like implementations in the kernel are nothing more than struct of function pointers, and this is almost exclusively.

<comment><USER15> As nostrademons pointed out above ([https://news.ycombinator.com/item?id=10261375](https://news.ycombinator.com/item?id=10261375)), if you feel that some tool you've used has created mess (so that you even feel sick to your stomach), it's most likely not because the tool is bad, but because you've used it in inappropriate way.

</comment></comment></comment></comment><comment><USER18> "The danger in trying to force object-oriented concepts onto a C base is to get an inconsistent construction, impairing the software development process and the quality of the resulting products. A hybrid approach yields hybrid quality. This is why serious reservations may be voiced about the object- oriented extensions of C described in chapter 20. To benefit from object- oriented techniques, one must use a consistent framework, and overcome the limitations of languages such as Fortran or C which regardless of their other characteristics -- were designed for entirely different purposes." Bertrand Meyer, Object-oriented Software Construction, 1988.

</comment><comment><USER19> This interesting article reminded me of this post by Rob Pike from some time ago: [https://plus.google.com/+RobPikeTheHuman/posts/hoJdanihKwb](https://plus.google.com/+RobPikeTheHuman/posts/hoJdanihKwb).

While I've been a C++ programmer since my uni days, I think algorithms and data structures should come first, and I don't like the idea of "bending" programs to make them fit nicely within the OO paradigm.

</comment><comment><USER20> Do _NOT_ use these techniques please!

I have experience of an early nineties project that was entirely structured like this and trust me, it ends up as a disaster.

C is not meant to be OO, consequently all the tooling in editors and the like do not understand the links between classes and methods.

What it ends up like is an impenetrable mess with all the mechanics of C++ exposed but being impossible to navigate.

again... please do _not_ do this in any project... for the sake of any who will follow you in maintaining your code!

<comment><USER9> Bah. It's a tool. Just like any tool, you should have it in your toolbox, and use it when appropriate.

When I hear about C programs that were a disaster because they used OO-like techniques, the operative word is usually "disaster" and not "C" or "OO". In other words, there were other things wrong with the project that had nothing to do with the selection of language or programming paradigm, like hiring inexperienced programmers or mandating a single programming paradigm for the whole codebase.

Good C code will have a lot fewer objects than say, Java, because most of the things you want to use C for, you can accomplish just fine with structs and functions. But you shouldn't shy away from a struct full of function pointers or an ADT with opaque pointer types and appropriately-namespaced member functions just because you're afraid a maintenance programmer won't get it. It's their responsibility to learn the language.

<comment><USER21> Seconding the idea that you don't use something like this prolifically. The point is to only go slightly past the limits of the tooling and still primarily be writing C in the style that C is best at.

For similar reasons, "cute" macro-heavy C code tends not to survive long-term, because it breaks too much tooling.

</comment></comment></comment><comment><USER22> A part a of series of articles on HN: How to %feature_from_c++% in C (when you could have used C++)

<comment><USER8> or when memory constraints prevent you from using libstdc++

<comment><USER23> You can get C++ OO without linking in a whole STL. IIRC it is the C++ equivalent of -ffreestanding in C. Given that popular toolchains like GCC and IAR offer C++ support to micro controllers as small as ATtiny 8-bit AVR micros, I don't see the necessity to reimplement C++ in a hamstrung C form.

I'm currently writing a binary parser library using C++ but without the STL. I'm able to use range-based for loops, zero-cost iterators, and other features without any dependencies on a C++ STL library. After optimization, the generated code is essentially what the C equivalent with all the boilerplate would compile down to. There are plenty of OS kernels written in C++, you just have to pick the appropriate C++ subset. ;-)

Regardless, I enjoy the stricter typing in C++ that generates essentially same code as C with OO tacked on but with less boilerplate.

</comment></comment></comment><comment><USER24> I don't feel like the crc32 example is a good one. Maybe the game entities example would have been better...

<comment><USER12> IIRC, MD5 (and probably the other hashs) are implemented in exactly this form in OpenSSL.

I can't really think of a more straightforward way to implement CRC32, frankly, especially assuming that maybe you don't want to force the entire buffer to be present. If you did, you could `uint32_t crc32(unsigned char * buffer, size_t len);` — but you can implement that function in terms of the interface in the article, and if you pick up a bit of inlining from an optimizer, I think it would end up being just as efficient, too. (If you don't, you'll end up with some extra pointer dereferences, but again, the streaming interface supports streaming.)

And perhaps to stress what some other commenters are missing: it's not "you should always OO in C"; it's that _if_ you want an interface to compute, while streaming, the CRC32 of a stream — you need to store that state somewhere, and you need to act on that state somehow. That state is an object: it has a setup, and potentially a teardown, and two relevant methods: feed it data, and get the computed hash.

<comment><USER25> CRCs or MD5 or other hash sums don't require inheritance or other OO tricks or even constructors or destructors (apart from zero-initialization). The state is just a single integer. For other hashes, the state might be slightly more complicated but there's still no need for fancy OO.

If you want to build a system where you can change the hash function at runtime, you might need some kind of interface or inheritance. But if you end up needing a virtual call per byte (or per a small chunk of bytes), you're killing your performance.

And besides, there's so few hash functions you end up needing in practice that a simple switch-case would do the same with less boilerplate and probably give better performance because compiler optimizations can take place (virtual calls tend to prevent many optimization tricks).

I agree with GP... The choice of CRC was a poor example for an article about OO in C. Something related to filesystems or device drivers would be vastly more practical.

<comment><USER12> > _CRCs or MD5 or other hash sums don 't require inheritance or other OO > tricks_

Given some of the other comments, I think this ought to be stressed though… OO doesn't strictly require inheritance, or vtables. A fair number of classes in the C++ STL don't use those features, for example.

It's not that the state is a single integer, either, it's that the concept of a state exists; having a separate type (with the functions surrounding that separate type) exist to embody that concept, and can change a function from an ambiguous "what goes in this uint32_t arg?" to a very obvious md5_state_t.

> _or even constructors or destructors (apart from zero-initialization)._

Just a nit: MD5 requires initialization that is more than just zero- initialization.

> _probably give better performance because compiler optimizations can take > place (virtual calls tend to prevent many optimization tricks)._

This is about the most concrete argument against vtables (but hardly against OO in general) thus far, and I'd still love more explanation: what makes a branch more optimizable than following a pointer?

</comment></comment></comment></comment><comment><USER26> This is probably a stupid question, but here it goes:

Embedded platforms tend to have size limits. Would this increase the size of the source code? Seems a bit verbose to me.

<comment><USER15> Surely it does have some overhead. And, by the way, passing arguments to function has an overhead as well, comparing to globals. But, how often would you recommend use globals?

The more interesting question is: how much overhead? And the answer is: it depends on the MCU. For example, some 8-bit PICs don't have silicon support for indirect function call (i.e. by function pointer), so they work around this problem by saving function address to the stack and execution 'return' instruction. It works much slower and code size increases notably. I don't use these techniques on these chips.

But for 16- and 32-bit MCUs that I was working with, it works flawlessly. For most of our projects, the overhead is much less significant than the maintainability we get with this approach. As I said in another comment, engineering is all about tradeoffs.

<comment><USER12> > _don 't have silicon support for indirect function call (i.e. by function > pointer), so they work around this problem by saving function address to the > stack and execution 'return' instruction._

While no doubt this is true, if you have an indirect function call in C++ OO code, how do you _not_ have it in C? That you had it in C++ implies — I hope — that you needed it. The C code can't simply whisk that need away. (Or, if it can, so can the C++…)

</comment></comment></comment><comment><USER27> Hmm...those who don't understand Objective-C are doomed to reinvent it, badly? (Yes, have used OO C techniques of different sorts and implemented ObjC compiler/runtime).

<comment><USER28> Isn't this article's implementation of OO C based on C++?

<comment><USER27> "...badly" ;-)

<comment><USER29> Method hashes (ObjC) != Vtables (C++). The former allows runtime introspection and modification that the latter doesn't, and the latter allows performance that the former doesn't.</comment></comment></comment></comment>


Ask HN: Are there any freelance "problem solvers" out there? - <AUTHOR>

I'm interested in a very specific kind of work. I want to consult in many different fields, applying concepts from math and computer science to solve hard computational problems. Are there any readers that do (or know someone who does) this or something similar? <comment><USER2> It doesn't matter that someone is doing it or not, only that there is a market for it. It's up to you to find that market (or to help it along by creating a market for your services.)

So, you need to start doing some research into connecting with clients.

Setup some social networking scrapers / alerts to look for keywords which might indicate someone is looking for something you can help with. A lot of people use these services as lazy ways to troll for talent.

Look through the jobs boards like Authenticjobs and all the others like it. Some jobs are full time, others are freelance positions. Either way, you could reach out to good matches and see if they would be willing to pick you up for freelancing.

Find communities which are targeted towards people with your skill set. These are great for general discussions, but also for people who go there looking for hired guns.

Look through Elance and Odesk (these are the only two worth bothering with) to look for job and service providers which might be matches for your skills. Look through the service providers history to see what sort of hits / rates they have been getting. Look at the companies they were being hired by. Obviously if there are jobs posted, then you could apply for those. These places are hit and miss for getting work, but they are decent for research (maybe you could contact some of these places directly.) Sometimes people post crap jobs, but sometimes good potential clients post there because they don't know where else to look.

Build up an online presence for the services you can offer. Find competitors and copy them until you can beat them. If you are in a large market (NYC) then target local.

Go niche by building your own market or by specializing. Build a service and then market that service to people who don't know how much you could really help them. Pivot based on feedback.

Apply your skills to your own business ideas (and ship!) Your skills can give you a competitive advantage if leveraged properly and people will notice / respect your success. Also, if you are able to build an income stream outside of client work, then you don't have to worry so much about landing gigs. Properly applied, your skills become far more valuable and you can charge whatever you like.

I use these tips mostly for web development, but they should apply to anyone looking for freelance work.

</comment><comment><USER3> If it's related to data crunching / classification / recommendation / ml , do take a look at <http://kaggle.com></comment>


Ask YC: Partial/No Funding Arrangements? - <AUTHOR>

Maybe YC already does this, but has YC ever considered accepting some applicants w/o giving them funding (or some type of partial funding)?
These accepted applicants would still be invited to all the YC stuff, but they would just be at different funding levels.  This type of arrangement could increase the number of YC startups per round and subsequently increase the odds of finding a "home run."
This, of course, assumes that the YC can handle more founders per round. <comment><USER3> Money is not the limiting factor.

<comment><USER4> Does this mean YC would make a no-cash investment if the right circumstances arose?

If so, is it safe to assume that YC's target equity position would not differ significantly given to the relatively low value of the cash component vs. mentoring/networking?

<comment><USER5> He means they fund every qualified startup that applies; they have plenty of money. If 100 promising startup teams applied, they'd fund all 100 of them.

<comment><USER6> Oh please, what nonsense. Your statement doesn't even match up with what pg writes.

<comment><USER3> Emmett's right.

<http://news.ycombinator.com/item?id=120949>

<comment><USER6> No, Emmett is not right because there is no definition of qualified. It is a meaningless statement. The problem with the statement is that it implies that you are not funded you are somehow not qualified. What does that mean?

</comment></comment></comment></comment></comment></comment><comment><USER7> I surely would love if YC did this. I have a design for a database/social net/marketing product for a niche of 100,000 executives just like myself. I will be late for this round of application submissions. I do not need the money, but would love to have the mentoring and interaction with other founders as I am not a software developer. I know exactly 2 programmers that worked in good startups and while they gave good advice they have their own life. One of them wants nothing better than to walk around in South East Asia and the other has his own product he spends 110% of his time on. While friend suggestions are helpful I would be delighted to get get some pointers. One of which I need most is how to find a developer co-founder

</comment><comment><USER8> Seems like it would dilute the pool of companies and create enmity between founders. As far as I know, funding levels already vary between accepted startups, but the whole point of investing is the hope of return -- if YC invested nothing, what would they even get out of a "home run"?

<comment><USER4> In my case I have money from a previous successful startup, will be moving to the US, and put a premium on local knowledge and the right introductions - <USER2> me and others in the same position there is little value in taking small amounts of cash, but the value of everything else YC offers could be quite significant. Surrendering a percentage of your company for a higher value return is quite reasonable.

<comment><USER8> Good point.</comment></comment></comment>


Scrap the SCP. How to copy data fast using pigz and nc - <AUTHOR> http://intermediatesql.com/linux/scrap-the-scp-how-to-copy-data-fast-using-pigz-and-nc/

<comment><USER2> I don't get it.

        nc -l 8888

Doesn't make any encryption, right?

If the answer is yes, then why they are compared here? Anyone on public network might sniff what you are actually sending / receiving.

<comment><USER3> You could try piping it through ssh, I don't know how that would effect the speed though.

tar -cf - /u02/databases/mydb/data_file-1.dbf | pigz | ssh user@destination "pigz -d | tar xf - -C /"

<comment><USER2> Yeah, but it will need executing commands on both hosts. SSH works on top of SCP and only needs running sshd on the remote host and access to that machine.

All those solutions ( from the OP ) are faster, but you will need some setup, before you could use it from one host remotely and in the end you might end up using good old SMB or NFS which will give you speed ( [http://www.linuxquestions.org/questions/linux- networking-3/s...](http://www.linuxquestions.org/questions/linux- networking-3/smb-vs-nfs-performance-4175502751/) )

</comment></comment></comment><comment><USER4> Thumbs up for pv which shows the progress bar. Using parallel compression may have serious impact on CPU resources, so it needs to be balanced.

Have you also done any testing with ssh + gzip?

Also, as you note at the end, the security concerns are not trivial.

</comment><comment><USER5> I wonder how this would compare to rsync using the '-z' (compress) option.

<comment><USER6> Speaking generally, rsync is faster than straight copying if the files partially exist in the destination first. If they don't exist, or they've changed completely, rsync is slower due to the checksumming on both sides.

<comment><USER7> There is no checksumming if the file doesnt exist..

</comment></comment></comment><comment><USER8> Looks like he reinvented _scp -C_?

<comment><USER4> pigz does parallel compression, taking advantage of multiple cores. I am not really sure if you can achieve this with scp.

<comment><USER9> You can use pigz with SSH as you can pipe commands over SSH (google it). If nc is faster than scp, I guess encryption is a factor, but then they're not comparable solutions to the same problem.

<comment><USER4> Sure you can :). Naturally transfers via SSH "suffer" from the encryption overhead but prevent MITM/network sniffing etc. The author points out that (only) in a trusted LAN you could use this solution to make things go faster.

I guess the title should be a little more mild - scp isn't going away, or rsync via SSH for that matter.

</comment></comment></comment></comment><comment><USER10> I used pigz for compressing and then rsync for transferring my (Postgre)SQL logs. The reason being that pigz has a built-in "rsyncable" mode, which allows rsync to avoid sending the whole log over always. The multicore compressing is just icing on the cake. gzip has a patch for an "rsyncable" mode, but it's no longer properly included in the distro's I use (debian).

At some point, the only way to copy data faster is to not copy it at all.

I wrote a blog post about it here: [http://www.aktau.be/2014/10/23/pg-dump- and-pigz-easy-rsyncab...](http://www.aktau.be/2014/10/23/pg-dump-and-pigz- easy-rsyncable-backups-with-postgresql/)

</comment><comment><USER11> The problem is that SSH uses a terrible buffering algorithm. This fixes it:

[http://www.psc.edu/index.php/hpn-ssh](http://www.psc.edu/index.php/hpn-ssh)

It's able to consistently fill 1G ethernet links.

<comment><USER12> > a terrible buffering algorithm

The main difference now it that hpn tweaks the tcp window to function better on high-latency links.

> It's able to consistently fill 1G ethernet links.

Between two stock Debian sid laptops:

        dd if=/dev/zero bs=1048576 count=4096 | ssh <otherhost> dd of=/dev/null
        8388608+0 records in
        8388608+0 records out
        4294967296 bytes (4.3 GB) copied, 37.0848 s, 116 MB/s

That's 90% of the theoretical bandwith, right?

If you're really transferring huge file files across fat WAN links, why not use GridFTP like the supercomputing centers use? They transfer TB daily.

I wouldn't mess with patching openssh, especially with patches for old versions of openssh.

</comment></comment><comment><USER13> xz + scp will still be faster than this. its not about the speed at which scp goes, is that the author doesn't compression before sending over scp, but does when he sends over nc and what not...

heck you can just use rsync over SSH for simplicity.

<comment><USER14> > xz + scp will still be faster than this

That's not the case if the data you're sending is already compressed. But you're right that it's not a fair comparison. scp/ssh also has integrated compression with "-C".

<comment><USER13> gzip: tar -cz /home/me/source/directory | ssh target tar -xz --directory /home/you/target/directory

xz: tar -cJ /home/me/source/directory | ssh target tar -xJ --directory /home/you/target/directory

ssh -C won't be as good. in particular with a recent xz that's threaded it will probably be faster than OP's with a good CPU

</comment></comment></comment><comment><USER6> One good alternative I've used is socketpipe[0]. It handles logging into the remote server, setting up a listener, and then piping the data over.

But, that tunnel still isn't encrypted. So, either encrypt your data first, or setup some vpn tunnel. The inefficiency of scp isn't just due to the encryption, there's overhead in the ssh protocol.

0 [http://freecode.com/projects/socketpipe](http://freecode.com/projects/socketpipe)

<comment><USER15> A VPN setup seems like overkill. You can run stunnel and run a daemon to loop back through the stunnel configured connection. It's not quite as easy to use offhand like scp, but it's certainly not as awkward to try to use as a random series of OpenSSL commands either and it'll be easier to understand what you tried to do later on the production machine.

</comment></comment><comment><USER16> Combine this with docker export / import and you got yourself an easy way to copy images between servers :)

If you still have the setup up and running, throw this in the mix:

      rsync -a -e 'ssh -c arcfour' source dest:destpath

and

      rsync -az -e 'ssh -c arcfour' source dest:destpath

still encrypted! The latter enables compression, but I've found it slower when dealing with several small files (ex: source code files)

<comment><USER13> arcfour is arguably close enough to not encrypting these days ;)

</comment></comment><comment><USER17> Maybe you can set up stunnel between the two hosts for SSL goodness, point netcat to the stunnel port, and call it a day.

</comment><comment><USER18> Surprised to see NC slower than SSH on network throughput. All of the authors benefits came from compressing the payload first.. Curious if enabling compression at the highest levels for SSH would have worked, or as others suggested, piping pigs over the SSH connection itself.

</comment><comment><USER14> scp's beauty is in its ubiquity. That host over there that I want to copy to? I need no extra configuration there because sshd is already running.

I agree that scp is dog slow and it can be pretty frustrating. As others have mentioned, cranking down the cipher provides a modest improvement. Ad-hoc netcat based solutions like this one are the way to go if you need throughput and not security.

</comment><comment><USER19> xz supports multiple threads, if CPU is no object. If you want to stream the results why not use ssh's -F option to create a secure tunnel, particularly if the required bandwidth is not high.

<comment><USER20> Which version of xz started supporting multiple threads?

My version latest from Debian testing (yes I know it is not cuting edge) says in man page: Multithreaded compression and decompression are not implemented yet, so this option has no effect for now.

<comment><USER13> they have had it on the git repo for quite some time now (months i think), but distros generally dont have it yet.</comment></comment></comment>


Show HN: Strime – Video project management made simple - <AUTHOR> https://www.strime.io <comment><USER2> You've probably thought of this & just haven't got around to it yet, but you might want to localize the screenshots on the English & Spanish pages, not just the text. Though it's also really cool to see a French startup.

The page headline should probably be "Simplify video project management", ie drop the 's' in projects. "Projects management" sounds awkward to me.

That front page image/cartoon is awesome. It makes me want to signup regardless of what it is!

<comment><AUTHOR> Thanks a lot! You're right about the screenshots, we realized that are now working on it. I'll also drop the "s" on projects as you advised. Thanks for these tips!

</comment></comment><comment><USER3> Up on the top right, there is language selection text: FR EN ES. Whatever language is currently active is underlined. This is a little bit fighting against convention. Please change that (i.e., active language should not be underlined; inactive languages should be underlined so that a click trigger will cause action).

<comment><AUTHOR> Umh... You shouldn't have the 3 underlined. I'll check that. Thanks for letting me know about this.

<comment><USER3> I must have miscommunicated.

Here is your website right now: [https://i.imgur.com/CnChJns.png](https://i.imgur.com/CnChJns.png)

You need to make changes such that it looks like this: [https://i.imgur.com/E2TsC1J.png](https://i.imgur.com/E2TsC1J.png)

<comment><USER4> you might not be a native English speaker, but "You need to make changes" comes across as rude. A better way to phrase the sentence would be "I'd recommend you change it such that it looks like..."

</comment></comment></comment></comment><comment><USER5> I'm not sure I completely get what you're doing, and I'm sitting here wondering "You're a video product and you don't have a video demonstrating your product??" or did I miss it?

<comment><AUTHOR> We've got one, but for the moment it's only in french. We're in the process of translating it, so we have not put it on the website for the moment, but here you go: [https://www.youtube.com/watch?v=itzBQSq3zH8](https://www.youtube.com/watch?v=itzBQSq3zH8)

</comment></comment><comment><USER4> This is a really cool idea, I looked at it, and said "gee why didn't I think of that?" which is always a great sign :D

<comment><AUTHOR> Haha! Thanks a lot man!

</comment></comment><comment><USER6> Pardon my rudeness, but what is the monetization strategy here?

<comment><AUTHOR> You're not rude, the question is legit. We're working on a B2B version of the app, dedicated to big companies.

<comment><USER6> Thanks!

</comment></comment></comment><comment><USER7> Looks very good!!

<comment><AUTHOR> Thanks a lot!

</comment></comment><comment><USER8> Seems similar to frame.io, is that right?

<comment><AUTHOR> In some ways, yes. Frame used to be much more complex than what we are, even though they recently redesigned their app.

</comment></comment><comment><USER9> Looks great!

<comment><AUTHOR> Thanks a lot!

</comment></comment><comment> ro-_-b cool project!

<comment><AUTHOR> Thanks man!</comment></comment>


In praise of complexity - <AUTHOR> http://sinofabit.tumblr.com/post/45541443769/in-praise-of-complexity

<comment><USER2> Sorry but there is no information in the post to justify that using C or assembly is more simple than using python, ruby or clojure. There is also no justification as to why making the code in a library or server simple would result in more complexity down the road. Having written servers, applications and libraries before, I'm left to wonder why making their codebase simpler would result in more complexity down the line. Also I wonder if complexity is being confused with (expressive) power. Simplicity is always a good thing. Lack of others things might not be. The trade-off is usually between simplicity and thought+work put into something. Not functionality/power and simplicity. The shortcut often taken is making things more complicated to make them more powerful without making the effort necessary to make them simple.</comment>


Tell HN: We just launched Stre.am for Android - <AUTHOR>

Hey HN! Longtime lurker, occasional poster here. I just wanted to share that today my team launched Stre.am for Android, a mobile video broadcast app with an emphasis on simplicity.
https://play.google.com/store/apps/details?id=com.sparc.stream
We're eager to have as many eyeballs on the new app with as much feedback as possible (with mostly obvious ulterior motive of maybe reaching the "Top New Free Android Apps" category in the Play store...).
Happy to answer any questions about the app itself or the technology we used to build it (primarily Node.js+Express, Java+Play and Scala+Akka on the backend, and native development for the mobile clients).
The app itself is designed to be as self-explanatory as possible, but the general idea is to sign up, hit the green record button, and your video shows up on stre.am with minimal delay.  Thanks for reading! <comment><USER2> clickable link : [https://play.google.com/store/apps/details?id=com.sparc.stre...](https://play.google.com/store/apps/details?id=com.sparc.stream)

<comment><AUTHOR> Thanks, didn't realize when I posted it that urls aren't linkified in submission text.

</comment></comment><comment><USER3> You may want to put this under the Show Category

<comment><AUTHOR> Thanks - do you think it's best to repost as such?</comment></comment>


Show HN: I made a Metacritic for tech products - <AUTHOR> https://www.metareview.co <comment><USER2> On iPhone/Safari I can click in the 3 boxes to see more laptops, phones, or tablets. But if I click on the titles below it does work. I think you should add some "more" buttons to clarify there's more than just the 2+2+2 in the home page. Good stuff otherwise, keep up!

</comment><comment><USER3> Are there only four products in each category? (Browsing on phone if it's a bug).</comment>


DMCA takedowns GitHub has received - <AUTHOR> https://github.com/github/dmca/

<comment><USER2> Just browsing a few of the Sony DMCA notices, I can't help but notice something strange:

       [5] Please act expeditiously to remove the file-downloads found at the following URLs:
       http://www.fileserve.com/file/cWAKEDR
       https://github.com/kakaroto/ps3keys
       https://github.com/kakaroto/ps3tools
       ...

Fair enough for the ps3keys and tools, but there's a URL for fileserve there. That's not github, wonder why they think they should send that URL to github.

<comment><USER3> Every program has bugs.

<comment><USER4> When the program makes legal statements under penalty of perjury on behalf of its operator, the program should not be permitted to have bugs.

<comment><USER5> IANAL, but isn't it perjury, or at least something subject to civil sanctions, to attest to _facts_ in this manner without personally performing enough due diligence to ascertain the _facts_ are at least probably correct? The Bar Association should be interested in its members signing-off on legal documents they have not properly vetted. Perhaps the best course of action is an education campaign directed at the States' Bar Associations.

</comment></comment></comment></comment><comment><USER6> Interesting that Sony was pretty takedown-happy a year ago and then seemingly went silent. Did something change? I can't imagine people stopped creating "infringing" content.

Also of note is the decompiled code with license info still intact, like 2012-07-16-microsoft.markdown. Seems like a dick move to put something like that on github, especially without even bothering to clean up the code or do something interesting with it.

<comment><USER7> Yeah, Sony's requests were regarding the tools that, at the time, could make any PS3 crackable from official firmware.

A year later they have all those old PS3's off the shelves and none have firmware 3.55 or lower, so they appear to not care as much.

</comment></comment><comment><USER8> AirBnb is issuing DMCA requests for their interview questions??

[https://github.com/github/dmca/blob/05885612f96982a7e4062a13...](https://github.com/github/dmca/blob/05885612f96982a7e4062a13a155da46996bd8fc/2012-05-21-airbnb.markdown)

<comment><USER9> Can you really issue a take down for an interview question? The _text_ of one, ok, but the essence of the question itself?

Surely not?

<comment><USER8> I wonder if you have to sign an NDA to be asked the questions? IMO these cutesy interview questions have gone over the top and I think I'm going to use this as my proof.

<comment><USER10> But NDAs are for trade secrets and DMCA is only for copyright.

<comment><USER11> Not to mention that a NDA only provides a way to attack the person who signed it, and has no effect on anybody else even if they further spread the information.

</comment></comment></comment></comment></comment><comment><USER12> This reminds me of all the major flaws in the DMCA, like not being allowed to "circumvent any measure that effectively controls access". The question that's unanswered: if a few lines of code can circumvent a measure, does that measure effectively control access? Either way: didn't stop Cisco from sending Github a takedown for a keygen. (Despite provisions in the DMCA that make distributing the circumvention device legal, like "a person who has lawfully obtained the right to use a copy of a computer program may circumvent a technological measure that effectively controls access to a particular portion of that program for the sole purpose of identifying and analyzing those elements of the program that are necessary to achieve interoperability of an independently created computer program with other programs".

Corollary: is it legal to open a closed door if you have to twist the handle first? What if the spring is tighter than on a normal door?

</comment><comment><USER13> My favorite was the bitcoin one. The complaintant (?) used DMCA to protect the MIT license on some code he wrote. Nice!

<comment><USER14> Link: [https://github.com/github/dmca/blob/master/2012-01-09-bitcoi...](https://github.com/github/dmca/blob/master/2012-01-09-bitcoin.markdown)

</comment></comment><comment><USER15> Not sure if any of those are included here but I have definitely seen links to 'warez' hosted as gists recently.

</comment><comment><USER16> I think it would be interesting to see the responses too

<comment><USER17> There are some posted. Here are a couple: [https://github.com/github/dmca/blob/master/2011-02-03-sony-c...](https://github.com/github/dmca/blob/master/2011-02-03-sony- counternotice.markdown) [https://github.com/github/dmca/blob/master/2012-03-26-deathw...](https://github.com/github/dmca/blob/master/2012-03-26-deathwyrm- counternotice.markdown)

</comment></comment><comment><USER18> Should not github take care of the commit messages?</comment>


I hate Lisp - <AUTHOR> http://funcall.blogspot.com/2009/03/i-hate-lisp.html <comment><USER2> _This_ is exactly what I've been complaining about lately. Hacker News seems to have been mobbed with people who have zero sense of humor and no ability to recognize satire. Hackers like to laugh. They like to laugh at _themselves_ most of all.

I've noticed this trend for the past couple of months...comments and articles that are clearly intended humorously being voted down as trolls, or responded to as trolls, or both. I know we're supposed to be politely nudging these new users onto the path of righteousness and into becoming productive members of the HN community...but how does one teach someone to have a sense humor? I really don't want to be one of those Eternal September types, but hackers like to laugh.

<comment><USER3> _Hacker News seems to have been mobbed with people who have zero sense of humor and no ability to recognize satire._

In my tenure as a hacker I've found that the subset of hackers who don't get satire and seem to have no sense of humor is at least as large as the subset that does. For every cool, funny hacker guy you meet, there's at least one weird, humorless semi-autistic guy waiting to make the next teambuilding outing more awkward.

<comment><USER4> Hey, I just told Jenny she would look way hotter if we were playing Lazer Tag in tight Star Trek uniforms instead of our street clothes. That's a compliment, right? I thought I was _supposed_ to make our new team member feel welcome.

<comment><USER5> You talk to females?

</comment></comment></comment></comment><comment><USER6> I'm pretty sure the title is tongue in cheek, and would be more accurately rendered as "I hated lisp when I first had to learn it", considering e.g. the name of the blog, and posts like these with considerable lispy content.

<http://funcall.blogspot.com/2009/01/day-4-part-1.html>

I hate explaining a joke as much as anyone but it seems that it's gone over some heads.

<comment><USER7> Interestingly, almost everyone posting to the Reddit thread got that it was a joke ([http://www.reddit.com/r/programming/comments/81s36/i_hate_li...](http://www.reddit.com/r/programming/comments/81s36/i_hate_lisp/)) but most people posting to HN took it seriously.

<comment><USER8> Maybe for more people on HN, Lisp is part of their identity, so they get defensive.

<comment><USER9> I haven't noticed this. Most people here seem to be PHP "programmers", which I find hilarious. There is also a large Ruby contingent (whenever someone links their open source project, it's always Ruby.)

<comment><USER10> Why the quotes around "programmers"? I think Facebook is mostly PHP (or at least was initially?) and I am definitely not going to claim no one working at Facebook is a programmer.

I understand that PHP is an atrocious language (although I haven't tried it myself). But if someone uses it to create a product that people want and satisfies a need, more power to them, right?

<comment><USER9> I'm just saying that the demographic here is more people that think they can get rich off some PHP app than hard-core Lisp hackers. I am not saying that there are no PHP programmers, merely that the PHP-lovers here don't do much programming.

I am being unfair to PHP, though... Java sucks too.

</comment></comment></comment></comment></comment></comment><comment><USER11> _Why would someone lookup a value in a property list when you could write a simple routine in Macro-11 that would find the value in a table?_

Why indeed! I'm glad Lisp is finally dead so that we can all go back to writing assembler code optimised for the cycle allocations of a specific cpu. If only we could get back all the time wasted writing all that silly code with all those silly parentheses!

<comment><USER11> Note to people writing a lengthy, angry reply: this article, and this comment, are both satire.

Check the other posts on the blog. It's a lisp blog.

<comment><USER12> I thought 'funcall.blogspot.org' might have given it away... ;p

</comment></comment></comment><comment><USER13> I know it's a joke article, but I still find it pointless and without substance. What can anyone learn from it?

<comment><USER14> Must everything be a lesson?

<comment><USER15> Not necessarily, but favoring intellectually rewarding stuff is a good way to keep the front page from getting saturated with e.g. lolcats.

<comment><USER14> I think, as pointed out in another comment, that this post isn't just lolcat- esque--it does paint a picture of programming in the 1980s, something many of us haven't experienced.

<comment><USER15> I agree - I've heard of people considering Lisp (with its _garbage collection_ ) incredibly indulgent and inefficient decades ago, but that's sufficiently before my time that it was an interesting read.

I just think that, in general, "voted up because it's funny, even though it's also dumb" is a terrible precedent.

</comment></comment></comment></comment></comment><comment><USER16> The main point he seems to be making is that LISP is terribly inefficient from an early 80s point of view because there's an abstraction layer between LISP code and the CPU.

These days of course that's a moot point, as almost all day-to-day code is implemented in a language that has such a layer. Ruby has a VM with multiple implementations, Java has JVMs, C# has the Microsoft dotNet runtime and Mono, etc.

I can't really tell whether or not this post is supposed to be funny but I'm guessing that the only reason this made the front page is because of the polarizing title.

</comment><comment><USER17> I don't hate Lisp but I do agree that in those days limited stack depth was a problem. I don't know if this is an accurate assessment of Lisp but I think of pure Lisp as language where all of the data is stored entirely in the call stack. In other words it's just functions and arguments piled up in a stack. Is that right?

<comment><USER18> Actually, no.

For some reason many people have impression that lisp is "functional language" and so on, but that is not true, and certainly was not true for first practical implementations (practical = really running on some hardware).

One could discuss various approaches of implementing LISP, but in the end implementation either do not use stack at all (which is especially useful when you want Scheme-like semantics) or use stack in way that is not too different from C or assembly programs (and when it is different it in most cases means using less stack space).

Other thing is that particularly common implementation strategy (at least in various simple and educational implementations) of heap allocation and garbage collection was ignoring the problem and simple allocating heap structures by incrementing some pointer and never reclaiming used memory. Which in the end looks somehow like "using ridiculous amounts of stack space".

</comment></comment><comment><USER19> Sounds like a construction worker enrolling in an architecture class. It would be baffling. The author doesn't seem to acknowledge the value of processes abstracted from laying bricks. My guess is that he hasn't faced many ad-hoc buildings.

<comment><USER20> Sounds like a HN geek enrolling in an irony class. It would be baffling. Try reading the article slower :-)

<comment><USER19> Eh, it's a troll. I sensed sarcasm but honestly, it's rendered as a troll. The title itself is present tense. There is no hint other than extra-article content that the author means anything other than what he's saying.

Didn't expect to see this type of thing on HN.

</comment></comment></comment><comment><USER21> What, nobody wants to piss on PG's beloved language?

Well, I DO hate Lisp and I'll tell you why. Syntactically speaking is the ugliest of all. I don't deny its inner beauty but those parenthesis are a stopper for me.

Look, nowadays we have powerful IDEs that help programmers do their job. How about an editor that subtly hides the parenthesis so they are out of the way when you don't need them?

Maybe then I would consider it, meantime no, I don't want to be cool.

<comment><USER22> So things like paredit mode (<http://mumble.net/~campbell/emacs/paredit.el>) for Emacs don't count because... why exactly?

Honestly I find most people who "hate parenthesis" don't actually hate parenthesis. They hate the idea of having to delimit the _start_ of a statement as well as the _finish_. And unless your editor is helping out it can sometimes be a pain (let's admit it, it can be). But like every computer language, Lisp makes a tradeoff here and says that the features they can enable with such an incredibly regular syntax outweigh the pain of needing an editor mode.

<comment><USER21> Hey, I DO hate parenthesis as much as I hate brackets, angled, square and curlies. They are visual speedbumps, at least for me. Therefor I hate all C based and java languages, also html and xml. Again, visually speaking.

Good to know there are editors out there that deal with the issue, I didn't know they existed.

<comment><USER10> I think that leaves Haskell and Python?

The Python indentation thing was an inspired choice and usually works very well, but sometimes fails in a way that would be solved neatly if everything was delimited with parentheses. But it is a pragmatic compromise much in the spirit of the rest of Python (or "Pythonic" as they say). There is a lot of use of delimiters in data collection literals and list comprehensions, though, which are commonly used parts of the language.

Haskell, to me, demonstrates the problem of getting rid of almost all delimiters. I have a hard time scanning Haskell code and discerning the structure or figuring out what is being applied to what, etc.

I like Clojure's approach: mix up the delimiters to provide cues for mentally parsing the code at a glance. If you see [], it is usually a place where variables are defined and destructuring can happen. () is function or macro application or a special form. {} is mapped data. Along with consistent indentation, I find it quite readable.

I credit you, though, for declaring your hate of all delimiters equally :). I find the people who abhor parentheses while never noticing all the {};<> in their preferred language a bit maddening.

</comment></comment></comment></comment><comment><USER23> Never mind, I hate Haskell. And since I'm too lazy to learn it, I'll hate it maybe forever...

</comment><comment><USER24> die hard ASM fan hates higher level languages, news at 11.

is it me or is HN getting worse by the day?

<comment><USER11> It's you. This is satire.

<comment><USER24> I realize that now, heh. One of those mornings I guess.</comment></comment></comment>


Bayesian Adjustment Does Not Defeat Existential Risk Charity - <AUTHOR> http://lesswrong.com/lw/gzq/bayesian_adjustment_does_not_defeat_existential/

<comment><AUTHOR> I submit this not because I think HN _really_ cares all that much about existential risk charity, but because this illustrates an interesting way that statistical arguments can be flawed: we're generally fairly savvy about how p-values go wrong, the need for power, and so on, but it's much rarer to see someone object to the choice of _distribution_.

In this case, the choice of a normal distribution (or any thin-tailed distribution) almost entirely determines the result of the original argument, and inasmuch as there is no clear justification for why we would make the assumption that charity efforts follow a normal distribution, the original is just a very long exercise in begging the question.</comment>


Do you have a spaceship I could borrow? - <AUTHOR> http://messel.typepad.com/my_weblog/2009/05/do-you-have-a-spaceship-i-could-borrow.html

<comment><AUTHOR> A brief account of the 40 years of generous wisdom imparted by my best friend and brother Ron, as well as a competition of your imagination (see the bottom of the post)</comment>


Ask HN: Strategies for getting customer development/feedback on Freelance Tool - <AUTHOR>

I'm building http://signup.codefix.io but am struggling with getting feedback on if this actually solves a problem for freelancers and what problems I could solve for them. The idea came out of my own experiences doing one off fixes for people.
Anyone have suggestions on how to get feedback from freelance developers and people who would post projects on the site?
Thanks <comment><USER2> I've seen something similar several times. It is a good idea, but the marketing is extremely difficult.</comment>


YouTube Flags Notre-Dame Fire as 9/11 Conspiracy, Says System Made 'Wrong Call' - <AUTHOR> https://www.bloomberg.com/news/articles/2019-04-15/youtube-flags-notre-dame-fire-as-9-11-conspiracy-in-wrong-call <comment><USER2> I think the AI drew a connection based on the burning and the tower [spire] falling, at least thats how my mind associates the two events, the towers and the cathedral with each other.</comment>