REMME – A blockchain-based protocol for issuing X.509 client certificates - <AUTHOR> https://github.com/Remmeauth/remme-core/tree/dev <comment><USER2> I spent 5 minutes trying to find out what and how this is supposed to work and all I figured out is that there's some kind of Hyperledger Sawtooth blockchain (whatever that is). No idea how that's helping with authentication for a web service.

Edit: I now skimmed through the linked architecture overview video and I don't see how that makes authentication any more secure: They seem to build a "distributed storage/management facility" for public keys from what I get from the video. How private keys are handled is nowhere mentioned. So I don't see how that makes anything more secure. From what I understand it might only make the verification part more distributed.

<comment><AUTHOR> REMME WebAuth solution uses one of the better ways of authentication through X.509 client certificates. Certificate-based authentication allows users to securely access a server by exchanging a digital certificate instead of a username and password. This means the client is not sending a username or password to the server which helps in preventing phishing, keystroke logging and man-in-the-middle (MITM) attacks among other common problems with password-based authentication. The certificate hash and status are stored on the REMME Blockchain. Server checks status of the certificate before login on the site/service.

<comment><USER3> I've read through some of the docs and I'm still struggling to understand the point of the blockchain in this case.

Specifically, what is it offering above, say, self-signed client certificates? From what I've read, you're not adding incontrovertible identity information to the blockchain so what does registering your certificate buy you?

Or put another way, when the server checks your status what do they find out?

<comment><AUTHOR> REMChain is only part of certificate management infrastructure and also an open source solution. We are working on applications that related to web authentication through OAuth standard, domain validation, KYC, SDK for IoT, but also propose to more broad tech community to search useful approaches for its current functionality. Users pay to the network for the work related with certificate generation, registration, and checks of its validity status during a login process. REMChain makes available to companies to generate its own protected certificates for different uses.

</comment></comment></comment></comment><comment><USER4> If you want a technology to be widely adopted ("better" auth), and it relies on a niche technology (blockchain), then you need to write your README/elevator pitch/copy/docs in a way that doesn't assume the people using it are experts in the niche technology.

I'm not dumb, but I'm also not a crypto expert and have no desire to become one. I also know next to nothing about the blockchain and have no desire to learn because it's not my field. My day-to-day walking around knowledge is already packed with stuff related to my field and I just don't have the bandwidth to also become a blockchain expert just to roll something out. I suspect most people who would potentially be rolling out software that would use a blockchain-based auth library are in the same boat.

As it stands I have absolutely no idea how this thing works or why I would ever want to use it.

<comment><USER5> 99% of these crypto projects are aimed to scam people who get excited about words and expressions like "decentralised", "proof of work", "proof of stake", "unbreakable", "foolproof", "fault tolerant consensus"

As it the empty meaningless words this still can happen:

"Ethereum Classic (ETC) Hit by Double-Spend Attack Worth $1.1 Million"

<comment><USER6> The entire goal of many blockchain projects is to add as many middlemen as possible to skim fees.

</comment></comment></comment><comment><USER7> Most companies are unable/unwilling to implement U2F. What are the hopes they adopt "a blockchain-based protocol used for issuing and management of X.509 client certificates"?

<comment><AUTHOR> Many changes occur only after the painful experience experienced by the company. The first ones to implement cybersecurity solutions are cautious and prudent, who do not want to find themselves in a situation where a cyber attack will erode confidence in them.

</comment></comment><comment><USER8> I don't see why trusting whoever has the most hashing power at any given minute is and advantage.

<comment><AUTHOR> What are your concerns about the safety of this technology?

<comment><USER3> I can't find anything concrete about the consensus protocol, can you help?

From what I've found out, to add a block the following happens:

A set of 10 masternodes are randomly selected from the pool of masternodes. The probability of selection is somehow weighted by the node's reputation. Q. How do the masternodes agree on that random selection?

Once 10 are selected, each creates a block and shares it with the other 9. One is selected. Q. How do they agree on that one?

The winner gets a reward, adds the block and then the process is repeated. This seems reasonable.

Have I got this right? If so, it strikes me that the strength of the protocol is in the answer to the first question (not sure why there are 2 stages, why not just pick 1?).

<comment><AUTHOR> Yes, it is right. You can read more about the concept of consensus here: [https://medium.com/remme/proof-of-service-consensus- algorith...](https://medium.com/remme/proof-of-service-consensus-algorithm- overview-57c359290207) It is still under development, hope I can share tech docs about its implementation soon. 2 stages are important for raising the speed of certificate generation that is critical for that sphere.

</comment></comment></comment></comment><comment><USER9> Quoting remme.io:

> No more passwords — no more break-ins. REMME implements unbreakable, > foolproof user authentication to protect your users, employees, and > company's data from cyber attacks.

This is laughable. Nothing is unbreakable. This is using a blockchain so I'd be willing to bet that it's vulnerable to the 51% attack.

This account's post history is also suspicious. They only post articles and links to this project, and do not have any comments (no community engagement).

<comment><USER6> Nor will this stop phishing of users handing over their private keys :D

<comment><AUTHOR> Why does user need to hand over its private key? It obviously breaks the security policy.

</comment></comment></comment><comment><USER10> Related [https://danubetech.com/download/dpki.pdf](https://danubetech.com/download/dpki.pdf): possibly interesting at the DNS, CA level. I'm struggling to see how this applies to user passwords though. Wouldn't users still need some form of "password".

<comment><AUTHOR> You are right. There are a lot such ideas of implementations for DNS, CA level etc. For authentication, there are also field to try it, but of course, blockchain isn't a solution that would fit everywhere.

</comment></comment><comment><USER11> So Duo without requiring a first password? Where's the value in making something like this distributed?

<comment><AUTHOR> It depends on how you estimate CA vulnerability and how much your organization ready to trust it. There are enough cases when important auth info was leaked.

</comment></comment><comment><USER12> TLDR: Blockchain-based distributed PKI.

Does it come with its own 51% exploit?

Yes, it's a product, monetized by yet another crypto-coin: [https://remme.io/](https://remme.io/)

</comment><comment><USER13> So...basically just public/private key authentication?

<comment><AUTHOR> The answer about the auth process with current protocol was written above.

</comment></comment><comment><USER14> pity it's blockchain based

<comment><USER5> You mean, just to have it painfully slow, use obscene amount of energy and be vulnerable of 50%+ attacks? Yeah it is great. Not. :)

<comment><USER15> >painfully slow

you can send coins securely with Ark in less than 8 seconds

>use obscene amount of energy

not in Ark, or any other DPOS

>be vulnerable of 50%+ attacks

what is merged mining, DPOS, renewable energy? the world may never know.

<comment><USER5> Sorry I am not up to date with 2019 bullshit bingo, these mean nothing: Ark, DPOS, merged mining

<comment><USER15> ark is a coin. dpos is an alternative to proof of work. you get paid by holding the coin. merged mining is from 2012, it's when two coins use the same algorithm so you can mine both at the same time, securing both chains</comment></comment></comment></comment></comment>


Why Twitter Should be Very Worried about Google+ - <AUTHOR> http://siliconfilter.com/why-twitter-should-be-very-worried-about-google/

<comment><USER3> > For a long time now, Twitter's proponents have argued that Twitter's 140 > character limit was an advantage. It keeps posts brief and to the point. > Once you use Google+ for a bit, though, you come to realize that those > constraints are really just annoying at the end – and likely hard to explain > to a mainstream user anyway.

I have to say, I really disagree with that one. I didn't truly appreciate the value of the 140 character limit _until_ I spent some time using Buzz. Once people are free to dump an entire essay into your timeline, it ceases to feel like a quick visit that I can pull 20 or 30 bite-sized nuggets of interaction out of, and more like as RSS feed -- an enormous backlog of reading I can never hope to catch up on and stop caring about.

<comment><USER4> I actually think Facebook got the balance right. 400 characters (approx) of unformatted in the default status updates, and a notes function (which can optionally be configured to import an external web log) that needs to be accessed through a separate user interface.

Facebook statuses are long enough that you can actually say something meaningful without allowing you to ramble on for too long.

</comment></comment><comment><USER5> >Google, being late to the party

This is biggest advantage I guess. Seeing both the models (Facebook and Twitter) working, Google+ tries to bring the best of both, wherein when I add someone to a circle, it's like following him rather than adding him as a friend, which is more like Twitter; but with it's rich media interface, the stream looks as good as Facebook. And not to mention the granularity of user control over what to share with whom, which again is a better version of what we have on Facebook. So it's more like the best of both worlds where you don't necessarily have to be friends with someone to broadcast and if you are friends, then well, you are friends.

</comment><comment><USER6> I think Yammer has more to fear from Google+ than Twitter. Once you can auto- integrate Google+ with Google Apps, you've essentially destroyed 99% of Yammer's value proposition.

<comment><USER7> Agreed. Now Google just needs to getting around to enabling "Accounts" with Google Apps. [http://www.google.com/support/forum/p/Google+Apps/thread?tid...](http://www.google.com/support/forum/p/Google+Apps/thread?tid=17b45c62b43447f6&hl=en)

</comment></comment><comment><USER8> Well. I added Markus Persson (aka Notch, of Minecraft fame) to my Following circle, and... his posts are always bumped to the top of the stream because so many people comment on them.

Posts can also take up a lot of space when there are attached pictures/videos and comments.

So Twitter has these huge advantages that everything is streamlined and kept short. Google+ does not; and it's not really necessary if you don't use Google+ as Twitter. This is also something that Google can fix, so we CAN (then) use Google+ as Twitter.

<comment><USER9> It's funny because the same exact thing happened to me. Notch now dominates my Stream, to the point I might just remove him from my circles.

<comment><USER10> At the top right of each post is a tiny arrow in a circle. It's a menu -- choose 'Mute this post' and it will no longer float to the top.

<comment><USER9> The problem is that Notch tends to post stuff all the time. Right now I have 6 of his posts on the first page of my stream. And they are all from the last 12 hours or so. If he keeps up that rate, I'll be muting a dozen posts a day, heh.

<comment><USER11> Check out this post from a Google+ engineer: [https://plus.google.com/107117483540235115863/posts/GTESUy4y...](https://plus.google.com/107117483540235115863/posts/GTESUy4y93t) (sorry, Google+ users only) This was identified as an issue that's planned to be fixed in the next few days.

</comment></comment></comment></comment></comment><comment><USER12> I think we all need to appreciate the fact most people use Facebook and/or Twitter because they are agnostic - that is, are not tied or linked to any singular email account. I have a Gmail account - albeit "lay persons" in the tech world - use Yahoo or Hotmail, and sure, some use Gmail [shocking generalization :)]. Most, in some capacity, usually check FB and/or Twitter on their mobiles and website daily. Many do not even "log into Google" to use the search engine [why would they?]

Facebook works. Twitter works. All their friends already exist on it - <USER2> friends list are closed, Twitter's are open. Both do everything they could possibly want it to do "connect to their friends" and "find what's happening in the world". In my mind - it's "Google and Bing" all over. For example, Bing is arguably just as good as Google now yet everyone continues to use Google. Why will Google+ bring about such a "rapid shift" that it will lead to a hemorrhaging of users from Twitter and/or Facebook ?

Google+ - great for technology people who want to "control their data". My friends don't even understand what "exporting data for portability" even means. They use Facebook, see their friends posts, upload photos, check-in to places and they love that. Those that use Twitter do so to find out instant real-time updates and news from around the world. Twitter focus on this and this only - not building and trying to be "everything to everyone".

Facebook will improve their "groups" feature to something similar to Circles and continue to innovative. Twitter will continue to expand as the real-time news service because it is so ingrained in modern culture now. People "tweet" it just like people "Google it" [in the verb sense]. Google+ - is great for "forcing" FB to continue to innovate - but I am still a cynic in relation to it's ability to have such a high incentive draw that users leave FB or leave Twitter "exclusively" - or even "in addition to" - Google+.

[that said, any chance of invite :) email in profile]

edit: Thanks to those that sent an invite. Seems that Google's disabled them :( i.e. there are no links in the sign up emails so there is no way to join. Awesome effort though! Thanks again +1 [pun intended]

<comment><USER13> Tried with this workaround: Create a circle, add a person to it, then share some content in the circle. Everyone who isn't yet member of Google+ gets an invite. Let us know if it's still working.

<comment><USER14> When about an hour ago, someone to whom I sent an invite clicked on the big orange button in the email, they got a page telling them, "Already invited? We've temporarily exceeded our capacity. Please try again soon."

<comment><USER15> They are rate limiting new sign ups. The person doesn't need to get a new invite, they just have to try the invite again later.

</comment></comment></comment></comment><comment><USER16> There is one thing that Google+ currently lacks that both Twitter and Facebook have:

      Like us on Facebook! facebook.com/ProductFoo

      Follow us on Twitter! @ProductFoo

In G+'s (hypothetical, since they haven't done it yet) case, neither the phrase nor the url are as catchy or memorable:

      +1 us on Google! plus.google.com/ProductFoo

<comment><USER17> Or was it "Follow us on Twitter! twitter.com/ProductFoo" at first?

The same way +1 could develop in to "+1 ProductFoo". Just give it some time.

<comment><USER18> or just +ProductFoo

<comment><USER19> I think this is the most likely. The top left of the google bar is +[name], and Andy Hertzfeld referenced other people in this way in his post: [https://plus.google.com/117840649766034848455/posts/FddaP6je...](https://plus.google.com/117840649766034848455/posts/FddaP6jeCqp)

</comment></comment></comment></comment><comment><USER20> I think if Google+ has a decent set of APIs and doesn't go on a "kill the client" spree, it might be a fairly interesting fight.

<comment><USER21> I was just about to say that. Google needs to make sure they get the API's right from the start, and not have a huge change of hard later, and say, like Twitter, that they want to improve the UX or whatever, when they really just wanted to be able to send you their ads.

Google should make sure they're not giving functionality that they're going to take away later on and piss off a lot of developers.

</comment></comment><comment><USER22> Google+ is reducing the amount of leverage Twitter has to monetize their service. I believe Twitter has waited too long to make money off of its platform. The only ones seem to be making money off of Twitter is the 3rd party developers that are making it easier to use the product!

</comment><comment><USER21> I've just realized today that I can use Sparks to get the news I'd be interested in finding on Twitter. For example if I look for "antisec" on Spark, I get pretty good new results with a much better signal-to-noise ratio.

<comment><USER23> Couldn't you get the same thing by searching Google News?

<comment><USER21> I've never really used or liked Google News interface. But they said Google News is just a part of it, since they also show blogs, videos, etc

<comment><USER23> _But they said Google News is just a part of it, since they also show blogs, videos, etc_

Google's search result pages have options to search blogs, videos, realtime, etc too. Seems like they just integrated this functionality into Plus.

</comment></comment></comment></comment><comment><USER24> While I realize it mentioned it in the article, and that it's forthcoming, I'll withhold my opinion of the "threat" to Twitter and Facebook until I see what kind of API they're going to roll out for Google+.

One of the reasons I like the older services is that I can access them via SMS - in fact, Twitter is just about perfect for that use case.

</comment><comment><USER25> One of the things that is great about Twitter is that you can subscribe to someone else's posts without them having to take any action. Is something similar available on Google+? Are your posts required to be directed toward a specific circle? I can't just add myself to someone I like's circle, right? They have to add me?

I'd appreciate any clarity on this, I think that the asymmetry and follower driven nature of Twitter is a huge asset. Merlin Mann isn't going to add 160,000 people to a "comedy" circle.

<comment><USER26> > Is something similar available on Google+?

Yes, you can add someone to your circles without them doing the same to you. There's even a default circle called "Following" for "People that you don't know but find their posts interesting" (i.e., basically the same thing as following famous people on Twitter).

> Are your posts required to be directed toward a specific circle?

Sort of. They can be directed at any combination of your circles, or all of them.

> I can't just add myself to someone I like's circle, right? They have to add > me?

Right, you can add anyone you want to your circles, but you can't touch their circles at all. It's like Twitter in that respect.

<comment><USER25> So by adding someone to one of my circles, I'm automatically added to their "Following" circle? It seems like you mean the opposite, that I would put someone I don't know really well into _my_ "Following" circle, but that still means that I don't get a feed of their postings, right?

Unless, as someone else mentioned, they set their post to "public", does that post then show up for everyone who has the poster in their circle, regardless of wether the follower is in a poster's circle?

<comment><USER27> You seem to have it mostly right, but to clear up some confusion:

There's basically two directions to consider.

Your circles are for your outgoing posts. When you post something, you choose which circles are allowed to see it (or you could choose individual people, or "Public").

On the flip side, your circles inform your incoming news stream. By putting someone in any of your circles, you basically say, "I could be interested in what they say."

What appears in your stream, then, are posts in the intersection of the two: from someone in one of your circles, and to a circle of theirs that they put you in.

So to answer your original question: Google+ can operate in the Twitter modality exactly. You put someone in any circle ("Following", by convention), and then any posts they make to "Public" will appear in your stream. The difference is that the person you're following doesn't have to direct all his posts to "Public". He or she could send some to specific groups of people, which you wouldn't receive.

</comment></comment></comment></comment><comment><USER28> I thought Google Wave was Twitter's doom. Then I got to try Wave. I think it's too early to hold a wake for Twitter until everyone can get into Plus.

<comment><USER29> A closed communication tool mostly targeted at projects vs an open status broadcast is hardly each other's doom.

</comment></comment><comment><USER30> As much as I like Twitter, I basically agree with most of the points in the article. G+ will attract developers, it does have a clear path to monitization, and for people who already use GMail+Calendar+Picasa+etc it is a natural since it is always available.

</comment><comment><USER31> author is wrong..

Google Search right now has more users than FB and twitter and linkedin combined..its a direct threat to all not just one and those Google Search users have a network effect as we saw in several past search engines just absolutely just die off due to competition from Google</comment>


Ask HN: Is anybody skilled in lockpicking? - <AUTHOR> If yes how did you acquire this skill? What is the best way? What was the best purpose this skill served you? <comment><USER2> I won´t define myself as skilled because I am not a profesional, there are people that get paid for that.

Out of curiosity I learned myself playing with locks, its a matter of practice and feel.

If you want to go deep into it they sell transparent training locks so you can see the springs.

The best purpose was impressing friends and also emergency situations that I needed to unlock something that im allowed to (mine or friends).

<comment><AUTHOR> How long did you spend learning this or just randomly trying to pick locks until you were able to pick the basic locks?

</comment></comment><comment><USER3> I've toyed with it, and the best way to learn seems to be being taught at least the basics by someone who knows how to do it. There's a surprising amound of lockpicking clubs, and if you're going to any kind of hacker event there's likely someone who's willing to show you the basics.

<comment><AUTHOR> Did trying it out yourself just not work for you or is it that being taught by someone significantly reduces the needed time investment?

<comment><USER3> I honestly didn't spend overly much effort on getting started on my own, but I found getting the basics shown in person was way more effective to get started than trying to follow instructions online. Working on improving those skills on my own then worked just by doing it, but seeing a technique done and getting immediate feedback the first few times was really helpful.

</comment></comment></comment><comment><USER4> related, [https://hn.algolia.com/?utm_source=opensearch&utm_medium=sea...](https://hn.algolia.com/?utm_source=opensearch&utm_medium=search&utm_campaign=opensearch&query=lockpicking&sort=byPopularity&prefix&page=0&dateRange=all&type=story)

</comment><comment><USER5> Maybe start here: [https://toool.us](https://toool.us)</comment>


About V, the language Volt is written in - <AUTHOR> https://volt.ws/lang <comment><USER2> Hi,

Developer here. I was going to post this here in a couple of weeks after launching the product and creating a separate site for the language with much better information about it.

I'd also like to hear your opinion about not allowing to modify function arguments except for receivers. This is an idea I got that isn't really implemented in any language I know of.

For example: mut a := [1, 2, 3]

So instead of multiply_by_2(&a)

we have to return a new array (and this will later be optimized by the compiler of course)

a = multiply_by_2(a)

I think this will make programming in this language much safer, and the code will be easier to understand, since you can always be sure that values you pass can never be modified.

For some reason all new languages like Go, Rust, Nim, Swift use a lot of mutable args in their stdlibs.

You can still have methods that modify fields, this is not a pure functional language, because it has to be compatible with C/C++:

fn (f mut Foo) inc() { f.bar++ }

<comment><USER3> I'm not sure if I'm the target audience for this (low-latency trading), but here's my thought - code which would allocate in a fast path is a strict no-go for me, and this runs fairly close to that in a few regards:

> It seems easy to accidentally make allocating code allocate by changing some > variable names (b = fnc(a) - oops, allocation)

> I would be extremely wary of trusting a compiler to realize what sort of > allocations are optimizable and not - I already have problems with inlining > decisions, poor code layout, etc in fairly optimized c++/rust code compiled > by gcc+llvm.

Replace allocation with any other expensive work that duplicating a datastructure would result in, and you have the same story. I suspect many of the people that would be evaluating this compared to C/C++/Rust have similar performance concerns.

<comment><USER4> You need to stop pretending they are not globals. Just accept you work on one continuous memory patch and are simply passing pointers around. If you don't lie to yourself, you can't shoot your own foot when the compiler do not see your lie.

<comment><USER5> not all abstractions are leaky, many compilers/language grammars enforce the paradigm of local lexical contexts.

Playing a game without accept its self imposed restrictions whose player accepted voluntarily would be lying to oneself.

</comment></comment></comment></comment><comment><USER6> > V is compiled directly to x86_64 machine code (ARM support is coming later) > with no overhead, so the performance is on par with C.

Direct compilation to x86-64 machine code does _not_ get you performance on par with C (by which I assume the author means GCC or Clang). The optimization pipelines of GCC and Clang have had decades of work put into them by some of the best compiler engineers in the world.

Since the author states that the compilation time is linear, this would seem to imply that a full suite of optimizations are not being done, since many optimizations done by GCC and Clang have nonlinear complexity. It is easy to get fast compilation if you don't perform optimizations.

> \- Thread safety and guaranteed absence of data races. You no longer have to > constantly ask yourself: "Is this thread safe?" Everything is! No perfomance > costs either. For example, if you are using a hash map in a concurrent > function, a thread safe hash map is used automatically. Otherwise a faster > single thread hash map is used.

This description doesn't guarantee freedom from data races. (Java's memory model basically fits this description, for instance, except for the specific case of hash tables, which aren't built into the language.) Even if it did, the tricky part is determining what a "concurrent function" is. The obvious ways one might imagine doing this tend to fall down in the face of higher- order functions.

<comment><USER2> Yes, you are right. I had a mental note to update the description, I never expected this to be posted on HN so early :)

Just updated it:

> V is compiled directly to x86_64 machine code (ARM support is coming later). > There's also an option to generate C code to support more platforms and > achieve better performance by using sophisticated GCC/clang optimization.

<comment><USER7> Why not output to LLVM code instead of C?

<comment><USER2> LLVM is a huge dependency. It's very complex and slow. And it's C++ :)

I want every part of the language ecosystem to be simple so that everyone can contribute.

<comment><USER8> May be you should say "LLVM will be considered once its code is converted to V." :-)

