Re: [DotGNU]flexible for users, or flexible for developers? (wasRe:User Interfaces)

[Timothy Rue]

On 10-Jul-02 06:32:25 David Bradley <address@hidden> wrote:
 DB> S11001001 wrote:

>> I share a quote from Stroustrup:
>>
>> "C has its problems, but a language designed from scratch would
>> have  some too, and we know C's problems."
>>
>> This is why it's better to start with the CLI (stop calling it
>> .NET!
>> .NET is a marketing term. CLI is the system DG supports), find its
>> weak spots, and patch them, than to design something from scratch.
>>
 DB> I'm not sure if I'd say it is "better". Was Windows was better
 DB> because  it was built on top of MSDos. It may be "better" from
 DB> the view that it's  easier and less risky than coming up with
 DB> something unique.

 DB> David Bradley
 DB> (Not the guy on the IBM commercial)


I believe ".net" is a label for a much bigger chalk board that includes
"CLI". Upon trying to find a description of "CLI" the best I could do is
to extract some parts of the ECMA document on CLI (see below for snips).

It seems that there is that within CLI, as CLI is with .net, that is of
core focus in understanding CLI. That is CTS, where the most important
statement is:

"The Common Type System is about integration between languages: using
another language's objects as if they were one's own."

The fundamental problem with any language is that in order for a language
to express some things in the scope of all things, it must limit itself
with self consistancy, not contridict itself. In other words all things
are not possible in any one language. I believe the most logical example
is that of the mathmatical Turning Haulting Problem.

The way you get around the problem is to either speak multipul languages,
using one language to get around another languages short commings, or to
develope a language big enough to combine all the concepts expressed in
the languages it combines without contridiction (with the downfall of
efficency failure). I believe the later was tried with Ada, and the
former is what CLI is supposed to enable via CIL (Common Intermediate
Language).

But in any event, what you have is:

Language(s) -> translation stage(s) -> binary (1's & 0's) machine language

The translation stage is what is important to get right.

So how versatile is CTS and CIL?

Put all that we have now in programming languages in a pot and boil it all
down..... and you end up having CTS and CIL? Perhaps.

But what about what we have yet to create, innovate? And how might the CTS
and CIL vocabularies hinder such advancements?

In and email from you, David:

"What is so frustrating for me, is that our development environment has
stagnated. In the last 15 years, nothing new has really been created.
Even this CLI effort is still based on a dated flat file system.
Programming is so much more dynamic than what flat file representation
of code allows. Yet we saddle ourselves with system after system."

I really don't know what you are suggesting here, as the binary nature of
machine code (a switch) is inherently 2D flat. But what I do realize is
that there is a growing spectrum of programming concepts described by CTS
and CIL. A spectrum that ranges from what is more concrete (less abstract
and more direct to machine code) to what is of ever higher levels of
abstraction (such as object oriented programming concepts).

So add your new concepts to the list and we will quantize it so to
integrate it into the vocabulary sets of CTS and CIL..........But somehow
I feel like this is a task to reach the number "1" by tacking on another
"9" to the right end of a growing string .9999999999999

Or in other words: somehow we need to get all possible things into the pot
before we start boiling it down to get the majic unified .......... core
of translation right. That is of course assuming that the whole point of
creating a programming language is so we don't have to program in machine
language, but instead work at higher levels of abstraction while letting
the translation happen in programmed automation, of what we know we would
manually repeat the same exact way every time.

In all of this I see the same set of actions being performed over and
over, be it by machine or human. Sorta like a carrier wave of a radio
signal, not concerned about what it is sending, but only that it, the
carrier wave is consistant and well defined. For without the carrier wave,
nothing can be sent, nothing can be communicated.

And it starts out with the action "this = that", "word = extended
definition or instruction, etc.." The act of defining what a symbol means
in order to simplify use so to decrease the amount of time required to
communicate the definition meaning details.

In the Small industry of autocoding (which should have started out as a
cottage industry but started out on the other end of the spectrum), it is
interesting to note that regardless of what the initial user communication
interface is, the code generated is of the lowest levels of abstraction,
the lower the better, as at lower levels code is easier to autoverify
functional correctness as well as ........drum roll.......AUTO-DOCUMENT it.

With all this in mind, perhaps the patch to apply to CTS and CIL is to
identify what is at what levels of abstraction, and then from there to
focus on the lower levels of abstraction with a goal of creating an
autocoding engine and the tools to create higher level abstraction User
Interfaces to the autocoding engine.

