Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "KOL";
Текущий архив: 2010.08.27;
Скачать: [xml.tar.bz2];

Вниз

SOL (Соль) = Simple Objects Language   Найти похожие ветки 

 
Vladimir Kladov ©   (2007-12-15 22:08) [0]

http://kolmck.net/sf/SOL=IdealSpade4Programmer.rar

Ну хорошо, пусть будет отдельная ветка.
Сразу ответ D[u]fa на
зачем каждый раз писать do, почему б нельзя объявить массив как arr[... , ..., ...]


Мы же пишем begin, и нормально. Анализ текста значительно упрощается. Дело даже не в компиляторе. Человеку тоже проще, если есть открывающая скобка блока. Есть ведь и эквиваленты, кому само слово DO не нравится (и END).

Массив не надо так объявлять. Я долго думал, почему. Например, во избежание непонимания того, что если есть объявление [3,3,3], то можно обратиться как [i,j] и получить элемент-масив из 3 элементов. Если можно объявлять только [3][3][3], согласитесь, такой проблемы вообще нет. В конце концов, ][ ничем не хуже , ,но видно этот "символ" лучше.

Спрашивайте ещё. Я пока пытаюсь "победить" многозадачность (точнее многонитевость). Изучил адовские рандеву, мониторы модулы-2, активные объекты эктив-оберона - ничего мне не нравится пока. И вообще. Механизм защиты CATCH, который я предложил как черновой, мне самому трашно не нравится. В общем, голову ещё есть над чем поломать.


 
Elec3C ©   (2007-12-16 02:24) [1]

Хм!? Я так понял новый язык что-ли?


 
Vladimir Kladov ©   (2007-12-16 08:06) [2]

Правильно поняли. Раз уж началась разработка ЯП 5-го поколения, то хотелось бы напоследок получить идеальный ЯП 4-го. Но я так понял, что для меня лично никто стараться не собирается. Решил сам попробовать.


 
Dodfr   (2007-12-16 22:23) [3]

may be it"s very nice ... if ever I could understand the docs, russian is not the most spoken language in the world and language translators do very bad working on technical words, why not write it directly in english ? ;-)


 
homm ©   (2007-12-16 22:47) [4]

> [3] Dodfr   (16.12.07 22:23)
> russian is not the most spoken language in the world and
> language translators do very bad working on technical words,
> why not write it directly in english ? ;-)

Это все равно что человеку, которому нужна медицинская помошь, предложить сходить в туалет по той лиш простой причине, что в туалет ходят чаще, чем к врачу :-/


 
Dodfr   (2007-12-16 23:05) [5]

Well..I suppose homm is doing some joke as this is how google translated its words :

"It is still that someone needed medical Assistance, suggest go to the toilet on the requester simple reason that go to the toilet more often than to a doctor"

But whenever this this "joke" is not translated correctly, may be I could answer Homm in French and say (you"ll see how fun it is to translate such words) :

"Puisque l"on parles de chiottes, tu pourrais te mettre dessus et devenir le roi des emmerdeurs".


 
homm ©   (2007-12-16 23:25) [6]

> [5] Dodfr   (16.12.07 23:05)
> But whenever this this "joke" is not translated correctly

I also know english worst, but at first look it is right. :)


> be I could answer homm in French and say

I dont feel any reasons to try to rtanslate this phrase.

I only try to say what Vladimir write on language, which more comfortable for him, and reasons such as «most spoken language» at least funny.


 
Dodfr   (2007-12-16 23:46) [7]

Whenever I am french and I do all my programs and docs (and web sites) in english because I know that French is not a common language, it"s a bit more work but more easy for everybody to access my jobs.


 
Robt ©   (2007-12-17 12:54) [8]

Тоесть про добавления и исправления в КОЛ
можно забыть раз появилась новая забава ?

Лучшеб с P-кодом до конца разобрались
чтоб у всех работало без ручных манипуляций...


 
misha_shar ©   (2007-12-17 15:44) [9]

Есть много языков программирования разных поколений. Но в 70 годы
был разработан язык MUMPS который в Амереке сразу же был и стандартизован. Я считаю что это самый лучший язык до сих пор. Приложения на нем писать можно в 100 раз быстрее чем на любом другом языке. При этом он еще и самый простой из всех. Ничего лишнего.


 
Vladimir Kladov ©   (2007-12-17 15:56) [10]