<comment><USER2> :)

</comment></comment></comment></comment></comment></comment><comment><USER9> My two biggest questions about V are 1) How is memory managed?, and 2) How is concurrency done?

"V has no runtime". No GC, but you don't have to manually release memory, like Rust but much easier. Sounds great. How?

And "no race conditions ever" and "everything is thread safe". You can do that with "no runtime" fairly easily if there's no goroutine-style concurrency. I didn't see any mentioned, but I could have easily missed it.

Those two aspects of the language are fundamental enough that I would certainly want to read about them near the top of any overview of the language.

<comment><USER2> Good question. I haven't mentioned memory management because it's not done yet. I know for sure there won't be a GC or reference counting.

I want to do something similar to Rust's approach, but much much simpler. It's not an easy task.

Right now the language handles very simple cases. Small strings are placed on the stack, local variables that are not returned are clean up automatically.

Globals are not allowed, function args can't be modified, so that helps a bit.

<comment><USER10> No GC, no reference counting, no manual memory management... Hmmm.... Not everything can be managed by RAII/SBRM... Let say I have a function which loads a complex document (like spreadsheet), does some changes, saves the document and then exits. Who will dispose this complex, dynamic document from the memory? This is the CORE question! If there is a no GC, no RC, no manual management solution to this, then I AM REALLY INTERESTED to know about it...

<comment><USER9> Yes, which is why I asked. He seems to be saying it will have the ease of GC with the performance of fully manual memory management with none of the costs of either. I don't see how radically simplifying Rust's approach can do that, but I don't have to. If he can find a partial solution that is significantly better, that will be great. I don't know if he'll succeed, but I'm rooting for him.

</comment></comment></comment></comment><comment><USER11> Making a programming language specifically for the needs of one program, then developing that language and the program together, is an underestimated strategy. I believe the world would be more interesting if more people applied it—because then we'd get more qualitatively different new systems. The Sapir- Whorf hypothesis may not be something people currently believe about natural language but for sure it's true about programming: the language you program in conditions what you think, which conditions what program you write. When the two evolve together, evolution can go to new places.

This strategy is time-honored in the Lisp world, where making a language and writing a program are more intertwined, and the cost of making a language much lower, than they usually are.

<comment><USER12> The downside to this is that unless your language gets widespread adoption, you can corner your community into a bubble and drastically increase the barrier to contribution.

I think one of the issues of Gnome Project is this, they use a language specifically designed for Gnome/GTK+ and as if that was not enough, it has two different syntax, one--Vala which is sort-of-kind-of C#-like and the other being Genie which is sort of kind of python-like.

<comment> loup-vaillant > _unless your language gets widespread adoption, you can corner your > community into a bubble and drastically increase the barrier to > contribution._

Only if your language (and standard library) is of comparable complexity to that of widespread languages. C has more quirks than it lets on, C++ is a monstrously complex beast, Java has an _enormous_ standard library…

If however you keep the syntax and semantics of your language simple, they can be learned in a matter of minutes. If you keep the "standard" library focused towards your application, it won't require more effort than any other regular application.

The real problem with custom languages, I think, is that very few programmers can actually write one. Most others don't even see the need, I think in part because of motivated cognition (If I delude myself into thinking I don't need something, I don't have to face the fact that I can't do it). Though the main problem is probably education: we are taught that languages are _chosen_ , not made. As for how they are made… well, that's the realm of geniuses who have way too much time to spare.

Every programmer should have an introduction to programming languages, and we need more specialists who can whip up a DSL in a couple days. Our craft would be very different (and I think much better) if we did that.

<comment><USER13> Elixir allows you to build powerful DSLs within the language using macros and optional syntax. Also, if you write CSS well you end up with a DSL describing your screens. What other languages give you this power?

<comment><USER14> Terra [1]. I used it to create Regent [2] specifically because it takes this approach.

[1]: [http://terralang.org/](http://terralang.org/)

[2]: [http://regent-lang.org/](http://regent-lang.org/)

<comment><USER15> You're affiliated with Stanford? If so, also with the developer of Terra?

</comment></comment></comment></comment></comment></comment><comment><USER16> Awesome, I love to see new programming languages in action. This is great. Some thoughts.

First, ignore negativity and focus on getting constructive feedback. One of my tiny regrets is that I abandoned one of my projects due partially to negative energy. Many years ago, one of my projects was shared here ( [https://news.ycombinator.com/item?id=226480](https://news.ycombinator.com/item?id=226480) ), and the feedback was kind of a buzzkill (especially since I wasn't the one sharing it).

Second, think about the growth you want. While I could ignore the buzzkill and keep the faith, I used my language to put a real product out into the world. The crazy thing is that I got it working and working very well, but when it came to hire. It was a cluster fuck. I should have spent a bunch more time on documentation and examples, but I had other concerns that were higher priority. I ultimately had to abandon the whole thing, and I just rewrote everything in C# and used Mono. It was painful, but the company was able to grow faster since the tools were somewhat standard and a plethora examples for the new hires.

When I look back, I was onto something. If I had kept the faith and pushed through, then I would have created something very similar to HHVM which Facebook uses. My strategy back then was to create a less awful language, improve it, then port the platform bits to a better ecosystem and preserve the "business logic".

My core advice with the programming language side of the house is to find a partner for you to lead/follow with shared values. Make it open source as soon as possible, don't wait.

</comment><comment><AUTHOR> Found this from the Slack thread: [https://news.ycombinator.com/item?id=19081896](https://news.ycombinator.com/item?id=19081896)

Is this language going to be open-source? It seems incredibly impressive, and 100% overlapping with what I'm trying to do with Zig.

<comment><USER17> To Andy:

I thought it was a new name for Zig seeing your name and the description in the link. ;) It actually looks about too good to be true, especially that it can handle any C++ to V conversion. I was pushing people to check out languages like ZL exactly to rid us of C++ without throwing away legacy code. If it can do that and fast compiles, I can't wait to read the full write-up later on.

Btw, I encourage you to keep at Zig for diversity in systems, language space. Plus, macros. I tell people to avoid them by default for more maintainable code. However, there's times where it's better to have them than not have them. I was happy to see D, Rust, and Julia do macros. Zig and V should have them, too, for max productivity.

To amedvednikov:

1\. The name. Although Kesterel had a V language, that was long time ago. You're not stepping on anything. I just encourage you to do one people can spell and pronounce easily that isn't already taken. That will make both search results and adoption a little better.

2\. Macros. Like I said above. I saw you mention Go which intentionally tries to keep a standardized language for maintainability and easy compilation. I get that. You could add a warning to the main page that macros are available but discouraged for most situations for those reasons. "Use them only when the cost is worth it." Can just do two passes: one for macros, one for regular code. Your incremental compilation should knock out most of what little slowdown there is.

<comment><USER2> I'm against macros. I've done a lot of research on this topic.

One of the main goals is simplicity and maintainability. I want people to be able to jump into any code base (including stdlib and compiler) and understand what's going on. Macros don't help with that.

I went through like 10 names and ALL of them were taken. There are a lot of programming languages out there :)

<comment><USER18> I don't know of any language with macros that have proper IDEs that do more than syntax highlighting. One of the reasons languages like Dart, Java or C# have such amazing IDE capabilities w.r.t. refactoring is that they don't generate half of their code during runtime...

</comment></comment></comment></comment><comment><USER19> Wow, I like the selling points:

* Strong modular system and built in testing.

* Global state is not allowed.

* There's no null and everything is automatically initialized to empty values. No more null reference crashes.

* Variables are immutable by default and functions are partially pure: function arguments are always immutable, only method's receiver can be changed.

* Thread safety and guaranteed absence of data races. You no longer have to constantly ask yourself: "Is this thread safe?" Everything is! No perfomance costs either. For example, if you are using a hash map in a concurrent function, a thread safe hash map is used automatically. Otherwise a faster single thread hash map is used.

* Strict automatic code formatting. It goes further than gofmt and even has a set of rules for empty lines to ensure truly one coding style.

Especially eye catching is the 2 mode of every data structure. Switch to thread-safe if there are concurrent access.

<comment> duncan-donuts For no null is he saying that everything is just initialized to a default value (int=0, str="", etc)? I'm thrown off by, "everything is initialized to empty values" because I don't see how empty and null are different.

<comment><USER20> The difference is all values are valid. In C, you can't know that a `char *` is safe to dereference.

<comment><USER21> Garbage but valid values are, in my opinion, _much_ harder errors to catch because they can silently corrupt data, than a simple crash/null pointer exception.

I'm not a fan of null (option types seem better -- which V does say it has), but defaulting to an "empty" value isn't the answer IMHO as it makes it much harder to debug by obscuring that there's a problem at all. You may not realise that the 0 is actually an "empty" and not a valid 0 until you realise all of your calculations are wrong, months later.

</comment></comment></comment></comment><comment><USER22> "No variable shadowing" might sound great when you're thinking about that one time someone confused you for three seconds with the addition of a new inner variable with the same name as an outer variable. But once you realize that it equally means forbidding the addition of a new outer variable with the same name as an inner variable (even though those inner variables are supposed to be implementation details)—and, as a corollary, you can _never add new builtins_ to the language without breaking backwards compatibility—you'll realize that most languages allow shadowing for a reason.

<comment><USER23> > you can never add new builtins to the language without breaking backwards > compatibility

Adding any keyword is by definition breaking backwards compatibility, so I'd say this is the correct behavior.

<comment><USER7> I think you're confusing "keyword" with "reserved word". A keyword has a special meaning in certain circumstances, while a reserved word cannot be used as an identifier. In some languages, those are the same thing.

For example, "goto" is a reserved word in Java, while not a keyword. Inversely, in Fortran, keywords are not reserved names, so `if if then then else else` is valid. C# has "keywords" and "contextual keywords", both categories being keywords, but only the former being reserved names.

Regardless, a builtin might be referring to a function that's included as part of the base language - like make() in Golang or zip() in Python.

<comment><USER23> Eh, right. But correcting for that I still hold the same view that adding new builtins should be considered breaking backwards compatibility.

EDIT: Since someone has gone through the trouble of downvoting this viewpoint, I would like an explanation as to why I'm wrong here. I cannot imagine a scenario in which doing so would not likely break existing code.

<comment><USER24> If you allow shadowing then surely the local definition of the name will take precedence over the new name introduced in the stdlib (or wherever), and thus the program will keep behaving how it did before the new builtin was introduced.

I think I must be misreading you, because it sounds like you're arguing for the idea that adding new names to an API should be considered a breaking change? I'll accept that maybe reflection will catch those changes, but with that exception why would any code even notice?

</comment></comment></comment></comment></comment><comment><USER25> Is this a real language, or am I dreaming this?

Those are exactly the ideas I had for what would make a perfect language! (Assuming they're implemented properly of course).

Simple features. Immutable and pure by default (but not dogmatically so). Fast compile. Hot reload. Automatic C interop. Fast-ish. Built in niceties like hashmaps, strings, and vectors (niceties compared to bare C). Receivers so you don't have to do the song and dance you do in C to tie structs and functions. No header files!

Go came close, but no cigar. Rust added the whole kitchen sink and loads of accidental complexity. Anxious to see how this fares...

<comment><USER26> You might want to take a peek at the Nim language as well; it has all of the above and is quite mature.

<comment><USER27> Hit reload though?

</comment></comment></comment><comment><USER28> It's interesting that the roadmap of volt has been saying v1.0 is just around the corner for the past half year. The other roadmap items also don't change much.

[https://web.archive.org/web/20180615121501/https://volt.ws/](https://web.archive.org/web/20180615121501/https://volt.ws/)

[https://web.archive.org/web/20181023093131/https://volt.ws/](https://web.archive.org/web/20181023093131/https://volt.ws/)

It would be great if the roadmap contained realistic items. Once a user is burned by an unmet expectation he won't believe anything else on the website.

<comment><USER2> Yes, I've done a terrible job with estimations and for 9 months I lived in "release tomorrow" mode.

I made lots of mistakes that caused the delay, I'll post a detailed blog about it.

Should have sticked to "it's ready when it's ready".

Ironically this time it it really is going to be released tomorrow (Feb 7).

<comment><USER29> please don't take this the wrong way but I'm almost more excited to read blog posts about your process and what you've learned than I am for the eventual product, or language used to create the product (though I am excited for both of those!). reading experiences people had trying crazy new stuff is more interesting than results of trying crazy new stuff imo

</comment></comment></comment><comment><USER30> I think doing away with global variables is not a very good idea. While using globals is usually a bad idea, there are many instances where globals are appropriate (at least for languages supporting mutability). People who say they never use globals usually do use globals and are just trying to convince themselves they are not because they heard they were bad from somebody.

The entire Spring framework is IMO an elaborate construction built so that engineers could use global variables without their managers finding out. There is little to no difference between carefully using global variables and Spring dependency injection except syntax.

The best solution I have ever seen to global variables is definitely parameterize with Racket ([https://docs.racket- lang.org/guide/parameterize.html](https://docs.racket- lang.org/guide/parameterize.html)). I don't think Racket was the first language to come up with this, but it was the first one I am aware of. The basic idea is that you define some global with a default value. However, you can call parameterize to change the value for the duration of some input function. It is made thread safe by using thread local memory. It then resets the parameter back to the default value at the end of the function.

On the other end of the spectrum, I think Rust also has a very good implementation of globals. It will let you use global variables, but you have to declare it as mutable, use some form of locking, or use an UnsafeCell. Additionally, you have to mark your code as unsafe any time you try to read or change this global variable.

<comment><USER31> > _The best solution I have ever seen to global variables is definitely > parameterize with Racket ([https://docs.racket- > lang.org/guide/parameterize.html](https://docs.racket- > lang.org/guide/parameterize.html)). I don't think Racket was the first > language to come up with this, but it was the first one I am aware of. The > basic idea is that you define some global with a default value. However, you > can call parameterize to change the value for the duration of some input > function._

Isn't that basically Perl's `local`?

<comment><USER32> It is, but Lisp did have it first, even if not through Racket.

<comment><USER14> Yes, it's called dynamic scoping, and for a long time it wasn't believed that the other option (what we call lexical scoping today) could even be implemented efficiently.

[https://en.wikipedia.org/wiki/Scope_(computer_science)#Dynam...](https://en.wikipedia.org/wiki/Scope_\(computer_science\)#Dynamic_scoping)

</comment></comment></comment></comment><comment><USER33> I like to know that there are still developers for whom the size of an application is an important issue.

<comment><USER34> The SS-ci5er is here to take the call.

This is "the deal"...

There are many computer environments beyond the desktop and cloud servers. Arguably most computer environments.

But to reduce it: imagine an O&G pipeline controller that stupidly did something bigger than QNX & C. That will be pumping oil and gas for 30 years. Online upgrades, until some young turk blows out the library size. Oil spill with a blown line, and New Jersey explodes.

<comment><USER20> Those systems aren't running desktop applications though.

</comment></comment></comment><comment><USER35> 100+ MB down to 5 MB is such a nice win, it's amazing that the author even bothered to continue from 5 MB down to 100 KB. Very impressive!

</comment><comment><USER36> Sounds too good to be true. If this is released it'll be serious competition to Rust, Nim, Zig, etc. Lets hope for the best. There's just so many amazing features. There's even a graphics library in it.

<comment><USER2> I'm very excited about it. I've been working on this and Volt full time for a year.

<comment><USER36> Very good to know! Keep going strong !

</comment></comment></comment><comment><USER37> To the problem you were originally trying to solve, why not just use Rust? Go and C are really about as related as Java and C. Rust would have met all your requirements, and has a lot of features you added to V to begin with.

<comment><USER2> Slow compilation. Complexity.

<comment><USER37> That's strange, I find Rust to be much less complex than working with C++ or C. It keeps track of all the tough bits for me, and it has all of the nice expressive stuff from Haskell. With Go I kept running into cases where the language simply had no feature to save me from multiplicative complexity in my code base.

I haven't had any problems with build times thus far, how big is your project?

<comment><USER2> It's not big. But I'm developing V so that everyone can create large applications with very fast compilation times. I'm getting x120 improvement for DOOM 3, and I think it can be up to 400 times faster for more complex C++ projects using more templates, boost, etc.

Of course I didn't need a new language to make my project compile faster :) I just wanted a simpler C, and I had some experience with writing languages (I wrote 2 languages at school/uni).

Now I'm actually more excited about V than the original product I created it for :)

<comment><USER38> This is the part that astonishes me the most. How can you compile so fast?

<comment><USER39> He is a russian- these guys are crazy when it comes to performance lol.

</comment></comment></comment></comment></comment></comment><comment><USER40> I had been looking for this exact project, but I couldn't remember its name for the longest time. But I remember that home page exactly. Doing a bit of seraching it turns out volt.ws appears to be a rebranding of a previously posted [1] Eul (eul.im), posted by alex-e (whom I assume is its author). Either way, volt.ws and the associated V language sound quite interesting, I look forward to hearing more about this in the future.

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

</comment><comment><USER41> As an (anonymous) programming language designer, a few bits of feedback.

First, nice concept, but without open code, it might as well not exist, and without open specification, it might as well be yours alone, like one of Tolkien's languages. Closed languages wither and die, and yours seems well onto that path.

Second, what makes V compelling to you appears to be completely uninteresting to me in terms of language design. It might as well compile from V to Go; I can't see why not!

Whenever a language designer appeals to simplicity, they are usually appealing to whatever makes it possible for them to be productive, and they are usually missing that the productivity is personal because the designer is the one who builds the language. The GL demo seems to be a great example of this sort of situation.

I hope that you publish your work so that we may properly critique it.

Edit: Here is another language designer who is not me saying "closed languages die" ([https://blog.golang.org/open-source](https://blog.golang.org/open- source)). I think that, until we actually have a compiler for V (or whatever it is hopefully renamed to before release) in our hands, we ought to be extremely careful about trusting that any of this exists. It is all too common in PLT/PLD for somebody to come in with bold claims, outrageous mockups, and zero toolchain. I addressed what I saw, which is yet another compiles-to-Go hobby language. To become more than that requires a committed community and a common repository of open code, and the author appears to have only the former.

<comment><USER42> > Closed languages wither and die, and yours seems well onto that path.

This is unnecessary harsh. The author has already said it will be open sourced later. I can understand the reasons to not open source now. Managing an open source project is no small work.

Second, notwithstanding V's slim feature set, it's already more successful than 99% of language design attempts out there in that it ships. It certainly succeeds in letting the author to build his other projects faster and easier. It fulfills the author's own needs. I'm sure Perl and Python started that way.

<comment><USER43> look at the authors comments in this thread, he's been known to miss deadlines before. open sourcing is probably gonna be really really delayed

<comment><USER42> This is his personal project. He really does not owe anyone anything, deadline or no deadline. Open source "users" have been getting really entitled these days.

</comment></comment></comment></comment><comment><USER44> Looks a bit like Odin ([https://odin.handmade.network/](https://odin.handmade.network/)) --a language explicitly designed to be small and simple I've been enjoying learning and toying around with.

</comment><comment><USER45> For me personaly the killer fature is: C/C++ to V translator

Having all my library in the same language make a lot thing like debugging and testing easier. It also semplify the mental model i have of the program.

Also C(lang) interop is my main struggle with go. For me it is such a pain that something i wrap a c library in a stdout/stdin server and just spawn it and use cap'n'proto for communication. When you use cgo you lose the easy cross-compiling, i would love for something similar in go and/or rust.

I wonder if llvm could be used to implement a sort of universal transpiler. even if it not use the target language in a semantic language it still make a lot of thing easier.

<comment><USER2> > For me personaly the killer fature is: C/C++ to V translator

Yes, I'm super excited about it!

</comment></comment><comment><USER46> I tried the app on the mac and it's very buggy.

I couldn't save settings, and from then it kept on crashing after restarting the app.

<comment><USER47> I was considering downloading it, but I think I won't now that I read your answer. Do you know of any good competitor ?

</comment></comment><comment><USER48> > Originally Volt app was written in Go, but after a couple of weeks of > development I decided to re-write it in C for two reasons: easier > integration with existing C graphics and UI libraries and much smaller > binaries. The app size reduced from ~5 MB to ~100 KB.

I'm always curious when people complain about binary sizes. Was there some reason the binary needed to be small? Or just based on some sense of 'largeness' and 'smallness'. It seems to me like rewriting in a 'less productive language' to save a few mbs of binary size that nobody cared about anyway is a pretty big waste of time.

I don't mean to come across super critical, there are cases where binary size could be really important. Say you're on an embedded platform with minimal memory. I just don't /understand why it was something worth optimising over here... especially to the point of a rewrite

<comment><USER49> This is the same attitude that has gotten us 20MB+ web page sizes.

<comment><USER48> I'm not talking about a web page, I'm talking about a binary you're running locally. Your criticism doesn't apply.

</comment></comment></comment><comment><USER50> So Volt seems interesting, but how to I download it?

All of the download links just give todays date and issues in the GitHub page the site links to mention it being flagged by virus or not being supported.

[https://github.com/voltapp/volt/issues](https://github.com/voltapp/volt/issues)

<comment><USER2> I've just released a macOS beta. Windows and Linux will be released later today.

</comment></comment><comment><USER23> I'm not sure I get what is going on in the live reloading code.. if you update the draw function to change colors, then why does the block only change colors when it hits the edge of a screen?

[0] [https://volt.ws/img/lang.webm](https://volt.ws/img/lang.webm)

<comment><USER2> Good catch!

It should be instant. But when I was making this gif, there was some kind of a bug, and I some how made it work only after it reaches the edge.

I was not able to reproduce this :)

I'll make a better gif once the new website is up.

</comment></comment><comment><USER51> Volt looks amazing. I've been looking for a native IM app for a while, and I couldn't find one. I hate all those electron or browser apps taking hundred of MB of ram just to display messages.

I hope it succeeds and is released soon! Thank you very much for your work.

</comment><comment><USER52> > You can also simply translate your entire C/C++ codebase to V and make your > build times up to 400 times faster. An automatic translator supports the > latest standards of these languages.

Is this saying you can actually get compile time improvements compared to the original codebase? If so I can imagine a couple of ways this could work-

1) skipping the optimization the C/C++ compilers would do, with V's direct-to- machine-code generator, and/or

2) doing some heavy lifting in the translator, so the equivalent V has more redundancy and less implicit information.

How close am I? Or is there something else here?

</comment><comment><USER53> > Modern garbage collectors are very powerful and optimized. However for the > best performance and latency it's better to use a language without a GC.

This is quite a controversial statement. But it could indeed be true, see this article: [1]

[1] [https://softwareengineering.stackexchange.com/questions/2037...](https://softwareengineering.stackexchange.com/questions/203745/demonstration- of-garbage-collection-being-faster-than-manual-memory-management)

</comment><comment><USER54> As a someone who has never design the language or implemented a compiler, this seems to be on very very daunting task. Just wondering how much effort it requires and if someone like me - who has experience in developing software using high-level languages but not compilers - can implement it. It seems to be very interesting project and I would love to try something like this just for the sake of learning. I would really appreciate if someone can give me the pointers about where to begin with.

<comment><USER55> [http://craftinginterpreters.com/](http://craftinginterpreters.com/)

It's an excellent book and is incredibly approachable.

</comment></comment><comment><USER56> I'm interested to know how the language handles memory; automatic memory reclamation without a GC and that is simpler than Rust seems like a very attractive proposition.

</comment><comment><USER57> This is a helpful approach for embedded platforms: Write in a nice language (V), spit out C code that the usually-old embedded toolchain can compile.

<comment><USER2> And you can also do C++ => V => C :)

<comment><USER58> Do you have anything to say about C++ => V translation?

From what I know C++ is an extremely complex language. How do you deal with the complexity? (Especially considering V is meant to be simple)

<comment><USER2> It is ridiculously complex. Right now the size of the C++ translator is 10 times bigger than C and it'll get even bigger.

I'll post a detailed article about it soon.

</comment></comment></comment></comment><comment><USER59> Re the website: are the fonts quite unreadable just for me? [https://screenshotscdn.firefoxusercontent.com/images/761f208...](https://screenshotscdn.firefoxusercontent.com/images/761f2089-8374-449d-827e-1a0d2be8e079.png)

(BTW, the language itself is exciting!)

<comment><USER2> Yea, it's using Google fonts, I'd better switch to something more standard.

</comment></comment><comment><USER60> I see Go-ish syntax in some of the examples but I also see underscore_case being used (instead of camelCase)

Does V encourage one or the other? (coming from a C background, I prefer underscore_case)

Does V have Go's funny "uppercase export" rule? Only identifiers that start with an uppercase letter are exported from a module?

<comment><USER2> V is very strict. There's only one style. Using anything other than the underscore case is a compilation error.

It doesn't have the uppercase export rule.

It's going to be either Rust's `pub` or Oberon's `*` or `+`, haven't decided yet.

</comment></comment><comment><USER61> How does the live reloading work when you are compiling to C or machine code and claim to not have a runtime?

</comment><comment><USER62> I'm a big fan of what they are doing, but this is really light on details. Please show us more!

<comment><USER2> You can follow the project here:

[https://github.com/vlang-io/V](https://github.com/vlang-io/V)

[https://vlang.io](https://vlang.io)

</comment></comment><comment><USER63> > You can also simply translate your entire C/C++ codebase to V and make your > build times up to 400 times faster. An automatic translator supports the > latest standards of these languages.

How do you plan to translate the latest C++ standard with all those template stuff?

</comment><comment><USER30> I would be cautious about making a language with only reference counting since you can easily end up with stack overflows when implementing something as innocent as a linked list unless you keep some sort of list of objects to free in the runtime.

</comment><comment><USER64> Finally, a simple alternative to C++! I've been dreaming about creating this for years, thank you for doing it!

Few ideas I had:

\- Simple classes (no inheritance, only mixins) like in JavaScript

\- Always pass objects by reference as in Java to avoid the pointer mess

\- Copy the core APIs from ECMAScript

</comment><comment><USER65> The programming language C was invented to write Unix. So sometimes creating a language to write software works. The defence industry (in the US) is (apparently) notorious for doing this. Any other examples?

</comment><comment><USER66> This is the most exciting software announcement I have seen in a while. I can't stand using Facebook Messenger in Firefox.

I'd love to see how V generates its machine code. Using the Go syntax is a wonderful idea.

</comment><comment><USER67> Would it be possible to compile V to Java or JVM byte code, but by not using giant array in the middle? I'm mainly wondering if one could use GTK+ in Linux and Android APIs without JNI on Android.

</comment><comment><USER68> Apparently now there are two programming languages called "V", the other being: [https://www.vcode.org/](https://www.vcode.org/)

<comment><USER36> Yeah, i guess V is just a temporary name. Other nice names : Jolt, Quark, Ether, L, Lum etc;

</comment></comment><comment><USER69> Off topic, but will there be a dark mode for Volt? I can't abide by Slack's lack of official one and the constant overwriting of the file that maintains the hack for the unofficial one.

<comment><USER2> Yes, there will be.

</comment></comment><comment><USER70> Hey! I just wanted to see keep it up and that this looks really cool

<comment><USER2> Thanks!

</comment></comment><comment><USER71> Volt looks like a cool app, I'll be trying it out this week.

</comment><comment><USER72> Very very interesting. But I hope it's renamed to something other than a single-letter name, so we can use search engines to find info about the language later.

<comment><USER73> Usually you can find information about a new language pretty easily by adding "Lang", e.g. "go lang" etc

</comment></comment><comment><USER38> > You can also simply translate your entire C/C++ codebase to V and make your > build times up to 400 times faster.

What are traditional compiler makers missing?

</comment><comment><USER74> I really would love an alternative to the horrible Skype client but I doubt it. AFAIK, you can't make your own unless things have changed ?

<comment><USER2> Check it out tomorrow :)

<comment><USER74> I will for sure. Their latest client is just too hostile.

<comment><USER74> the Mac client is available but Skype support is tomorrow :/

</comment></comment></comment></comment><comment><USER75> Looks like this language has something in common with single-assignment C. Can anyone offer comparison/ontrast with that?

</comment><comment><USER76> Fantastic stuff. Waiting for a release though before getting too excited. Sounds too much for a single person to do.

</comment><comment><USER77> How does this prevent data races? Does it suffer performance, or require Rust- like annotations about lifetimes?

</comment><comment><USER78> Looks really good. Any ressources on how you wrote the x86_64 backend ? Or Thema Compiler per se?

<comment><USER2> [http://ref.x86asm.net/coder64.html](http://ref.x86asm.net/coder64.html) mostly

</comment></comment><comment><USER79> I'm excited about this.. Feature list seems almost too good to be true. :)

</comment><comment><USER80> > Full source code is available here.

Link refers to the same page.

</comment><comment><USER81> Is Volt WebKit or not? I can't tell...

<comment><USER82> Cramming WebKit into 100 kB seems technically impossible, unless those 100 kB contain "git clone ; ./configure; make -j32 / _wait three hours_ /".

<comment><USER81> I totally agree. So what does "Slack support" mean? Is he... implementing the Slack API? and Skype? and Gmail? and Discord? and Facebook Messenger?

Edit: I see now. It's just a chat app with a bunch of protocols and a clean interface.

</comment></comment></comment><comment><USER83> It's not garbage collected, right?

<comment><USER84> Correct. There's some more details in this (unfinished) article: [https://volt.ws/game](https://volt.ws/game)</comment></comment>


Ask YC: For a startup hiring its first employee, what are pros/cons of local vs remote? - <AUTHOR>

(37Signals says remote works well, others say hire local)
There is a good related thread here, but not exactly the same question:
http://stackoverflow.com/questions/246795/hiring-your-first-employee <comment><USER2> If the employee is going to be a 'peer' then remotely will work fine as they will most likely be responsible and highly motivated to do a good job. If they are just a cog in your machine and productivity is key (thinking not so much), you can't beat local yokels.

Also with developers, there's a huge difference between being able to look someone in the eye after they just horked your entire product/service and trying to do the same over the phone/via email. Remote developers simply don't care, because they don't usually _have_ to care.

<comment><AUTHOR> In this case we would likely be thinking of the person as a mini founder, with a significant amount of equity. So hopefully the ownership of their work would help with the self motivation.

</comment></comment><comment><USER3> You might do well to find someone who is active in OSS communities, ideally, someone who has contributed code. This allows you to see the quality of their work and communication skills, and (in my opinion) it gives some indication of their willingness to work remotely and still "get things done".

I work for Mozilla, and I am a full time remote employee. When I was hired, I came in to the office to work for two weeks, and now, I typically visit the office at least once a quarter for at least a week. For a startup on a tight budget, that much travel might be difficult to handle.

I would also encourage you to find a place to live in IRC (either host your own private server or set up a channel on freenode or something). IRC brings a sense of closeness to local and remote resources. If people stay in the channel and use it, there is also a good opportunity for "water cooler chat". When I work in an office, I listen to people casually talking around me. If they are talking about something interesting or something I might have some useful comments about, I speak up. If people in your team live in IRC, then they will use that medium as a place to ask those little one off questions that normally happen either in the hallway, snack-room, or via IM. If it happens in IRC, you can easily capture that knowledge for future use, and other people can see the conversation and might have something useful to say about it.

I also encourage the use of an IRC "backchannel" if you have meetings that include remote resources. If you want to see an example of a meeting like that, tune in to <http://air.mozilla.com> and irc://irc.mozilla.org #staffmeeting on Mondays at 1PM PST.

</comment><comment><USER4> I strongly disagee with josefresco. I have a 5 year old "startup" with 6 full time remote workers -- 3 developers. It works great.

If an employee isn't caring about his work, it doesn't matter if he is local or remote. Hiring smart, passionate people is the most important factor.

</comment><comment><USER5> Do you already have someone in mind or are you planning on going through the interview process?

<comment><AUTHOR> Interview process

<comment><USER5> I personally have no problem hiring someone to work remotely. In my case; most everyone I've hired to work remotely - I've worked with in the past - so I knew they'd get the work done effectively. If I hired someone I didn't know and they wanted to work remotely I'd bring them in house for a period of time during a probation period - then I'd let them work from anywhere they wanted too.

<comment><AUTHOR> Yeah if we hired remotely we think we would have a two week or so on site period. We would also probably hire as a 3 month trial period that allows for reevaluation at the end of the 3 months.

</comment></comment></comment></comment><comment><USER6> i gotta go with local. I just don't have a good experience with people working remotely. Both cases suffered huuuge delays. There are way too many distractions for them, and the work suffers. At least if they are doing it full time at your office, you are pretty much guaranteed that they'll be working on your project all of that time.</comment>


Announcing TripleSec - JavaScript encryption combining Salsa20, AES, and 2fish - <AUTHOR> https://keybase.io/triplesec <comment><USER2> It's all very cool but "magic bytes"? When I encrypt data the last thing i want is for its format to be easily recognizable.

<comment><USER3> That's a good point. You can feel free to strip them off. After byte 8, the rest of the outputs will appear almost entirely random. It depends on your usage. I'm imagining a database table on a server with a column of TripleSec- encrypted values. In that case, the adversary knows what he/she is getting by looking at the DB schema or reading the code.

</comment></comment><comment><USER3> Hi, Max here. I'm happy to answer questions about TripleSec, so let me know.

<comment><USER4> Hi, Max. CTR doesn't have an IV. It has a nonce. IVs need to be unpredictable; nonces only need to not repeat.

<comment><USER5> Actually, you rarely want a predictable nonce as well. The difference is that a nonce must not repeat (or repetition is statistically irrelevant).

Even per wikipedia, many often refer to an IV as a nonce: [http://en.wikipedia.org/wiki/Cryptographic_nonce](http://en.wikipedia.org/wiki/Cryptographic_nonce)

<comment><USER6> What problem does a predictable nonce cause?

</comment></comment></comment></comment><comment><USER7> I'm a security noob and I've been thinking about writing an encrypted chat application with Node.js and Socket.io. I have the chat part already done, but not exactly sure where to proceed with the encryption part. I don't want to store data and I want the data that is being received and sent to be encrypted. I was thinking of having users enter a room together with the same key to use for decryption. This could potentially be something I use and I was also considering using SJCL. Am I totally way off in my approach to this...? Suggestions?

<comment><USER8> TripleSec seems to be only about the same person who did the encrypting, doing the decrypting -- for securing your _own_ stuff, not really for communication. Communication requires exchanging keys beforehand...

[Edit: meant encrypting not encoding... thanks Perseids]

<comment><USER9> I may be a bit pedantic, but please don't use "encode" when you mean "encrypt". These words describe two quite different concepts and guarantees. Exchanging them the other way around produces catastrophic results like "Of course we encrypt our passwords, we use the renowned base64".</comment></comment></comment>


How we tripled our revenue by adding one button - <AUTHOR> https://medium.com/what-i-learned-building/a8e04b2d85fe <comment><USER2> Good deal, I think I'll buy this.

When it comes to buying games or apps me or our kids the "Unlock All" option is more than just a nice to have, it's a necessity. For me personally it doesn't have to do with convenience or perceived value: Rather it's because I feel that I am not buying into a scam.

If I see item (X) on the market for "Free" \+ in-app purchases I'm flat out not going to spend any time on it. You offer the same (X) for $5-$20 with everything unlocked and no gimmicky BS sales tactics then I'll pick it up without hesitation.

There are too many applications out there designed to be time and money sinks. The focus tends to be on giving the user just enough and then stalling until they spend more money. It's a dirty, scummy industry.

If you're selling a product (game, book, series, otherwise) and feel it can stand on its own merits then offer a fair price for the complete item with no strings and I'll most likely purchase it.

<comment><USER3> Yup. Especially if you're handing the app off to somebody who's just learning to read - even if the tablet is locked-down, the kid will be frustrated and need help if they get trapped in the "unlock" content while they were tapping around randomly and exploring the app.

I'm disappointed so few app developers don't offer a "I just want to pay for this so you can stop marketing at me" option. Free/Freemium/pay-up-front are not mutually exclusive revenue streams for an app, release with multiple revenue strategies.

<comment><USER4> We actually released a version of the app that was $2.99 upfront with no in- app purchases to test which model worked better for us.

The $2.99 version netted us less than $20 in the lifetime of the application. It never was ranked anywhere in the app store and thus was virtually DOA.

I agree it would be great to charge upfront - We didn't have a budget to market these applications to them to show them the value before they reach the store which would be essential in that business model. The freemium model was our only way to leverage the rankings in the store and give parents the ability to see the value in the application before buying.

<comment><USER3> That's surprising to me, as a user. On Android I often search for apps, find the "free" one, read all the reviews and (if it has positive reviews) I seek out the "pro" version and buy that without ever having installed the "free" version. That is, I know the "free" version will have the top placement and the good user-feedback info so that's the one I can quickly get info about, but I skip the middle-step of installing the "free" one and move straight to the pay-up-front thing.

I guess my workflow is unusual.

<comment><USER5> It's really because of Apple and their rules. Apple discourages Free and Pro versions of the same app (they may have loosened that up recently, but at one time, in an effort to combat app clutter and promote IAP, they would reject you). On iOS, there is no real way to try-and-buy without Freemium. At least in Android, and I think WP, you can get a refund within a certain time frame. Couple this with users generally seeking out free or super cheap apps and treating them as fairly disposable, just having a premium app for an upfront price, not being an established known brand, is basically a death wish.

<comment><USER3> Ah. Yes, WP actually has built-in support for offering both a "try" and "buy" version of each app, allowing two apps to coexist as the same entry... but in practice, most follow the "free" and "pro" naming-convention and offer two separate apps.

I hadn't realized that Apple's strict curating prevented these patterns.

<comment><USER6> You also can't return an app in iOS. If there is something grossly wrong you might be able to talk support into it, but in general that $5 purchase is final. I've heard that as a popular reason for the IAP model after people stopped buying apps after buying real duds for real money.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Over and over again I see the pattern that if you reduce friction to let people pay you, you will make more money. Also, discount bundling is smart and works all over the place. Smart combination.

<comment><USER8> Very true, especially for parents. If I find an author that I like and trust and my kids will read, I'll buy everything they write before going through trial and error again.

Now we just need to see Bilingual Child in other languages and I'll be a buyer!

<comment><USER4> What languages are you looking for? We have a Mandarin version and we're working on a French and Portuguese version.

<comment><USER8> The latter two.

My observation of NY is that parents here don't have cars, so our conspicuous consumption is how many languages we force our kids to learn.

I'm sold!

<comment><USER4> haha! I love it.

</comment></comment></comment></comment></comment><comment><USER9> Didn't see this comment:

We have an 18mo and a 4yo we read books and play games with on the iPad. The 4yo gets to play games or read books on his own as well.

Any app that doesn't let us unlock everything to remove IAP or Ads gets uninstalled.

For one I don't want my 4yo racking up $$$. But it's also frustrating for both of us when he clicks a button and gets taken out of his app and doesn't know what to do now.

So for us at least it's not that "parents can't resist". It's that $13 or whatever isn't all that much to spend if our kids like it, and we don't want IAP buttons and/or Ads in front of our 4yo. Perceived "value" has almost nothing to do with it.

Apple generally gives a 10% discount for buying a season pass. I'd be fine with that. A greater than 50% discount is surprising.

A better model might be something like FarFaria, where we pay an iTunes subscription fee to unlock everything and get rid of the ads. So recurring revenue ($4/month). You might consider it.

I don't claim we're super typical but I doubt we're all that special in regards to letting our children play with Adware either.

<comment><USER10> You're not that special :-) I do the same thing. And I complain to developers that place buttons like "see our other apps" or similar on the main screen of their app.

There aren't many good apps for kids. If your app is good, I will actively search for other apps done by you — no prompting needed. This is how I purchased a number of Toca Boca apps, for example.

I also think most good apps for kids are priced too low. I'd have no problems paying $15 for an app like "Little Digits". In general, I think $5 is fine for apps which are just fun/games, $10 or more if the app teaches something useful.

I think smartphones and tablets have a lot of untapped potential as educational tools, but I'm worried we'll never get there with $1.99 apps.

<comment><USER9> re: "see our other apps"

You nailed it. Hate that. Thanks for the app tips. :-)

</comment></comment></comment><comment><USER11> Great Article, _HATE_ the title. I think it gives the wrong impression. The title should be:

 _How we tripled our revenue by understanding our users better_

Yes by adding a button you tripled your revenue, but what you really did was understand your customers/users better and identified that you could have them spend more by offering a certain deal (which you then implemented by adding a button).

It (title) gives people the impression that they should be A/B testing button locations/colors/<insert (99.99% of the time) random property/> when what they should really be doing is learning more about their users and how to provide the most value for them which in the end gives you more revenue or profits or candy :)

</comment><comment><USER12> My theory with content apps (I've seen this elsewhere) is that the majority of money comes from a small percentage of users (1-10%).

These users are what typically is referred to as whales. The biggest obstacle to monetizing whales is new content. Also, whales tend to be less price- sensitive. That is, they will buy what content you have at a reasonable price, and that price should be based on what those (paying) users will pay.

I don't really buy the convenience argument. It's unclear whether they released 10 books and users were still only buying 2. That is, they were unable to test whether convenience or the lack of new content was the gating factor. I suspect it was the latter.

<comment><USER4> You're dead on - our "whales" were 3% of our users.

We never released 10 books w/ out the Buy All option so you're assumption is correct - we have no data on this. You could be correct in that it was solely content as a gating factor, had we tested incrementally we would have firmer data in this area.

</comment></comment><comment><USER13> Does anyone know what software he's using to display those charts and graphs? Is that a 3rd party app or a custom in house dashboard? I've been looking for something like that for my SaaS business.

<comment><AUTHOR> The charts are from appfigures.com. I'm not quite sure what they are using to generate them, but I'm sure the developer console in chrome will tell you ;-)

</comment></comment><comment><USER14> "To date — the 'unlock all' has been our highest grossing option." Love this.

And although it sounds so simple (just add a button!) there's really more to the success of it behind the scenes and you did great job highlighting those factors (ie: perceived value - convenience, etc.)

Super motiving post :)

</comment><comment><USER15> Looks like a sound application of the "make it as easy as possible for people to give you money" principle. Well done.

</comment><comment><USER16> I will start by saying that the sentiment of this is simple and true. The value added by the "Unlock All" button in it's simplicity is valid.

But they didn't "just add a button" they also added over 3x the content to give that button value.

If they had kept their original 3 books and added the button I'm guessing they would have seen next to no difference in the bottom line.

My point being that in order for an Unlock/Buy All button to work, you need to have enough content/product/etc to make the button worthwhile. Just adding a button may not be enough.

</comment><comment><USER17> Thanks for sharing.

From a technical standpoint I am wondering about the implementation and scalability of such an approach. Are people sensitive to having to wait to download content for their kid's apps?

This app only has, as far as I can tell, ten items per subject. Download size is about 70 MB, which means all the content for the available subjects is contained in the one download waiting to be enabled. This is OK for a few subjects and a few items per subject. I can see a more substantial offering grow to hundreds of MB if a similar approach is used.

The next approach would be to serve new content off a server when purchased. I really don't have a clue as to whether or not that is seen as a negative when it comes to toddler or young child apps.

<comment><USER4> The content is all contained in the base download so there is no wait for the user.

To serve from our own server there would be a delay - Apple also has a serve that lets you deliver assets from their server, still a delay, but much faster infrastructure than we could afford.

</comment></comment><comment><USER18> Hello. Nice article. I just wanted to point out a small mistake where you forgot to fill in an amount: "our users who would have spent an average of $."

Hope this helps (and that you read this).

<comment><USER4> Thanks! Fixed now

</comment></comment><comment><USER19> "With the release of the next seven books we assumed most users would drop off purchasing around the fifth book resulting in a max purchase of $14.95 for less than 20% of our purchasing clients."

Did they?

I must be reading this wrong but it seems you added new contents AND a unlock all button and that increased the revenue.

Did you have a period where you had the new content but no unlock all button? How were sales at that period?

</comment><comment><USER20> "Raising our prices and adding a convenience option paid off big time for us."

Since reading this, we've changed up how we're going to handle the pricing for HookFeed.

Breaking it up into individual feature upgrades, and easy options/discounts for buying all of the features. Also increased rates.

We won't know until we test it. But it seems like a much more attractive offer. Thanks for sharing!

<comment><USER4> Awesome! Can't wait for Hookfeed to launch btw!

</comment></comment><comment><USER21> Great read, but I don't see how this wouldn't be implemented from the start. It's a lot of clicking, adding up what you're spending and authorizing for in- app purchases. One click and authorization with a discount seems like a necessity.

<comment><USER4> Agreed - I wish we had the foresight at the time to have launched with it. Live and learn.

</comment></comment><comment><USER22> From the profit chart it seems to me that there was a boost in Q2 and then in Q3 things essentially returned to how they were before.

</comment><comment><USER23> Often times, its the smallest changes that generate the most success.

<comment><USER4> It's so true. Tinker. Tinker. Tinker. Boom!

</comment></comment><comment><USER24> Is there a video of the app for us non-iDevice users?

</comment><comment><USER25> Nice share! I think all our apps need that button.</comment>


Speaking as a Performing Art - <AUTHOR> http://blog.guykawasaki.com/2007/06/speaking_as_a_p.html <comment><USER2> Say what you will about Guy, he's a hell of a speaker. His "Art of the Start" video should be required viewing for everyone everywhere with even a passing interest in startups or public speaking. It's very compelling stuff.

<comment><USER3> I picked up his book, Art of the Start, a few weeks ago and was somewhat disappointed. I love Guy, except that Garage invested in Gator/Claira, and read his blog and watch his speeches. After that there really was nothing new in the book.</comment></comment>


Learn SQL, dammit - <AUTHOR> http://gun.io/blog/learn-sql/

<comment><USER2> WTF an experienced and "good" developer doesn't know how to do a select from a table!!

Forget get fizbuz maybe getting people to do a simple join of two tables might be a better weeding out exercise.</comment>


Why underdogs should take more chances - <AUTHOR> http://www.37signals.com/svn/posts/1735-why-underdogs-should-take-more-chances <comment><USER2> Football is not a sport that lends to risky behavior. One or two interceptions could lose a game where you otherwise dominate, and turn a loss into an embarrassment. The laboratory for "let's do something crazy and see if it works" in football is college ball, though you are seeing pro ball get more adventurous in recent years.

Basketball lends itself well to "systems" that work well statistically over the long run: you get dozens of possessions, and the other team gets the same number, so you just maximize your average-case possession outcome (offensively and defensively) and the variance will wash out in a seven game playoff series, or a 90 game season. (Which is why boring teams like the Spurs succeed).

But soccer? In soccer, 95% of what you do has _no impact at all_. Even if it is theatrical, the average case outcome for a soccer play is that a goal isn't scored at all. So you can play systematically, except like football, a fluke play in soccer can win or lose the game. But unlike football (where interceptions are usually more the passing team's fault than the defending team's credit), soccer allows you to create fluke plays. You can spend most of the game doing almost nothing of interest, pull off a fluke play (at the very end, if you have a flair for the dramatic), and beat a team that had a slight advantage the whole game but never capitalized. Turkey repeatedly did this in Euro 2008 and it was the most fun I've ever had watching any team play any sport ever.

If you're an underdog, and you're going to take a risk, best check which game you're playing, and whether you're good enough for that risk to pay off.

<comment><USER3> > The laboratory for "let's do something crazy and see if it works" in > football is college ball, though you are seeing pro ball get more > adventurous in recent years.

The forward pass itself was actually an innovation that was introduced by UNC Chapel Hill into American football over 100 years ago. Before the forward pass, college teams simply brute-forced the ball forward.

"John Heisman, a noted historian, wrote 30 years later that, indeed, the Tar Heels had given birth to the forward pass against the Bulldogs (UGA). It was conceived to break a scoreless deadlock and give UNC a 6-0 win. The Carolinians were in a punting situation and a Georgia rush seemed destined to block the ball. The punter, with an impromptu dash to his right, tossed the ball and it was caught by George Stephens, who ran 70 yards for a touchdown.

Heisman wrote he was at the game standing near the action on the sidelines. He is emphatic that Pop Warner, who was coaching Georgia, protested to the referee to no avail. And he adds that he personally wrote Walter Camp, the final authority on football, of the possibilities of the 'forward pass' making football a new and more exciting game."

[http://tarheelmania.wordpress.com/2007/09/13/unc-invented- th...](http://tarheelmania.wordpress.com/2007/09/13/unc-invented-the-forward- pass/)

<http://en.wikipedia.org/wiki/Forward_pass>

</comment></comment><comment><USER4> A Malcolm Gladwell quote from the article:

 _The consistent failure of underdogs in professional sports to even try something new suggests, to me, that there is something fundamentally wrong with the incentive structure of the leagues._

This pretty sums up why I generally don't watch professional sports. I love basketball, but the way that it is played in the NBA is so conservative that it's about as interesting as watching paint dry.

I would love to see the pro sports leagues implement financial incentives in order to reward teams that are taking risks. The only organization I know that does this is the UFC (via their "Fight of the Night", "Knockout of the Night" and "Submission of the Night" bonuses), and perhaps not coincidentally, that is the only sport I find interesting enough to watch on a regular basis.

<comment><USER5> What are you referring to when you say the NBA is conservative? Play calling? Refereeing?

<comment><USER4> Mostly the style of offense. Teams are much more content to keep the ball around the outside and shoot threes all night than to a) drive into the paint and make something happen on the inside, or b) score points off of fast breaks.

<comment><USER6> I used to "assume" the same thing, but I have reasoned that nba teams use a lot of perimeter offense because _its hard_ to penetrate the paint. Imagine having Dwight Howard, Andrew Bynum, Pao Gasol, or Yao Ming waiting for you ...

Usually guards are responsible for "penetrating and kicking" because they have the knowledge and dexterity to do so. But the average guard is maybe 6'3" 180lbs. Good centers start at 6'11".

I just don't think outsiders appreciate how much effort, skill, and knowledge it takes to drive to the basket and

a. take and make a good shot over a 7foot defender.

b. recognize the collapse and pass down low accordingly

c. recognize a double team and swing out to the parameter.

edit*: Maybe you just are not watching the right people. Have you ever seen Allen Iverson play? You'd like him. How about Dwayne Wade or Chris Paul ?

</comment></comment></comment></comment><comment><USER7> "When you're small and risking less, you don't need a business plan. You don't need a board of directors. You don't need to study the techniques of Fortune 500 CEOs. You don't need to know Six Sigma ideas. The strategy that's right for heavyweights has nothing to do with how welterweights should fight."

Sounds like PG ...

</comment><comment><USER8> Yes, but the coach of a mediocre NBA or NFL team has a lot more to lose than just the game. Take big risks and end up losing 15 football games, and your career as a coach might be over. Play the regular style and lose 15 games, and you have a "young team".

</comment><comment><USER9> Actually, there are several excellent counter-examples to OP's sports examples (that further support his point).

Two years ago, the Golden State Warriors implemented a fast paced "run and gun" style offense to offset their liabilities. They made the playoffs (and knocked off top seed Dallas) for the first time in years.

Last year the 1-15 Miami Dolphins brought back the left-for-dead Wildcat formation into the NFL and went from last to first.

The critical missing piece? Heavyweight management that knew what to do. Golden State's Don Nelson and Miami's Bill Parcells were both brought in specifically to "shake things up".

The problem isn't that underdogs don't take more chances.

The problem is that underdogs don't know how to do it.

Being an underdog startup is tough enough. Not knowing how to compete is even tougher.

<comment><USER10> _Last year the 1-15 Miami Dolphins brought back the left-for-dead Wildcat formation into the NFL and went from last to first._

To be accurate, the loss of Tom Brady and the addition of Brett Favre within the division helped Miami get 1st place instead of 3rd. If the Patriots beat Miami by having Tom Brady in just that game, then the seedings would have been Patriots, Jets, Miami, Buffalo. Miami had just enough success to compete with the Brady-less Patriots and interception-king Favre, barely winning the tiebreakers against them.

Also, the loss of Tom Brady in game one of the season likely inspired Miami, and beating the Patriots without Tom Brady, as well. In fact, the wildcat formation was first used against the Patriots, if I am not mistaken. Had the Patriots beaten them, would they have tried it again? Also, Bill Parcells didn't throw those balls; their players were versatile.

 _The problem isn't that underdogs don't take more chances. The problem is that underdogs don't know how to do it. Being an underdog startup is tough enough. Not knowing how to compete is even tougher._

This sounds fancy, but I don't see what you're saying.

</comment></comment><comment><USER11> _When you're small and risking less, you don't need a business plan._

While I agree with the general spirit of the artiicle, this particular advice is just stupid. Maybe you don't need a _written_ plan, but you absolutely need to address all the standard points in a normal business plan.

</comment><comment><USER12> My first guess was that shaking things up would hurt sports betting based on point spreads.</comment>