You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ultimately a programming language's technical debt follows a distribution of symbols and characters in a programming language affording convenience to specification languages with similar hidden Markov model distributions.
If serving the community of systems level languages and lower is the goal of AA I would surmise this is well accomplished. in this matter the initial boilerplate of yaml, dockerfiles, properties files, shell scripts, json, grpc, xml, have all had less than smashing timeliness or convenience in systems languages though surely there are no faster parsers possible. this too appears where AA would land on the scale of developer conveniences.
the recent ccc conversation brought to light some impressions I would call insular to systems programming languages of past decades.
Namely the symbols chosen. While APL was expressly oriented to having a keyboard of mathematical and category symbols (in 1970), it is important to consider the keyboards and conveniences of onlookers and what might have changed about the distribution of programmers who use code, let alone grammars consumed by programs.
on this note I will leave it at advocating for a language that leverages a common programming characters in use to arriving as close in probabilities as possible to a wikipedia dump, and having the Turing completeness features available to potentially verify correct against a very minimal fix-up using operators.
it's not that this proposing this reducto-absurdome is something I consider realistic, but it strikes me as a stated direction AA is in opposition of, and in every way reducing the applicability of common expressions being ported to AA from common sources which may be specification language and not at the same time expressly be programming language.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
ultimately a programming language's technical debt follows a distribution of symbols and characters in a programming language affording convenience to specification languages with similar hidden Markov model distributions.
If serving the community of systems level languages and lower is the goal of AA I would surmise this is well accomplished. in this matter the initial boilerplate of yaml, dockerfiles, properties files, shell scripts, json, grpc, xml, have all had less than smashing timeliness or convenience in systems languages though surely there are no faster parsers possible. this too appears where AA would land on the scale of developer conveniences.
the recent ccc conversation brought to light some impressions I would call insular to systems programming languages of past decades.
Namely the symbols chosen. While APL was expressly oriented to having a keyboard of mathematical and category symbols (in 1970), it is important to consider the keyboards and conveniences of onlookers and what might have changed about the distribution of programmers who use code, let alone grammars consumed by programs.
on this note I will leave it at advocating for a language that leverages a common programming characters in use to arriving as close in probabilities as possible to a wikipedia dump, and having the Turing completeness features available to potentially verify correct against a very minimal fix-up using operators.
it's not that this proposing this reducto-absurdome is something I consider realistic, but it strikes me as a stated direction AA is in opposition of, and in every way reducing the applicability of common expressions being ported to AA from common sources which may be specification language and not at the same time expressly be programming language.
Beta Was this translation helpful? Give feedback.
All reactions