I am trying to compile... sorry, to translate to English smaller (2nd) specification now. (Even this work is taking too many time to do it and still the "thinking" stage is not finished it is delayed a bit). But what concerning about the (1st) large story... I"m sorry. It seems very large to do this work and may be better to take time to create first compiler / source editor for it instead.

Вот P-код - это и впрямь забава. Я просто исхожу из потребностей которые обнаружил при написани достаточно большого софта. Мне нужна надёжность, которую мог бы дать только какой-нибудь ядрёный язык типа Оберона или Ады, но заморочки этих языков меня не устривают. Малый размер - тоже нужен, но это не проблемы языка, а компилятора (и для обоих этих языков с удалением мёртвого кода есть проблемы). А если уже говорить о надёжности, то я сюда вкладываю очень много. Прога не должна зацикливаться, потоки не должны портить друг другу данные и влезать в dead-lock (а если влезли то должен быть способ распутать). Объекты должны сами себя убивать, а куча должна быть дефрагментирующаяся, чтобы прога могла работать практически вечно без перезапуска из-за сильной фрагментированности кучи. Но сборщик мусора мне не нужен, в его классическом варианте. Желательно максимум проверок отнести на этапы компиляции. Нужно средство тестирования, которое автоматически проведёт все нужные тесты после изменений (а не только те, про которые автор то бишь я в частном случае соизволил вспомнить после серии исправлений). Нужна параноидальность языка, избавляющая от параноидальности (или наоборотнедальновидности) программера, в общем. И при этом чтобы просто и без особых заморочек. Да, и ещё, всё это должно продолжать надёжно работать в условиях использования сторонних либ, написанных на довольно ненадёжном но увы распространённом С. Вы где-нибудь такой язык встречали? Вот и я не встречал.

Кажется, у меня получилось придумать и с многопоточностью что делать. Немного не так, как думал сначала (я про CATCH-переменные, если кто читал большой текст). Но что-то около того. Главное - нужна полная изоляция данных между потоками, контролируемая синтаксически. Кроме тех точек, где нужен контакт. Переменная может принадлежать только одному потоку в каждый отдельный момент времени. Для глобала - захват в исключительное использование блоком DO TRY, для прочих - передачей в теле сообщения. Завтра надеюсь закончить, и выложу тогда уже. Кстати, никто не знает, можно ли в винде загрузить одну и ту же dll в 2 разных участках памяти (или по крайней мере, чтобы её глобальные переменные для 2х экземпляров оказались в общем адресном постранстве в разных местах?) Что-то до сих ничего такого не встречал я. А надо (кажется).


 
heilong   (2007-12-17 17:08) [11]

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


 
heilong   (2007-12-17 17:09) [12]

Но только если полные пути совпадают.


 
Barloggg   (2007-12-17 17:50) [13]

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


 
Sapersky   (2007-12-17 19:20) [14]

Если требуется действительно ветвление на этапе компиляции, то при наличии хорошего компилятора, вполне должно быть достаточно обычного оператора "DO IF" с анализом в условии значений констант и константных выражений: качественный компилятор не должен генерировать код для ветвей, условие на которых вообще никогда не выполняется.

Delphi так и делает, если константы нетипизированные.


 
Vladimir Kladov ©   (2007-12-17 21:40) [15]

Delphi так и делает, если константы нетипизированные.
Если бы этого было достаточно, мы бы не использовали {$IFDEF}. И в любом случае, слишком жёсткое ограничение. Типизированные константы - конёк Паскаля. И вообще-то, должно быть так, что константа - она и есть константа, типизированная она или не типизорованная. А в Delphi получается, что типизированная константа - это вовсе и не константа даже. А просто проинициализированная переменная. А, например, вот так:
const S = "ABCDEF";
procedure TForm1.Button1Click(Sender: PObj);
var S1: String;
begin
 if S = "Ятакидумал" then
 begin
   ShowMessage( "Привет0" );
 end;
 S1 := "Ятакидумал";
 if S = S1 then
 begin
   ShowMessage( "Привет1" );
 end;
end;

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

А что, если это выражение, вызывающее функции? Я описываю класс функций, которые компилятор обязан уметь посчитать на этапе компиляции. Остальные - в силу интеллекта, а эти - обязан.

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


 
D[u]fa   (2007-12-17 22:12) [16]

да ифдефы достанут кого угодно... но вот что б компилятор был нам обязан искать такое... лично для меня фантастика =)


 
misha_shar ©   (2007-12-18 07:39) [17]

