Eating Mostly Whole Grains, Few Refined Grains Linked to Lower Body Fat - <AUTHOR> http://news.tufts.edu/releases/release.php?id=208

<comment><USER2> As interesting as hacking the body is, am I really the only one who can't seem to keep up with which of these articles to listen to? I mean, it used to be fat was bad, then it became some fat is bad, some isn't, then carbohydrates became bad (even as that is literally what we are made of) now grains (well, mashed in small pieces but still).

What the hell am I supposed to eat that doesn't take hours to prepare and doesn't cost a fortune?

<comment><USER3> I know there's a perception that nutrition science is churning, and I'm sure that behind the scenes it _really_ is, but at the macro- scale that laypeople care about, aren't the trends straightforward and aren't they unfolding pretty slowly?

* Fat is bad

* Saturated fat is bad, olive oil is good

* Transfats are particularly bad

* Carbs are bad

* Fat's not so bad after all

* Fructose is particularly bad

* Refined carbs are bad, normal carbs maybe not so bad after all, and complex carbs are good

For 50+ years, this doesn't seem that hard to keep up with.

It's also one thing to say that we're "made of carbohydrates" and another thing altogether to suggest that our metabolisms are equipped to process large quantities of purified, metabolically dense nutrients that our ancestors never had access to.

<comment><USER4> Also, not that you particularly exercised it here, but the whole what-did- cavepeople-eat argument is totally retarded. Cavepeople clearly could reproduce a fair amount of the time on the diet they had. That doesn't even a little bit mean that their diet was the diet people were 'designed for' or that that was even remotely related to their optimal diet.

(Which obviously doesn't necessarily mean that refined sugar is either good or bad.)

So we should all stop mentioning our ancestors when thinking about what to eat.

<comment><USER3> Not that I buy into the whole caveman fad, but isn't there evidence that the switch from hunter/gatherer society to agriculture came with a decline in health?

<comment><USER4> Dunno. Offhand, if the HG diet is berries and meat, and the farm diet is bread and more bread, could be. But we already kinda knew that bread and more bread wasn't the best diet; cavemen don't add more information if that's what was going on.

Basically, what I'm saying is that the truth about nutrition and caveman diets are conditionally independent given currently actually-known science about nutrition. If we didn't have science, and all you had was cavemen observations, that might be valid, but we do, so it's not.

(And by "currently actually-known science" I mean very basic things like that we can't make iron from scratch so if we don't eat stuff with iron in it then we get sick, and same with some amino acids, and same with noticing that if you eat 20 cheeseburgers a day you get fat quickly. Not stuff like whether fat is bad or good.)

</comment></comment></comment></comment></comment><comment><USER5> A while back I made a choice to lose some weight and eat healthier. I cut out anything with lots of sugar or refined starches - and deep-fried food. So, I switched from white rice to brown, white bread to whole wheat, and white tortillas to corn. Other than that I ate just about what ever I wanted and ate until I was full, but not over-full.

One of the things I found was that the temptation for sugar went away as long as I cut it out completely. Whenever I had a little, it started to creep back in.

I steadily lost about 3 pounds a week until I'd lost about 40. I was even able to stop taking high blood-pressure meds. That was about a year ago I've kept the weight off. Actually I'm still losing weight, but much slower.

</comment><comment><USER6> I'd be interested to also see a study comparing a regular diet with one that's only whole grains as well as one that is completely grain free. I know that processed grains are definitely starting to show up as really bad for us but I think removing grains entirely is likely to be even better than just going with whole grains.

<comment><USER5> I think whole grains are great. They provide fiber, lots of vitamins, and they fill you up with less calories, so you eat less of the other bad stuff.

</comment></comment><comment><USER7> I can attest to this. I gave up gluten last year. I don't know if I was really allergic. I never had the blood test done. The result is that I pay greater attention to everything I eat and stick mainly to whole grains, vegetables, seafood and dairy.

But I eat a lot more dairy. Something about the diet makes me crave ice cream and creme brulee type things. I must be consuming more fat than I ever did before.

The net result is I lost about ten pounds, which is about 8% of my body weight.

If I wasn't allergic to begin with, I also gave myself a gluten intolerance, so it's not something to enter into lightly. But I feel like a new man.

<comment><USER6> When you say you eat whole grains, does that just mean rice like grains? Whole grain bread still has plenty of gluten in it so I'm interested what your whole grains look like. I'm in the process of converting to a completely grain free diet and it's made a big difference in my sleep as well as my body fat percentages.

<comment><USER7> Yup, that's right. Also quinoa. Grain Free looks pretty intense too.

As someone who tries to keep a low profile (or at least only be noticed for things I think are cool about myself) it's not ideal having such a dietary restriction. But the benefits erase the question in my mind.</comment></comment></comment>


Simplicity Matters By Rich Hickey (Keynote at RailsConf 2012) - <AUTHOR> http://www.confreaks.com/videos/860-railsconf2012-keynote-simplicity-matters <comment><USER2> His emphasis on simplicity is welcome, but I'm not so sure I agree that simple hashes are the best choice for internal data representations. Exposing all the fields of any particular datatype to all clients seems to invite exactly the kind incidental "complecting" he decries.

Every non-trivial program is going to have to define abstract datatypes and I'm not sure how embedding and dispatching on a type tag in a hash is any better than using the more explicit support for dynamic dispatch you find in typical OO languages.

The real problem with most OO is that it mashes a lot of interdependent, mutable state together.

<comment><USER3> > I'm not so sure I agree that simple hashes are the best choice for internal > data representations

I've been contributing to the Clojure community lately. My experience working with hash-maps as the primary data structure has been entirely liberating.

At my startup, we've got an app with Sinatra services, a Rails API, a Node.js web frontend, and Backbone client code. JSON gets passed between them. Being forced to encode keys as strings is a mild annoyance that Clojure's reader syntax avoids, but the real issue is that I've got raw JSON, Javascript domain objects (Backbone.Model), Ruby models (ActiveRecord), and Ruby hashes (hashie/mash/similar). Each has their own idiosyncrasies and interfaces. Of all of them, the raw JSON is most pleasurable to work with. CoffeeScript & Underscore.js roughly approximate 10% of the awesomeness that is Clojure's core data structures, including maps, sets, vectors, and lazy-seqs.

ActiveRecord, for example, makes it super easy to tangle a bunch of objects up. If we had a big bag of functions, they could operate on in-memory hashes, or they could operate on database rows, or they could operate on the result of an API call. It would be so much simpler to reuse code between our main Rails API and our Sinatra service. And we could one-for-one translate functions for non-Ruby services. Instead of requiring a crazy tangled ness of polymorphism and mutable state.

> Every non-trivial program is going to have to define abstract datatypes

Absolutely true. However, Clojure has taught me that you really aught to only define a very small number of those. It's been said that it's much better to have 100 functions which operate on 1 data structures, than to have 10 functions that operate on 10. Clojure's get-in function for example: (get-in some-hash [:some :key :path]) is glorious compared to Ruby's some_hash[:some][:key][:path] because you don't need to go monkey patch in a get_path method. And even if you did monkey patch that in, it won't work for the some_object.some.key.path case, unless you got fancy with object.send and yet another monkey patch.

Look at some of the substantial pieces of Clojure code out there. They may only define a small handful of data structures, but most of those are even defined with defrecord, which produces a hash-like object, which all those 100s of functions work on. The rest are tiny primitives that compose in powerful an interesting ways.

> I'm not sure how embedding and dispatching on a type tag in a hash is any > better than using the more explicit support for dynamic dispatch you find in > typical OO languages

Because you may want differing dispatch & single-dispatch inheritance doesn't let you change your mind as easily. Those dynamic dispatches in Ruby/Python whatever are simply hash lookups anyway. You'll get the same performance either way. Look at the output of the ClojureScript compiler for example. Most code paths dispatch on :op, but you could just as easily dispatch on some bit of metadata, maybe the [:meta :dynamic] key path to have a function that runs differently on static vars than dynamic ones. People are also working on advanced predicate dispatch systems.

> The real problem with most OO is that it mashes a lot of interdependent, > mutable state together.

That's _a_ real problem. But it's not _the_ real one :-)

<comment><USER2> That style of programming was also popular back in the pre-OO days with tagged unions in C. It's pretty easy to write fragile software that way that has a lot of incidental dependencies.

<comment><USER4> How so?

<comment><USER2> It basically makes every single field part of your public API. Once somebody starts consuming that field directly you can never remove it or change it or replace it with a synthetic property.

<comment><USER4> I'd argue it's better in the long term to change the API than to maintain an increasingly elaborate facade as your data structure changes. OOP doesn't solve the core problem; it just lets you sweep the issue under the carpet until it becomes too big to easily deal with.

<comment><USER2> It gives you the freedom to make a lot of smaller changes before you have to resort to explicit versioning. I think the benefits of encapsulation are pretty well established at this point.

For example, the entire Apple CoreFoundation API is exposed as operations on opaque C structs. Cocoa uses that abstraction to wrap them in a very nice, high level API. If the actual layout of those structs was exposed I can guarantee you people would start writing code that used that information directly and Apple's hands would be tied when they wanted to improve their implementations.

Where I agree with Rich is that we should work to minimize mutable state.

<comment><USER4> If the only benefit of encapsulation is to make small API changes easier, is it really worth the additional complexity it adds to your architecture?

A strong theme in many of Rich's talks is that we should prefer "simple" over "easy", as the former will benefit you more in the long run even if it's harder in the short term.

You also seem to be confusing encapsulation with abstraction. Working with data structures directly does not mean you need to operate at a low level.

<comment><USER2> Changing software without breaking it _is_ the central problem of software engineering, as Rich points out himself.

In what sense can you have encapsulation when your entire data structure is exposed to every function that touches it?

<comment><USER4> > Changing software without breaking it _is_ the central problem of software > engineering

But encapsulation doesn't solve that problem, except in very minor cases. Is it worth complecting the architecture of our software for the development equivalent of a bandaid?

> In what sense can you have encapsulation when your entire data structure is > exposed to every function that touches it?

I'm not saying you should have encapsulation... Did you mean to say "abstraction"?

<comment><USER2> _But encapsulation doesn't solve that problem, except in very minor cases._

The WIN32 API has largely remained unchanged over the last 15 years while changing dramatically under the hood in its implementation. With the recent possible exception of Apple's recent bull run this is so far the most lucrative API in the history of the world. And it's made possible by the fact that all the key API elements are exposed only as opaque handles.

I could go on and on with examples like these that are about as far away from a minor bandaid as you can get.

<comment><USER5> I'll give an example of what I think Hickey is talking about. In a OO API you have an

      class Employee
        private boss
        public getBoss()

What IMO Hickey thinks, is that you should have instead a map with a field _boss_. Yes, you can't then change that field name, in the same way you can't change the method name _getBoss_ in the OO API. But you can change the content of that field.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> Slides are here: [https://raw.github.com/richhickey/slides/master/simplicityma...](https://raw.github.com/richhickey/slides/master/simplicitymatters.pdf)

<comment><USER7> Thanks, great to see more material along the same lines as your Simple Made Easy talk. The concepts you outlined in that talk (and in this one) have made a tremendous impact on how I think about creating software. Can't thank you enough.

</comment></comment><comment><USER8> Rich better illuminates these concepts in his "Simple Made Easy" talk (<http://www.infoq.com/presentations/Simple-Made-Easy>) at the Strange Loop conference, where he doesn't pull any OO punches.

<comment><USER9> I know that not everyone agrees with Rich, but I do think everyone who writes software professionally could benefit from watching this talk.

<comment><USER10> And this one (2009):

[http://www.infoq.com/presentations/Are-We-There-Yet-Rich- Hic...](http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey)

</comment></comment></comment><comment><USER11> I don't understand his point on encapsulation of information versus implementation. If anyone can help me here, I would be grateful.

* Should the user of your object/data have to make this distinction? Does he care if age is a piece of data or the result of a calculation?

* Should the user of your object/data know where a piece of information is? Suppose I start of with having a birthdate attribute in my person hash. I later read something about CQRS and decide to build my person as an event store. My birthdate is now in some event hash inside an events list in person. If I encapsulate this birthdate information, the users of my object/data don't have to change.

Encapsulating information/implementation might "complect" person, but doesn't it make it a lot more simple for the users/callers?

</comment><comment><USER12> "We can make the same exact software we are making today with dramatically simpler stuff—dramatically simpler languages, tools, techniques, approaches. Like really radically simpler—radically simpler than Ruby which seems simple.

Why aren't we?"

<comment><USER8> Inertia. That uncomfortable feeling you get when you venture into a new paradigm that you don't understand acts as a barrier and an excuse for people to stay where they are.

<comment><USER13> I'm not sure that's it. I do 100% consulting, and so end up working with lots of programmers.

In my experience, younger programmers who are otherwise competent tend to create the most complicated, generalized systems imaginable.

It's only when you get older, and have done enough systems, that you start to favor the "simple" approach Rich is talking about.

If I had to guess, I'd say that younger, more inexperienced programmers _know_ there is a problem with complexity, and believe that "general", non-simple solutions are the way to tackle that complexity.

A similar thing happens with college students introduced to a new topic. They'll write these elaborate, complicated papers about the simplest of topics -- because they don't understand it well, and don't want to miss anything. It looks and feels very similar to what inexperienced developers do.

</comment></comment></comment><comment><USER14> It seems strange (to me)--maybe in a good way, but would it be preferable to use the JSON literal over the if statement (for the sake of the argument assume in javascript if returns a value)?

val = if (person === "Homer") { return expr } else if (person === "Bart") { return expr } ...

\----

val = { "Homer": expr ,

"Bart": expr , ... }[person];

Would the literal be simpler because it uses _data over syntax_ , or _rules instead of conditionals_?

<comment><USER15> I frequently use the latter in Python. I like that it's easy to construct programatically (because it's data) and it more explicitly handles the various cases (especially the default case).

<comment><USER16> Agree, I do it a lot as a way of selecting functions in a switch statement:

        handlers = {
            'dave'  : call_dave(),
            'ted'   : call_ted(),
            'julie' : contact('julie') }

        handlers['dave']()   # Call dave
        handlers['julie']()  # Contact julie

        [handlers[person]() for person in ['dave', 'julie', 'ted']] # Contact all three

</comment></comment></comment><comment><USER12> "If you want everything to be familiar you'll never learn anything new—you have to break out of that."

</comment><comment><USER17> This is an interesting site and informative. I really impressed from this site.

<http://www.professional-term-paper-writers.com></comment>


Ask HN: Has Anyone Modded the BB-Unit from Disneyland Galaxy's Edge? - <AUTHOR> I find myself in possession of one of the build-your-own BB-8 units from the Star Wars Galaxy's Edge "Droid Depot".
It seems like it is basically a 1st-party replacement for the older licenced Sphero BB-8, except really big (~10 inches high), and reacts to bluetooth beacons scattered around the theme park.
https://secure.cdn1.wdpromedia.com/dam/disneyland/shops/disneyland/droid-depot/BB-8-Instruction-Sheet-064019.pdf
I'm curious if anyone has attempted to mod/hack this? It has a number of inconveniences:
- It has a physical bluetooth remote, but I'd love to be able to pair it to a smartphone app instead.
- It runs on a stack of AA batteries, rather than having a built-in battery with induction charging.
- It goes into a power-save mode after 5 minutes of inactivity, and seemingly the only way to wake it back up is to crack it open and flip the powerswitch off/on again.
- The magnets attaching the head are fairly weak, and the head flies off even on pretty gentle impacts.
It's a little underwhelming as is, so I'd love suggestions on (relatively simple) mods that would improve it. <comment><USER2> I built the R-series unit at the Droid Depot last week, actually. Just today I've finally started to poke at the bluetooth/BLE stuff with it.

Apparently, once powered up, it broadcasts a repeating advertisement packet of some sort. Beyond that, I'm too new to attempted bluetooth tinkering to figure much out.

One thing I'd love to do, is figure out how to mimic this advertisement (like a nearby droid). Even more so, I'd love to be able to mimic the BLE beacons that are supposedly scattered around Galaxy's Edge that the droid may react to. Of course I'm not going to have the opportunity to return to Disneyland with a BLE sniffer enabled phone anytime soon.</comment>


What powers Facebook and Google's AI – and how computers could mimic brains - <AUTHOR> http://theconversation.com/what-powers-facebook-and-googles-ai-and-how-computers-could-mimic-brains-52232 <comment><USER2> The neural network chips are really interesting. Anyone have any detailed articles they on them that they can recommend?</comment>


Tools from EFF's Tech Team - <AUTHOR> https://www.eff.org/pages/tools <comment><USER2> I'm wondering if HTTPS Everywhere and Privacy Badger are on schedule for transition to the Web Extensions API for Firefox? Or will they stop working on version 57?

<comment><USER3> I have a feeling of dread about Firefox version 57.

<comment><USER4> One thing that wasn't clear to me at first was that the point of Web Extensions is ensure that extensions play nice with multiprocessing rather than just to give compatibility with Chrome extensions; viewed in that light, I find it a little less surprising and much more palatable that they're planning to disable legacy extension functionality in a few versions.

<comment> yjftsjthsd-h But old extensions can support e10s?

</comment></comment></comment></comment><comment><USER5> Has anyone else noticed HTTPS Everywhere slowing their Firefox to a crawl? One day I got tired of FF being so slow and started disabling addons one by one, and page loads got ~6 seconds faster when I disabledd HTTPS Everywhere. Yes, it was _that slow_.

<comment><USER3> Are you using the 32-bit version of Firefox? It's the default version that is shown unless you specifically choose the 64-bit version.

<comment><USER5> No, I'm on Ubuntu, so it was in the repos (i.e. it was the proper architecture).

</comment></comment></comment><comment><USER6> If Google nudged sites towards HSTS then https everywhere wouldn't be needed anymore, correct?

<comment><USER7> Seems like Google has done a pretty decent job of 'pushing' most sites towards secure sockets.

This, along with a lot more companies being hacked, blackmailed, extorted, etc - costing them real money - seems to have solved the problem for 99% of sites.

Unless it's a personal blog or something, I won't even use a site not using encryption.

Is HttpsEverywhere even needed anymore, or just used out of habit?</comment></comment>


Show HN: Vim-Gitstatus Plugin - <AUTHOR> https://github.com/ElHacker/vim-gitstatus <comment><AUTHOR> Wrote this simple plugin that just shows the new and modified files in vim's quickfix window, powered by git status.

I find it very useful to easily navigate to the files I'm working with in the current commit.

Hope you find it useful as well.</comment>


Carbon dioxide toxicity and climate change: a serious unapprehended risk - <AUTHOR> https://www.researchgate.net/profile/Phil_Bierwirth/publication/311844520_Carbon_dioxide_toxicity_and_climate_change_a_serious_unapprehended_risk_for_human_health/links/5a7586c645851541ce56e37e/Carbon-dioxide-toxicity-and-climate-change-a-serious-unapprehended-risk-for-human-health.pdf?origin=publication_detail <comment><USER2> Abstract:

> "As atmospheric levels of carbon dioxide continue to escalate and drive > climate change, the issue of CO2 toxicity is not recognised as a global > risk. The toxicity of CO2 for breathing has been well defined for high > concentrations but it remains effectively unknown what level will compromise > human health when individuals are perpetually exposed for their lifetime. > There is evidence from the few studies of long-term low-level exposure that > permanent exposure, to CO2 levels predicted by the end of the century, will > have significant effects on humans. Other studies of slightly higher CO2 > levels may offer clues to effects that may occur when humans experience > lifelong exposure. Unhealthy blood CO2 concentrations have been measured > from people in common office environments where reduced thinking ability and > health symptoms have been observed at levels of CO2 above 600 ppm for > relatively short-term exposures. Although humans and animals are able to > deal with elevated levels of CO2 in the short-term due to various > compensation mechanisms in the body, the persistent effects of these > mechanisms may have severe consequences in a perpetual environment of > elevated CO2. These include threats to life such as kidney failure, bone > atrophy and loss of brain function. Existing research also indicates that as > ambient CO2 increases in the near-future, there will be an associated > increase in cancers, neurological disorders and other conditions. Research > is urgently required to clearly identify the severity and proximity of this > risk, associated with the primary human function of breathing, being a > potential major aspect of climate change."

\---

Every day, I grow more and more convinced that we are just _utterly_ screwed. Global warming (I am starting to favor the Stallmanism "global heating") has us fucked left, right, and sideways. And the leaders of the world do little about it.

It's already too late to reverse course, hasn't been possible for a while. Even then, mitigation isn't coming, not fast enough. There is not enough political will, and a magic carbon- _reducing_ invention is... unlikely (if unpredictable).

From whence cometh hope? (Because I'm almost out of it.)

<comment><USER3> I work close to this space (I'm an algae cultivation technician), and this is the peace I have come to with it. Hope it helps.

> ...a magic carbon-reducing invention is... unlikely (if unpredictable).

The technology to remove CO2 from the atmosphere isn't magic; you feed algae and you let them grow. There's work being done on piping flue gas from power plants through algae to scrub the carbon as it leaves. Even without scrubbing the flue gas, the only real problem with releasing CO2 into the atmosphere is when you dig it up from the ground first, and the technology for turning organic waste into natural gas is very mature.

It is certainly too late to stop climate change, but it's not too late for us to survive climate change. We know how to make energy and chemicals from fresh biomass instead of ancient biomass transformed into petroleum (such as with pyrolysis), we can even sequester carbon while we do it (as biochar), but we don't necessarily know how to integrate all of the required technologies and some of them aren't ready for prime time (hydrothermal liquefaction and cellulosic ethanol come to mind). But research into things like algae cultivation and thermal processing of biomass has been going on since the 80s and the 40s, respectively, and they're actually fairly mature.

The two biggest problems are managing massive amounts of complexity and the lack of political will around actually funding & fielding these solutions. If there were sufficient political will, the first problem would simply be a matter of time and money.

Hope springs eternal because humans are not. We will begin in earnest to rework our global economy and to fix our environment when enough of the old guard have died that their viewpoint is no longer relevant. There's an adage which goes, "progress is made one funeral at a time." If they don't die quickly enough, our climate will collapse which should provide them with sufficient encouragement. It's not something to celebrate but it is something to reckon with.

In short, our bed is made and we're going to lie in it. But tomorrow is a new day.

<comment><USER4> Are those two the biggest problems when it comes specifically to biomass? I hear biomass advocates all over the place saying they're the solution, saying: "we'll run entirely on carbon-neutral corn-derived ethanol and the poo from our vegan diets". Wow, that'd be great, but where are the numbers? Many of these claims go without physics-first principles and real numbers to back them up. For instance, using algae, we'd need an incredibly massive commitment of funds to install scrubbers on all the plants across the world. Even if we did that over the next 30-50 years, which we really can't yet because the tech isn't ready, even if a miracle occurred and we did that, that doesn't solve the existing CO2 heating the planet or the negative feedback loops.

IMO, the real problem with biomass is the sheer scale of the energy system, it's far too large of an industrial base already for algae scrubbers to be effective. IMO, we need planet-cooling measures, increasing cloud cover, increasing albedo, somethjing to prevent heating and the vicious feedback loops in the arctic and elsewhere. Then, we also need to deal with the CO2, which will still be around even if we reduce insolation and heating. I don't know if algae or CCS or some other method will be used for that, but I see that as secondary to the "easier" cooling mechanisms.

<comment><USER5> For waste-stream based fuels, consider first that the _upper bound_ on potential is the incoming feedstock, that is, food, and nets to something like 25% of its energy potential.

And the feedstock is bounded by net primary primary productivity, also referred to as the photosynthetic ceiling. It turns out that humans already lay claim to 20% of this. Replacing fossil fuels (a prerequisite to acheiving net zero emissions) would require another 20% of NPP, an unlikely scenario.

Using crop yields and land area, one quickly realises that under all but the rosiest scenarios, more land is required for biomass fuel production than exists in major technological and industrial nations.

So, no, biomass is not sufficient to sustain present per-capita energy use and populations.

[https://old.reddit.com/r/dredmorbius/comments/2cvap7/the_int...](https://old.reddit.com/r/dredmorbius/comments/2cvap7/the_intractable_problem_of_biomass_for_fuels_is/)

<comment><USER6> you can also use the sea with wastewater as feedstock: [https://www.nasa.gov/centers/ames/research/OMEGA/index.html](https://www.nasa.gov/centers/ames/research/OMEGA/index.html)

<comment><USER5> Interesting, though still bounded by the photosynthetic ceiling, and you're competing with all other marine life.

</comment></comment></comment></comment></comment></comment><comment><USER7> Well that was worrying. Now I'm sitting here in my air-conditioned office building wondering what the CO₂ level is and wishing I could open a window.

Got to buy a CO₂ meter: [https://www.amazon.com/s?field- keywords=CO2+meter](https://www.amazon.com/s?field-keywords=CO2+meter)

<comment><AUTHOR> I think good AC is actually ok, since it's based on venting indoor air out. Definitely depends on the building though.

But my CO2 meter reads lower with AC on. (With windows closed. Windows open is power still)

<comment><USER8> If your AC is the type that vents out indoor air then this makes sense (though smaller AC units tend to just circulate the indoor air after cooling/dehydrating). Depending on the sensor technology in your CO2 meter, it could be sensitive to temperature, so that may be worth trying to exclude as a factor.

</comment></comment></comment><comment><USER9> 'You and your children and grandchildren are going to suffocate' sounds like a much better way for people to get across the dangers of burning fossil fuel than the vague threat of climate change. It's personal and horrifying to contemplate.

<comment><AUTHOR> That's what I was thinking. The warming and climate destabilization effects will be _worse_ (ugh), but this is perhaps easier to describe.

"You know that feeling of a stuffy meeting room? That's what outside will be in 2100 if we don't reduce. Inside will be worse."

</comment></comment><comment><USER10> Increase in co2 equals increase in plant growth. A sealed greenhouse pumped with higher concentration of co2 than normal saw plants grow faster.

Point of view is that co2 may not be absorbed quickly enough or that there may be a limit to the amount that plants can take in: [https://www.carbonbrief.org/rising-co2-has-greened-worlds- pl...](https://www.carbonbrief.org/rising-co2-has-greened-worlds-plants-and- trees)

<comment><USER11> I agree with your statement and would like to add to your comment:

I don't understand when people point to bio mass that could absorb the carbon. This is based on my understanding of carbon history on this planet, which is far from detailed or complete.

We already had the earth covered in biomass before human populations increased explosively. Back then, a looooooong time ago, what as far as I know brought the carbon levels (CO2) down was when dying bio mass was getting buried instead of being recycled. That means most carbon is underneath the earth.

We just spend the last few centuries busily getting it back out from there though.

So as I understand it (someone correct me please if it is wrong), how can we possibly hope that a biomass cycle could keep enough carbon trapped? The past shows that it has to be _buried_ deep inside the earth! That would mean biomass cannot be the solution, even at full capacity it could not bind enough.

I'm happy to be corrected if my understanding is wrong.

<comment><USER12> You can get a certain amount out of growing additional live biomass where there isn't any now.

There was a supposition that one of the causes of the Little Ice Age was reforestation of the Americas after plagues wiped out 90% of the inhabitants. I don't know what the current state of that conjecture is, but I recall the amount of carbon taken up in the process was significant.

If you found a way to eg forest the Sahara, it would be significant on a global scale. Not a one-and-done fix, but significant. Then you would either have to find new land to plant or cut down the trees and not burn them/mulch them to sequester more carbon, but a living forest holds a good bit on its own.

<comment><USER13> There is a fascinating project to turn around desertification of the Sahara: [https://en.wikipedia.org/wiki/Great_Green_Wall](https://en.wikipedia.org/wiki/Great_Green_Wall)

</comment></comment></comment></comment><comment><USER14> I've wondered for a while—very non-scientifically, just idly—if atmospheric CO₂ could account for increased rates of neurological/psychological conditions such as ASD (autism spectrum disorder) and ADD (attention deficit disorder)—to a degree not explained by more obvious factors like increased visibility into the existence of these conditions and ability to diagnose them. Is there any good research into such a correlation, or is it just absurd?

<comment><USER15> At first blush I find it very hard to believe. Your body might have to work a tiny bit harder to maintain homeostasis (since more CO2 in the atmosphere = more ventilation needed to expel it from your blood), but we're dealing with such low levels - and such small changes - that it sounds very improbable to me.

</comment></comment><comment><USER16> I'm blocked from the PDF link. This may be the same article, although it's dated 2016: [https://www.semanticscholar.org/paper/Carbon-dioxide- toxicit...](https://www.semanticscholar.org/paper/Carbon-dioxide-toxicity-and- climate-change%3A-a-risk-Bierwirth/a53f3a6f7a0db8cfd006c51f19c76a68f3386f7e)

<comment><AUTHOR> The link goes to html now. Same author, but it's a 2017 working paper.

</comment></comment><comment><USER17> > Unhealthy blood CO2 concentrations have been measured from people in common > office environments where reduced thinking ability and health symptoms have > been observed at levels of CO2 above 600 ppm for relatively short-term > exposures.

Oh, that's scary. How often does that happen in small offices converted into open offices?! I've often noticed people acting strangely, missing small bugs or acting confused. I have a CO2 detector at home but those are only for extreme levels. How would someone check for unhealthy but not deadly concentrations?

<comment><USER18> I wouldn't worry about it. OP is massively cherrypicking studies. That particular citation is an unreplicated experiment which contradicts literally scores or hundreds of other experiments going back half a century or more, including dozens sponsored by the US Navy investigating cognitive performance at CO2 concentrations all the way up to 20,000 PPM and higher, finding jack squat (which is why submarines are allowed to have such high CO2 levels, which saves on scrubbers & range). Here's one book reviewing CO2 studies: [https://www.nap.edu/read/11170/chapter/5#54](https://www.nap.edu/read/11170/chapter/5#54) For comparison, your bedroom will routinely get to 1-3000 PPM while you sleep for 8-10 hours daily even if you leave the door open; have you noticed any ill effects or that you are borderline retarded while in your bedroom? Probably not... And see my discussion in [https://www.lesswrong.com/posts/pPZ27eZdBXtGuLqZC/what-is- up...](https://www.lesswrong.com/posts/pPZ27eZdBXtGuLqZC/what-is-up-with- carbon-dioxide-and-cognition-an-offer)

Since you have to go to 10,000 PPM or even 60,000 PPM to start finding serious effects of CO2, it's very hard to believe that the Satish effect is real or of the staggering magnitude claimed, or that global warming will, by increasing average CO2 PPMs by at most a few hundred over a century, will have much of an effect. (Not to mention that it would be easy to offset with office plants+better ventilation even if you buy the story.)

</comment></comment><comment><USER19> Please mark the title with [pdf] tag, as it auto downloads.

<comment><USER20> I just got an HTML version with a link to download the PDF, no auto download.

</comment></comment><comment><USER21> Maybe a side business figure out how to e sure building air systems are pumping the correct balance of air for maximum lung efficiency... like pumping O2 into the room but with filters to remove and correctly balance the air. For that matter it seems like some longer term studies to determine what balance if air actually leads to longer life

<comment><USER22> Very sci-fi; suddenly we need a life support system inside our offices because we've ruined the air. Maybe borrow some of these from the ISS:

[https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/200502...](https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20050210002.pdf)

</comment></comment><comment> rich-w-big-ego There are many solutions to the problems that Earth's atmosphere faces. One of the solutions is Accelerated Silicate Weathering[1]. Everyone likes to talk about how screwed we are, but that is yesterday's discussion. Today's discussion is this: How hard are you going to work today and for the rest of the year and for the rest of the decade on advancing the many solutions we have available to this problem? Are you going to be a hero, or are you going to fear-monger? The future of the planet depends on the readers of this comment (and the writer of it, for that matter) more than any of us can know. That's right. It is your personal responsibility to advance the efforts to reduce pollution and C02 levels. Do not abandon us.

[1] [https://www.eoas.ubc.ca/~mjelline/453website/eosc453/E_print...](https://www.eoas.ubc.ca/~mjelline/453website/eosc453/E_prints/AnnRev.28.1.611.pdf)

</comment><comment><USER23> Raise of CO2 level is because of incoming glacial period, not a global warming [0]

[0][https://en.wikipedia.org/wiki/Glacial_period#/media/File:Co2...](https://en.wikipedia.org/wiki/Glacial_period#/media/File:Co2_glacial_cycles_800k.png)

<comment><USER24> The current level is at 400 ppm, while that graph only goes to 300.

<comment><USER25> I'm not sure how they argue that ice core CO2 is representative for the earth, but on the face of it I wouldn't compare Mauna Loa measurements (from near the equator and at thousands of feet above sea level on the largest active volcano on the planet) with those directly above the Antarctic surface.</comment></comment></comment>


Show HN: my YC W17 App "Sellbyme – Blog Monetization as It Should Be" - <AUTHOR> https://www.youtube.com/watch?v=ee5Tl5NtoIY <comment><USER2> You already applied or just thinking to apply ? Anyway, very cool video made. How can I join there?

<comment><AUTHOR> sending soon, thanks for compliment, but any critics also to the product, would you use it on your site?

</comment></comment><comment><USER3> Really cool product!</comment>


Ask HN: How do you monitor your infrastructure? - <AUTHOR> Hello! In the past day I've been researching how to do proper monitoring to our infrastructure, but unfortunately this seems much harder then expected. We need to monitor: 4x AWS Lambdas (errors & invocations), 2x Cloudfront statistics, CPU usage of EC2 instance, requests per second of heroku instance and its response time and few stats about Mongo instance.
If we were running only on AWS stack, Cloudwatch fit our needs, but we have some external dependencies.
I would like to hear, how do you monitor your infrastructure at scale and what tools are you using? <comment><USER2> For my projects I almost always use NewRelic (free works fine, unless something gets really wrong and more info is needed). Additionally, I use my own open-source application and write custom setups to collect data of whatever I want ( [https://github.com/andriussev/server- seer](https://github.com/andriussev/server-seer) ); from there on the data can be processed internally or, I tend to use my wrapper for it on [https://sysplatter.com](https://sysplatter.com).

Obviously, that would not work with log data.

</comment><comment><USER3> I work at a monitoring company (VividCortex) so I mostly use that. I look at CloudWatch for some more AWS-specific things.</comment>


Show HN: DoreenMichele/Phone - <AUTHOR> https://github.com/DoreenMichele/Phone <comment><AUTHOR> There's not much there yet. It's a readme file that points to the background discussion that led to this. The intent is for this to be an open source project.

I have long fantasized about a project that provides smart phones or tablets to homeless individuals, but I want the device to come with some kind of informational or educational component. Ideally, it should be built into the phone and I had no idea how to do that well. In conversation on HN, someone suggested a custom Android ROM. This is a new concept for me.

I have already developed informational resources in the form of various blogs, but I didn't know how to set up a phone so that it points to them. Hopefully a custom ROM will solve that.

Then people can wipe their old phones, install the custom ROM and give them away. This repo is intended to provide the technical piece marrying existing informational resources to the hardware in an elegant fashion so that just giving a homeless person the phone hooks them up with a means to start solving their problems.

My initial concept was that someone would need to develop a class or information packet and that strikes me as inherently problematic. If a phone can be set up properly such that the phone itself prompts people with URLs and other info, that is a vastly superior solution. Homeless people have trouble making it to classes. They lose papers or get them wet. Etc. I think this idea only really works if the phone itself is the instruction manual for how to start accessing online resources relevant to the needs of homeless individuals.

I have a lot to learn about the technical end of things. I would welcome collaborators.

<comment><USER2> Great idea!

Is there any particular reason why this isn't better solved with just a regular old app?

Aside from a whole bunch of technical hurdles involved with a custom ROM, it would probably be easier to. Instead of needing to get this custom ROM on the phone, it would just be a matter of wiping the thing, resetting to a clean OS, and installing the app either through the store, or (possible on Android) by providing a link.

As for the prompts and active 'engagement': I think that's a really, really good idea. And it could be achieved by simply using the phone's built-in features (notifications, badges, alerts, etc.).

I'm not sure if I can be too involved when it comes to building the thing, but I'd love to help out in any way I can.

<comment><AUTHOR> I'm potentially open to it being an app. At the moment, it's just a readme file.

Previously, my best idea was to set up a throw away gmail address, activate the phone using that and then bookmark some websites. I am looking for something better than that approach.

An app still probably needs to set up your Google account on the phone to download it. That might be a problem, especially if this catches on and hundreds (or thousands) of throwaway gmail addresses are needed. I would rather the recipient of the phone set it up with their own email address.

My understanding is a custom ROM is more built in than that and shouldn't require setting up an app store account. Correct me if I'm wrong.

<comment><USER2> I think for iOS you do need an email address to set up an account. But wouldn't an email address be kind of a necessity anyways?

For Android, as far as I know, the app can just be a download from a webpage, so you'd bypass the need to use the app store, and the need for an email address.

One way perhaps to solve the iOS issue (assuming you'd even want to do this for iOS devices) is to do whatever it is that some companies do where apps come pre-installed for new employees. Not sure how that works and what the options are, but that could be a way to avoid the apple app store.

<comment><AUTHOR> My intent is to start with Android, in part because it is familiar, in part because Android phones can be cheap. I currently have a $30 Android smartphone with Tracfone service. Apple products tend to be on the spendy side.</comment></comment></comment></comment></comment>


Jobs of 2030 - <AUTHOR> http://sciencesowhat.direct.gov.uk/future-jobs/future-jobs-what-might-you-be-doing

<comment><AUTHOR> Quite interesting, though it seems that more than a few seem to be extrapolations of current fads.</comment>


Buckminster Fuller - Everything I Know (42 hours of video) - <AUTHOR> http://archive.org/search.php?query=collection%3Abuckminsterfuller&sort=-publicdate <comment><USER2> I stumbled upon Fuller while doing research for a college class. His story stuck with me.

From Wikipedia:

At 32 his daughter died, he became bankrupt, and almost gave up. Instead he By age 32, Fuller was bankrupt and jobless, living in public, low-income housing in Chicago, Illinois. In 1922, Fuller's young daughter Alexandra died from complications from polio and spinal meningitis. Allegedly, he felt responsible and this caused him to drink frequently and to contemplate suicide for a while. He finally chose to embark on "an experiment, to find what a single individual [could] contribute to changing the world and benefiting all humanity."

<comment><USER3> <http://bfi.org/about-bucky/biography/guinea-pig-b>

</comment></comment><comment><USER4> A long time ago in a galaxy far away I was in a first year of university. I soon discovered some library computers were connected with something called Gopher. Soon I was visiting the library not for the books or magazines but for traversing gopher links. Only one other person did the same for hours sometimes until closing time. When I asked this older guy what he was looking up on Gopher he mentioned he was on a mailing-l discussing Buckminster Fuller, Synergetics and an in my view weird but fascinating mathematical philosophical system. Now much older and much more acquinted with philosophy, science, alternative (dymaxion) sleeping patterns and spirituality I still wonder on occasion what this guy's pythagoraeic fascination entailed exactly. Can anyone of my fellow hackers explain more?

Deus - The Architect (about Buckminster Fuller) <http://youtu.be/k2CFDsG_oxg>

You do not belong to you, you belong to the universe... \-- Buckminster Fuller

</comment><comment><USER5> If anyone is interested, I took the time to download all the MP4 files, and made a torrent: [http://cl.ly/3v3R2G111u1X/download/Everything%20I%20Know.tor...](http://cl.ly/3v3R2G111u1X/download/Everything%20I%20Know.torrent) I'll seed when I get time (including overnight), so please seed if you find it valuable :)

I have not watched them all, but they all seem to be working. There is a gap in the numbers in part 11, but that's consistent with the site.

</comment><comment><USER6> Fuller is the best example I can think of (with the single possible exception of Tesla) that supports my theory that genius is composed almost, but not quite, entirely of crazy.

<comment><USER7> I'm not going to research this, but I've seen stats that show the extreme high iq people tend to have a much lower tendency toward real (diagnosed) mental illness. Eccentricity, otoh...

<comment><USER8> That may very well be the case, but there certainly have been some high profile exceptions. Howard Hughes anyone?

<comment><USER9> Nietzsche, Robert Schumann (composer) and Tesla are also notable.

If we factor in brilliant writers who shot themselves. Well, that list is quite long.

<comment><USER8> John Nash too. Not sure how he slipped my mind.

</comment></comment></comment></comment></comment><comment><USER10> The entire first session on Youtube: <http://youtu.be/o6yaSLipeWg>

</comment><comment><USER11> I saw a biographical film about Buckminster Fuller a few years ago. There was a story about his kindergarten teacher expressing concern to his parents about Bucky being "different". One deviant thing she mentioned was that when the children were given blocks to play with and told to build houses, Bucky refused to make normal houses. He would only make structures consisting of triangles. At 5. How amazing is that.

</comment><comment><USER12> Why does the internet archive suck so much? I am on this page, [http://archive.org/details/buckminsterfullereverythingiknow0...](http://archive.org/details/buckminsterfullereverythingiknow01) and there isn't a single file download. No context, no description, I just get dropped into some shitty video with BF (who is awesome) but unknown to many just talking ...

archive.org needs our help. it is like some crappy swap meet / information dumping ground.

<comment><USER8> When I visit that page I see almost nothing _but_ file download links.

<comment><USER12> Yeah, 100s of little files doesn't increase the reach of information, to lessens it. My beef isn't with the information but the presentation. Only the most diehard autodidacts will push through these barriers.

</comment></comment></comment><comment><USER13> Fuller was a crackpot and he definitely sounds off his rocker in the video. Maybe he inspired some things, but I don't understand why he gets so much positive attention. Geodesic domes are horribly impractical (prone to leaks, difficult to use their interior space). Three wheeled cars are dangerous.

<comment><USER14> Comments like these make me wish I had the Karma to down vote. Like others have said, the guy was a genius, maybe one day we'll catch up.

<comment><USER15> For what it's worth, I think you gain karma by writing comments that contribute to the discussion. Your comment could have been something informative, perhaps supporting the point of "the guy was a genius", but as written was little more than "nuh uh you're wrong". (I apologize in advance for also not furthering the discussion.)</comment></comment></comment>


JET, a framework to compile numeric python to C++ - <AUTHOR> https://github.com/wolfv/pyjet <comment><AUTHOR> I wanted to announce JET, a different take on how to make numeric Python much faster! It's very much inspired by TensorFlow -- a computation graph is compiled to C++. And there are constants, variables and placeholders, like in TensorFlow.

But, it's converted to a regular C++ class, and compiled using e.g. GCC instead of being executed with a custom scheduler (as it is in TensorFlow). This makes execution for small programs much, much faster.

Compared to NumPy it's up to 20x faster.

<comment><USER2> If it meets the guidelines, this might make a good 'Show HN'. Show HN guidelines: [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)</comment></comment>


What Is Kickstarter For? Video Games - <AUTHOR> http://blog.airbriteinc.com/post/66886152025/what-is-kickstarter-for-video-games Kickstarter is most effective at financing video and tabletop games, which have raised $189 million of the total $861 spent on the platform. More than $2 out of every $10 spent is on interactive entertainment. Backers are people who play. <comment><USER2> You're welcome to say that based on the money, Mr or Mrs Airbrite, but I'll continue to use it to publish my comic books. And so will a lot of other people - I've seen statistics that the 'comics' category of Kickstarter is now having more money flow through it than the #2 publisher of comics in the US.

YMMV.

I also suspect that the people who make and maintain Kickstarter would disagree with this, given how they've taken steps to largely _remove_ hardware projects from the site. They deliberately left a lot of money on the table by doing this.

<comment><AUTHOR> Mr. Airbrite here. We are saying it based on the money and on total backers, where the 100K video game projects also come in first.

We don't want to discourage you from publishing your comic books. We like graphic novels, and we're going to analyze the category later to see what pledge levels work best.

Looking at our data, I see the average 100K comic book project gets about 3900 backers, and from them, about $62 per head.

<comment><USER2> 100k comic book project? Man I'd be happy with a 10k comic book project. Although personally I designed my latest campaign to _avoid_ digging into the pockets of a few whales - I built it around "moving more books". Promising a ton of extra junk you have to fulfill, and promising more of them to push stretch goals, is a huge trap IMHO.

YMMV, obviously. I think there's a lot more to consider about Kickstarter than "how much money can I raise".

</comment></comment></comment><comment><USER3> It might be more interesting to look at number of funded projects rather than dollar value. Video games dominate because they are so ludicrously expensive to produce - whereas if you look at a typical art Kickstarter the asking sum is a relatively low number (you can get a lot of art done for <$10K).

Side note: I'm not sure if I really want to support another video gaming Kickstarter. With the exception of Planetary Annihilation everything I've backed has turned out far below expectations. Lots of projects shipping after endless delays and not even hitting the original bullet point promises after basically running out of money.

</comment><comment><USER4> Perhaps there's something to be said about the industries getting crowd funded. The video games industry is notorious for being dominated by AAA publishers spending Hollywood-level budgets on mass market blockbusters (that often don't recoup costs) and turning away a lot of traditionalist, purist, or hardcore gamers. Kickstarter has been an excellent platform for indie gamers trying to revive older genres, or perhaps engage in experimental forms of video games.

<comment><USER5> I'm a backer of Chris Robert's Star Citizen. The big appeal for crowdfunding for both Chris and all of us supporting him and the team at CIG is that he gets to make the game he wants, we trust Chris to make a great game, and anything that cuts the Bobby Koticks out of the loop is GREAT!

</comment></comment><comment><USER6> Hey Airbrite folks, it's a _blog post,_ it shouldn't be a blank page with NoScript in effect. That is a failure on your part.

Regarding the substance of the article: I'd argue that you're introducing a bias towards the outlier projects and ignoring projects (like Egypt Urnash's upthread) that don't _need_ huge budgets. Tabletop gaming and comics have both set up thriving Kickstarter communities. Videogames make a big splash on Kickstarter because their fixed costs are so high (which is its own separate problem - they need to invest heavily in art assets which, as patio11 put it, depreciate straight off a cliff).

</comment><comment><USER7> You might want to take into account backers' context. I believe projects related to video games attract wealthier backers who are ready to put more money. As you say it yourself, Veronica Mars raised less money than OUYA but had more backers. Therefore the backers' social and financial context could be another potential explanation of why games raise so much money on Kickstarter. An analysis of who the backers are in each category would make this blog post more relevant.

<comment><AUTHOR> That's an interesting point. We don't have demographic data on the backers, and if KS knows, they haven't released it. Two things to think about. "Torment: Tides of Numenera" raised $4.2 million. If you look at their pledge levels, they got nine backers to pledge $10,000 or more. Yes, those people have a lot of money, but if we assume they pledged 10K and no more for their rewards, then they account for just one quarter of one percent of Torment's funds. The real pillars of the campaign were pledges in the $20-$28 range. Almost 38,000 backers signed on at that level, and their pledges totaled more than $900,000. Our conclusion is that video games are actually more dependent on the mass market than on high-end backers. We'll get a post on this out soon.

</comment></comment><comment><USER8> It felt like the article was just starting and then it ended; makes me less likely to follow future content. Although I seem to prefer longer-form writing than a lot of the internet, so maybe others will be satisfied.

<comment><AUTHOR> It's a series. We're still crunching the numbers. Most people don't read past the first page online, anyway, so there's usually no point publishing long form. You being the obvious exception.

<comment><USER9> I'm surprised there aren't any graphs, though. (of the actual data)

<comment><USER8> Yes! Some graphs would have made this feel much better. I can't believe it didn't occur to me, but I totally see that gap now.

</comment></comment></comment></comment><comment><USER10> I recently played Shadowrun Returns which was funded via the Kickstarter. Although graphics were bad, on many levels it was the best game I played in a last few years. Kickstarter for games give me some hope that there will be some games reaching to niche demographics, like old school players. Majority of new games are targeted for 15 year olds with 15 seconds attention span looking for flashy graphics :(.

<comment><USER11> > Although graphics were bad

wha? Bad? That's harsh. Maybe they aren't flashy graphics, but I wouldn't say they are remotely bad.

<comment><USER12> they look like a game from around 2000

<comment><USER11> Rose colored glasses? Yeah, it's not hyper-realistic, but saying the graphics are bad is harsh.

[http://cdn.pastemagazine.com/www/articles/shadowrun%20return...](http://cdn.pastemagazine.com/www/articles/shadowrun%20returns%201.jpg)

[http://rpgsquare.files.wordpress.com/2012/04/final- fantasy-i...](http://rpgsquare.files.wordpress.com/2012/04/final-fantasy-ix- festival-of-the-hunt.png)

That is the best I could come up with without taking 10 years of searching.

</comment></comment></comment></comment><comment><USER13> This seems to be a more and more prevalent model for funding non-AAA games. A good proportion of the games on the front page of Steam right now are "Early Access", which work in a similar manner - funding upfront, continual development.

</comment><comment><USER14> Kickstarter has several non-electronic consumer products I've seen make it through, as well as table top RPGs and board games.

</comment><comment><USER11> Of the 840 projects over 100k they looked at, 718 were not for games. So, most projects are not for games.

<comment><AUTHOR> That's true. But we didn't say the majority of projects were for games. We're just saying games do better than other projects on KS. 57% of all KS projects fail. So the number of projects in any given category is an indication of project supply but not backer demand. In a sense, it's irrelevant. We assume people are interested in what succeeds on KS, so we're only talking about the top projects. And those are the projects that attract the most money and the most backers.

<comment><USER11> > We're just saying games do better than other projects on KS.

Monetarily, sure. I'd be interested in knowing if games are successfully funded more overall, regardless of the actual funding amount, or if it's just that the money games get is larger.

> We assume people are interested in what succeeds on KS, so we're only > talking about the top projects.

Well, people are interested in what succeeds, but that's different from what succeeds and what's popular. Most projects that succeed on KS fall short of your 100k minimum. How do games fair there. Is their a correlation between what a game asks for and whether it's success.

For example, it would be interesting to know if 95% of games fail if they ask for less than 50k, but over 100k, only 50% fail. And of course, their is the question of whose involved with these projects.

Anyways, I didn't mean to imply you are wrong, only that your perspective is just one perspective, and possibly self-selecting.</comment></comment></comment>


CompuServe is closing - <AUTHOR> http://paperpc.blogspot.com/2009/04/its-over-compuserve-classic-is-closing.html

<comment><USER2> user 70611,3101 password "sleeve!coast"

Last login: circa 1988

I'm stunned that that's still in my brain. I never would have remembered it my brain not been able to pattern match against the ID number in the article.

<comment><USER3> Ha, mine was 103476,1704, password "angry?blink." I remember having a terrible time writing scripts to convince Linux's pppd to dial in and connect.

</comment></comment><comment><USER4> I think my first isp after using compuserve for a while was netcom. No idea what happened to them but they gave me a shell account and pine and tin and gopher and the I has a very happy camper...

<comment><USER5> I was a Netcom guy also. I used them right up until I got cable HSI service (which in my area wasn't until late '01 or early '02). Netcom as a company disappeared somewhere in the late 90s; I don't know exactly what the story was, but I recall getting a letter saying that I was suddenly going to be a MindSpring customer, and then a few months (or so) later, an EarthLink one.

Their domain names and email addresses lived on through all that though, and I still occasionally see an "@ix.netcom.com" floating around.

When I finally canceled my service with them, after getting the cable modem installed, I was pretty bummed that they didn't have some minimal level of service that would have just let me keep my email address. (AOL offered something like this at the time.) I probably would have paid $3-5/mo just to hang onto it because I'd had it for so long.

Ah, well. They were one of the better dialup ISPs I had; I never had trouble getting access numbers in various cities, and they had fairly responsive support. Quality declined precipitously after the Mindspring/EarthLink buyout though; I had no love for _them_ as a company by the end.

</comment></comment><comment><USER6> Anyone else have Q-Link as their first online service provider? For Commodore computers, and in the early 90s it became AOL...

<comment><USER7> I did. I still recall running up $400 for a monthly bill from chatting with random people around the U.S. I seem to recall it was $0.08/min at some point beyond your allotted time.

I downloaded a national BBS list from there eventually, stumbled upon one or two amazing local BBSs, and that was end of Q-Link for me.

</comment></comment><comment><USER8> well, that's sad. compuserve was my "internet" before i had access to the real thing.

<comment><USER9> I started out on Prodigy, in 1992, but Compuserve (started a year or so later) had much better discussion. I made some good friends there.

<comment><USER10> For me it was The Source (anyone remember them?) some time in the early 80's. Then Compuserve, and then GEnie. Those were the days ....

</comment></comment></comment><comment><USER11> Being on Compuserve with a blazing fast 140 baud modem was expensive. My buddy being busted for plagiarizing a paper from Compuserve in 1986..Priceless.

</comment><comment><USER12> Didn't they own the GIF patent? Wonder what happened to that - expired, hopefully? Not fondly remembered.

<comment><USER13> No. And, yes, long since expired. UniSys held the patent, CompuServe was the victim (and the actual innovator, since they invented the GIF format, which happened to use Limpel Ziv...it was a submarine patent for many years until GIFs were pervasive; very nasty business).

<comment><USER12> Ah so I guess compuserve made gif popular, that is why I associate them with the story.

</comment></comment></comment><comment><USER14> I'm surprised they didnt close earlier

</comment><comment><USER15> It's still around?

I was annoyed at the way they'd ding you for more $ if you used a better zip.

However, their wordpuntuationmarkword schema for pw is still not bad.

<comment><USER16> well.. it is somewhat bad ;)

It significantly reduces the keyspace to be searched</comment></comment>


How Michigan took hackathons by storm. - <AUTHOR> https://medium.com/hackers-and-hacking/e6439754078 <comment><USER2> I am an outsider, but I've seen the inside of this machine.

I came to Ann Arbor from LA in 2009 in order to build stuff in a hacker- friendly and foodie town that is a financially rational place to live.

But I didn't expect to find this community of startupy freaks at UM. They are gung-ho in a lets-go-to-the-football-game sort of way. They are often innocent to technological limits, and at times godawfully ruthless. I also notice a particular affinity for building things quickly and then moving on. But they are doing amazing work at MPowered and have roped in a lot of people who would have otherwise marched into corporate oblivion.

UMich hackathon culture is what germinated my current startup, rapt.fm, in January, 2012. A lot of folks involved in MPowered helped the demo get built on that weekend and put in a lot of hours throughout the buildup since then, (including David, the writer of the article).

As great as it is for Michigan, I do think that most of these folks will head out to the Bay Area. But enough will stick around here where the woods run deep and the people are happy.

</comment><comment><USER3> My initial instinct was to criticize this. I think that's some combination of feeling like hackathons are often a coarse method of exploitation and the feeling that this kind of boosterism may be overstated or unnecessary.

But the truth of the matter IMO is that this deserved to be recognized and celebrated. It's really exciting to see environments that expose people to the joy of making things and the realities of making things happen. This kind of culture was foreign at the major liberal arts universities I saw when I was an undergrad 5-10 years ago, and I think it's a positive change. Congrats!

<comment><USER4> There's a big difference between corporate hackathons and collegiate hackathons, I think. The former are exploitative and weird; the latter are inspiring and awesome.

(I organize HackMIT, our big hackathon)

</comment></comment><comment><USER5> I'll throw in my experience. I went to PennApps Jan 2013 after I learned some HTML, CSS, and javascript with some new friends I made. While we didn't associate with Michigan Hackers, we saw the rise of the facebook group, and their "recruiting efforts". They killed it. Fun stuff on the diag(the quad), awesome hack nights. It was sort of a focal point - a bright light to hacker moths, who were always around, but didn't have a community. Mhacks is definitely a force to be reckoned with, and a large part of my first steps towards software development.

Also, MPowered is our university entrepreneurship club. In my experience with them, it is mostly filled with business people trying to find software guys to build their stuff for them. However, apparently there is an incubator that has most of the people that actually build, but I never saw them too much.

Go Blue! Can't wait to see what they will do next year.

</comment><comment><USER6> I think this post serves as a wonderful blueprint as to how one can create a passionate community of individuals with a single goal in mind.

I would love to see another post, detailing the other side of UM's success; the long hours students spent training, and preparing for a hackathon. Everyone loves to make the claim that they showed up at a hackathon, learned how to program some new language, and take top 3 at a hackathon. What many posts fail to address are what was done to rally the students around such causes and get them both mentally and technically prepared for a hackathon.

Great job David et al, can't wait to see what's next!

</comment><comment><USER7> Given most of the post is about the quantity of Michigan students at hackathons or other events, I think it's worthwhile to mention how the school is also unique because it has the advantage of size: there are just so many students there.

I find Penn's breakout achievements far more impressive given their much smaller student body, as well as what Columbia/NYU have done with hackNY.

<comment><USER8> There are many state schools as large as Michigan, such as Penn State, Ohio State, University of Illinois. Illinois in particular actually has a larger CS department but their hackers don't come anywhere close to the turnout Michigan gets. None of the other large schools do. That being said, this shows how impressive of a feat this is for Penn and other small private schools.

</comment></comment><comment><USER9> There's no place to hack like Michigan. Can't wait to see what happens when people start realizing they can hack anything. Not just photo apps, but civilization itself.

</comment><comment><USER10> "A year ago, the University of Michigan's hacker community lay dormant. Today, it is a force to be reckoned with." - says who?

<comment><USER11> It is a bit of an overstatement to say Ann Arbor's hacker community has been dormant. It's the liveliest in the state and Ann Arbor has also long been the startup capital though it is starting to be challenged by Detroit.

However I was there opening night at MHacks and what that crew pulled off was nothing short of amazing. There was incredible energy in the building that night.

</comment></comment><comment><USER12> What do you think about me changing the title to "How hackathons took Michigan by storm?"

<comment><USER10> A bit sensationalist, but gets the point across I guess

<comment><USER12> sensationalist as opposed to the current title? Any other recommendations?

</comment></comment></comment><comment><USER13> University of Michigan grad here. Keep up the good work gentlemen. Go Blue!</comment>


Lack of QA was the problem, not the sloppy coding - <AUTHOR> http://www.enhance-ict.com/2014/02/25/its-the-qa-process-stupid/

<comment><USER2> The argument can be made that you can't test in quality. On the other hand, based on speaking with some Apple developers that I know personally, it would seem that automated testing is not encouraged. Neither unit testing, nor a dedicated team of SDETs for many groups. Contrast that to someplace like Microsoft, where I've worked as an SDET and a skilled, dedicated test team for a product is just the way it is.

<comment><AUTHOR> Hmm, interesting to see such different approaches.

I just don't see how one can guard against regression bugs without having automated tests, especially when software gets complex. And these days, all software is complex :)</comment></comment>


Flat Design = Skinny Jeans: An Interview with Jeff Veen and Tony Conrad - <AUTHOR> http://www.trueventures.com/2013/10/28/flat-design-skinny-jeans-an-interview-with-jeff-veen-and-tony-conrad/ <comment><USER2> The title is a bit misleading. A better title would be "Modern Design = Trust," per this quote:

 _" An up-to-date design tells you that the company is led by smart, modern people. They're on top of things. They get it, and as a result, their customers trust them because they feel like the product or service will continue to evolve."_</comment>


Scaling Ruby Apps to 1000 Requests per Minute - <AUTHOR> http://www.nateberkopec.com/2015/07/29/scaling-ruby-apps-to-1000-rpm.html

<comment><USER2> Must read</comment>


Rome: A Linter for JavaScript and TypeScript - <AUTHOR> https://romefrontend.dev/blog/2020/08/08/introducing-rome.html <comment><USER2> I feel so torn on this project. On the one hand, I want to root for sebmarkbage, who has done so much for the field.

On the other, as someone who used to do some "JS platform" work at a tech company, I really don't want Rome to catch on. Yet Another Standard is really painful for the ecosystem, and while it's obnoxious that you need so many tools, at least we've finally settled (mostly) on good answers for each vertical. TS, ESlint, Prettier, Webpack, Babel.

Now, would it be nice if there were an underlying engine/server that all tools could use to share an AST without reparsing everything? Sure, I guess. Would it also be nice to have one tool that wraps the others, at least when you're getting started? Yes, though I _think_ create-react-app has blazed that trail pretty well.

The thing is, all those tiny little details from Prettier and ESLint and Webpack really matter – Rome will take years to achieve the number of lints that ESLint has, and even more years for the community to agree on which ones matter. Similarly, every corner-case of prettifying will have to be considered anew, and every edge case of bundling rebuilt or reimagined.

I love to see a talented person take on something insanely ambitious, so I wish him luck and hope he proves me wrong. But if Rome succeeds, it'll be a big pain for a lot of people as they try to port everything over, and for the community as they grapple with dueling standards for how things should be done.

<comment><USER3> The ecosystem is already fragmented and dueling. When it says it replaces those tools it means it aims to replace the functionality of those tools, not make them obsolete.

Rome being successful doesn't mean eliminating those tools, it's providing something valuable and giving people an option. If it's not for you then that's okay. Rome is early and is still evolving, including possible areas for extensibility.

I think a lot of people don't realize the sort of capabilities that they're missing out on by not having their tools work together, or sticking with old tooling that cannot innovate for legacy reasons (like Babel). I don't think it's harmful to the ecosystem to advocate for more consolidation, especially around tooling that not a lot of people either like to deal with, or have few maintainers in the first place.

I also think you have me (Sebastian McKenzie) confused with Sebastian Markbage from the React team.

<comment><USER2> Hey there – I do mix the two of you up, but Babel is nothing to scoff at. I've used its internals in the past, and read a good chunk of its source code, so I think I've seen your blames all over. I'm quite appreciative of your past contributions! (and his)

Reading your comment, it sounds like you expect some people might use Rome for some things (say, linting and compilation) and preexisting tools for others (say, formatting and bundling). Is that your intent?

<comment><USER3> Thanks! Yeah, it is, at least for a while since it will take a very long time to reach expected maturity. You can adopt as many or as little pieces as you want. The idea is that once you adopt one of the "tools", you can use the others and reuse the exact same configuration, and ideally you shouldn't even need to do anything else.

ie. For linting we also do dependency verification. So you might need to configure Rome if you put your dependencies on some weird non-standard place. Once we open bundling up, we'll already know how to resolve everything.

Each part should stand on it's own. It's not as if the linter we've released is worse, and the only selling point is that it's going to be part of a larger suite. It legitimately has features and separates itself from the alternatives. eg. extreme focus on useful error messages, powerful autofixes (that operate on an AST rather than insert strings like ESLint), proper caching for even better performance (ESLint doesn't offer a good solution here) etc.

Many are making the mistake in thinking that building Rome is just as time consuming and resource intensive as rewriting each of the tools it's meant to replace separately, it's not. Once we've validated the linter we've also validated the compiler (it's the same thing), our ability to watch files, analyze dependencies, integrate with your editor etc. Sharing so much fundamentally decreases the actual complexity of everything, not increases.

I think it's also important to note that I personally have written an extremely small amount of the implemented lint rules. Our API is just easier to use, and we've focused on setting up the tooling necessary to make writing them easy (although internally in our repo).

Check out [https://github.com/romejs/rome/issues/341](https://github.com/romejs/rome/issues/341), [https://github.com/romefrontend/rome/issues/20](https://github.com/romefrontend/rome/issues/20), and [https://github.com/romefrontend/rome/issues/159](https://github.com/romefrontend/rome/issues/159), if you're interested in seeing how the progress was actually made in the implementation of those rules. The work was spread out over a really long time, and if given complete focus and proper coordination (I was not good at this and kind of let it be organized ad-hoc, which is actually how we got some amazing contributors), then it could have been completed in a fraction of the time.

There's been some overfocus on particular things like minimal configuration and the lack of extensibility but those are not hard requirements and will evolve over time, particularly as we get feedback and people demonstrate the requirements and restrictions they're under. The project understandably involves a lot of hubris, but I do believe that Rome isn't only valuable in aggregate and will have significant advantages even if you only decide to use one piece.

<comment><USER4> Thanks for this clarification. My first reaction to reading the project page was "damn a tool that takes doing _everything_ to a whole new level". If it's adoptable piecemeal, there's a good chance that if it becomes popular I may actually get to work with it someday - but if it were an all or nothing proposal, in my current job the answer is likely to be nothing due to challenges integrating with other technologies we use and get value from.

</comment></comment></comment></comment></comment><comment><USER5> the prevailing consensus esp in the JS world is that 1 tool should do 1 thing. This is fine under the Unix philosophy, but challenges arise due to the combinatorial explosion of config needs, bad errors, and overhead from crossing module boundaries. There are a number of attempts at challenging this status quo:

\- ESbuild (100x faster than webpack in part due to focus on doing a single parse (but also shipping a Go binary))

\- Deno

\- Rome

As we consolidate on the jobs to be done we expect out of modern tooling, it makes sense to do all these in a single pass with coherent tooling. It will not make sense for a large swathe of legacy setups, but once these tools are battle tested, they would be my clear choice for greenfield projects.

recommended related reads:

\- [https://medium.com/@Rich_Harris/small-modules-it-s-not- quite...](https://medium.com/@Rich_Harris/small-modules-it-s-not-quite-that- simple-3ca532d65de4)

\- (mine) [https://www.swyx.io/writing/js-third- age/](https://www.swyx.io/writing/js-third-age/)

<comment><USER6> After spending way too much time debugging issues with frontend tooling, I am all on board for this glorious monotool future. We've definitely gotten some progress out of the massively micropackage approach that Webpack/Babel/etc use, but these days it really feels like we're passing a complexity limit and we need a new approach. The fact that CRA will refuse to startup if you have another version of Babel installed anywhere in the tree, is a pretty good clue that the current approach isn't scaling.

<comment><USER7> Yes, time spent on tooling is time not spent solving real problems. The ability to make unpopular decisions necessary to move a product forward is what separates an expert from an expert beginner.

</comment></comment></comment><comment><USER8> Huge ambitious project and I hope it delivers. If anyone can lead this one to fruition is Sebastian. So this project is in good hands.

Undeniably, it's technically ambitious to build all these pieces under a single umbrella. And then, convincing people who are honestly scared to touch their Webpack config to switch to a new tool might not be easier.

But if Rome booms, it'll truly benefit the community.

<comment><USER9> > convincing people who are honestly scared to touch their Webpack config to > switch to a new tool might not be easier.

If someone can offer me a convincing alternative to webpack I will switch in a heartbeat.

<comment><USER10> Parcel is pretty amazing

<comment><USER11> agree 100%. love how it requires no configuration.

</comment></comment></comment></comment><comment><USER12> There's something that scares me about Rome: it's lack of plugins.

I really like Babel because of its plugins. My project typecheck.macro, could not exist without Babel plugins.

How will Rome support compile time transformations like graphql.macro or typecheck.macro?

Compile time plugins allow JavaScript to evolve super rapidly & make the creation of frameworks that act as compilers instead of traditional frameworks possible.

[1] [https://github.com/vedantroy/typecheck.macro](https://github.com/vedantroy/typecheck.macro)

<comment><USER3> I spoke in this post about how rushing into a plugin system hurt the longevity of Babel and it's ability to innovate. We aren't going to make the same mistake again. Rome will likely eventually have a plugin system, but what that would look like isn't clear.

This is the first release and until there's some actual usage, there's no real way to realistically predict what sort of things people will feel is missing. You can always supplement your project with multiple linters if you feel like it is currently a blocker.

<comment><USER13> Without plugins at first, how open are you to contributions that would normally go into a plugin and not into core?

As someone who works on libraries that don't use JSX, and therefore have to rely on compiler and linter plugins to get support (tagged template literals in my case) I worry that React's dominance will mean that it gets a place in Rome, while other systems are locked out, which only increases React's dominance.

Would you consider an internal plugin system as a first step, where plugins have to be part of the codebase, but intentionally get a restricted API surface? This would allow you to try out and refactor the plugin API over time before committing to it publicly.

<comment><USER3> Depends on what it is I think. We discussed the idea of "expansion packs" which would enable certain funtionality as a sort of "limited config" hack. [https://github.com/romefrontend/rome/issues/173](https://github.com/romefrontend/rome/issues/173)

I specifically call out not allowing smaller communities to grow that don't have the advantage of their community size being forcing functions for support. It's the most compelling reason to me to even have any sort of plugin or custom rules system in the first place.

Although we didn't go through with that idea because they can just be enabled by default since the patterns they're linting for are unambiguous, I guess that applies to any additional ones, although so far the way we've approved these sort of these has been adhoc. There's a strong desire though to formalize some "approval process" for lint rules and more typical project decisions.

</comment></comment></comment></comment><comment><USER14> Sebastian keeps mentioning how all these different kind of tools could re-use the same infrastructure for the things they all do, but... It's still not quite clear to me what benefit that brings to me as a non-contributor? I can see how it could be beneficial if the entire ecosystem would rally around the same tools and then be able to move faster, but given that that has not yet happened... Why would I use this to lint my code? The nicer error messages?

<comment><AUTHOR> Two immediate potential benefits:

\- Only one tool to configure, instead of many

\- Many tools revolve around parsing your code and generating an AST, then manipulating / processing that AST (Prettier, ESLint, Babel, TS, Webpack, ....). That's a lot of extra processing that has to be done. In theory, doing all that processing _once_, and reusing the AST, would potentially run a lot faster.

<comment><USER15> Also, fixes in the shared libs would be directly available to the tools build on top.

</comment></comment></comment><comment><USER16> Why a focus on frontend only? I am using Typescript, Babel, Jest and a bundler for any app/library on the frontend/backend. If you got to do it, do it all the way! I can already see the GH issues, "sorry, this is a backend use case". So now my tooling would end up being more complex with the addition of another tool since it will never support all my use cases. Seemed promising but this alone makes me question its utility.

<comment><USER3> TypeScript is a frontend language. "Frontend" is the category of languages we plan on supporting. It doesn't say anything about your usage of those languages. Where you run the code does not matter.

<comment><USER17> Could you expand on why you think TypeScript is a "front-end" language? I was under the impression that it just compiles to Javascript and while Javascript used to be a front-end language, it's nowadays bravely used for backend projects as well, for some reason.

</comment></comment></comment><comment><USER18> Why start this from scratch ? Why not build on top of TypeScript ?

I get the single pass rationale but isn't it possible to integrate a bundler into TypeScript compiler ?

I'm just wondering because Microsoft has a decently sized team of paid engineers working on TS for years now - what are the odds an OSS project outperforms them at implementing their own language (which they also evolve with every release)

<comment><USER19> The TypeScript compiler API[1] is beta, underdocumented, and not really designed to support use-cases other than working with an abstract AST. It's OK for transpiling, but would be a bit awkward for writing a linter and not at all suitable for a formatter.

As an example of the sort of problems you might run into with the API in its current state, trying to parse and then pretty-print code can cause comments to vanish[2] under certain circumstances. This is fine for transpiling, but is a major issue when you're trying to prettify and overwrite the original source file.

[1] [https://github.com/Microsoft/TypeScript/wiki/Using-the- Compi...](https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API) [2] [https://github.com/microsoft/TypeScript/issues/39620](https://github.com/microsoft/TypeScript/issues/39620)

<comment><USER18> I get that - but since TS is also OSS you can fork and upstream, still sounds like less work than writing everything from scratch.

<comment><USER20> Why?

TS and Rome architectural goals are completely incompatible.

Writing a transpiler is not complicated at all, especially for someone who has written Babel in the past.

On the other hand, if you familiarise yourself with both TS's gigantic codebase and with Rome's goals, you'll quickly see that modifying TS would be much vaster undertaking than writing it from scratch.

Also if Rome were just an also-ran to replace ESLint/Webpack/Babel/etc, it would be ok to have a less-than-ideal starting point, but it's actually trying to do things differently: better error messages, recoverable parser errors, more fixable linter messages, being faster.

This is the exact case of something that should be written from scratch (or at least use something that makes it possible) rather than building on some another technology with completely incompatible goals.

Another example? It took several years for Webpack to achieve tree-shaking that was as good as Rollup first versions, even with more maintainers, more sponsorship and a lot of time. Why? Because Webpack's architecture was completely different.

<comment><USER18> But you're basically trying to superset the TS compiler. If this doesn't cover TS typechecking then it fails on it's promise of a single pass compiler stack.

Are you suggesting that TS team is so incompetent or legacy burdened that their codebase is impossible to extend. What use case of TS would you exclude to arrive at simpler code base ?

Writing a transpiler that ignores type checks is probably simple but also quite useless for dev workflow - if I need to run a separate type checker might as well run a separate linter and compiler, the tech is established.

<comment><USER21> The TypeScript plugin for Babel already works this way: it strips out the type annotations to make the code understandable to plain JS interpreters, nothing more. Most people do their type checking through their editor or some other tooling. The coupling of building and checking in a single step, in the case of a dynamic language, is really just a matter of convenience for the implementers (as well as historical tradition). Unlike C, in TypeScript type information is not actually needed to output runnable code.

<comment><USER18> I know how it works and I work with TS on a daily basis - the problem is you can't rely on editor type checking because all editors (Idea and TS language server) do type checking on the currently open file - so as soon as your module is referenced from somewhere else you won't get editor notifications if your changes broke that module unless you open that file - using this alone is useless on large projects.

I would argue editors already do a better job at linting and lint rules are mostly file local anyway so the "single pass lint on each build" is not that useful.

Having type checking as a part of the compile process is the best way to leverage typescript (you can fork the checking process so it doesn't block output for faster reload experience)

<comment><USER21> It's entirely possible then to use tsc as a "global" typechecker for the purposes of your dev workflow, without making it a part of your build process (unless you're doing CI, in which case it could still be a separate, preliminary pass that doesn't have to be bound up in the actual build stage). All I'm saying is, especially for a project like Rome that has so many other irons in the fire, I think it's a fully legitimate decision to focus on builds alone and parse-but-not-typecheck TypeScript code, leaving the latter to projects like tsc that have much bigger teams and already do a great job of it.

<comment><USER18> But what's the value proposition of this solution then ? If I need to run separate processes anyway what's the benefit over running webpack with TS and a fork checker ?

<comment><USER21> There are lots of use-cases for producing a working build that doesn't necessarily pass type-checks. Active development, for one. I often find myself hacking on something and actively ignoring certain TypeScript errors that I know won't cause breakage, until I'm at a point where I want to start polishing things up. During this time I may need to test out the functioning- if-unsafe iterations, and I don't want to be blocked by errors that I plan to clean up later. Another case is if you're building a clean checkout; if you already know there are no type errors, there's no need to check again. The two are simply separate, if related, concerns.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> I just don't see the use case for RomeJS and I'm not sure people will want to wait several years for this project to mature. esbuild seems to hit the sweet spot for ESNext/TS/JSX/bundling - it's 100 times faster than current tooling and works today with with next to no configuration.

</comment><comment><USER23> Is there any chance that Rome can be based on Deno in the future?

It seems to me Deno has built with browser-like environments in mind, thus the environment would be more unified.

Node.js is pretty much a different beast. If we want to have an ambitious project like Rome, I would love to have it based on an ambitious foundation.

<comment><USER24> I asked this question, as well, and the answer I got is that Deno already does these things.

</comment></comment><comment><USER25> I'm not great at predicting how tech will evolve but I have a feeling that this will be built in a day.

</comment><comment><USER26> >Regular double quoted strings can have newlines.

This doesn't feel right. There are already ` for multi-line comments. Why not use them? Changing the meaning of " breaks the ability to copy paste an rjson file into regular sourcecode.

</comment><comment><USER27> Can I ask how long is it probably going to take for Rome to provide fuctionality to replace the tools it aims to replace, in a stable release? Rough estimate

</comment><comment><USER28> A few questions on top of my head when I consider changing the toolchain:

\- does it handle images imports

\- does it handle scss imports

\- if not, does it require css-in-js (and if so which one)

\- does it handle shaders imports (and other arbitrary dependencies that need custom processing to get embedded in the bundle)

\- does it generate SRI hashes for stylesheets and scripts

\- can it generate web workers

\- can it generate node bundles or only browser bundles

\- can it split chunks

\- do you still get TS intellisense in VSCode

\- can it be used with Rust and/or Webassembly

<comment><USER3> It's a linter so you don't need to ask any of those questions. Future usage as a bundler isn't dependent on any decision to use it as a linter.

<comment><USER28> It does matter if the only value of the linter at the moment is that it will be part of a set of tools to replace the entire toolchain.

It already took forever for the ecosystem to get JSHint, Tslint and others to converge into Eslint.

</comment></comment></comment><comment><USER29> Please integrate the features of dependency cruiser [1] while you are at it. One of the most useful tool of its kind.

[1] [https://www.npmjs.com/package/dependency- cruiser](https://www.npmjs.com/package/dependency-cruiser)

</comment><comment><USER30> I liked the old logo[0] better.

[0]: [https://raw.githubusercontent.com/romefrontend/rome/1d583050...](https://raw.githubusercontent.com/romefrontend/rome/1d58305097f768b320150bb9bd293c7e74f87b00/assets/logo_with_text.png)

[1]: [https://raw.githubusercontent.com/romefrontend/rome/main/ass...](https://raw.githubusercontent.com/romefrontend/rome/main/assets/JPG/logo.jpg)

<comment><USER31> That helmet is Greek. It was a placeholder. There's a pretty good GH issue[0] for creating the new one.

[0]: [https://github.com/romefrontend/rome/issues/1](https://github.com/romefrontend/rome/issues/1)

</comment></comment><comment><USER32> I feel like Google could have had this with their Closure Compiler/Sheets/Templates/Library but they never dedicated any resources to making the APIs more ergonomic and they've been historically poorly documented as well, not to mention for one reason or another the Compiler doesn't do automatic dependency traversal and because the APIs are not not intuitive and well documented they lost mindshare.

Like many great Google projects it just never got fully realized, which is a shame :(

<comment><USER33> Closure's Achilles' heel is that it's written in Java. It's well-integrated into the stack at Google, but independent JS developers are often skeptical of tools that require more than `npm install`. It's been recently cross-compiler to JavaScript, so it is now available via npm.

</comment></comment><comment><USER34> Very happy to see that this is no longer a Facebook project, which I believe it was just a few months ago. I'd bet there's a good story behind that.

Let's liberate React next?

<comment><USER33> Sebastian started it, and it followed him when he left:

[https://romefrontend.dev/blog/2020/08/08/introducing- rome.ht...](https://romefrontend.dev/blog/2020/08/08/introducing- rome.html#history)

</comment></comment><comment><USER35> Can someone ELI5 what kind of linting is required for a transcribed code generated by TS compiler?

</comment><comment><USER36> Have been watching Rome for a while and can not wait to use it, especially since it's beta time.

It took forever to get eslint/prettier/webpack etc to work in sync and if there is one tool can do it all, I'm all for it.

</comment><comment><USER37> I feel like new tools for JS should ideally be written in a compiled language like Rust, just the performance benefits alone are making me use SWC rather than some other tools for part of my TypeScript toolchain.

<comment><USER38> That was part of the impetus behind ReasonML IIRC, JS tooling in OCaml-ish. Not sure if the performance benefits translated though.

<comment><USER39> They absolutely did. Compilation happens in a fraction of a second, it is fun to use. Refrain if you have to use Typescript at work, it will spare you a lot of frustration.

</comment></comment></comment><comment><USER40> I find this interesting. One of the things I like about languages like Go, Dart, and Rust is their robust tooling.

</comment><comment><USER41> Strangely there's no reference to XKCD yet. Here you go: [https://xkcd.com/927/](https://xkcd.com/927/)

</comment><comment><USER42> I like this idea, I'm tired of configuring tools that I use together to know about one another. I don't need most of the notional power that arrangement supposedly can offer, and configuring these tools has only gotten more bewildering. Tired of screwing around with an endless array of plugins. Many of us build react apps, I think it's worth having a toolchain that caters to that.

I care a lot more about dev experience and speed than "one tool to do one job". The "job" is to handle the code I'm working with in a way that isn't as frustrating as our current tools.

</comment><comment><USER43> Ugh. I cannot stand names based on ancient things or myths. They remind me of the early days of programming when systems were named Neptune, Iapetos, or Cronus in order to make themselves sound bigger or larger than life.

<comment><USER44> Rome is the current capital of Italy... not a mythical or ancient thing.

<comment><USER45> However, it is a little bit weird to name a programming tool after a country's capital city. Are we gonna get the London linter next? Or the Washington DC web framework?

<comment><USER46> There is also Istanbul a test coverage tool and their CLI named nyc.</comment></comment></comment></comment>