The Imperium programming language - IPL

[Sherlock Holmes]

Allowing different language keywords will break a havoc in developing and maintaining tools which work at the source code level. Just do not do it.

Why? first only a single lexicon's keywords can be used in any file, it is not permitted to ever mix lexicons in a source file. The lexicon is specified in a compiler directive or can be overridden as a compiler option. Every source file uses one and only one lexicon and the default is English, if no directive or compile option is specified.

One must "opt in" to use other lexicons.

Any source file can be converted from any lexicon to any other using a simple utility (and class library by tool builders).

Owners of repositories can establish a check that all pull requests contain source in some defined lexicon, this is trivial to do with GitHub actions, every contributor would have to save their code with that lexicon.

A developer could work locally by seeing Bulgarian keywords but always have their files saved as English.

The analogy with fonts and colors in an IDE is good, nobody cares about how the source appears to a developer, all we care about is what is shared.

It is your language and project, so you can do whatever you want to. I have just expressed my opinion and concern here.

That's fine with me, this is a very unusual feature, I expect some push back for that reason.

[Sherlock Holmes]

Incidentally my thread asking about uses for analog scopes we not the idiocy some here seemed to insinuate, to them I say try this thread.

[DiTBho]

edit:
waste of time, don't feed the troll

[Nominal Animal]

To continue from my last post:

If you create a mechanism for users to define the mapping between token sequences and patterns, and compiler backend abstract syntax tree, you don't have to define the programming language at all: you simply let each user define their own.

A different mapping could be used from token sequences and patterns to bytecode runtimes, like Java and CIL.

In theory, this would allow the same code to be compiled for CIL and Java runtimes, or use GCC or LLVM backends to generate machine code, just by defining the mapping between structures (token sequences and patterns) to each target.

Additionally, similar to GitHub, you could have a centralized repository of projects, but continuing with the social responsibility, it could automatically scan the token mappings (to human-readable languages), and assign each token set a political correctness score and warn sensitive developers if negative words like "master", "slave", "daemon", etc. are used.  As increasing number of young people are sensitive to such issues, but still interested in coding, this would lower the inherent stigmatizing barriers in current software development communities.

[Sherlock Holmes]

I'm looking at the way to best represent exception handling in this new language.

Like in C# and Java, accessing variables defined within the scope of the faulting block should likely be prohibited since the fault might have been associated with the instantiation of those variables.

Making 'catch' a keyword statement mean's we could write this as:

Code: [Select]

procedure English (X)

declare counter binary(15);
 
        counter = FACE B034 D85F BAD7:H;

if counter > 0 then
   call retour;
else
   return;
end;

loop while (a > b)
   go to place;
end;

catch;
          /* cannot reference container's scope, i.e. cannot reference 'counter'
end;

begin;

   dcl array(x) binary(15);

   // do stuff

   catch;
              // cannot reference 'array' but can reference 'counter'
              // since the exception arose in this 'begin' block.
   end;

end;

The idea here is that a 'catch' block is an optional statement inside another block, rather than a clause within a try-catch syntactic construct.

Any code can throw an exception, if there's a 'catch' in scope invoke it, if not, search up the stack looking for one.

In C#, Java and I presume C++, a 'catch' block must be attached to a 'try' block, whereas here we avoid the need for an explicit 'try', we let a 'procedure' block a 'begin' block and so on, have an optional, enclosed 'catch' block instead...

[Nominal Animal]

One facet that I've been thinking about is code comments, and how to properly facilitate those in a multicultural, multilingual project.

One option is to ban direct source comments –– the code speaks for itself, after all ––, and instead use hyperlinks to specific team-wide emails (using the message-id) or IM discussions (using the exact date and time).  When those involve people outside the immediate team, they will use either commonly-agreed language, the shared language between the teams, or the messages and emails will be translated to the languages involved.  Good development environments already support normal hyperlinks within source code, so making such hyperlinks is trivial.

There may be a temptation to sidestep such rules by using otherwise unused literal strings in the sources –– like in Python, where the first literal string in a class, method, or function, is used for documenting it (pydoc) ––, so some teams might wish to ban those as well, and instead use keys referring to a database entry (with each string identified by the key and the language).   At build time, the compiler can trivially check which keys are used, and list those; which also makes localization and language version completeness easy to track.

[tggzzz]

–– the code speaks for itself, after all ––

No, it doesn't, except for trivial stuff.

In particular these things cannot be visible in the source code:

• why the code is that way and not another way
• the conditions under which it will behave as expected, and conditions under which it might not
• what it is not guaranteed to do
• permitted sequences function invocations

If all that is in a separate document, then you have even more chance of, ahem, "asynchronism" than with comments in the source code

Please don't mutter something about TDD. Usually the tests are the bare minimum crap, are unlikely to be comprehensive, and cannot prove that the code work. But you, at least, know that

[SiliconWizard]

Agree with tggzzz here.

You may write external documents to explain, for instance, a very complex algorithm. But otherwise, comments in the code still stand a much better chance of being in sync and being relevant. Besides, engineers usually hate writing documents, so adding some relevant comments in the code is a better option, they usually do not hate doing this as much. Of course the comments must be relevant, so as said above, comment the why rather than the how, and the how only sparingly and only if it's really non-trivial.

Write documents for specifications though. Oh, specs, you know, the bad word. Who needs specs, right? Just write some code and see if it passes tests.
Yes, TDD is (usually) bullshit and a misnomer. Testing is good. But specs should drive development, not tests. And what tells you that you're gonna do a better job at implementing a test for some spec, than at implementing the functionality itself?

[Sherlock Holmes]

Agree with tggzzz here.

You may write external documents to explain, for instance, a very complex algorithm. But otherwise, comments in the code still stand a much better chance of being in sync and being relevant. Besides, engineers usually hate writing documents, so adding some relevant comments in the code is a better option, they usually do not hate doing this as much. Of course the comments must be relevant, so as said above, comment the why rather than the how, and the how only sparingly and only if it's really non-trivial.

Write documents for specifications though. Oh, specs, you know, the bad word. Who needs specs, right? Just write some code and see if it passes tests.
Yes, TDD is (usually) bullshit and a misnomer. Testing is good. But specs should drive development, not tests. And what tells you that you're gonna do a better job at implementing a test for some spec, than at implementing the functionality itself?

I worked at a company once which did not permit comments. I did not share that view, but it was what it was, these were no lightweights either, amongst the sharpest developers I ever worked with.

I couldn't agree more about specifications, having been a programmer for decades and also a formal (hand off the code) project manager I've seen how easily time (itself a resource) can get wasted, huge amounts of time.

The most basic reason for decent specs is that there are usually a dev team and a qa team, the dev team need to write code and the qa team need to write test cases, unless these two teams are using the same identical problem statement you're going to get pseudo defects and often lots of them and that costs time.

[tggzzz]

Yes, TDD is (usually) bullshit and a misnomer. Testing is good. But specs should drive development, not tests. And what tells you that you're gonna do a better job at implementing a test for some spec, than at implementing the functionality itself?

The idea behind TDD isn't too bad: write a test that illustrates some part of the specification. It will fail, so write code until it doesn't fail. If done with good taste and intelligence, that can work - especially for simple additions to functionality. But when the ignorant religious zealots get hold of the concept, they make it useless: "the green light is on therefore it is working".

And it is "difficult" to write a test for the appallingly named "non-functional specifications" such as "downtime <5minutes per year" or "updates to X must be ACID".

[MIS42N]

Agree with tggzzz here.

You may write external documents to explain, for instance, a very complex algorithm. But otherwise, comments in the code still stand a much better chance of being in sync and being relevant. Besides, engineers usually hate writing documents, so adding some relevant comments in the code is a better option, they usually do not hate doing this as much. Of course the comments must be relevant, so as said above, comment the why rather than the how, and the how only sparingly and only if it's really non-trivial.

Absolutely.

 '–– the code speaks for itself, after all ––' yes, it does say what it does but nothing about why. I cannot conceive why "I worked at a company once which did not permit comments". Assembler is more obtuse than most languages, I find documentation almost essential. Take the following subroutine - in any language its purpose might be divined from its name, what it is doing (multiply, divide, convert to BCD) is very clear, but why it does what it does would be very difficult to work out. In my opinion documentation is very important and any language should make it easy to do it in whatever way is convenient - blocks, one liner, etc.:

Code: [Select]

; -- control volts to BCD --
; Converts the 24 bit control volt value to microvolt
; It is assumed that PWM 0x000000 = 0 Volt PWM 0xFA0000 = 5 Volt
; 0xFA0000 = 16,384,000.
; The fraction 112/367 is within 8uV at full scale, the integers
; used are limited by the 32 bit signed arithmetic routines.
; The value is not intended to be accurate, the source of the
; control voltage is unlikely to be perfect.
; Input is already pushed onto the stack
; Output is delivered to PackedD
CV2BCD:
    CALL    PushLit
    data    D'112'
    CALL    multiply
    CALL    PushLit
    data    D'367'
    CALL    divide
TI2BCD: ; entry used to convert stack to BCD
    CALL    Pop4
    data    REGA
    CALL    BIN2BCD
    RETURN


[Nominal Animal]

I disagree.  After all, OP's purpose is to create a programming language that is concise but descriptive enough to not need comments, because users can choose the language (and perhaps even the keywords they want to use).

I can envision this being a transition path from PL/I, IPL, COBOL, FORTRAN 77, various domain-specific languages based on SKI combinator calculus, BASIC, SAKO, Qalb, Fjölnir, Malbolge, and others, into proper modern CIL-based programming languages, with minimal disruption or re-education needed for the developers.

[Sherlock Holmes]

Agree with tggzzz here.

You may write external documents to explain, for instance, a very complex algorithm. But otherwise, comments in the code still stand a much better chance of being in sync and being relevant. Besides, engineers usually hate writing documents, so adding some relevant comments in the code is a better option, they usually do not hate doing this as much. Of course the comments must be relevant, so as said above, comment the why rather than the how, and the how only sparingly and only if it's really non-trivial.

Absolutely.

 '–– the code speaks for itself, after all ––' yes, it does say what it does but nothing about why. I cannot conceive why "I worked at a company once which did not permit comments". Assembler is more obtuse than most languages, I find documentation almost essential. Take the following subroutine - in any language its purpose might be divined from its name, what it is doing (multiply, divide, convert to BCD) is very clear, but why it does what it does would be very difficult to work out. In my opinion documentation is very important and any language should make it easy to do it in whatever way is convenient - blocks, one liner, etc.:

Code: [Select]

; -- control volts to BCD --
; Converts the 24 bit control volt value to microvolt
; It is assumed that PWM 0x000000 = 0 Volt PWM 0xFA0000 = 5 Volt
; 0xFA0000 = 16,384,000.
; The fraction 112/367 is within 8uV at full scale, the integers
; used are limited by the 32 bit signed arithmetic routines.
; The value is not intended to be accurate, the source of the
; control voltage is unlikely to be perfect.
; Input is already pushed onto the stack
; Output is delivered to PackedD
CV2BCD:
    CALL    PushLit
    data    D'112'
    CALL    multiply
    CALL    PushLit
    data    D'367'
    CALL    divide
TI2BCD: ; entry used to convert stack to BCD
    CALL    Pop4
    data    REGA
    CALL    BIN2BCD
    RETURN


Well said, however in my formative years, learning "programming" on IBM mainframes, I was beaten if I did not comment. Later I developed a reputation for plentiful, constructive comments.

I still, often, begin to write non trivial code by writing the comments first, little blocks of comments that I then "back fill" with code.

But at Faithlife many years later, they "do not do" comments. Their reasons were things like "the comments never get updated when the code is changed" and "you can compile the code but not the comments" which is - like it or not - very true.

I did not agree with their overall approach but it was entrenched in them and they did raise some very relevant points, they are first rate developers but I disagreed about this (and some other things).

A comment that no longer matches the code, is worse that no comment at all - this can be true, so it's far from clear what to do really.

[SiliconWizard]

Organizations more or less all have their own set of rules, and whether they are good or lame, you just have to follow the rules. Discussing those rules is often pointless: if you work there, you don't have a choice, and if you don't work there, you may not have a full view of the rationale behind the rules.

The risk of comments not being up to date is one of the most common arguments I've heard for defending the zero-comment approach.

You may wonder if a developer that fails to keep comments up to date can be trusted on their code, though.

And then, as we said above, if you comment the 'why' rather than the 'how', chances of having comments not up to date are drastically lower. While changing the 'how' can happen pretty frequently (and thus, the probability of having obsolete comments is high if they are about the 'how'), the chances of changing the 'why' is much more uncommon, and if you change the 'why', then usually that means a rewrite big enough that you'd almost have to do it on purpose to keep old, obsolete comments about the 'why'. Just my 2 cents.

Finally, that's also what code reviews are for.

[tggzzz]

I disagree.  After all, OP's purpose is to create a programming language that is concise but descriptive enough to not need comments, because users can choose the language (and perhaps even the keywords they want to use).

If a programming language can express why rather than what, then that will be a truly remarkable advance, and I will be very interested in the language. I suspect those concepts would find their way into many programming languages in the future.

But I'm not going to hold my breath, either for this language nor future languages

[Sherlock Holmes]

Organizations more or less all have their own set of rules, and whether they are good or lame, you just have to follow the rules. Discussing those rules is often pointless: if you work there, you don't have a choice, and if you don't work there, you may not have a full view of the rationale behind the rules.

The risk of comments not being up to date is one of the most common arguments I've heard for defending the zero-comment approach.

You may wonder if a developer that fails to keep comments up to date can be trusted on their code, though.

And then, as we said above, if you comment the 'why' rather than the 'how', chances of having comments not up to date are drastically lower. While changing the 'how' can happen pretty frequently (and thus, the probability of having obsolete comments is high if they are about the 'how'), the chances of changing the 'why' is much more uncommon, and if you change the 'why', then usually that means a rewrite big enough that you'd almost have to do it on purpose to keep old, obsolete comments about the 'why'. Just my 2 cents.

Finally, that's also what code reviews are for.

Well said, this is why I personally hold the view that designing, writing, maintaining and enhancing software is best described as a "craft" rather than "science" or "engineering", I liken it to architecture myself, there are aspects that are based in physics and mechanical engineering yet there are also aspects that are aesthetics, style, atmosphere, art and so on - both aspects are essential.

[Nominal Animal]

I personally hold the view that designing, writing, maintaining and enhancing software is best described as a "craft" rather than "science" or "engineering", I liken it to architecture myself, there are aspects that are based in physics and mechanical engineering yet there are also aspects that are aesthetics, style, atmosphere, art and so on - both aspects are essential.

Spoken like a true Windows-only C# programmer who has zero idea about verifiability, robustness, or security.  Congratulations!
I don't recall when I last read such idiotic drivel, and I often read people spouting conspiracy theories at Rense and AboveTopSecret.

It's like listening to a bridge-builder describe how they scoff at stuff like engineering calculations, and instead prefers to call themselves a craftsman.  Would you trust such a bridge?  I wouldn't.
The world is already chock full of crappy software written by craftsmen and monkeys, ignoring all engineering principles and scientific thinking and research.
We do not need a single more.  Please!

My last few posts have been an experiment.  As I've mentioned in other discussions, I sometimes entertain ideas and concepts I do not believe in at all, like conspiracy theories, just to find out where they lead to, and how their proponents see the world around them.  In this case, I inverted everything I have learned in practice about teamwork, portability, maintainability, and so on, and wanted to see if OP has any pushback to the known non-working ideas I would describe.

The concepts I described:

• #743: token stream, user-defined mapping between tokens and their human-readable/printable representations, ZIP archives containing multiple files, encoding the source as a Gödel number, encrypting source files, centralized vendor storage for encryption keys for keeping source code 'hostage'
• #761: replacing interaction and common rules ('laws') by each team doing their own thing, minimizing inter-team interaction; using localization as a barrier between teams by encouraging them to use different languages during development; leveraging political fads instead of technical suitability to entice/force developers to use (this) particular programming language
• #803: leave the token pattern/sequence to AST mapping to the users to define; use of a centralized source code management to score and enforce political fads and views on developers; use of ideology as the central idea in the programming language to attract attention, while completely ignoring all technical aspects
• #805: banning comments, using remote and often unavailable resources for 'documentation' and 'explanation' in code; also, re-read the post subject
• #811, as the discussion is concentrating on ridiculously dysfunctional or irrelevant details: clearly referencing Intercal (subject) and Malbolge.  Apparently throwing buzzwords with a couple of examples of ridiculous and dysfunctional programming languages, and concentrating on old (FORTRAN77, COBOL) and single-vendor controlled, basically single-OS environments (CIL), raises no objections or comments at all.

None of these work in practice, but are enticing if and only if one does not consider the implementation or functionality and the related consequences.


Human-readable text is converted to tokens using lexical analysis.  The sequence of tokens are converted to some form of abstract syntax, usually an abstract syntax tree (AST), by a parser performing syntactic analysis.  Many – if not most – interpreters and compiler input frontends use C code generated from a Backus-Naur form specification by flex and Yacc or GNU Bison.  The latter can also generate lexers-parsers for C++ and even Java.

It is the mapping from this abstract form, to the abstract forms that can be generated into machine code, that defines a programming language.  For example, there is no such concept as a "function" in machine code.  There are subroutines, and an instruction that will call a subroutine, which ends at some kind of a return statement, which causes the execution to continue at the instruction following the call.  So, to map a function definition to a form comprehensible to the backend, you need to include things like "include this symbol (the name) in local symbol table using type 'function', ..." and so on.
There is a lot of scientific research on how this can be done.  Leaving it to users is like giving an English-only speaking student a Hungarian dictionary, and telling them to write a novel in Hungarian.  Perhaps one can consider writing to be a craft, but unless you know the rules and science, all you generate is word soup –– or horribly crappy software.

The above means that syntax and grammar, including the selection of reserved keywords and operators –– all tokens recognized ––, is something that can and should be finalized last, just before the language specification is released.  Until then, the syntax and grammar can be varied at will, without affecting the core of the language: exactly what it does, i.e. the mapping between the language-specific AST and the language-and-architecture independent AST used by the code generating backend.  Starting at syntax and grammar is like deciding to create a new spoken language like Esperanto, and prioritizing deciding whether the language will use Oxford comma or not.  Utterly ridiculous and irrelevant!  Such details are best resolved last, not first.

A lot of the practical progress in the last decade or so in computer science has been in optimization at both the frontend (language-specific AST) and backend (architecture and language-independent AST), using (old) discoveries in graph theory, and basically the exponentially increasing computational power allowing slower/more computationally costly algorithms to be used to simplify the ASTs.  Using resources like Compiler Explorer (godbolt.org) to examine the machine code generated by different compilers and different optimization levels, shows both how much work has already been done here, but also how much work there is still to be done with the current compilers.

For the GNU Compiler Collection, the backend language is called GENERIC (and GIMPLE is its simplified version, it being possible to map GENERIC to GIMPLE, splitting certain constructs into multiple ones); see here.  LLVM is the backend language, although 'intermediate representation' (IR) is used when 'LLVM' would be ambiguous; see here.

In a typical complex application/service/firmware build, there are multiple stages.  It is not only the 'compiler' that accesses the source code, various tools from code generators (like flex and yacc/bison) to static code analysis to dependency checkers (to speed up builds) and so on.  Having the exact source code in plain text formats allows the widest possible set of tools here; including project-specific custom tools (like the many ones used in building the Linux kernel, for example; from configurators to formatting checks to locking scheme verification).

Even script languages like Python use the plain text source, and 'compile' to internal token/bytecode format dynamically, although it can also store the binary representation of the source code in .pyc files if so requested, to reduce load latencies; even then, it does verify that the binary file is more recent than the text source file.  This is not just an arbitrary decision, but a decision based on lots and lots of experience.  Plain text sources will always be more versatile (and therefore useful to users and developers) than binary formats.

While ZIP archives sound good, they are basically write-only.  To modify just one file, basically the entire archive has to be recompressed; or at least recopied.  Thus, it makes zero sense to use any kind of packed archive format for source code during development, because it simply slows down I/O.  Using a sensible directory/folder structure will always work better.  Learning how distributed source management tools like Git work, will give you a much better picture of the existing knowledge and experience in this subfield.

Gödel number was an indication that I'm being surreal; I couldn't just be serious, because that could actually lead people who find my contributions worthwhile reading, astray.  It means that instead of a sequence of natural numbers (identifying the tokens), the source code is encoded as a single huge natural number: a product of the prime powers of the token.  The i'th multiplier is the i'th prime raised to the power of the natural number representing the i'th token.  While encoding is reasonably fast, decoding involves prime factorization of a natural number possibly hundreds of thousands of bits long.  There is absolutely no reason to do this!

Vendor lock-in and vendor control of our projects is something you might not be afraid of at all as a developer, until it bites you.  Then you'll avoid it like the plague it is.  The vendor owning encryption keys (and essentially having access to all clients' encrypted sources) is probably the scariest scenario of rent-seeking vendor behaviour that I can think of.  No sane experienced developer will subject themselves to it, it is simply just too risky: years of work may be irretrievably lost because of 'minor vendor policy change'.

As described by others, source code comments are worthless if they describe what or how the code does what it does.  We know from decades-old projects that are still alive and maintainable, that the most useful and practical comments are those that describe developer intent and assumptions.  For example, if you refactor a function, you typically should not need to change the comment describing the purpose and assumptions of the function, unless the assumptions (for example locking scheme) changes.

I have done my best work in teams with wildly differing members.  I have also taught basic computer skills (to both youngsters at the turn of the century, as well as to teachers older than myself), mentored dozens of programmers (from just about every continent except Antarctica), worked for two different universities with lots of exchange students (so much so that typically even lunch discussions were in English, to not exclude anyone present – it was especially funny when we noticed everybody present was fluent in Finnish).  I have lead teams, interviewed and hired people.
In my experience, synergistic collaboration – where teams become more than just the sum of their parts – requires effective, clear, honest, direct, and free discussion, debate, and even argument.  Everybody participating must agree that arguments/debates are done at the logical level, and must only concern things; and peoples' personalities must be kept out of it.  The rules must be clear, easily checked, and apply to everyone equally.
Intersectionalist and cultural relativist approach where each person is governed by rules depending on non-technical aspects of their personality will not work, and will destroy teams and significantly degrade their work product and performance, because humans are social animals with inherent, biological concept of fairness, specifically procedural justice and distributive justice (as observed in several animal species also).
Competitiveness based on meritocracy is useful, but may lead to internal conflict within a team, so I recommend larger emphasis on team rewards than individual rewards in most cases; it does vary on the situation, though.

In simple terms, the current fad of political correctness is dysfunctional in development environments.  It leads to reduced discussions (because all discussions have a risk of offense, so avoiding discussions is always the safer option in PC-conscious environments).  We can see this in how certain open source projects (funded by Red Hat/IBM in particular) are already asking for isolation from users, especially in regards to problem reports.  They would prefer to receive only automatically generated problem reports, even though they contain far less information.

The period of stagnation in the GCC community in the first decade of the current century was largely because the key GCC developers refused to consider anything external to the project, unless the reporter had at least a PhD in Computer Science.  I do not know how those developers were retired, whether it was mutually agreed upon, or some kind of machination between the GNU foundation and the GCC project, and how much of the change was driven by the eventual shift from C to C++, but overall, it is a perfect example of how isolated open source developers can kill projects.

Also, the longest-lived, most 'successful' (for various definitions of 'successful') projects, have traditionally been led by 'dictatorial' leaders, often with analogs of 'advisory councils'.  As usual, the leader mostly sets the social atmosphere and long-term goals in the project, but also seems to be the quality enforcer: responsible for rejecting sub-standard suggestions.  For the Linux kernel, Linus Torvalds has been berated for his harsh language, not for his 'autocratic control'.  Democratic processes are easily subverted (as seen by for example the Debian project regarding init systems; just read the discussions prior to the general resolution, and compare to the consequences observed today), and many respectable developers occasionally produce utter garbage that deserves to be rejected.  See for example Greg KH's suggested kdbus subsystem, discussed at the linux-kernel mailing list.  (RedHat proponents at the time believed that if they got Greg KH to suggest it, his authority would be enough to silence any objections.  No, that didn't work, because the contribution was crap.  The good thing about it was that Greg KH just accepted the rejection, and that was it: it did not, and should not, affect his later contributions, because contributions are and must be evaluated on their own merits, and not based on who submitted them.  He is still very highly regarded Linux kernel developer, and I personally 'trust' him; nevertheless, whatever he submits as a new feature, requires exactly the same scrutiny as any other submission.  This is how a divergent, distributed team functions well.)

I could also describe why I find complex runtimes like Java and CIL objectionable, but I'm not sure it is worth going into here.  Simply put, they are an unnecessary abstraction layer that attempts to gloss over differences in environments and operating systems and processor architectures.  In my experience, this leads to the phenomenon historically referred to as "writing FORTRAN code in any programming language".  While it makes development available to less skilled developers, and therefore cheaper, they really bring no real benefits (compared to native code written in a comparable language) to the end users.
I just care more about end users than developers myself; specifically, the end users that contribute their time, effort, or money to my open source projects; and the paying end users for the proprietary projects I've contributed to.  With sufficient skills and ability to implement anything I want in about a dozen programming languages, the Java RE and MS CIL are unnecessary and unwanted abstraction layers to me: waste of resources.

To repeat once again: to develop a new language, you need to consider both how the concepts and algorithms are implemented in that language, and what kind of machine code one should expect them to generate.  Starting from the syntax and grammar is starting from how the code should look like; something that logically should be decided last, just before the language specification itself is finalized.  You need to ask yourself "Why would I want to implement algorithm X or system Y in this language, as opposed to some other language?".  If your answer is "Because it's better", you do not have the skill in design, logic, and software engineering to pull it off, sorry; and are just daydreaming about appearances without any actual content.

[tggzzz]

I personally hold the view that designing, writing, maintaining and enhancing software is best described as a "craft" rather than "science" or "engineering", I liken it to architecture myself, there are aspects that are based in physics and mechanical engineering yet there are also aspects that are aesthetics, style, atmosphere, art and so on - both aspects are essential.

Spoken like a true Windows-only C# programmer who has zero idea about verifiability, robustness, or security.  Congratulations!
I don't recall when I last read such idiotic drivel, and I often read people spouting conspiracy theories at Rense and AboveTopSecret.

It's like listening to a bridge-builder describe how they scoff at stuff like engineering calculations, and instead prefers to call themselves a craftsman.  Would you trust such a bridge?  I wouldn't.
The world is already chock full of crappy software written by craftsmen and monkeys, ignoring all engineering principles and scientific thinking and research.
We do not need a single more.  Please!

I had very similar thoughts, the major difference being that C# is no worse than other languages.

[tggzzz]

Snipped many sensible poins...

To repeat once again: to develop a new language, you need to consider both how the concepts and algorithms are implemented in that language, and what kind of machine code one should expect them to generate.  Starting from the syntax and grammar is starting from how the code should look like; something that logically should be decided last, just before the language specification itself is finalized.  You need to ask yourself "Why would I want to implement algorithm X or system Y in this language, as opposed to some other language?".  If your answer is "Because it's better", you do not have the skill in design, logic, and software engineering to pull it off, sorry; and are just daydreaming about appearances without any actual content.

Precisely.

The OP appears not to want to use those concepts as a starting point, bit to concentrate on what interests them. That's reasonable, iff the limitations are understood and accepted.

[DiTBho]

@Nominal Animal
Java ... my Java-cup says "program once, use many"...and I laugh every time I use it to drink my coffee.

It was the Java v1.0 motd when I bought that cup in 2001, and I found that it is somehow a good cup that keeps the temperature of the coffee (so the box wasn't lying when I bought it), just ... I keep it on my desk, but I no longer trust what it says about programming 

[Nominal Animal]

I had very similar thoughts, the major difference being that C# is no worse than other languages.

It is similar to Java in that it compiles to CIL, a stack-based bytecode interpreter, which is touted as "portable".  We all know how portable Java is, and how portable .Net/Mono is: not very, when you start trying to get actual work done, instead of simple examples.  Instead of acknowledging differences between operating systems and hardware architectures, it applies a heavy (again, bytecode interpreter/JIT compiler) abstraction layer to hide them.  For this reason alone, C# is not a language one should base their understanding of programming languages on.

(We can nitpick about NGEN, though.)

Portability and adaptation to different architectures, and understanding the different approaches (paradigms) different languages have, is utterly paramount for understanding software engineering in a way that one can apply in more than one particular niche (Windows C# programming).  C# is designed to avoid having to do that.

If we ignore the single-vendor control, the reliance on CIL, and just look at the language specification, say the latest version (C# 6.0) standardized by ECMA in ECMA-334.pdf –– noting that Microsoft published it in 2015, ECMA-334 was published in 2022, and Microsoft has already published C# 11.0 –– you could compare it to older versions of C++.  In particular, it does not have specific-size integers, and instead codifies that 'short' is 16-bit, 'int' is 32-bit, 'long' 64-bit, and the 'char' type uses UTF-16; i.e. IP32 or LP64.
In short, meh.

Java ... my Java-cup says "program once, use many"...and I laugh every time I use it to drink my coffee.

Exactly.

If we do not learn from the past, we're doomed to repeat the same mistakes, as well.

[MIS42N]

My last few posts have been an experiment.  As I've mentioned in other discussions, I sometimes entertain ideas and concepts I do not believe in at all, like conspiracy theories, just to find out where they lead to, and how their proponents see the world around them.  In this case, I inverted everything I have learned in practice about teamwork, portability, maintainability, and so on, and wanted to see if OP has any pushback to the known non-working ideas I would describe.

Aha. I looked at some of those and thought WTF? I want to be constructive so try not to malign other posts.

In a way, programming is a craft. We walk the fine line between constraints, some being size of code, efficiency of code, cost of production, cost of maintenance, tolerance of bugs (e.g a game v. medical equipment). When some operation needs doing 20 times, if code space is not an issue but speed is then make it a macro and put it in line 20 times. If speed is not an issue, make a loop. Programming languages rarely make that choice for you. Use a binary search or a linear search of an ordered array? use hash tables or original data? They are not necessarily yes/no answers, a good programmer will make a good choice - the result of experience - is that not the hallmark of a craft?

But yes, it is less of a craft today when processing power and memory are cheap and plentiful. It is easy to use something that works rather than something that works better. Especially if the something better is not familiar to others. I had the joy of reducing the run time of an application from 3 hours to just over 1 minute (and won a bet for a beer for the effort). Today it may be the difference between 20 seconds and a tenth of a second, who cares?

[SiliconWizard]

[brucehoult]

I had very similar thoughts, the major difference being that C# is no worse than other languages.

It is similar to Java in that it compiles to CIL, a stack-based bytecode interpreter, which is touted as "portable".  We all know how portable Java is, and how portable .Net/Mono is: not very, when you start trying to get actual work done, instead of simple examples.  Instead of acknowledging differences between operating systems and hardware architectures, it applies a heavy (again, bytecode interpreter/JIT compiler) abstraction layer to hide them.  For this reason alone, C# is not a language one should base their understanding of programming languages on.

Wanting to define the result of every construct and getting bit-identical results from every program, no matter what machine or environment it is run on, are not evil goals. They are simply goals where getting maximum efficiency, performance, and execution predictability on any given machine is not a priority.

Modern machines are so fast that this is often fine.

Lots of people use things much more inefficient than Java or C#. For example Python, which gives not just 80% or 50% of the performance of native code, but 3% to 5%.

This is all completely at odds with the concept of cycle-accurate code on a PIC, of course.

[Nominal Animal]

I had very similar thoughts, the major difference being that C# is no worse than other languages.

It is similar to Java in that it compiles to CIL, a stack-based bytecode interpreter, which is touted as "portable".  We all know how portable Java is, and how portable .Net/Mono is: not very, when you start trying to get actual work done, instead of simple examples.  Instead of acknowledging differences between operating systems and hardware architectures, it applies a heavy (again, bytecode interpreter/JIT compiler) abstraction layer to hide them.  For this reason alone, C# is not a language one should base their understanding of programming languages on.

Wanting to define the result of every construct and getting bit-identical results from every program, no matter what machine or environment it is run on, are not evil goals.

Did I even imply they were?  I am only describing the reasons why I believe C# is not sufficient or suitable as the basis for ones understanding for designing a programming language.

Lots of people use things much more inefficient than Java or C#.

Yes, I use such things as well, but how is that supposed to be relevant here?

Do you seriously believe that people who only have used Java or C# have a well-rounded understanding of how programming languages and environments work?  Because that is what your reply seems to imply.

My own experience indicates they simply propagate the inefficiencies and domain-specific patterns as if they were universal (which they are not), and simply call the result better than what has been done before, without any scientific or engineering basis on such qualifications.