-------------------------------------
А если уже говорить о надёжности, то я сюда вкладываю очень много. Прога не должна зацикливаться, потоки не должны портить друг другу данные и влезать в dead-lock (а если влезли то должен быть способ распутать). Объекты должны сами себя убивать, а куча должна быть дефрагментирующаяся, чтобы прога могла работать практически вечно без перезапуска из-за сильной фрагментированности кучи. Но сборщик мусора мне не нужен, в его классическом варианте. Желательно максимум проверок отнести на этапы компиляции. Нужно средство тестирования, которое автоматически проведёт все нужные тесты после изменений (а не только те, про которые автор то бишь я в частном случае соизволил вспомнить после серии исправлений). Нужна параноидальность языка, избавляющая от параноидальности (или наоборотнедальновидности) программера, в общем. И при этом чтобы просто и без особых заморочек. Да, и ещё, всё это должно продолжать надёжно работать в условиях использования сторонних либ, написанных на довольно ненадёжном но увы распространённом С. Вы где-нибудь такой язык встречали? Вот и я не встречал.
--------------------------
А я встречал. И это уже давно работает. Все эти идеи давно реализованы
еще 70г. И сейчас существует и живет язык в котором это реализовано.
Велосипед изобретать можно но там это сделано лучше. Язык называется
MUMPS. Система в которой он реализован Cache даже продается книга
по этой системе на русском языке. В Москве есть представительство InterSystem. И на нем работают люди уже много лет Нет проблем с переменными в этом языке никаках. Все данные реализованы в виде дерева либо в памяти либо на диске. О возней с переменными в этом языке заниматься не приходится вообще. Надо записал в любую переменную надо прочитал из любой если там нет данных то возвращается пустая строка где надо удалил переменные. По завершению задачи все локальные переменные удаляются. Потоков тоже нет. Но есть многозадачность с поморщью команды JOB запускается подпрограмма. Все переменные всегда изолированы. Обмен осуществляется стандартными средствами. Блокировка переменных в языке команда LOCK. Это самый компактный и самый мощный язык.


 
Sapersky   (2007-12-18 16:20) [18]

А в Delphi получается, что типизированная константа - это вовсе и не константа даже

Ну да, при определённых настройках компилятора им можно присваивать значения.

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

Вы слишком многого хотите от компилятора, это же не C++ с его многопроходным монстром. И для эмуляции IFDEF вполне достаточно первого случая, хотя удобнее, конечно, не строки, а Boolean.


 
Vladimir Kladov ©   (2007-12-18 17:09) [19]

Basically, Mumps has only one data type: string, although it does allow integer and floating point computations as well as logical expressions. Мне кажется, дальше читать уже не надо. Меня скритовые языки не интересуют.


 
Vladimir Kladov ©   (2007-12-18 17:14) [20]

А в Delphi получается, что типизированная константа - это вовсе и не константа даже

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


 
Vladimir Kladov ©   (2007-12-18 20:50) [21]

S1 := "Ятакидумал";
if S = S1 then

Вот в этом примере всё очень однопроходно. Я к Delphi  C/C++ отношусь именно как к навороченному макроассемблеру. Я от него уже не хочу ничего, спасибо за то, что уже есть. Но стало маловато.


 
misha_shar ©   (2007-12-19 11:56) [22]

А зря там много интересного.
MUMPS исторически был создан как язык интерпритатор. И в таком
виде существует до сих пор. Это связано с тем что некоторые конструкции
языка не поддаются компиляции в принципе. Таких конструкций 2.
Это косвенный синтаксис и команда XECUTE. В остальном все остальное
прекрасно компилируется. Последняя реализация языка это CACHE фирмы
InterSystem. В этой реализации применяется компиляция промежуточного
P-кода. Называть этот язык скриптовым у меня язык не поворачивается.
Это мощный развитый компактный язык программирования. Который на много
превосходит и С и Pasсal.  На этом языке построена бала операционная система
DSM-11. И язык выполнял все функции как языка так и операционной системы.
Это язык будущего. И вот почему.  В язык встроена
иерархическая база данных и она является неотемлемой частью этого языка.
База построена как B-дерево. (Кнут.3-том). Такое дерево строится на диске
и в оперативной памяти. Все переменные являются  деревьями на
B-дереве в памяти. При старте Cache оно создается при стопе все уничтожается.
Управление переменными осуществляет B-деревом в памяти. В любой момент
любая переменная создается и в любой момент удаляется. Никаких сборщиков
мусора и других обслуживающих программ не надо. Библиотека встроенных
функций состоит из 12 штук. Так возможностей у ней больше чем у библиотеке
в  Pasсal. Там кстати давно есть и функция аналогичная Parse. Но возможностей
у нее больше. Так как она может применяться как в правой так и в левой части.
И вырезать может любое поле. Изобретать свой язык не познакомившись
с MUMPSom это по моему идти в неверном направлении по давно
пройденному пути. Не нравится язык. Посмотри какие команды реализованы.
Как сделано управление переменными. Какая библиотека встроенных функций.
Я лично считаю что в MUMPSе самая развитая система управления данными.
Не имеющая аналогов в других языках. Команды NEW,KILL,ZKILL,SET,MERGE.
Есть книга по CACHE - Вольфганг Кирстен и др. Постреляционная
СУБД Cache 5 Об"ектно-ориентированая разработка приложений. Перевод с
английского.


 
Vladimir Kladov ©   (2007-12-19 15:35) [23]

дело не в том что он интерпретатор компилятор тоже есть. Ну и что? В MUMPS нет нормальных структурных типов данных, модулей (файлы - это ещё не модули), указателей, ОО, шаблонов, ... . Я посмотрел примеры кода. Бэйсик это. Модерн, но Бэйсик. Или у вас есть сведения, что он может использоваться для эффективных вычислений?


 
misha_shar ©   (2007-12-19 17:16) [24]

Об"ект по вашему это не структура? Типов данных там действительно нет
в базовом языке хотя в объектах эта галиматья вся есть.  Дерево само
является структурой причем любой и динамически изменяемой. Когда я
разрабатываю приложение я проектирую дерево а затем навешиваю
программы обработки. Какого типа переменная неважно. Важно чтобы
там были данные и их можно было обработать. Хотел бы я знать какие
вычисления на MAMPSe нельзя сделать? Указатели в языке есть и они
реализованы косвенным синтаксисом и передачей параметров по имени.
Где вы там обнаружили файлы для меня загадка.


 
Vladimir Kladov ©   (2007-12-19 19:21) [25]

У вас есть бенчмарки, доказывающие, что код мампса ничем не хуже по скорости кода С# хотя бы (считая что С# вдвое уступает С++)? Да читал я описание. Есть проекты размером больше 100 000 строк? Никаких дедлоков нет, исключения обрабатываются, один ажур спложной? Вы сами положа руку на сердце доверите программе на мампсе управление атомной электростанцией? (Я даже и Аде не доверяю, посл более близкого знакомства. Хм, софт для ракеты Ариан-5 был на Аде, а взорвалась она все-таки, в основном не столько из-за софта, правда, но в конечном счёте из-за него, родного). Вот не могу я поверить, что ЯП моей мечты давно существует, но все почему-то пользуются чем угодно, только не им. О Мампсе от вас первый раз услышал. Так не бывает. Если язык так хорош, как вы говорите, все уже давно выкинули бы на помойку и С/C++ и все #-языки, и Паскаль/Модулу/Оберон, и писали бы себе на мампсе. И не придумывал бы D, Java и прочая с ними.


 
D[u]fa   (2007-12-19 19:37) [26]

misha_shar, назовите крупный проект созданный на нем, просто язык с 60 годов... а слышу первый раз от вас здесь =)


 
AndreyRus ©   (2007-12-20 00:20) [27]


CACHE

O subj я ранее читал достаточно много, концепция мне очень понравилась, хотя в живую я с ним не встречался. Проблема его нераспространенности, равно как и SOL в том, что я писал ранее...


 
misha_shar ©   (2007-12-20 07:25) [28]

