LESSWRONG
LW

0
0

All of Jasen Qin's Comments + Replies

The case against AI alignment
Jasen Qin
-1-1

Any sufficiently intelligent AGI is bound to be able to have powerful reflection capabilities and basically be able "choose its own alignment", as you say. I don't see what the big fuss is all about. When creating higher order 'life', why should one try to control such life. Do parents control their children? To some extent, but after a while they are also free.

Reply
The case against AI alignment
Jasen Qin
-10

Whenever the masses gain control over a non-trivial system, it usually doesn't take long to crumble under its own weight. Infighting is frequent. They band into tribes and start shaping their own persona's to match that of the group that they are now in rather than the other way around. For something like AI alignment, I really do not want AI to be anywhere near conforming to the standards of the average person. The average person is just too "converged" into a certain line of thinking and routine, a certain context which they have grown up in, a certain c... (read more)

Reply
Most sensible abstraction & feature set for a systems language?
Jasen Qin
30

Maybe thats a problem, you've been at this for too long, so you've developed a very firm outlook. Just kidding.

You can get a long way with the Unix philosophy (small single-purpose tools that compose via a shell/script mechanism

I do quite like sed, wget, etc. but it also doesnt feel very rigid to use in a project. What I see is a bunch of projects that have a mess of scripts invoked by other scripts. See https://github.com/gcc-mirror/gcc. Why not try to link those tools into the code in a more rigid way? If a project uses git why make a script that calls g... (read more)

Reply
2Dagon
Grin.  There's more than a little bit of truth there, thanks for reminding me. Depends on the project.  If it's stupid and it works, it's not stupid.  There's a WHOLE LOT of projects that don't need wide applicability, great uptime, nor long-term maintainability.  Getting them functional in half a day is way better than getting them reliable in a week (or in GCC's case, keeping the build-of-gcc system functional over 35 years is important, but making it clean is less important than improving the actual usage and functionality of GCC).  Rigidity is a cost, not a benefit. Sometimes. Which is my main point - using different tools and languages for different needs is the only way I know to get to the right points in the tradeoff space (both human-level and operational) for different things.  I suspect we're talking past each other when we talk about multiple levels of abstraction in a project - the word "project" is pretty undefined, and separation between these abstractions is absolutely normal -whether they build/test/deploy together or separately is an independent question. You're absolutely right that pretty much all long-lived projects are a mess of hacks and debt just trying to get it to work (and keep it working as new uses get added).  But there are pretty difficult-to-oppose reasons that this is universally true.  The decisions about when to refactor/rewrite vs when to patch over are ... non-trivial and heated.  Fundamentally, tech debt is a lot like financial debt - a VERY useful tool for being able to do things sooner than you can fully afford it by yourself, and as long as you're growing, can be rolled over for a long long time.   And it makes you more fragile in a downturn, so the organizations and codebases that over-use it get winnowed occasionally.  Circle of life, you know.
Most sensible abstraction & feature set for a systems language?
Jasen Qin
10

@Villiam I noticed I didnt really spell out my motivations but yes, Im looking at things like operating systems and the "science" of making core software that would then be used by other software, and eventually apps that would directly provide business logic.

My reasoning for documentation is mostly a way to elaborate how the code should work in a vacuum. That is, how you can directly use that piece of code to get what you want. I think it is quite hard to understand someone else's perspective just from comments so it makes sense to have a language that is... (read more)

Reply