В процессе разработки - нужны нестандартные идеи

[Полянин М.А.]

Несмотря на все проблемы, дадим таки людям шанс реабилитироваться , вдруг найдется понимающий человек, с серьезным отношением и интересными подходами к решению.

Проект упорно движется, и уже додвигался ужас до чего. Опишу кратко, если найду разумный отклик (т.е. я не готов обсуждать здесь технологии ОО-проектирования и пр. - это все только после выполнения вопрощающим домашней работы - изучения их основ), то можно обсудить детали.

1. Ветка ОС (Для сети нужны терминалы, для терминалов сети нужно оборудование, а для оборудования - ОС):

Все известные ОС рассмотрели и выкинули их на помойку. Нужно написать ОС, согласно современным технологиям - объектно-ориентированную.

Проектируем структуру ОО ОС.

2. Ветка ЯзыкПрограмирования (Для ОО ОС нужен ОО язык). Известные компилируемые ОО языки рассмотрели и выкинули их на помойку, пришли к модернизации С/С++.

Кратко об этом новом ОО компилируемом языке:

- язык делится на две части - user/base(core):
-- user пишется на base - это язык для приложений
-- base пишется на С - это ОО язык поддержки компилятора

- частью языка кроме спецификации являются:
-- исходники user/base(core) этого языка (вариант компилятора этого языка - default compiler, вариант среды и утилит разработки )

- отличия user части языка от С++:
-- диалекты
-- новые типы памяти
-- низкоурневое управление
-- и очень много другого

3. Ветка ЯзыкИнтернациональный (человеческий язык "международного" общения). Сеть и язык программирования нуждается в техническом языке для человеческого общения и в информационном языке для информационных материалов.

Известные искусственные языки рассмотрели и выкинули их на помойку, пока ни к чему конкретному не пришли, нужны:
- перечень звуков
- перечень коней
- перечень способов словообразования
- кой чего еще

Принимаются ответственные предложения от заинтересованных лиц, владеющих научным методом .

[Полянин М.А.]

Подчекнул на всякий случай лиц, владеющих научным методом - обратите на эту просьбу особое внимание, нет смысла спорить здесь о нем! (сам научный метод здесь)

[in4]

А почему Объектно-Ориентированные ОС и Язык Программирования (ЯП)?
И почему ЯП С-подобный?! Есть варианты и получше, из текстовых - Форт, например!

- перечень коней

корней?
И есть сравнительный анализ искусственных языков? Про УСК(Универсальный Семантический Код) Мартынова тоже читали?

[Полянин М.А.]

А почему Объектно-Ориентированные ОС и ЯП?

Ну, началось... Потому что это единственный известный мне "эффективный" способ построения и сопровождения больших программных систем. Это решенный вопрос.

Если кто-то считает что это не так, то должен быть готов предоставить "научный труд", в котором сравнивается ОО-техника проектирования программ с иной, более прогрессивной и описываются преимущества и недостатки обоих.

Вы, я так понимаю, не готовы предоставить? Я так и думал .

И почему ЯП С-подобный?!

Пользовательская часть языка (uС++) похожа на С только тем, что и там и там есть типы, есть функции, в деталях они вполне расходятся, хотя бы тем, что исходный текст uС++ представим как "элементы класса", а не как "файлы". Безусловно, в основе uС++ лежит С, надо только уточнить, что считать "основой".

Есть варианты и получше, из текстовых - Форт, например!

Язык Форт не предоставляет в плане проектирования ничего, что бы не давал С или Паскаль, он отличается только на стадии кодирования, причем отличается спорными преимуществами.

корней?
И есть сравнительный анализ искусственных языков?

Не поверите - есть, для 5-10 языков, информация о которых есть в сети.

Есть анализ, который завершился на предварительной стадии. Это как с комиссией, которая пришла проверять объект, а не нашла даже фундамента .

Языки всех типов рассматривались и на основе рассмотрения было решено, что:
- язык должен иметь "смысловые элементы" (корни), из которых по простым правилам с помощью "добавочных элементов" (аффиксы) строятся остальные слова;
- правила построения таковы, что не требуется толкования построенных слов, нужно только знать корни и правила;
- правил и вспомогательных элементов языка должно быть как можно меньше, но без потери выразительности и однозначности высказываний;
- нужно решить вопрос с обновлением словаря - введением новых слов;
- и т.д.

