Hacker Newsnew | past | comments | ask | show | jobs | submit | chrismatic's commentslogin

Even worse so: Why does he not simply ask these people? What is it with this trend of sneering at expert decisions without even doing the bare minimum of engaging with them?


In the case of the humanities, art, or architecture in academia if you disagree with the orthodoxy you might end up labeled something you don’t want to be labeled as, and you don’t get very far.

In architectural design I think it’s rather pronounced. We already know how to design great buildings for the human environment. There ain’t anything new to learn here, so in order to stand out in the field you have to invent some bullshit.

Well, you do that, you create Brutalism or something similarly nonsensical, and in order to defend your creation you have to convince a lot of other academics that no, in fact, buildings that look like bunkers or “clean lines” with “modern materials” are the pinnacle of architecture and design.

And as time has gone on we still go and visit Monet’s Gardens while the rest of the design and art world continues circle jerking to ever more abstract and psychotic designs that measurably make people unhappy.

Not all “experts” in various fields are weighted the same. And in some cases being an expert can show you don’t really know too much.


This is a point well taken, but it also instills a certain incuriosity about expert opinions which is on display in this article.

In fact you can find a question to this very answer with a quick search: https://www.reddit.com/r/AskHistorians/comments/1nfz67t/comm...

Experts are also not a monolithic block. Within architecture and arts you can find many people who agree with your aesthetic preferences.

It is like claiming that there is a "curly-braced" orthodoxy in programming when you just haven't engaged deep with modern varieties.


Eh, that's overstating the case. There's clearly some aesthetics that are more appealing to more people but for many architectural movements in particular the reason that they look that way is for the way that specific ideological reasons interacted with material constraints and the intended message. Brutalism in particular was intended to be cheap and honest; given the constraints many of these buildings were designed under, it makes sense. There are some quite appealing brutalist buildings; a core tenet of the style was integrating the buildings into the natural landscape, in contrast to the artificial styles that had previously been popular. The post-war shortages limited the available materials, shaping the constraints they were operating under. Raw concrete was honest, cheap, and was allowed to weather naturally.

There's a lot of ugly brutalist buildings, but there's a lot of ugly buildings in every style. At lot of them look cheap because they were supposed to be cheap; to a certain extent looking inexpensive was intended. In some cases the hostile nature of the institutional building was part of the point, conveying strength unstead of offering a pleasant experience, but there's also some quite pleasant brutalist buildings that have a lot of nature integrated into the design.


I am working on Grog, the “grug-brained” alternative to Bazel. A mono-repo build tool where all you do is provide your build commands and interdependencies and the Grog will run everything in parallel with aggressive caching.

https://grog.build/why-grog/


Came here to post the same resource and to point out that based on it it rarely was a "two person's job" only.


I good a few good laughs out of this post, but I still hope it's just elaborate trolling.


I am working on Grog, the “grug-brained” alternative to Bazel. A mono-repo build tool where all you do is provide your build commands and interdependencies and the Grog will run everything in parallel while caching as much as possible.

https://grog.build/why-grog/


Good idea! But try to think of a different name since you will have to deal with Groq (https://groq.com/) and Grok (https://grok.com/).


The point about trying to stick with a single language build tooling really cannot be stressed enough. It is what prompted me to write a simplified version of Bazel, a generic "target determinator" with caching capabilities if you will. I call it "Grog", the monorepo build tool for the grug-brained developer.

https://grog.build/why-grog/


I am excited to learn of this project. I started working on something quite similar recently. It's a surprisingly unaddressed niche.

One thing your tool appears to be missing (IMO) is execution sandboxing. This is useful, as you likely know, for avoiding undeclared dependencies and for avoiding dirty builds due to actions polluting the source directory, among other things. I was playing around with allowing configurable sandboxing, with symlink forest and docker as two intial options.


I fully agree. I was also thinking about docker or symlinks, but it seemed hard to design the API without any actual user feedback. Pants environments [0] look interesting.

Very cool that you are also recognizing this issue and working on it. I sent you an email in case you want to exchange further.

[0] https://www.pantsbuild.org/stable/docs/introduction/welcome-...


If a single language is an option you are a small project that is not facing the problems people on large projects are facing. A monorepo will be easy for you without read the article and the lessons learned.

Come back when you have millions of lines of code, written over decades by hundreds (or thousands) of full time developers.


What a weird take, "millions of lines of code, written over decades" applies to quite many C (or C++) codebases where using a high-level language is not a possibility (and companies that do have such codebases are pretty conservative and don't even talk about Rust no matter how great fit it would be).


In every case I've seen the vast majority might be C, but there are other other languages hidden in there that are hard to find. Many companies would use more languages if it wasn't such a pain. Rust for example would be really nice to use in new code, if only they can figure out how to mix it in.


There is a space between the two types of repositories you are describing. One where you just have enough tools/langs that a single-language setup does not cut it for you anymore, but investing all that effort into Bazel does not seem worth it yet. That is the gap that Grog is meant to fill.


I am working on Grog, the “grug-brained” alternative to Bazel. A mono-repo build tool where all you do is provide your build commands and interdependencies and the tool will run everything in parallel while caching as much as possible.


Why should I use this and how is it better than Bazel?


If you are a small to mid-sized team, moving to Bazel is massively painful and basically requires up to one full-time position to provide your team with a good experience.

Grog on the other hand let's you keep your existing build setup while just parallelizing and caching it. It's not a full replacement, but it's more than enough for most mid-sized teams that want to have fast mono-repo builds.


> [2] The OP's OurWorldInData graph screenshot says beef emissions are 60, but the actual page says 99. Same chart. I don't understand. https://ourworldindata.org/grapher/food-emissions-supply-cha... I used 60 in the calculation above.

The chart I used does not include losses in the supply chain. The difference between both charts is further explained here: https://ourworldindata.org/faqs-environmental-impacts-food


> 2. It might not get close to real meat in taste and texture

That's not in the article, I think.

> This was disappointing because I was expecting an analysis of the greenhouse gas contribution of lab grown meat. I didn't see anything (long article with lots of charts, I could have missed it). This is the key issue to me, will lab grown meat significantly help. I am fine with some meat substitutes, I want healthy and tastes good, lots of veg food is like that without trying to be meat.

I also would love to have this analysis, however, the data simply does not exist yet which adds to the uncertainty. I would also argue that the outlook on the techno-economic aspects is more pessimistic than what you put in 1. To quote the relevant section:

> It doesn’t scale. One of the chief proponents of lab-grown meat, the Good Food Institute (GFI), commissioned a techno-economic analysis (TEA) to project what the production of cell-cultivated meat in 2030 might look like. They imagine a facility that would use huge bioreactors to produce 10,000 metric tons of meat per year at an upfront capital cost of $450 million. 10,000 metric tons might sound like a lot until you learn that it would only amount to 0.002% of meat production in the US. Further, due to the high capital expenditure, investors would have to lock themself into 30-year repayment terms to keep the price per kilogram competitive - this is why supporters of the technology are calling for substantial public investments. So investors are faced with the “choice” of either throwing away absurd amounts of money to maybe make the tiniest dent in our meat production or to make a profit with a niche luxury product.

My only argument then is that this is a bet that we cannot afford to make, especially when reductionism already gets us there. Fully agree on the points about veggies being good on their own.


There is a significant difference between scaling up high-tech pharma-grade facilities and just breeding more cattle.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: