Why Arrington blogs about porn - <AUTHOR> http://www.seomoz.org/blog/techcrunch-upskirt-arrington-blogs-about-porn

<comment><USER2> I'm not disputing his advice which will probably work but I have to say SEO people seem shadier and shadier to me. SEO started out as a way to make your existing content turn up for people who were searching for it but now it's turned into "blog about this because people search a lot for it" and that seems wrong to me.

I guess it's the same instinct that's eaten every other industry (see TV and marketing execs) it's just sad to see the web going down that road.

<comment><USER3> _that seems wrong to me_

Wait, what?

I spend significant effort and money on content creation. Decisions as to what content to produce next are often driven by user suggestions or analytics data -- i.e. "Oh, it looks like a lot of people are searching for baby shower bingo cards, I guess I should write some baby shower bingo cards, because then more people will find my site and this will make me money."

So people get the content they want and I get money... tell me where we're going wrong here, again? Would it be somehow cleaner if, rather than using evidence as to what my customers enjoy, I just put my finger to the wind and guessed? I did that for a while -- I'm not a terrible guesser but why should I watch 80% of my content budget produce pages that are grossly less effective than my average?

<comment><USER4> I don't mind what you do - nor do I think the parent does - but techchrunch is not a porn site, and it is not a blog about porn, when they write about porn it annoys those who come there to read tech news.

<comment><USER5> The porn industry has a lot of early adopters. How they're using a technology is a good leading indicator of how everyone else is going to use it.

</comment></comment></comment></comment><comment><USER6> I have the same situation on my blog. I get consistent hits from people looking for porn because I've mentioned porn a couple of times. I've been sorely tempted to serve special ads just for them...

<comment><USER7> Likewise, although in my case it's often unintentional!

I wrote a satirical post on the elderly called "Old People Suck" and spent 3 years trying to get rid of regular searchers looking for porn containing, well... use your imagination.

</comment></comment><comment><USER8> Why we worry about Arrington?

<comment><USER9> Predictable, content-insensitive comment. Plenty of people have a problem with Zed Shaw, or Joel Spolsky, or Jeff Atwood, or Michael Arrington, or ___________, but it's really tedious to hear the same whining with every story that comes across this site.

<comment><USER10> i actually plan on writing my own SO clone this weekend with my own compiler that i plan on releasing under the GPL so its funny you mention that</comment></comment></comment>


The making of Exchange, a new typeface - <AUTHOR> https://frerejones.com/blog/decompiled-and-remixed-history-the-making-of-exchange <comment><USER2> A very interesting article! For those that aren't type geeks, Tobias Frere Jones and Jonathan Hoelfer used to be partners in www.typography.com, and designed a bunch of well know fonts such as Gotham (the Obama campaign font). They had a verbal agreement to be 50-50 partners, but it was never put in writing. It ended in a very messy divorce.

[http://nymag.com/news/features/jonathan-hoefler-tobias- frere...](http://nymag.com/news/features/jonathan-hoefler-tobias-frere- jones-2014-6/)

Something good for other co-founders to keep in mind.

<comment><USER3> As someone who really followed them closely (archer was HUGELY impactful ~10 years ago, and gotham set a bar in politics that has yet to be surpassed), this breakup really left a bad taste in my mouth that's prevented me from ever doing anything with Hoefler again.

So what it wasn't in writing. Hoefler led Frere on for decades, as he did his lifes work, and then dug a dagger into his back.

Glad to see Frere has been able to move on and remain productive after such a setback. Though I'd really like this to have a weight one thinner and one blacker, for that super intense contrast. That optionality is one of the things I really love about Gotham and Proxima Nova

<comment><USER4> I don't understand how the design community continues to support Hoefler. Without a clear explanation that his actions weren't simple, bald dishonesty and greed.

<comment><USER3> Well sure. The design community also continues to fawn over a cell phone assembled in factories where they have nets to keep the workers from killing themselves.

The design community likes to pretend they're all TED talks and social good, but mostly it's crabs in a bucket, trying to out-shiny each other, realities be damned.

(I say this as a designer)

<comment><USER5> Crab buckets? Terry Pratchett fan by any chance?</comment></comment></comment></comment></comment>


The Pros and Cons of Working for Yourself - <AUTHOR> http://blog.earbits.com/online_radio/the-pros-and-cons-of-working-for-yourself/

<comment><USER2> There are lots of different forms of Working for Yourself. This is evidenced in the author's last few points, where he seems to equate Working for Yourself with Consulting, or, rather, Working for Somebody Else.

My favored form of Working for Myself involves building self-sustaining products that bring in the maximum revenue with the minimum commitment on my part. That means, for example, a product that sells itself without my involvement, is straightforward enough that it doesn't generate many support requests, and stays finished once it's launched.

With that sort of business, the author's worry about income stopping when you stop working goes away completely. The whole point is to stop working. State that as the goal from the outset, and you'll be good to go. Quite literally.

</comment><comment><USER3> 'With a "regular" job it is normally easier at the end of the day to completely plug out and enjoy the rest of the evening.'

Definitely have noticed this myself: it's easy to slip into a kind of mindset where, no matter how much you work, you worry about not doing enough, which makes your free time less enjoyable because not worry-free, which in the long run makes you less productive.

That, and the fact that it's always just you and yourself, and you never get to enjoy the dynamics of a good team.

Obviously a lot of people manage to make it work for them, but I did it for a couple of years and it's been enough for me.

</comment><comment><USER4> _My friends often make fun of how rigid I am about [working]. I think they often overlook the fact that although I don't have to report to a boss, and nobody would fire me, I still need to report to myself, and if I don't get my work done it's bad news._

I never thought about it like that. This is exactly the response I get from people who don't understand that working for yourself doesn't mean _not_ working.

</comment><comment><USER5> >Just like you'd own the success, you'd also own the failure, and you will have to take full responsibility for it. Unlike working for an employer, when you run your own business you can't just give a 2 week notice, quit and get another job. You'd have to work through the tough times.

I completely disagree about this. You will take a personal reputation hit, but you most certainly can _stop working for yourself and take a new job_.

</comment><comment><USER6> I 've been doing it for 3 years and i don't see these "cons". I presume people who choose to work on their own are usually self-motivated enough so as not to mind taking the blame, fixing their time schedule, and dispensing with everyone else's opinion (maybe it's just me though).

<comment><USER7> YES. I don't mind "taking the blame".

I much prefer taking the blame, recognize what I did wrong, and be able to do something about it (even if it's hard, or even if I sometimes make the same mistake more than once) than throwing my arms up in the air thinking it's someone else's fault and out of my control.

Control is good. Control makes you happy.

</comment></comment><comment><USER8> pros: time freedom

cons: no one to discuss, share ideas or set up a strict deadline

I can finish my app bookspp.com in less than 10 days, but it took me more than 2 weeks...

<comment><USER9> There are more classy and contributive ways of advertising your app.</comment></comment>


An outlining app similar to Workflowy - <AUTHOR> https://dynalist.io/ <comment><USER2> Some of the UX isn't quite as smooth as Workflowy... but it does have some features workflowy is missing like images/attachments etc. It's definitely very pretty. I find the loading of some nodes to be unbearably slow though. The cross-linking is a great feature, though again the markdown processing takes a while to happen so the UX feels choppy and lets it down slightly.

I don't really get the need for the files panel on the left hand side. In theory the first page just acts as an ad-hoc version of that. Seems unnecessary to me. I could look past that though as if you just hide it and pretend it's not there then it doesn't really matter.

Also... no mobile app :/

I use workflowy every day and there are definitely areas for it to improve on that I feel like dynalist is trying to address. Will keep an eye on this one. Not ready to switch at this time but hopeful for the future.

<comment><AUTHOR> > _Also... no mobile app : /_

They have mobile apps for iOS and Android [https://dynalist.io/download](https://dynalist.io/download)

</comment></comment><comment><USER3> I use this now, having switched from Workflowy. It's great — I'm a huge fan.

</comment><comment><USER4> Interesting. This a bit like org-mode but less powerful and more user friendly.</comment>


Mozilla VPN - <AUTHOR> https://vpn.mozilla.org/ <comment><USER2> The big thread was [https://news.ycombinator.com/item?id=23565192](https://news.ycombinator.com/item?id=23565192)

also [https://news.ycombinator.com/item?id=23859489](https://news.ycombinator.com/item?id=23859489)

and [https://news.ycombinator.com/item?id=20927832](https://news.ycombinator.com/item?id=20927832) from last year

</comment><comment><USER3> If you support a free, open, and standards-based web and Internet AND you need a VPN, you should subscribe to this.

Read the 10 principles of the Mozilla Foundation here: [https://www.mozilla.org/en-US/about/manifesto/](https://www.mozilla.org/en- US/about/manifesto/)

This product is an essential step in Mozilla diversifying and increasing their revenue so that they can keep working without being dependent on search revenue from hostile/neutral-at-best companies, like Google.

I have nothing to do with Mozilla personally or professionally, I just think they should exist and are a net force for good on the Internet.

<comment><USER4> Agree, but aren't they a five eyes company?

<comment><USER5> Nope.

</comment></comment></comment><comment><USER6> ArsTechnica recently did a review of it:

[https://arstechnica.com/gadgets/2020/07/we-test-mozillas- new...](https://arstechnica.com/gadgets/2020/07/we-test-mozillas-new- wireguard-based-5-mo-vpn-service/)

</comment><comment><USER7> Recently, some VPN providers that advertised themselves as log-free turned out to by lying about that. Source: [https://www.theregister.com/2020/07/17/ufo_vpn_database/](https://www.theregister.com/2020/07/17/ufo_vpn_database/)

Aside from "we trust Mozilla", what independent verification assures us that Mozilla is not, in fact, logging their VPN traffic?

<comment><USER8> This service is Mullvad rebranded, with restrictions. (Their custom app only.)

Mullvad is a very widely trusted and respected service.

<comment><USER9> In addition to that, mullvad allows you (and encourages you) to pay them without them knowing anything but your account id. And your account ID is also the only thing there is to your account. No E-Mail, no password.

<comment><USER10> How does that work? Wouldn't they still know about my credit card details and my Credit Card name?

I have also never heard of Mullvad at all?

<comment><USER5> You can pay in cash.

</comment></comment></comment></comment></comment><comment><USER11> I'm sad that spamming users via Firefox account email is now becoming a regular practice for Mozilla. Last time it was for the picture-in-picture feature. Now they're advertising their VPN.

I'm pretty sure I again unchecked all the boxes referring to unsolicited mail in the account preferences when the picture-in-picture mail landed [1]. Yet "Firefox account tips" was now back on for me again.

[1] [https://news.ycombinator.com/item?id=23772909](https://news.ycombinator.com/item?id=23772909)

</comment><comment><USER12> Perhaps I'm being naive but $5USD ($7.50CDN after exchg and credit card padding) per month seems too much for the average Joe. I.e. compared to its competitors - esp. well known competitors like PIA and the free offering from Opera.

<comment><USER13> If a product is free, you (or your data s) are the price.

BTW personally i would not recommend PIA anymore.

<comment><USER14> Can you explain your reservations about PIA?

<comment><USER13> [https://www.techradar.com/news/cyberghost-owner-buys-pia- for...](https://www.techradar.com/news/cyberghost-owner-buys-pia-for- dollar955m-to-create-vpn-giant)

</comment></comment></comment></comment><comment><USER15> Is there an easy way to make this work with NextDNS.io? I don't want to lose the filtering/analytics on my devices, but would also like to have access to a VPN...

</comment><comment><USER16> "Linux coming soon". Will buy when it's here. :)</comment>


Rooby: a Ruby-like object oriented language written in Go - <AUTHOR> https://github.com/rooby-lang/rooby <comment><USER2> > Rooby is a Ruby-like object oriented language written in Go. You can think > it as a simplified, compilable Ruby for now.

I have to ask, if your goal is "compilable Ruby", then...why not Crystal? ([https://crystal-lang.org/](https://crystal-lang.org/) ) Seems like it accomplishes your goals, already exists, and is (as far as I know) stable and well regarded.

Nothing wrong with reinventing the wheel, and you may have very compelling reasons to write your own project. But it looks weird when there's already a well-known project in this space and you don't compare yourself to it. How are you better?

<comment><USER3> I'd argue there's a lot wrong with reinventing the wheel. People don't seem to care about the inevitable waste of programmer time and effort that comes with introducing a new programming language or library, assuming it gains any traction.

<comment><USER2> > assuming it gains any traction.

There's little risk of that I think; even very strong and innovative languages struggle to gain traction. It doesn't tend to happen by accident.

And let's not forget that writing your own ORM, compiler, programming language, hardware driver, etc., (even blog engine!) is an _amazing_ way to learn. But it is good to know whether a project is a hobby project to help learn, or a serious project aimed at getting traction, or what.

<comment><USER4> >> But it is good to know whether a project is a hobby project to help learn, or a serious project aimed at getting traction, or what.

Most programming projects start with the intention of the latter but usually end up becoming the former.

<comment><USER5> I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu)

Linus Torvalds 1991

<comment><USER4> Minecraft is another good example.

</comment></comment></comment></comment></comment></comment><comment><USER6> Hello, I'm the author of this project. Let me explain a few things:

1\. The goal of this project is to let people "Use Ruby-like syntax build Go- like performant api servers".

2\. The "Ruby-like" means Ruby-like syntax because I am a Rubyist and I think using Ruby to develop project is fast.

3\. Using golang is because I want to build a http server library upon go's http package, which I think is a very good choice for writing api servers. And of course I might use goroutine directly in the future.

4\. Making rooby compilable is just a feature I personally like.

5\. You can see this project as a experimental language for a relatively small goal (see the first point above) + I like writing Go, then you won't be so surprise why I created it and not using crystal instead.

6\. I really didn't expect rooby would gain so many traction, thanks for all your opinions :)

<comment><USER7> I think you shoulda named it "Goby" \-- which is a real word for a cute l'il fish.

[https://en.wikipedia.org/wiki/Goby](https://en.wikipedia.org/wiki/Goby)

</comment></comment><comment><USER8> Nice... reminds me of Mirah (formerly known as Duby). It's basically a compiled Ruby, but abandoned since some time. 5 years ago it used to be the fast alternative to JRuby on Google's App Engine. Together with the web framework Dubious :D

</comment><comment><USER9> I like the name and I hope the obligatory web framework will be called "Rales".

<comment><USER10> Name is terrible, you can't tell your friend "I've started using Rooby", response would be "good for you".

I suggest renaming before too late.

<comment><USER11> Should rename to Rubby.

<comment><USER12> When I get bored I'll give into recruiter spam sometimes and take them up on a phone call. I'd purposely pronounce Ruby as Rubby, and similar words. My favorite was Mysqueel.

<comment><USER13> Sounds like you may enjoy My Rails Blob: [http://railsblob.blogspot.ca/2006/08/my-new- blob.html](http://railsblob.blogspot.ca/2006/08/my-new-blob.html)

</comment></comment></comment></comment></comment><comment><USER14> I see a lot of references to Crystal here and I would agree it is more mature but has different goals to be sure. If you want a rubyish DSL for microservices which can expose golang features and libraries then Crystal isn't a suitable match. We have to assume the later is important.

It's like saying JRuby is a suitable replacement because it's fast and has microservice libraries - it's not exactly what you want.

If the author is not planning to support rubyspec, monkey patching, runtime magic, etc. then it looks like they are closer to delivering on their objective.

<comment><USER6> Hello, I am the author of this project and I think you said what I think. I won't support most of ruby's meta-programming magic for keeping rooby as simple and performant as possible. Thanks for your explanation

<comment><USER14> Awesome, it looks really interesting.

</comment></comment></comment><comment><USER15> For all the people asking "Why not Crystal?". It seems to me like the creator obtained a copy of the Go Interpreter book([https://interpreterbook.com/](https://interpreterbook.com/)). Seems like a fair bit of the code is reused here. Nothing wrong with that at all (if true). After all its all under MIT License. Seems like a pet project more than something the author expected to gain any attention (kind of like Linux started out). Seems to me more like a ruby-like-coffeescript equivalent for Go.

<comment><USER6> Haha, I did read that book before start this project, it's a very useful material. But for now the project are far more complicated than the sample project in that book, only lexer and parser remain similar.

BTW I also took "nand2tetris II" on coursera and read "Ruby under a microscope" for this project.

<comment><USER16> I think that you should be a bit more transparent about how much of Thorston's ideas and code you are using in this project. You should probably give him some attribution.

I also read that book, and have a toy language I've been building, basically extending his ideas. I've looked through your code and much of is it nearly verbatim from the book (including code in your 'vm', or the monkey 'eval' package - it's not just the lexer/parser), though you (as I have), chose different names, or organized things differently, and added new features.

Yes, you've extended his ideas much farther, but the core of 'rooby' is pretty much the same as Thorston's language, 'monkey'.

Monkey is available with the MIT license, so it's fine what you've done. But, having been through the book and pretty familiar with the Monkey code (available for download here: [https://interpreterbook.com/waiig_code_1.3.zip](https://interpreterbook.com/waiig_code_1.3.zip)), I think it's disingenuous to say 'I read that book before this project..', which seems to imply that it was inspiration, rather than original source material.

On a positive note, it's a pretty cool version of Monkey.

<comment><USER6> The 'code' you read is similar, but the way they work are totally different.

Monkey is fundamentally a functional language, but rooby is totally an object oriented language. And the compiler, vm's internal implementation and bytecode spec, which are the 'core' of rooby, is not like monkey at all.

I would say I extended monkey's lexer and parser as rooby's. I feel sorry if I didn't give enough credit to Thorston, I would add reference to his book in readme. But the core is more a Ruby than monkey, so I don't think it's just an "extension" of monkey.

Please read the commits and you'll know how much work I did to make rooby, it's far more complicated than just "extend" monkey.

</comment></comment></comment></comment><comment><USER17> It would be interesting if it would include native Go features such goroutines and channels

<comment><USER18> +++++ yes it would

</comment></comment><comment><USER19> It might not matter much to the Ruby folks if it remains a hobby project, but this probably violates the "Ruby" trademark.

<comment><USER20> How about changing the name to Gooby?

<comment><AUTHOR> How about changing the name to Roobish?

<comment><USER21> Rubish?

</comment></comment></comment></comment><comment><USER22> Why not Guby or Gooby?

</comment><comment><USER23> Seems like interop with Go could be its selling point. I wouldn't call it gruby though, since it isn't Ruby-on-Go.

</comment><comment><USER24> Crystal is years ahead and way better with an active community. What purpose does Rooby serve?

<comment><USER25> > What purpose does Rooby serve?

I don't know. I do know that many of these language projects are people's hobby projects. They like to pick a language they either know'n'love or want to get more proficient in.

</comment></comment><comment><USER26> This would be huge if it passed at least some portion of the RubySpec

</comment><comment><USER27> So basically another elixir? I'm curious why Ruby? and why with Go?

<comment><USER9> I'm baffled as to why people keep insisting Elixir is "Ruby-like".

Is it just because they both have "def" and "puts"? Cause that's just about where the similarities end :-)

<comment><USER28> Agree. The language is different. The standard library is different. The runtime is different. The last two quite substantially at that. JavaScript is more like Ruby than Elixir is. I'm tempted to say Go and Jave are more Ruby than Elixir is.

FWIW, I've been using elixir for about a year now, and I think it's fantastic. I still use node & ruby for scripts (which can get complicated, but almost always for one-offs and asynchronous processing), Go for anything I actively want to share memory (though, started using Crystal, can't wait for threads), and OpenResty for any web proxy/middleware stuff. But Elixir is now the lions share for me and I find it fun and productive.</comment></comment></comment>


Coco: Framework for enterprise blockchain networks - <AUTHOR> https://azure.microsoft.com/en-us/blog/announcing-microsoft-s-coco-framework-for-enterprise-blockchain-networks/ <comment><USER2> Watching the demo video [1] has me a little confused.

He makes it sound like all your interaction with Ethereum goes through the Coco framework (so permissions are implemented by Coco deciding which contracts you're allowed to see). Is that right?

If so what's the point of using Ethereum at all?

\- Who is doing the computation for a smart contract if it's private and only you can see it?

\- Is the permissioning managed by a trusted Coco server somewhere? If so, why not also trust that server with storing the information about your supply chain?

[1] [http://aka.ms/cocodemo](http://aka.ms/cocodemo)

<comment><USER3> I think the idea is that, since the blockchain nodes are running in a TEE, that any participant in the network can get an attestation to be sure that no one has tampered with the rules of the network. You don't need to personally validate each transaction as long as you are sure that the network is running the correct code.

It seems that permissions are set in each contract with identities tied to Azure AD members. I might be wrong about that. The white paper is pretty long and I only had time to skim it.

<comment><USER4> You captured the basic idea of the TEEs well. One way of thinking about this is that proof of work and proof of stake consensus protocols establish trust on a per-block basis. By leveraging TEEs, we have hoisted that trust establishment out of the per-block workflow and instead have the option to pay the cost once, at the time the network is established. One tradeoff of this design is that a TEE compromise would have major impact on the ledger. The whitepaper ([https://aka.ms/cocopaper](https://aka.ms/cocopaper)) contains a section on mitigating TEE compromise. Additionally, our intent is to support multiple consensus models, including models that require per-block trust validation. Ledgers and consortiums are free to make choices about what they want to support depending on their threat model and the assets being protected - with the ability to trade off scalability and latency against security as they see fit. What we demo'ed is one design that we think is interesting for many use cases we've heard about from customers.

Permissions are not tied to AAD members per se - we rely on a set of X.509 certs that correspond to the identities of the actors on the network for network-level authentication. These certs are referenced in the network constitution.

Ledger- and app-level authentication can be done however developers would like to do it. It can be, but need not be, AAD. See my comment above or the whitepaper for more details on the confidentiality design.

<comment><USER5> This is nothing that cannot be achieved by a write locked DB, with verification via inputs from smart contracts. You are basically using the security of these massive P2P networks to shore up a consultancy model.

<comment><USER6> Yeah, exactly. These permissioned blockchain implementations rely upon some centralised source of trust (eg the government, network permissions, etc.) and I don't see exactly what distinguishes them from a distributed ledger. The core innovation and the whole point of blockchains is that they are permissionless and trustless. Or am I missing something here?

<comment><USER7> Yes, the core innovation in public blockchains, the double spend problem in trusless networks, is not present in private blockchains and private blockchains can he simplified with basic block that have existed for decades.

The biggest and critical issue with private blockchains is at the political level: how to make a lot of parties (e.g. bank) agree in a protocol involving critical things (e.g. money).

</comment></comment></comment></comment></comment></comment><comment><USER8> I wonder what are the best use cases for an enterprise blockchain? EDIT: Great suggestions. How about some non-banking applications?

<comment><USER9> I know I already replied but I forgot to mention another great usage of a blockchain: Logging. Not general-purpose logging, no. I'm talking about SOX- like "must be tamper-proof" transaction logging.

So say you've got central logging setup at your organization. You're smart and are using rsyslog with SSL/TLS and your own CA. For the most part you can reasonably claim that your log messages are secure from the server that emitted them to the destination in your central logging system but _can you guarantee they 're not modified after that_? No. You can't.

From this perspective using a blockchain for logging security-critical events would be extremely useful. It would be impossible for an attacker to modify the logs after-the-fact so that you could no longer determine which account they used to login.

You wouldn't want to use it for _general_ logging because of the overhead but for things like login events, reboots, etc it would be fantastic.

<comment><USER10> I'm curious, has this ever been a problem in real life?

<comment><USER11> Googling for enterprise blockchain scenarios, I find [https://www.hyperledger.org/projects/sawtooth/seafood- case-s...](https://www.hyperledger.org/projects/sawtooth/seafood-case-study) I guess in this case the goal is to ensure customers trust in the enterprise beyond just reputation. These records are currently being stored in traditional databases and the customers trust that the records aren't being tampered with out of the expectation of consequences if the enterprise was caught cheating. But, with a blockchain record, cheating becomes extraordinarily harder. The customers do not need to trust. They can verify.

<comment><USER12> Do the customers have to run their own mining network to ensure the producer can't pull a 51% attack?

<comment><USER13> While a 51% attack is a real concern, an even more likely scenario is the network going down. During a network split the local node(s) will happily continue to ingest logs which once the network is healed will all be rejected.

</comment></comment></comment></comment></comment></comment><comment><USER14> I don't understand 'enterprise blockchain'. Doesn't a blockchain depend on thousands of computers, each independently verifying the data? How does this hold if the blockchain is just running on 1 server (or a few, but that's not the point)? Then it's just a server, not a block chain...

<comment><USER9> You're right: It's not practical to run a blockchain on a single server or even just a collection of servers. For it to work properly it needs to be constructed as a P2P system. So each system that wants to use the blockchain has to participate in its construction.

What this framework _appears_ to do is enable your endpoints to participate in a one-way fashion. So they will get just enough information to facilitate a transaction but nothing beyond that.

It _seems_ like a bit of cloak & dagger tomfoolery where the blockchain is just being implemented behind-the-scenes on a specified collection of servers but I haven't looked very deep yet. I can see the benefit _to Microsoft_ from having a setup like that--they can allow customers to participate in a blockchain-utilizing system _without giving them full access to the blockchain_ but to me that seems like defeating the purpose and unnecessarily trusting a 3rd party to handle _all_ your transactions with no independent way of verifying said transactions.

In other words, it's no different than just standard server-client architecture except instead of handling transactions through a database (the traditional way) they utilize a blockchain in the background. When you want to verify a transaction you're really just making a request to their central server and asking it to do the job for you--and trusting whatever it tells you.

Not exactly a proper blockchain if you ask me.

<comment><USER15> > It seems like a bit of cloak & dagger tomfoolery where the blockchain is > just being implemented behind-the-scenes on a specified collection of > servers

The key is who is running that "specified collection of servers". If they're all yours, then yeah, there's no advantage to just running your own sql-ish cluster.

However, what if now your p2p miner pool includes a few machines run by your regulator? Yes, your business logic endpoint nodes are participating in a one- way fashion, but their transactions are now being automatically logged by the regulator (regulator doesn't need to know what the underlying business logic is, just that the reportable transaction results are being logged in the blockchain they're part of). Something like a third of financial firms' business is around reporting requirements.

Or consider a large supply chain... again the miners aren't just one company, it's everyone in the supply web or the consortium. Allows for coordination without necessarily being open to the public.

<comment><USER16> I can imagine something like carbon credits working well with this. What else?

</comment></comment></comment></comment><comment><USER17> "My framework runs on anything and works with anything..." should translate to, "it's very fragile and only works with what we tested it with."

</comment><comment><USER18> I was hoping it would be a new Tandy Color Computer. I guess the news on the new Amiga clone got my hopes up.

</comment><comment><USER19> Wheres the ICO!

<comment><USER4> We were talking about this yesterday. We should call them Cokens :)

</comment></comment><comment><USER20> Really? Couldn't come up with a name that wasn't effectively already in use?

<comment><USER21> It's Microsoft, their names are supposed to be confusing.

<comment><USER22> Their parallelized data warehousing solution: Azure Data Warehouse.

Their document store database: Azure DocumentDB.

Their large scale structured+unstructured data storage and analysis (frequently referred to as a data lake): Azure Data Lake Storage... AND Azure Data Lake Analytics. Let's talk about the precise differences and co- dependencies between these two.

Their offering to expose functions as an API: Azure Functions.

Their RDBMS, a product that runs as a server and is queried with the language, SQL (what might, in another world, be called a SQL server): SQL Server.

Their cloud version of the same: Azure SQL DB.

Their only well named product, you ask? Their cloud platform named Azure, which is the color of a blue sky. Well played, Microsoft.

tl;dr I agree with you.

<comment><USER23> All those names are actually pretty clear and not confusing at all.

Boring and uninspired - yes - but certainly not confusing.

No different from MapKit and WebKit and ARKit and HomeKit and HealthKit

<comment><USER22> ADLS and ADLA do definitely inspire confusion, but your point is well-taken.

</comment></comment></comment></comment></comment><comment><USER24> Are we running out of words, or combinations of letters that are pronounceable? I swear to god this is like the third time I've seen someone release a new framework that had the same name as a different, already popular framework.

Sure, Apple's API is called Cocoa, but verbally is there really any difference?

</comment><comment><USER25> MSFT needs a name doctor

</comment><comment><USER26> Because removing an A makes it a completely different framework from Cocoa Framework...

<comment><USER27> I was just going to say, verbally Coco = Cocoa. Not that it matters all too much since they're in different spaces, but they could have come up with a different name, especially when you don't even have to use a real word.

</comment></comment><comment><USER28> Because removing an A makes it a completely different framework from Cocoa Framework...

<comment><USER29> It's not a clon.

<comment><USER30> Nice. They could have named it "Chanel" and by the fifth version it would smell great.

</comment></comment></comment><comment><USER31> Is this Microsoft's subtle way of saying they do not ackknowledge iOS's Cocoa and Cocos2d frameworks? Or were they hoping dropping the 'a' wouldn't cause for confusion/overlap.

<comment><USER32> Was Apple naming their mobile OS iOS a diss towards Cisco?

<comment><USER33> They got a license from Cisco: [https://blogs.cisco.com/news/cisco_and_apple_agreement_on_io...](https://blogs.cisco.com/news/cisco_and_apple_agreement_on_ios_trademark)

</comment></comment></comment><comment><USER34> Coco? Jamboo! [https://www.youtube.com/watch?v=m_- Qtz70_z4](https://www.youtube.com/watch?v=m_-Qtz70_z4)</comment>


Programmers: Before you turn 40, get a plan B - <AUTHOR> http://improvingsoftware.com/2009/05/19/programmers-before-you-turn-40-get-a-plan-b/ <comment><USER3> Disclaimer: I didn't read the full article. I can't stomach these types of "career strategy" articles anymore. This approach to life in general is very misguided (maybe less so if you just want a career to fulfill other goals), but for those who want to pursue a more idealistic life, just pursue your passions. Plan B is being an improv comedian. Plan B is writing the great American novel. Plan B is traveling the world as a war correspondent.

I left corporate world precisely because I felt "planning my career", as I was encouraged to do, was an absolute false way to live (for me). I couldn't reconcile the absurdity of it with the severity of the consequences if I didn't do it. But the consequences are all socially constructed, and they go away as soon as you change your mentality.

When I think of my heroes, I don't think of people who've hedged their bets here or there - they just did what they felt they had to.

<comment><USER4> Thank you! I've felt exactly this way. It's rare that someone expresses it so well.

</comment></comment><comment><USER5> This reasoning doesn't take into account the fact that a lot of people are very bad at programming and get tired of doing something they're very bad at. We have a fair number of bad programmers in their twenties, few in their thirties, and probably none over 35. It isn't because they get better. The only middle-aged programmers we have are absolutely solid.

<comment><USER6> "The only middle-aged programmers we have are absolutely solid"

As a several year veteran in the government contractor space and from personal experience as a configuration manager, I strongly disagree this this. I've seen poor and mediocre programmers survive as programmers well toward retirement age. Part of the reason is that programming isn't the only skill that they provide. They provide domain knowledge on the systems which the gov (mil and civilian) rely. Then us poor sods have to clean up after them and clean up after them, and hold their hands on radical new ideas like object oriented programming. I could really rant on this topic if I wanted to.

Another perspective: I mean, how many coders do you know that make it through a few years working who have _NOT_ developed some significant domain knowledge?

<comment><USER7> That's in government though where the contractor is in many cases above all trying to fill seats to make sure they can bill the maximum amount of hours. They just call it "domain knowledge" to justify to anyone that might question why they are keeping someone who is bad at the job around.

When you talk about government and government contracting you are discussing an entirely different world devoid from reality.

<comment><USER8> While I cannot fully disagree, I would like to point out that a great many government contractors take their jobs very seriously and do very good work.

Of course, I may be biased since I work as a contractor.

<comment><USER7> Sure at the individual level there are plenty of people who do good work but I'm referring to the companies themselves. A government contract company's only real goal is to get more contracts in terms of numbers and dollar amount and run them in a way that maximizes profit. A contract companies success in the government realm has little to do with actual performance and a lot to do with salesmanship.

I'm not suggesting contractors beat their children. I am saying that if one wants to move up within a government contracting company they will reach a point when they will have to push a course of action that is _not_ in the best interest of the government at which point the individuals and company are indistinguishable.

<comment><USER8> You have a certain logic, but all I can say is that I have not witnessed it myself after working now for 2 different contractors. Of course, in both of those cases everyone in my immediate management chain was, like me, a former military officer.

</comment></comment></comment></comment></comment></comment><comment><USER9> If the geezer with 10 years of C++ experience showed a capacity to rapidly learn a new language / framework, I'd hire him every time. Those 10 years of C++ experience taught a lot in terms of general understanding of programming, best practices, how to "think" like a programmer, etc. (or at least one would hope; it varies, of course). That is far more important than a few years using an extremely high-level language.

I think about it this way: I am supremely confident that I could know all I need to know about Ruby/Rails to do just about anything within a few months of working on an honest-to-god project. I'm equally confident I wouldn't know a fraction of C++ in that time. As our tools continue to become higher-level and more acutely focused, they become easier and easier to grok. The learning curve of a language with C++'s history vs. a new-shit-on-the-block web framework? Forget about it. You can write a blog in 10 minutes, remember? ;)

<comment><USER10> I'm that "geezer". Coded in C and C++ for over a decade, and now I'm working in the magical world of Rails, where I get to watch 20-somethings rediscover the value of old ideas the hard way. (Given the average comment thread on Hacker News, and you'd be excused for wondering why _anyone_ ever used compiled languages or static typing. Silly dinosaurs!)

That said, while I appreciate your sentiment, I know in my heart that the author is right. All of my friends from college have moved out of programming. Many have left the industry completely -- and we're not even that old! The bottom line is that there's little or no cost advantage to hiring an older coder, when I have t-shirts that are older than the most popular development environments.

Every once in a while, some young geek chimes into these conversations with the observation that one needs only _"keep up with technology"_ to stay relevant in the industry. But even ignoring the fact that "keeping up" is usually easier said than done, the economics just don't work out. My friends who went to medical school are finishing their residencies and starting in private practice; my friends who went to law school are making partner. In most industries, you're just _beginning_ your career when you're in your early 30s. In software, you're already old enough to be a conversation topic.

<comment><USER11> _That said, while I appreciate your sentiment, I know in my heart that the author is right._

Even the "keep up with technology" people know in their hearts that these articles are correct. Everyone knows programmers have a half-life, they just are in disagreement about when it kicks in. Nearly everyone would be surprised to discover a 60 year old programmer who was still gainfully employed. 50 is really pushing it, 40 is pushing it, and 35 is starting to push it. In contrast, nobody would think it was weird to see a 40, 50 or even 60 year old doctor or lawyer.

<comment><USER12> It's a bit early for these comments. There aren't that many programmers in their 50s because there wasn't as much need for programmers in their twenties, 30 years ago. Demand for doctors has been more steady.

That's half the story, but it's a big part of it.

The other half is that it's an area with gradual drift out & little drift in.

That half needs some explaining but it seems like more of a young man's game then it is. It's easy to get behind. If you're out for 2 years, it's daunting to get back in. The opposite is true for some domain (like medicine). You get very little drift in to the field (more programmers become HR people or sales people then the other way around). It's a first career, not a second.

<comment><USER13> It depends. You could be out of Unix or C or Oracle for 2 years and come back. It's only "front-end" technologies like Flash, Rails, PHP, AJAX that suffer from the rapid churn and the latest thing when you come back didn't even exist when you left.

<comment><USER12> I wouldn't really know personally, but my reasoning was that not only technology moves, you forget or lose the feel.

</comment></comment></comment></comment></comment></comment><comment><USER14> OP glosses over one critical truth: programming is not just about delivering code, it is about delivering _value_.

In spite of what many of us technologists may think, customers and employers do not purchase "software", they purchase the benefits that software delivers. These benefits come in many forms, and it's just as likely that they come from solving general problems as well as solving technical ones.

If someone at any age complains about their difficulties securing work, it's not necessarily because of their technical skill set, it's because they're not delivering the value their customer covets. They need to find out what their customer needs and deliver it, whether that means brushing up on their skill set or not.

When the posers and BS'ers meet their makers, it's not necessarily a bad thing; I prefer to call it "industry Darwinism".

<comment><USER15> For the sake of imagining someone working at an employer where they have no real control over the direction of the product, what value do they bring other than their technical skill set and analytical ability? Presumably the value most developers out there deliver is producing a coded up version of someone else's specification. Outside of having enough business acumen to know when to shut up before the management threatens your employment (if remaining employed is important enough to you), what else is there?

<comment><USER14> "...they have no real control over the direction of the product..."

Not my experience. I (and almost every other programmer I have ever met) have had _some_ control over everything I've ever worked on. Perhaps this is a self fulfilling prophecy: if you don't think you have any control, then you don't.

"Presumably the value most developers out there deliver is producing a coded up version of someone else's specification."

Not my experience either. At least on this planet.

If anyone else ever produced a specification rigorous enough for me to code from, I could die happy.

<comment><USER15> "if you don't think you have any control, then you don't."

Or you've tried to get some control, and have had your hand slapped away. And then realize the part that you don't have control over is the crux of the product's value proposition, and that it is a bad value proposition. Having control of the how isn't going to make it valuable enough, because it doesn't solve the right root problem. If you've ever tried to push a certain direction, only to have people respond "that is management's decision, not yours," that's what I am referring to. Perhaps you have never experienced that.

"If anyone else ever produced a specification rigorous enough for me to code from, I could die happy."

That's not quite what I meant. My point is that, in a large number of development shops, this is _the_ way people deliver value. Their manager and the organization he represents is the customer, and often times they already know what they want, even if it is the wrong solution. It comes in the form of a specification, even if that is badly written. The value they bring _is_ their technical skill set, such as it is, because most of the other decisions regarding the product have already been made by the time it gets to them.

I'm not ascribing this method of delivering value to you and those you know, nor to I and most of the programmers I know. I'm ascribing this to the people in the stories they and I tell of the other programmers we've met who operate this way: offering technical skills, and otherwise having faith everyone else will figure out the customer value part. Some are getting Darwined, as people find out they don't even provide what they claim to offer, but enough people out there find good value in a cog.

</comment></comment></comment></comment><comment><USER16> By the time you turn 40, you may likely have a mortgage and family. Packing the family up and selling the house to pursue a more challenging development job in another area is just not feasible, especially when your spouse has her own career. The "Plan B" suggestions given by the author are good for people in this situation. A few more are teaching software development and writing about technology as a journalist.

Most software in the field today (80% is the figure I read - trying to find the article again) takes user input from a screen, queries a database, and sends results back to the user. After developing enough systems like this, you realize only the technologies are changing, not the problems solved. Keeping up with the latest tools does not change the dull repetition of this reality so you can easily lose incentive to keep up. And, frankly, I'm not sure companies need to pay someone with 20 years experience to do such mundane development.

Interviews for my last couple of employers centered more around growth in the organization, ie. understanding business processes, the business' industry, and organizational dynamics, not on technical knowledge. I think there comes a point when organizations begin evaluating a potential employee on potential to grow in the organization rather than grasp of functional vs. imperative paradigms, etc.

If staying a developer is what you really want, then it's probably worth learning another problem domain. Perhaps mining biological data for patterns, etc. (Heck, despite advances in neuroscience we can't explain why a stroke causes memories to "move" to another set of cells in one patient but are lost in another patient. There are plenty of problems to be solved.) Anything that makes the field fresh again. (Of course, you may run into the same problem I stated in paragraph 1.)

<comment><USER17> > you may likely have a mortgage and family

I would like to point out that these don't simply fall out of the sky. They are something you sign up for voluntarily (at least in the civilized world.)

<comment><USER18> Voluntarily? More like instincts & hormones.

<comment><USER19> voluntary. you don't need to get permission/contracts set up with the government/people to love (see "free love" on Wikipedia), and you don't need to take loans from banks (see renting vs buying articles, especially 'is renting throwing money away?' or something like that from earlier in the week on hacker news). // free love advocacy: complete.

</comment></comment></comment></comment><comment><USER20> This logic is so broken. Languages and dev platforms may change every 10 years. C++ may get stale. But image processing, or compression, or security, or low-latency high-throughput congestion-aware network protocols, or what- have-you don't.

Just don't pick things to specialize in that are guaranteed to date themselves. People who did program transformation masters theses in the mid-90's are _just now_ coming into their own in the industry.

<comment><USER15> I asked this elsewhere, but I'll ask it again here, and I am being completely sincere. Why pick things to specialize in at the expense of other things you elect not to?

Specialization is not free; it decreases flexibility, and would seem that it would decrease cross-pollination of ideas from different areas of knowledge. It increases income, for sure, but also increases the attendant risk that people won't have need for an X specialist right at that moment, or at least no one you would want to work for.

I'll grant that generalization is not free either. Someone who really needs an X specialist will pay top dollar, because the supply is likely pretty low. And people may not trust a generalist to go and implement some specialized X performing application.

I think there are opportunities and attendant risks for both. I really don't think either one wins outright. But, I'll be happy to listen to words of wisdom you might have on this.

<comment><USER8> Really, your post answers your question. There is value (and risk) in either specializing or generalizing, and there is room in the world (and the job market) for both.

Personally, I am a database specialist. I do have skills in other areas (I do python coding as a hobby and I can write C# code that at least works), but my strong suit is definitely in databases, and even with databases I focus on MS SQL Server and Access with just a little experience in some others.

I personally chose to do that because databases appealed to me and by specializing I could gain a depth of knowledge that very few generalists can. In terms of careers this limits my options somewhat, but it means that within my particular domain I can out compete most others. When the company needs a generalist that can do a lot of things, I am probably not their best choice, but when they need someone with a deep understanding of SQL Server and relational theory then I am a good candidate.

Its all about trade offs really.

</comment></comment></comment><comment><USER21> Sigh. Over 40 geezer checking in, but because I spent my 20s pursuing a music career, and then a number of years in QA, I've really only been doing pure software development for about 4 years. The problems I've been encountering these days mostly center on the physical demands of the job (typing and sitting) -- joint pain, back pain, tendinitis, etc...

Yoga has been helpful, but I'm wondering how long I'll be able to cope.

<comment><USER22> On the physical demands (speaking as an 37yo coder), I've found these things to be very helpful...

\- yoga (which you've got covered)

\- a kneeling chair does wonders for posture

\- placing your monitor at the proper height (eye-level is 1/2-1/3 from the top of the screen otherwise you tend to crane your head forward and downward)

\- stepping away from the screens regularly (set a timer to remind you because it's easy to blow this one off)

\- eye exercises (especially this one...alternate focusing on the tip of your nose and focusing on a far distance)

Good luck

<comment><USER23> > \- stepping away from the screens regularly (set a timer to remind you > because it's easy to blow this one off)

Ubuntu includes an application to enforce breaks by locking your screen. I have tried it. Works.

<comment><USER24> For Mac there's this: <http://tech.inhelsinki.nl/antirsi/>

</comment></comment></comment></comment><comment><USER12> I think there are some other questions that need to be asked here. I'm not sure exactly how to phrase this:

"Of the software-centric industries, what percentage of employees are actually writing software? What percentage of software developers do not work in these industries."

I don't know the answer to that, but for some reason I think it's well under 50%. It tends to (on HN anyway) get presented as the coders & management. But (IMO) that's too simplified to mean much.

Programming makes sense as a starting point. It's a relatively straightforward, transferable & acquirable skill set. On the other hand, things like account management, or sales may require the kind of skills you need experience to gain & are hard to develop intentionally.

Also, I think it's relatively easy to shift from coding to something else organically, but not the other way around. If you are a programmer that ends up making software for the agricultural industry , you may pick up all sorts of skills & knowledge that make you useful in other areas. If you enter that industry from another end (even if you are very close to the software), you are unlikely to become useful as a programmer. At least not without intending to.

You wouldn't be surprised to hear this story: CS degree at 22, worked as a developer of farm management software for 5 years >> a (software/technology) consultant in agribusiness for 5 years >> a manager/executive/account manager/marketing person etc. for irrigation supplies manufacturer >> something else.

You would be somewhat surprised to hear the reverse, someone with 10 years industry experience leveraging that to create software for that industry. It's not impossible, but it's worth remarking on. It probably means that either the person was a programming amateur that went pro or that they actively decided to retool themselves via a path of quite a lot of existence.

</comment><comment><USER25> What ever happened to the view that some programmers have a capable productivity that is entire orders of magnitude over others?

I think most employers just look at keeping expenses to a minimum. This means ruling out the concept of pair programming, because why would you consolidate two into one (even temporarily) when you have a brick and mortar mentality to construction that points to keeping everyone busy? And most importantly, young employees need to pay their dues. That means lower salaries for a while, and toleration of extra abuse.

</comment><comment><USER26> I wonder how accurate those statistics are. For example a dozen years ago I was called a programmer, now I am called a project manager, but I still work in software in the same group for the same employer - about as good longevity as you can get. It may be that seniority leads to job relabeling that misrepresents the true situation.

The real question is whether the people who "drop out" of the statistics still wanted to be "programmers" at 40.

<comment><USER27> What percentage of mechanical engineers still work as "engineers" a decade after graduation? The stats for CS majors are meaningless without a baseline for comparison.

<comment><USER7> The article gives the number 62% for Civil engineers as a comparison.

</comment></comment></comment><comment><USER28> Hiring by resume keyword is good only for recruiters, internal and external.

Most jobs [citation required] are found through networking. My advice is to make that your plan B, if you feel you need one. Network all the time.

As noted elsewhere in these comments, the ability to pick up a new language is not really the critical factor in experience.

The value of experience includes 1) knowing what not to build, that is, avoiding building the wrong thing 2) knowing which approaches don't work, or avoiding building the thing wrong 3) being able to pick up the technical parts of a project thoroughly--the language, code, design in good time.

This is helped by a mindset of taking the initiative for your own education, and never stop learning.

</comment><comment><USER29> Does anyone still think it really matters which programming language a developer has experience in?

It didn't take long at all after working full time as a developer to realize that software development is much more comprehensive than simply knowing a language. Shouldn't we all be able to create software in any language after a short ramp up period to learn the new language?

<comment><USER30> Some languages are really different, function, object oriented. While you can learn to write code in a new language fairly quickly, figuring out what the best practices are in a new language, what libraries are reliable, can take much longer. Maybe learning a new language the runs on the CLR/DLR or JVW isn't quite as different, but languages are ecosystems that take experience in order to make good decision.

</comment></comment><comment><USER31> In other words, if you want to be a programmer all your life, become an entrepreneur. <http://friendfeed.com/akkartik/5ab60c50>

</comment><comment><USER32> _The industry turns on a dime, but is slow to retire proven technology._

I have been slow to retire vim. In fact, I keep learning new things that make my work easier (like _:arge filename_ \--- the e means it's like _:e_ , to edit a file, but it also adds it to the arglist, so you can move back and forth the list of files with _:n_ and : _p_ ; and _:tabnew_ , _^PgDn_ and _^PgUp_ give you tabs and switching between them).

It seems inevitable that the day will come when the Eclipses and IDEAs of this world are more productive (some say it already has), and when it does, I won't be up to speed to make the switch. I don't think typing support is critical for understanding problems and solving them, but it helps.

</comment><comment><USER33> Has anyone considered the possibility that maybe the workhorse technologies in software development have begun to stabilize? C, C++, SQL, Unix etc. has been around for some time. Java and .Net aren't going to go away anytime soon. We may yet see some disruptive changes in Web development, but I doubt whether the basic Javascript/HTML/CSS scheme, or PHP/Python/Ruby set will become obsolete anytime soon.

My plan is to ensure that I can always deliver valuable software and maybe even create some that I can own. A lot of my friends are doing their MBAs - <USER2> just don't think that route is for me.

</comment><comment><USER34> I just found the same phenomenon in science career.

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

<comment><USER35> The similarity raises a question for me--what are the defining characteristics of a vocation without longevity? What do I do if I like this computer stuff, and hate doing management stuff, but just turned 30 and can't claim anything near "guru" status?

</comment></comment><comment><USER36> I have a problem with the idea that all the C++ veterans with 10+ years of experience are priced out of the market.

If they're "too expensive" to hire doesn't that imply that their services are in demand?

</comment><comment><USER37> There is one more fundamental reason. When you getting aged you have less time to stay tuned with all changes in your field. Of course, if you have a contract to maintain some old system, or playng a key role in some long project with solid finance - that is ok. But on the field motivated younger guy will easily outperform you, because you have many things to do as an adult. You simply cannot spend days and nights with laptop. So, there are two obvious directions how to reuse your experience - project management and work as a system architect. But these positions are rarely vacant, so, you probably should start your own project or a joint venture. There is no use to try to compete with younger generations on their field (coding). It is much better to reuse your own experience and use thier energy, naivety and enthusiasm.</comment>


Changelog CI (Generates Changelog and commits to pull request) - <AUTHOR> https://github.com/saadmk11/changelog-ci <comment><AUTHOR> I have created my first Open Source GitHub Action called Changelog CI. This is a GitHub Action that generates changelog, prepends it to CHANGELOG.md file and commits it to a release pull request

What is Changelog CI?

Changelog CI is a GitHub Action that generates changelog, prepends it to CHANGELOG.md file and commits it to a release pull request

How Does It Works:

It uses a python script with GitHub API to get the last release. Then it checks all the pull request merged after the last release and writes it to CHANGELOG.md or user provided file. The pull request title must start with release <space> <version_number><space> *anything else for example: Release 0.1.1 releasing a new version The Changelog CI will see the pull request and submit a commit to the pull request with the changes written in the CHANGELOG.md file.</comment>


Fast software is a discipline, not a purpose - <AUTHOR> https://lemire.me/blog/2017/11/16/fast-software-is-a-discipline-not-a-purpose/ <comment><USER2> "Avoid multiple passes over the data when one would do."

Totally disagree. Unless performance is an issue (like I'm not dealing with a trivial number of elements), I would rather use functional programming approaches to sort data into shape (think map/filter/reduce). These approaches typically result in passing over the data multiple times, and often performing multiple copies, but it makes for readable and less error prone code. Doing the performant thing consists of writing a for loop (or multiple of them unless you unroll) and automatically result with a large custom body of code performing multiple transformations on the data. It's just wasted mental effort when you write it and every time when you happen to read it again.

Most collections/array I process have trivial number of elements (<100) and you get virtually no benefit from writing optimized code.

I have also written a lot of performant code, and the lesson is always benchmark benchmark benchmark. The results do not always fit the mental model about what you think should be the fastest. In particuliar avoiding cache misses is far more important than you might think.

<comment><USER3> Readable and less error prone? As opposed as to proven to be correct for example? Recursive functional code is a pain to prove to be right and not blow up stack. Multiple passes (when interspersed with other accesses) can blow up cache.

Even calling through a lambda is a cost compilers cannot easily optimize away unless you help them. (Even in C++.)

You do get the benefit of optimizing all the "trivial data size" code when it is all the functions being written in such silly way. Difference of 10% in one function as opposed to across whole application.

Benchmarking is often even harder to do right than writing good tests. (In fact is tied to it.) Instead of benchmarking, be a real computer scientist and prove bounds and memory allocations.

<comment><USER4> How is it difficult to prove if a recursive call is tail-recursive or not? If it's tail-recursive and your language supports tail-call optimisation then you proved that there will be no stack blow-up.

<comment><USER3> For simple calls, not. For something more involved? (Dependent functions, corecursion, partially stateful code.) Very which is why compilers fail to optimize it in general.

</comment></comment></comment></comment><comment><USER5> "When people train, they usually don't try to actually run faster or lift heavier weights. As a relatively healthy computer science professor, how fast I run or how much I can lift is of no practical relevance. "

This is really strange. If you don`t try to lift heavier weights you will not have progress. It is called progressive loading. I don`t wan`t to go into the details of the training, but if you do not track and improve your training (with whatever goal you have in mind, there are different kinds of progressions) you are the same as the programmer who write bad code, and knows it is bad, but does not care.

<comment><USER6> > If you don`t try to lift heavier weights you will not have progress.

That depends on what you're aiming for - if you're aiming for tone rather than bulk, you'd go for more reps of the same weight rather than stepping up the weight with the same reps, wouldn't you?

(Although I guess, technically, that does count as "heavier" since you're still moving more weight in your sets.)

<comment><USER7> The general consensus is there's not really such thing as 'tone' \- usually that's just a matter of low bodyfat % which shows your muscles more promimently.

What you're talking about somewhat though is balancing hypertrophy and strength goals - where someone may wish to increase their reps to say 8-20 which is demonstrated with studies to increase muscle size, but is poorer for progressing with strength (where 3-8 reps is more effective)

</comment></comment></comment><comment><USER8> Regarding the point "Don't use floating-point operations when integers will do." I agree that using integer arithmetic can result in cleaner, easier to reason about code when applicable. It then follows that because of these traits the software will faster.

But integer arithmetic is not necessarily faster than floating point arithmetic in general; see for example: [https://youtu.be/3K2LmnaLLF8?t=31m10s](https://youtu.be/3K2LmnaLLF8?t=31m10s).

<comment><USER9> > But integer arithmetic is not necessarily faster than floating point > arithmetic in general;

GPUs was the first place I feel like floats got a much better pathway than any other data type - graphical pixel manipulations also can get away with much higher arithmetic errors, because it's all going to get rounded down to a pixel eventually.

On the other hand, the only place where I've really worked heavily with fixed point was on a graphical interface toolkit (MIDP on ARM I was working with would've had to use softfp for floats, so fixed point was hugely superior).

<comment><USER3> Come on, all reasonable ARM have NEON and VFPv3 (including cortex M) about the only place I saw something that didn't was an old internet router. Hardware completely unsuited to maths.

Softfp does not preclude the use of floating point math at all. It means you pay an extra cost when passing floats as arguments. (Which means you should rather use a hardfp math library if possible.)

<comment><USER9> > Come on, all reasonable ARM have NEON and VFPv3 (including cortex M) about > the only place I saw something that didn't was an old internet router

ARM MIDP UI code in 2003-2004 - very interesting chip (ARM926EJ-S [1]) ... not that I ever invented anything new to do all this, all of what I did was learn & repeat tricks from 1980s arcade consoles.

[1] - [https://en.wikipedia.org/wiki/Jazelle#BXJ:_Branch_to_Java](https://en.wikipedia.org/wiki/Jazelle#BXJ:_Branch_to_Java)

</comment></comment></comment></comment><comment><USER3> There is indeed a point where being fit and clean turns into an obsession. There is such a thing as premature optimization.

Commonly the mistakes costing performance are caused in part by bad design though, typically arrived at by either not caring or not fixing a quick and dirty prototype with something reasonable. Or "brute force" bug fixing in concurrent code.

If I got paid for every unnecessary or replaceable synchronized statement in Java, I'd be rich. Or a fat data copy made using a queue.

<comment><USER10> > There is indeed a point where being fit and clean turns into an obsession. > There is such a thing as premature optimization.

There is also something as no optimization (at any point), and I see far more often in the wild. I think more devs should run their app on a cheap Android phone or cheap consumer entry laptop to see what is happening when it's not running on 32 gb i7 octa cores. I recently got some entry level machine from a friend to play around with; it has 4gb and flash drive; it is eerie how slow the thing is; this is what is sold in walmart etc at the entry price level, so fair to say, if you are B2C software dev, this is your audience.

For fun, I tried to do some development on it; Atom/Vscode started both snappy, but when devving on it a bit, they became rapidly unusable (cpu 100% always and typing appearing seconds after you typed it); emacs was ok; vim did well. You cannot run Electron on that and yet, that's what many people deliver. And my suspicion is that most don't optimize when using that (if you are fast software minded, you wouldn't use it in the first place, not because it's inherently bad, but because there are too many moving parts you cannot influence). Please try it on these machines to know what you are doing to your users :)

</comment></comment><comment><USER11> 1\. Make it work

2\. Make it right

3\. Make it fast

 _" Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."_ \- Donald Knuth

<comment><USER12> This quote is so misunderstood and so abused all the time.

The point of the statement is to not micro-optimize this and that corner of the program without having any data to guide you on what you should optimize and how.

It's not a rallying call to forgo all concerns about application performance and efficiency.

The mis-application of this quote is the root of all evil in modern software IMO.

It's why a chat program takes 500MB of RAM and why many programs take 10 seconds to load even though there's no technical reason they cannot startup instantly.

You should make it right and fast from the very start. You should not make something that "works" but is full of bugs and slow as hell. Like, that makes no sense at all. If it's full of bugs then it doesn't work. If it's slow as hell then it doesn't work.

1\. Make it work correctly and efficiently (to a reasonable degree)

2\. Make it even faster

3\. Make it better

<comment><USER6> > 1\. Make it work correctly and efficiently (to a reasonable degree)

Unfortunately, this took your team 6 months and the people that launched their app 4 months ago (having opted for "make it work") now have 90% of your market and you've all just been made redundant because the customers do not care whether your app is "more correct" and "more efficient" because they just plain damn couldn't use it.

There's a reason "worse is better" applies to software.

<comment><USER12> There's no evidence than any of this is true.

First market is not often the winner. Facebook came very late to the social media scene but it dominated.

Google came very late to the search engine scene, and people don't even remember this but there was a time when there were a ton of search engines and anyone at the time would probably think that the search engine market is saturated and there's no space for a new product.

All evidence actually points to better products dominating the market even if they come late.

If your competitors released their app 4 months ahead of you but it was full of bugs and always hangs up, and then you release your product which actually works and performs well, people will see your product as a breath of fresh air.

Another example is the Chrome browser, which came at a time when Firefox and IE were competing fiercely for market share, and Chrome completely dominated them on the simple basis that it was _really fast_.

For most products it doesn't even cost 6 months to make it fast. If you have that as a goal from the very start, there will never be a stage of "omg it's really slow let's try to make it a bit faster". It will always just be fast.

<comment><USER6> > Chrome completely dominated them on the simple basis that it was _really > fast_.

It isn't that simple - a lot of Chrome's success came because they "made it work" in ways that Firefox (horribly wasteful of CPU, memory, battery life) and IE (shambles in every department) didn't. Also helped in large part by having an enormous web monopoly pushing it and favouring it for their properties.

But you're definitely right that it came after them.

</comment></comment></comment></comment></comment><comment><USER13> > But then, I dress cleanly every single day even if I stay at home. And you > should too.

Nope.

It's good to know how to produce fast software, but also good to know when to do so. Lemire sounds like he has some psychological issues to work out.

</comment><comment><USER14> I've spent the last 20 years not caring about performance. Not once has performance ever been a real issue on any project I've been on. Imagine how much time I could have wasted prematurely optimising.

<comment><USER15> You've never written any code to run in parallel? Or used a data structure or algorithm with O(logN) time instead of O(N) time?

<comment><USER14> I probably have, without particularly prioritising it. Ok, perhaps I should have said "overly caring about performance". Of course I have used built in functions in languages that take advantage of this when searching or sorting - but no, I can't remember a time when I had to get into the nitty gritty of low level performance enhancement, unless it was in a coding challenge of course.

</comment></comment></comment><comment><USER16> For most people, "seeing inefficient code" is basically hallucinating. There's real truth to the mantra about premature optimization. I've seen people so many times worry about the performance of something, thinking that some code _looks slow_ , when in actual reality it's a complete nonissue.

Software development is all about compromises, just like any kind of real world engineering. Building a stage for a weekend festival is different from building a bridge over a river. We're always on a budget, so if I can work much faster and safer and lose some marginal efficiency, I'll do it—unless marginal efficiency is what I'm competing on, which it usually isn't.

</comment><comment><USER17> _There is a reason we don't tend to hire people who show up to work in dirty t-shirts. It is not that we particularly care about dirty t-shirts, it is that we want people who care about their work._

I don't quite agree the cleanliness of clothing is a good proxy of one's craftsmanship or personality, even if t-shirts are acceptable garment at a particular workplace.

</comment><comment><USER18> It maybe different in US. But in some Asian countries, most people care about the money at the end of the day.

So yea, they don't care. But does it matter ? People are happy as long as they get paid at the end of the day. They don't care about the quality of code written.

Not saying its a good thing or bad thing. Just the way it is.

</comment><comment><USER19> I think of myself as a software craftsman. Just like a master carpenter, the things I make should be not only functional but beautiful as well. Of course we should "care" about our work.

However there are other metrics besides performance that are worth caring about, e.g. readability, maintainability, etc...

<comment><USER20> Meeting deadlines, getting paid, whether anyone will ever care about the code, again, etc.

I also try to be a 'craftsman', and I try to pick work where that's an option, but I find that in practice, more often than not I have to care about various 'other metrics' at the detriment of craftsmanship.

Although I suppose being skilled at managing these various metrics could in itself be considered craftsmanship. And perhaps that mindset helps a bit with not getting utterly depressed at some of the shit I'm forced to deliver...

</comment></comment><comment><USER21> Code bloat could easily be sorted out by forcing people to read the generated assembly of their creations.

<comment><USER22> This is easy and convenient in Common Lisp with the DISASSEMBLE built-in function.

</comment></comment><comment><USER23> Blah. You get a lot of _performance "for free"_ by getting the overall _architecture of a system right_. By starting with optimizations, you usually hit the "limit of your brainpower" very soon, like before you know enough to architect things right, so you _mess up the architecture_ (think like "shit, we ended up with this location dependent time conversion logic in the backend instead of on the clients, so now is un-cacheable, but it's too late to refactor across multiple teams now... shit").

Just _avoid building un-optimizable systems_ (nowadays it's harder than ever to avoid this... all the tools and services lay traps for us), and then you can safely leave the optimizations for later...

If you can't avoid building an un-optimizable system, all your clever early optimizations are worthless anyway. If you can, they can be postponed anyway.

Now, _what I 'd really want to read would be an article/book about avoiding the traps that lead people to get stuck with un-optimizable systems!_ (Though I imagine it's in general an unsolvable problem if natural evolution didn't solve it either: at some point your body accumulated enough de-optimizations that it basically stops working or being fixable/optimizable, so you die, and some of your memes and genes carry on in "rewritten forks" aka "other newly born people".)</comment>


Neal Stephenson Heiroglyph project launches - <AUTHOR> http://hieroglyph.asu.edu/

<comment><USER2> I don't think progress towards big goals have stopped completely, but a lot of work is being done in areas that will indirectly help accomplish the big goals. Stuff like tiny computers, 3D printing, battery technology etc. Those technologies can make bigger goals possible and more easily obtainable without spending billions of dollars.</comment>


Four Lessons From Evernote's First Week On The Mac App Store - <AUTHOR> http://techcrunch.com/2011/01/19/evernote-mac-app-store/

<comment><USER2> This seems like a really big deal for SW developers. The return of the desktop would be incredible.

</comment><comment><USER3> When the app store for iOS was released my first thought was that the Mac really needed one of these, mostly based on how easy it is to install things through Linux package managers like apt - and of course updating everything easily was nice too.

Over time (and as my experience with OS X grew) I slowly thought that it was less and less of a deal - and that few people were actually expecting a Mac App store, so I guess I just gave up on the idea.

Now it's here though, I can't believe how obvious it all is. They should have had one of these years ago. I don't think there are even rumours at this point, but Microsoft would be mad to not build one for Windows too.

</comment><comment><USER4> 320k downloads in a week is pretty amazing.

This really makes me wonder how many sales the top ten Paid Apps received. Fingers crossed that Rovio releases the Angry Birs stats.

<comment><USER5> Chopper 2 was #2 on the Mac app store for a couple weeks and the developer says on his blog that it sold 100,000 copies (at 99 cents, mind you) in its first week[1]. So, We can guess #1 is roughly double that.

So, back of napkinning:

100,000 units sold / 7 days = 14,285 copies a day.

You can guess, then, that Angry birds is probably selling 20,000 copies a day at the very least, which at 5 a pop is US$100,000/day gross, 70k net.

Wow.

[1] <http://majicjungle.com/blog/>

</comment></comment><comment><USER6> Don't understand why windows haven't invented an app store years ago...

<comment><USER7> Remember Vista Marketplace? no? No me neither.

</comment></comment><comment><USER8> Wait, didn't you have to pay for it before? I saw it free in the app store. That would explain the jump in downloads.

When I saw it free, I considered installing it as well.

<comment><USER9> No, Evernote uses a freemium business model. The client is always free; you only have to pay if you store more than some X amount of data.

</comment></comment><comment><USER10> Terrific piece.</comment>