[flagged]
7,576 karma · joined January 28, 2012
South Korea, Japan, Philippines, are all proxy states and hostages to the US defense budget.
If this study is true, it should be easy to compare prevalence of autism on these countries that don’t rely on Tylenol.
It's bad anyway. These people burnout and start making dumb moves to bail out sooner.
That makes sense, as you're breaking the task into smaller achievable tasks. But it takes an already experienced developer to think like this.
Instead, a lot of people in the hype train are pretending an AI can work an idea to production from a "CEO level" of detail – that probably ain't happening.
But trying to use it like “please write this entire feature for me” (what vibe coding is supposed to mean) is the wrong way to handle the tool IMO. It turns into a specification problem.
Proofreaders still exist, despite spell checker. Art assistants still exist, despite Photoshop. There's always more work to do, you just incorporate the new tools and bump the productivity, until it gets so commoditized it stops being a competitive advantage.
Saying AI "replaces" anyone is just a matter of rhetoric to justify lower salaries, as always.
We'll reap the productivity benefits from this new tool, create more work for ourselves, output will stabilize at a new level and salaries will stagnate again, as it always happens.
Meanwhile, US development strategy post-WW has been 100% based on projecting military [1], political [2] and economic [3] power on a global scale.
So war isn't just "spending", but trading off investment on your own country vs. extracting value from somewhere else. That's how you get large defense funding but not public health care.
[1] https://www.visualcapitalist.com/mapped-every-known-u-s-mili...
[2] https://en.wikipedia.org/wiki/United_States_involvement_in_r...
AGI would take making at least one full brain, and then putting many of those working together, efficiently.
I don't believe we can engineer our way out of that before explaining how the f. the wetware works first.
China’s population is 4x times the US, and still, total emissions are a little over 2x — and that’s ignoring the outsized impact from exported goods.
If at least the US got in line with the rest of the world, we would be half-way there.
https://ourworldindata.org/grapher/co-emissions-per-capita
The problem is not the 8 billion people, is the handful that have an disproportionate impact.
VCs hope that with AI they can have a larger portfolio, shipping more things, so that by sheer luck, one is a success. That's why many employees are critical of the AI hype while VCs and C-level love it. The whole discussion about maintainability doesn't even register on the radar, employees vs. VCs and C-level are operating at a different definition of "failure".
The cost seems deceivingly low right now because those AI companies are fighting for monopoly, but in reality the cost is huge – not only capital, but also trust, privacy, and environmental.
Requirements _may_ change, but it’s much harder to have consumers move to a new API. Once it’s published, it’s a contract you don’t want to break.
That doesn’t mean you need to design an extremely flexible and future-proof API to the point it stops making sense — it’s a false dichotomy.
What you can do is take your time designing an API that still makes sense as long as possible, until your understanding of the domain has changed so much that it’s a different shape altogether.
Throwing your hands up and saying “it’s impossible” is easy, the art is in figuring out how much has to change until you have to say that.
Design is a game of push-pull between context and form, and you can add tolerances both ways.
Real life sample:
let print_expr exp =
(* Local function definitions *)
let open_paren prec op_prec =
if prec > op_prec then print_string "(" in
let close_paren prec op_prec =
if prec > op_prec then print_string ")" in
let rec print prec exp = (* prec is the current precedence *)
match exp with
Const c -> print_float c
| Var v -> print_string v
| Sum(f, g) ->
open_paren prec 0;
print 0 f; print_string " + "; print 0 g;
close_paren prec 0
| Diff(f, g) ->
open_paren prec 0;
print 0 f; print_string " - "; print 1 g;
close_paren prec 0
| Prod(f, g) ->
open_paren prec 2;
print 2 f; print_string " * "; print 2 g;
close_paren prec 2
| Quot(f, g) ->
open_paren prec 2;
print 2 f; print_string " / "; print 3 g;
close_paren prec 2
in print 0 exp;;
let print_expr exp =
Also, you need to end the declaration with `in`?
Then, semicolons...
open_paren prec 0;
print 0 f; print_string " + "; print 0 g;
print 0 exp;;
> In any nontrivial codebase, this inevitably leads to bugs when, for example, a string representing a user ID gets used as an account ID
> or when a critical function accepts three integer arguments and someone mixes up the correct order when calling it.
I understand the line of reasoning here, but the examples are bad. Those aren't good reasons to introduce new types. If you follow this advice, you'll end up with an insufferable codebase where 80% LoC is type casting.
Types are like database schemas. You should spend a lot of time thinking about semantics, not simply introduce new types because you want to avoid (hypothetical) programmer errors.
"It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures."
It may appear so, because that’s how the actors involved use social media, but it’s not caused by it.
The pressure of the financial capitalism on the industrial capitalism is too high. Any company that produces anything is eventually forced into rent-seeking to keep delivering what has come to be expected YoY growth. C-level that won't let that happen will see the way out.
You get a lot of positive reinforcement from positive opinions online, but the people who don’t depend on this to work won’t be vocal about it.