<p>Most programming languages model the human beings using the system, as data like any other data. It is only through loose convention and framework level convention that things like authentication and data ownership are dealt with. While flexible, this leads re implementation of things which users of the system expect to just work, and on the main haven't changed much in the past decade.</p>
<p>Are there programming languages which model the user as a fundamental primitive?</p>
<p>When I say user, I do not mean authentication. And any type system which attempted to model users would of course need to be extensible by program authors to tailor to the needs to software products. But like so many languages have things such as tasks, memory, data types, built into the language itself with all of that extensibility available, it seems like we should have a &quot;user role&quot;, &quot;user identity&quot; keyword that allows for algebraic expressiveness of what our products demand.</p>
<p>Why should &quot;is the current user / 3rd party which is accessing the data on behalf of the user allowed to access this data for a certain reason&quot; always be implemented in library level code, when this concern is perhaps the most important consideration for any business making its profit off of the manipulation and storage of contracts pertaining to services rendered?</p>
<p>It surprises me that this has not been solved at a language level given its importance.</p>

<type-systems>
What programming languages exist which model the human beings using the application as language level constructs?
CC BY-SA 4.0
2024-04-29T01:47:08.277Z
Authentication mechanisms have changed rather a lot in the last decade and will continue to change in the next decade. Besides the rise of 2FA, fingerprint and face authentication, password managers, hardware keys and OTP, we have much better password hashing algorithms, and we now understand that it's counterproductive to force users to change periodically their password. Best practices change, and passwordless authentication is most likely going to get more common.
kaya3
CC BY-SA 4.0
2024-04-29T01:50:08.653Z
More generally, if the language favours a particular model of the user, then it will only be useful for writing programs where that model is both accurate and reasonably complete. A model of human users won't be very well-suited for writing APIs, for example; rather a lot of code has no (direct) human user at all, it is used by other code.
kaya3
CC BY-SA 4.0
2024-04-29T02:48:03.957Z
**PostgreSQL [roles](https://www.postgresql.org/docs/current/user-manag.html) and [privileges](https://www.postgresql.org/docs/current/ddl-priv.html)**. Roles are PostgreSQL's concept of users or groups, and the database actions they may perform can be restricted, including preventing users from modifying tables others have created (ownership). [This question](https://dba.stackexchange.com/a/128798) suggests that these permissions don't natively extend to individual rows, but you can even do that using triggers (albeit this goes back to re-implementation).
tarzh
CC BY-SA 4.0
2024-04-29T03:29:34.363Z
Respectfully, authentication and user Identity are not synonymous. The user and their relationship to data is the preeminent role of all software, yet we relegate it to a string, guid or long at the aspect where it matters most, the business rules
Bryan Rayner
CC BY-SA 4.0
2024-04-29T03:43:33.370Z
I think you need to [edit] the question with some more details of what it means to model the users as language constructs; at the moment it's not clear what sorts of language feature might fit within that description, and one of the obvious possibilities has just been ruled out. Either examples of what that would entail, or a direct description of the perimeter of what you're thinking of, could make that work.
Michael Homer
CC BY-SA 4.0
2024-04-29T05:21:38.993Z
Edited to express reason behind why I'm asking which will hopefully make this a more direct question
Bryan Rayner
CC BY-SA 4.0
2024-04-29T23:26:41.573Z
What would ‘human being’ mean for a microservice?  A script?  A web service?  A GUI application under the control of an automated test suite?  A GUI app accessed over a remote desktop?  A cron job?  A stored function in a database?  A program launched by a human but running in the background?  What could you model that would be simple enough to cover many of those cases, but still be complex enough to be worth doing?
gidds
CC BY-SA 4.0
2024-05-27T15:18:23.180Z
I think you can model the identity of the person who invoked any function call or created any data. The meanings behind these identities would then be able to be categorized by various relationships. If you think in terms of graph connectivity, is user A part of group B through group C... the language would simply need keywords allowing these hierarchies to be expressed and then statically analyzed for correctness. And then runtime and data storage hooks to facilitate it in the real world. As for microservices - it would have to cross into the RPC layer as well.
Bryan Rayner
CC BY-SA 4.0
2024-07-07T15:13:03.597Z
*"user identity"* - our thinking would be a lot more honest, if we just went back to calling them "logins".
Steve
<p>Languages tend to <strong>add</strong> abstractions and/or tools (within the languages) which help developers to build <strong>even more</strong> abstractions, through development.</p>
<p>It seems to me that the existence of an entity User, in the language (maybe in form of language constructs, maybe in form of data-structures, maybe both) would not produce more, but <strong>less</strong> abstraction.</p>

CC BY-SA 4.0
2024-06-19T00:06:54.610Z
2024-06-19T00:07:48.267Z
2024-06-19T00:07:48.267Z
pber
<blockquote>
<p>Are there programming languages which model the user as a fundamental primitive?</p>
</blockquote>
<p>Perhaps. There are all sorts of DSLs out there and there is a good chance some of them cover <em>specific</em> user/role/capabilities models. I won't even try to give a list, because it depends much more on what one considers &quot;programming languages&quot; than anything else.</p>
<blockquote>
<p>Why should &quot;is the current user / 3rd party which is accessing the data on behalf of the user allowed to access this data for a certain reason&quot; always be implemented in library level code, when this concern is perhaps the most important consideration for any business making its profit off of the manipulation and storage of contracts pertaining to services rendered?</p>
</blockquote>
<p>Because these concepts really are not as simple as they sound, and conversely the generic parts are as simple to be useless.</p>
<p>Even concepts like &quot;user role&quot; and &quot;user identity&quot; vary wildly between authN/authZ approaches. Is the identity an opaque token? Is it a <a href="https://en.wikipedia.org/wiki/User_(computing)#Username_format" rel="nofollow noreferrer">UPN with meaningful user and domain</a>? Is it a <a href="https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol#Directory_structure" rel="nofollow noreferrer">distinguished name with hierarchical information</a>? Are there even identities, or just anonymous sessions with individual capabilities?</p>
<p>The generic stuff that remains does not make for great abstractions. If you want a generic identifier, languages already offer tons of those - numbers, strings, raw bytes, opaque objects. If you want a generic &quot;can this session do that?&quot; -  that is maybe a simple bool, a first-class function, or a code path that does not even have access to disallowed actions.<br />
These abstractions are much more generic than the use-case of users/roles/capabilities. Restricting them to that narrative or duplicating them is a loss for general purpose languages.</p>

CC BY-SA 4.0
2024-04-29T08:50:04.520Z
2024-04-29T08:50:04.520Z
MisterMiyagi
CC BY-SA 4.0
2024-05-12T14:54:01.853Z
The specifics of how one identifies the symbolic truth - "who invoked this method and are they allowed to"? do vary widely. But do do processor architectures. By your logic, we wouldn't use any higher level languages because some chips are little endian and some are big - but that's the exact reason we need higher level languages. JavaScript had to add private identifiers at a language level... I think the current user who is triggering method execution is the most important aspect and it's surprising this is always re implemented
Bryan Rayner
CC BY-SA 4.0
2024-05-27T17:10:38.030Z
@BryanRayner I think that you even think there *is* a current user - be it in the meaning of at least one, exactly one, or even that there is such a thing as users - means you are not looking at this broad enough. High level languages add domain agnostic abstractions on top of the bare metal, what you describe is extremely domain specific and this a whole different focus than what general purpose languages provide.
MisterMiyagi
CC BY-SA 4.0
2024-05-27T17:17:16.800Z
As a data point, I have spent the better part of the last year deploying a new authN and authZ mechanism at my dayjob. Yet only about 1% of code is aware there are users, about 10% is aware there are capabilities, and at least 50% avoids having even traces of knowledge about either concept on purpose. "Who requested this" is an opaque blob in an audit log at the very edge of our infrastructure.
MisterMiyagi
# What programming languages exist which model the human beings using the application as language level constructs?
Posted by: username_0 on 2024-04-29
Most programming languages model the human beings using the system, as data like any other data. It is only through loose convention and framework level convention that things like authentication and data ownership are dealt with. While flexible, this leads re implementation of things which users of the system expect to just work, and on the main haven't changed much in the past decade.

Are there programming languages which model the user as a fundamental primitive?

When I say user, I do not mean authentication. And any type system which attempted to model users would of course need to be extensible by program authors to tailor to the needs to software products. But like so many languages have things such as tasks, memory, data types, built into the language itself with all of that extensibility available, it seems like we should have a "user role", "user identity" keyword that allows for algebraic expressiveness of what our products demand.

Why should "is the current user / 3rd party which is accessing the data on behalf of the user allowed to access this data for a certain reason" always be implemented in library level code, when this concern is perhaps the most important consideration for any business making its profit off of the manipulation and storage of contracts pertaining to services rendered?

It surprises me that this has not been solved at a language level given its importance.
**Tags:** type-systems
> **Comments:**
> **username_1**: Authentication mechanisms have changed rather a lot in the last decade and will continue to change in the next decade. Besides the rise of 2FA, fingerprint and face authentication, password managers, hardware keys and OTP, we have much better password hashing algorithms, and we now understand that it's counterproductive to force users to change periodically their password. Best practices change, and passwordless authentication is most likely going to get more common.  
> **username_1**: More generally, if the language favours a particular model of the user, then it will only be useful for writing programs where that model is both accurate and reasonably complete. A model of human users won't be very well-suited for writing APIs, for example; rather a lot of code has no (direct) human user at all, it is used by other code.  
> **username_2**: **PostgreSQL [roles](https://www.postgresql.org/docs/current/user-manag.html) and [privileges](https://www.postgresql.org/docs/current/ddl-priv.html)**. Roles are PostgreSQL's concept of users or groups, and the database actions they may perform can be restricted, including preventing users from modifying tables others have created (ownership). [This question](https://dba.stackexchange.com/a/128798) suggests that these permissions don't natively extend to individual rows, but you can even do that using triggers (albeit this goes back to re-implementation).  
> **username_0**: Respectfully, authentication and user Identity are not synonymous. The user and their relationship to data is the preeminent role of all software, yet we relegate it to a string, guid or long at the aspect where it matters most, the business rules  
> **username_3**: I think you need to [edit] the question with some more details of what it means to model the users as language constructs; at the moment it's not clear what sorts of language feature might fit within that description, and one of the obvious possibilities has just been ruled out. Either examples of what that would entail, or a direct description of the perimeter of what you're thinking of, could make that work.  
> **username_0**: Edited to express reason behind why I'm asking which will hopefully make this a more direct question  
> **username_4**: What would ‘human being’ mean for a microservice?  A script?  A web service?  A GUI application under the control of an automated test suite?  A GUI app accessed over a remote desktop?  A cron job?  A stored function in a database?  A program launched by a human but running in the background?  What could you model that would be simple enough to cover many of those cases, but still be complex enough to be worth doing?  
> **username_0**: I think you can model the identity of the person who invoked any function call or created any data. The meanings behind these identities would then be able to be categorized by various relationships. If you think in terms of graph connectivity, is user A part of group B through group C... the language would simply need keywords allowing these hierarchies to be expressed and then statically analyzed for correctness. And then runtime and data storage hooks to facilitate it in the real world. As for microservices - it would have to cross into the RPC layer as well.  
> **username_5**: *"user identity"* - our thinking would be a lot more honest, if we just went back to calling them "logins".  
---
## 2 answers
### Answer by username_7 on 2024-04-29. Score: 3
> Are there programming languages which model the user as a fundamental primitive?

Perhaps. There are all sorts of DSLs out there and there is a good chance some of them cover *specific* user/role/capabilities models. I won't even try to give a list, because it depends much more on what one considers "programming languages" than anything else.

> Why should "is the current user / 3rd party which is accessing the data on behalf of the user allowed to access this data for a certain reason" always be implemented in library level code, when this concern is perhaps the most important consideration for any business making its profit off of the manipulation and storage of contracts pertaining to services rendered?

Because these concepts really are not as simple as they sound, and conversely the generic parts are as simple to be useless.

Even concepts like "user role" and "user identity" vary wildly between authN/authZ approaches. Is the identity an opaque token? Is it a [UPN with meaningful user and domain](https://en.wikipedia.org/wiki/User_(computing)#Username_format)? Is it a [distinguished name with hierarchical information](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol#Directory_structure)? Are there even identities, or just anonymous sessions with individual capabilities?

The generic stuff that remains does not make for great abstractions. If you want a generic identifier, languages already offer tons of those - numbers, strings, raw bytes, opaque objects. If you want a generic "can this session do that?" - that is maybe a simple bool, a first-class function, or a code path that does not even have access to disallowed actions.  
These abstractions are much more generic than the use-case of users/roles/capabilities. Restricting them to that narrative or duplicating them is a loss for general purpose languages.
> **Comments:**
> **username_0** (2024-05-12): The specifics of how one identifies the symbolic truth - "who invoked this method and are they allowed to"? do vary widely. But do do processor architectures. By your logic, we wouldn't use any higher level languages because some chips are little endian and some are big - but that's the exact reason we need higher level languages. JavaScript had to add private identifiers at a language level... I think the current user who is triggering method execution is the most important aspect and it's surprising this is always re implemented  
> **username_7** (2024-05-27): @BryanRayner I think that you even think there *is* a current user - be it in the meaning of at least one, exactly one, or even that there is such a thing as users - means you are not looking at this broad enough. High level languages add domain agnostic abstractions on top of the bare metal, what you describe is extremely domain specific and this a whole different focus than what general purpose languages provide.  
> **username_7** (2024-05-27): As a data point, I have spent the better part of the last year deploying a new authN and authZ mechanism at my dayjob. Yet only about 1% of code is aware there are users, about 10% is aware there are capabilities, and at least 50% avoids having even traces of knowledge about either concept on purpose. "Who requested this" is an opaque blob in an audit log at the very edge of our infrastructure.  
---
### Answer by username_6 on 2024-06-19. Score: -3
Languages tend to **add** abstractions and/or tools (within the languages) which help developers to build **even more** abstractions, through development.

It seems to me that the existence of an entity User, in the language (maybe in form of language constructs, maybe in form of data-structures, maybe both) would not produce more, but **less** abstraction.
---
