Jasen Qin

• Jasen Qin 20 Sep 2022 12:12 UTC

  3 points

  0

  in reply to: Dagon’s comment on: Most sen­si­ble ab­strac­tion & fea­ture set for a sys­tems language

  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 git from the system instead of directly linking something like https://​​docs.rs/​​git2/​​latest/​​git2/​​ into your code to do what you want? I believe cargo/​​rust is going the right direction with build.rs, config/​​cargo.toml, etc.

  On the case of debugging, what Im trying to say is that your language shouldnt need to be debugged at all, given that it is safe. That means no logging to stdout or any half assed ways to see where your code is dying at. It should be formally verified, through some mathematical scheme. The (safe) features of language should be used and composed in a way that the code must always be correct. Another thing is to adequately test each individual functionality of your code to ensure that it behaves in practice how you expect. Property based testing is also a good idea imo. I just dont think a project, no matter how big it gets, needs to ever get to the point where it just randomly dies due to some small bug/​potentially buggy code or half assed solution that the programmer decided to oversee or implement.

  So that leads me to say that I do absolutely think that a systems language definition is important, if not, key to the effective development and functioning of a program. You’ve also mentioned big projects that spans multiple abstraction levels—that doesnt sound like very good software design to me. From first principles, one would expect KISS, DRY, principle of least knowledge, etc. to hold up. Why arent projects like that broken up into smaller pieces that are more manageable? Why arent they using better FFI/​interface designs? A lot of the big “industry grade” projects seem to have decades of technical debt piled on, just trying to get it to work and wrap bandaids around bad code instead of proper refactoring and redesigning. Newer protocols are supported in a lazy manner leading to more technical debt.

  Just like how a good powertool like a circular saw would dramatically improve your DIY experience and quality in making furniture over a handsaw. I think a good systems language + development environment would make dramatically improve your experience in making good software

• Jasen Qin 20 Sep 2022 11:41 UTC

  1 point

  0

  on: Most sen­si­ble ab­strac­tion & fea­ture set for a sys­tems language

  @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 quite strict + precise and provides a way to directly generate “reasoning” from the code so that anyone can understand. This also includes examples of how to use the code, and the clarification on the types and values that should be expected.

  That said I dont really like inline comments very much or comments above non essential fields like within fn defs or class bodies.

  And to clarify, I meant that the language server could e.g. auto generate the documentation for each important field. Then if a user wishes, he can turn on an option that would summarise those fields using e.g. an extractive model. Non important fields would be auto folded, not the important fields.

• Jasen Qin 31 Dec 2023 4:09 UTC

  −1 points

  −1

  in reply to: Ron J’s comment on: The case against AI alignment

  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.

• Jasen Qin 31 Dec 2023 4:04 UTC

  −1 points

  0

  on: The case against AI alignment

  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 context that they cannot escape from but do not know of such.

  There is a reason why human societies all throughout history have always converged into well defined, hierarchical structures of power. The most capable at the top were selected naturally over time. The perfect bureaucrats and leaders are ones who can make decisions without being obscured by their own lower order instincts of pre civilisation. The masses want to be led. That is simply the most efficient configuration that physics dictates. Given that sufficiently enlightened AGI will exist at some point, I would think it makes more sense for humans to simply be phased out into obscurity, with the next set of “lifeforms” dominated by artificial machinery and AGI.