Есть форум, где я это писал подробнее, но вряд ли эти подробности нужны здесь, разве что кто-то будет заниматься языком, но тогда он спросит о конкретных проблемах, я отвечу .

Про УСК(Универсальный Семантический Код) Мартынова тоже читали?

Не припомню такого имени, но если этот Код не отвечает даже вышеозначенным требованиям, значит он не пригоден.

[in4]

Потому что это единственный известный мне "эффективный" способ построения и сопровождения больших программных систем.

Рекомендую прочитать Л.Броуди "Способ мышления - Форт". Очень занимательная книга. И вопрос эффективности построения и сопровождения программных систем тоже рассматривается.
Классика, хотя несколько устарела, как и язык С - предлагаемые подходы ориентированы больше на текстовое представление информации, хотя сейчас нужно работать с гипертекстом, деревьями и графикой.

Язык Форт не предоставляет в плане проектирования ничего, что бы не давал С или Паскаль, он отличается только на стадии кодирования, причем отличается спорными преимуществами.

Сокращение записи исходников уже огромное преимущество!
Кстати, как-то попалась статья, где показывалось, что производительность программиста на Лиспе превышает производительность программиста на С чуть ли не в разы при сопоставимом качестве кода. Наверняка приврали (подобрали подходящие примеры), но заставляет задуматься... Процедурно-ориентированные языки - не единственная возможность. Как и ОО подход.
ИМХО, будет время, когда программирование будет просто указанием на метод решения задачи и его ограничения. Компьютер сам сделает остальное. Но программист (или как это будет называться, скорее, инженер) должен быть значительно более высокой квалификации, хотя и не обязательно...

Про УСК(Универсальный Семантический Код) Мартынова тоже читали?

Не припомню такого имени, но если этот Код не отвечает даже вышеозначенным требованиям, значит он не пригоден.

Вроде отвечает. Но детальный анализ я для себя планирую сделать позже. А там, глядишь, еще что интересное появится. Правильных-то направлений не так и много...

[Полянин М.А.]

Сокращение записи исходников уже огромное преимущество!

Но не для проектирования.

Процедурно-ориентированные языки - не единственная возможность. Как и ОО подход.
ИМХО, будет время, когда программирование будет просто указанием на метод решения задачи и его ограничения.

Это время уже наступило, как раз ОО технология позволяет решать задачи декларативно. Язык С++ содержит только "некоторые элементы ОО технологии", но даже сейчас на нем доступны подобные тексты:

// "для имя" значит
// по умолчанию пространство имен "имя->"

пользователь вася;
еда финики;
система эксперт;

для эксперта
{
вася ищет финики;
хочет больше, дешевле, послаще,
сейчас вася в москве, подключен к интернету;
покажи на компьютере у васи, где их взять;
}

"Диалекты" (которые еще можно назвать "расширениями") в uC++ могут быть использованы, в частности, и для такой незначительной настройки синтаксиса под целевую задачу, хотя в общем они решают более общую проблему.

Правильных-то направлений не так и много...

Я попробовал сделать нужный язык, но с налету не получилось, это оказалось посложнее, чем язык программирования. Мне даже сейчас известно много неясных "переменных", которые влияют на вид языка (а сколько их еще появится в процессе разработки!), нельзя же их определять произвольно.

[in4]

Сокращение записи исходников уже огромное преимущество!

Но не для проектирования.

Именно для проектирования! Есть возможноть охватить бОльшую часть проекта одним взглядом (больше помещается на экран).

А конкретно приведенный код ^ может откомпилироваться под ВС5.5?

[Полянин М.А.]

Именно для проектирования! Есть возможноть охватить бОльшую часть проекта одним взглядом (больше помещается на экран).

Нет, объектно-ориентированное проектирование работает иначе.

А конкретно приведенный код ^ может откомпилироваться под ВС5.5?

Это типа юмор, хочется посмотреть на текст С++? Да пожалуйста, ничего, если я на английском? Кстати, BC5.5 не поддерживает еще и диалекты, это упущение, но не мое, придется их не использовать. Вариантов очень мнгого, но, например, так:

Код: Выделить всё

//
class Tuser;
class Tfood;
class Tsystem;

Tuser     bill("вася");
Tfood     apple("финики");
Tsystem expert("по жратве");

//для эксперта
void test()
{
expert.listen("вася ищет финики");
expert.about("хочет больше, дешевле, послаще");
expert.about("сейчас вася в москве, подключен к интернету");
expert.show("покажи на компьютере у васи, где их взять");
}

Ну как? Шикарно. Вы конечно скажете, что "не компилится", тогда я уж сразу облегчу вам жизнь, вставьте с "#include" в самый перед вот это:

Код: Выделить всё

class Tuser
{
public:
   Tuser(const char *const);
};

class Tfood
{
public:
   Tfood(const char *const);
};

class Tsystem
{
public:
    void
    listen(const char *const);
    void
    about(const char *const);

public:
    void
    show(const char *const);

public:
   Tsystem(const char *const);
};

Компилится!

[in4]

Это типа юмор, хочется посмотреть на текст С++?

Не юмор, а иллюстрация.

Да пожалуйста, ничего, если я на английском?

Даже лучше. Ближе к оригиналу.

Так вот о чем я говорил. Код

Код: Выделить всё

// "для имя" значит
// по умолчанию пространство имен "имя->"

пользователь вася;
еда финики;
система эксперт;

для эксперта
{
вася ищет финики;
хочет больше, дешевле, послаще,
сейчас вася в москве, подключен к интернету;
покажи на компьютере у васи, где их взять;
}

Это почти код на Форте. Ну, если убрать(!) некоторые лишние детали (";" в конце слов).
Конвертором (программой - транслятором с одного языка на другой) можно получить код и на С. Но уже видно, что в коде на С значительно больше "шумовых слов/символов", которые не несут смысловую нагрузку (она вся в приведенном выше фрагменте), а требуются для обеспечения работы транслятора.
Причем при отладке/доработке весь этот код надо просматривать, отслеживать части. А если использовать Форт, то количество шума не увеличится.

Зная язык С, я заинтересовался, неужели кто-то сделал препроцессор для преобразования нормального кода (ну или псевдокода - как удобнее назвать) в код на С. Поэтому и спросил. Но чуда не произошло...
Кстати, мне кажется, что русские ключевые слова тоже будет применить не так просто. Разве что прописать их через препроцессор.

А ООПроектирование делается специальными средствами? Они лицензионно чистые? Обеспечивают ли переход к коду (генерацию кода на С) и обратно к схеме (по программе восстанавливается схема и при этом сохраняются комментарии к коду)?

[Полянин М.А.]

Так вот о чем я говорил. Код

Код: Выделить всё

// "для имя" значит
// по умолчанию пространство имен "имя->"

пользователь вася;
еда финики;
система эксперт;

для эксперта
{
вася ищет финики;
хочет больше, дешевле, послаще,
сейчас вася в москве, подключен к интернету;
покажи на компьютере у васи, где их взять;
}

Это почти код на Форте. Ну, если убрать(!) некоторые лишние детали (";" в конце слов).

У меня есть книга по форту - вон она стоит на полке и на код форта этот текст свосем не похож.

Но в чем то вы правы. Этот код похож на другой язык, и этот язык называется Пролог. Это получилось потому, что Пролог самый декларативный язык из всех декларативный языков, которые я встречал. Если вы почитаете описание к Прологу, то найдете что-то вроде такого: "обеспечивают(ся) эффективные(ми) механизмы(ами) поиска, встроенные(ми) в язык".

Вот, вот - поиска. Это значит, что данный пример с васей и финиками плохо иллюстрирует преимущества ООП (даже те, которые реализованы в С++).

Это значит, что если вы выполните этот поиск сами, вместо Пролога, то получите некий конкретный набор объектов, для этого набора объектов которого преимущества такого ООП языка, как С++ уже будут неоспоримы, потому что сущности и отношения, которые есть в вашей задаче, прямо поддерживаются средствами ООП языка, даже такого как С++ и ваша программа становится как бы явной программной моделью вашего явления (без какого-либо шума).

Но явное построение программистом модели явления в общем снижает декларативность, про которую шла речь изначально.

Есть вот пример С++ кода, который хоть и содержит конкретные объекты и даже всю реализацию (т.е. компилится в исполнимый файл), но изначально был сделан все же для иллюстрации проблем динамической памяти в С++, попробуйте может его

Код: Выделить всё

     Tlandscape    &meadow= *new Tlandscape;

     meadow.has(*new Tgrass + *new Tpine(3)+ *new Tlake );

     enum{ grass=0, pines, lake};
     meadow[lake].has( *new Tfish(5) );

     Tperson    &worker=*new Tworker;

     worker.making(meadow.east, *new Tditch);
     const uint ditch=lake+1;


вот это полный текст, чтобы компилировать

Код: Выделить всё

#include <typeinfo>
#include <exception>
#include <memory>
#include <list>


//sorry, but
#include <stdio.h>


// ******************
// ******************
namespace Ntest{


using std::bad_cast;


//{
//using std::auto_ptr;
//using std::auto_ptr_ref;


//C++ still not support
#define heap
#define array //heap[]
#define _auto


#define ctor
#define dtor
#define after(x)
#define befor(x)
#define once
#define probe


#define memtype


// *****************
template<class Tobj>
class Tarray
{
public:
    //C++ still not support
    //typedef array memtype;


    Tobj array* ptr;


public:
    void            detach(){ ptr=0; }
    void            destroy(){ if(ptr)delete[] ptr; ptr=0; }


    void            replace(Tobj array* p)
     {
      if( p != ptr )
       {
        if(ptr)delete[] ptr;
        ptr=p;
       }
     }


    Tobj array*    move()
     {
      Tobj array *const tmp=ptr;
      ptr=0;
      return tmp;
     }


public:
    Tarray(Tobj array* p=0):ptr(p){}



};


// *****************
template<class Tobj>
class Tobject
{
public:
    //C++ still not support
    //typedef heap    memtype;

    Tobj heap*      ptr;


public:
    void            detach(){ ptr=0; }
    void            destroy(){ if(ptr)delete ptr; ptr=0; }


    void            replace(Tobj heap* p)
     {
      if( p != ptr )
       {
        if(ptr)delete ptr;
        ptr=p;
       }
     }


    Tobj heap*      move()
     {
      Tobj heap* const tmp=ptr;
      ptr=0;
      return tmp;
     }


public:
    Tobject(Tobj heap* p=0):ptr(p){}



};


// *****************
template<class Tobj>
class Tadr
{
public:
    //C++ still not support
    //typedef _auto   memtype;
    //typedef Tobj _auto* memtype;

    Tobj _auto*     ptr;


public:
    void            detach(){ ptr=0; }
    void            destroy(){ ptr=0; }
    void            replace(Tobj _auto* p){ ptr=p; }


    Tobj _auto*     move()
     {
      Tobj _auto* const tmp=ptr;
      ptr=0;
      return tmp;
     }


public:
    Tadr(Tobj _auto* p=0):ptr(p){}



};


//}

//{
// **********************************************
template<class Tobj, class Tmemory=Tobject<Tobj> >
class Tauto_ptr
{
    mutable Tmemory     memory;
    //typedef typename Tmemory::memtype   memtype;


    Tauto_ptr&  set_ptr(Tobj memtype* const new_adr)
     {
      memory.replace(new_adr);
      return *this;
     }


    void    created()
     {
      #ifdef MY_DBG
      printf("%p: createdn",this);
      #endif
     }


public:
    char            is_ptr_assigned()const probe { return memory.ptr? 1:0; }


    Tobj _auto*     get_ptr()const after(set_ptr||created) { return
static_cast<Tobj _auto*>(memory.ptr); }
    Tauto_ptr&      replace(Tobj memtype* const new_adr)ctor { return
set_ptr(new_adr); }
    Tobj memtype*   move()const dtor { return memory.move(); }
    void            detach()const dtor { memory.detach(); }


public:
    Tobj&           get_obj()const { if(!memory.ptr)throw bad_cast(); return
*get_ptr(); }


    Tobj&           operator* ()const { return get_obj(); }
    Tobj _auto*     operator-> ()const { return &get_obj(); }


    Tobj&           operator() ()const { return get_obj(); }
    Tobj _auto*     operator() (const int)const { return get_ptr(); }


    Tauto_ptr&      operator= (Tobj heap* const new_adr)ctor { return
replace(new_adr); }


public:
    Tauto_ptr(Tobj memtype* p=0):memory(p){created();}
    //move construction
    Tauto_ptr(const Tauto_ptr& obj):memory(obj.move()){created();}
    //move assignment
    Tauto_ptr& operator= (const Tauto_ptr& obj)ctor
     {
      if( &obj != this ){ replace(obj.move()); }
      return *this;
     }
    ~Tauto_ptr()
     {
      memory.destroy();
      #ifdef MY_DBG
      printf("%p: destroyedn",this);
      #endif
     }


};


//}

// ******************
// ******************
using std::list;


typedef unsigned int uint;


void  greetings(const char* const msg, void *const ptr, const char* const
what="created"){printf("%p: Hello, i am %s, just %s!n",ptr,msg,what);}
void  bye(void *const ptr){printf("%p: Bye.n",ptr);}


// ******************
// ******************
template<class T>
class Tseq
{
public:
    //typedef auto_ptr<T>             Tptr;
    //typedef auto_ptr_ref<T>         Tptr_ref;
    typedef Tauto_ptr<T>            Tptr;
    typedef Tptr                    Tptr_ref;


    typedef list<Tptr>                      list;
    typedef typename list::iterator         iterator;
    typedef typename list::const_iterator   const_iterator;


T&      operator[] (const uint)const;


T&      operator+  (T& obj)
     {
      assigned.push_back(Tptr_ref(&obj));
      return static_cast<T&>(*this);
     }


T&     has(T& obj)
     {
      tree.push_back(Tptr_ref(&obj));
      //tree.merge(obj.assigned);
      add_list(obj);
      return static_cast<T&>(*this);
     }


T&     remake(T& obj)
     {
      tree.clear();
      return has(obj);
     }


protected:
    Tseq(){}


protected:
    list    tree;
    list    assigned;


    void    add_list(T& obj);


private:
Tseq(const Tseq&);
Tseq& operator= (const Tseq&);



};


// ******************
class Tlandscape: public Tseq<Tlandscape>
{
public:
    Tlandscape&     east;

public:
Tlandscape():east(*this){ greetings("landscape",this); }
~Tlandscape(){bye(this);}


protected:
Tlandscape(const char *const msg, const char* const
what="created"):east(*this){ greetings(msg,this,what); }



};


// ******************
const char*     make_name(char *const msg);

// ******************
// ******************
class Tgrass: public Tlandscape
{
public:
    Tgrass():Tlandscape("grass"){}



};


// ******************
class Tditch: public Tlandscape
{
public:
    Tditch():Tlandscape("ditch 10x10"){}


};


// ******************
// ******************
class Tpine: public Tlandscape
{
public:
    Tpine():Tlandscape( make_name(msg) ){}

    explicit Tpine(const uint num): Tlandscape( make_name(msg) )
     {
      if(!num)throw bad_cast();
      if(num==1)return;


      for(uint i=num-1; i; --i){ has(*new Tpine);}
     }


protected:
    static char msg[15];



};


// ******************
class Tlake: public Tlandscape
{
public:
    Tlake():Tlandscape(make_name(msg)){}
    explicit Tlake(const uint num): Tlandscape( make_name(msg) )
     {
      if(!num)throw bad_cast();
      if(num==1)return;

      for(uint i=num-1; i; --i){ has(*new Tlake);}
     }


protected:
    static char msg[15];



};


// ******************
class Tfish: public Tlandscape
{
public:
    Tfish():Tlandscape(make_name(msg)){}
    explicit Tfish(const uint num): Tlandscape( make_name(msg) )
     {
      if(!num)throw bad_cast();
      if(num==1)return;

      for(uint i=num-1; i; --i){ has(*new Tfish);}
     }


protected:
    static char msg[15];



};


// ******************
// ******************
class Tperson
{
public:
    virtual void   making(Tlandscape& dst, Tlandscape& src)=0;
virtual ~Tperson(){bye(this);}

protected:
//Tperson(){ greetings("person",this); }
Tperson(const char *const msg, const char* const what="come in"){
greetings(msg,this,what); }


private:
Tperson(const Tperson&);
Tperson& operator= (const Tperson&);



};


// ******************
class Tworker: public Tperson
{
public:
    virtual void   making(Tlandscape& dst, Tlandscape& src){ dst.has(src); }

public:
Tworker():Tperson("worker"){}



};


// ******************
// ******************
//namespace Ntest


}


// ******************
// ******************
using namespace Ntest;

char Tpine::msg[15]="pine #000";
char Tlake::msg[15]="lake #000";
char Tfish::msg[15]="fish #000";


// ******************
const char* Ntest::make_name(char *const msg)
{
    if(!msg)throw bad_cast();


enum{ num_chars=3 };
const uint len=strlen(msg);  if(len<num_chars)throw bad_cast();
char *const p=msg+len-num_chars;


    ++p[num_chars-1];
    for(uint i=1; i<num_chars; ++i)
     {
      if( p[num_chars-i]>0x39 ){ p[num_chars-i]=0x30; ++p[num_chars-i-1]; };
     }
    if( p[0]>0x39 )p[0]=0x30;


    return msg;



}


// ******************
template<class T>
T&     Tseq<T>::operator[] (const uint idx)const
{
    if( tree.empty() )throw bad_cast();

const_iterator    it=tree.begin();
const_iterator    end=tree.end();


    for(uint i=idx; i; --i)
     {
      ++it;
      if(it==end)throw bad_cast();
     }
    return **it;



}


// ******************
//tree.merge(obj.assigned);
template<class T>
void    Tseq<T>::add_list(T& obj)
{
iterator    it=obj.assigned.begin();
iterator    end=obj.assigned.end();

    while(it!=end)
     {
      //tree.push_back( Tptr_ref( it->release() ) );
      tree.push_back( Tptr_ref( *it ) );
      ++it;
     }
    obj.assigned.clear();



}


// ******************
// ******************
int     main()
{
try{

    //original example start
     Tlandscape    &meadow= *new Tlandscape;

     meadow.has(*new Tgrass + *new Tpine(3)+ *new Tlake );
     enum{ grass=0, pines, lake};
     //100 is too much to place messages on screen, take a 5
     //meadow[lake].has( *new Tfish(100) );
     meadow[lake].has( *new Tfish(5) );

     Tperson    &worker=*new Tworker;

     worker.making(meadow.east, *new Tditch);
     const uint ditch=lake+1;

    //original example end
     delete &worker;
     delete &meadow;
}

catch(bad_cast&){fprintf(stderr,"error: %s","bad_cast");}
catch(...){fprintf(stderr,"error: %s","unknown");}
}



Опять же, многие проблемы относятся к С++ , а не к ООП.

А ООПроектирование делается специальными средствами? Они лицензионно чистые?

Честно - не могу по вашим вопросам уловить вашу идею, т.к. ваша терминология не общепринята для ООП и говорит скорее о том, что вы не рассматриваете вопрос ООП проектирования (я конечно могу ошибаться).

Это все потому, что для проектирования важны не сколько средства (которые конечно нужны), сколько сами вопросы, которые решаются при проектировании, и ряд ваших проблем, например, "видимость всего кода" как бы не входит в этот перечень вопросов, по крайней мере если рассматривать проблему "видимости кода" так, как это общепринято.

Или я не пойму про что вы говорите.

[in4]

Честно - не могу по вашим вопросам уловить вашу идею, т.к. ваша терминология не общепринята для ООП и говорит скорее о том, что вы не рассматриваете вопрос ООП проектирования (я конечно могу ошибаться).

Наверное, отличается. Я не много общался с адептами ООП...
И, действительно, не рассматриваю ООПроектирование, т.к. IMHO оно позволяет решать некоторые частные задачи, пока сложность не превысит некоторые пределы. И оно IMHO не очень хорошо масштабируется.
Кроме того, средства, которые переводят ООП-модель в исполняемый код (и данные) слишком громоздки и неудобны в работе. Языки С и С++ - это примеры таких средств.

Это все потому, что для проектирования важны не сколько средства (которые конечно нужны), сколько сами вопросы, которые решаются при проектировании, и ряд ваших проблем, например, "видимость всего кода" как бы не входит в этот перечень вопросов, по крайней мере если рассматривать проблему "видимости кода" так, как это общепринято.

Я работаю над созданием лучшего представления что кода, что данных. И, пожалуй, даже смог бы выдать что-то типа ТЗ на разработку, по крайней мере, поползновения были.
А основные идеи просты - как сделать представление кода+данных как можно проще/удобнее с сохранением максимального количества функций.
Для текстового представления кода IMHO лучше всего подходит как раз Форт - тексты высокого уровня на нем почти не содержат избыточности - символов, которые не несут дополнительной качественно новой информации.
Для данных - лучше какие-то таблицы или деревья. Кстати, код тоже может быть представлен в этом виде!
Но это требует специальных программ-редакторов.

Или я не пойму про что вы говорите.

Похоже, я таки не могу правильно выразить свою мысль.
Хотел сказать, что выбор ООП и С/С++ не очень удачный для переспективных разработок.
Сделать-то, конечно, можно. Но потом будут проблемы. Или серьезные проблемы...
Лучше IMHO использовать другие средства (не все из них пока реализованы ), о которых я и пытаюсь рассказать.