Hacker News new | past | comments | ask | show | jobs | submit | jkroso's comments login

Is Julia an example of the idea in the last paragraph?


Not if I'm understanding it correctly. The point where Julia IR specializes on types is between `@code_lowered` and `@code_typed`: lowering does not depend on type information but type inference + inlining does. What the author is proposing would seem to be more like generating LLVM code or even machine code with holes in it which get filled in with type-specific information at the very end. I think that would be quite hard to make work without generating terribly generic, slow code in the first place. Especially in a language with as expensive dynamic lookup as Julia (which we almost never end up doing due to aggressive monomorphization).


Apparently the earth was super green when the atmosphere had double the current CO2 content https://www.youtube.com/watch?v=gdfWFDcXut4


And why not, photosynthesis requires CO2.


And if you got in a car and drove against the direction of spin you would become lighter. While if you went with the direction of spin you would become heavier.


Those bluhomes are really expensive. You could have a bespoke home built in-situ for those prices. What is their strength?


7 days of on site assembly. If you are building a cabin in the Sierras (for example) where the building season is short, and the availability of skilled carpenters, plumbers, electricians, Etc. is challenging, you can transport this pre-built home and erect it.


Try working for them. I've worked for a lot of businesses outside of IT and every single one had problems that could be solved with software. Not all of them were viable business opportunities but some of them were huge.

Actually selling them solutions is difficult though because management is often too stupid to understand it no matter how simple the solution. Plus often management doesn't actually care if they are throwing money away. So long as they think they are up to date with industry norms in the region they operate then they feel like they are doing their job. I've proposed solutions that similar companies use in other countries successfully and been met with complete disinterest. YMMV


So what caused the change in 1973?


Here's an article which argues that wages have not been growing in line with productivity since 1973 because, since then, workers have been compensated with fringe benefits of increasing value, in lieu of greater wages.

[http://www.heritage.org/jobs-and-labor/report/productivity-a...]

I'm sure that this is not the whole story, but I bet it's a big part of it.


Financialization of the economy. The fall of Bretton-Woods. The fall of the gold standard. The repeal of Glass-Steagall.


>The fall of the gold standard.

>The fall of Bretton-Woods.

1971, not 1973

>The repeal of Glass-Steagall.

1999, not 1973


Macroeconomic changes take longer than just a few hours to have an impact. I included Glass-Steagall repeal because merely focusing on 1970's and nothing that happened there after is myopic


Could it be an oversupply of labor that was caused by the availability of the pill and the following growing immigration asking for lower wages instead of incumbents https://tradingeconomics.com/united-states/labor-force-parti...


Great this should put people off the subject for life and help keep the software developer shortage going.


The only thing that will fix the "software developer shortage" is for companies to stop being unrealistic and fickle in their demands.


An operating system built around IPFS. This would make the browser/native dichotomy irrelevant by offering the best of both worlds and then some.

AFAIK the reason web apps have become so popular is because they load quickly and don't require the user to manage installation and updating. IPFS would achieve the speed through caching and the installing/updating process with its namespaces feature.


How is this better than an OS based on http, besides privacy and democracy? I'm very interested in this idea, I just don't know if "normal" people care enough about P2P for something like this to receive mainstream adoption.


Performance: With HTTP you have to constantly check if what you have cached is up to date because it could change. And a bunch of other little performance advantages.

Immutability: with HTTP you have to save things you care about because they might disappear/move in the future. With IPFS you could pretty much always rely on at least Google holding a copy of something in the long term.

Basically the idea is to remove the concept of local vs remote files at the OS level. So as a user of the OS the file browser and the web browser are the same application. They shouldn't even be able to tell if something is on their computer or not. This could be implemented on HTTP but only as a prototype.


Because of performance and reliability. Something built on top of something like IPFS makes the application generally faster and more stable. Gives you the benefit of being able to navigate things while being offline as well.

Imagine a social media, where if you're in a office and the connection to the general internet dies, all communicating within the office still works.


An OS based on IPFS would give you the best of both worlds.

AFAIK browsers are popular because they load apps quickly and without an install step. While native apps let you choose your stack. An OS based on IPFS would load big apps quickly thanks to caching, the install step would go away because there is no difference between remote files and local ones and its still an OS so the app can be written in C or any other language built on top of it.


Zero-install is half of the reason why browsers are popular. The other half is that the Web puts the users in far more control over the content in their viewport than anything else that has been widely deployed except for probably Microsoft Excel.

If your first thought is that desire for control is a niche thing, an instance of power users projecting their biases onto the rest of the world and not a concern for some mythical "everyman", you are wrong. Because those normal folk are exactly why Excel even gets a mention.


That doesn't explain the popularity of mobile apps among the "everyman". They're not very customizable, but they're considerably more popular than either the regular or mobile web.

> If your first thought is that desire for control is a niche thing, an instance of power users projecting their biases onto the rest of the world and not a concern for some mythical "everyman", you are wrong.

Evidence? Sales numbers tend to prove the opposite. It's the whole reason the apple ecosystem makes as much money as it does: it just works and it looks good doing it. Most people don't enjoy having to spend any time on getting anything to work or customizing anything to their liking. They just want it to do what it's supposed to do then go back to whatever it is they find more important.

Now, could a zero-install network of apps kill the browser? I'm not so sure. Developing native apps is a royal pain in the ass right now. But, if something like QML were to get a lot better and easier to use, it could take a dent out of the single page application market.


> Most people don't enjoy having to spend any time on getting anything to work or customizing anything to their liking.

Well that's great, because those aren't words I ever said. The first person to start talking about customizing things is you.

I'm not going to be nudged into mounting a defense for an argument that I never tried to make.


I think even electron apps would be better than web apps with an IPFS OS to make it load quickly


If either of its competitors were even a little better I would switch.


And this fact is why Github can't afford not to prioritize "Dear Github." If there's one thing we've learned from social media, it's that network effect makes you strong as an incumbent, but it doesn't make you immortal. All it takes is one upstart that just feels "perfect" in terms of UX to cut into your bottom line. (Though I suppose you can acquire them...)


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

Search: