Язык программирования GOODWELL

← →
Kladov (2003-02-22 14:42) [0]

Потихоньку готовлю к публикации предварительную спецификацию разрабатываемого мною языка. Собственно, спецификация уже готова. Просто перевожу на английский. Все, кто желают ознакомиться, я сейчас выложу русскую версию спецификации здесь: http://bonanzas.rinet.ru/goodwell/GOODWELL-spec-RU.htm

Предвосхищая вопрос При чем тут KOL - редактор будет делаться на KOL/MCK, компилятор поначалу тоже. Ну и автор тот же. И сторонников я надеюсь набирать из тех же людей, что занимаются улучшением KOL. И сайт будет тот же - нет возможности еще и сайт отдельный создавать :)

← →
SPeller © (2003-02-22 16:23) [1]

Ещё пока не читал, но по вступлению понял что весчь довольно интересная. Владимир, я честно говоря завидую вашему трудолюбию и целеустремлённости: XCL, KOL, теперь ещё и язык свой. Один КОЛ каких трудов стоит.
Прочитав совсем чу-чуть меня этот язык заинтересовал. Будет время и возможность - обязательно займусь изучением.
И вот ещё замечание по поводу спецификации: глаза устают читать такое большое количество текста на чёрном фоне. На мой взгляд было бы лучше сделать фон как здесь - светлосерым.

← →
Kladov (2003-02-22 19:18) [2]

Ну насчет фона это уже как мне чтобы меньше глаза уставали - писать все это. Можно ведь загрузить себе и перед чтением исправить параметры страницы, если вам так удобнее. А еще, в Опере есть возможность включить свои цветовые настройки, причем в каждой закладке отдельно.

О моей трудоспособности, это... спасибо. Был помоложе, был еще трудоспособней.

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

← →
Forest (2003-02-22 22:04) [3]

Флаг Вам в руки, свой язык (а тем более такой) - очень полезная и нужная вещь. Но вот тольк всегда мечтал о русском языке программирования, где можно было бы на писать:

переменные
ф : число;
в: строка;

поехали
...
...

конец;

конец.

← →
Kladov (2003-02-23 07:02) [4]

если внимательно прочитаете, то увидите, что там это есть. Причем, то, что написано китайцем по-китайски, сможет читать русский по-русски или по-английски. Надо внести во вступление.

← →
SPeller © (2003-02-23 08:04) [5]

Из наименований мне больше нравится DESCENT, или просто WELL. Выговаривается проще.

← →
Forest (2003-02-23 15:07) [6]

Честно, хочу помочь в осуществлении проекта данного (если помощь требуется).

← →
Kladov (2003-02-23 17:58) [7]

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

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

← →
Kladov (2003-02-24 15:16) [8]

По названию. Проверил синтаксис текста (в английском варианте). Упорно предлагает GOODWILL вместо GOODWELL. Оно и так можно. Indented вместо Embedded :) Только мне больше нравится: Хороший Источник. Хотя и РВЕНИЕ тоже неплохо :) Опять же, первый вариант допускает сокращение до WELL.
Это я к тому, что за последние двое суток уже поступило 3 предложения по наименованию. Но я склонен остановиться на одном из GOODELL, WELL или GOODWILL.

Добавил про INLINE (как в C). Только можно еще и при вызове функции. Мне в Delphi самому иногда хоть режь нужен inline. А нету. И про параметр типа NAME. В коде пишем дентификатор, в самой функции или операторе считаем параметр строкой. Это чтобы допустить естественный вызов com-объектов. В Delphi это можно. Хотя и выглядит слегка кощунственно. Потому что скорее исключение, чем правило.

← →
Ketmar © (2003-02-24 16:27) [9]

мнэ... почитал спеки. мне уже страшно. в дрожь бросает. дикая помесь бейсика, паскаля, фортрана и еще непонятно чего...
искренне надеюсь, что проект тихо умрёт... потому что писать на ЭТОМ... лучше утопиться.

Satanas Nobiscum! 24-Feb-XXXVIII A.S.

← →
miek (2003-02-24 17:03) [10]

Владимир, а может, все гораздо проще? Есть ведь компилятор Странник, он вроде open-source. Переписать немного и все.

← →
SPeller © (2003-02-24 18:01) [11]

> Ketmar © (24.02.03 16:27)
> мнэ... почитал спеки. мне уже страшно. в дрожь бросает.
> дикая помесь бейсика, паскаля, фортрана и еще непонятно
> чего...
> искренне надеюсь, что проект тихо умрёт... потому что писать
> на ЭТОМ... лучше утопиться.
Ну что ж вы так? Паскаль выучили? Выучили. И это выучите если захотите, а если не хотите - не надо, вас никто не заставляет. Да вот, и не забывайте иногда писать ИМХО, потому что говорить за всех не хорошо. Ну а если писать визуально хорошо структирированный код вам не по силам, то я вам просто сочувствую.

> miek (24.02.03 17:03)
> Владимир, а может, все гораздо проще? Есть ведь компилятор
> Странник, он вроде open-source. Переписать немного и все.
Проще написать с нуля. Это ведь не блокнот какой-нибудь.

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

← →
SPeller © (2003-02-24 18:03) [12]

> Это я к тому, что за последние двое суток уже поступило
> 3 предложения по наименованию. Но я склонен остановиться
> на одном из GOODELL, WELL или GOODWILL.

Я за WELL

← →
miek (2003-02-24 20:44) [13]

Я за DESCENT

← →
Bartov (2003-02-24 21:24) [14]

Из статьи:
В частности, я заявляю свои права разрабатывать 2D-редактор, компилятор и среду программирования, и публиковать ее бесплатно или с целью продажи, по моему усмотрению.
Хм... Я че-то не понял, это будет платное удовольствие или нет?...
Не случится ли так, что KOL станет платным?!

← →
SerB (2003-02-25 06:25) [15]

Не случится ли так, что KOL станет платнымНу... в этом случае он и останется "вешью в себе"... Что касеатся названия, а почему бы не GW (хотя и не исключаемый Кладовым -U - тоже неплохо)

← →
Ketmar © (2003-02-25 11:12) [16]

>SPeller © (24.02.03 18:01)
>Ну что ж вы так? Паскаль выучили? Выучили. И это выучите если захотите
поределённо не захочу. потому что язык перегружен фичами. эдак из него скоро PL/1 сделают. который никто выучить не мог.
кстати: а он не будет, часом, пытаться исправлять кривые конструкции программиста. а то, опять же, был, помнится, компилятор, который успешно понимал программу "IF ;"...

>Да вот, и не забывайте иногда писать ИМХО
пардон, пардон. после всех постов я его задалбываюсь писать. думается, что и так понятно: имхо там в конце, имхо.

>Ну а если писать визуально хорошо структирированный код вам не по силам, то я вам просто сочувствую.
попробуйте сами. с удовольствием посмотрю на процесс вылавливания ошибки "забыл поставить пробел".
я, знаете ли, тоже занимался изобретательством языков. и даже писал на том, что изобретал. и не только я. и на грабли наступал неоднократно.
возможно, реакция у меня была черезчур резкая, однако сути это не меняет: язык неудобен. блин, откуда у людей такое маниакальное желание сделать всё посложнее?
хотя бы читали перед изобретательством труды умных людей... кулибины, елы-палы...

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

зыж
ни в коем случае не хотел и не хочу оскорбить Диму Кладова. ежели он вдруг обиделся -- приношу пардоны.

Satanas Nobiscum! 25-Feb-XXXVIII A.S.

← →
Юрец (2003-02-25 12:19) [17]

Я за WELL tooo (!!!)

← →
SPeller © (2003-02-25 15:11) [18]

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

Я, просто приучил себя уже СРАЗУ писать код со всеми полагающимися отступами. Приятно смотреть и разбираться в красивом коде, а не в каше из букв и символов.

← →
Kladov (2003-02-25 16:13) [19]

Пробелы... вам не надо будет их ставить. Это за вас редактор сделает. Даже в редакторе Delphi, попробуйте в опциях поставить Smart Tabs, и посмотрите, что бывает, когда нажат enter на конце строки. И вообще, программа будет представлена деревом. Видели TTree ? Вот оно самое и есть.

← →
Ketmar © (2003-02-25 16:25) [20]

>SPeller © (25.02.03 15:11)
ага. приятно. а также вы никогда в жизни не ошибаетесь. homo superior.

>Kladov (25.02.03 16:13)
и как редактор догадается, где там у меня цикл должен будет закончится, к примеру?

Satanas Nobiscum! 25-Feb-XXXVIII A.S.

← →
SPeller © (2003-02-25 17:07) [21]

> Ketmar © (25.02.03 16:25)
> >SPeller © (25.02.03 15:11)
> ага. приятно. а также вы никогда в жизни не ошибаетесь.
> homo superior.
Ну от этого никто не застрахован. По крайней мере если смотреть по отступам, то с ними у меня проблем уже давно нет. Автоматом уже проставляются, даже задумываться не надо где и сколько пробелов ставить.

← →
Kladov (2003-02-25 17:19) [22]

> Не случится ли так, что KOL станет платнымНу

Какие глупости. И как я его тогда один буду тестировать, исправлять, и совершенствовать?

← →
Kladov (2003-02-25 17:55) [23]

> и как редактор догадается, где там у меня цикл должен будет
> закончится, к примеру?

По концу уровня вложенности.

Вы все-таки поставьте smart tab в редакторе Delphi. Видно, вы никогда им не пользовались. Вы возможно не знаете, что дают комбинации клавиш Ctrl+Shift+I / Ctrl+Shift+U с выделенными строками. А Word"ом пользовались? Есть там кнопки "увеличить уровень", уменьшить уровень". А еще в том же ворде (будь он неладен), есть выход на больший уровень в списке-дереве: два раза enter.

> язык перегружен фичами

Фичами не обязательно пользоваться всеми и сразу.

И вообще, я не понял, вас внешний вид код пугает? Для самых пугливых будет режим отображения и редактирования максимально приближенный к традициям Си, Паскаля, Бэйсика и чего угодно другого, насколько это возможно. Может не сразу, но это будет все через плагины. Значит, те, кому захочется себе иметь такое, сделают.

2Bartov и всем, кто дочитал до авторских прав. Это немного шутка. Но уже достаточно для того, чтобы ни один суд не смог потребовать от меня компенсировать какому-нибудь наглому вору вроде M$ их потери в результате того, что они сделали вдруг компилятор и запатентовали его и продают, я тут, понимаешь, появился какой-то самозванец Владимир Кладов, сделал понимаешь то же самое, и пытается это распространять от своего имени. Поверьте, ситуация совсем не шуточная. До того, как тот же М$ начал скупать идеи, он их просто крал. Интерфейс windows2000 вчистую содран у эппловского макинтоша. И что сказала M$, когда эппл попыталась судиться? То-то же. Я судиться не собираюсь. Я просто не хочу, чтобы меня судили за то, что я якобы украл у кого-то мои собственные идеи.

← →
Ketmar © (2003-02-25 18:43) [24]

>Kladov (25.02.03 17:55)
прошу вас: перечитайте труды Вирта. а если читали -- прочтите еще раз. и подумайте над ними. тогда поймете, против чего я протестую. а то лень цитировать такие кучи текста.

Satanas Nobiscum! 25-Feb-XXXVIII A.S.

← →
Bartov (2003-02-25 18:48) [25]

2Ketmar
Слышь нечисть, сгинь с этой ветки.

← →
Kladov (2003-02-25 18:53) [26]

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

← →
Bartov (2003-02-25 23:23) [27]

2Kladov

Я как и вы получли письмо от Boguslaw"а.
В крации для всех, он поднимает следующие вопросы:

1. Что будет с KOL в будующем, не забросите ли вы его со своим новым компилятором?
2. Поддержка мультиплатформ.
3. Как насчет SQL databases и Internet protocols, таких как:
POP3,SMTP,PING,FTP(partially supported) и других.
4. Двойная работа: создание KOL компонента и МСК к нему.
5. Множество ошибок в KOL.
6. No debugging purpose objects like detecting memory leaks and telling in which function and line of unit was critical error with call stack info.
Solution proposal: add apropriate debug code to TObj should be no problem, to detect memory leaks it is sufficient to modify memory alloc code to send message about each allocation/deallocation.
И так все понятно без перевода.

Я, как стороник KOL, поддерживаю Boguslaw"а и хочу спросить:
Зачем вам этот компилятор, давайте KOL на ноги поставим!

Есть хорошая русская пословица:
За двумя зайцами погонишься - ни одного НЕ поймаешь!...

← →
centronix (2003-02-26 01:41) [28]

По поводу утечек памяти - а чем вас MemProof не устраивает ?

← →
Boguslaw (2003-02-26 02:01) [29]

MemProof is very good, I use this tool very often, but should be some portable way to detect memory leaks even if currently KOL is only Windows based.

← →
SPeller © (2003-02-26 09:58) [30]

2 Ketmar

Зачем забивать начинание на корню? Не лучше ли посмотреть что из этого получится? Это ведь ещё зародыш, и от того в каких условиях он будет расти зависит во что он превратиться. Если называть его постоянно свиньёй, то он в конце-концов и захрюкает.

← →
Ketmar © (2003-02-26 10:44) [31]

>Bartov (25.02.03 18:48)
спокойнее. дорастёшь до модератора -- будешь командовать.

>SPeller © (26.02.03 09:58)
просто я спеки видел. куда-то они не в ту сторону идут... тяготеют к монстризации. в итоге получим достойного конкурента для CPP. по запутанности и "фичам". вот и критикую. возможно, излишне резко.

Satanas Nobiscum! 26-Feb-XXXVIII A.S.

← →
Bartov (2003-02-26 11:27) [32]

2Ketmar
> Satanas Nobiscum!
Чё за бред?!

← →
access_violation, ICQ 161328952 (2003-02-26 15:59) [33]

Дмитрий, добрый день!!! То, что Вы собираетась делать - просто супер! Если данный язык, вберет в себя, кроме синтаксиса, еще и мощь отдельно взятого языка из выше указанных, то это просто решит практически все проблемы совместимости, как "разноязычных" приложений, так и приложений для различных платформ. Я полностью поддерживаю эту идею и хотел бы участвовать в ее развитии.
Вед. спец., к.т.н., Попов М.Г.

← →
access_violation, ICQ 161328952 (2003-02-26 16:13) [34]

Единственное, что сразу же бросилось в глаза - не будет ли это полностью "ручная" (как в VisualStudio C++) технология написания программ. В статье нигде не просматривается связь со средствами разработки интерфейсов по технологии RAD или это и есть 2D-редактор?

← →
Kladov (2003-02-26 17:39) [35]

2Bartov

> Что будет с KOL в будующем, не забросите ли вы его со своим
> новым компилятором?

Нет, не заброшу. Но развивать его дальше на базе Delphi не вижу смысла. Delphi вяжет по рукам и ногам. Хочется экономии кода, но при этом - нормальной иерархии объектов (или классов). Хочется больше не мучиться изготавливая компонент, делать для него зеркало. И еще: Delphi не позволяет расширяться на другие платформы нормально. Я надеюсь, в новом языке проблемы поддержки многих платформ уйдут в небытие. В том числе желаю, чтобы можно было легко компилировать для других процессоров, для тех же Sun, или Palm, или для Скиф-2. В том числе, чтобы можно было генерировать любые obj, в формате Borland или COFF или код для .net. Чтобы можно было и под DOS, и под Win, и под Unix, и вообще для работы на голой машине скомпилировать. Чтобы был один язык на все случаи жизни, и не надо было бегом бежать переучиваться, как только возникнет новая задача. И чтобы при этом можно было и на уровне исходником, и на уровне бинарников использовать все, сделанное на любых других языках, без того даже, чтобы переписывать код вручную.

> Множество ошибок в KOL

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

> add apropriate debug code to TObj

Лучше не в TObj, а использовать заменители MemoryManager, которые позволяют отслеживать все выделения и освобождения, и более тщательно анализировать ошибочные попытки освободить не ту память (например, уже освобожденную). Есть уже и готовые такие заменители MM, можно модифицировать или самому сделать - там ведь несложно.

> давайте KOL на ноги поставим

Если что глючит, давайте разбираться. По большому счету KOL - инструмент вполне рабочий. Я просто хочу перевести его на рельсы нового языка, вот и все. А первый заяц уже вполне пойман. Все равно, как ни крути, связка KOL + MCK по большому счету - это костыль для Delphi, хромающего из-за того, что не был изначально Паскаль тем языком, который из него сделали. Так же как и C++, он хромой. Вспомните: сначала ему приделали string[], потом object, потом class, потом прикрутили interface, overload, ... И все это - сбоку. Все скрипит, шатается, груз совместимости давит.

Дело-то в чем. Начал я было с полгода назад смотреть, нельзя ли написать простенький компилятор с Паскаля. Обнаружил, что можно, ничего сложного в том нет. Но - скучно, поверьте мне. Делать компилятор только Паскаля. Даже в его расширении Delphi. Ограничения языка таковы, что эффективный код создать все равно не получится. Не для того язык планировался. В нем слишком много от тех представлений о программировании, которые появились в каменном (лампово-перфокарточном) веке. Чего одно многозначное слово const стоит.

Я потихоньку (между делом) буду дописывать свои мысли о том, как должны (и будет) выглядеть) реализация WELL. Это будет в отдельном разделе.

Например, такой момент. Всем известно, что большое число мелких процедурок - это хорошо для стиля. Но - совсем нехорошо для размера кода и быстродействия. (В Delphi это еще усугубляется тем, что все процедуры и функции выравниваются на границу двойного слова - 4 байта, в результате еще по 2 байта в среднем тратится на nop). А иногда бывает и так, что код, вставленный непосредственно (inline в C), получается и короче, и эффективнее, чем оформление вызова подпрограммы N раз + код самой подпрограммы. В WELL можно будет забыть об этой досаде, и даже не писАть inline. Просто в режиме smart-inline компилятор сам будет считать, что выгоднее, встроить код в место вызова, или оформить подпрограмму. Само собой, должен быть режим "быстрой" компиляции, и тогда эта фича напрочь выключается.

2Ketmar

> тяготеют к монстризации

Ну, и что вы предлагаете выбросить? Я внимательно выслушаю. А потом подумаю, может еще что добавлю :)

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

> достойного конкурента для CPP

более того, я надеюсь, что получится достойный конкурент даже для C#. Особенно если учесть, что C# скорее всего останется жить только на платформе .net, живучесть которой еще не проверена временем.

Сейчас еще добавлю ответ Богуславу. Лучше отдельным сообщением.

← →
Kladov (2003-02-26 17:40) [36]

Привет Boguslaw,

Среда, 26 Февраля, 2003, 1:02:46 БУДУ, Вы написали:

BB> ПРИВЕТ Vladimir,

BB> Я читаю Вашу статью о GOODWELL с некоторым типом страха. Это - хороший
BB> проект Я полагаю но другой вопрос - : почему Вы планируете новый компилятор не BB> совместимый с Delphi?
Он будет совместимым, и способен понять Delphi код.

BB> КАК НАСЧЕТ KOL? Каково будущее KOL?
А что плохо с KOL? KOL ГОТОВ к использованию. Некоторые дефекты должны фикситься, и все. Я планирую использовать KOL как основу визуальной библиотеки для goodwell. Но с лучшей объектной иерархией, Я уверен с goodwell это будет возможно.

BB>, КОГДА такая новая идея происходит есть больше вопросов, тогда решения,и так
BB> - на этот раз.
BB> ВЫ обоозначаете, что KOL не достаточен для разработки хороших программ?
Я хотел бы использовать больше кода других авторов без необходимости переписывать их компоненты / объекты / процедуры каждый раз.

BB> ЭТО - интересно becouse также Borland забыл об объектах и выбирал классы.
Но они осуществили их так неэффективно.

BB> ТАК, каковы основные причины, чтобы создать новый компилятор? - Вы действительно уверены
BB>, что Вы можете сделать это в разумное времени (взгляд на разработку
BB> компилятора FreePascal [позволяет мне] сомневаться )?
Я уверен, что если Я бы мог быть свободным совсем от других работ (от потребности тратить ежедневно 9 часов, чтобы заработать деньги, 3 часа для моей семьи и т.п.), и то потребовалось бы только 9-12 месяцев, чтобы сделать это для меня одного. Но даже с моей постоянной занятостью, Я надеюсь, что сделаю стартовые шаги (2D-редактор, первая версия компилятора) менее чем за год. И дальнейшая работа может делиться между добровольцами, поскольку GoodWell использует plugin-ы для чего угодно.

BB> ПОЗВОЛЮ высказать несколько слов : может быть это - хорошая идея, сделать список
BB> преимуществ и слабостей KOL и затем решить, что лучше делать : новый компилятор BB> или может быть новое IDE или новый язык и компилятор?
BB> Я могу начать заполнять этот список,например:
BB> СПИСОК преимуществ:
BB> 1. Небольшой размер выполняемых программ.
BB> 2. Объекты очень близкы к delphi компонентам , так что перенесение - сравнительно
BB> легко
Я бы переместил это утверждение в недостатки. Перенесение все еще слишком тяжело. Если бы это было легким, мы теперь имели БЫ огромное число компонентов, преобразованных в KOL-совместимые.

BB> 3. Full hierarchy of standard objects for almost every processing with full
BB> source code
К несчастью, KOL не имеет почти никакой иерархии совсем (все визуальные объекты - в TControl). Это - хорошо для выполняемого размера, но это - очень плохо для стиля программирования.

BB> 4. Full list of standard visual controls in Windows
BB>....

BB> СПИСОК слабостей:
BB> 1. Недостаточно объектов для не-стандартных визуальных управлений по большей части для поддержки
BB> базы данных SQL и протоколы Internet такое подобно:
BB> POP3,SMTP,ЗВОН,FTP(частично поддерживающее) и другие.

BB> ПРЕДЛОЖЕНИЕ Решения: есть много открытых источников способа свободного пользования delphi компонентов
BB> пригодных для adapt для KOL (наконец ровный ТУРБОРЕАКТИВНЫЙ [TurboPower] Morpheus собирается
BB> [перейти] на OpenSource)
BB> МОЖЕТ БЫТЬ также мы можем попросить, что создатели допустили статическую компоновку в программы KOL если
BB> компонент распространяется под LGPL лицензией.
Нет проблем, чтобы сделать это. Точнее, время, и желание (У меня нет такого желания, и даже под VCL в большинстве случаев Я чувствую себя хорошо без db-aware контролов).

← →
Kladov (2003-02-26 17:41) [37]

BB> 2. Двойная конструкция: средства KOL+MCK также двойной работы создания объектного кода
BB> и зеркало MCK
BB> предложение Решения: замена IDE (и компилятора конечно). Lazarus Имеет
BB> почти полное IDE (но базировавшееся на GTK так очень медленный по сравнению с Delphi) и
BB> - открытый источник GPL, так что это может быть заменено KOL
Давайте лучше подождем .NET, и у нас будет общее IDE - для всех языков (если Microsoft не врет нам).

BB> 3. Только для Windows
BB> предложение Решения: после установок в Free Pascal Compiler и приспосабливая
BB> Lazarus IDE для KOL есть шанс, чтобы сформировать multiplatform решение основанное
BB> на KOL ,но KOL было бы rewritten (например столбцы с указывают точку зрения должно
BB> быть объектом против avoid, изменяющий имя столбца используя низкий уровень API)
Очень сомнительно. Очень.

BB> 4. Никакая отладка цели не возражает подобно памяти detecting просачивается и сообщая в
BB> какая функция и строка устройства была критическая ошибка с инфо стека вызова.
BB> ПРЕДЛОЖЕНИЕ Решения: подходящий отладочный код дополнения, чтобы TObj не было бы никакой проблемы,
BB>, чтобы обнаружить, что память просачивается это достаточное, чтобы модифицировать память распределять код, чтобы послать
BB> сообщение относительно каждого распределения/освобождения

Memproof, Ищейки Памяти (Memory Sleuth), наконец, замена менеджера памяти в Delphi.

BB> 5. Много дефектов? (по сравнению с другими проектами подобно wxWindows) Я не буду
BB> разработанное, чтобы судить этому, если бы не я есть гораздо больше дефектов в KOL, тогда в
BB> другие проекты (может быть delphi - плох или слишком широко использован ассемблер)

Для KOL важен размер кода. Иногда? Нет, часто код записан в стиле, который не позволяет писать совсем без дефектов. Я должен избегать постоянной проверки параметров, границ индексации и т.п. Лучший компилятор мог бы решить такую проблему. Но мы даже не знаем, как Delphi компилятор работает в деталах, чтобы помочь Inprise увеличить мощность компилятора Delphi.

BB> KOL ДАВАТЬ мне что Я ожидал (почти) от библиотеки RAD : легкая разработка из-за использования
BB> объектов и - powerfull (мощная?) из-за выбрасывания неиспользованного кода из завершенной
BB> программы. Весь RAD должно иметь эту характеристику.

