How important are 'economies of scale'? - <AUTHOR> https://mattstoller.substack.com/p/national-champs-or-national-chumps <comment><USER2> "Bigness often cuts against innovation."

The term the author needs is "diseconomies of scale." Economies of scale is unquestionably important for increasing value production and economic growth. However, if economies of scale is a positive feedback signal, it is diseconomies of scale that acts as a negative feedback signal, keeping the economy in equilibrium by recycling the old companies that fail to innovate and adapt back into the market, and providing opportunities for smaller, more innovative companies to gain a foothold before they achieve economies of scale. You see diseconomies of scale in companies that have multiple groups working on the same product, lack of oversight and skewed incentives, and overall organizational incompetence that often stems from complacency in a once innovative company.

This is where rent-seeking and regulations come into play. Having legal scale enables less innovative companies to get into the business of lobbying and regulating themselves. Most companies that are not completely dominant in the absence of government want to be regulated in certain ways, because it helps entrench them, such as Telcos, defense contractors, "software" consultancies like PwC, etc.

I've observed that your average Joe will immediately think a regulation is good for "the people" and bad for "the company" without context. In reality, it's important to determine if it's a _good_ regulation: i.e., one that charges a proportional cost or mandates an antidote to an externality on society.

If the regulation instead creates occupational or corporate licensing requirements, or really is doing anything besides addressing the externality, you will most likely entrench the bad actors, add some inefficiencies for paperwork, possibly create other unintended consequences, and accomplish nothing.

<comment><USER3> > "'Bigness often cuts against innovation.'

> The term the author needs is 'diseconomies of scale.'"

diseconomies of scale, like economies of scale, are systemic characteristics that change (somewhat predictably) with size.

stagnation resulting from bigness is a self-inflicted dysfunction that is independent of size (that is, it doesn't only happen when companies get big).

and multiple groups working on the same product might not be a dysfunction at all. it could just be risk mitigation (that only a large company can afford).

my point isn't so much to disagree, but to redirect. organizational dysfunction increases as companies get larger because of "coordination neglect" (it gets harder to keep all the initiatives pointing in the same direction as communications channels necessarily multiply with size).

but risk socialization strategies at large companies leading to things like "too big to fail" bailouts really chap my hide. those companies should go bankrupt--not out of business, but reorganized, with the execs replaced, their compensation clawed back, and possibly sued for malfeasance.

the bigger you are (or equivalently, the more power you have), the bigger the consequences and the more important it is to face justice from wrongdoing, the exact opposite of the direction we're headed right now in the US (e.g., recent presidential pardons).

<comment><USER4> > stagnation resulting from bigness is a self-inflicted dysfunction that is > independent of size (that is, it doesn't only happen when companies get big)

How could stagnation resulting from bigness happen to a company that hadn't gotten big?

<comment><USER5> "Big" is relative. If a company starts falling apart as soon as the founder can't personally manage everyone, it has a disease of bigness, even though it's still small on some absolute scale.

</comment></comment></comment></comment><comment><USER6> Often the investments that are made possible by scale aren't really an economic advantage, but rather an economic tradeoff, and many times it is of the worst kind: a visible advantage (lower variable costs) for an invisible disadvantage (higher fixed costs as well as other cash flow risks).

As an example, we have the story of every single major retail company failure in the last 150 years. Fast sales growth leads to growth in physical presence, which leads to excessive inventory. Excessive inventory isn't the end of the world when revenue is strong...but it _can_ be the end of the world when revenue drops. When the going gets tough, having all your working capital tied up in inventory that isn't moving often leads to the death spiral.

Even Amazon isn't immune. Look at their inventory turns from 2003 vs today. It is absolutely shocking how much they have degraded. Sure, they've had amazing revenue growth from their laser focus on reducing shipping times and costs, but that laser focus has led them to build hundreds of warehouses, and each warehouse you build is going to increase your inventory requirements. I'll fall short of predicting their downfall from the next recession, but from their financial trends, they're not exactly looking much different from Sears or Circuit City or ToysRUs.

<comment><USER7> the difference is that amazon's tech operations can fund their other business, even at a loss (as they had done so in the past iirc).

AWS is insanely profitable, and looking likely to continue being insanely profitable.

</comment></comment><comment><USER8> I don't really see how a return to dispersal of innovation and r&d spending is supposed to help the United States against China. It's just another way for the US to pay for China's gains. Huawei built its business on stolen American intellectual property. It's routers instructions manuals have had the same spelling mistakes as the Cisco models they cloned. Huawei is now at the forefront of telecom innovation but they got into this orbit using a boost from stolen American intellectual property. The biggest change that China is forcing on the United States is a closing of America. When American openness is abused by the Chinese government America must change. But how will we change, and what does that mean?

<comment><USER9> It is worth remembering that the USA became what it is today by stealing British designs and patents wholesale until it had caught up technologically.

<comment><USER10> [https://stratechery.com/2015/xiaomis- ambition/](https://stratechery.com/2015/xiaomis-ambition/)

>And, I might add, from my perspective it's not a big moral problem either: the truth is the United States ran just as roughshod over intellectual property during its rise to power as China does today, and I'm more than sympathetic to the developing world's position that the West is attempting to pull up the ladder behind it: no one was holding Europe or American to task for pollution or intellectual property or workers' rights the way the West does the rest of the world. That doesn't make it "right," it just makes "right" a whole lot more gray than "Xiaomi-are-copycats" complainers are apt to admit.

</comment></comment></comment><comment><USER11> One of the largest and most important "economies of scale" is in complying with government regulation.

Small business are crushed with huge costs (on the order of 10% of Gross Revenue) to comply with government tax, accounting and legal requirements, compared to fractions of a percent endured by large corporations — who have departments lobbying the government to create and refine the laws crushing their future competition.

Solve that, and many of the existing "diseconomies of scale" would become lethal to these large, sclerotic enterprises.

<comment><USER3> yes, aka regulatory capture.

having really read the article (rather than skimming it the first time), i think this gets at the point of the (rather rambling) essay, trying to distinguish legal scale (in which regulatory capture fits) vs. technical scale (the normal kind of scale).

before the 70's, we relied on the latter kind of scale along with a robust focus on decentralizing power, and benfitted from all sorts of innovation (in which government also played a central role with major r&d spending).

these days, we rely on legal scale, just being big and being able to throw your weight around, which hides a lot of waste (like concentrating wealth among those who don't know how to innovate with it). and we're losing, not just against other countries, but compared to our former selves.

</comment></comment><comment><USER12> > Please keep sending me info on what you're seeing in terms of supply chain > disruptions. I think that is one of the biggest stories in the world right > now

Preceding the article and not directly related to it, but imho I also find this subject one of the biggest stories right now and it's a pity that it hasn't yet been discussed on HN the way it should have been (or at least I didn't see it discussed that way), probably because of some active moderation efforts concerning covid-19.

<comment><USER13> Examples?

<comment><USER12> Apple's warning about it was not discussed at all, even though pretty much everything Apple officially says is discussed at length in here. Plus, you would think that seeing images with the streets of Beijing and Shanghai basically empty would have elicited at least a post or two on this website, seeing that just yesterday we had a discussion on the front page about the Paris car traffic being slightly lower compared to last year. There was also the news of China's greenhouse emissions being down by 25% because of coronavirus, again, we're talking about a subject dear to HN users (the environment) which was practically ignored.

<comment><USER13> Thanks.

</comment></comment></comment></comment><comment><USER14> While I agree with much of what is being said, I find the anti-China tone troubling. The monopolization and centralization of the U.S. economy (and thus politics) would be equally problematic, even if China had a democratic government and we had 0% chance of a military conflict with them. The "China is dangerous, we need to be ready for a war with them" subtext, I think, just detracts from the overall point about the problems of bigness in the private sector (which, again, I fundamentally agree with).

<comment><USER15> This sort of complaint is weird to me. Sure, monopolization and centralization in the US would be a problem too, but...that's not what actually exists. We have a number of large companies that probably should be parted out for better competition--something I'm _super_ in favor of--but the state is not actively pulling their levers.

Is criticism of China subject to dismissals of "anti-China tone" when _it describes what 's happening_?

<comment><USER16> It _is_ a problem. There is no need to use hypothetical here.

\- healthcare

This high degree of concentration has been building for years. A study published in the American Economics Review in 2012 found that the share of U.S. communities in which health insurance markets had become "highly concentrated" (using the standard deployed by Federal anti-trust regulators) increased from 68 in 1998 to 99 percent in 2006. The same study concluded that this increase in concentration had caused a seven percentage point increase in premiums over the period.

\- telco

[https://www.groundedreason.com/does-the-u-s-have-a- broadband...](https://www.groundedreason.com/does-the-u-s-have-a-broadband- monopoly-problem/)

The actual list is long. There are 2 more obvious examples.

<comment><USER15> If you don't grok the difference between unhealthy levels of corporate concentration and _every major business in every industry having agents of the ruling party in the org chart_ , I don't know what to tell you.

</comment></comment></comment></comment><comment><USER17> Economies of scale are important but I think the thing is, they hit massively diminishing returns after you get past a critical threshold that is usually industry dependent, but related to the cost of capital to overcome fixed overheads.

For example if you can afford to build a fully automated factory to manufacture your product then you are probably 95% as efficient as a company that can build 10 such factories.

The large companies we have now are exceeding that size by one or more orders of magnitude.

</comment><comment><USER18> This articulates many thoughts I've had over the last few years relating to advantages that China has over the US/west in terms of ability to focus at a national scale versus the power of the west relating to individual incentives.

History shows that the US is at it's strongest when it can focus as a nation on the ends by leveraging capitalistic incentives as the means.

</comment><comment><USER19> What is "legal" scale? He just says "and then there's legal scale" and doesn't define it.

<comment><USER20> Legal scale is being big on paper, such as a single corporate entity owning multiple others. This implies, but does not require, efficient operational amassing of men and capital.

</comment></comment><comment><USER21> They're more important in steel making than in rocket launching.

</comment><comment><USER22> Economies of scale work when you have end to end supply chains and can save incremental transaction costs on raw-ish materials.

They _don 't_ work when you concentrate power in large companies that waste human resources and continue to have large blind spots. Our tech sector would be way more robust in all dimensions if it were made up of thousands of entities rather than these monoliths. As HN as this sounds, we need microservices and service meshes to make capitalism work. Anything else and you get myopic, calcified monopolies, that while they dump huge sums of money into projects, that money is largely wasted.

<comment><USER23> There are limits to that as well - defacto standardization can have boons as well due to the "ergonomics" of many competing standards. It brings to mind the old 90s "tons of sound card options to select installing".

Open standards technically can avoid some of it but the equilibrium tends to involve "defecting" to decommoditize and compete leading to a breakdown anyway.

</comment></comment><comment><USER24> :/ I've got strong opinions here, even if they might be a bit radical to all jam in one post. It is likely that the reforms of the 1970s broke the US [0] and if it wasn't them then something changed (maybe access to cheap oil, maybe other nations recovering from WWII) that really broke the environment where the US understood how to be successful. The US has to ask itself how effective its 'capitalist economic system' really is.

* It has a higher tax:GDP than China [1]. That is to say, the nominal ratio of money siphoned into government vs money retained by private citizens is less free than China's. There isn't really a point of comparison here because the two countries are so different (eg, China has state ownership) but there is some shock value in just how large the US government is in the economic sphere.

* It has socialised access to capital. Large banks have the power to create new money and the US government steps in during crisises to pick winners and losers when the lenders are proven to be incompetent at taking risks (eg, 2008 era). China does this too, but the battle becomes which government is more astute at supporting bad risks rather than which system is more effective. China is probably more long-term strategic, using the money to build useless infrastructure instead of the US using money to uselessly boost asset prices. This point is a huge deal to me and really undermines my faith in the effectiveness of free markets used elsewhere in the system.

* A complicated IP law system where people are prevented from doing things they know are good ideas. China largely ignores this system.

This article teases at one point; which is socialised access to capital favours companies that are too large to compete but can negotiate for loans and are known to government/large investors.

[0] [https://www.epi.org/publication/charting-wage- stagnation/](https://www.epi.org/publication/charting-wage-stagnation/) & _EDITED_ from 1980s, a decade too late.

[1] [https://en.wikipedia.org/wiki/List_of_countries_by_tax_reven...](https://en.wikipedia.org/wiki/List_of_countries_by_tax_revenue_to_GDP_ratio)

<comment><USER25> It has amazed me how much innovation there has been in FDM 3D printers since the patents expired in the mid 2000's. In 2012 Stratasys published an article congratulating themselves for the ten year anniversary of the release of their "low cost" $30,000 3D printer. [1] Meanwhile I'd been playing with my first open source 3D printer which was $1900. The designs did not come from one monolithic corporation but a distributed group of hackers and 3d printing enthusiasts from around the world. Interested parties from all over the world improved on open source 3D printer designs and released their findings for free to be taken up by the community.

8 years later and you can buy a beginner's 3D printer for $250, a very reliable open source machine for $1000, and a super high end machine for $15,000.

To say that patents always stimulate innovation is obviously false to me. Patents may stimulate innovation at times but they also clearly stifle it. I was thinking today how the Prusa 3D printer is no more technologically complex than a pen plotter from the 1980's. If it had not been for patents, many companies could have competed for the high end 3D printer market in the 1990's, prices would have been perhaps a few thousand dollars for a printer in the year 2000, and the spread of personal computers would have led to the same hacking and innovation to lower costs we've seen but perhaps ten years earlier.

And the second order effects of this are I think dramatic. 3D printers accelerate innovation by dramatically reducing the cycle time for iterative development of mechanical parts. In the 1990's if you designed a mechanical part you had to wait weeks for it to come back from a machine shop if you could not hire a 3D printer. With a 3D printer in your office you can get a mechanical sample of your design the next day, and go through 5 design iterations in a week.

Instead of allowing for cheap and ubiquitous 3D printing, we chose to give a legal monopoly to stratasys who got to profit greatly for it. And I think society suffered economically because of it.

It is a source of great frustration to me that people dogmatically believe patents cause innovation. It is quite obvious to me that there are benefits to innovation even without intellectual property protection. Prusa Research still makes all of their products open source and they appear to be a healthy, growing, multi-milion dollar a year business. Chinese clones flood the market and are great for broke students, but those who want more reliability still source from Prusa. It seems there is room in the market both for the OEM and clones as they serve different groups.

The only reason business people love patents is that in a world where patents exist, you have an incentive to collect them. But I think the second order negative effects of this dramatically slow innovation and harm society economically. If Prusa can exist without patents in a market where competitors still use them, we can obviously make functional an entire economy with less intellectual property restrictions.

Unfortunately this is seen as arcane or obscure and nobody cares. Its a HUGE issue that I think affects our ability to innovate broadly but I fear the business community would be against the change we need.

My only hope is that competent and respected economists could examine this issue. People who know China well already know how much innovation can flourish in an open business community [2] but we need to convince the American business community to buy in to IP reform.

[1] [https://www.businesswire.com/news/home/20120217005877/en/Str...](https://www.businesswire.com/news/home/20120217005877/en/Stratasys- Celebrates-10-Year-Anniversary-Industry%E2%80%99s-Low-Priced-3D)

[2] [https://www.bunniestudios.com/blog/?p=284](https://www.bunniestudios.com/blog/?p=284)

<comment><USER26> >The only reason business people love patents is that in a world where patents exist, you have an incentive to collect them. But I think the second order negative effects of this dramatically slow innovation and harm society economically. If Prusa can exist without patents in a market where competitors still use them, we can obviously make functional an entire economy with less intellectual property restrictions.

You make some interesting points, however generalizing one example from 3d printers and concluding "patents are clearly bad" is really oversimplifying the issue by _a lot_.

There are plenty of examples of patents stifling innovation (oftentimes purposefully, where a company buys a patent just so nobody else can use it). There are much more complicated examples though, such as the pharmaceutical industry. At least in the US, which funds most of the world's drug research, the entire business incentive for developing new drugs would evaporate without patents. Now there are lots of problems with the pharmaceutical industry, however developing new innovative drugs (with the intent of profiting from them, often viciously) is not one of them.

Everybody agrees the patent system is broken. The problem is nobody can propose a better alternative.

<comment><USER27> > Everybody agrees the patent system is broken. The problem is nobody can > propose a better alternative.

Here are two proposals, pick the one you like better:

1) Abolish patents completely.

2) Abolish patents, except for pharmaceutical industry.

If anything, proposal number 2 should be strictly better than the status quo.

<comment><USER28> > 2) Abolish patents, except for pharmaceutical industry.

So what are the boundaries we'd place? Only companies whose primary income source is parmaceuticals are allowed to own patents? Are all the non-pharma companies still required to avoid patent infringement?

Or is it that patents can only exist if they're relevant to pharmaceuticals? If so, where do you draw the border? If a pharmaceutical company comes up with a new process for synthesizing some compound Z which they use for their drug, is that patentable? What if it turns out that compound Z is also useful for weather-treating surfaces, and gains widespread use in construction? Now, what if we switch to an alternate timeline where compound Z was invented by a construction company first, and _then_ pharma started to use it? What's the patent situation look like?

#2 seems rather arbitrary to me, even moreso than existing patent law. I'm not convinced it's any better than the status quo, though also it's not clear to me exactly what you mean with it.

<comment><USER27> The point is that the patent system is so deeply messed up an unjust that almost any move towards lessening the applicability of patents is a positive one. In these conversations, someone inevitably comes up with the "but what about the drug research" response.

To avoid any worries that the drug research will cease if drugs are no longer patentable, the practical solution is to leave patents in place for drugs. Drugs are regulated in million of ways already. Patent system already has special provisions applicable only to drugs. Just craft the new intellectual property category that will cover 95% of ways patents are now used for pharmaceutical research and call it a day.

It doesn't have to be justified from first principles or fully cover all the edge cases because: 1) patent system is already justified on purely consequentialist grounds (at least in the US) 2) existing patent system already fails basic sanity checks, let alone perfectly handling all the edge cases.</comment></comment></comment></comment></comment></comment>


File Upload with Cordova that Doesn't Suck - <AUTHOR> http://swantner.tumblr.com/post/43724314036/file-upload-with-cordova-that-doesnt-suck

<comment><USER2> I hadn't noticed Filepicker had that neat mobile solution. Very nice. The only problem I've ever had with Filepicker, is that sometime if you query their returned URLs instantly after you've uploaded a file, there's no file there.

P.S Holy tiny type. My eye sight is failing, it's the end of the day. I'm dyslexic. At least the site doesn't break when you zoom in.

<comment><USER3> Hi there,

Filepicker here. Thanks for the compliment. Regarding the url not showing up immediately: We've been working hard to keep the system scaling and performant. One of those things is to have read slaves and you seem to have beaten our db propagation. I'll take a closer look at that and tune it a bit.

<comment><USER2> Cool thanks. We're working on something where it's quite problematic getting zero byte files occasionally. It's nothing to do with the speed, because the file is always there milliseconds later. I imagine it's just that our callback is triggered by the filepicker.io api moments before the file is available on your read slaves?</comment></comment></comment>


Show HN: Like Python's lru_cache, but for shell functions - <AUTHOR> https://github.com/adtac/shell-fn-cache <comment><AUTHOR> Author here. Not exactly an LRU cache (doesn't remove old elements from memory), but I think it's useful anyway. Lemme know if you have any questions.</comment>


Writing in a Dynamic Language? Naming Matters More. - <AUTHOR> http://www.bitnative.com/2013/10/18/dynamic-language-naming-matters-more/

<comment><USER2> Here's an interesting observation I've found related naming in dynamic languages. As I've been working more with Ruby and Python over the past few years, I've been using and debugging more and more open source code. In the process, I've noticed how naming affects trying to work with and debug code in these languages. In general I've found it more difficult to jump in and figure out code written in ruby than python.

Part of this seems to be the grep-ability of identifiers. In the ruby community there seems to be more of a push towards constructing DSLs, which seems to cause developers to write more generic single word methods and variable names. Searching through a decent sized codebase tends to result in a lot of noise/reuse. In the python world, it seems that methods at least tend to be a little more verbose and more easily identifiable. Explicit imports in python do help quite a bit also.

Has anyone else noticed a similar pattern, or am I being biased here?

</comment><comment><USER3> Yeah, definitely. Since jumping from full time Java to full time Python a few years ago I've learned this lesson the hard way a number of times.. It's definitely worth naming for grep-ability to ease refactorings. I'm sure this post will garner at least a few STATIC TYPING > SCRIPTING LANGUAGE comments, but I think that's short sighted. There are definitely advantages and disadvantages to both. Refactoring and code-findability is where static languages shine. We're lucky that it's a relatively simple problem to solve in dynamic languages via thoughtful naming and unit tests.

<comment><AUTHOR> Great point. I didn't mention findability but that's a struggle in dynamic languages since you must resort to searching for strings. Thus in dynamic languages similar/duplicate function names hinder refactoring and navigation.

</comment></comment><comment><USER4> I don't think the authors's GetByPersonId() goes far enough. I suggest PersonFromPersonID() which puts the return type and the parameter in the function name.

</comment><comment><USER5> Even better approach would be to minimize having business logic in dynamic/weakly typed languages at all. Scripts like JS are most suited for rich GUIs.

<comment><USER6> This is a flamebait, of course. No need to think how to respond any longer, just move along.</comment></comment>


Show HN: Photo Raster- An Advanced Online Photo Editor - <AUTHOR> http://web.appstorm.net/reviews/images/photo-raster-an-advanced-online-photo-editor/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+webappstorm+%28Web+AppStorm%29&utm_content=Google+Reader

<comment><USER2> <http://photoraster.com> direct link, the pricing seems great and also the application seems to work really good. Nice job!</comment>


Saving the Hackathon - <AUTHOR> http://www.tokbox.com/blog/saving-the-hackathon/

<comment><USER2> The #1 way to save hackathons is to stop offering cash prizes to winners. That way people who are coming to the events to make money will stop showing up, and people who show up won't worry too much about winning, and the people who are there for fun/exploration/friendship/camaraderie will be able to build and enjoy whatever they came for. Compare the quality of hackathons with massive prizes in cash or funding (i.e. AngelHack) to those without (i.e. StartupWeekend) and you'll see a dramatic difference.

GroupMe is an outlier, it was a great story for Twilio but it was a huge surprise. We never ever ever sponsored or organized hackathons with outcomes like that as a goal, even after it happened.

People alway asked me why Twilio has always supported building "toys" in our hackathons, contests, etc. - and it is simple. Often in their free developers _want_ to build toys, play, explore, be free to make a mess - and we want to make them happy, and associate being happy with using Twilio. And maybe they'll go back to their day jobs and think of us when a problem we can solve crops up. Sponsors should focus less on getting PR hits and shiny hacks, and more on giving what hackathon attendees want, and the events will be good. Organizers should seriously consider whether sponsors are adding value, and whether the prizes they offer are worth the trade-off.

<comment><USER3> I tend to agree that large cash prizes and thinking that hacks == startups is a recipe for trouble. That said, I sit on the more cynical side of the fence and I'm still not comfortable ruling out prizes all together. I'd like to see an event where people were rewarded for embracing the hacker spirit though (most helpful, best use of new tech, most common problem solved, etc).

</comment></comment><comment><USER4> The general public, including most hackathon organizers and corporate types, have no clue about how long it takes to make software. No one has a build a car in a weekend contest. Even if someone could build a car in a weekend, they find the parts, find suppliers, and plan the design out long before the weekend and have a dozen people on standby to do the work. What you end up with a hackathon is the equivalent of a soap box racer. It looks feasible because it can take you from the top of the hill to the bottom of the hill. But it's not a car.

The entire concept of productivity out of a hackathon is born out of a perpetual misunderstanding and lack of knowledge about software development because the people that organize them usually have always A) found someone else to solve their problems. They have no concept of how long a problem should take to solve. and B) payed money to resolve their problem immediately. Again, they have no basis for how long a problem should take to solve. If someone suggests a hackathon and expects actual results, which lots of people do, those people have not come to terms with the idea that engineering is where the "find someone else to solve it" chain comes to an end.

</comment><comment><USER5> I attended this hackathon.

The biggest problem in these hackathons is that it's more about the pitching than the product.

At this particular one, they even told us, worry about the UI and the pitch, don't worry about the backend.

I've been to 5 hackthons total, including 2 Techcrunch disrupts, 2 angelhacks, 1 startup weekends. What I realize is that the winners aren't the best hacks, they are the best pitches, some people only demo their hacks for 2-3 seconds and it's questionable that it even works.

If the business person pitches well, and you have a good designer, you probably win.

<comment><USER6> I've experienced that at other hackathons too. Fake click throughs using photoshop drawn screenshots beat out actual mobile applications with backends. I stopped going to hackathons after a powerpoint beat out my hack. It was a cool idea but the only execution was drawing some pictures. 24 hours to draw pictures. Yup.

</comment></comment><comment><USER7> I guess I'm different to the target audience for this article. I go to hackathon for fun and a change of scenery. I don't expect my hackathon project to turn into a new startup. I use them to test out new ideas. With the bigger better organized ones like TechCrunch Disrupt I get to meet useful people in companies with APIs I may want to use in the future. I usually go with buddies and we stick it out and produce something at the end.

I've learned lots under the pressure of hacking fast and loose to get a product built and will continue to go for that reason. I'd love to hit a big idea just right and have something sustainable to follow up on of course but I'm okay with just having fun, meeting interesting people and learning.

</comment><comment><USER8> I was at the hackathon too, and had a good time. It certainly felt a lot more like a Startup Weekend than a traditional hackathon- there were people there that had ideas they'd clearly thought about for a very long time, and wanted to continue to work on after the event. That's awesome. But I suspect I wasn't the only developer there that wasn't willing to make that kind of a commitment to a project, and was just there to work on some interesting ideas.

So, I suspect the key here is communication, and setting people's expectations before they walk into the room. As it happens in this case, I don't think the judges on Sunday participated in the panel on the first day, so they weren't judging based on 'real world' merit- I know of at least one "boring, back-end" solution that didn't even get the chance to present.

</comment><comment><USER9> I participated in an "extended hackathon" last spring called the Boston Innovation Challenge. In addition to the unusual format (2 weeks from kickoff to demos, with mentor office hours offered in the intervening weekend), the best part was the fact that several community representatives showed up with real, specific problems they needed solving. A musician talked about the difficulty of having people serendipitously discover local live shows. The American Red Cross of Eastern MA brought up their problems in connecting with younger, more itinerant citizens to spread disaster prep awareness. Both of these representatives had several teams form around their problems, and a few useful applications actually came out of the challenge. Were they "start-ups"? No. But real problems got solved, and everyone had a blast.

</comment><comment><USER10> When I think about Hackathons, I always think about GroupMe (reportedly acquired for north of $50M). It seems like an example of right place, right time, right technology, right audience. Lightning striking.

"We were at the first Disrupt Hackathon in New York. We had group SMS working on Twilio's API. You could add people to the group using commands on SMS, or you can use an HTML5 webapp. The only problem was that you had to know numbers and type them in. I mean, it kind of sucked. But we added in an offers tab, and in the demo we were talking about the LOST series finale. In the top corner, when you clicked on the offers tab, it took you straight to an actual ad for half-price if you check out the LOST series finale event at Brooklyn Bowl. We basically demoed that we had a working group chat with a functional business model...

We had the idea a couple days before, and after we decided to go in we found it was a massive springboard for acceleration and growth."

[http://techcrunch.com/2012/05/11/from-disrupt-ny- to-a-43-mil...](http://techcrunch.com/2012/05/11/from-disrupt-ny- to-a-43-million-skype-acquisition-groupme-tells-all/)

</comment><comment><USER3> I actually gave a talk with a very similar title back in December at API Days and I'll be giving a second iteration at the API Strategy Summit at the end of the month in NYC (<http://www.apistrategyconference.com/>).

My thesis is that the problem lies in the disconnect between the goals that we think hackers have and the goals that they actually have. If you want to know more about that, watch the video below. But the point where I think we intersect is about direction and the benefits that it can have. Great hacks solve real problems. There's no doubt about it. You should do everything in your power to to put real, visible problems into the hands of developers because they _will_ solve them.

Anyway, good writeup.

-

"Saving Hackathons": <http://www.youtube.com/watch?v=ocY70UORNsk>

</comment><comment><USER11> What I like best about this post is the underlying message you can almost miss. Yeah the hackathons are important; we should save them; software engineers need a place to get collaborative together; and making "simply pretty" apps isn't all that awesome. The message getting to me, however, is that software engineers may not be all that great at requirements gathering. We work out improvements to almost every part of our workflow all of the time (e.g. new languages, ides, postures, etc.), but when was the last innovation for requirements gathering?

If there's a major bottleneck in the process, it's probably the disconnect between client and developer. Not that I'm saying this is an easy problem. It certainly isn't. Perhaps we need a bit more focus on this issue than how to create nicer interfaces, though.

</comment><comment><USER12> I found that having problem statements does energize hackers. As a participant, I've seen a lot of people not having "cool" ideas to work on and instead ending up smashing together a bunch of API's or building another social share app.

To relate to your point of organizing purpose-based hackathons, I've helped organize a hackathon last year, in which we brought in NGO's and had them issue problem statements about specific problems in the third world. Then hackers were encouraged to try to solve these problems using tech. I was amazed at the results -- people had actually built something useful to the world outside the narrow 48-hour time window! And in the end, the programmers seemed happy that they were solving a real problem, of course doing it in their own "cool" way.

</comment><comment><USER13> I agree that it may be unrealistic to expect fully functioning products out of a three day hackathon, but I am continually impressed by the amount that people accomplish in such a short period of time. Extreme time constraints can often be a useful tool to break conventional thinking and prompt disruptive solutions.

Here's two suggestions that might produce a more focused outcome and reduce wasted effort:

1) Engage key stakeholders throughout the hackathon - so that a deeper understanding of their problems is reflected in the hacked solutions

2) Offer an "overtime" session for those who are interested in working with the stakeholder over an extended period (a few weeks or possibly months) to refine the solution

</comment><comment><USER14> I participated in a Hackathon this past weekend where the organizers had formed a panel of technology experts to interface with the charitable organizations that we were hacking for.

This was really excellent, because they met with 12 different charities many times over a period of time. By meeting so many times, the tech panel was able to tease out some really specific ideas and the hackathon ended up being pretty great.

It was my first hackathon and I learned a lot about what not to do. C'est la vie.

</comment><comment><USER15> For the past few years, I've had this idea of creating some kind of hackerspace. The number one rule(s) would be: You must build something original. Or you must be learning how to build things. Software, hardware... whatever. If you don't _make_ then you _are not welcome_.

I've never been to a hackathon, but I wonder if this is the problem when the author says "They exploit developers."

</comment><comment><USER16> Music Hack Day and similar events are great way to meet people, no one expects a product (maybe sometimes there are?) but only a nice weekend to meet similar minded developers.

I am quite convinced that the companies who sponsor are more likely to be looking for recruitment opportunities than hacks that they can monetize. Don't underestimate a good party…</comment>


MoviePass is running out of money and needs to raise $1.2B - <AUTHOR> https://money.cnn.com/2018/07/02/media/moviepass-stock-debt-sale/index.html <comment><USER2> > But the company loses money when its customers use a pass, because it must > pay theaters for the tickets.

This is some dotcom bubble 1.0 level stuff, "we'll sell at a loss and make it up in volume".

> Previous SEC filings revealed that the company was burning through an > average of $21.7 million every month operating MoviePass. In May it blew > through $40 million.

With zero growth to their customer base another $1.2 billion would last them 30 months. But if all goes according to plan they could lose this much faster:

> The service recently passed 3 million subscribers, and is trying to draw in > more as part of the plan to stay afloat. Executives want to reach 5 million > members by the end of the year, a number they say should help make the > business profitable.

Who would be crazy enough to invest?

</comment><comment><USER3> An article was just posted on HN titled "Why does your company deserve more money?" What could their answer possibly be?

Most people only care about the widely released movies. AMC has the $19.99 Stubs A Plus plan where you can see up to three movies a week, any format, you don't have to jump through hoops, and you can buy in advance. I'm sure the other chains are going to follow suite.

From what I have read, AMC is accounting for each movie that you see as a ticket being sold at $8.99 and they give the movie studio 45-65% of the "ticket price". They also have 65% profit margins on concessions. AMC can do it profitable. Movie Pass, can't.

[https://www.marketwatch.com/story/the-spectacular-rise- and-f...](https://www.marketwatch.com/story/the-spectacular-rise-and-fall-of- moviepass-2018-07-09-101033943)

</comment><comment><USER4> We lose money on every sale, but we make it up in volume.

</comment><comment><USER5> The parent company of MoviePass Helios and Matheson around October of last year was trading at highs of $30. Myself and a friend were exuberant saying it was a great short. Should have taken the short position... $HMNY is now trading at 18 cents a share. See the chart [https://yhoo.it/2N30F0B](https://yhoo.it/2N30F0B)</comment>


Coder Talk - A podcast. For coders. By coders. - <AUTHOR> http://codertalkshow.com

<comment><USER2> Great podcast! Take a listen...</comment>


Algebraic Subtyping (2016) [pdf] - <AUTHOR> https://www.cl.cam.ac.uk/~sd601/thesis.pdf <comment><USER2> Also by Stephen (and previously discussed on HN): [https://www.cl.cam.ac.uk/~sd601/papers/mov.pdf](https://www.cl.cam.ac.uk/~sd601/papers/mov.pdf)

As usual, he injects just the right amount of humour. Eg. this footnote in his thesis:

"*This paper is out of print, in Russian, and quite difficult to get a hold of, so the interested reader is directed to a shorter proof by Conway [Con71, p. 105], which is merely out of print."

<comment><USER3> It's not difficult to get a hold of tho

[http://umj.imath.kiev.ua/article/?lang=en&article=10002](http://umj.imath.kiev.ua/article/?lang=en&article=10002)

<comment><USER4> It looks like that volume was produced after this thesis was submitted.

</comment></comment></comment><comment><USER5> From just skimming the intro, this seems like very exciting work. And the formulation of the problem in terms of data flow was really novel to me.

I was surprised that I couldn't find any references to Martin Odersky in the paper, whose work for years at EPFL has been focused on unifying functional and object oriented programming under a sound type system. This work produced the Scala programming language. More recently, he reworked the foundations of Scala using a system he developed called the calculus of dependent object types (DOT) [1]. I couldn't seem to find any references to this in the thesis. It's hard to imagine the author was unaware of this work, but I'm really interested in hearing more about how the two approaches compare.

Anyway, I'm imagining this work could have great applications for things like TypeScript, and maybe even Scala.

[1] [http://scala-lang.org/blog/2016/02/03/essence-of- scala.html](http://scala-lang.org/blog/2016/02/03/essence-of-scala.html)

<comment><USER6> Scala's type inference is not complete; it is marketed as a way to "omit certain type annotations". One of the reasons why Hindley-Milner is so influential is because you really _don 't_ need any type annotations: the inference algorithm always works.

As for DOT [https://www.cs.purdue.edu/homes/rompf/papers/amin- wf16.pdf](https://www.cs.purdue.edu/homes/rompf/papers/amin-wf16.pdf) DOT is an _explicitly_ typed calculus (similar to System F), for which no attempts at type inference are made. So... they're not really comparable at all.

<comment><USER5> Thanks for the insight.

So, I suppose the follow-up question would be whether the techniques of the paper would make it possible to reformulate DOT without explicit types. Sorry if that's an ignorant question.

</comment></comment></comment><comment><USER6> The lesson of "algebra before syntax" is one that I have seen before, and it is very gratifying to see it pay off such dividends here.

There is also discussion on LtU here: [http://lambda-the- ultimate.org/node/5393](http://lambda-the-ultimate.org/node/5393)

<comment><USER7> Ha, seems like ltu is having issues; cached version [https://webcache.googleusercontent.com/search?q=cache:http%3...](https://webcache.googleusercontent.com/search?q=cache:http%3A%2F%2Flambda- the-ultimate.org%2Fnode%2F5393)

</comment></comment><comment><USER8> I've only read the introduction so far - but already it has taught me something. As a lay-person I am finding it very readable and accessible.

I'd always thought that subtyping inference was only something you need for OO style languages. But he begins with two very clear, non-OO, motivating examples and a key insight: failing to support subtyping ignores the data flow of the program.

<comment><USER9> I just had a look at it, and this thesis is really well-written. A beautiful piece of work, with the right mix of concrete examples, abstract concepts, and meta-concepts that describe why and how the author developed their concepts. Can't wait to read more of it.

</comment></comment><comment><USER10> Lots of positive comments. Given that I'm an idiot, can anyone summarise why this is interesting?

My view is that this extends the work possible with the type system at compile time (e.g. in an integer sense, which would be pretty cool if you scoped it as that) but doesn't extend to "real" numbers or byte manipulation of data.

Like do I need this level of structure in my data, and am I being short- sighted by thinking of it as constraining?

Perfectly happy to get smashed to heck in exchange for being enlightened :) Thanks!

EDIT: sorry in advance for the degree of my ignorance.

<comment><USER11> (Disclaimer: I have yet to read the paper.) It's interesting because it's both _important_ and _hard_.

It's important because it allows you to infer types in the presence of parametric polymorphism ("generics") and subtyping ("OOP"). For example, consider this function:

      twice(f, x) = f(f(x))
      twice : forall a. (a -> a) -> a -> a             // OCaml type (no subtyping)
      twice : forall a, b <: a. (a -> b) -> a -> b     // "ugly" type with subtyping
      twice : forall a, b. (a -> a & b) -> a -> b      // equivalent to the above, but maybe nicer to see and reason about

In OCaml, the type of this function would be too narrow, so you wouldn't be able to call `twice` with arguments such as `round : float -> int` (assuming `int <: float`). Stephen's previous work [1] infers the third type (`&` means intersection type).

It's hard because subtypes are hard to reason about. Type inference usually works by solving equations; if you have 3 type variables 'a, 'b and 'c, and you know that

      'a == list[int]
      'b == list['c]
      'a == 'b

then you can infer that `'c == int`. This breaks down in presence of subtyping; for example, you cannot use

      'a & 'b == 'c & 'b

to infer that `'a == 'c` (a possible solution is `'a == int`, `'b == int`, `'c == float`).

Type inference in the presence of subtyping is so hard that _no_ programming language does it currently. There are many tricks and approximations - e.g. Scala does _type propagation_ (if it knows the types of function parameters, it can infer the types of most other variables), and _bidirectional type inference_ (it can figure out the types of anonymous function arguments), but AFAIK there is no existing implementation of it. Hopefully this paper changes that. Of course, there is an argument to be made that writing types in code makes it more readable, and therefore types _should_ be written - in general, I agree with this argument, but type inference can still be very helpful (e.g. you write a function with complicated types and ask the compiler to fill in the type; or you write a number of tiny helper functions with obvious types).

[1] MLsub [https://www.cl.cam.ac.uk/~sd601/mlsub/](https://www.cl.cam.ac.uk/~sd601/mlsub/)

<comment><USER12> Though note that an even better type would probably be

        twice : forall a,b,c. ((a->b)&(b->c)) -> a -> c

(e.g. in MLSub, the type for

        twice (fun x -> x::[]) 1

is the unsatisfying

        (rec a = (a list | int) list)

rather than the expected

        (int list) list

    )

<comment><USER11> You're right, interesting example! Although I'd prefer to "fix" this by incorporating first-class polymorphism [1] with MLsub - I guess non- polymorphic functions satisfying the constraint `(a -> b) & (b -> c)` are quite rare (although I'm sure that _you_ can think of an example).

[1] [https://github.com/tomprimozic/type- systems/tree/master/firs...](https://github.com/tomprimozic/type- systems/tree/master/first_class_polymorphism)

Edit: although on second thought, just first-class polymorphism isn't enough to fix this... any type system where the function `twice` has the same type as the function `three_times` will exhibit the same problem!

<comment><USER12> Non-polymorphic functions of the type `a->a` trivially satisfy it, of course. Also, I think polymorphic functions are the most interesting case where you can't use twice as desired in an ML-like language, so it's too bad that despite the fancier type they don't work too well in MLsub. Here's another example that fails when I'd hope for it to succeed:

      let one = twice (fun o -> o.x) { x = { x = 1 } }

</comment></comment></comment></comment></comment><comment><USER13> I've been waiting for this paper ever since I saw Stephens presentation of MLsub [0] at ICFP 2015. I thought the paper had an interesting take on type checking, and it has given me some ideas that I've been wanting to try out for myself.

I look forward to reading the dissertation over the weekend.

[0]: [https://www.cl.cam.ac.uk/~sd601/mlsub/](https://www.cl.cam.ac.uk/~sd601/mlsub/)

</comment><comment><USER14> Just read the introduction, and it hits all the right spots in explaining why people (including me) have failed to come up with good subtyping in Hindley- Milner world. I expect people to rush to update their various HM-based systems to this new approach. This seems like a really big thing to me.

</comment><comment><USER15> "The primary tool by which this was achieved was not advanced or complicated algorithms, but attention to the minutiae of basic definitions."

</comment><comment><USER16> > Disjoint union is the coproduct in the category of sets, so we have a good > excuse to use the symbol +

This is definitely making fun of somebody

</comment><comment><USER9> [deleted]

Stupid misunderstanding. Sorry, forget what I wrote. I wanted to delete my comment, as it provides no insight and not even an interesting question. But unfortunately the delete button disappeared here in Hacker News.

<comment><USER17> "PhD" stands for "Doctor of Philosophy".

</comment></comment><comment><USER18> And now I know why record-like types are so awkward in many functional languages. A classical type inference just cannot type them requiring heavy type annotations.

</comment><comment><USER10> Thanks. Do you have any useful insights such as programming in a relevant language? Shoot from github first if you want to hulk smash demonstrating competence.

P.S: let me know if I'm not adequately rating your contributions.

<comment><USER19> Incivility like this will get your account banned on HN, so please don't do it here.

We detached this comment from [https://news.ycombinator.com/item?id=13782112](https://news.ycombinator.com/item?id=13782112) and marked it off-topic.</comment></comment>


Mobile Web jQuery And HTML5 Frameworks for Web Developers - <AUTHOR> http://webinsightlab.com/design/10-best-mobile-web-jquery-and-html5-frameworks/

<comment><USER2> Can someone concisely explain to me the benefits of a very javascript heavy way to build your mobile app like Sencha-touch over the more HTML5/CSS based way of jQuery Mobile and Bootstrap?

Also I'm confused why this article failed to mention two of these frameworks

</comment><comment><USER3> I've been doing a lot of research over the past week on all the solutions out there because I'm building a phonegap based html5 app. My goal is to make it as native feeling as possible. The closest to that experience comes from Sencha Touch and Spine.js mobile. However, what I have found is that doing things from scratch is really the best way to get as close to native as possible.

Sencha touch is a bit heavy and you have to do things their way, and there's a bit of a learning curve (not to mention it doesn't mesh well with a lot of the javascript MVC-style frameworks out there). That said, it really is the most complete, best performant option out there.

</comment><comment><USER4> This article was a fail in that it failed to mention sencha touch which is the no brainer choice in this space.

Jquery mobile comes second after this.

<comment><USER5> That's an interesting opinion. How do you feel about the fact that Sencha touch requires the purchase of a license for a commercial app whereas jQuery Mobile does not? IMO that makes jQuery a more attractive choice.

However, I will agree that the article was a bit jQuery heavy; several of the options presented were extensions of jQuery Mobile.

<comment><USER4> It does not now. Sencha updated their commercial license to be free.

</comment></comment></comment><comment><USER6> I feel like Bootstrap should be added to this list. The included CSS and Javascript is amazing and makes development incredibly easy.

</comment><comment><USER7> useful collection ...</comment>


Records and Sealed Types – Coming Soon to a JVM Near You - <AUTHOR> https://www.infoq.com/presentations/java-language-records-sealed-types/ <comment><USER2> Too bad records won't have named arguments, this would really have helped for large records. Kotlin is once again ahead both in time as in design.

<comment><USER3> They don't now but they likely will. See "named invocation" here: [https://cr.openjdk.java.net/~briangoetz/amber/datum.html](https://cr.openjdk.java.net/~briangoetz/amber/datum.html)

Kotlin is actually at a disadvantage when it comes to design. It has little to no influence on the Java platform it targets and its ecosystem (or on the Javascript platform and ecosystem it also targets), and so it is forced to shape its designs to fit its environment, while the Java language can shape the ecosystem and platform with its design. You see this pattern in records vs. data classes, coroutines vs. Loom, and inline types in both languages. Kotlin's solutions are always more complex and less harmonious in their environment; they need more knobs and joints so that they could fit the contours of the existing constructs around it, on which they have no power. Don't get me wrong, it's doing fine with the cards it's got, but it's clear that it does not have the freedoms of a "platform language."

<comment><USER2> > They don't now but they likely will. See "named invocation" here: > [https://cr.openjdk.java.net/~briangoetz/a](https://cr.openjdk.java.net/~briangoetz/a)

This is good news!

> It has little to no influence on the Java platform it targets and its > ecosystem

It certainly influenced the ecosystem by showing what is possible, and making the shortcomings of Java even more obvious. It has replaced Java (and to some degree, Scala) as the default backend language at some shops, because of less boilerplate and null-safety, leading to better and more maintainable code. Its running the apps on worlds biggest smartphone OS. It may not have pull over the JVM's direction, but afaik that had not been a problem so far. Kotlin's performance is on-par with Java.

<comment><USER3> > It certainly influenced the ecosystem by showing what is possible

Not really. The new features are much similar to their ML (and Scala) counterparts, and ML was well-known to Java's original designers. It is simply a matter of priorities and familiarity. It is true that Kotlin made some ideas more familiar to the point that Java was able to adopt them, and that is why Java benefits from Kotlin existing as an option on the Java platform. The Java language tries not to adopt a feature until it has been tried for a long- enough time by a large-enough number of developers.

> It has replaced Java (and to some degree, Scala) as the default backend > language at some shops

Yes, but to put it in perspective, its penetration on the Java platform is around 2-5%, not higher than Scala's penetration ten years ago.

> leading to better and more maintainable code.

That is a hypothesis that some believe but does not seem to have any actual empirical support.

> Kotlin's performance is on-par with Java.

Yes, and that is a big problem for Kotlin. Kotlin was created at a time of stagnation for Java -- Sun's last years and the first years at Oracle -- and when Android was still similar to Java. Those two platforms have now diverged greatly, and will diverge even more, and it will be impossible to have a language that is at once the same on those different platforms and aims not to introduce performance overheads. Kotlin will either split into two languages (like Java and Android's "Java"), focus on one platform, or introduce performance overheads.

</comment></comment></comment></comment><comment><USER4> Serious question: why are there accessor methods on records?

Record fields are final, so they can't be modified. Records can't be extended; so the methods can't be overridden, which means that the accessor methods don't protect the fields from change or allow for redefinition. Accessor methods are not appropriately named for JavaBeans, so that's not the reason either.

AFAIK the accessor methods generated by the compiler are in all ways functionally equivalent to simply accessing the fields directly.

But the accessor methods take up more space and add code to the class which increases class size and could be avoided. It's slightly more cumbersome to use value() instead of just value. And, presumably, compilation takes slightly longer as the compiler (hopefully?) elides the method call and... replaces it with a direct field access.

There must be a benefit to all these costs, but what is it? what is their purpose? why do they exist?

Serious question, I can't work it out and it's driving me nuts.

Edit: turns out I'm wrong, methods can be overridden, I misread an article. It makes more sense now.

<comment><USER5> There are things such as arrays that you cannot really make immutable as things are at the moment. So you will have to override the accessor and provide a copy of the array. If the components were fields you would not be able to do this.

Also if you are designing APIs for others to use. You might in some situations want to expose an interface instead of an actual record. As records are difficult to evolve. So having methods are much easier than fields in those situations. For example, the JDK itself mostly plans to use records behind interfaces.

<comment><USER4> It's not clear that this is how records work though. I think only the top level fields are final - I don't think there's an expectation that the array contents would be immutable - and since you can't redefine the methods, this would have to be done by the compiler and I don't think that's the case.

Also, same problem happens with fields which are instances of classes; although the record is mutable, the instances are not. So I don't think that's the answer.

I also don't think records can implement interfaces.

<comment><USER5> Yes, you can override accessors and mutability is the main reason. It has been discussed a number of times on the various amber mailing lists, here is one [1].

Yes, records can implement interfaces. The syntax is {ClassModifier} record TypeIdentifier [TypeParameters] RecordHeader [SuperInterfaces] RecordBody

[1] [https://mail.openjdk.java.net/pipermail/amber-spec- experts/2...](https://mail.openjdk.java.net/pipermail/amber-spec- experts/2019-March/001046.html)

<comment><USER4> OK thanks. I misread an article as saying that records couldn't be extended, but on rereading, it actually said that java.lang.Record couldn't be extended other than by declaring a record. That makes a lot more sense, and certainly explains the use of methods instead of fields. Thanks!

(I continue to dislike the syntax, FWIW)

</comment></comment></comment></comment></comment><comment><USER6> It will be interesting to see how Java developers who argued against functional programming will react to these features.

<comment><USER3> The Java community has the population of a mid-sized country and is far from homogenous on any axis, and so the 0.1% of Java developers who use it to, say, write embedded control software [1] outnumber those who do it in Rust at least 100 to 1, and the 1% of professional Java developers who use monadic (ish) composition for IO [2] outnumber those who use it in Haskell 50 to 1.

So there could be a million Java developers who'd like to see more functional features, a million who'd like to see less, and then a group the size of, say, the population of Ireland that doesn't really care (with a sampling error of several Haskells).

[1]: [https://www.aicas.com/](https://www.aicas.com/)

[2]: [https://docs.oracle.com/en/java/javase/14/docs/api/java.base...](https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/util/concurrent/CompletionStage.html)

<comment><USER7> Unfortunately, many of us tend to run into the 99% of professional Java devs still stuck in the old, almost meme-level culture of pre-Java 8, where:

* var is a sin (if the Java version is even high enough to utilize it)

* Methods frequently have 3 arguments by default * Getters and setters are nigh-on useless and verbose, existing primarily because one doesn't trust the coder next to him

* Names are atrociously long and laid out in a way auto-complete helps zilch (25+-char names are not uncommon even for local variables)

* Methodology is still primarily stuck in its old GoF OOP AbstractCreatorFactoryFactory ways

Java is doing good and making leaps to improve. I can't say the same for the culture, which is mostly due to it attracting tons of people who have no innate skill or desire to learn programming, mostly there to occupy a job that pays decently well and make zero effort to improve. Or worse, it used to attract those kinds of people, who now occupy senior/principal/lead positions and enforce the old way of programming under the guise of "consistency" (Consistency is important, but using it as an excuse to not adapt is simple abuse). That attitude is a lot less prevalent in Haskell communities, where the environment itself preselects for programmers with an innate interest.

<comment><USER8> Sometimes I wonder where the blame truly lies. Is it complacent developers? Or a decade of bad practices encouraged by big frameworks? Probably a bit of both and now we have a vicious circle. Unfortunately, there's real demand for poor software quality in our industry, for good and bad reasons.

I moved to Scala as my main language on the job because I wanted to make sure I'd work with coworkers who are open to adapt and learn new things. But I cannot deny the churn has a real cost if you aren't careful.

<comment><USER3> I think the blame lies with those who fail to understand that you cannot compare the "culture" of an ecosystem the size of a university with the "culture" of an ecosystem the size of the country that contains it, and several others like it. Go to a Java shop that does robot control, sensor fusion, simulation, formal methods or spacecraft orbits, and I guarantee you that you'll find coworkers that are open to adapt and learn new things, things that are probably far more important, and interesting, than typeclasses and lenses.

<comment><USER8> Surely, but I'm not in these fields. And it's like screening and interviewing candidates: I need to pick proxy metrics when I evaluate employers.

</comment></comment></comment></comment></comment></comment><comment><USER9> So I have not used Java in production until recently. I was working with languages like C#, Go, Python, Ruby, etc. and built significantly large services in those (10 - 50 MAU). Coming back to Java 8 I was surprised that language made little to no progress, and was significantly painful to use with modern async eco-systems. I still had to review IDE vomit, and people were happy doing so. This has changed recently but records/sealed types is one such example of something that should have been done way back in time. Unfortunately that has been not the case; project loom is still exploration phases. I wonder how many people are bothered by this and moved on to different platform/language due to these shortcomings.</comment>


Ng vs React vs Vue - <AUTHOR> https://mdbootstrap.com/angular-vs-react-vs-vue/ <comment><USER2> Cookie notification - mm OK...

Do you allow this page to send you notifications? .. NO! WTF, it's my first visit and I know nothing about it.

Scroll a bit ... popup layer covering content ... Fuck off! Close window with prejudice.</comment>


Compiler Explorer – now with side-by-side compiler comparison - <AUTHOR> http://gcc.godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(j:1,options:(colouriseAsm:%270%27,compileOnChange:%270%27),source:%27//+Compare+multiple+compilers+at+once%0A//+using+the+!%27%2B!%27+button.%0Aint+testFunction(int*+input,+int+length)+%7B%0A++int+sum+%3D+0%3B%0A++for+(int+i+%3D+0%3B+i+%3C+length%3B+%2B%2Bi)+%7B%0A++++sum+%2B%3D+input%5Bi%5D%3B%0A++%7D%0A++return+sum%3B%0A%7D%0A%27),l:%275%27,n:%271%27,o:%27C%2B%2B+source+%231%27,t:%270%27)),k:27.612542007477654,l:%274%27,n:%270%27,o:%27%27,s:0,t:%270%27),(g:!((h:compiler,i:(compiler:g62,filters:(b:%270%27,commentOnly:%270%27,directives:%270%27,intel:%270%27),options:%27-O2%27),l:%275%27,n:%270%27,o:%27%231+with+x86-64+gcc+6.2%27,t:%270%27)),k:26.189215099875707,l:%274%27,m:100,n:%270%27,o:%27%27,s:0,t:%270%27),(g:!((h:compiler,i:(compiler:icc17,filters:(b:%270%27,commentOnly:%270%27,directives:%270%27,intel:%270%27),options:%27-O2%27),l:%275%27,n:%270%27,o:%27%231+with+x86-64+icc+17%27,t:%270%27)),k:46.19824289264664,l:%274%27,n:%270%27,o:%27%27,s:0,t:%270%27)),l:%272%27,n:%270%27,o:%27%27,t:%270%27)),version:4 <comment><AUTHOR> Coming soon too: a diff view between two versions. Visual Studio is also coming soon, thanks to some help from Microsoft. The main holdback is the windows part of everything...(isn't it always!)

<comment><USER2> Awesome!

</comment></comment><comment><USER2> It would be interesting to see visual c++ on there too, although I imagine both the practical and licensing aspects make this too difficult

</comment><comment><USER3> I guess if you would add a Turbo theme, mr Jason Turner will be the most happier person. :)) .. However it looks great as it is now. GG

<comment><USER4> Turbo styled theme would be awesome

</comment></comment><comment><USER2> Ooh nice, I like being able to compare two compilers or options</comment>


Building a chat app in 8 minutes with Phoenix - <AUTHOR> https://elixircasts.io/chat-room-in-8-minutes <comment><USER2> I'm in the very early stages of building what will be a pretty large web app with Phoenix and so far I really like it.

I have a lot of prior Rails / Flask experience and minimal Elixir experience but you can still figure things out for the most part.

It's kind of funny but, even at this Elixir newbie stage I feel more confident reading and tracing most Elixir code vs Ruby.

<comment><USER3> Yeah, it's interesting, I've had the same experience. There's not so much magic lurking beneath the surface. Things are relatively easy to track down when you do need to figure things out; otherwise, things are pretty intuitive.

And when it comes to performance, threads and queueing, not having to deal with duct-tape and gum solutions like Resque (Ruby's "One Ring" (I love it and I hate it)) makes such a big difference.

</comment></comment><comment><USER4> Great screencast, Alex!

The best tools are the ones you don't even notice, and Elixir is an absolute pleasure. You get to focus on the problem with little ceremony. Chat is a really interesting application of Channels, too.

It's especially interesting to me as my team and I are working on a hosted API called Chatkit that makes it equally easy to add real-time chat to your applications, no matter what technology you're using: [https://pusher.com/chatkit](https://pusher.com/chatkit)

In addition to basic chat data, we also manage, "Who's online", typing indicators, rich media... And more

I highlight those features in particular because I am especially curious what that would look like with Elixir and Pheonix? Managing chat data, especially at scale is quite a hairy problem.

By the way, it simple/clean to subscribe to Elixir Channels on other platforms like Android and iOS, for example? One place we think we can add a lot of value is X-platform client SDKs (JavaScript, Kotlin, Swift, etc.)

<comment><USER5> Phoenix has Phoenix Presence for managing the "Who's online" feature. We use replicated CRDTs to transparently manage the presence state across the cluster: [https://dockyard.com/blog/2016/03/25/what-makes-phoenix- pres...](https://dockyard.com/blog/2016/03/25/what-makes-phoenix-presence- special-sneak-peek)

As far as native platform clients, we have all major channel clients covered across community libs – Swift/objc/Java/C#

</comment></comment><comment><USER6> I cried in pain when I got to securing my app (uberauth, guardian etc). There's too much to grasp and I ended-up just copy pasting code in frustration.

Elixir & phoenix are fun though. I really like how much easier it is to test an elixir app (functional language).

<comment><USER7> You can use Coherence. It's basically Devise for Elixir:

[https://github.com/smpallen99/coherence](https://github.com/smpallen99/coherence)

<comment><USER8> I've been coding Elixir professionally for a few years, and working in security for longer, and I recommend against using Coherence for anything but toy apps. It's a fairly full-featured Devise-substitute, but the code quality isn't great, and a lot of the less-used features haven't had any sort of real- world testing. There's been a few trivial, high-severity security vulnerabilities in it, and I wouldn't be surprised if more are hiding.

For example, when I last read through the codebase it was common to find features that simply wouldn't work, because the code referenced hardcoded parts of the sample application.

You'll also going to run into a lot of issues trying to migrate off of Coherence if you ever need to support anything other than form based username / password login.

I think it really is worth the effort to go with Ueberauth [0]. You'll need to do more work upfront, but the maintainability gains will quickly pay off. You can even use :ueberauth_identy [1] to provide username / password based auth without too much trouble.

[0] [https://github.com/ueberauth/ueberauth](https://github.com/ueberauth/ueberauth)

[1] [https://github.com/ueberauth/ueberauth_identity](https://github.com/ueberauth/ueberauth_identity)

<comment><USER7> I agree about Coherence. It's good for starter apps, but becomes a liability for anything more serious. Like you say, too much stuff is hardcoded, and moving away from it is painful.

I don't agree about ueberauth though. It assumes too much knowledge on the part of the developer, and is insufficient if one is looking for a "plug and play" authentication solution. I used it with Guardian but in the end moved away from it because using JWTs for authentication is just not a good idea.

<comment><USER8> I agree about using JWTs for authentication being a poor idea :)

Ueberauth definitely isn't a turnkey solution, but I'm not convinced that turnkey solutions for authentication are possible for real use cases. It's only going to be so long before you run into a customer that needs to integrate you into their SSO provider, and even Devise isn't going to help you then.

What Ueberauth needs, in my opinion, is a hex, built on ueberauth_identity, that adds support for everything people have grown accustomed to from Devise, like password resets, out of the box. You'll still need to do the manual work of mapping credentials to your user resource, but at least you'll be leaving yourself open to eventually supporting other authentication methods, without too much carrying cost in the meantime.

Elixir will get there eventually though :)

</comment></comment></comment></comment></comment><comment><USER9> I've been writing an API in Phoenix for a high message volume high user count application and it's pretty amazing how little code I have been writing thus far.

Some concepts are a bit weird like GenServer but it completely decouples your application from your state.

Writing tests was intuitive and one of the few times I've been doing TDD that really felt faster than manual testing.

<comment><USER10> Elixir turns from wonderful to magical once you grasp the GenServer concept and learn about its extensions, namenly GenStage. The producer/consumer pattern and the back-pressure logic will allow you to build incredibly scalable, resilient systems. When I first saw it in action, I was mesmerized.

</comment></comment><comment><USER11> Here is another write-up that builds the same thing (and reads a bit nicer):

[https://medium.com/@Stephanbv/elixir-phoenix-build-a- simple-...](https://medium.com/@Stephanbv/elixir-phoenix-build-a-simple-chat- room-7f20ee8e8f9c)

</comment><comment><USER12> You can't do a build-X-in-low-Y-minutes trope when X involves implementing 30+ line classes.

EDIT: This comment was not appropriate, I apologize.

<comment><USER13> Why not?

<comment><USER12> The build-X-in-low-Y-minutes trope implies that something is _trivial_ to implement (usually by importing middleware that does the heavy lifting). A 30 line class is not trivial.

<comment><USER14> > The build-X-in-low-Y-minutes trope implies that something is trivial to > implement

I think it just implies that the reader can do it without prior knowledge, and that Y minutes is surprisingly small.

You wouldn't write "build a blog in 80,000 minutes" even if it could be done with one line of code. And you wouldn't write "build [complicated thing] 3 minutes" and then show an expert rapidly typing a pre-determined program into an editor.

If a newbie can do it in Y minutes following the tutorial, it seems valid to me.

<comment><USER12> I'll agree the "surprisingly small" interpretation is more charitable.

</comment></comment></comment></comment></comment><comment><USER15> Has anyone used gen stage / flow for their jobs / small - medium projects ? What are some examples where this could be used ? Game server ? I found an example on YouTube about using it in an automation warehouse but that seems too niche to implement

<comment><USER16> We use Elixir at Tinfoil Security for our API Security Scanner, and it uses GenStage quite a bit under the hood. It's a big simplification, but we basically have a producer that emits a stream of "scan tasks" to be performed (things like "scan this endpoint for SQL injection"), and then those are consumed by individual worker processes.

It lets us super easily manage things like rate limiting and throttling, while providing backpressure so that an influx of scans (or scans on large APIs) won't overload our infrastructure.

</comment></comment><comment><USER17> Nice work, Alex!

<comment><AUTHOR> Thanks!</comment></comment>


Teleport 4.3: Modern Replacement for OpenSSH - <AUTHOR> https://gravitational.com/blog/introducing-teleport-4-point-3-modern-replacement-for-openssh/ <comment><USER2> Why is this "modern replacement for OpenSSH" when people use ssh specifically because it's so simple and doesn't have webui? There have been many ssh webuis in the last decade, none of them were "replacements" of ssh, just wrappers for people scared of terminals. What exactly does it do that 20 other ssh wrappers (or even portainer for containers) don't?

<comment><USER3> It's really slick, and provides a client/server architecture with a bunch of extra security on-top. It generates 1:1 certificates between the api layer and the clients, using a full auth service.

I deployed it at a previous position and stopped SSH across all hosts entirely, and just used this.

It rotated all it's own certificates every 4 hours, and each SSH connection used a unique certificate.

I never had any issues with it, and I had the web UI straight up exposed to the internet. It enforces TOTP and user management with the OSS stuff is pretty trivial.

It also did something really cool, which is that I had multiple bastions federated together through a single API, instead of having singular multiple bastions. This meant no configuration to access hosts between prod/stage/test, all a single entry point, it was awesome.

I don't use it today in my current position for a number of reasons, but if I were to go back to a smaller company and had the choice, I would deploy it with no hesitation.

</comment></comment><comment><USER4> Aside from shivering at the mention of "Web UI", I don't quite get what this does that SSH doesn't. The landing page is super useless, and the blog post doesn't exactly explain why a VPN service (since it "removes the need for VPN", it's a VPN) is a replacement for ssh.

Like, "glorious portal radiating encrypted beams into all of your clouds and smart devices", umm yeah okay.

<comment><USER5> Seems like this mainly notes changes in this release.

[https://gravitational.com/teleport](https://gravitational.com/teleport) is the landing page with more feature details.

I think a short list of features interesting to me is:

* SSH CA integrated with whatever SSO you have, removing need to distribute SSH authorized_keys files.

* SSH Bastion & Server with audit logging. Record sessions, who did what. Needed for many security-sensitive environments.

* Reverse-tunnel mode, where devices without public IPs (or a vpn) can connect to your bastion server. Useful if you're deploying computers "in the field" that you want remote access to, without needing additional VPN or port forwarding, etc.

<comment><USER6> > Reverse-tunnel mode, where devices without public IPs (or a vpn) can connect > to your bastion server.

This may be a ridiculous question, but what's wrong with a VPN in this scenario? Or even a SOCKS proxy, which is already widely deployed and supported? You say "without needing additional VPN or port forwarding", but I'm curious what advantages it offers over using a VPN.

<comment><USER5> Just extra pieces to manage. With a VPN, now you need to start worrying about firewall rules (do you isolate clients? What internal resources do they get access to?), IP assignment (now you need to run a DHCP server, or handle static IP allocations). What subnets do you use for your VPN, and what happens if they conflict with the network at some of your locations? Or maybe buy a VPN appliance to do that for you. Then you need to handle VPN authentication...

Lots of that is largely un-needed effort. If you just want to be able to SSH into computers, it's simpler to just have your ssh server connect back.

At small scale, where an ops team can keep track of all the computers individually? yeah, VPN is probably fine, especially if you've already got one. But I think these days, a lot of people are looking at avoiding VPNs outright.

<comment> jon-wood These complications are particularly relevant if you're managing a fleet of devices on networks you don't control, such as on-prem versions of SaaS systems, or consumer IoT devices. In that situation you definitely don't want the device to be sitting around with a back door into your network, and subnet conflicts are often impossible to resolve.

</comment></comment></comment></comment></comment><comment> jon-wood For all the people complaining about the web UI, it's optional, Teleport also has a CLI and if you really want to you can use OpenSSH as the client. Teleport's benefit isn't really the web UI, it's the fact it manages a certificate authority for authentication, hooked into the same authentication used for other things, and full audit logging of what people are doing via SSH.

</comment><comment><USER7> "modern replacement for X" looks to me like about the worst title one could choose for advertising a product.

In networking (and a bit everywhere in engineering) people seem to associate "modern" with negatives, at least as a first impression; so if the tagline you try to sell your product is only "Modern replacement of X", it likely starts at -1 in the minds of most of your targets.

</comment><comment><USER8> Why!?!?

Why do people do this!?

If I want to ssh, I'll use ssh. I do not want or need a "web UI" in or for my ssh client.

Is it because I'm getting old? Do I not understand why these darn kids do what they do? Or has my 51 years on this planet taught me that the KISS principle reigns supreme and that "those who don't learn from history, are doomed to repeat it"?

Is it, in fact, just me who is mildly abhorred by this? Grimacing like Clint Eastwood from Gran Torino?

<comment><USER9> Teleport solves SSH'ing in to a ton of machines on private networks from outside the private network. Teleport handles the auth at its entry point, so you don't need a keypair for every node in your cloud. Just one for Teleport. That's the short pitch.

You can do the same thing w/ a VPN and a good secret store. But Teleport is just another way of doing it and it has some nice tools around it for folks that want it :shrug:

<comment><USER10> > _Teleport handles the auth at its entry point, so you don 't need a keypair > for every node in your cloud. Just one for Teleport._

From ssh(1):

         -J destination
                 Connect to the target host by first making a ssh connection to
                 the jump host described by destination and then establishing a
                 TCP forwarding to the ultimate destination from there.  Multiple
                 jump hops may be specified separated by comma characters.  This
                 is a shortcut to specify a ProxyJump configuration directive.

Auth to the jump/bastion host and then have key(s) on that, or tunnel back the internal auth requests over to your desktop via ssh-agent(1) forwarding:

* [http://www.unixwiz.net/techtips/ssh-agent-forwarding.html#fw...](http://www.unixwiz.net/techtips/ssh-agent-forwarding.html#fwd)

* [https://www.cloudsavvyit.com/25/what-is-ssh-agent-forwarding...](https://www.cloudsavvyit.com/25/what-is-ssh-agent-forwarding-and-how-do-you-use-it/)

<comment><USER11> There are a few differences between an OpenSSH jump host and Teleport: \- you have to actively manage authorized_keys for every person using openssh; Teleport manages a PKI and can be backed by your existing SSO \- it hard to restrict any given user to a subset of hosts (e.g. only allow select few to access prod database); Teleport has RBAC \- hosts with Teleport also get SSH certificates, so you don't need to trust-on-first-use (which everyone has been conditioned to ignore)

</comment></comment></comment></comment><comment><USER12> There's little more than marketing bull on that site. Web user interface? No need for VPN? They precisely miss the whole reason for ssh. It's as if they have no clue what ssh is or does.

<comment><USER13> > It's as if they have no clue what ssh is or does.

It's marketing speak geared towards managers who have no idea what SSH is or does.

</comment></comment><comment><USER14> Hey HN! I Director of Product for Teleport, and that does include CLI and YAML experience. This is a bumper release, with a bunch of fixes [https://github.com/gravitational/teleport/releases/tag/v4.3....](https://github.com/gravitational/teleport/releases/tag/v4.3.0) . Even for OpenSSH users using Teleport in Recording Proxy mode.

As always I love some HN comments. While you do need a running proxy. You can use Teleport without ever having to use the UI.

Here to answer any questions.

<comment><USER15> Hey, tell your marketing people that they did a really poor job. Taking a stab at everyone's beloved ssh? Calling your offering a replacement for it?! Daring! No wonder you're getting all that hate here on HN

<comment><USER14> We love OpenSSH, and you can even setup Teleport in Recording mode. [https://gravitational.com/teleport/docs/architecture/telepor...](https://gravitational.com/teleport/docs/architecture/teleport_proxy/#recording- proxy-mode)

but there are many good reasons to use the Teleport Library. [https://gravitational.com/blog/openssh-vs- teleport/](https://gravitational.com/blog/openssh-vs-teleport/)

</comment></comment></comment><comment> rob-olmos I wish RBAC was part of core rather than a paid addon. Oh well.

<comment><USER14> Hey Rob, We are considering this. Send me mail, it would be good to get more feedback email@example.com

</comment></comment><comment><USER16> For those who are looking for a simple ssh bastion but have no need for all of Teleport features, there is also [https://github.com/moul/sshportal](https://github.com/moul/sshportal). Administration and registration is done through ssh, with no need for a special client or a web ui, and the whole thing is just a single binary which stores its configuration in sqlite (by default).

</comment><comment><USER17> Is this compatible with SCP?

<comment><USER14> Yes [https://gravitational.com/teleport/docs/user- manual/#copying...](https://gravitational.com/teleport/docs/user- manual/#copying-files)

but beware of SCP [https://gravitational.com/blog/scp-familiar-simple- insecure-...](https://gravitational.com/blog/scp-familiar-simple-insecure- slow/)

<comment><USER17> Interesting. Thanks!

</comment></comment></comment><comment><USER18> bleah. solving made-up problems.

<comment><USER19> The problems are very real if you work at any large organisation which has compliance requirements.</comment></comment>


40 Tips for optimizing your php Code - <AUTHOR> http://reinholdweber.com/?p=3

<comment><USER2> > 1\. If a method can be static, declare it static. Speed improvement is by a > factor of 4.

Wow!

     function Prime1() { ...calc one million prime numbers...}

     static function Prime2() { ...calc one million prime numbers...}

Prime2() will calculate the prime numbers 4 times faster then Prime1()? Cool.

</comment><comment><USER3> These range from sensible to utterly useless [1,2,3].

I'd say forget all of this and focus on being a productive developer, building something people want, and ruthlessly avoiding premature optimization. When your application is slow, measure it to find out why, then fix it, and repeat.

1\. Let's take #2, "echo is faster than print" - Seriously, is this what we should be worrying about? I can't detect a difference in PHP 5.2.4 across 100,000 echos/prints, so it must not be very big.

2\. ++i vs i++ to squeeze out 1 fewer opcode?

3\. Using isset($foo{5}) vs a strlen check? I pity the next programmer who has to read and understand the purpose of this code.

</comment><comment><USER2> > Set the maxvalue for your for-loops before and not in the loop.

What does this mean?

<comment><AUTHOR> it means that this:

$maxvalue = 100/10; for($i=0; $i<$maxvalue; $i++){ // Some code }

is much faster than this:

for($i=0; $i<100/10; $i++){ // Some code }

because the value is calculated once instead of ten times.

<comment><USER4> That's not necessarily true. If the compiler is smart enough it won't recalculate the value of a numeric expression which doesn't contain any variables. On the other hand, dereferencing a variable isn't without cost. Of course, in most cases you'd be dereferencing variables anyway in the test clause, so the original idea, compute loop limits before entering the loop, is correct.:

mbp:~/test doug$ time php -r 'for ($i=1; $i<100000000/10; $i++) {$x++;};'

      real    0m5.930s
      user    0m5.867s
      sys     0m0.026s

      mbp:~/test doug$ time php -r '$maxval=100000000/10; for ($i=1; $i<$maxval; $i++) {$x++;};'

      real    0m6.999s
      user    0m6.907s
      sys     0m0.029s

      mbp:~/test doug$ time perl -e 'for ($i=1; $i<100000000/10; $i++) {$x++;}'

      real    0m2.520s
      user    0m2.496s
      sys     0m0.010s

      mbp:~/test doug$ time perl -e '$maxval=100000000/10; for ($i=1; $i<$maxval; $i++) {$x++;}'

      real    0m2.537s
      user    0m2.499s
      sys     0m0.014s

The results are a little different with Python (maxval1.py computes inline; maxval2 divides in advance and uses variable inline)

      mbp:~/test doug$ time python maxval1.py

      real    0m2.134s
      user    0m1.761s
      sys     0m0.276s

      mbp:~/test doug$ time python maxval2.py

      real    0m1.890s
      user    0m1.588s
      sys     0m0.278s

Java shows even more of a difference (again, maxval2 sets variable in advance):

      mbp:~/test doug$ time java maxval1

      real    0m0.174s
      user    0m0.116s
      sys     0m0.040s

      mbp:~/test doug$ time java maxval2

      real    0m0.531s
      user    0m0.125s
      sys     0m0.041s

<comment><USER5> Does anyone have any ideas for what's happening in the Python example? Could you post the Python code?

<comment><USER4> Sure... here is maxval1.py:

      for i in range(1, 100000000/10):
        pass

And here is maxval2.py:

      maxval=100000000/10
      for i in range(1, maxval):
        pass

<comment><USER5> Oh, of course - range() is evaluated once in either case. It returns an array, which is then stepped through. The time difference must have been just some inaccuracy. I guess 'time' isn't the best command to use to test efficiency ... or maybe try adding another 0?

<comment><USER4> Oh, thanks. I redid it using xrange instead of range and the numbers went down to an average (over 20 tries) of about 1.36 sec for maxval1 (which computes endpoint within the xrange) and 1.9 sec for maxval2 (which uses variable in xrange.)</comment></comment></comment></comment></comment></comment></comment>


How to create a buck based c++ project - <AUTHOR> https://firstname.lastname@example.com/how-to-create-a-buck-based-c-c-project-38b85273d6a6 <comment><USER2> What the hell is Buck? Too many web sites start by telling you how to install the latest and greatest. But they never tell you what it is that you are supposed to be installing.

<comment><USER3> From [https://buckbuild.com/](https://buckbuild.com/) "Buck is a build system developed and used by Facebook. It encourages the creation of small, reusable modules consisting of code and resources, and supports a variety of languages on many platforms. "</comment></comment>