Ask HN: Payment processing within my app, without losing (too much) money? - <AUTHOR>

Example: Let's say I'm building a show/exhibition management app, allowing you to manage floor space, exhibitors, course participant registration, etc. To register a booth, a potential exhibitor will have to pay a fixed amount of money, let's say $100 for simplicity's sake. Except that with each payment, I as the service provider will lose n% of that payment in processing fees, depending on which payment gateway (Paypal or otherwise) I choose. Which results in me not being able to pay my app's customers the full amount due to them. The same scenario comes up for the show participants' payments, if I want to have that billing process administrated through my app, too.<p>So my question is, do I just tack on the % as a service fee to my customers, resulting in my customers only receiving, say, $95 instead of the $100 for booth registration? Or are there other ways to tackle this issue? <comment><USER2> A friend of mine has a similar type of software where he is somewhat of a middle man. He charges the company $x base + y% of the transaction. His customer is required to have their own merchant account and his service just processes through their merchant account. The $100 would never run through his account.

Depending on the nature of your business, another idea would be to charge a convenience fee to the exhibitor, but having exhibited at tradeshows for many year I would find that annoying. However, it wouldn't stop me from exhibiting. Annoyances are par for the course for anyone who has ever exhibited at a tradeshow managed by someone like Freeman.

If a customer is shocked that they will only receive $95 of a $100 transaction for the value you add, then it may be time to re-evaluate how you communicate your value or find a new customer.

</comment><comment><USER3> Sorry my coffee hasn't kicked in yet, but I am a little confused here. How do you intend to make money on your app or is this a free service?

If your app is a paid service service, then you have two choices. First you can build in the processing fees to your monthly fee (or however you plan to charge). You can base your fee on the expected number of registrations and go from there. The other choice would be to charge an administrative fee on top of each registration to the exhibitor or participant. The problem with this method is that if I am an exhibitor why am I going to pay $X through your service versus going directly to the show and paying $Y?

Short answer is that you somehow need to build the cost of the payment processing into your pricing. Whether that is through an added administrative fee or built into your monthly pricing.

<comment><AUTHOR> Sorry, I should have mentioned that this will be a paid service, billed monthly. I wanted to come up with a tiered, flat fee, except that won't work with the above scenario. If I price my app at, say, $100 per month, the minute one paying client's in-app processing fees cost more than that, I'm losing money.

I suppose I could bill my customers the incurred fees at the end of each billing cycle, but that would probably put off some customers, as they would be left scratching their heads as to why they have to pay $100 per month, then get ANOTHER bill for fees.

<comment><USER3> If that is the case I would build the tiered pricing based on the number of exhibitors (or participants) each tier can handle. You should be able to closely estimate what your processing fees are going to be for a set number of registrations. The problem with this method is that some of your customers will most likely be purchasing tiers that are out of line with their registrations. For example if you have 3 tiers: one tier for 100 exhibitors, one for 500, and one for 1000, then your customers will be bound to registering for tiers that may be out of line with the number of exhibitors they plan on having. You may be able to offset this a little two ways. First if you know your target market well enough that you know approximately how many exhibitors are at each conference you could plan your tiers based on those numbers. The other way, although it requires development on your behalf, but is a little more customer friendly, would be to do away with tiered pricing, and build a cost estimator into your app. Your customers could come to the site, fill out all the information including an estimate of number of exhibitors they will have, then your app would give them an estimate of the cost. You verify their payment for the estimated registrations, but do not charge them at this point, then when all the exhibitors have registered, you bill them based on their actual number of registrations.

</comment></comment></comment><comment><USER4> Well how do you make money? At some point you have to be charging more than they are receiving, right?</comment>


Linear types are merged in GHC - <AUTHOR> https://www.tweag.io/blog/2020-06-19-linear-types-merged <comment><USER2> Incredible work, congrats, the evolution of GHC is quite impressive. A better description of what linear types can be useful for is at [https://www.tweag.io/blog/2017-03-13-linear- types/](https://www.tweag.io/blog/2017-03-13-linear-types/).

<comment><USER3> > the linear arrow says this: a function that has type A⊸BA⊸B is a function > that has an AA available to compute with, but it can only use it once. Not > twice, not zero times: just once.

Superficially this sounds a lot like Rust's FnOnce. Is there a relation there?

Edit: Actually it sounds like linear functions are more about using their _arguments_ once, internally, as opposed to themselves being _called_ once. So perhaps not. Still would appreciate any further commentary by someone with a better grasp on things than I have.

<comment><USER4> Rust's ownership system has Affine types (types which must be used 0 or 1 times), which are indeed closely related to Linear types, which must be used exactly once.

Types marked with `#[must_use]` in Rust are pretty close to linear types. But must_use is a lint rather than being integrated with the type system.

See also: [https://gankra.github.io/blah/linear- rust/](https://gankra.github.io/blah/linear-rust/)

<comment><USER5> > Types marked with `#[must_use]` in Rust are pretty close to linear types. > But must_use is a lint rather than being integrated with the type system.

An other issue with must_use is that it just requires use not "consumption" of the value, so if, say, you print it the lint is satisfied. Meaning it's an issue for resources you'd want to be linear e.g. resources which really should be explicitly terminated because the termination can fail.

<comment><USER6> Uh so how do you debug linearly typed code if you can't log values? Or does ghc allow to cheat?

<comment><USER5> I don't know if GHC provides either, but either a borrowing or a dup feature would handle that (the latter would probably count as "cheat"). There may be other ways as well.

Since linear types are a separate opt-in feature you'd probably need (as far as I understand) you'd need separate printers anyway, so you could probably "cheat" them in. Though I think the sort of structures you'd want to be linear would generally not be amenable to print-debugging anyway.

</comment></comment></comment></comment></comment></comment><comment><USER7> Note that the focus here is to make it safe to have mutable data around, not to have manual memory management.

Next up I hope:

      - https://www.youtube.com/watch?v=0jI-AlWEwYI
        https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md

<comment><USER8> I think for people who need absolute performance, manual memory management seems inevitable. No amount of GC tuning or hacks (such as the wonderful compact regions) would be satisfactory.

This enables more kinds of programs to be written in Haskell, whereas your day-to-day typical server programs can just use GC as they currently do.

<comment><USER9> If one needs absolute performance, then their only option is bare metal, as the OS can also induce every kind of delay, including RTOS, so manual == performance goes a long way until it is actually true.

<comment><USER10> There's a pretty wide area between the current situation and completely bare metal, a gap wide enough to fit the vast majority of performance sensitive applications today. It's not like you have to stop at bare metal either in a world as the hardware can introduce some latency on its own. You really need an FPGA or ASIC to take this to its logical conclusion.

<comment><USER9> Just like exists a gap between allocating memory like crazy, and taking care where it is allocated from, and what kind of data structures are used before assuming that malloc()/free() are faster than the alternatives without taking into consideration what happens between calling them and the kernel round-trip that takes place.

So, while Haskell isn't D or Nim, there also also more than just one way to allocate memory when performance fine tuning is called for.

And yes, in Fintech that is exactly what they do, reach out for FPGAs and measure cable lengths as well, while on high integrity computing all allocations are static, either at compile time or as part of the application startup, nothing else is allowed.

</comment></comment></comment></comment></comment><comment><USER11> This has been bugging me for a while: Why are type names what they are? I get why sum types and product types are named what they are.

But linear types? A value can be used only once? Cool. We call that "linearity"? Um, what? What's _linear_ about that?

<comment><USER12> Vector spaces and linear maps between them form a model of the linearly-typed lambda calculus. That is, each type can be interpreted as a vector space, with each well-typed term representing a linear map between vector spaces.

1\. The linear tensor product A ⊗ B gets interpreted as the tensor product of vector spaces.

2\. The linear function space A ⊸ B gets interpreted as the vector space of linear functions between A and B.

3\. The Cartesian product A × B gets interpreted as the direct product of vector spaces (i.e., the categorical product).

4\. The sum type A + B gets interpreted as the direct sum of vector spaces (i.e., the categorical coproduct).

5\. The exponential !A gets interpreted by the Fock space construction.

This explains why the choice of name is sensible, but I don't actually know if that was the reason why Jean-Yves Girard named it so. If memory serves, he invented linear logic after thinking about Berry's notion of stable functions, but I don't know for sure when the vector space model was invented. (It's not in his 1987 paper, but it can't have appeared very long after that.)

<comment><USER13> Are vector spaces really the right category? In particular the product and coproduct of vector spaces are isomorphic (both isomorphic to the direct sum).

<comment><USER14> It depends on what you mean by right category. It is true that vector spaces identify certain constructs that linear logic distinguishes, but it doesn't identify everything so it still has some interesting content. Finding models that don't make unnecessary identifications is one of main lines of research in the field.

</comment></comment></comment></comment><comment><USER15> The proposal is described here:

[https://github.com/ghc-proposals/ghc- proposals/pull/111](https://github.com/ghc-proposals/ghc-proposals/pull/111)

</comment><comment><USER16> I wanted to try this out, but getting nightly GHC was a bit harder than expected. Threw up a repo on how to set up nightly binary on buster and compile with -XLinearTypes:

[https://github.com/rjeli/hs-linear-example](https://github.com/rjeli/hs- linear-example)

</comment><comment><USER17> Awesome! Very impressive work! I can't wait until the kinks are ironed out and we start seeing resource management APIs using this.

It surprised me how useful Rust's affine types were for resource management APIs, so I'm sure we'll see some cool applications in Haskell.

</comment><comment><USER18> I hope they implement this in Agda as well.

<comment><USER19> Actually I wonder if its not already possible to implement it since it has had levels of universes for quite a while. Is that, with dependent types, not powerful enough?

<comment><USER18> I remember asking this question on agda subreddit a while ago (maybe 3 years ago? I don't know) and they told me it's not possible. However, they implemented Cubical type theory and a few other stuff (universe levels? Has it been implemented last couple years?) so maybe it's possible now.m

I love doing algebra proofs with agda as a hobby but I'm by no means, even remotely, experienced in everything agda capable of.

</comment></comment></comment><comment><USER20> Awesome work!

I still kind of wish that something RAII-like that is safe in the presence of exceptions and & types had made it in. But considering the immense amounts of work and effort that this has taken adding some more sweeping changes is somewhat of a pipedream.

The current version definitely looks practically useful, though kinda awkward given the syntax and polymorphism restrictions.

</comment><comment><USER21> Wow very cool stuff. I'm wondering if these ideas could be integrated into the rust type system.

<comment><USER22> It's unclear if Rust can ever get linear types: [https://gankra.github.io/blah/linear- rust/](https://gankra.github.io/blah/linear-rust/)

<comment><USER23> FWIW, from having built types like this in C++ before, the thought process at the end of how to handle assignment feels better to me to implement where instead of assigning Some(step1()) directly to token, you construct a new value and then "swap" (which is a C++ concept that is supposed to be guaranteed noexcept) the token variable and the value variable; you then would have until the end of the scope to call some function that asserts the value is None. Regardless, I agree with footnote 3: if you want to claim that linearity is somehow a bad default, then you should take a long hard look at move-only... but I like move-only, and I like linearity! ;P FWIW, I don't think this is that hard: require all values to be forgotten, allow types to provide deconstructors called on unwind / scope exit, require that deconstructor to eat the value, and if a type doesn't have a deconstructor then the user has to eat the value (and you get all the cool behavior of not being able to hold it across a panic without having some way to guarantee it will get eaten, such as by holding it in a container that has a deconstructor that will eat it). This would be _epic_ and would be a pretty awesome sell to get me on Rust ASAP despite the devastating decision to not have implicit error propagation ;P. Like, seriously: I have way more concerns about linearity issues in my codebase--ensuring proper deconstruction of non-memory resources in an asynchronous context (which is where this gets hard)--than I do with my memory correctness... I can't begin to explain how much time I have spent over the past two months chasing deadlocks or premature synchronous deconstruction of an object that absolutely _must_ deconstruct synchronously... I have these "deconstructor bombs" (as mentioned in this article as supposedly an ok solution: no, they really really suck...) throughout my codebase, but I have found it infuriating to come up with rigorous local heuristics to ensure that everything always gets closed in the right asynchronous context :( and so I would be willing to jump through almost any hurdle to use a language that could simultaneously promise me tight memory usage (which sadly Haskell isn't great at, due to its garbage collector, but I am going to seriously look at it again I guess?) and linear types (preferably universally, similar to focusing on movable types).

<comment><USER5> > FWIW, from having built types like this in C++ before, the thought process > at the end of how to handle assignment feels better to me to implement where > instead of assigning Some(step1()) directly to token, you construct a new > value and then "swap" (which is a C++ concept that is supposed to be > guaranteed noexcept) the token variable and the value variable; you then > would have until the end of the scope to call some function that asserts the > value is None.

For this specific case Rust has mem::swap and Option::replace (though the essay probably predates the latter), however the essay really seems to be using this as just an example of entire rust constructs becoming impossible to use, and / or having to be replaced by significantly less convenient ones e.g. every reassignment having to become a mem::swap + a check means a single-line statement becomes 3 different statements (possibly a utility function implementing that).

> require that deconstructor to eat the value, and if a type doesn't have a > deconstructor then the user has to eat the value

But the point of the panic issue is that the user can't consume the value in that case isn't it? Though I don't understand why gankro didn't mention the option of a fallback `Drop` for use during unwinding (which would probably default to a deconstructor bomb).

> I can't begin to explain how much time I have spent over the past two months > chasing deadlocks or premature synchronous deconstruction of an object that > absolutely must deconstruct synchronously…

That's already the case for Rust? Drop always occurs at end-scope at most.

Moving objects to other threads in order to free them asynchronously is a specific pattern (mostly useful for large collections of heap-allocated objects), I don't think it's something Rust will ever do for you as much of the language relies on RAII, which itself relies on synchronous destruction.

> I have these "deconstructor bombs" (as mentioned in this article as > supposedly an ok solution: no, they really really suck...)

Note that they're only mentioned as a solution for unwinding affecting a linear value, because panic can be recovered from. Essentially the deconstructor bomb would be as if every linear type had an implicit Drop which panics: drop would never be invoked during "normal" explicit deconstruction, and a double panic (panicing during unwinding) is already an abort.

<comment><USER23> > or this specific case Rust has mem::swap and Option::replace (though the > essay probably predates the latter), however the essay really seems to be > using this as just an example of entire rust constructs becoming impossible > to use, and / or having to be replaced by significantly less convenient ones > e.g. every reassignment having to become a mem::swap + a check means a > single-line statement becomes 3 different statements (possibly a utility > function implementing that).

I am trying to explain why the semantics of this way of doing the replacement is cleaner and requires less weird special cases in the code (such as this object that is temporarily dead and suddenly revived) than the way in the article (which I see as a strawman designed to make me dislike linear types).

> But the point of the panic issue is that the user can't consume the value in > that case isn't it? Though I don't understand why gankro didn't mention the > option of a fallback `Drop` for use during unwinding (which would probably > default to a deconstructor bomb).

The whole point of linear types is to make it so that this is a compile-time error, so I don't really understand your objection. If it helps, I will try this in a different tense: if the type doesn't (in the continual sense) manage to provide a deconstructor which eats the object (and could be used on unwind), then either the user _had to have_ (in the past tense) or the code didn't (in the past tense) compile if there were (at the time of compile) any codepaths without nothrow that could cause such an unwind.

> > I can't begin to explain how much time I have spent over the past two > months chasing deadlocks or premature synchronous deconstruction of an > object that absolutely must deconstruct synchronously…

> That's already the case for Rust? Drop always occurs at end-scope at most.

I think I lost an "a-" there, so I'm hoping that if I said "must deconstruct asynchronously" this makes more sense? Otherwise I'm reading the rest of your message as actually kind of insulting my intelligence a bit (that's ok ;P I don't feel particularly intelligent today anyway ;P), so I'm going to assume this missing "a" was a serious problem and kind of shift the discussion to focusing back on the problem statement instead of trying to address any of it directly.

So, I've been doing C++ development since before it was standardized, which I note only to make it clear that I am _so painfully_ fully bought into RAII that I can't even begin to describe how poor my mental opinion of manual management of anything is at this point. With such background, I'm also mostly working on distributed systems that aren't just multi-threaded but are also multi-machine. That said, I don't want this to sound like some complex corner case: most of my actual code is simple stuff like "I want to do API calls using HTTPS" or like "I want to build a VPN/proxy". (Notably, I have spent a lot of time also coding such systems in Erlang.)

I thereby end up in situations where I'm simultaneously dealing (but never "handling" if I can possibly avoid it) weird distributed error cases (and thereby am somewhat dissatisfied with Rust having adopted the data structure from systems that use monads for error handling without the actual syntax part that makes that awesome while simultaneously attempting to claim that exceptions are somehow any less "monadic", when they are just the syntax part without the data structure; so like, neither expose the monad, but Rust forces me to reify it constantly... but I semi-digress).

The issue is then when you are dealing with all three of what should be monads in a more powerful language at the same time: error propagation (whether manually by way of Maybe types or automated by exception/panic), deterministic finalization (RIAA, which isn't often described as a monad but definitely is one), and asynchronous execution (without threads). You are thereby inside of an asynchronous function (which in both Rust/C++ you have to manage manually using async/await) and need deterministic finalization (which in both Rust/C++ you can have automated using deconstructors), and yet errors can happen (which makes the problem obvious _but is not at all requires for the problem to happen_ ).

As a basic example, you finish your SSL request, and now need to deconstruct the SSL connection, which means you want to close the socket... only no, you first need to do an asynchronous SSL CloseNotify, so you have to await that behavior before you allow that socket object to deconstruct. If you let the object deconstruct before you await the CloseNotify, you haven't really completed the protocol. This is also a great case, as while HTTP itself mitigates this (and even in my system I eventually decided to just close this socket by force), you aren't really supposed to trust where the end of the data you got from the server is (and so in the abstract thought process you can't really return from this function until you've finished this CloseNotify; this means that trying to fire-and-forget this to a background thread--which is essentially the analogy of garbage collection--is not a valid solution).

I thereby end up with abstractions that look like an asynchronous "using" statement for that case, to prevent me from constructing the object without showing that I'll asynchronously deconstruct it, and I have primitives now for the cases where it _is_ safe to shift to another thread (these are generally cases where I already had a shared pointer to something needing this behavior), or the case where it is primarily (and permanently) owned by another object (though this only half-solves the problem as the order of operations hasn't generalized yet)... and I've set it up so you have to explicitly say "I know what I'm doing" by mixing in another subclass in order to instantiate this object at all outside of one of my more "guaranteed" mechanisms, and yet the problem remains, and is just _all over_ anything that involves networking: you have to be able to guarantee that you have completed asynchronous deconstruction of the object (which might fail! this makes the whole problem harder, but doesn't really change its character at all) before allowing a synchronous deconstruction.

I have seen attempts in both the Rust and C++ communities to then define what an "asynchronous deconstructor" would look like (fwiw, the C++ one looks a lot better), but they frankly all miss the mark (and lead to other soundness issues, which is why they are stuck in design phases and when they come out will likely have tons of compromises... the Rust proposal doesn't even look truly asynchronous) as the core problem here is really one that comes down to linear types: you need to guarantee that the object's lifetime doesn't end--at compile time, or you are just throwing deconstructor bombs at the problem-- before you've finished its asynchronous deconstructor "somehow" (and that can be by any number of techniques, and is all up to the developer).

And then, as I noted: this has been the #1 source of subtle bugs in the systems that I build, as this is essentially "fearless concurrency" taken to the extreme of "fearless networking" (though to really approach that you have to have a serious conversation about "what is an error, anyway?" that I'm not sure the Rust community will ever accept ;P). So yeah, like: it is super disappointing to hear that Rust might just never end up with linear typing because I guess people understand the need for it about as little as C++ programmers appreciate the need for lifetime analysis (which is ironically in a design space very related to linear types, and why I'd expect that if I go to all that trouble I'd also be given a solution to my asynchronous deconstructor problem that didn't involve deconstructor bombs; like, I will again say that I _loved_ that footnote #3 ;P).

<comment><USER5> > I am trying to explain why the semantics of this way of doing the > replacement is cleaner and requires less weird special cases in the code > (such as this object that is temporarily dead and suddenly revived) than the > way in the article (which I see as a strawman designed to make me dislike > linear types).

I've always read that article as exposing linear types as more complicated than just slapping a attribute, at least within the context of Rust, but it might just be a naive view of it.

> The whole point of linear types is to make it so that this is a compile-time > error, so I don't really understand your objection. If it helps, I will try > this in a different tense: if the type doesn't (in the continual sense) > manage to provide a deconstructor which eats the object (and could be used > on unwind), then either the user had to have (in the past tense) or the code > didn't (in the past tense) compile if there were (at the time of compile) > any codepaths without nothrow that could cause such an unwind.

But the point of using linear types is that there are constrains which the normal drop does not fulfil or allow for e.g. the deconstruction is failible, or requires additional data, or (as seems to be your case) needs to be moved off-thread. _During_ an unwind, these things are not guarantee or even available at all (how would unwinding know what parameters to provide? How can it report errors to a caller which doesn't exist?). Otherwise the regular Drop would work fine.

> I think I lost an "a-" there, so I'm hoping that if I said "must deconstruct > asynchronously" this makes more sense?

It does make a lot more sense yes.

> As a basic example, you finish your SSL request, and now need to deconstruct > the SSL connection, which means you want to close the socket... only no, you > first need to do an asynchronous SSL CloseNotify, so you have to await that > behavior before you allow that socket object to deconstruct. If you let the > object deconstruct before you await the CloseNotify, you haven't really > completed the protocol. This is also a great case, as while HTTP itself > mitigates this (and even in my system I eventually decided to just close > this socket by force), you aren't really supposed to trust where the end of > the data you got from the server is (and so in the abstract thought process > you can't really return from this function until you've finished this > CloseNotify; this means that trying to fire-and-forget this to a background > thread--which is essentially the analogy of garbage collection--is not a > valid solution).

Ah I see, even in the original I think I'd have misunderstood what you meant by _asynchronous_ deconstruction because I wasn't thinking of the "async" context when I read your comment.

Anyway thanks for the expounding on your issues and their relevance to linear typing.

</comment></comment></comment></comment></comment></comment><comment><USER24> I am pessimistic about this one, but we'll see.

<comment><USER25> It's obviously ok to be pessimistic, but at least explain why.

Do you think the feature is not going to be very useful in a practical setting?

Do you fear people are going to use it all over the place in libraries and make life harder for their users?

Is there something wrong with this feature in a theoretically basis. Does it need more thought?

Do you think the implementation is broken or not finished? Does it need more work?

Something else?

<comment><USER24> Yes to almost all of that. The proposal process has exhausted me, but I suppose I will write it again, since your questions there serve as excellent section headings :).

> Do you think the feature is not going to be very useful in a practical > setting?

Yes. For one example, you cannot write anything like `malloc :: Word -> LinearPtr Void`. With, `malloc :: Word -o Ptr Void`, since Word is not duplicable, `Ptr Void` would be. The "solution" is to CPS everything, which is pointed out in the paper and they say it's OK cause some big honking monad can take care of that, but I don't buy it, and I don't believe in "zomg all the effects" monads either.

Haskell is supposed to lead they way with type system features, but I think we are the ignorant followers on this one (At least Go outsourced generics!!). There's so much that can be learned from Rust, and yet I don't think this feature learns those lessons. In particular, anyone that spent any time with Rust would realize that borrowing / borrow checking is super important for making something actually usable.

Unfortunately, regions/lifetimes are far less studied theoretically! So the first step would be not making some linear proposal that cherry-picks theory to make for an easier implementation, but go back to the ivory tower and figure out what the hell this borrow checking is and how to understand it better.

> Do you fear people are going to use it all over the place in libraries and > make life harder for their users?

Yes, it is a fact that lot of Haskell users are magpies driven by boredom with the rest of the industry. That's certainly how I was when starting Haskell! I think there is a tendency to be attracted to shiny new features and have fun with them, which is fine itself. But this will lead to a bunch of PRs to all the core libraries, which is understandable too, since no feature works except for at scale.

However, if this proves to be a bad feature as I fear, then we will be left with a bunch of newly-complicated core libraries on this debt-end route. And no language ecosystem I know I think has a good story for deprecating and cleaning up failed experiments in a timely matter. I think we are just too small and disorganized a community to risk our ecosystem like this.

> Is there something wrong with this feature in a theoretically basis. Does it > need more thought?

Yes, I think linear types should be a separate kind, like runtime reps. Right now there is just a linear arrow with normal types. If you recall the relationship between --> in the language and |- in the meta language, it feels to me that the meta language has no kept up.

I really do believe more in affine types, but think linearity is useful for fixing Rust's Drop to be a dual to Copy and Clone (Types are linear by default, you can right a designated destructor (like Clone) for RAII, or furthermore (in some cases) use a built-in special no-opt destructor (like Copy).

[https://arxiv.org/abs/1803.02796](https://arxiv.org/abs/1803.02796) is a paper from the OCaml community that I think is on much better footing.

> Do you think the implementation is broken or not finished? Does it need more > work?

No. I haven't looked at the implementation but this doesn't worry me as much. I think the features were chosen to make an implementation without even more effort tractable---I'm sympathetic as it's enough work as it is and I do commend Tweag for marshaling the resources for our commons at this scale even though I do not agree with what is actually being done. Cleaning up GHC is easier than cleaning up the library ecosystem, and in this case a smaller implementation helps.

</comment></comment></comment><comment><USER9> Love it, the productivity of tracing GC with the tools to do more fine grained resource management when needed, congratulations!

</comment><comment><USER26> Is there a short and simple explanation, for what "linear types" are?

</comment><comment><USER27> GHC?

<comment><USER28> A Haskell compiler whose implementation of Haskell has essentially become the language itself. They add lots of experimental features for their users to play around with, such as linear types it would seem. Language extensions like this might make it into the official language, but probably not. I'd say don't use it in production, but if you're using Haskell, you're probably an academic, hobbyist, or mad scientist.

<comment><USER27> To be honest I was 80% sure it was Haskell but I do hate acronyms being used without sufficient context for the average reader to understand them. The post should have had the word "Haskell" in it. It certainly helps understand what "linear types" probably means.</comment></comment></comment>


Tackling Inequality in Gifted-And-Talented Programs - <AUTHOR> https://www.theatlantic.com/education/archive/2015/09/inequality-gifted-programs-schools-testing/405013/?single_page=true <comment><AUTHOR> tl;dr After the Houston school district introduced universal IQ testing for 2nd graders, the number of minority and low-income students in gifted programs went up significantly (without changing the admission standards of those programs).</comment>


Kickstarter project for $100 - 1 kW - stirling engine - <AUTHOR> http://www.kickstarter.com/projects/672465444/low-cost-sterling-engine?ref=live <comment><USER2> Yes gas is near $4 - what does that have to do with utility prices, since there aren't any gasoline powered plants in the USA since the 70s ?

I would have to assume the way the utility company produces power is far more efficient than a town with thousands of mini-engines. Only stuff like solar cells work better in distribution.

Not sure how this would work either - what fuel are you going to use to power it for 24 hours without maintaining it? Will it drive an alternator to power an inverter? How stable would the feed be?

<comment><USER3> A huge amount of the generated electricity is lost on resistance of the power lines on the way to your house. So having it in your basement and going 30 feet to a lamp/outlet would be more efficient.

<comment><USER4> According to wikipedia, the average loss on the power lines is 7%. Source:

[https://en.wikipedia.org/wiki/Electric_power_transmission#Lo...](https://en.wikipedia.org/wiki/Electric_power_transmission#Losses)

That's not what I'd call "huge".

</comment></comment></comment><comment><USER5> Looks like a cool project.

One note to entrepreneurs using Kickstarter, or creating any slide presentation for potential investors: Take the time to spell check your slides.

Tim Sefton (creator of this project), if you happen to be reading this, here are some notes that may help you make your presentation more professional...

"One thing.. The Sterling engine is about 10% more efficent then the gasoline engine, but strugles with changes in suden acceleration - like what is needed for cars."

If you are the author of the presentation, you may want to correct the four errors: efficient, than, struggles, and sudden. Also misspelled is "temperature" (on the previous slide),

Not a big deal to me, but some potential investors will absolutely be turned off by that.

<comment><USER6> Not to mention it's "Stirling", and not "Sterling".

<comment><USER7> This. Maybe it's just because I am a web designer and lover of the English language, but when a company's blog URL looks like this: <http://volodesigns- sterlingproject.blogspot.com/>

a) free site b) a dash? c) mispelled stirling?

I get just a tad anxious.

</comment></comment></comment><comment><USER8> _"Well the average US household uses about 8,900KWH of electricity per year - that comes down to 24 KWH per day and so our goal is to have a minimum engine output of 1KW so that it can produce close to the average home use of electrical power per day (24 hours of 1 KW output give you 24KWH)."_

This math isn't taking into account that the power use isn't consistent, batteries will be needed to handle the variances in consumption. You'll never get 100% efficiency from power storage so the amount needed per day is much higher.

I also didn't see anything about the temperature required to make this run. Does this go on a roof or do they expect me to keep this in the fireplace the whole time.

<comment><USER9> _You'll never get 100% efficiency from power storage so the amount needed per day is much higher._

Lead acid batteries are 85-95% efficient for getting power in and back out. It doesn't change your sizing much.

That said, until a significant percentage of the utility's customers are using these devices, it makes no sense to use batteries. Just sell surpluses to the grid and buy back to handle peaks.

If you have no grid, then about $1000 of batteries will cover you, and need replacing every 5-10 years. Either way, your inverter is probably around $2000.

I'd have already clicked to buy in, except there is a missing chunk of the efficiency. Assuming I don't have a small lava flow next to a stream in my basement, what is the total projected efficiency of these units from fuel to electrical energy? They don't seem to be addressing burner efficiency. How will it compare to a small gasoline powered generator? (You can't buy a diesel genset this small.)

<comment><USER10> _If you have no grid, then about $1000 of batteries will cover you, and need replacing every 5-10 years._

This is wishful thinking, both on lifespan and cost of a household battery bank sufficient to run average household appliances like air conditioning and electric water heater and such. Even deep cycle batteries in this sort of working environment will need replacing every 3-5 years (and past 3 years, you'll probably be working with maybe half the capacity of what you started with). The workload of a household running off of batteries during periods when power usage far outstrips power generation is really hard on batteries. There are very expensive batteries that are rated for 5 years or more of use, but they cost two or three times what regular deep cycle lead acid batteries cost, making the total cost much higher. You'll also need more than $1000 worth of batteries for an average American household that uses air conditioning and electric heating devices.

I live in a motorhome with a $300 battery bank (a motorhome has far fewer energy users than a standard home, and I don't run AC, microwave, or electric heaters off of the batteries; I have to crank the generator to use those), and solar on the roof. I'm very familiar with the limitations of batteries, and lead acid battery technology is extremely unforgiving of discharging beyond 50% (even beyond 75% leads to degradation, but most people in RVs accept that because the weight of carrying more batteries to be able to run at 75+% charge at all times is more costly than replacing batteries more frequently).

But, I agree with you that selling back to the grid is the way to deal with this problem in a home on the grid. It's more cost-effective and more environmentally responsible.

</comment></comment></comment><comment><USER11> It's possible to buy something like this.

A WhisperGen which generates electricity (1kW) and makes hot water using a four-piston Stirling Engine: <http://www.ehe.eu/ehe/dm/whispergen.asp?nombre=2401>

They do both because they get cooling by transfering the heat to the domestic hot water supply getting hot water and electricity at the same time. They are powered by natural gas. The gas company E.ON in the UK did a study on them (they also provide them I believe): <http://www.microchap.info/Carbon%20Trust%20field%20trial.pdf>

To quote that report: "For typical family homes, carbon savings of up to 20% are realistically attainable with economic payback of around 3 years."

<comment><USER6> WhisperGen is also only available in Europe and costs two orders of magnitude more than this device would last time I checked.

<comment><USER12> But this device is vaporware, and its price is a pipe dream.

<comment><USER13> Lets hope not - we did complete a working prototype, proving out the mechanics, linkages, and feasibility. We are pretty close to budget on the full sized model - bearings may take us slightly over the $100 mark.

<comment><USER11> What would be useful is an apples-to-apples comparison. The WhisperGen is about £3,000 in the UK but that's a complete installable unit in the home that burns natural gas and hooks up to the electricity and water supply.

It sounds like your $100 is for just the motion part of the engine (perhaps I'm wrong about that). Do you have a sense for what it would cost me to go from having nothing to a working system in my home generating electricity?

</comment></comment></comment></comment></comment><comment><USER14> Variant idea: a small portable version for camping. Stick one end in a fire, USB plug for power connector at the other. 2.5W shouldn't be hard to get under conditions where "unreliable" is normal.

<comment><AUTHOR> It will be kind of heavy though. For simple charging of appliances, other projects are very interesting:

[http://www.kickstarter.com/projects/ryochijiiwa/bootstrapsol...](http://www.kickstarter.com/projects/ryochijiiwa/bootstrapsolar- portable-power-pack-kit?ref=live)

[http://www.kickstarter.com/projects/davefoster/lilypad- using...](http://www.kickstarter.com/projects/davefoster/lilypad-using-light- to-power-all-our-mobile-device?ref=live)

<comment><USER14> I have a solar charger/battery. Surprising how often you can't get enough sun to matter, as you need many hours of continuous direct bright light to collect anywhere close to enough.

I'm imagining a sort of pencil-sized Sterling; stick one end in the fire and the other in a cup of cold water. Not reliant on ambient/weather conditions for power.

<comment><USER15> I've got a miniature Stirling on my shelf. It's a two cylinder setup that runs off of two small alcohol lamps (about the equivalent of two candles), and is air cooled. It weighs about a pound (but could probably be lighter). I don't know exactly how much power it puts out, but it's not much - you can stop the flywheel with light finger pressure.

More heat would produce more power, but I think pencil sized may be a bit optimistic. I like the idea though.

</comment></comment></comment></comment><comment><USER16> Although the goals are clearly different, Dean Kamen (inventor of Segway) has been working on optimizing Stirling engines for years with seemingly great results:

[http://www.nextenergynews.com/news1/next-energy- news4.24.08d...](http://www.nextenergynews.com/news1/next-energy- news4.24.08d.html)

<comment><AUTHOR> One particular design that I'm very interested in is a quasiturbine based stirling engine. It seem to have a lot better power/volume ratio than other stirling designs. Unfortunately, I haven't seen even a single running model yet :(

</comment></comment><comment><USER17> What sort of performance could you expect by just sticking this in the wall of your house? In the winter, you've got cold air outside and you're already heating the inside. In summer, you've got hot air outside and you're cooling the inside. Does it matter which side is hot/cold?

<comment><USER18> I like that idea - can anyone commment further? Up here in the Yukon it's regularly -30C and below for long stretches and we all have our wood stoves burning 24x7 for 4+ months.... It would not be hard to have one end touching the wood stove (200-400C) and the other end outside (-30C - -40C). Will this work?

<comment><AUTHOR> It depends on what your power requirement is. For a 200C difference, you should be able to get around 500W to 600W with a properly built stirling engine.

<comment><USER18> Sounds nice for all the people running off-grid up here who get so little precious sunshine in the winter. Can you provide more information on where I might be able to buy such a Sterling engine? Are there any companies actively making them?

<comment><USER13> Thats what we saw and why we started the project - just not enough solutions for real world requirements. The engine itself is somewhat simple, its the thermodynamics that are tricky - There are only a few moving parts, no spark plugs, no oil, no valves and works off of any kind of heat.

</comment></comment></comment></comment></comment><comment><USER15> An interesting side note: You can build one of these that will run off a candle and fit in the palm of your hand. I've got one in my office. It's a pretty neat technology.

<comment><USER18> Can you give us more details please - did you build it? buy it?

<comment><USER15> It was a kit like one of these: [http://www.ministeam.com/acatalog/Bohm_Stirling_Engines_and_...](http://www.ministeam.com/acatalog/Bohm_Stirling_Engines_and_Kits.html)

I also tried to build one from scratch once, but only got a few parts in before I sold my lathe and mill. The kit was much easier...

Also look up flame eater or vacuum engines. Pretty neat.

</comment></comment></comment><comment><USER19> >The second difference is the Stirling engine is more efficient then the gasoline driven engine.

Gotta proofread this stuff.

Anyway, I was thinking recently about how a stirling engine could be powered by solar energy, and discovered that this is actually done. From wikipedia:

>Placed at the focus of a parabolic mirror, a Stirling engine can convert solar energy to electricity with an efficiency better than non-concentrated photovoltaic cells, and comparable to Concentrated Photo Voltaics.

That's cool, and I'm startled that it isn't mentioned at all on this kickstarter page, especially considering the first paragraph of the pitch.

<comment><USER6> Problem is, CPV only works with clear sun. i.e. it's best for deserts. My hunch is this is targeted at off-grid homesteaders, who tend to live where there's vegetation (and thus clouds).

</comment></comment><comment><USER20> Seems like a huge long shot. Even if you wanted to get one now, it's $250.

I guess I've never seen this yet, but what happens when they can't' deliver you the working product? Do you get your money back?

<comment><USER20> Also, there has to be some sort of mechanism for heat, and then something to actually generate it. All this is going to be is the engine to turn it I believe...

<comment><USER21> Sterlings are normally run on solar heat.

<comment><USER6> I don't know why you're being downvoted. One of the primary uses of Stirling engines, especially for off-grid homesteaders (at whom I'm sure this is aimed) is concentrated solar. All you need are a giant Fresnel lens (~$100), some black metal to act as a collector, and heat transfer compound to attach that to your Stirling engine and you're off to the races.

<comment><USER15> Not a downvoter, but maybe it was the "normally". The cool part of a Stirling is that it is indifferent to fuel.

<comment><USER21> That's true, but in the real world it's fairly uncommon to see actual burners in use, outside of machine shop projects and the like.

</comment></comment></comment></comment></comment></comment><comment><USER22> Hmm. I see a few practical issues with this. I need to keep a fire burning the whole time? Not practical for many (most) homes and also will result in a lot of wasted heat.

<comment><USER13> We've given some thought to this - one idea we are kicking around is embedding a heat capacitor in the engine, kind of like a battery for heat so that we can even out the heat input to the engine - The heat capacitor coule be a type of insulated molten salt bath.

</comment></comment><comment><USER23> Great, if I had enough space I would build one.

</comment><comment><USER24> Robotics.</comment>


Jacob Appelbaum at European Parliament: Privacy, security, spying issues - <AUTHOR> https://vikingvpn.com/blogs/politics/japplebaum-speaks-at-euro-parlaiment <comment><USER2> Everybody has a cryptographic telephone in their pocket. The problems are the cryptography is weak, the endpoints are insecure and people underestimate the value of traffic analysis.

Even if the cryptography were perfect the endpoints could still be listened in on and the latter would still be a huge problem.

Mobile phone encryption only works for the phone-to-tower part. Obviously what Appelbaum is referring to is a phone that does end-to-end encryption (still leaking some info but at least the contents of your conversation should be mostly safe), but people that are not capable of making this distinction will be wary of radio intercepts rather than wholesale line tapping.

It would be a funny thing if you needed a key-signing party before you could start to call people on the phone but it may come to that yet.

<comment><USER3> It's all very do-able. Even carrier voice could be pulled up into userland code in LTE, and therefore could use open source strong encryption.

Social networks are the ideal medium to exchange keys and form and maintain a web-of-trust.

This does not fix traffic analysis, but it would blind Sauron's eye enough to make the current surveillance infrastructure so unreliable as to be useless.

What's needed is for one or two national governments to come to the conclusion that their own surveillance is so far behind the NSA that the only way to win is not to play the game and actually secure their nation's communications and sell this the way tax havens sold financial privacy.

<comment><USER2> > Social networks are the ideal medium to exchange keys and form and maintain > a web-of-trust.

I can see some real problems with that method.

<comment><USER4> I agree.

I've noticed my use of Facebook has been restricted and constrained by mistakes I made when I first used Friendster and Tribe and Orkut. I see my family and friends making many of the same mistakes I made - playing the competitive "more friends" game and connection to people they've never met or who they really don't want "snooping" on their social life - exes, coworkers, bosses, friends-of-friends…

There's no way I'd want Facebook (or Twitter or Google or Yahoo or Microsoft or … ) being any part of a "web of trust" I was using for privacy/encryption/authentication – partly because there's no doubt they're deeply in bed with the NSA (are you really suggesting Facebook's platform is trustworthy enough to exchange keys?), but at least as much because I can clearly see that most people haven't curated their social networking "connections" with anything like the rigor they might have done if they'd been told up-front that "these connections might be used to authenticate your identity and communication to others (potentially including government, law enforcement, and other legal/contractual entities), and also to authenticate your connections identities and communication to those entities."

Do you _really_ know who all of your Facebook "friends" are? Are you _sure_ the person you think that account represents is actually in control of that account? Even if they are, do you trust them enough to vouch for your identity? Are you sure enough of that trust that they wouldn't "betray" you if the NSA, or a police officer, or their local council's dog-catcher, or your car/health insurance company approached them with either a threat or a handful of cash?

<comment><USER3> Key signing enables keys to be exchanged in a hostile environment. Compare web-of-trust to x.500 directory services, which are dependent on CAs.

It also isn't necessary to use Facebook for key exchange in order to adopt social networking functionality to enhancing a web of trust.

The bottom line is you have to design a secure system to avoid having to trust cloud services. While Facebook may be the poster child for untrustworthyness, you can't trust your own machine in the basement of your house not to get hacked. What you _can_ trust is key signing, because it requires stealing a number of identities all at once.

</comment></comment></comment></comment></comment><comment><USER5> "I have in my pocket a cryptographic telephone"

Anyone know what he is referring to? I'd like one of those.

<comment><USER6> If you can't get one of those, you can try Moxie's RedPhone for Android:

[https://play.google.com/store/apps/details?id=org.thoughtcri...](https://play.google.com/store/apps/details?id=org.thoughtcrime.redphone)

<comment><USER7> I think the part of the speech quoted by the parent commenter was indeed referring to exactly this software, and to the other things that the speech mentions:

"I have in my pocket a cryptographic telephone [...] This phone, short of breaking into it when I make a phone call, no one here, short of a mathematical breakthrough, is going to be able to intercept it. I have a couple different encrypted text messaging services. I have the TOR project, Orbot, Progra, Cryptophone, Redphone, TextSecure."

In context, the "cryptographic telephone" is a smartphone running all of this software. "Progra" is a mistranscription; I just listened to the original and he says "the Tor Project's Orbot program".

<comment><USER8> I would be shocked if Appelbaum is still using a standard cell-phone at this point. There's just too much reason to worry about remote compromise of the device.

</comment></comment></comment></comment><comment><USER9> Jacob is awesome.

It doesn't need to be said anymore, but it still needs to be said.

<comment><USER10> I met him once. We exchanged words. I didn't even know who he was, when it happened.</comment></comment>


Don't Let Criminals Hide Their Data Overseas - <AUTHOR> https://www.nytimes.com/2018/02/14/opinion/data-overseas-legislation.html?rref=collection%2Fsectioncollection%2Ftechnology&action=click&contentCollection=technology&region=stream&module=stream_unit&version=latest&contentPlacement=1&pgtype=sectionfront <comment><USER2> I would rather not have criminals in US government and agencies access my personal data, thank you very much. This is much more important to me than this "figthing crime and terrorism", which can show only modest results at best and certainly doesn't make me safer in any way.</comment>


Leading causes of death by age group, United States [chart] - <AUTHOR> http://www.cdc.gov/injury/Images/LC-Charts/10lc%20-%20By%20Age%20Group%202006-7_6_09.jpg

<comment><AUTHOR> I also found the leading causes of nonfatal injury hospital visits interesting: [http://www.cdc.gov/injury/Images/LC- Charts/10lc%20-%20Nonfat...](http://www.cdc.gov/injury/Images/LC- Charts/10lc%20-%20Nonfatal%20Injury%202007-7_6_09.jpg)</comment>


Proxino (YC S11): Automated Error Reporting For Your Client-Side JavaScript - <AUTHOR> http://techcrunch.com/2011/08/22/yc-funded-proxino-automated-error-reporting-for-your-client-side-javascript/ <comment><USER2> Seems to be an interesting product, but..

There seem to be a lot of questions in the thread regarding how this thing works, one commentator noted that you could just bind something to window.onerror (which is a valid point)

They basically seem to have their own JS asynchronous loader script that will wrap all of your scripts into its own thing. That also means you can't use a JS loader like head.js, require.js etc, but their loader serves a similar purpose. (If I'm not misunderstanding)

I have no idea why they need to do this, they might be extending JS function prototypes to log function calls etc to get a stack trace. Who knows. Way beyond myself atm.

This is just got released, but still there are a few things that strike me as odd/worrying:

\- If they really need to load the JS for you, what happens to inline JS and JS that needs to be at the end of the document (for some reason or another)..

\- Their JS file is +100k un gzipped.. That seems a lot if you compare to any other JS loader (typically in the 5-10 k range

\- Note: 100k of JS to load in the head is a LOT of KB before the user starts downloading some HTML.

\- They are actually including all of jquery within their JS file - not in global scope - which seems really wasteful, because you will probably also be doing that - there might be more libraries in there, I'm not sure.

\- This taken from their docs:

> 2\. We recommend that you download proxino.js and host it locally. This will > ensure that your javascript always loads, even if our proxy goes down (which > has never happened). Here is the basic form:

"Which has never happened" -- didn't they JUST launch? That seems a bit immature.

I mean, this is probably just their initial beta thing and I'm guessing this will be pretty decent in a year or two, but so far it's just an interesting tech demo, imo.

</comment><comment><USER3> Is it just me, or does the pricing seem a bit steep? (<https://www.proxino.com/plan>) The free tier buys you roughly 33 page views a day, which I'd expect to surpass just handing a site to a single user or two. At $100/100K page views (which is not terribly hard to reach), that's getting pretty pricey.

<comment><USER4> I also wonder what they consider a page view? Since it's to debug JS, a fair number of their target customers would be running apps that don't have conventional page views, but load data through AJAX. On a similar note, with caching there shouldn't be an incremental cost for each page view.

<comment><USER2> They probably count the page views by the times their JS script gets loaded

</comment></comment></comment><comment><USER5> This looks very interesting, though I'd really like a "lite" version that just logs the error messages. I really don't want my javascript passed through a startup's proxy.

<comment><USER6> Agreed. I'm not sure SaaS is the best business model for this. It looks useful, but just sell it outright.

</comment></comment><comment><USER7> Considering that Chrome and Firefox have enough native Javascript stack trace support to make this trivial, I'm not sure why you would want to do this in production:

1) introduce added network latency (time to proxy / parse / instrument) + risk of downtime of proxy

2) adding try/catch to every function in your program will make it larger and increase download / parse time

3) try/catch blocks can cause performance hits on some JS VMs, so you're slowing down your runtime as well.

<comment><USER8> This doesn't (or shouldn't be) using try/catch, but rather just firing a request to their server when the window.onerror event is triggered.

<comment><USER7> The Proxino blog/website says they parse the JS into an AST and add try/catch blocks to every method.

</comment></comment></comment><comment><USER9> Isn't this trivial to implement?

<comment><USER10> Less so than you'd think. There's a great previous thread about it here on HN.

Similarly, the proxy isn't something you can do without, unless you fail to catch several significant classes of errors.

</comment></comment><comment><USER11> Discussion from 12 days ago: <http://news.ycombinator.com/item?id=2869381>

The most interesting item was kalvin's find about why they proxy your code (and what their value-add is over window.onerror):

[http://blog.proxino.com/post/8388203148/catching-the- worlds-...](http://blog.proxino.com/post/8388203148/catching-the-worlds-bugs- instrumentation-via-proxy)

"At Proxino, there's one question I receive with uncommon frequency: why the proxy? After all, we only ever (at the moment) handle exceptions for you, and so there is curiosity. Is it really necessary, my customer will ask. He considers, perhaps, that the proxy is some clever ploy, a small glimpse at our plans for world domination. A lovely thought, if only it were so. Developers in particular have a tendency to believe that what Proxino does can be done dynamically. They are mistaken.

In a general sense, what Proxino does is a form of global exception handling, a way to catch every exception that occurs within your Javascript. To their credit, our customers correctly suspect that some approximation of this can be achieved dynamically. For it certainly can. Here is a naive first pass attempt at such a global handler, no proxy required:

window.onerror = function(e){ console.log(e) }

Unfortunately, window.onerror does not work in every browser, nor on every piece of code. It will fail to catch some exceptions raised by elements of jQuery, and other similarly complex libraries. It's a simple one-liner, and it sort of works. But quite often, sort of is not enough.

With a bit more care — and a lot more code — a clever programmer can find dynamic work arounds for most browsers and most popular libraries. However in the general case, a global exception handler constructed dynamically is something of an elusive, asymptotic state. You are simply not going to get there. And this brings me to my point. Proxino is not interested in most. We want to catch, and tell you about, everything that goes wrong in your Javascript. Enter the proxy.

When a request reaches proxy.proxino.com, we lookup your existing code, parse it into AST form, and walk down the tree inserting special try/catch blocks within each function definition, as well as around the file itself. We then serve this instrumented file to your users, and handle every exception that occurs. Naturally, we have optimized this process for speed (with caching, etc.) but this guarantees us — and more importantly, you — complete code coverage. You will know about every exception.

Dynamic approaches are incredibly convenient in some ways, but in the general case they simply don't work. And so there is a Good reason for the proxy. Hope this helps."

</comment><comment><USER12> How does this do on minified JS since that's often what's in production?

</comment><comment><USER13> Or you could just do this:

1) [http://mattsnider.com/languages/javascript/window-onerror- ev...](http://mattsnider.com/languages/javascript/window-onerror-event/)

2) [http://mattsnider.com/javascript/catching-all-javascript- err...](http://mattsnider.com/javascript/catching-all-javascript-errors-in- all-browsers/)

I have no idea what kind of lazy developer would pay so much money for this.

<comment><USER14> Thanks for this code. We'll look over it carefully to see if there are some tricks that we've missed.

But we've tried many libraries, and many approaches, to monitoring and debugging javascript. The browser is a much more hostile, varied and foggy environment than (say) Python. It's much harder to notice when something goes wrong, which browsers and which pages it's common to, narrow it down to the right subset of circumstances and contexts, and then effect a fix.

You can try sending an email every time you catch a window.onerror, but most of what you receive will be irrelevant or inscrutable.

If Proxino can make more sense of things, they could make a huge difference to rich-front-end development.

[I don't know them, I've not yet checked out their product, I'm just trying to persuade you all that they're trying to solve a meaningful (at least to me) problem]

<comment><USER13> No need to email errors, you can AJAX it to whatever event tracking/aggregating system you prefer. I love Splunk (which is pretty expensive too for large projects), but there are open source alternatives.

</comment></comment></comment><comment><USER15> I feel like I'm missing something.</comment>


Show HN: Interactive hacking demo of Capital One security breach - <AUTHOR> https://application.security <comment><USER2> Fascinating experience. I enjoyed that.</comment>


The success of Go heralds that of Rust - <AUTHOR> https://medium.com/@george3d6/the-success-of-go-heralds-that-of-rust-73cb2e4c0500 <comment><USER2> Choosing a language is a purely pragmatic issue. You grab the tool that's best suited for a job at hand. I've just started using Go because it's easy to get things done in it and has good tooling and already good libraries.

The time I was most productive with my hobby/shareware programming so far was when I used Realbasic, the Visualbasic clone sold by Andrew Barry as affordable shareware before it became the ultra-expensive mess that is now called Xojo.

Language features are fairly irrelevant, sure Go has some weird oddities for a language of the 21st Century, but it has everything I need to get things done.

As for Rust, I really tried to like it, but so far the only thing I see is an overly complex, anal-retentive language focused on perceived safety but without Ada's readability and long-term maintainability and, just like Ada, without an optional GC but, unlike Ada, without other standard features like integer subtypes and OO with inheritance. I have been downvoted for this just yesterday, there are apparent many ardent language afficionados for Rust on HN, so I need to stop here. I definitely _would_ choose Rust for high- integrity software that doesn't need the guarantees of Spark, but I currently don't write such software.

Go is a great language despite its quirks, verbose error handling and lack of generics because it has a large developer base, compiles fast, compiles to reasonably fast executables, and allows me to get things done relatively fast in certain domains like CLI tools. Unfortunately, it still lacks a good, non- license encumbered cross-platform GUI library, so it's not a full replacement for REALBasic yet. I hope this changes soon, Go would be ideal for developing mid-size desktop applications.

</comment><comment><USER3> There are many factual errors in this article, and some ridiculous amount of hyperbole. Several Rust developers have already addressed the shortcomings on Reddit [1].

[1] [https://reddit.com/r/rust/comments/9nsjmj/the_success_of_go_...](https://reddit.com/r/rust/comments/9nsjmj/the_success_of_go_heralds_that_of_rust/)

</comment><comment><USER4> The most important feature of go is it's simplicity. Rusts isn't anywhere near.

It's easy to jump into a new go project and start writing code. Most other languages will fail at this.

People call it opiniated. but I think, it came from writing years of complex code.

</comment><comment><USER5> This article seems to be missing just how _hard_ it is to learn and use Rust compared to Go. That's a big consideration in the popularity of a language. The article seemed to miss the forest for the trees, as they say.

</comment><comment><USER6> How can I invest?</comment>


The Sun Has Set. Maybe it will rise again - <AUTHOR> http://www.sun.com

<comment><AUTHOR> A little sad to see sun.com redirecting to oracle.

Edit: Consoling myself that this is a better fate than just dying off like SGI

<comment><USER2> My 1st job in the valley was working for SGI. Seeing our one-time rival become a forgotten memory makes me a little sad all over again.

Some of the best OS Kernel engineers that ever walked, walked the hallways of those two companies.

</comment></comment><comment><USER3> In addition to being a bit sad, I'm having a technical problem with the website. It redirects me to oracle.mobi, which I guess is the mobile version of the site. Not good for the company image, I guess.

Note: my user agent is "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 Slackware Linux".

<comment><USER4> Sounds like slackware hit the end of their switch statement ;)

</comment></comment><comment><USER5> I've said it before and I'll say it again; anyone using MySQL in new projects is living dangerously. PostgreSQL is the future. This makes me happy and a little sad. :/

</comment><comment><USER6> I liked Sun's branding better.

<comment><USER7> I did too. They had one of the cleverest logos I've seen. With this redirect dies one of the oldest sites on the web. Sun.com had the 11th oldest registered domain name (tied with IBM.com) <https://www.iwhois.com/oldest/>

<comment><USER8> I tried to do some rudementary research, but without more work it is hard to know if the current owner is the original owner, or just a corp with the same name. I caught ISC as one of these abandoned domains, there may be more.

Oldest Domains:

1\. Symbolics.com => Domain Squatter

2\. BBN.com => Owned by Raytheon

3\. Think.com => Owned by? Oracle

4\. MCC.com => Domain Squatter

5\. DEC.com => HP.com

6\. Northrop.com => Northropgrumman.com

7\. Xerox.com

8\. SRI.com

9\. HP.com

10\. Bellcore.com => Telcordia.com

11\. IBM.com

11\. Sun.com => oracle.com

13\. Intel.com

13\. TI.com

15\. ATT.com

16\. GMR.com => Broken?

16\. TEK.com

18\. FMC.com

18\. UB.com => ultimatebet.com

20\. Bell-ATL.com => verizon.com

20\. GE.com

20\. Grebyn.com => broken?

20\. ISC.com => Aquired by Kodak who abandoned domain

20\. NSC.com

20\. Stargate.com => latisys.com

</comment></comment></comment><comment><USER9> Anyone know what's happening to the Sun research department?

<comment><USER10> Oracle said no one will be laid off and they will dramatically increase R&D spending.

<comment><USER11> As a general rule, don't trust anything that's said during an acquisition. Those communiqués are designed to assuage shareholder, employee and fan fears and usually get, uhm, reinterpreted within the first year.

<comment><USER12> Sounds like campaign promises.

I'm going to miss Sun.

</comment></comment></comment></comment><comment><USER13> I guess there is no more "dot" in "dot-com".

</comment><comment><USER14> Maybe they can do something with sunsolve next. That site and the backend has been terrible for at least a year due to the failed backend change they were working on forever. No one on the Sun side knew where my cases were half the time.

<comment><USER15> If you think Sunsolve was bad, wait 'til you try Metalink.

</comment></comment><comment><USER16> What happened to all the online tutorials?

<comment><USER17> When Oracle acquired BEA, they took them offline for awhile.

This sucked, as the BEA products seem to demand frequent trips to the online references, and troubleshooting guides. Actually, it still sucks, because although they have replaced most of the documentation that was available (the most valuable bits were the dev2dev and forum areas) they often link back to BEA, which redirects you to Oracle's front page, or to the front of their BEA documentation section, but absolutely never to anywhere resembling where the link was intending to go.

<comment><USER18> The docs are still up: <http://docs.sun.com/>

The same site, just rebraded.

</comment></comment></comment><comment><USER19> Java was the first real language that I learned, back in the days of BufferedReader and no generics ... I'm still young in the programming world, but to see my first and favorite programming language's developer being bought out is ... most sad, to me.

I suspect it is because I'm in a period of mourning, but ... Java just doesn't feel the same to code in right now... like it's been killed, even though it's still around...

</comment><comment><USER20> Eric Schmidt (former Sun guy) could have _bought_ Sun with his Google money (note: not quite).</comment>


Think Outside the Box, but Don't Forget the Box Exists - <AUTHOR> http://uxmag.com/design/think-outside-the-box-but-dont-forget-the-box-exists

<comment><USER2> Wow great info. I can now see why designer stick to the macro.

</comment><comment><USER3> OMG, finally someone that see's the bigger picture!!!</comment>


Open Letter to Web Designers and Developers: Max CSS - <AUTHOR> http://daneden.me/max-css/ <comment><USER3> CSS is the easiest part of the design cycle. (The hard part is actually mocking something to look great.. implementing it is the fun part.)

Creating CSS which matches your design should not really be an issue, and as others have pointed out, if you see something on another website that you like, then you can just use chrome inspector which would always work by an order of magnitude better than using a main.max.css sheet as you suggest.

I'm not going to be elitist and say that learning CSS is a non-issue, but maintaining a commented CSS would be ridiculous. Especially when all of my CSS is automatically compliled (lessCSS) and comments are stripped.

What would your main.max.css look like?

        .container {
           border: 1px solid black; // This adds a solid black border
           float: left; // Remove element from doc flow, and align left
           padding: 10px; // This adds a 10px padding
           background: white; // This sets the background white
         }

When I read the title of this post, I thought that you might of been suggesting that developers maintain two sheets, a

[1] main.min.css

[2] main.max.css

Inside of the min CSS, you might use all of your layouting styles _and lightweight background styles_. However, inside of the max you would add all of your complementary styles.

Such as all of the background gradients. All of your vendor specific box shadows, border-radius', box-sizing, opacitys, etc. Getting background gradients compatible accross different browser vendors totally bloats my CSS (by about a 100-140kb (since I use alot of high quality gradients instead of png).

I could perhaps get behind the idea to seperate two sheets. One min.css for pure templating and layout, and a max.css for all that awesomeness.

The only benefit this would give is being able to detect a user agent and serve up the more lightweight version.

Anyway, big NO NO, for your suggestion. I can't get behind that idea.

<comment><USER4> That's not a very fair example. That would be like commenting Python like this:

        def foo():       # This defines a function
            a = 5        # This defines a variable, a = 5
            return a + 5 # The function returns the value of a + 5

Not to argue in favor of or against max.css, but nobody comments their code like that. It's more about things like this:

        .ribbon-edge {
            /**
             * By setting the width and height to 0
             * and having a really large border, we
             * can use the way the borders intersect
             * to create a ribbon edge for our header/
             * This results in three angled red borders,
             * and one transparent, right-facing triangle
             * on the left side.
             */
            width: 0;
            height: 0;
            border: 50px solid transparent;
            border-left-color: red;
        }

</comment></comment><comment><USER5> A good command of chromes inspector etc makes this largely a non issue for me ...

<comment><USER6> But that doesn't magically insert comments explaining the reasoning behind doing a certain thing a certain way. I don't know about you, but I have those comments in my CSS just for myself, which is a good indicator a newbie might have use for them as well. Lucky for me I do parsing/compacting/caching the CSS on the fly, so I might as well put a comment into the compact version explaining where to get the "max" version. But I don't see how it would be much work with static files for that matter.

<comment><USER7> What sort of comments do you add? Mine are usually of two varieties - <USER2> explaining a pixel value (width + border + margin), or adding a short note about why I did something unconventional (two pixels removed so FireFox doesn't flow to the next line). In either case, someone learning CSS wouldn't be hugely benefitted by them, since I don't make the comments all that verbose.

That said, I usually don't minify my CSS anyway. I was just wondering if there are any significant cases where comments would make a huge difference to someone who is learning CSS.

<comment><USER8> I think the latter is what could be useful to people learning. E.g. "set X to Y so browser B doesn't do Z" is actually useful to someone who has never seen that behaviour and may encounter it, or be looking at you sources cause it seems you handled it somehow but it doesn't work on one's own page.

Not sure how much though.

</comment></comment></comment></comment><comment><USER9> In general, if you want to make your source code available for others to learn, publish it on github or elsewhere.

<comment><USER10> Yeah initially I agreed with this article, but after reading the comments and thinking about the fact that i always use sass or stylus for css, I think it makes more sense to publish your source on github and put the github url in a comment - this is much better for learning anyway.

<comment><USER11> I'd give serious consideration to something like:

      static/style/foo.css

containing the comment

      /* See static/style/foo.css.src on this domain */

since you want the source for the deployed version, not master, and we're trying to make things easy for people grokking what's deployed, not express an opinion about branch naming and deployment practices :)

Publishing the repository URL and/or deployed branch/tag/revision might also be awesome, but it serves a different albeit overlapping set of goals.

</comment></comment></comment><comment><USER12> I consider myself both a non-designer and a non-programmer. I'm able to do basic things in Photoshop, and if i was really determined, i could probably replicate a decent design from somewhere else, but it would take some conscious effort. Similarly, I dont consider myself a programmer, but i can read javascript code, and i've done a little bit of programming here and there but never completed a full web app journey from start to finish as part of a team, or even on my own.

I finally took the leap a few months ago, and have started out on my own app. The thing that i have found most in my journey is that there seems to be a wealth of information out there for newbies - such as the htmlcss book or the w3schools site - and a wealth of information for people at a more advanced level - though i've noticed conversation between experienced devs is what is helping them. There doesnt however, seem to be much targeted at the intermediate level of developers that kind of get wedged in between a rock and a hard place (like me).

Take git or mercurial for example. Lots of information explaining what git is, what the advantages of dvcs are. Also plenty of tips and tricks and cheat sheets for someone already using dvcs, but nothing at someone that's understood the basics but wants to go up a level.

People like me are desperately trying to get to the next level in both design and development.

So i beg all of you that are at a more advanced level and have been doing design or dev for a considerable length of time, to please think about us intermediate people; us non-designers and non-programmers that want to create something great and have finally plucked up the courage to have a go. Help us out. Please.

I'm not saying that many of us, won't still try even if you dont reach out to us. The best way to learn, of course is just to dive in and keep cracking on at it, but if you guys were to think about us, it would make our lives just that little bit easier and more rewarding.

<comment><USER13> Side note, Please don't use w3schools. <http://w3fools.com/>

Consider the excellent MDN instead, <https://developer.mozilla.org/en-US/>

<comment><USER14> For some reason, whenever I've used mozilla's site, it has a horrible response time. Whether this is due to extreme load or just a crappy server, half the time I quit after waiting 20 seconds for a page to load (my normal wait time is less than 5 seconds).

W3Schools is still an OK reference site. I haven't really looked at their tutorials.

</comment></comment></comment><comment><USER15> I think this is even more important for Javascript files. So many times I'll look at something to learn and find it's minified, which makes it a lot harder, there are tools to deminify but obviously a lot of semantic information is lost and then I can't step through etc.

<comment><USER16> I fail to see that as a problem. Source code for programs have nearly always been compiled and often obfuscated so why should Javascript be treated any differently?

</comment></comment><comment><USER17> Try using Chrome developer tools or firebug to inspect css. Its's better.

<comment><USER18> Firefox's built-in inspector is pretty nice too.

</comment></comment><comment><USER19> Is this really a problem with css? javascript I can understand but with firebug or chrome inspector, CSS is basically self documenting.

<comment><USER20> Agreed. More often than not, CSS that doesn't explain itself (margin-top: -43.1px;) is bad css.

That's not to say CSS comments are useless, but they should be helpful, not necessary.

</comment></comment><comment><USER21> Not a bad idea, though I'd just avoide the .max all together. Perhaps I'm missing the point and/or assuming everyone already does this, but I always make my _.min.css files from_.css (eg foo.css becomes foo.min.css).

</comment><comment><USER22> Better yet, just allow directory indexes on /js and /css, showing the smaller files that the minified one is built from. You can do this, and also minify them using a Makefile.

      zx2c4@albali ~/zx2c4.com $ cat Makefile
      JS_DIR = js
      CSS_DIR = css

      JS_MIN = $(JS_DIR)/scripts.min.js
      CSS_MIN = $(CSS_DIR)/styles.min.css

      JS_MIN_FILES := $(patsubst %.js, %.min.js, $(filter-out %.min.js, $(wildcard $(JS_DIR)/*.js)))
      CSS_MIN_FILES := $(patsubst %.css, %.min.css, $(filter-out %.min.css, $(wildcard $(CSS_DIR)/*.css)))

      JS_COMPILER = ~/opt/bin/google-compiler --warning_level QUIET
      CSS_COMPILER = ~/opt/bin/yuicompressor --type css

      .PHONY: all clean

      all: $(JS_MIN) $(CSS_MIN)

      %.min.js: %.js
      @echo "Compiling javascript" $<
      @$(JS_COMPILER) --js $< --js_output_file $@

      %.min.css: %.css
      @echo "Compiling stylesheet" $<
      @$(CSS_COMPILER) -o $@ $<

      $(JS_MIN): $(JS_MIN_FILES)
      @echo "Assembling compiled javascripts"
      @cat $^ > $@

      $(CSS_MIN): $(CSS_MIN_FILES)
      @echo "Assembling compiled stylesheets"
      @cat $^ > $@

      clean:
      @rm -fv $(JS_MIN) $(JS_MIN_FILES) $(CSS_MIN) $(CSS_MIN_FILES)

You prefix the js/css files with an order number.

js/000-jquery-1.2.3.js js/001-silly-jquery-plugin.js js/002-another-silly- jquery-plugin.js js/010-something-else.js js/100-fetcher.js

or whatever kind of ordered number scheme you like. This way, the Makefile's auto-discovery of the js/ _.js and css/_.css contents will maintain order.

</comment><comment><USER23> Source maps are the standardized way of defining the original source of CSS, JS and other compiled-to-the-deployed-web languages.

<https://github.com/h5bp/html5-boilerplate/issues/820>

In this thread I ended up proposing something very much like what Dan is saying here but realized (after Kevin Dangoor, product manager of Firefox's Developer Tools, chimed in) that indeed source maps were designed exactly for this situation, no authoring convention or filename guessing necessary.

Source maps not only can point to the original sources, but can translate between minified css and fully formatted Sass with comments, and developer tools can identify the mapping.

As for how ready this is, CSS source map plumbing is in both Firefox and WebKit, though they are not totally complete. I believe FF has a Google Summer of Code student working on the feature: <https://wiki.mozilla.org/DevTools/Features/CSSSourceMap>

Just because its relevant: all the source map projects: [https://github.com/ryanseddon/source-map/wiki/Source- maps:-l...](https://github.com/ryanseddon/source-map/wiki/Source- maps:-languages,-tools-and-other-info)

</comment><comment><USER24> While the idea seems decent, it completely forgets about CSS preprocessors (LESS/SASS). When using one, the original 'source' stylesheets usually don't even make it into deployment server, for they are just used to build final CSS. Even if not minified, that CSS file would likely be pretty unreadable, not to mention that it wouldn't really reflect the original patterns and ideas used in source files.

</comment><comment><USER25> Call me crazy, but why would you waste a user's bandwidth on this? Also, usually, there is a foo.css, next to a foo.min.css, why introduce a new paradigm?

on top of that, there's right click on an element -> inspect, and it will tell you all you need to know, in any proper browser.

I really don't see a need for this.

<comment><USER26> There really isn't a need to do it in the manner that was suggested. If a frontend developer wanted to provide a copy with comments, it's better to host it on github & comment the link in the css file.

</comment></comment><comment><USER27> This takes out any or all learning curve for beginners. If we did this it would disrupt the web development industry, think of it like natural selection. Half of why web developers are so great is their resourceful. I just see this as a terrible way to teach people to copy and paste. Creating myspace all over again

</comment><comment><USER28> At the end of the day, I'm not writing my CSS for others to learn from outside of the // hidden comments for my devs that don't get compiled in the final CSS. There are tools out there to reverse engineer/un-minify CSS and JS files if they are so intrigued, and if they want to learn the best way for them to do so is to get down and dirty the same way the rest of us did and just learn what works and how it works outright. Having the Inspectors already gives them a leg up over a lot of us.

</comment><comment><USER14> I would say Firebug or Inspector is a better tool for poking around in CSS than trying to look at a raw stylesheet. There are hidden settings that you'll never see otherwise (that don't get used much, admittedly) and it gives you the ability to make a change and see how it affects the current page.

The CSS you see in those tools is real decompressed CSS (organized a bit better than most stylesheets) and is pretty much exactly what you'd put in a stylesheet.

</comment><comment><USER29> As I've been playing with SASS I had decided that I would place the resulting scss file in with the actual css file. My reasoning being very close to what the article states; my css file is compressed and comments stripped, the scss file is not. Granted, I would probably have to put a link to the file somewhere but it would be nice if this somehow became a thing people just did.

</comment><comment><USER30> Beyond Firefug and Inspector, there are also CSS prettifier tools out there like the excellent <http://procssor.com/process>. That's about the best you can hope to do, unless you are expecting developers to put extra educational content in their maxified CSS files. Which ain't gonna happen!

</comment><comment><USER31> This almost seems like a browser problem for me, rather than a problem that developers should solve.

If you use Firebug or the equivalent across the browsers it's very easy to see the "maximised" CSS, but surely a setting to do this when viewing the CSS would be a good thing?

</comment><comment><USER32> Hi all. Thanks for your comments on this. I've addressed a few of the misunderstandings and concerns raised here on HN, Twitter et al over on my blog: <http://daneden.me/2012/07/max-css-in-depth/>

</comment><comment><USER17> Compress/minify everything: HTML, CSS, JS, Images. Less is more. Anyway, There are tools to help you understand the code if you take time to find it.

</comment><comment><USER33> Actually should we give also the real source? What about SASS/LESS/Stylus? Uncompressed CSS says seriously nothing more than minified one.

</comment><comment><USER34> how about just use: <http://www.codebeautifier.com/> ?</comment>


The end of Snap and Tesla - <AUTHOR> https://medium.com/s/no-mercy-no-malice/no-mercy-no-malice-the-end-of-snap-tesla-af4499558ce0 <comment><USER2> Not much to say about Tesla (haven't been following the story), but one thing that I don't get with Snap is why don't they cut their overheads to try and get back in profit, instead of chasing the impossible dream of getting back to Instagram-levels of growth?

It seems like their platform is already built, they have some ways of making money (ads, sponsored filters, etc), so surely the easiest option is to cut overheads and at least make _some_ money, instead of burning the little of it they have left?

Same thing for Twitter. Last time I checked they had thousands of employees; yet the platform is stagnating and getting worse every day. If they can't innovate, it seems wise to at least cut their losses and try to make some profit with whatever they have left.

<comment><USER3> Snap should have built a decent Android app and expanded internationally years ago.

This could have stopped Instagram before they got the opportunity to clone their product and present it as a new thing to audiences all over the world.</comment></comment>


Startup focused on medical communities looking for UI/UX help - <AUTHOR>

We are a San Francisco startup that has been actively developing a service for collecting information for under-served medical conditions, and for developing communities for these patients.
We have a prototype, physicians from Stanford onboard, and have our first VC pitch on Wednesday.
We need a UI/UX/frontend developer, preferably able to customize Joomla (or replace it). We can currently only offer sweat equity, but we are not looking for a full-time developer.
Email: eadonj -at- gmail.com <comment><USER2> FYI, most competent developers are going to see that and decide it's worth roughly what you give them in free coffee. If you want a competent developer to do work for you and they're not a cofounder, you generally need to be paying them in something which they can turn around and use for paying bills.

There are a few exceptional cases. For example, would it make an interesting research project? But in general, you'll get something very close to what you pay for.</comment>


There is No Bubble, There is Entrepreneur Envy - <AUTHOR> http://howardlindzon.com/there-is-no-bubble-there-is-entrepreneur-envy/

<comment><USER2> I disagree.

1\. I can think of many bubbles that the author has lived through, even if he can't. Oklahoma natural gas in the early 1980s, junk bond credit bubble in the mid 1980s, Japanese stock and property markets in the late 1980s, regionalized housing bubbles in California and Boston in the 1970s and 1980s, etc. There are many other examples, depending on how old he is (Nifty 50 in the late 1960s), etc. And I don't think it's a stretch to call the "mania" for tech stocks in 1999 a bubble. (If that's not, why is housing/credit in the 2000's a bubble?) Ignorance of history is not generally a qualification to opine on it.

2\. To take this seriously as comment, he'd need to define the difference between a bubble, a mania, and a phenomenon, at least well enough for someone else to apply it to a situation and arrive at the same classification. Otherwise, this is an article about how he doesn't think there's a bubble, so you shouldn't either.

3\. I will do him one better and hazard at least a partial definition of a bubble--a rapid and escalating series of price increases that is driven by a feedback loop of public perception rather than by the fundamental cash flows of the asset. One can quibble with this (it's hardly scientific). If you don't like mine, have a look at Robert Shiller's ([http://dealbook.nytimes.com/2010/01/27/schillers-list-how- to...](http://dealbook.nytimes.com/2010/01/27/schillers-list-how-to-diagnose- the-next-bubble/)).

4\. To establish that this is not a bubble, he would need to make it clear why he believes that the cash flows the affected firms will ultimately generate will make their present valuations reasonable. While that may be true in some cases, in general I don't think it's a hard case to make that the tech industry has jumped from cyclical upswing to nascent bubble. Pockets of tech financing--arguably angel financing and some late-stage financing--are, to my eyes, pretty much already there.

</comment><comment><USER3> "We had ONE bubble in my lifetime and it was a 'credit bubble'."

In other words, he has redefined bubble to mean what he wants so that all the other bubbles aren't really bubbles and he can make a link-bait headline.

</comment><comment><USER4> I found this particular article vague and lacking of any necessary supporting facts. I read through a few other posts by the author and found them along the same lines [1,2]. I see no reason to value anything written by Mr Lindzon on the serious subject of whether we are in a bubble.

[1] [http://howardlindzon.com/apple-and-bank-of-america-i-love- wh...](http://howardlindzon.com/apple-and-bank-of-america-i-love-when-the- market-makes-sense/)

[2] [http://howardlindzon.com/the-cotton-crash-the-q-tip-bear- mar...](http://howardlindzon.com/the-cotton-crash-the-q-tip-bear-market- of-2011/)

</comment><comment><USER5> I actually agree with this.. I tried to think back about the dot.com era (which some people refer to as a bubble. If you think about it, the dot com bubble never burst. It is still alive and if anything, has allowed the amazing platforms we have today to materialize from something. Perhaps the insane growth has somewhat mellowed, but the dot.com era never blew up (destruction blow up, not growth haha). The dot.com era and our current entrepreneurial/start up era are unique, but I still think they play by the similar rules that any business, product or service goes by. They'll be created, experience growth, begin to mature and then possibly (with no regard to adaptation) decline or slowly die out. It's up the people behind the companies how long it takes and how much traction they can establish in each phase, which is where the true entrepreneurial skills shine.

Just a few points that come to mind after this article, not saying they're right or wrong.. but thanks for getting the mind cranking!

<comment><USER6> "If you think about it, the dot com bubble never burst."

the NASDAQ went from over 5000 to under 2000. how can this be characterized as anything other than a bubble bursting?

<comment><USER5> You're right, market values dramatically declined.. but you have to include other variables such as 9/11. The market was its worst in 2002 and one would have to think that without the repercussions on the market from 9/11, things wouldn't have been nearly as bad. The market went on to rebound and soar very high for the next 5 or so years and then our current situation began.

Case and point, the dot.com era experienced a decline in product life cycle growth as it transitioned from its growth to maturity stage (and of course, the events that took place on September 11th didn't help either).</comment></comment></comment>