BB> Я проявляю живой интерес к KOL из старого времени XCL (У меня все еще есть отпечатанная подсказка о
BB> XCL ,тем не менее никогда соединенное в этот проект) и хотел бы быть уверенным, что
BB> KOL будет разработан.
XCL был хорош, пока не стали разрабатывться сложные компоненты как например, listview или grid. Затем Я обнаружил, что преимущество уменьшения размера сошло на нет, но с большим числом багов. Я не очень сожалею об XCL, это было хорошая прелюдия для того, чтобы начать KOL.

BB> НЕСКОЛЬКО слов о GOODWELL:

BB> ЕСЛИ Вы планируете преобразовывать KOL в "goodwell" компиляторе, тогда:
BB> "goodwell" ДОЛЖНО быть свободным для ХОРОШО , и "goodwell" должно ХОРОШО разработать
BB> delphi <-> "goodwell" и C <-> "goodwell" преобразователь.
Несомненно! Я планирую делать это через plug-in"ы. Вы читали?

BB> P.S.

BB> Я ценю если Вы или, кто-то мог бы перевести этот email на русском и
BB> публиковаться в форуме KOL, чтобы начать дискуссию.
Перевести? Mmmm. Очень долго. Я попытаюсь хотя. С авто-переводчиком.

--
Сердечный Привет, Vladimir

------------------------
P.S. Ну вот, вроде бы и все. Извинения за слишком машинизированный перевод. Но время дороже :)
(пришлось поделить на 2, слишком длинное сообщение)

← →
Kladov (2003-02-26 18:36) [38]

2access_violation

> В статье нигде не просматривается связь со средствами разработки
> интерфейсов по технологии RAD или это и есть 2D-редактор?
>

IDE оно и в Африке IDE :) Все-таки я предпочитаю по возможности классический подход - вот редактор, вот компилятор, вот отладчик. В визуальной разработке добавляется еще и визуальный дизайнер. И уже сумма всего этого, когда оно интегрировано в единую среду = IDE. Деление на части облегчает разработку целого. При описании языка нет необходимости рассказывать, как оно будет визуально (а что, вы думаете, это будет намного отличаться от того, что есть в VB, VC++, CB, Delphi?). При изучения Паскаля тоже не надо знать, как в Delphi можно строить этот же код визуально.

← →
Ketmar © (2003-02-26 18:57) [39]

2Kladov:
Дима, я понял. вам очень охота личный велосипед изобрести. и это не важно, что велосипедов уже много -- они же не ваши. и не важно, что некоторые люди, съевшие собаку на велосипедах, дают какие-то рекомендации. рекомендации у них заведомо неверные. и реализации у всех кривые. а у нас будет самый поездатый поезд.
насчёт "плохого кода": посмотрите компилятор XDS от Excelsior. который компилит Modula-2 и Oberon. и сравните его код с любым CPP, который сейчас считается крутым.

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

Satanas Nobiscum! 26-Feb-XXXVIII A.S.

← →
Kladov (2003-02-27 04:39) [40]

Очень жаль. Человеку, призывающему перечитать Вирта, не хватило терпения, чтобы внимательно прочитать то, что я изложил. Почему я так решил? Меня зовут не Дима.

← →
Bartov (2003-02-27 10:49) [41]

2Kladov

AB> Что будет с KOL в будующем, не забросите ли вы его со своим новым компилятором?
VK> Нет, не заброшу. Но развивать его дальше на базе Delphi не вижу смысла.

А я, и надеюсь многие другие поддержут меня, - вижу смысл. Если ни какого развития не будет, то KOL - умрет! Ну и что, то что он хромой, Винда не хромая? Нет не хромая - КАРЯВАЯ, но ведь все на ней работают. А то чуствую я, что при выходе новой версии Делфи, мы просто не увидим к KOL"у МСК... Или я не прав?!...

С другой стороны, если вы не хотите развивать его на Делфи, то не надо ;-(
СРАЗУ ОГОВОРЮСЬ.
Прежде чем забросить развитие KOL на Делфи, вам НЕ мешало бы написать пару статей ( кратких СПРАВОЧНИКОВ ) о MCK и KOL, где было бы расмотрено по шаговое построение КОЛ объекта, а про - МСК не плохо было бы - описать весь принцып его работы (что где находится и как все это выполняется), а то на чистых исходниках тяжеловато разбираться.
А вот после этого можете на КОЛ уже меньше времени уделять и больше GOODWEEL"у. Поверьте, 90% нужно писать под Виндами...
Будующее покажет что к чему, но нелепую смерть КОЛа не хотелось бы увидеть (типа: год 2005, последния версия КОЛ 1.75)...

P.S. Это лично мое мнение и я буду его отсаивать.

← →
Ketmar © (2003-02-27 11:17) [42]

>Kladov (27.02.03 04:39)
"Владимир" для меня подсознательно сократилось в "Дима". извиняюсь, если обидел или оскорбил.

Satanas Nobiscum! 27-Feb-XXXVIII A.S.

← →
SerB (2003-02-27 12:48) [43]

Владимир, а есть ведь еще один вариант "организации труда"... KOL&MCK должен развиваться на существующей базе, что не должно помешать созданию GoodWell, как я понял включающего KOL&MCK как бузу для IDE... А т.к. в сутках 24 часа, семья и работа отнимают немного времени, да и спать иногда надо, можно переложить поддержку этого проекта на приКОЛистов...
Ну а... "кетмаров" (ничего личного не имею)бояться - в лес не ходить... Удачи...

← →
Kladov (2003-02-27 16:45) [44]

2Bartov
Ну, а что в KOL развивать-то? Будет использоваться, будут и новые функции появляться. Вот сейчас, в связи с задачей построения 2D-редактора, который доллжен рисовать Unicode-символы, среди прочего мне придется усилить KOL.TCanvas, чтобы можно было рисовать Unicod-овский текст. Это и есть развитие.

Писать справочники я никому не запрещаю. Хоть книги. Но ИМХО - пока не нужно.

← →
Bartov (2003-02-28 01:15) [45]

2Кладов

Ну, а что в KOL развивать-то?
Да БД и визуализацию к ней.

← →
Kladov (2003-02-28 04:54) [46]

> БД и визуализацию к ней

А это сами, пожалуйста. Мне оно не надо. То, что я сделал, было сделано только для того, чтобы показать, что ничего невозможного нет. Дальше все уже легче.

← →
Kladov (2003-03-01 21:26) [47]

Добавил спецификацию P-кода, если кому интересно.

← →
Boguslaw (2003-03-03 12:24) [48]

Where ? Give a link.

← →
Kladov (2003-03-03 19:15) [49]

bonanzas.rinet.ru / GOODWELL -> главная -> P-code

По-русски только.

← →
Bartov (2003-03-04 00:32) [50]

2Кладов
> Добавил спецификацию P-кода, если кому интересно.
Дейтсвительно интересно, исли это будет так как описано, то GOODWELL цены не будет.

← →
Yury Sidorov (2003-03-04 10:36) [51]

Покритикую P-код.
Суть критики в следующем: не стоит делать набор команд P-кода проще (примитивнее) чем набор команд хотя бы одного процессора, на который будет компилироваться P-код программа.

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

Дополнительно нужно ввести команды Р-кода для работы с блоками памяти - копирование, сравнение, поиск, заполнение значением, т. к. подобные комадны есть, по крайней мере, в процессорах Интел. Конечно, можно для пересылки блока памяти организовать цикл, но компилятору (если в процессоре есть команды для работы с блоками памяти) будет очень трудно заменить этот цикл на команду пересылки блока памяти. А если в конечном процессоре нет команд для работы с блоками памяти, то такие команды легко заменяются на цикл из поддерживаемых процессором команд.

Т. е. суть всего сказанного такая: сложное легко заменить простым, а простое не всегда просто заменяется сложным.

← →
Kladov (2003-03-04 16:30) [52]

> Команда сравнения есть в наборе команд практически любого
> процессора

Но не у любого процессора есть регистр флажков в том же виде, как на PC. Когда идет перевод с ЯВУ в п-код, это неважно, потому что в ЯВУ мы сразу пришем IF ... THEN ... . Здесь и вычисление условия, и переход. А когда с P-кода в тот же ассемблер, то уже намного хуже получится. Что должно быть? IF-последнее-сравнение-дало-истину-THEN ... ? Что считать последним сравнением? Где искать команду, если она отстоит на сколько-то уже вверх. А если их несколько? И при этом они по-разному воздействуют на флажки? То, что я предполагаю, означает всего лишь косвенное указание на ту операцию, которая была выполнена. А там уже дело компилятора, будет он ассоциировать регистр с настоящим регистром, памятью или флажком процессора.

> нужно ввести команды Р-кода для работы с блоками памяти

Совсем не обязательно. Совсем не трудно перевести цикл
:11 D[{P5}]=0
{P5}+4
{D4}-1
{D4}>0?:1
В что-то вроде
MOV EDI, {P5}
MOV ECX, {D4}
XOR EAX, EAX
REP STOSD

Вообще, чем проще язык, тем лучше. На простом языке можно организовать анализ сигнатур (что-то похожее на анализ сигнатур полиморфных вирусов) - с целью оптимизации, и вообще компилятор в код любого процессора можно построить как анализатор таких сигнатур. Такую технологию я использовал еще аж в 1988 г. при написании компилятора с С, тогда еще не ++.

Например, для вышележащего P-кода сигнатура могла быть именно такой, как сам код, только отличались бы номера регистров ( команды {P5}+4 и {D4}-1 можно было бы записать в одну строку, как бы помечая, что их можно переставить. Или нужно две сигнатуры - на каждый порядок этих команд ). Найдена сигнатура, а дальше компилятор знает, какой код генерировать для такой сигнатуры. Для каждого типа процессора свой набор сигнатур. Можно и выходные шаблоны поставить в прямое соответствие. Транслятору только остается отслеживать занятось реальных регистров.

А вот почему я решил, что нужна независимая команда для выделения локального массива: потому что тут уже проблема не команды переставить местами. А вообще ухитриться без знания того, что это за память, как она получена, где располагается, все-таки описать это выделение (оно обычно статическое в том смысле, что в начале блока делается один раз, и при выходе из блока память освобождается, но мало ли - для оптимальности и на платформе PC бывает выгодно заменять getmem простым сдвигом ESP). Где-то будет сдвинут указатель стека, а где-то придется выделять участок памяти из динамики. Тут уже просто никак иначе нельзя. Не стоит, однако, сразу поступать так же со всеми прочими вещами.

В общем, как дойдет до компилятора, тогда и смотреть будем давайте :)

← →
Kladov (2003-03-04 17:09) [53]

эээ метка там должна быть :1 (сдвоило)

← →
Yury Sidorov (2003-03-04 18:06) [54]

Ответ меня устроил :)
Главное чтобы алгоритм эффективного компилятора с Р-кода был простым.

а зачем вообще p-код? см. juice.

Satanas Nobiscum! 05-Mar-XXXVIII A.S.

← →
Kladov (2003-03-05 21:05) [56]

> а зачем вообще p-код?

1. Чтобы плагин, который переводит в код целевой платформы, не заморачивался с синаксисом исходного языка.
2. Пока код представлен в виде P-кода, можно выполнять предварительные оптимизации путем последовательных инвариантных преобразований. В том числе все плагины, переводящие из P-кода в код целевой машины, могут использовать один и тот же модуль оптимизации, подавая на вход свои правила преобразования, удобные для этого плагина и для этой целевой платформы. Правила можно представлять в виде пар сигнатура-преобразование. Это намного упрощает процесс создания плагина для каждой новой платформы.

>Kladov (05.03.03 21:05)
отвечаем не читая полностью сообщение. плохо. повторяю: см. juice.

Satanas Nobiscum! 06-Mar-XXXVIII A.S.

← →
Kladov (2003-03-06 19:46) [58]

Ну а при чем тут juice. Умершая (или неживая, что то же самое) альтернаива явы, платформ-независимый. Более эффективный, чем ява. (Но яву браузеры поддерживают, а juice нет). Не знаю, есть в нем свой п-код, или нет. А дальше? В goodwell эффективность самого п-кода не имеет значения. Не будет интерпретатора. Главное - примитивность представления кода. Чем примитивней, тем лучше.

И пожалуйста, больше не надо - см. туда, читаем сюда. Некуда смотреть. Было бы куда, не писали бы мы на Delphi сейчас.
И не пытался бы никто изобретать новые языки.

>Kladov (06.03.03 19:46)
>Главное - примитивность представления кода. Чем примитивней, тем лучше.
перл.

>И пожалуйста, больше не надо - см. туда, читаем сюда. Некуда смотреть. Было бы куда, не писали бы мы на Delphi сейчас.
И не пытался бы никто изобретать новые языки.
ещё один перл.

вся ветка -- коллекция перлов. Владимир, неужели ваш фанатизм НАСТОЛЬКО зашорил ваше мышление?

Satanas Nobiscum! 11-Mar-XXXVIII A.S.

← →
АлексейС (2003-03-13 11:53) [60]

Насчет PI-cod, то что бросается в глаза и возможно является непринципиальным, но люди работающие на разных платформах по разному понимают тип данных WORD и DWORD, например для процессоров с гарвардской архитектурой машинное слово, т.е. WORD может быть равно 14 битам, 12битам. Возможно для кросплатформенности (точнее для взаимпонимания программистов разных платформ) стоит в PI коде указывать дополнительную секцию настройки на тип данных или использовать тип данных одназначно говорящий о ширине (в битах данного). Может так B16, B32, B64, B12? По поводу системы счисления в константах, может приблизить ее к более традиционному H,B,O в замен 16,2,8 (учитывая заодно и экононмию в символе на шестнадцатиричной системе).

← →
puky@ukr.net (2003-03-26 21:00) [61]

Как там прогресс???

← →
Fantasist. (2003-03-26 22:24) [62]

Начал читать - очень интересно! Особенно впечатлила идея использования абзацов вместо огранечителей блоков. Так сразу не скажу, что идея бесспорная, но мне кажется очень здравой. Правда, хотелось бы все-таки чтобы определения функций имели какую-то закрывающую лексему. Хотя бы как в бэйсике:
function ... endf;

Во-первых, в теле функции часто оставляю пустые строки для разделения подэтапов функции (типа инициализация, цикл обработки, завершение) - читается удобнее. Во-вторых, удобно при отладке - можно бряк поставить на выход из фунции. В-третьих, все-таки нагляднее.
Да. И сами определяния функций по-моему лучше в стиле С++. Вот что меня в паскале очень достовало, так то что надо писать то function то procedure, писать жутко неудобно, многословно, читабильность ничуть не лучше.
Равноправность скобок это тоже интересно, однако мне кажется внесет это больше путаницы, нежели облегчение восприятия.

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

← →
alek111 (2003-10-24 18:08) [63]

Использование абзацев вместо ограничителей блоков реализовано в Python, кстати, очень неплохой язык его-бы переработать немного для полного счастья.

Язык программирования GOODWELL Найти похожие ветки