reeses

Fully agree. There are so many people who can't do the basic Excel work even to generate the information on the chart who are capable of starting a business. (I include in this every restaurant ever opened, modulo statistical outliers.)

That's not a problem with the chart. That's a problem with starting a business.

You don't have to grow along a fixed axis, whether that be # of users, # of widgets, etc. You just have to average the growth in income.

I had a similar initial reaction to the chart because I stick to R&D-driven startups that will run at $0/week for as long as it takes. However, pushing the stop-energy out of my head and running with it is a good gut check for viability on breaking even given assumptions about expenses vs income over time.

The output isn't "we will grow at an annualized 360% forever, yielding foo," it's "we only need to kick in $x to have a good shot at getting to B/E."

You had me at 'syntax'.

The fact that we're still typing crap into windows and calling advances along this one-dimensional path 'innovation' is pain.

Intentional[1] had a lot of promise but was too slow off the mark and now feels more like BPML, which has too much XML hiding under the covers to be good. As it stands, making solution development easier for business users has not had a broad impact on the overall productivity of developers.

'Blub' assumes existence on a continuum of language. It's a limiting concept in itself, as many of us have a different internal representation of thought.

It's sad to read about "python stuff for swift" or "haskell stuff for scala" when the only advantage of those exercises is as homework to understand the concepts.

[1] http://www.intentionalsoftware.com/

It's that race to the bottom they mention. As they mention, they're in a relatively expensive labor market (although, as I sit here in the Bay Area, they have me thinking about a recruiting run to the UK).

They're paying for the market validation that can be eaten up by a company in a less expensive market to produce a knock-off version (or, more likely, ten knockoff versions) for that USD9.99 and enjoy boatloads of sales.

This pattern sets an expectation that, because it can run on your phone, it should cost significantly less than desktop software, even if it is more useful than a desktop version.

I'm a big fan of leverage and my father taught me the ROI model of tool selection from an early age, for everything from shoes to calculators. Unless it's completely unaffordable, the cost of a tool is irrelevant outside the context of its ability to amplify your thought and your output.

This works out when discussed in the context of "competitive compensation" in your market. While your manager may not care that you want to live in a USD5,000/mo apartment, she may care that companies x, y, and z are paying programmer analyst IIIs USD5k/mo more than she's paying you.

I almost never give COLA raises, but I will raise based on performance and desire to remove money as a reason to look for another job. It's the easiest way to overcome inside recruiting and it doesn't take much thought, so I can spend my time with other retention techniques.

The concepts are the important part. You can get a long way with a nasty interpreter to see if your concepts play out. :-)

If it's a "deep" concept, I'd pick a simple representation that I can implement without much cognitive overhead (a basic Lispish or Forthish stacks-and-registers syntax is usually something I can spin up in a few minutes) and then start layering my concepts in.

Some of the things you think will be awesome will end up just being wrong or inefficient, but you'll cut the loop down really quickly.

It makes it really easy to compare your hypotheses. If you want to factor them into a more conventional syntax model (c, python, haskell, etc.) you can always learn that along the way.

In fact, if you want to get really simple about it, write the code you would want to write and hand interpret it. You can get really far with simple pre-processors written in whatever text or AST manipulation environment with which you feel comfortable. (I'm notorious for being lazy and writing 50-pass compilers, just writing 10 to 200 line features and chaining them, all in a ghetto RPN.)

Well timed after prime music imports your itunes library.

no hairy workarounds to replace an iphone in your mac ecosystem, which is something google has not achieved.

(yes, other than apps, but that will follow)

To make a comparison for anyone who hasn't programmed FPGAs (especially on the path to etching silicon), placement is extraordinarily important. Not only can (will) you make a highly non-optimal layout, FPGAs are not orthogonal. You'll spend a lot of time trying to route the bits that need to talk to each other via direct connection as much as possible instead of going through a gp line or worse.

Depending on the make and model of FPGA, you will have "large" areas that you either can't or don't want to plop logic.

You can have a pretty netlist that validates and simulates correctly (although you'll eventually end up dealing with Cadence, who seem to have the right hand side of the bugs per line of code curve locked up) but still takes weeks or months of that inline ASM work to make it competitive with a rack of Xeons. The edit/compile/debug cycle is not quick by any means past a trivial number of gates.

Dealing with that junk is why IP blocks are so attractive, but you end up on the road to structured ASICs and that just leads to misery.

Former LVMH director here.

The Chinese luxury market is insane and has been popping for the past ~10 years. It's not just LV (and child companies) but across the board, with Richemont and others doing quite well. LV just happens to be very good at a) encouraging mobility in its staff so that the "experience" is consistent b) grabbing a great spot of real estate and building monstrous stores in which you could fit an Apple store or ten and c) selling product that advertises the financial status of its owner.

I'm sure you could run a similar metric with Rolex or other "conspicuous consumption" brands.

And no, it's not the poor kids sewing Nikes who are buying the top kit. The average purchasing power is very low.

In general, of course, it depends.

In the case I mentioned above, we left the candidate site immediately, arranged earlier flights, and flew back to Seattle. There may have been exec communication but I was just the technical DD guy at the time. But I never heard from them again.

Had the code been stellar, we may have given them time to sort it out so that the package was clean.

A fun one is finding loans from friends and family that involved any sort of strings, whether convertible or interest that has accrued because Aunt Bertha forgot about the $50k she gave you.

It's easy to forget these loans from the early days, especially if there were 20 people who gave the founder little bits of money, especially if it was before he or she set up the corp accounts, etc.

Other than that, one of the worst I've knocked down uncovered a lack of assignment of IP (an early rich-media MUA) from a contractor that effectively meant the candidate company had zero value. "Who's Bob Smith of Bob Smith, Inc.? Can I talk to him about this shitty code? Oh, he owns it..."

Some commonly involve artificially boosting turnover by trying to be clever and using in-house developers as a separate concern, billing or paying through companies owned by family members. Sometimes this sort of setup is kosher (you want to smooth out and isolate capex and a friend has office space and a couple devs, or there's an overseas component, or whatever) but if money is moving between them in a semi-closed ecosystem, it's often a bad sign.

Usually, as stated, it's sloppy stuff, but sometimes you get a real weasel.

As for being a founder, having an accountant/CFO makes a huge difference. The first contract CFO I hired was a revelation. The commitment was low and the upside was huge. We were too small for a FT CFO and I was a babe in the woods and didn't even realize these people existed.

The most commonly-heard excuse is that programmers do not like all the parens.

I would assert, rather, that we have 60 years of compiler and runtime experience, both academic and industrial.

Consequently, I would propose that there is no excuse for a public release of a commercial programming environment to be so slow unless it introduces significant novelty sufficient to render the preceding work inapplicable.

It's also more pronounceable and appetizing, like the chilean seabass.

Don't worry, it will turn out to be, in fact, an aardvark. Please see the "panda bear is a racoon, oops, no, he's a bear," controversy.

The fundamental problem is that Wikipedia's editorial policies great drag on the memory hole.

Elinks, while shamefully neglected by most of us, does expose an interface for ecmascript. http://www.elinks.cz/documentation/html/manual.html-chunked/...

Write an email and ask. People are generally decent and like to explain how they did something that impressed someone.

The first thing I think with "cheap <industrial>" is "superfund". I hope no one ever did any work with electroplating, pharmaceuticals, pesticides, VOCs, asbestos, explosives, PCBs, or any other fun stuff that will come back to haunt the current owner.

I suspect you already know the answer to that. A brand new dump truck would be clean, with a minimum of oil, grease, dirt, or grime. I'm sure you could construct a large enough accommodation inside the bed of the truck to have the equivalent living space of a medium sized sailboat.

The great part of this is, when all of your clothes smell like diesel/gazole/etc., people will assume you are a liveaboard!

You would have excellent security. If you had a "home invasion", a simple press of a button would disorient your attackers and incapacitate them much in the way of the wicked witch of the East. If they have ruby slippers, I believe they would be yours by right of conquest.

Also, you could park almost anywhere you liked, at any time. No one questions a dump truck being anywhere, because they have so many uses. With a prudent selection of magnetic door logos, you could park for a nap in the middle of Market Street in San Francisco, Fifth Ave in NYC, or right in the middle of Piccadilly Circus.

That's the thing. If all you say is "fuck", then there's no problem, but you also have no range in your profanity.

When I swear, there's no way I would want a child to hear it. Their parents would hate having to explain what I said and they would dread their children repeating it in front of 'polite company'.

I wouldn't want my mother to hear it, because her brain would explode thinking that she created a son who, some 20+ years on his own, could create the thoughts behind my swearing.

My father would probably just pause for a second, chuckle, and then utter a string of such vile filth that I couldn't look at a roll of duct tape again without nausea.

I think the core message of the post is a really, really weak version of what Louis CK got into regarding the "n-word".[1] Without saying something offensive, you're still putting that offensive thing into the person's mind. If you write "fvck", you know people are reading it as "fuck". It's just cowardly.

[1] https://www.youtube.com/watch?v=dF1NUposXVQ, not work-listenable.

Which it will, in the form of transfer taxes and capital gains taxes.

"professional engineer" is more than just being paid. It is a regulated term that connotes an ethical code, qualification, and acceptance of responsibility. It can be loosely compared to the bar association in the USA, or many guilds.

There are very few "professional software engineers" in the USA. Only a few schools, such as UIUC, have such a program.

Software engineer and software architect are meaningless terms. They are self applied yet imply some sort of parity with engineering or architecture. Insert your favorite "if x were built in the same way as software" joke here.

Your comment is quite pythonic. There should be only one question about the only one right way to do something in python.

And most Lisps.

This comment is a fine example of jl's points. While the tone was not rude or aggressive, commenting merely to contradict and to attempt to invalidate specific points, out of context, is unhelpful to someone who is self aware enough to admit they are pretty, thin, and skinny. (We know our own and can read through the code.)

Jl is probably aware that this sensitivity can be overcome, and how to do so. Sometimes it's ok to pass over a thing in silence instead of telling a stranger to smile.

It is apparent you have not written many grant applications. :-)

For example, from the NIH (https://grants.nih.gov/grants/writing_application.htm):

Remember the Details! Below are tips to assist you in meeting the requirements on font, font size, margins and spacing. Be sure to follow the format in the instructions and label sections as requested.

Use an Arial, Helvetica, Palatino Linotype, or Georgia typeface, a black font color, and a font size of 11 points or larger. (A Symbol font may be used to insert Greek letters or special characters; the font size requirement still applies.)

Type density, including characters and spaces, must be no more than 15 characters per inch. Type may be no more than six lines per inch. Use standard paper size (8 ½" x 11) . Use at least one-half inch margins (top, bottom, left, and right) for all pages. No information should appear in the margins.

The USPTO has a patent search for the US Patent and Trademark Office at http://patft.uspto.gov/.

As for MSFT not having any patents in 1983, this is largely the result of the policy of not patenting "abstract ideas" that was argued in the courts at the time. The United States Court of Customs and Patent Appeals and the PTO were in opposing positions regarding the patentability of inventions that were essentially algorithmic.

The key log that stopped discouraging patent applications for software was Diamond v. Diehr in 1981, which involved applying a mathematical formula to a database of information for operating rubber curing machines under computer control.[1]

The United States Court of Appeals for the Federal Circuit has largely followed this method since this decision. Between the early 70s[2] and Diehr, SCOTUS settled disputes when Customs and Patent Appeals attempted to overrule the PTO and its Board of Patent Appeals and Interferences/Patent Trial and Appeal Board.

[0] I'm lazy, you get wikipedia. [1] http://en.wikipedia.org/wiki/Diamond_v._Diehr [2] Gottschalk v. Benson, 409 U.S. 63 (1972), http://en.wikipedia.org/wiki/Gottschalk_v._Benson

I actually found it optimistic, in the "destroy a village to save it"[1] sense. HN, as it currently stands, will cease to exist. I suspect the volume of submissions pointing directly to old wikipedia articles will dry up. I consider this a good thing.

I suspect the volume of submissions that are reposts piling onto something already on the front page (Erlang, Erlang, Erlang, Erlang, Haskell, Haskell, Haskell, Go, Go, Go, Snowden, Snowden, NSA, Erlang, Lisp, Lisp, Lisp, Lisp-flavored Erlang, NSA, Erlang, Erlang, Bacon and Spam, Javascript, Framework, Framework, NSA, Erlang, Haskell, Haskell, Erlang, Lisp, 2048, will dry up. I consider this a good thing.

I suspect I will spend less time on the site, either because conversations will become static expressions of views or because I won't have to filter through as much content, even though much of which marginalia I find quite engrossing. I consider this a good thing.

What comes next is open to conjecture. It could be a more mature salon full of reasoned discussions or it could become a ghost town with lots of great, old, discussions.

[1] I know, apocryphal at best.

The "luck" over the long term is, as you say, more than just the equivalent of finding a quarter on the street.

Nearly everyone I've observed with long-term "luck" has been mostly successful at recognizing and acting on opportunities.

The a-hole contingent merely has another tool to widen the funnel of opportunities. By eliminating compromise and being willing to divest others of their benefits, one can increase the likelihood of eventual success.

It just takes timing to stumble on one gold-making opportunity. It takes an approach to repeat it with consistency.

I had a conversation with a drill instructor who encapsulated (hah) the role by asking if I thought he really had that level of anger over untied bootlaces.

Many a-holes use every opportunity to send the message that not following their way will lead to dire consequences. It doesn't have to appear rational in the moment, but it is generally intended to achieve end results that the a-hole is unwilling to communicate.

But I bet you wrote more, more accurate, and more advanced calculus than he did, and you wrote it the way Leibniz intended. :)