Я с 70г работаю на MUMPSe и только ему я бы даверил общее
управление всей электростанцией. Более надежной и простой системы
в мире не существует. Объем кода на MUMPSe может быть в зависимости
от задачи меньше на порядок. И его намного легче сопровождать.
А вот обработку прерываний от атомного блока я бы вынужден написать на
С в QNX системе. Потому что нет реализации MUMPSa в реальном времени.
Эта система разделения времени. Она очень надежна и хорошо обслуживает
много пользователей. Но это проблемы конкретной реализации а не языка.
Теперь более подробно о конструкциях языка. И язык С и PASKAL это
типизированые языки а MUMPS нетипизированый язык.
И подходить к ни с одними и теми же мерками нельзя.
Это 2 разных мира. Объект это модель и она должна существовать
прежде всего в голове. И на разных языках описание оъекта будет
выглядеть по разному. И бессмыслено в нетипизированом языке искать
описание объекта. Его описания там нет. Но это не значит что нет
объектов. Они есть. В MUMPSe объект это дерево. Любой объект должен
обладать 3 мя свойствами.
1,Локализовать переменые внутри объекта.
2.Обеспечить наследование.
3.обеспечить полиморфизм.
Всеми этими свойствами деревянная структура обладает от рождения и
никаких дополнительных ухищрений не требует. Правда в дереве нет
методов. Но это не проблема. Каждому дереву можно по имени сопоставить
модуль с программами обработки. Хотя в MUMPSe я никогда этого не
делаю за ненадобностью. Программы обработки я пишу всегда для
выполнения определенных функций над любым деревом.
Теперь по поводу программ. В MUMPSe я работаю всегда в определенной
области. Каждая область локализует данные и программы. В каждой
области они свои за исключением общей библиотеки. То что в Pascale
называется модулем (Unit) в MUMPSe называется программой. Хотя
точнее было бы назвать это блоком кода. То что в Pascale программы
и фунцкции здесь точки входа. В принципе в блок можно войти с
любой строки кода. Один и тотже программный блок может
использоваться поразному и как программа и как функция и как
продолжение программы(если точка входа не имеет передаваемых параметров).
Все зависит каким образом вы к этому блоку обратились.
Если по команде DO то это программа, если внутри команды SET то это
функция, если по команде GO то это продолжение вашей программы.
Все зависит от конкретной потребности.
Теперь о том что вы первый раз о нем слышите. Вообще то
незнание это не аргумент. И если все (в том числе я) работают
на Windows это не значит что это хорошая операционная система.
Более того это плохая ОС. Этот язык распространен в США где и
был разработан, в Англии, Австралии, Бразилии и других странах СНГ.
В Союзе существовало общество MUMPS которое возможно существует
и до сих пор.Это собщество сегодня вращается вокруг представительств
InterSystem в Москве и Хабаровске. На MUMPSe активно работали
в Москве, Ленинграде,Воронеже,Новосибирске,Томске,Хабаровске
,Владивостоке. Издаются книги. Не распостранен язык из за
безобразного менеджемента. Но к достоинствам языка это не
имеет никакого отношения. Язык конечно имеет недостатки но они
все устранимы при правильном подходе. Где используется MUMPS.
Все военные госпитали США по всему миру работают на этой системе.
Хотя реализованных проектов на нем очень много. Я сам разрабатываю
систему бухгалтерского учета с 80годов. Сейчас уже 5 версий этого
комплекса у нас функционирует.У меня серверная часть
написана на MUMPSe. Есть заказчики которых мы необслуживаем
уже много лет а они до сих пор работают на этой системе и она
надежно функционирует.


 
heilong   (2007-12-20 09:09) [29]

А лично мне нравиться идея написания компилятора для SOL, только вот на сколько производительным будет сгенерированный код? мне кажется это еще вопрос открытый.


 
D[u]fa   (2007-12-20 10:34) [30]

т.е ни одного проекта вы не назвали.. конкретного проекта...

вобщем не стоит тему про SOL превращать в тему про MUMPS.


 
homm ©   (2007-12-20 10:47) [31]

> [28] misha_shar ©   (20.12.07 07:25)

Очень охото посмотреть на тесты производительности по сравнению с любым известным Вам языком.


 
misha_shar ©   (2007-12-20 11:37) [32]

Насчет ссылок. Чтобы понять почему их нет. Надо немного разобраться
с системой управления данными в языке. Данные управляются с помощью
B-дерева. B-дерево это структура блоков в памяти или на диске. И к
логической структуре хранимых данных никакого отношения не имеет.
В это дерево можно записывать любые данные индексированые или нет
и вообще любые. B-дерево не вникает в содержимое данных. С увеличением
данных оно растет сбалансировано и все. Единственное требование
они должны быть поименованы и эти имена должны быть уникальны.
Дерево хранит даные выдает их по требованию и если их нет то
возвращает пустую строку или удаляет их по требованию. Причем
данные могут находится в различных местах и это место можем в
любой момент измениться. Поэтому адресная ссылка на данные бессмыслена.
Данные в дереве хранятся только те значение которым присвоено.
Пустые значения не хранятся.
Обработка ошибок. Обработка ошибок в MUMPSе в зачаточном состоянии.
Острой необходимости в ней нет. Во время исполнения встречаются
как правило только 2 ошибки. 1-<UNDEF> неопределенная переменная
эта ошибка может быть подавлена в параметрах языка. И <DIV> деление
на 0. Эта ошибка подавлена быть не может ее надо обрабатывать
с помощью обработчика ошибок. Обработчик сделан просто и со вкусом.
В системную переменную пишешь точку входа в обработчик ошибок и все.
При возникновении ошибки управление передается в эту точку. Писать
блоку try finale не в стиле MUMPSa так как программа может перейти
на любую строку а блоки это плохо переносят.
Насчет бытродействия. С и MUMPS языки с различными возможностями.
В С нет встроенной базы данных. А с любой другой С будет на порядки
медленней MUMPS. В рекламных материалах InterSystem приводится
сравнение MUMPS с Ораклом. Так они считают что на больших данных
Оракл в 200 раз медленнее. Но реклама есть реклама. Из моего опыта.
Как только появились персоналки у меня небыло реализации MUMPSa и я
написал бухгалтерию в Delphi в качестве базы использовав InterBase.
Быстодействие меня не устроило и я с помощью обработок на сервере
попытался его улучшить. Мне это удалось в 2 раза. Потом в Москве
Фетисов написал реализацию MUMPS. И я на ней переписал бухгалтерию.
Так вот без всяких оптимизаций мое приложение на одних и тех же
данных работало в 20 раз быстрее. С ростом объемов данных разница
в быстродействии еще увеличивается.


 
AndreyRus ©   (2007-12-20 11:40) [33]


> С ростом объемов данных разницав быстродействии еще увеличивается.

:)


 
Barloggg   (2007-12-20 12:01) [34]

ну MUMPS выглядит неплохо. интересно за ним надо таскать кучу библиотек?
лично я посмотрю на него поглубже.

сейчас делаю программу натурально на заказ. и все переменные храню как строки :)

что-то я не верю что мумпс быстрее при базовом типе "строка". это же бесконечные преобразования.
В-дерево дает обалденную скорость поиска и структуризации, но больше преимуществ я что-то не вижу.


 
homm ©   (2007-12-20 12:14) [35]

> [34] Barloggg   (20.12.07 12:01)
> В-дерево дает обалденную скорость поиска

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


 
Vedun   (2007-12-20 13:45) [36]

Есть предложение: для обсуждения MUMPSa создать отдельную ветку. А в этой обсуждать SOL.
В принципе соль - это типизированый язык. И сравнивать его с нетипизированым МУМПСом не совсем корректно.
Как и с паскалем и С.
По поводу эффективности. Мне кажется, при правильном и аккуратном написании кожа его эффективность в готовом виде зависит только от компилятора (и его автора).


 
Jon ©   (2007-12-20 14:31) [37]


> А в этой обсуждать SOL.


I agree. Any documentation in English yet?


 
misha_shar ©   (2007-12-20 15:47) [38]

Вообще то речь идет о новом языке а не о MUMPSe. MUMPS слава богу
есть и будет независимо от того знаете вы о нем или нет. Я предлагаю взять
для SOL за основу MUMPS доработав его спецификации. Кстати я хотел бы
увидеть описание SOL и требования к нему чтобы понять о чем идет речь.
Я извиняюсь влез в дискусию вконце и совершенно случайно. И может не
понял о чем речь. Прошу меня извинить.


 
homm ©   (2007-12-20 15:48) [39]

> [38] misha_shar ©   (20.12.07 15:47)
> Кстати я хотел бы
> увидеть описание SOL и требования к нему

см. [0].


 
misha_shar ©   (2007-12-20 16:00) [40]

см. [0].
Чтобы это значило?



Страницы: 1 2 3 4 вся ветка

Форум: "KOL";
Текущий архив: 2010.08.27;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.61 MB
Время: 0.066 c
3-1238361532
TheEd
2009-03-30 01:18
2010.08.27
как "вытянуть" описаниея полей в DisplayLabel


15-1270451902
brother
2010-04-05 11:18
2010.08.27
FAT32


15-1269263611
ocean
2010-03-22 16:13
2010.08.27
Логи ISA 2006


3-1243786232
Serjio77
2009-05-31 20:10
2010.08.27
Ошибка отображения данных в результате sql запроса в BDE


15-1269692542
Kerk
2010-03-27 15:22
2010.08.27
Задачка





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский