5 ms·

All these are implementation details. The programmers should be seen as “users” of the language. What you give here is a list of excuses on why system X doesn

All these are implementation details. The programmers should be seen as “users” of the language. What you give here is a list of excuses on why system X doesn’t do what is best for its users.

pie_flavor 4y ago
No, explicit pointers are not an implementation detail. Nor is knowing when you are on an OS thread in a language where you are likely to integrate with OS functions that depend on what thread you are on. Different languages exist for different purposes requiring them to solve problems in different ways.
- noncoml 4y ago
  Two out of three arguments of the GP are implementation details. You can tell that they are implementation details by the way the language is used. “It’s difficult to do A given B” As a user I don’t care about B. I just want A. For your example, the concept of explicit pointers are orthogonal to threads. That’s why you can have OS threads with explicit pointers. Just because it’s difficult to make them work together doesn’t mean they are incompatible as concepts. It’s still an implementation detail. For example, during Win95 one could argue it’s impossible for a crash program not to crash the whole system. As a user I don’t care what’s going under the hood. I just don’t like it when my Windows 95 app can crash the system. It is an implementation detail
ecnahc515 4y ago
Implementation details are often also defacto features, because the behavior may be relied upon by users. Unless you designed the language up front to consider these things, it's often very much a challenge to tell your users that their code is broken, especially if you did not have a language specification clarifying it. For languages like Python for example, this is a big issue, and reason why alternative concurrency patterns to async/await haven't made much progress.
- noncoml 4y ago
  Totally agree. But that was not the point of GP
kjeetgill 4y ago
Choices come with trade-offs and in turn make languages suitable for different use-cases and users. There's no uniform "best for it's users" choices that apply to all languages. Well, ironically, the exception that applies to all languages being: "does my code still work?" choices... which is what pron was addressing.
- noncoml 4y ago
  I can buy the argument that async/await is a design choice. In which case this is what is “best if the user” But the GP replied to a comment that was claiming threads of execution are better than async. So in the context of the reply the threads are the “best for the the user”
vbezhenar 4y ago
As I grow older, implementation details are all that matters to me in the end. I hate go language, IMO it's ugly and terrible to work with. But its compiler and toolset are golden and I'll use it just because of its implementation details. I don't have time to wait until language developers will implement implementation details I need, if ever. I need to ship software tomorrow.
- rileyphone 4y ago
  The compiler and toolset are the user facing aspects of a language like go, how the parser works or internal functions in the standard library would be the implementation details.
- noncoml 4y ago
  Hmmm. Implementation details are the stuff that are not visible to you as a “user” of the language and the toolset. I don’t know why people confuse this so much
  - Hercuros 4y ago
    I would say that implementation details could be visible to you as a user, but should not be relied upon because they are not part of the documented API. E.g. it might be visible to you that a certain operation runs quickly on certain inputs, or that a particular output is chosen for a particular input, even though the documentation does not specify the exact output.
noncoml 4y ago
Damn folks. Downvoting is not meant for showing your disagreement Targeting a specific IR is an implementation detail. Having explicit pointers and thread are not mutually exclusive concepts. It’s the implementation details that make them difficult. HN can be so annoying sometimes
- yCombLinks 4y ago
  It's not about disagreement with your opinion, it's about your rudeness presenting it.

All these are implementation details. The programmers should be seen as “users” of the language. What you give here is a list of excuses on why system X doesn’t do what is best for its users.

pie_flavor 4y ago

No, explicit pointers are not an implementation detail. Nor is knowing when you are on an OS thread in a language where you are likely to integrate with OS functions that depend on what thread you are on. Different languages exist for different purposes requiring them to solve problems in different ways.

noncoml 4y ago
Two out of three arguments of the GP are implementation details. You can tell that they are implementation details by the way the language is used. “It’s difficult to do A given B” As a user I don’t care about B. I just want A. For your example, the concept of explicit pointers are orthogonal to threads. That’s why you can have OS threads with explicit pointers. Just because it’s difficult to make them work together doesn’t mean they are incompatible as concepts. It’s still an implementation detail. For example, during Win95 one could argue it’s impossible for a crash program not to crash the whole system. As a user I don’t care what’s going under the hood. I just don’t like it when my Windows 95 app can crash the system. It is an implementation detail

ecnahc515 4y ago

Implementation details are often also defacto features, because the behavior may be relied upon by users. Unless you designed the language up front to consider these things, it's often very much a challenge to tell your users that their code is broken, especially if you did not have a language specification clarifying it. For languages like Python for example, this is a big issue, and reason why alternative concurrency patterns to async/await haven't made much progress.

noncoml 4y ago
Totally agree. But that was not the point of GP

kjeetgill 4y ago

Choices come with trade-offs and in turn make languages suitable for different use-cases and users. There's no uniform "best for it's users" choices that apply to all languages. Well, ironically, the exception that applies to all languages being: "does my code still work?" choices... which is what pron was addressing.

noncoml 4y ago
I can buy the argument that async/await is a design choice. In which case this is what is “best if the user” But the GP replied to a comment that was claiming threads of execution are better than async. So in the context of the reply the threads are the “best for the the user”

vbezhenar 4y ago

As I grow older, implementation details are all that matters to me in the end. I hate go language, IMO it's ugly and terrible to work with. But its compiler and toolset are golden and I'll use it just because of its implementation details. I don't have time to wait until language developers will implement implementation details I need, if ever. I need to ship software tomorrow.

rileyphone 4y ago
The compiler and toolset are the user facing aspects of a language like go, how the parser works or internal functions in the standard library would be the implementation details.
noncoml 4y ago
Hmmm. Implementation details are the stuff that are not visible to you as a “user” of the language and the toolset. I don’t know why people confuse this so much
- Hercuros 4y ago
  I would say that implementation details could be visible to you as a user, but should not be relied upon because they are not part of the documented API. E.g. it might be visible to you that a certain operation runs quickly on certain inputs, or that a particular output is chosen for a particular input, even though the documentation does not specify the exact output.

noncoml 4y ago

Damn folks. Downvoting is not meant for showing your disagreement Targeting a specific IR is an implementation detail. Having explicit pointers and thread are not mutually exclusive concepts. It’s the implementation details that make them difficult. HN can be so annoying sometimes

yCombLinks 4y ago
It's not about disagreement with your opinion, it's about your rudeness presenting it.