This way it becomes not a matter of what language you use but rather what
autocoding interface you use. Which can be anything you make it, be it a
point and click, GUI, command shell, interregation sequence, etc... or
some combination.... perhaps UML interface for UML fans..... but most
important, it's open to whatever interfaces one can think up, be it a
general programming interface to a industry and field specific interface,
or how about an interface autocoder for developing autocoding interfaces?

I suspect the difference would be similiar to the difference between
using a language and using a GUI? Know any users who speak GUI? Or do they
simple just use it?

And there is nothing stopping generated code from being sent thru the CLI
or being sent thru a more specific translation to binary process.


Snips from http://www.ecma.ch/ecma1/STAND/ecma-335.htm
Standard ECMA-335
December 2001

Partition I: Architecture
Partition II: Metadata Definition and Semantics
Partition III: CIL Instruction Set
Partition IV: Profiles and Libraries
Partition V: Annexes (ECMA/TC39/01/19A)

5 Overview of the Common Language Infrastructure
The Common Language Infrastructure (CLI) provides a specification for
executable code and the execution environment (the Virtual Execution
System, or VES) in which it runs. Executable code is presented to the VES
as modules. A module is a single file containing executable content in
the format specified in Partition II.

At the center of the Common Language Infrastructure (CLI) is a single type
system, the Common Type System (CTS), that is shared by compilers, tools,
and the CLI itself. It is the model that defines the rules the CLI follows
when declaring, using, and managing types. The CTS establishes a framework
that enables cross-language integration, type safety, and high performance
code execution. This section describes the architecture of CLI by
describing the CTS.

The following four areas are covered in this section:

The Common Type System. See Chapter 7.
The Common Type System (CTS) provides a rich type system that supports the
types and operations found in many programming languages. The Common Type
System is intended to support the complete implementation of a wide range
of programming languages.

Metadata. See Chapter 8.
The CLI uses metadata to describe and reference the types defined by the
Common Type System. Metadata is stored (persisted) in a way that is
independent of any particular programming language. Thus, metadata
provides a common interchange mechanism for  use between tools that
manipulate programs (compilers, debuggers, etc.) as well as between these
tools and the Virtual Execution System.

The Common Language Specification. See Chapter 9.
The Common Language Specification is an agreement between language
designers and framework (class library) designers. It specifies a subset
of the CTS Type System and a set of usage conventions. Languages provide
their users the greatest ability to access frameworks by implementing at
least those parts of the CTS that are part of the CLS. Similarly,
frameworks will be most widely used if their publicly exposed aspects
(classes, interfaces, methods, fields, etc.) use only types that are part
of the CLS and adhere to the CLS conventions.

The Virtual Execution System. See Chapter 11.
The Virtual Execution System (VES)  implements and enforces the CTS model.
The VES is responsible for loading and running programs written for the
CLI. It provides the services needed to execute managed code and data,
using the metadata to connect separately generated modules together at
runtime (late binding). Together, these aspects of the CLI form a unifying
framework for designing, developing, deploying, and executing distributed
components and applications. The appropriate subset of the Common Type
System is available from each programming language that targets the CLI.
Language-based tools communicate with each other and with the Virtual
Execution System using metadata to define and reference the types used to
construct the application. The Virtual Execution System uses the metadata
to create instances of the types as needed and to provide data type
information to other parts of the infrastructure (such as remoting
services, assembly downloading, security, etc.).


5.2.3 Summary
The Common Type System is about integration between languages: using
another language's objects as if they were one's own.

The objective of the CLI is to make it easier to write components and
applications from any language. It does this by defining a standard set of
types, making all components fully self-describing, and providing a high
performance common execution environment. This ensures that all CLI
compliant system services and components will be accessible to all CLI
aware languages and tools. In addition, this simplifies deployment of
components and applications that use them, all in a way that allows
compilers and other tools to leverage the high performance execution
environment. The Common Type System covers, at a high level, the concepts
and interactions that make all of this possible.

The discussion is broken down into four areas:

Type System - What types are and how to define them.

Metadata - How types are described and how those descriptions are stored.

Common Language Specification - Restrictions required for language
                                interoperability.
Virtual Execution System - How code is executed and types are instantiated,
                           interact, and die.

---
Timothy Rue
Email @ mailto:address@hidden
Web @ http://www.mindspring.com/~timrue/