Designing a Programming Language - <AUTHOR> http://ducklang.org/designing-a-programming-language-i <comment><USER2> "A program written in C can be deployed on virtually any operating system". Let me kill that illusion: While it is possible to write C that can be deployed on virtually any operating system, doing so is quite hard.

Operating systems have different system calls, and even if they are the same family (Linux vs Solaris fe) the semantics can differ. Another thing is that the resolution of the basic primitive types can vary: 'long' is not equally wide on all platforms, heck, even 'char' can be 16 bits on some exotic systems. Anyway, writing portable C is an extra level of complexity. Just write up a little socket server in C and try to get it running on Windows, Linux and Solaris, maybe mix in 32 and 64 bit and see if you still have the same opinion afterwards.

<comment><USER3> Love it or hate it, that's what Autoconf and friends are for. I get to use the same CLI on every computer I have thanks to Autoconf. Also, how many of the compilers and VMs for the languages you love were written in something other than C/C++?

<comment><USER2> most of them end up self-hosting, but plenty of them are initially written in language that's well geared to building compilers. Rust fe was bootstrapped using OCaml to write the first compilers. Smart choice.

<comment><USER4> I believe many lisps do this too. This is where I learned about self-hosting compilers before realising they're pretty much everywhere. I remember looking at the source of a CL impl and thinking "what? It's all in Common Lisp?!"

Despite my ignorance, it's pretty common. C compilers tend to be self-hosting from my understanding. It seems like madness to maintain it all in x86 without some justification.

<comment><USER4> Taking another look at SBCL, even the assembler and its code is written in Lisp:

[https://github.com/sbcl/sbcl/blob/master/src/assembly/x86/ar...](https://github.com/sbcl/sbcl/blob/master/src/assembly/x86/arith.lisp)

Very interesting stuff.

In the same repo, you can also see that the compiler is also written in SBCL.

<comment><USER5> It's written in ANSI Common Lisp, not in an SBCL dialect: you can bootstrap SBCL with an ANSI CL implementation other than SBCL. IIRC, that was one of the key reasons for the original SBCL/CMUCL split.

</comment></comment></comment></comment></comment></comment><comment><USER6> The article starts out with a simple, incremental approach, pretty easy to grasp the concepts all the way through the discussion of the lexer and digesting the program input.

Then all of a sudden the density of the material accelerates dramatically. The discussion of the parser, and parsing as it applies to the language, becomes very opaque to readers not already familiar with the technologies being described.

It's perfectly OK to proceed that way for a sophisticated audience, but the first part of the article is written at a much more introductory level. An unsuspecting beginner may very likely feel overwhelmed about half-way through, and probably give up at that point.

When I got to the explanation of the AST, no surprise, it was exactly representable as an sexpr, which anyone with a few hours experience with Lisp or Scheme would recognize. Not sure, _maybe_ it would have made more sense to begin with the parsed goal (the AST) and work backwards to explicate how parsing of the original syntax was done.

I guess parsing is a really hard subject to teach, but it's the core idea that the reader needs to grasp to be able to understand PL construction as the author laid it out. A still gentler introduction could be possible, if it doesn't sound so easy to do.

<comment><USER7> I noticed this phenomena in my own writing and I think I know where it comes from. In Polya's list of heuristic (from _How to Solve It_ ) he writes about the the two rules of teaching:

> The first rule of teaching is to know what you are supposed to teach. The > second rule of teaching is to know a little more than what you are supposed > to teach.

When we learn something and then write about it to teach others, oftentimes we are excited about the things we just learned, so we write about that, even if we don't fully understand it yet. Then we add an introduction to the "meat" (i.e. the limits of our current understanding) which is very clear, precisely because we are "overqualified" to teach it. Another way to state Poyla's rule for teaching is as follows:

 _Being overqualified in knowledge is a prerequisite for being qualified as a teacher of that knowledge._

One way I like to picture knowledge is as a dark room. You might step into one but that doesn't mean you know every corner of it. For example, imagine a proof or a technique. Unless you can know by heart why each assumption is there, or when the technique fails, you don't fully understand it. If you are guiding someone through a dark house, as you go from room to room, you are only qualified to give someone directions about the room you already been in, not the one you are in right now - even if that's what is on your mind.

Note that this isn't unique to people writing technical blogs, it happens in academia a lot too. There's a reason Feynman's lecture on "undergraduate physics" attracted the attention of graduate students.

<comment><USER8> Your comment resonates very weirdly with my experience.

College teachers are guilty of the exponential wall. Easy and lengthy intro then steep but short core material (often cut short because the bell is ringing). Impossibly annoying.

The dark room exhaustive search is exactly how I ended up learning about learning. Through music though, as a self taught I had to visit every possible spots, even if most of them were holes. And most of the time, most things only 'make sense' because the other things just don't work. Now if you teach a topic to someone by listing what 'make sense', unless that person is very easy on remembering or extremely creative, it will be a meaningless burden to rote learn. On the other hand, knowing all the wrong parts, makes you very good at teaching someone since as the student will ask why his intuition is failing, you know how it feels and you know what to do about it, how to try other ideas, patterns, revisit things that he might have overseen.

Douglas Crockford said that once you understand monads, you suffer the curse of not being able to explain it anymore. I really wonder how often this happen, how many students learned shortened and polished stuff in books without the whole story, the whole experience of the actual researcher ? This tiny offset in understanding, repeated generation after generation .. might lead to large divergence. Saying this after watching (too many?) A. Kay talks about how people ignore the past, they ignore it because it's not taught that is all.

</comment></comment></comment><comment><USER9> Jonathon Blow has a great series [1] on YouTube where he's designing and implementing an alternative to C/C++ specifically aimed at meeting the needs of modern game programmers.

It's an interesting watch.

[1] [https://www.youtube.com/watch?v=TH9VCN6UkyQ&list=PLmV5I2fxai...](https://www.youtube.com/watch?v=TH9VCN6UkyQ&list=PLmV5I2fxaiCKfxMBrNsU1kgKJXD3PkyxO)

<comment><AUTHOR> This is similar to a talk that Tim Sweeney (Epic Games) gave about creating a new language for games, that I thought was interesting. In particular, he talks about the tradeoffs of using C# over C++ for game development, and then talks about ways that ideas from Haskell or purely functional languages can be brought over that might improve performance and productivity for developers.

"The Next Mainstream Programming Language"

([https://www.st.cs.uni- saarland.de/edu/seminare/2005/advanced...](https://www.st.cs.uni- saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf))

<comment><USER10> I remember seeing this long back. Did he (or anyone else) make progress on this?

<comment><AUTHOR> Um, I sort of doubt it. Unreal Engine 4, while I haven't dug around with it, is presumably still C++ and low-level stuff.

The way the game industry is moving is still along the same path. With a lot of amature and professional developers moving towards platforms like Unity, it's sort of a backslide in my opinion. Then again, it's almost as if the target platforms have become too powerful for people to really care what they're developing on.

(My opinion, not trying to be controversial.)

</comment></comment></comment></comment><comment><USER11> Great read - concise yet decently in-depth. Something cool about parsers is how many practical uses there are, and how easy they are to play with.

I decided to learn Go recently, so I first wrote a little parser combinator library (which also returns concrete syntax trees). Then I implemented a little grammar for a shorthand to define parsers, and did the cst -> parser step to make it spit out working parsers. Example here [1] I got it to work for recursively defined context free grammars with some fun [2] deferred function reference trickery.

I haven't decided what to do next, but I've been kicking around the idea of writing a notation to describe cst -> ast conversion. That way one could easily define parsers that generate abstract syntax trees (which can be much easier to perform high level graph manipulations on then the underlying cst.) This, paired with a lexer, could be used for quite a few practical applications, including writing special-purpose languages/compilers.

I'm also interested in investigating the efficiency/time complexity of the library I've made and seeing what can be done to speed things up. I'm fairly sure a few tricks could speed things up significantly. Could be interesting to do some profiling to see how Go is doing with the functional code.

I did this all as a learning exercise/toy project, so I know that there are similar things already out there and that this is a solved problem. I'll might write something about all this once I do something more interesting with it. Eventually I might try to write an optimizing compiler...

[1] [https://github.com/kctess5/Go-lexer- parser/blob/master/main....](https://github.com/kctess5/Go-lexer- parser/blob/master/main.go) [2] [https://github.com/kctess5/Go-lexer- parser/blob/master/parse...](https://github.com/kctess5/Go-lexer- parser/blob/master/parse/shorthand.go#L44)

</comment><comment><USER12> I accept that some people don't know how, or don't want to dedicate the time to making a responsive site. I get that, I have sites that don't make sense in mobile, so we don't bother with a mobile design. But don't take away the ability to zoom on mobile if you don't. You lose a good portion of your audience.

<comment><AUTHOR> Try refreshing the page.

The site is hosted on GitHub pages and I used a template. I found this tag in the HTML

<meta name="viewport" content="width=device-width, initial-scale=1, user- scalable=no">

And changed it to

<meta name="viewport" content="width=device-width, initial-scale=1, user- scalable=yes">

<comment><USER13> The page is not responsive. Hosting on Github pages doesn't mean the web page will be responsive. It depends on the template you have used which is not responsive apparently.

<comment><AUTHOR> Yeah, I'm not a UX guy, I'm a programmer. It's plaintext rendered with HTML. The <meta> tag above prevented scaling on WebKit phones. I don't really believe in using templates or overlays because I'm afraid of them interfering with usability, disabling the ability of a viewer to read the text, or being distracting.

If you are interested in the content I've posted, you would be best off printing it out and reading it. It's probably easier on the eyes.

<comment><USER14> You still have widths expressed in pixels which still limits the chance of your text being readable on some smaller devices. At least I can report that your page is fully readable using Safari on iPhones in the "reader mode" (which avoids all the original formatting of the page).

</comment></comment></comment></comment></comment><comment><USER15> "Additionally, there are certain types of circular references that may never be freed under this scheme, although that's not a huge concern to look at from the start."

Early versions of PHP were released in the late 90s, with PHP 4, the first Zend Engine version, released in 2000. The first PHP that didn't leak cycles (PHP 5.3.0) was released in 2009. Beware of how long "not a huge concern to look at from the start" can last.

[http://php.net/manual/en/features.gc.collecting- cycles.php](http://php.net/manual/en/features.gc.collecting-cycles.php)

[http://php.net/ChangeLog-5.php#5.3.0](http://php.net/ChangeLog-5.php#5.3.0)

<comment><AUTHOR> Yes, that is a good point. I had an adviser in college who specialized in garbage collection algorithms and I unfortunately didn't have the chance to take his course or learn from him, but there are definitely tradeoffs to all of the methods out there.

</comment></comment><comment><USER16> I think the first section confuses a couple of things.

First, a program can be compiled (static) or interpreted (dynamic) as stated in the article. However, that does not mean that you can't have a dynamic type system in a compiled language, or vice versa.

Also, if you add type inference, the examples given for variables in dynamic languages are perfectly valid examples for variables in a language with a static type system (the type would just be defined on first assignment).

<comment><USER17> Static and dynamic are theoretically unrelated to compiled or interpreted. The reason why it seems like these two are the same is that it's much harder to implement a compiled version of a dynamic language than an interpreted dynamic language, although I'm sure it's been done. There are plenty of interpreted static languages though.

I'm missing a discussion of weak vs strong in the article though. Visual Basic might be statically typed but it does have implicit type coercion which gives it a very different feel from — say — C#.

<comment><USER18> Common Lisp is an example of a compiled dynamic language.

<comment><AUTHOR> And a rather opaque one at that. I've never heard of anyone discussing the implementation details of a Scheme or Lisp compiler, leading me to believe that they must have really complicated internal logic.

I might be better served applying my time towards development on Chicken (Scheme).

<comment><USER19> There are books about Lisp implementations and papers about various Lisp compilers. Actually there is a whole bunch of literature about it.

Personally I find that the article needs a bunch of improvements:

static vs. dynamic vs. statically typed and dynamically typed

These are different things. Either we are talking about runtime behavior (a dynamic language can change itself or the program at runtime) or we are talking about typing.

For example Java is a statically typed language, but it allows the use of class loaders which can reload classes at runtime - which provides some dynamic features. On the other end of the spectrum are many compiled Lisp implementations which allow various changes to the programming language at runtime, for example via an extensive meta-object protocol.

> Attempting to access a value that has not been named in a relevant scope > leads to a syntax error issued at compile time.

A syntax error? Really? Syntax?

> So called dynamically typed languages are sometimes referred to as duck- > typed or duck languages.

Definitely not. Duck typing is a only a special form of dynamic typing, usually in an object-oriented language. Non object-oriented dynamically typed languages don't provide duck typing, because they lack OOP objects.

Does compiled Lisp look different?

Maybe... Let's look at SBCL on a 64bit Intel processor:

        * (defun calc (a b c) (+ (* 2 a) (* 3 b) (* 4 c)))

        CALC

        * (disassemble #'calc)

        ; disassembly for CALC
        ; Size: 118 bytes. Origin: #x1002EC2599
        ; 599:       48895DE8         MOV [RBP-24], RBX               ; no-arg-parsing entry point
        ; 59D:       BF04000000       MOV EDI, 4
        ; 5A2:       488BD1           MOV RDX, RCX
        ; 5A5:       41BBD0020020     MOV R11D, 536871632             ; GENERIC-*
        ; 5AB:       41FFD3           CALL R11
        ; 5AE:       488BF2           MOV RSI, RDX
        ; 5B1:       488B5DE8         MOV RBX, [RBP-24]
        ; 5B5:       488975F0         MOV [RBP-16], RSI
        ; 5B9:       BF06000000       MOV EDI, 6
        ; 5BE:       488BD3           MOV RDX, RBX
        ; 5C1:       41BBD0020020     MOV R11D, 536871632             ; GENERIC-*
        ; 5C7:       41FFD3           CALL R11
        ; 5CA:       488BFA           MOV RDI, RDX
        ; 5CD:       488B75F0         MOV RSI, [RBP-16]
        ; 5D1:       488BD6           MOV RDX, RSI
        ; 5D4:       41BBD0010020     MOV R11D, 536871376             ; GENERIC-+
        ; 5DA:       41FFD3           CALL R11
        ; 5DD:       488BDA           MOV RBX, RDX
        ; 5E0:       48895DF0         MOV [RBP-16], RBX
        ; 5E4:       488B55F8         MOV RDX, [RBP-8]
        ; 5E8:       BF08000000       MOV EDI, 8
        ; 5ED:       41BBD0020020     MOV R11D, 536871632             ; GENERIC-*
        ; 5F3:       41FFD3           CALL R11
        ; 5F6:       488BFA           MOV RDI, RDX
        ; 5F9:       488B5DF0         MOV RBX, [RBP-16]
        ; 5FD:       488BD3           MOV RDX, RBX
        ; 600:       41BBD0010020     MOV R11D, 536871376             ; GENERIC-+
        ; 606:       41FFD3           CALL R11
        ; 609:       488BE5           MOV RSP, RBP
        ; 60C:       F8               CLC
        ; 60D:       5D               POP RBP
        ; 60E:       C3               RET
        NIL

Now we can even define the types in Common Lisp:

        * (defun calc (a b c)
          (declare (fixnum a b c))
          (the fixnum
               (+ (the fixnum (* 2 a))
                  (the fixnum (* 3 b))
                  (the fixnum (* 4 c)))))
        STYLE-WARNING: redefining COMMON-LISP-USER::CALC in DEFUN

        CALC
        * (disassemble #'calc)

        ; disassembly for CALC
        ; Size: 38 bytes. Origin: #x1002F4B802
        ; 02:       48D1E1           SHL RCX, 1                       ; no-arg-parsing entry point
        ; 05:       488D047F         LEA RAX, [RDI+RDI*2]
        ; 09:       48D1F9           SAR RCX, 1
        ; 0C:       48D1F8           SAR RAX, 1
        ; 0F:       4801C1           ADD RCX, RAX
        ; 12:       48C1E602         SHL RSI, 2
        ; 16:       48D1FE           SAR RSI, 1
        ; 19:       4801F1           ADD RCX, RSI
        ; 1C:       48D1E1           SHL RCX, 1
        ; 1F:       488BD1           MOV RDX, RCX
        ; 22:       488BE5           MOV RSP, RBP
        ; 25:       F8               CLC
        ; 26:       5D               POP RBP
        ; 27:       C3               RET
        NIL
        *

<comment><AUTHOR> Overkill.

This article isn't a dictionary entry, an encyclopedia, or a research paper. It describes what's necessary to build a programming language for someone who has the necessary skills, which is someone who programs.

The entire premise of this programming language isn't based on as rigorous ideas as what you're criticizing, and that's been the reaction since the first time I posted about it.

As for what I was talking about, I'm only interested in dynamically typed languages that are compiled and provide support for 'eval in this case, because I don't believe that this is possible without providing a complete library for an interpreter with a compiled executable. For every other case, who really cares? Being able to replace every variable declaration with the keyword `auto' does not a new (or useful) programming language make. Additionally, all of these other gray areas in-between are not something I am interested in.

For this purpose, when speaking of the Duck programming language, dynamicism refers to being able to literally manipulate types and data in any way imaginable, both in terms of runtime behavior AND typing. In any case, it is designed to be _the most_ dynamic language, as the union of all of these features, and as such that invalidates a huge number of complaints.

>> Attempting to access a value that has not been named in a relevant scope leads to a syntax error issued at compile time.

> A syntax error? Really? Syntax?

This is a very minor complaint and mirrors 99% of the criticism I've received.

I wish I could get more interesting feedback for the content of my writing rather than the semantics.

</comment></comment></comment></comment></comment></comment><comment><USER20> Nice. But, as usual, a bit too much emphasis on syntax and parsing - the least important part of the language. Semantics and intermediate representations are much more important. Also, not quite convinced about the choice of C vs. LLVM IR.

<comment><USER21> Why intermediate representation? Build a straightforward AST then convert to LLVM.

Semantics is important. Before you start writing the frontend, I would advise to write some programs in your language like a tutorial for newbies.

<comment><USER20> > Why intermediate representation?

Because you'd need not just one, but many of them, in order to keep things simple and manageable - for the philosophical background on this read about the Nanopass approach: [http://www.cs.indiana.edu/~dyb/pubs/nano- jfp.pdf](http://www.cs.indiana.edu/~dyb/pubs/nano-jfp.pdf)

> Build a straightforward AST then convert to LLVM.

It's only possible for the very low level languages without any interesting features.

Firstly, you'd need some type system, even if it's mostly dynamic. Secondly, your frontend may provide quite a bit of syntax sugar that will need further lowering before you can easily turn it into IR.

Even before typing, you'd have to handle the lexical scoping, which may also involve an additional intermediate representation (one distinct IR per each pass is normal).

With this approach you can keep your entire compiler pipeline as a sequence of trivial, fully declarative, pattern-based tree rewrites. With the less fine- grained approaches you'd end up with a barely maintainable mess, where multiple passes functionality is combined into a single bloated, twisted pass.

> Semantics is important.

Of course it's the only thing that is important. Unlike syntax.

<comment><USER22> > one distinct IR per each pass is normal

Source?

<comment><USER20> > Source?

1) Personal experience

2) The link I provided above (and all the other relevant Nanopass papers too)

</comment></comment></comment></comment></comment><comment><USER23> Designing a programming language is something I've found very interesting for the past few years now, but this is the one area of programming that really still eludes me and seems unapproachable. I've been through Understanding Computation, but at a certain point I just no longer understood what the hell was going on I was just typing in the examples.

I have the Principles of Compiler Design book and I've made a run at that a couple of times, but it seems to theoretical for me to do anything useful with it.

I've been thinking about taking a go at creating something with ANTLR alone with the books The Definitive ANTLR 4 Reference and Language Implementation Patterns, but I'm not sure if I'll have much more luck there.

If anyone knows of a better path to get from here (can't design my own language) to there (clarity and understanding) I would love to hear your ideas.

I'm not trying to create the next Rust, JavaScript, etc... I just believe that being able to implement my own language would give me a deeper understanding. In fact I'm very much interested in the idea of reimplementing an interpreter or compiler for languages I already work with as a way of learning this rather than trying to create something new.

<comment><USER24> I started a series of articles called "Let's Build A Simple Interpreter" which might be what you're looking for:

\- [http://ruslanspivak.com/lsbasi-part1/](http://ruslanspivak.com/lsbasi- part1/)

\- [http://ruslanspivak.com/lsbasi-part2/](http://ruslanspivak.com/lsbasi- part2/)

<comment><AUTHOR> +1

</comment></comment></comment><comment><USER25> Anybody know the difference between the "green" and the "red" dragon book?

<comment><USER26> green dragon book is [https://en.wikipedia.org/wiki/Principles_of_Compiler_Design](https://en.wikipedia.org/wiki/Principles_of_Compiler_Design)

red dragon book is the first edition of [https://en.wikipedia.org/wiki/Compilers:_Principles,_Techniq...](https://en.wikipedia.org/wiki/Compilers:_Principles,_Techniques,_and_Tools)

</comment></comment><comment><USER27> I really wish more help from human-computer interaction & cognitive psychologists would be used to design a programming language.

The programming language is (to me) the most expensive part of a system, because it determines how the coder works & interacts with the system. And the human resources involved in building the system are the most expensive (besides those used to maintain and run it daily).

There must be symbols used to write code that are more easy to cognitively process than others. There must be keywords that are easier to memorize than others. There must be ways to write a statement that are less prone to error than others. Let's start working on this important and neglected problem.

<comment><USER28> Those are the "language by committee" that people complain about. Ada was made that way, if I remember correctly.</comment></comment>


Everest: an app to help you live your dreams. (Launched today) - <AUTHOR> https://itunes.apple.com/us/app/everest-live-your-dreams-achieve/id581016826?ls=1&mt=8

<comment><AUTHOR> Some friends of mine made it. Comments? Feedback?</comment>


Ask HN: Does anyone know any good resources for enterprise UX design? - <AUTHOR> Hello
I've been working for sometime now at enterprise HR solution (similar an ERP) and i've been looking for a long time for resources about enterprise UX design. Seems like it's incredibly hard to find any relevant information. For example table design - holds a lot of data, needs to support complex filtering, a lot of contextual actions, etc.
Most of the content online focuses on consumer products and the knowledge barely applies in enterprise products.
It would be great to see if you guys know any in-depth resources (preferably books). <comment><USER4> Hi Victor, Books as such I can't tell, but I'm working on tutorials on table design.

For instance, imagine the UX of Amazon or Ebay showing you a table with all of their products. Like AMD does in this page: [https://www.amd.com/en/products/specifications/processors](https://www.amd.com/en/products/specifications/processors)

In short, their problem is not about table design, but how to design without a table.

In other words, think of table as a detail, as opossed to a starting point. Sometimes a table would fine, especially if it has no row variants. But if you have conditional actions across rows, or too many unused fields per row, then a table would be too difficult to implement and use.

As you mentioned contextual actions in a table, I'm pretty sure you can provide a better UX if you don't use a table. For example, in my product I started out with a table drafting out the team members per account (invite, resend invited, remove, etc). But I ended up better by using cards. So I drafted each row variant in a card.

</comment><comment><USER5> A lot of the underlying principles from consumer oriented design can be applied to enterprise.

Do some observation and learning about how tools your users are used to do what you're trying to do.

Some resources:

[https://uxdesign.cc/data-table-for-enterprise-ux- cb48fb9fdf1...](https://uxdesign.cc/data-table-for-enterprise-ux-cb48fb9fdf1e)

[https://uxdesign.cc/enterprise-ux-anything-but- typical-a955d...](https://uxdesign.cc/enterprise-ux-anything-but- typical-a955da0ce7cc)

[https://uxdesign.cc/tagged/enterprise](https://uxdesign.cc/tagged/enterprise)

[https://www.nngroup.com/search/?q=enterprise](https://www.nngroup.com/search/?q=enterprise)

</comment><comment><USER6> There shouldn't be any difference. The fact there are differences is a symptom of a broken procurement process where you get your specs from the person who has purchasing power, or an executive, or really anyone except the people who'll end up using that software.

If you have a saying, you can advocate to include those who will actually use the product.

If you are not forbidden to get in touch with them (believe it or not, some execs will forbid you to include the people you're building for in the conversation), you can try and tighten the feedback loop.

If you're designing to a rigid spec, then it pains me to say it doesn't matter: You will get paid but nobody will use your software. Those are the bitterest dollars.

<comment><USER7> What about easy peasy vs power users?

The cash register has more buttons than my keyboard and that's maybe a good thing. No consumer product would do that.

<comment><USER6> That's at the functionality level. You have the common parameters or settings, and then the advanced ones.

However, the software contains many functionalities, for different customers. A functionality that is relevant for one customer is irrelevant for another, hence my reply on using a plugin architecture.

</comment></comment></comment><comment><USER8> The users.

<comment><USER6> Yes. As per my previous comment, there are unfortunate situations that prevent this.

      Developer -                                        - <USER3>
                 \                                      /
      Developer -----> Vendor Rep <---> Client Rep ---||-- User
                 /                                      \
      Developer -                                        - <USER3>

The || represents a barrier/broken link. The users are involved once the product is "finished" and told to start to use it. This is a great way to build useless products.

<comment><AUTHOR> We do have a saying, as our product does a lot of atuff differently than competition and our users accept that (they're even looking for that). we also decided that we're not going to become a one customer product, but even with feedback and previous domain experience, it's still hard to model an enterprise product that accommodates all the required processes and data and still feel good and not feel like accounting software.

<comment><USER6> One way to solve that is with a plugin architecture and categories and a platform. You can create:

\- An API that allows to interact and control your software functionality

\- An SDK to allow third party development.

\- A marketplace where you and third parties can put plugins/applications to your software.

One problem is clutter and trying to cram in too many things for every customer. By customer I also mean an enterprise as a whole. For every customer, only a subset of these functionalities is useful, and the rest is noise. This will be the experience of every customer using your software: mostly noise, some useful features.

The plugin architecture will increase the signal/noise ratio by allowing people to install the extensions that matter to them and only those that matter. Every customer will only have the extensions that are useful to them, and this will be the experience of every user.

Take your computer or phone. We might have the same OS, but we have different applications installed. Imagine if the entity that produced the OS wanted to satisfy us both: they'd cram the _union_ of applications we need, and it would be a nightmare.

Our guiding line for our SDK is "Anything you can do on the platform, you can do with an API call" and "You should be able to reproduce the platform with the SDK and API keys".

Here are a few lines for a recent reply[0] to another question:

> _the first few commits in our iko.ai project were to use a plugin > architecture so that new features were apps /plugins we could > activate/deactivate from a config file._

> _These apps live in separate repositories and are loaded by the core. The > core is tiny and most of the work is on the extensions. Similar to kernel > vs. drivers._

> _Why we did that? We 've been building custom enterprise data products for > almost seven years. Many of these products were so custom we couldn't sell > the same product to another client if we wanted. It is not just about code > reuse on the function or library level, it's "functionality" refuse as in > you plug in a forecast extension, you plug in a sentiment analysis > extension, etc._

> _A couple of years ago, a college acquaintance came to me and asked if he > could hire us to deliver a certain product. We practically had the product > ready but the features were baked in the product._

> _So, now, we have features as independent applications that get loaded, > displayed, and interacted with easily._

[0]: [https://news.ycombinator.com/item?id=24503365](https://news.ycombinator.com/item?id=24503365)</comment></comment></comment></comment>


Launch HN: Embrace (YC S19) – Spot and fix bugs in mobile apps - <AUTHOR> Hi HN!
I'm Eric, the co-founder of Embrace (https://embrace.io).
Embrace is a debugging and performance monitoring platform that gives developers the information and context they need to monitor and solve errors, crashes, and performance issues. Think of it as what you wish Crashlytics had evolved into combined with the session replay capability of Fullstory.
Before Embrace, I co-founded the mobile gaming company Scopely, where we made six top-grossing mobile games including Yahtzee, Walking Dead, and Star Trek. The pain I felt while developing those games sparked the idea for Embrace. Customers and I would find bugs that were impossible to reproduce by the development and QA teams, and the analytics and logging tools we had in place just weren't enough to solve them.
We had crashes under control, so we cared more about startup freezes, failed purchases, and out-of-memory app closes. Without reproducing the issue, we couldn't tell if the error was caused by a fundamental code issue, something with my device settings, a network problem, or just a very unfortunate combination of all of the above. The solution seemed simple: I wanted to look up my session and see all the user interactions, networking and logging together to find out what caused my issue.
After talking with my friends at other mobile app companies, I knew I wasn't alone. Things worked well in development, but we saw unexpected errors in production and we never had enough information to solve them. I wanted more than just a stack trace to help developers fix the problem, so my co-founder Fredric—who has now built three mobile analytics companies—and I started Embrace.
We've talked with many mobile developers and companies and we saw many common problems with apps, such as slow app starts resulting from too many blocking network calls on startup, and we have built the features into our platform to help solve these problems. We also saw processes that were more cumbersome than they needed to be. Often when developers had to fix an issue they would try to combine data from backend logs, different monitoring tools, and feedback from bug reporters to try to build a picture of what was going wrong, but in the end it still wasn't enough. There was always that one log message that they realized they should have added and they had to wait another release cycle figuring out a fix for the issue.
You can add Embrace's SDK to your app to start collecting the info I had been missing when building apps. We intercept network calls, track views, monitor CPU usage, capture crashes, and automatically collect many more metrics to provide developers with the context that they have told us helps them solve problems. Add logs and breadcrumbs that you define, and we are able to get you as close to replaying user sessions as possible without capturing video. You'll be to see able to see the network calls before a failed purchase or whether or not the device was in low-power mode when it crashed.
We are fortunate to have 40+ customers already, including Wish, OkCupid, AllTrails, and Home Depot. We helped solve the 2nd largest, long-standing crash for Wish by providing their developers with context they were lacking. Developers for a subscription revenue app were able to identify that a critical network call did not occur as expected when users took a certain path through their app. The most recent customer I visited solved two bugs using info from our tool the day after they integrated.
We look forward to answering any questions you have and hearing what challenges you face with your mobile apps. We are free to use in development, so any feedback you have on the service would be much appreciated! <comment><USER2> Wow. Great tech. Congratulations!

A few questions:

What's the typical amt of overhead due to the sdk on the app in terms of RAM, CPU, Network and how much does that translate to battery drain? What improvements, if any, are in the pipeline with regards to this?

How does the sdk behave in 2G environments? Is it built for billions [0]?

How did you ensure the sdk itself isn't causing issues given the myraid of functionality it supports? Interested in knowing how you built resiliency.

On the server side, how does the architecture look like in terms of storage, reporting, and collection of data from phones.

Thanks.

[0] [https://developer.android.com/topic/billions](https://developer.android.com/topic/billions)

<comment><USER3> Thanks for all the great questions!

The overhead is fairly minimal since we mostly intercept things that happen in the app and don't really have any things that run continuously at high frequency, e.g. we add about 0.5ms to network calls on average devices. The RAM usage is limited since we put caps on how much data we capture in a session. We do give devs the option to configure the SDK to capture screenshots when errors occur, which is the largest consumption of RAM we incur, but that can be disabled.

We make network calls for logs and submitting session data, so that does some bandwidth, but as mentioned above we put caps on how much data we capture in a session to avoid payloads getting excessively large.

We've had some customers who have been pretty sensitive to battery drain, and from working with them we've solved a couple of issues that did affect battery drainage, but no longer do.

We haven't invested a ton of effort yet to optimize the SDK specifically for 2G environments. That said we do have customers using our service with large user bases in India and the Philippines, where many of their users are on less-than-stellar network connections. As we expand to serve more markets where 2G is more common, we will be focusing on SDK performance for that.

As to how we ensured the SDK wasn't causing problems.... blood, sweat, and tears? Jokes aside, we had great early adopters who worked through some painful bugs with us. We've also had some devs at companies that we think have high code standards give us pointed feedback. Our basic thesis is that development for mobile is hard, and developing an SDK for mobile that does not impact the app it's integrated in is really hard, so we also used our own tool to figure out when things were not going right with the SDK.

The backend stack uses a bunch of wonderful OSS tech like nginx, Kafka, Cassandra, Clickhouse, Redis, MySQL, React, Gin, and Django. We are dealing with data volumes that pose fun engineering challenges, and we wouldn't be able to do it if we weren't standing on the shoulders of giants.

If I missed the mark or you're looking for more depth, don't hesitate to follow up!

<comment><USER2> > If I missed the mark or you're looking for more depth, don't hesitate to > follow up!

Thanks a lot for taking time to reply. I hope you blog about the challenges you overcame at some point, esp wrt power consumption and resilience.

This product looks like something Google should have built themselves!

Good luck.

<comment><USER3> Thanks for the kinds words! I will talk to our SDK folks and see if I can get them interested in writing a blog post and not just writing code :)

</comment></comment></comment></comment><comment><USER4> It looks really cool, but I feel your 'Live' pricing @ $1000/m is highly prohibitive to developers not in the first world. Although I suspect that's not your target market. I wouldn't be able to recommend to anyone to add that cost onto their app, without massive differences from what one gets with other platforms.

<comment><USER5> It seems they have a Startup plan

<comment><USER4> Yes but if I have client's that aren't startups, and want to use a product like this, I'd much more easily recommend a cheaper alternative.

<comment><AUTHOR> I think the question I generally ask is what are the alternatives? There are so many developers tools but very few built for the uniqueness of mobile.

</comment></comment></comment></comment><comment><USER6> This sounds really useful. Can you intercept communication with GPS as well? One of the most frustrating bugs I had to deal with was GPS misbehaving on like 1% of Android users with with no pattern among OS version, manufacturer, carrier, physical location etc. Maybe it would have been helpful in that situation.

<comment><AUTHOR> We find that customers typically use session breadcrumbs to collect data around subsystems like Bluetooth and GPS to figure out what is going wrong. The 1%-failure use case is definitely a pattern we see quite a bit and we've had customers use our platform to figure out infrequent GPS tracking and Bluetooth connectivity problems.

</comment></comment><comment><USER7> Interesting. How are you actually capturing the network request data if it's HTTPS?

<comment><USER8> There are lifecycle hooks you can plug into within the app to make these types of captures. This tool is an example that uses them: [https://github.com/kasketis/netfox/blob/master/README.md](https://github.com/kasketis/netfox/blob/master/README.md)

<comment><AUTHOR> Yep, there are definitely a lot of ways to tackle network capture. I haven't looked in-depth at that particular tool to know how close they are to what we do. We're always excited to see how other people are tackling this. Is there something that you think netfox does better than other tools you've looked at?

<comment><USER8> No, I was just pointing out you don't need a man in the middle proxy to analyze http traffic.

</comment></comment></comment></comment><comment><USER9> Looks interesting! Is there an easy way to mask PII from the analytics tool?

<comment><AUTHOR> We have a few ways to ensure you don't send us PII. Sending identifiers like user name or email exist as an option in the SDK, but it is an opt-in integration step and not done automatically. We also have an option to capture screenshots, but again this is something that customers have full control over so that sensitive parts of the app are not captured. And we built a remote kill-switch for screenshots if a customer didn't get their integration quite right or something unforeseen happened. If you have sensitive data in URLs we allow specific URL patterns to not be captured. Was there any specific type of PII you were primarily interested in seeing masked?

<comment><USER9> Sure - I'm more concerned about inadvertent leakage of email addresses or passwords than passing along an identifier to the API as part of the implementation, especially if it's capturing network traffic.

<comment><AUTHOR> We do support network traffic capture, but this is not enabled by default and is typically only used on specific endpoints with specific status codes that customers are having problems with. We do not capture request and response bodies both for privacy and data usage reasons. We don't want to double the bandwidth usage when somebody integrates us nor do we want them to accidentally send us sensitive data.

</comment></comment></comment></comment><comment><USER10> Looks really interesting!

How does it behave with slow/unreliable networks? Do you buffer events if they don't go through immediately? What's typical data usage for the SDK?

<comment><AUTHOR> We do buffer session, log, and event data and retry it when network connections improve. The data usage will vary from application to application since it is heavily dependent on how much network activity the app has, how many logs are captured, and a few other integration options which are specified by the developer. Session payloads are typically in the 5kB to 10kB range, and will increase to the 20kB range for network heavy apps that are making a lot of calls for assets.

</comment></comment><comment><USER8> Looks pretty fantastic. Is the sdk open source?

<comment><AUTHOR> Not yet. We will be open sourcing our React Native SDK in the coming month, and the native SDKs will be open sourced later this year.

</comment></comment><comment><USER11> Does it work in app-extensions such as custom iOS Keyboards?

<comment><AUTHOR> Sadly not. We have not seen a lot of demand for this yet. It'd be great to hear more about your use case.

</comment></comment><comment><USER12> Flutter?

<comment><AUTHOR> Yes, we have people using Flutter with our service

<comment><USER12> The docs don't say anything about it, the integration works the same way as for native android?

<comment><AUTHOR> Yes, the integration is the same as for native Android. We're happy to work through any questions you have about it if you want to test it out.</comment></comment></comment></comment>


How I Did It: Google's CEO on the Enduring Lessons of a Quirky IPO - <AUTHOR> http://hbr.org/2010/05/how-i-did-it-googles-ceo-on-the-enduring-lessons-of-a-quirky-ipo/ar/1 <comment><USER3> I disagree with another HN commenter on the value of this article. Taking two backward steps through Eric Schmidt's conclusion: \- "I wouldn't change a thing - except maybe (an interview that Playboy published putting Google in breach of the SEC-mandatory quiet period)" \- "To this day I can't fully explain why our stock price opened so high—causing the pop we had tried to avoid [Google sold its shares at $85; three days later people were selling what they'd bought at $110]. A lot of complicated factors played a role" (none of which are discussed).

Basically, they screwed up, left a huge amount of money on the table, and he doesn't admit to the possibility of any possible improvements, the possibility that doing the IPO at that time was the wrong call, or discuss the factors behind the pop despite their strategy to try and avoid it.

Firstly, Could Google not have just stayed privately owned, but published its financial records for a few years, before then doing their IPO? From this article it doesn't sound like the IPO cash was particularly important at that point, and the meteoric rise in the share price suggests (with 20:20 hindsight) that they let far too much go, far too early on. The crucial paragraph doesn't discuss the decision process to do the IPO, it only lists the options. That's disappointing.

As for why they went for a Dutch auction - to bust the institutional racket (good on them) and because "It was consistent with the auction-based business model we used to sell our ads, so we felt we understood the underlying dynamics, and it had a strong intuitive appeal for us." Clearly that understanding wasn't worth shit - it doesn't seem to have helped them predict anything about what happened in the auction. The anti-establishment attitude was really commendable, but it seems like it was a huge strategic mistake. Some factors may of course have been out of their hands - <USER2> inexperience/wariness with the Dutch auction format leading to low initial bidding, pseudo-concerted action to keep the bids low, etc. But that's a strategic mistake which a strategy exec should be owning up to. The two first weeks in August before the bidding opened were stuffed with terrible Google news (and he sets up a surprise Playboy publication of an April interview as a paper tiger - but see the diagram in the article for the rest). They got pushed into August because of the complexity, and it is a bad month to do an IPO, but he says they didn't care.

He bemoans the press for portraying their approach as 'hubristic' and therefore worth staying away from. Yet the press was spot on with their analysis of the factual situation - it _was_ hubristic, seemingly not particularly well thought through, or even diligently executed. What the press got wrong is in concluding that it was something to stay away from. Quite the opposite - the people who got in at the Dutch auction stage made a vast amount of money! Google didn't, though.

So I found the pomp and pride underpinning the article really quite unsubstantiated - and yes, particularly hubristic. It was innovative, done with some honest and interesting motivations, but it was a cockup, from top to bottom. I disagree that they had 'risen to the task'. They do that in their core business, undoubtedly, day in, day out, but this was a fuzzy mess and I'm always worried by CEOs who don't learn from cockups - substantially more so when they deny that the cockup even existed

<comment><USER4> I disagree with your assertion that they left a huge amount of money on the table.

From wikipedia ([http://en.wikipedia.org/wiki/History_of_Google#Financing_and...](http://en.wikipedia.org/wiki/History_of_Google#Financing_and_initial_public_offering))

Google's initial public offering took place on August 19, 2004. A total of 19,605,052 shares were offered at a price of $85 per share.[27] Of that, 14,142,135 (another mathematical reference as √2 ≈ 1.4142135) were floated by Google and 5,462,917 by selling stockholders. The sale raised US$1.67 billion, and gave Google a market capitalization of more than $23 billion.[28]

So - assuming the market established a price of $110, and the sold at $85. Google lost out 14,142,135 x $20. Now $280M is not to be sniffed at, but for a company with a market cap of $23,000M it's little over 1% of it's value. Given the shares had risen 25% on the opening day, 1% is not really material.

Given that the company was cash flow positive, the difference between raising $1.67B and and $1.93B of would probably not have any operation affect on the business.

<comment><USER3> I'm not saying a dutch auction is necessarily a worse option. Indeed it might theoretically be the best. But they spent a vast amount of money setting it up, with all the extra legal fees and transactional costs, so let's not focus entirely on the money left on the table by the strategic error to a) pick a theoretical, rather than tested, procedure that was b) seemingly, poorly executed and c) if it yielded any lessons at all, for which there is no evidence, Schmidt refuses to share.

On a pedantic point, if my understanding is correct, google made (14m * 85) about 1.2 bil on the IPO, not 1.67 - the rest being sold by other stockholders (who, incidentally, 'lost' $136.5 mil due to the pop, and made $464m, minus fees for being involved in the IPO - not insignificant) That means that Google made 1.2 bil, but had they 'got it right' (very difficult, of course, as other commenters point out, 14% pop is usual on IPOs) they would have made $1.55 bil. You can make it seem small compared to their market cap, but the headline is: he's proud at a messy, protracted transaction, possibly the most important in Google's history, that netted them $353m more than their 1.2 bil haul. That's 20-25% on the table, well in excess of the 14% bandied about in this thread.

And all that says nothing about the overarching questions of 'Why IPO, why then?' and 'what actually went wrong?'

</comment></comment></comment><comment><USER5> One page version of the article: [http://hbr.org/2010/05/how-i-did-it-googles- ceo-on-the-endur...](http://hbr.org/2010/05/how-i-did-it-googles-ceo-on-the- enduring-lessons-of-a-quirky-ipo/ar/pr)

</comment><comment><USER6> I wonder if he wrote it himself. It's really well written.

</comment><comment><USER7> The reason for the underpricing is simple: it was the first big Dutch Auction IPO and when something is new, only the few will participate leaving the hesitant to jump in once it trades on the open market, bidding up the price.

This left the auction open to certain big institutions (Fidelity and another I forget) to badmouth the deal to lower the price while buying big themselves. Of course they were joined by the Investment Banks who really like that 7% standard IPO fee and felt threatened. And the press to whom everything is either an epic success or huge failure.

As a first, the deal also had many technical issues which lead to the August pricing and fed the negativity.

Anyway, the key win was that anyone (even a tiny investor like me) could buy in the IPO. Just try to get shares in any decent IPO run the normal way. If you do, it's likely to be a broken deal they couldn't find demand for and you'll most likely lose money at first trade.

</comment><comment><USER8> Seems like a chapter out of [http://www.amazon.com/Google-Story-Googles-10th- Birthday/dp/...](http://www.amazon.com/Google-Story-Googles-10th- Birthday/dp/038534273X/)</comment>


Mt. Gox Bitcoin CEO Can't Stifle Grin as he Bows in Apology for Bankruptcy - <AUTHOR> http://www.dailytech.com/Mt+Gox+Bitcoin+CEO+Cant+Stifle+Grin+as+he+Bows+in+Apology+for+Bankruptcy/article34424.htm <comment><USER2> The article's author is obviously unfamiliar with Japanese customs. A bow without a smile is taken as insincere.

[http://blog.heritage.org/wp- content/uploads/2009/11/obamajap...](http://blog.heritage.org/wp- content/uploads/2009/11/obamajapanbow091116.jpg)

[http://thumbs.dreamstime.com/x/two-young-smiling-woman- japan...](http://thumbs.dreamstime.com/x/two-young-smiling-woman-japanese- kimonos-bowing-to-each-other-studio-shot-women-33399547.jpg)

</comment><comment><USER3> Some people grin, or even laugh when uncomfortable or nervous. Using what _may_ be a slight grin as the title of an article means this article, and journalist for that matter, aren't worth my time. I highly doubt they are worth anyone else's either.</comment>


Why Drug Dealers Live With Their Moms (2007) - <AUTHOR> http://articles.latimes.com/2005/apr/24/opinion/oe-dubner24

<comment><USER2> 2005\. Discussed in the book Freakonomics.</comment>


Secret Shuts Down - <AUTHOR> http://techcrunch.com/2015/04/29/psst/ <comment><USER3> This shutdown - and some of the comments here that indicate how nasty Secret had become before it died - is quite interesting in light of the conversation surrounding Google's Real Names Only policy.

Secret cofounders David Byttow and Chris Bader-Wechseler were both veterans of Google+. Byttow, in particular, I recall being quite well-respected as someone who got shit done, quietly and efficiently, by the rest of the G+ team. I didn't know him personally, but I had a few professional dealings with him where I found him to be a straight-shooter that was remarkably effective and helpful. When I heard of the product concept for Secret, my first thought was "Woah, somebody's finally decided to take the other side of the stupid Real Names policy and build a social network that's completely anonymous."

Apparently that doesn't work either, and when you do that, people hate you just as much.

My take-away from this is that social software is remarkably hard, and that whatever you do, people will hate you. The social sites that survive - <USER2> Reddit, Flickr, and Facebook - are those that very carefully balance everyone's competing desires, making just enough changes to keep everyone slightly disgruntled but not enough to leave the site. The ones that die - like Secret, G+, LiveJournal - are the ones that either do nothing to moderate or that introduce heavy-handed blanket policies. (4chan, as always, remains inexplicable; somehow it is still going strong despite being a cesspool. Maybe that's the whole point of it, though, to be the Internet's honey pot of bad behavior.)

<comment><USER4> 4chan isn't a cesspool though, that's just an image they project to push away people who would respond to such pushing (approximately, the olds).

(There are certainly parts of it that are risky clicks though)

<comment><USER5> I would phrase it as, "the default/most-well-known subforums of any forum will be garbage once the site reaches critical mass, being diluted by new members too quickly to keep their character. A proliferation of smaller subforums with their own effective communities will displace the sense that the site has any worthwhile/coherent community taken as a whole." Applies equally to 4chan and Reddit.

<comment><USER6> One name for this is Eternal September: [http://en.wikipedia.org/wiki/Eternal_September](http://en.wikipedia.org/wiki/Eternal_September)

</comment></comment></comment></comment><comment><USER7> This has been a fascinating story to watch unfold (and experience as a user.)

When Secret came out, the addiction bug bit me hard too -- it was _extremely_ compelling. I posted. My friends posted. Everyone was checking Secret obsessively. People were "communicating" with their exes (or so they thought), people were guessing who was posting what. It was fun. It was interesting. It pulled some emotional heartstrings (I had a few interactions with "friends" who I was pretty certain I would never have spoken with in real life - i.e. bad breakups, etc.)

Then it took a nasty turn. There was gossip, there were attacks. They didn't get too bad, but the tone changed.

Then they released the Android app. More users signed up. It started to take on a high school feeling ("omg my crush winked at me"). It got more popular.

Then, at least in SF, it started being almost entirely about gay sexual fantasies. Friends in my circle started using it less, so it got less interesting to me. Eventually I stopped using it when nobody I knew was posting.

After that, I stopped following. They did some massive redesign which seemed terrible, and I didn't really pay attention after that.

In the end, it was a niche fad that had particular appeal if you were a tech person in SF. All the gossip - as taboo as it was - was interesting and compelling (I admit it!). It was a fun, exciting, interesting fad, but it succumbed to the sort of thing fads usually succumb to -- time.

The problem with these sorts of things - flash in the pan community-specific fads - is that they're _incredibly_ hard to sustain, and even harder to monetize as a business. I certainly understand the instinct of VCs to throw money at a hot app experiencing meteoric growth (and I doubly understand the response of the founders to take both the investment and the secondary $), but it was a longshot to start with.

Frankly, I admire them for giving it a shot, recognizing the reality, and returning the leftover capital. Well and rationally played all around, me thinks.

<comment><USER8> _" When Secret came out, the addiction bug bit me hard too -- it was _extremely_ compelling....Then it took a nasty turn. There was gossip, there were attacks. They didn't get too bad, but the tone changed."_

And all of that, from what I recall, in the course of maybe three months. It wasn't hard to predict the decline -- the Greater Internet Fuckwad Theory has been around since what, 2004?

Maybe the investors who dump money into this kind of flash-in-the-pan stuff ought to wait a few minutes before signing the term sheets. But, oh yeah...because we're in a white-hot investment market, the Fear of Missing Out (aka Fear of the Greater Fool) doesn't let you stop to think.

<comment><USER9> It seems to me that VC's take heat for investing too early, too late, too much and too little. Being too conservative or too risky. They're an easy punching bag.

<comment><USER8> I don't ordinarily care what VC's do with their money (i.e. mostly lose it), but it's disingenuous to suggest that there aren't clear trends: it's very difficult to raise a series A, but if you're the hype-driven flavor-of-the- moment, you can close a round with little to no diligence, few metrics and none of the proof traditionally required of a series A investment. We're still seeing money get shoved at companies who had a moment in the sun on ProductHunt or Reddit, with zero validation of the underlying business prospects (or even much in the way of critical thinking).

So yeah, VC's do take heat for investing too early, too late, too much and too little. It isn't a contradiction -- it's what people do when they act as a herd.

<comment><USER3> Because the best validation is people using your product. Or technically, the best validation is people _paying_ for your product, but if they're doing that in amounts great enough for a VC to notice then you don't need to raise VC.

The herd behavior comes from everyone having more-or-less the same metrics for what constitutes success: people using your product. If that metric isn't evident, you fall back on the fundraising strategy for people who don't have traction: try lots of VCs and hope that one buys into your vision enough to invest. If the next better metric - lots of revenue - is evident, then it's too late and chances are that someone else has already invested, or they don't need investment.

<comment><USER8> Ehhh. Traction is a necessary, but insufficient condition for getting a series A. There's a "hotness" component here that's contributing to the overreaction.

You can't explain things like (for example) Meerkat raising a big round and cratering _the very next week_ without considering the importance of hype. Meerkat and Color and Secret are walking out the door with big checks while lots of other entrepreneurs with great metrics are waiting for their fifteenth meeting...because they're not in the tech gossip rags.

Say what they will in public, I'll bet you that Meerkat's investors are wishing they'd sat on _that_ term sheet for a couple of days.

</comment></comment></comment></comment></comment></comment><comment><USER10> It seems kind of crazy to me that people talk about startups and try to apply completely the same model for everything to:

1) A social app like this, which is essentially hype-based and self reinforcing. Success seems entirely down to virality and adoption, followed by monetization.

2) Some very vertical market focused SAAS offering which can be developed with minimal outside capital, own a niche, and where capital can then be applied to expand to other verticals, accelerate the sales process, etc. (Say, a scheduling application for vets)

3) A capital intensive project in a well understood field (IAAS, hardware, lab stuff, etc.)

4) Entirely new technology deployment (not discovery, which tends to be hugeco or lab, but first commercialization)

Clearly there are some commonalities, but there are a lot of areas like employee vesting periods, how you recruit, etc. which probably should be different in these different kinds of companies, but tend to be the same.

<comment><USER11> Spot on. A lot of what's very challenging for today's web startups, like hiring, is easy for startups in cleantech, since there's so few funded startups. Conversely, it feels an order of magnitude more challenging to raise the money in clean tech...

</comment></comment><comment><USER12> For the curious, pulled their deal history from PitchBook:

Secret raised their B last July at a post valuation just over 130M ([http://i.imgur.com/jNXw5PZ.png](http://i.imgur.com/jNXw5PZ.png)). They had some major investors backing them up, and then the hype train just... stopped.

I remember so many people being so high on it when it launched, with several friends all raving about how fun/addicting it was, then just _poof_ it disappeared from conversation.

Hearing that the founders got some cash off the table (article from last summer - [http://www.businessinsider.com/secret-founders- pocket-6-mill...](http://www.businessinsider.com/secret-founders- pocket-6-million-in-25-million-fundraise-2014-7)). While I always thought that seems like a _good_ thing, I can't help but let my mind wander a bit as I know if I were given a nice chunk of change like that so early, it might be kind of hard to keep focus.

<comment><USER13> _>[http://i.imgur.com/jNXw5PZ.png](http://i.imgur.com/jNXw5PZ.png) _

Here was the intended use of the $25M: _" The funding will be used to implement two new features, a Facebook login and the ability to follow posts on a certain topic"_. This is what is wrong with Silicon Valley today. An afternoon project for a single developer gets $25M from investors. Please, someone give me just $10M....I've already implemented Facebook login for my apps.

<comment><USER14> That's hilarious! In Web 1.0, people raised $7 million to buy a domain name. Needing $12.5 million to implement a Facebook login ($25/2 projects) is even more ridiculous.

<comment><USER15> Box paid 7 figures for the Box.com domain name, so I wouldn't say that raising money to buy domains is dead yet.

<comment><USER16> Box bought box.com roughly 6 years after they launched, they were already wildly successful (as box.net).

<comment><USER17> Has box had a profitable quarter yet?

<comment><USER18> has Amazon?

<comment><USER15> Amazon's first profitable quarter was in 2001: [http://news.cnet.com/2100-1017-819688.html](http://news.cnet.com/2100-1017-819688.html)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> Here's the official Medium post by the cofounder, in which there is confirmation that they are returning the money to investors: [https://medium.com/secret-den/sunset-bc18450478d5](https://medium.com/secret- den/sunset-bc18450478d5)

The post also includes the phrase "incredible journey" verbatim.

<comment><USER20> Was that a reference to this tumblr: [http://ourincrediblejourney.tumblr.com/](http://ourincrediblejourney.tumblr.com/) Pretty appropriate.

<comment><USER21> Technically, the curator of that Tumblr account created it to criticize acquihires, not shutdowns in general. From the "What is an incredible journey?" page:

> Companies go broke all the time. It's unfortunate and it may mean a service > you love will close. But some things just don't work out. [...] This is what > is galling. A company that can afford to pay millions for some new staff but > not for what those staff built. The people who used the service, and > invested their belief and time in uploading photos, or forming friendships, > or logging data, are left to find new virtual homes while their former hosts > enjoy a nice (if possibly delayed) payday.

\-- [http://ourincrediblejourney.tumblr.com/post/89180616013/what...](http://ourincrediblejourney.tumblr.com/post/89180616013/what- is-an-incredible-journey)

Although admittedly, from an end-user's perspective, the effects are the same no matter the reason for the shutdown.

</comment></comment></comment><comment><USER22> I thought secret was a really, really cool idea. I downloaded the app and played with it for a few days. After the hype died down, the app was almost 100% about sexual fantasies, coming out of the closet, and having been beaten/molested as a child.

I can't be sure, but it seemed to me that the "upvote/like" mechanism boosting posts to the top (with no validity required) turned Secret into an enormous, "Who can say the most absurd clickbait thing" contest. It got tiring, and I deleted the app.

Having talked with a few other people about Secret, they said the same thing.

<comment><USER23> This was exactly my experience, even before the hype died down. 99% of the posts were from my gay friends (and friends of friends) talking about some sexual fantasy or sexual encounter.

It was simply not compelling content, so about two weeks in I deleted it.

I wonder if there was something in the marketing or the initial group of people that created some zeitgeist that eventually killed the idea? I'd be interested to know if they actively made some effort to try and get out of that rut.

</comment></comment><comment><USER24> I would've never understood the appeal of these anonymous apps over something like Reddit (in which you can be as anonymous as you'd like) if I hadn't had a job on campus, where YikYak is well-frequented, and a far better source of breaking trivial news (i.e. what is all that yelling outside about?) than anything else...using YikYak periodically has made me realize again how easy it is to underestimate the appeal of less friction...including the friction of having to deal with users and their user histories. On the other hand, it's a shitshow when some topic like Greeks vs. non-Greeks or Middle East politics comes up...and having no way to filter the noise, either by user or by topic, ends up killing the enjoyment of the app. Yikyak is interesting because of its popularity on campus...but anywhere else, and it's not something I'm compelled to check at all. I imagine the same thing happened with Secret after it stopped being the gossip platform for Silicon Valley people

<comment><USER25> > I would've never understood the appeal of these anonymous apps over > something like Reddit

Recently, we did some analysis (sensitivity, type, potential audience and linguistic characterists) on the content posted on anonymous social media like Whisper [0]. Most of the posts were about Confessions, Relationships, Meetup and QnA/Advice.

[0] [http://socialnetworks.mpi- sws.org/papers/anonymity_shades.pd...](http://socialnetworks.mpi- sws.org/papers/anonymity_shades.pdf)

<comment><USER26> I'm not sure I understood your point. You have all of this on reddit.

<comment><USER25> In Reddit, you are pseudonymous - users do convert pseudonymity to anonymity by the usage of throwaway accounts. In case of anonymous media apps, the concept of anonymity is embedded. For example, on reddit - there can be ONLY one "Barack_Obama" on Whisper there could be thousands of them because there is no unique username. In addition, you could view profile of a pseudo- identity on Reddit. On anonymous social media, there is no profile information.

The key difference between anonymous vs non-anonymous (or pseudonymous) media is lack of unique identities and/or profile information.

</comment></comment></comment></comment><comment><USER27> I've never been more addicted to an app than when Secret first came out. It was all the rage in SF. I had to force myself to delete it after a few weeks in order to get back to productivity. I completely understand the hype. Personally, I feel this is a story about poor execution. They changed the nature of the app so significantly over time that it lost its appeal and never expanded successfully beyond the bay area. Shame.....it was so much fun and they are such a talented team.

<comment><USER15> > _never expanded successfully beyond the bay area_

This seems to be something of a meme.

The Bay Area is a truly unique and bizarre place. People are incredibly busy and tech-savvy, and they're willing to spend way more on minor conveniences than people elsewhere.

It seems like lots of companies raise on their explosive growth in and around the SV community. It may extend to people with similar demographics in other cities, but it's still a niche.

I'm also thinking of all those gourmet snack-delivery companies, laundry- delivery, etc. Those might make a few million in revenue some day, but they're never going to have high margins or universal appeal.

</comment></comment><comment><USER28> From my very limited perspective from outside Silicon Valley, Secret looked almost like an exercise in Silly Valley self-parody - like an elaborate joke that went too far. Did it implode? Yeah, sure. Did it ever make sense in the first place? Not really.

pg says that great ideas often look like bad ideas. But I think it's also true that bad ideas often look like great ideas.

<comment><USER29> And that it's often hard to tell that a great idea has been poorly executed until it's too late.

</comment></comment><comment><USER30> Can we not link to TC please and use [https://medium.com/secret-den/sunset- bc18450478d5](https://medium.com/secret-den/sunset-bc18450478d5) the official link?

</comment><comment><USER31> I've used Secret several times a week since they launched. Although the most recent redesign was panned from every corner, I found it to be the best anonymous messaging UI, by far. The friendly branding and overall feel of the design put it way ahead of its competitors, IMO. I discovered that their branding was actually outsourced to these guys: [https://dribbble.com/shots/1854215-The-Secret-s- Out](https://dribbble.com/shots/1854215-The-Secret-s-Out)

I would love to see their series A and B pitch decks -- how were they able to convince investors to hand over so much cash with no serious monetization strategy and nothing more than a temporary download spike? Add that to the fact that they were able to take 6m off the table. I can't see any rational investor thinking Secret for Business was actually going to bring in revenue? Props to Mr Byttow for raising the money, building out a great product, and returning the capital when he ran out of options... Can't wait to read the post-mortem.

</comment><comment><USER32> I hit a speedbump pretty fast when they wanted me to give up my address book. Yik Yak never asked for that. Yik Yak is still on my phone. Both are kind of crappy ideas, but if there was a clear winner it was the people that just let me use the damn app.

</comment><comment><USER33> "Secret will hand its remaining cash back to investors"

Minus the $6M the founders took off the table?

If they keep it.. if ever there were a case for blacklisting founders, this is it.

It is definitely NOT cool to pull a move like that. You want to cash out early a little because you've been boostrapping, ok, but if you then bail on the company and shut it down within a year, then you start to look like a fraud who knew the company was in trouble and took advantage of investors.

<comment><USER34> 1\. What do you mean "if they take it..."? It is _their_ money. They gave away personal equity that was at the time worth $6M for the cash.

2\. It is ridiculous to assume they pulled any move. Startups are a high risk gamble and the VCs who put money in them know it better than anyone else does. So they didn't pull a move on anyone.

3\. Let's say a company raises $1M on a $3M valuation. Then in one year the valuation goes up to $300M. Would you be calling for blacklisting of those investors? Because by your logic, they should know the company was going to be so successful and should have given the founders a better deal.

<comment><USER15> I agree that there isn't necessarily anything unethical about this. The investors knew what they were doing.

However, founders who would pocket $6M from a not-even-close-to-profitable company are probably not good founders, or they don't believe in the company. Either way, their behavior doesn't inspire confidence.

<comment><USER35> I think that you are totally wrong about these founders in particular and what taking money off of the table revels about founders generally.

Most founders are extremely protective of their startup. It's their baby, and their livelihood. They'll do anything to keep it alive. Most "poor"(<$5M in the bank) would prefer a 'safe' acquisition to gambling on being a world changer. A good accusation can change a persons life forever $10M verses $100M? Who cares? Either way it's a lifetime worth of fuck-you-money. But investors what entrepreneurs to "go big." So if an investor finds a company and team that they think has a chance of making it they will give the founders fuck-you-money. It says, "ok, your safe, nothing can hurt you. Now take the chance of building a company that can change the world!"

When you see a founder take a big chunk of cash from an early round, you shouldn't think, "they don't believe in what they're doing." You should think, "These investors (who know these founders a lot better then I do) think that they are so awesome, and have such a high chance of doing something transformative, they are basically giving them enough money that they will never have to worry about money again."

<comment><USER36> Well, maybe getting an early payout caused them to lose the hustle. They turned the engine off, handed the keys back to the investors and walked. It would have been harder to shut down the company if they saw 0 upside, and all their sweat equity evaporated.

<comment><USER34> You seem to suggest that shutting the company down was _definitively_ a worse outcome for investors vs. keeping it going. It isn't that black and white. For example, if they kept the company going and spent the remaining millions and still failed(most common outcome), it is a worse outcome than shutting it down now and returning the millions.

<comment><USER36> To clarify, the outcome of any company is unknowable, as is the future of everything. When you take a look at the guys from airbnb trying to make rent selling cereal and renting out an air mattress, that's the hustle. I am just suggesting that, hypothtically, if these guys were that hungry they would do anything to save the company. I saw Byttow's interview with Kevin Rose, he seemed passionate and intelligent, I don't want to discont their work. I just think that there are some people that won't (or financially can't) quit until the repo guys carry out their office. The people with that drive have a high correlation with success.

<comment><USER37> They also have a high correlation with failure, burn-out and destroyed lives.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER38> While I have heard of Secret the majority of my friends who are still in college haven't and it's all about Yik Yak on campus right now.

<comment><USER39> Same here. I am curious as to what caused Secret to disappear so suddenly. I am not a power user of social networks but something that really struck me was the really poor UI of Secret relatively to the crystal clear interface of YikYak.

<comment><USER40> Yep agreed, same confusion here. TechCrunch seems to cite the slow response to Cyberbullying criticism as one of the reasons for Secret's downfall, but doesn't YikYak have the same problem, if not worse with college students?? What gives?

</comment></comment></comment><comment><USER41> Paging Michael O. Church to this discussion.

</comment><comment><USER42> _We curated one of the most amazingly talented teams..._

Curated! #help

</comment><comment><USER43> Good, and good riddance. Anyone who invested in Secret is a fucking moron. You can't monetize anonymous messaging, and no established company would buy technology they could build in an afternoon hackathon for the cost of a couple cases of Red Bull. If you need proof, 4chan's run at a loss for over a decade. Any investor in a VC fund that invested in Secret should sue their fund for mismanagement of money.

<comment><USER25> > You can't monetize anonymous messaging

I have always been curious about this part. What are the reasons you think one can not monetize anonymous messaging?

<comment><USER44> You can slap ads on anything. But the chance of slapping enough ads on a service to earn a multiple of a £130M valuation is pretty slim at the best of times, and when it's part of a trend of new "social" apps whose distinguishing feature is that they _don 't_ have network effects or targeting...

VCs backing startups whose primary hope of a major return is to get enough eyeballs to make Facebook nervous enough to buy them deserve to take losses more than most.

<comment><USER25> > it's part of a trend of new "social" apps whose distinguishing feature is > that they don't have network effects or targeting...

May I indulge in a bit more? In these anonymous social apps, it is made explicitly clear that you are _anonymous_ but _traceable_. It means that the service can identify your unique mobile device identity as it wishes to. You are ONLY anonymous in the eyes of the users of the app; in terms of the service provider there is NO difference.

</comment></comment></comment></comment><comment><USER45> 35 Million boggles my mind for what amounts to very simple technology. I'm a dinosaur though and compare everything to hardware start-up costs.

</comment><comment><USER46> I remember last year Techcrunch was publishing story over story about Secret, mostly as uninteresting as 'Secret app has an update and now it remembers where you left off'. And there was always someone commenting on the article 'Techcrunch stop trying to make Secret happen, it is not gonna happen.'

That artificial media boost brought users and huge expectations, but users did not stick.

</comment><comment><USER47> This is going to be used as a case study of why not to let founders take cash off the table in early rounds for years to come.

<comment><USER23> To be honest, the investors knew what they were signing at the time. If they didn't do their due diligence to figure out how the application was going to make any money, they deserve what they had coming for them. That's the kind of shitty "let's throw money out the window, in case we hit one successful startup" attitude that'll get us in a bubble.

</comment></comment><comment><USER48> "It rode the hype to massive funding, which allowed the two founders, David Byttow and Bader-Wechseler to each take $3 million off the table. They essentially traded stock for cash, putting money in their pockets though the business wasn't earning any."

Wow. I guess their round was oversubscribed so they were able to sell this to the vcs. This is the first case where I heard of where a startup failed recently after founders took significant money off the table. I wonder if vcs will be able to use this as an argument to combat founders wanting to do the same in the future.

I have mixed feelings about the whole affair but I have to hand it to the founders. That was really smart of them to take life changing money when they could.

<comment><USER49> VC's offer this deal only when they are desperate to have an entry.

So yeah some VC's may use this argument but if the startup isn't desperate its the VC who will have to make the concession.

</comment></comment><comment><USER50> I just opened secret for the first time in months(years?), and the first post was a very explicit dick pic... Seems like an appropriate send off.

</comment><comment><USER51> I still think there's a lot of room to do something interesting with social and mobile on the spectrum of Real Identity (Facebook) <\-----> "Complete" Anonymity (Whisper).

Yik Yak and After School have taken a small step to the left by focusing on specific geographic areas (schools) and that has worked well - a community centered around a shared context/life experience. Secret also took a step to the left with the "Friend" and "Friend of a Friend" concept - one which was ultimately unsuccessful, I think because it threatened to pierce the veil of anonymity, so many people didn't feel safe posting their real "scandalous" content.

And of course with all of the anonymous apps you have the problem of bad behavior. So far we've seen community solutions to this (flagging, downvoting, karma - like here, Reddit, Yik Yak) and company solutions (moderating with 100 people in the Philippines, like Secret and Whisper - [http://www.wired.com/2014/10/content- moderation/](http://www.wired.com/2014/10/content-moderation/)). It would be interesting to think if there might be others.

So the current "anonymish" apps have started from the right (anonymous by default) and either stayed there or moved to the left a bit. One of the things I've been thinking about recently is what would happen if you started from the left (Real Identity/FB) and moved to the right? Would the outcome be any better? I'm actually going to try it out and see with a new mobile app I've been working on - [http://www.IAmOffTheClock.com](http://www.IAmOffTheClock.com)

And as for them taking money off the table in their funding round - good for them. They weighed their offers and took one that eliminated their risk while giving the company enough cash to grow and still giving them a chance for a big payday. If Secret had hit it big, that would have been a very expensive $3M they took off the table. Investors wanted more stock, founders wanted some small amount of liquidity, and at the time everybody was happy, everyone believed, the graphs were all up and to the right, and nobody had a perfect crystal ball.

</comment><comment><USER52> I stopped using it when they changed the app design to what it currently is. I loved it when it was a picture app.

</comment><comment><USER53> It's hard to build a business on negativity when that negativity is directed at your own users. People like gossip but not when it's about them.

</comment><comment><USER54> I hope that Ping [0], a side project by the Secret team that has nothing to do with Secret itself, is going to stick around in some capacity. I loved the little knowledge bits that it sent me randomly. I just checked the app and other than a couple weather notifications, the last curated content was pushed to me 2 weeks ago :(

[0]: [http://iamping.com/](http://iamping.com/)

</comment><comment><USER55> I've a question! Maybe totally unrelated, but isn't it always a bad sign when founders sell their shares before even reaching 1 year?

Doesn't that put a red flag on how the investors should look into it? Or it's just the hype & hockey stick presentations that doesn't matter to some investors?

</comment><comment><USER56> Well in the last few months activities in the app was similar to omegle.

People posting nude photos and stuff.

I think the curation of content was a huge challenge for them., and also not to mention the new app design was not at all intuitive with lots and lots of bugs.

But having said that, I had lot of hope in this app.

</comment><comment><USER57> Can we speculate as to the timing of this with the DoD marriage with VC firms and investment groups in Silicon Valley, or is that too conspiratorial?

</comment><comment><USER58> So, what can one develop using this beside "hello, world?"

Can I build a cross platform GUI application? Is there a servlet container? How about an IDE?

</comment><comment><USER59> The founder pretends that the investors have put money on the table to build a great team and a great product. If the problem resides in the product, I think pivoting is the least they can do in respect of their investors.

Giving back the money is ridiculous, especially when they pretend to be guided by the motto "Innovation requires failure".

<comment><USER60> In the article, it says they made this decision after much discussion with the board. The board is the investors, so the investors are probably OK with this.

It's likely the investors were investing in "the next big social network". When it became clear that this wasn't going to be successful, they were faced with the choice of get 80% of their money back, or to "invest" (as it were) that money in the remaining team.

Maybe the remaining team had an idea, but the investor didnt want to invest in that idea. Or maybe the team was tired and didn't want to continue, and the investor would prefer their money back then try to force the team to continue.

</comment></comment><comment><USER61> I wonder how long it will take to leak their data, spec those associated with facebook logins.Not surprised that they failed, it had plenty negative and offending posts and no cats/burgers/porn.

</comment><comment><USER62> I've only ever heard bad things of that team.

Arrogant, mean, shameless...

I'm happy to see that this happens, when they cloned yik yak it was one of the most pathetic moves I have ever witnessed in the silicon valley

</comment><comment><USER63> Can someone explain to me why people return money to investors?

Legal reasons? Altruistic reasons? Selfish reasons (maybe that keeping it would hurt their reputation and make them feel guilty)?

<comment><USER64> One reason is when the investors own > 50%, control the board, and decide to recoup 10 cents on their dollar.

But I've known entrepreneurs who made the decision independently, feeling it was the right thing to do.

And it is the right thing to do if the company has no other prospects or the team is falling apart.

But even so, returning the balance just keeps some salt from the wound. It doesn't make anybody happy.

<comment><USER63> > And it is the right thing to do if the company has no other prospects or the > team is falling apart.

Why do you say that? If for moral/altruistic reasons, that doesn't make sense to me - if you have $x million, do you really think the best place to donate it would be to VCs? I don't know anyone who donates to VCs, so I assume the answer is no. (sorry if I come off as harsh, I don't mean to - I just don't know how else to put it)

<comment><USER65> _you_ don't have $x million. The company you founded, and no longer wholly own has $x million. It's a rather different thing.

I mean, unless you are talking about the money for the personal shares the founders sold, the money, as it was said, that they "took off the table" \- if that's the case, then I'm completely with you (but I didn't see any indication that they were giving that money back.)

<comment><USER63> I was under the impression that someone had _decided_ to give the money back to the investors. That they had a choice, presumably, to do what they want with it. Is that not true? To what extent were they restricted?

<comment><USER65> that depends on who controls the company, something that usually has to do with ownership percentages, something that wasn't revealed in the article.

The thing is, though, even when you control the majority of the company you do have some legal and ethical obligations to the minority shareholders.

<comment><USER63> I see. Well, my point applies to any situation where someone does have the freedom to do what they want with (a large chunk of) money, and chooses to give that money to a VC, rather than, say donating it to an effective charity. Am I the only one who sees something wrong with that?

<comment><USER65> that seems like an astonishingly unlikely situation.

<comment><USER63> Maybe. It's just that I hear of stories that talk about founders giving money back to the investors as if it were admirable. Admirable implies that a decision was made. But maybe I'm just misinterpreting.

<comment><USER65> _removed regrettable bit_ \- but he or she is right about the options; ethically and legally, they could have continued to try to make it work, or they could shut down the company, sell the assets and distribute the proceeds to the creditors and then the owners of the company (the investors)

Really, one could ethically do either one of those things; it's just that depending on the situation and your perspective, well, probably one or the other is the better choice.

Now you seem to be arguing that the choice between continuing to run a company or not is not one that has an 'admirable' option. And maybe from you point of view, it doesn't really matter.

There's a stadium down the way from my house. when the football player makes a home run or whatever, well, personally, I don't see how that matters; I don't care, and I'm mildly pissed that I'm going to have to pay for the bonds to build the eyesore. But even so? I don't go to football forms and tell people that the large man getting the ball in the hole or whatever isn't an admirable achievement. It's the game those people want to play, and that's fine.

I personally find business really interesting, really in a similar way to the football fan. Most of this stuff doesn't really matter. Some of it does, but even that stuff doesn't matter as much as people say it does.

To me? the decision to give the money back to the founders, rather than shitting the money away when you know you have been beaten, is admirable because investors seem to select for overconfidence; quitting before you've spent every cent implies that you were able to project that overconfidence to the investors, but that you were able to remain a rational person.

I mean, it's not world peace, sure, but it implies some attributes which within the context of the business game are pretty important.

<comment><USER66> I guess I just clicked the wrong button. Not really sure how that makes me an ass. Thanks though.

[http://blog.ycombinator.com/new-hacker-news- guideline](http://blog.ycombinator.com/new-hacker-news-guideline)

<comment><USER65> I meant no real insult. I was having a shallow conversation with a troll, I was repeating something someone else said, and misjudged the tone.

You want me to delete/edit my previous post? there, I did; I'm not sure if that's more appropriate or less.

You make a good point with the guidelines; I'm far too cynical and negative to participate in these sorts of discussions with this sort of a community.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER67> What were some of the key contributions from Secret to wider culture?

Was it — Julie Ann Horvath's decision to disclose big cultural problems at the company GitHub?

Was there anything else?

</comment><comment><USER68> Secret is probably a very successful social experiment.

</comment><comment><USER69> feelings.blackfriday is still up though

</comment><comment><USER70> How much do Unicorn horns fetch on the black market?

<comment><USER71> Pound for pound, about the same as black swan foie gras.

</comment></comment><comment><USER72> I certainly don't think this is the end. Was writing a comment but decided I will post it on my blog [https://blog.scrape.it/secret-shutting-down-isnt-the- end](https://blog.scrape.it/secret-shutting-down-isnt-the-end)

</comment><comment><USER73> nooooooooooooo

</comment><comment><USER74> I knew day one the idea and execution was going to fail.

<comment><USER75> You could say this about every single startup, and you'd be right 99.9% of the time. The other 0.1% you'd find a way to make yourself right.

It's a really, really silly thing to say.</comment></comment>