| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Язык программирования GOODWELL
Kladov © (2003-02-22 14:42:00)Потихоньку готовлю к публикации предварительную спецификацию разрабатываемого мною языка. Собственно, спецификация уже готова. Просто перевожу на английский. Все, кто желают ознакомиться, я сейчас выложу русскую версию спецификации здесь: http://bonanzas.rinet.ru/goodwell/GOODWELL-spec-RU.htm
Предвосхищая вопрос При чем тут KOL - редактор будет делаться на KOL/MCK, компилятор поначалу тоже. Ну и автор тот же. И сторонников я надеюсь набирать из тех же людей, что занимаются улучшением KOL. И сайт будет тот же - нет возможности еще и сайт отдельный создавать :)
SerB (2003-02-27 12:48:00) [21]Владимир, а есть ведь еще один вариант "организации труда"... KOL&MCK должен развиваться на существующей базе, что не должно помешать созданию GoodWell, как я понял включающего KOL&MCK как бузу для IDE... А т.к. в сутках 24 часа, семья и работа отнимают немного времени, да и спать иногда надо, можно переложить поддержку этого проекта на приКОЛистов...
Ну а... "кетмаров" (ничего личного не имею)бояться - в лес не ходить... Удачи...
Ketmar (2003-02-27 11:17:00) [22]>Kladov (27.02.03 04:39)
"Владимир" для меня подсознательно сократилось в "Дима". извиняюсь, если обидел или оскорбил.
Satanas Nobiscum! 27-Feb-XXXVIII A.S.
Bartov (2003-02-27 10:49:00) [23]2Kladov
AB> Что будет с KOL в будующем, не забросите ли вы его со своим новым компилятором?
VK> Нет, не заброшу. Но развивать его дальше на базе Delphi не вижу смысла.
А я, и надеюсь многие другие поддержут меня, - вижу смысл. Если ни какого развития не будет, то KOL - умрет! Ну и что, то что он хромой, Винда не хромая? Нет не хромая - КАРЯВАЯ, но ведь все на ней работают. А то чуствую я, что при выходе новой версии Делфи, мы просто не увидим к KOL'у МСК... Или я не прав?!...
С другой стороны, если вы не хотите развивать его на Делфи, то не надо ;-(
СРАЗУ ОГОВОРЮСЬ.
Прежде чем забросить развитие KOL на Делфи, вам НЕ мешало бы написать пару статей ( кратких СПРАВОЧНИКОВ ) о MCK и KOL, где было бы расмотрено по шаговое построение КОЛ объекта, а про - МСК не плохо было бы - описать весь принцып его работы (что где находится и как все это выполняется), а то на чистых исходниках тяжеловато разбираться.
А вот после этого можете на КОЛ уже меньше времени уделять и больше GOODWEEL'у. Поверьте, 90% нужно писать под Виндами...
Будующее покажет что к чему, но нелепую смерть КОЛа не хотелось бы увидеть (типа: год 2005, последния версия КОЛ 1.75)...
P.S. Это лично мое мнение и я буду его отсаивать.
Kladov (2003-02-27 04:39:00) [24]Очень жаль. Человеку, призывающему перечитать Вирта, не хватило терпения, чтобы внимательно прочитать то, что я изложил. Почему я так решил? Меня зовут не Дима.
Ketmar (2003-02-26 18:57:00) [25]2Kladov:
Дима, я понял. вам очень охота личный велосипед изобрести. и это не важно, что велосипедов уже много -- они же не ваши. и не важно, что некоторые люди, съевшие собаку на велосипедах, дают какие-то рекомендации. рекомендации у них заведомо неверные. и реализации у всех кривые. а у нас будет самый поездатый поезд.
насчёт "плохого кода": посмотрите компилятор XDS от Excelsior. который компилит Modula-2 и Oberon. и сравните его код с любым CPP, который сейчас считается крутым.
а впрочем... чего это я? ваш проект умрёт сам собой. и особых усилий для его умертвления прикладывать не надо. в таком виде, в каком он сейчас -- мертворожденное дитё. увы.
на сём я самоустраняюсь из дискуссии.
Satanas Nobiscum! 26-Feb-XXXVIII A.S.
Kladov (2003-02-26 18:36:00) [26]2access_violation
> В статье нигде не просматривается связь со средствами разработки
> интерфейсов по технологии RAD или это и есть 2D-редактор?
>
IDE оно и в Африке IDE :) Все-таки я предпочитаю по возможности классический подход - вот редактор, вот компилятор, вот отладчик. В визуальной разработке добавляется еще и визуальный дизайнер. И уже сумма всего этого, когда оно интегрировано в единую среду = IDE. Деление на части облегчает разработку целого. При описании языка нет необходимости рассказывать, как оно будет визуально (а что, вы думаете, это будет намного отличаться от того, что есть в VB, VC++, CB, Delphi?). При изучения Паскаля тоже не надо знать, как в Delphi можно строить этот же код визуально.
Kladov (2003-02-26 17:41:00) [27]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 17:40:00) [28]Привет 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:39:00) [29]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, живучесть которой еще не проверена временем.
Сейчас еще добавлю ответ Богуславу. Лучше отдельным сообщением.
access_violation, ICQ 161328952 (2003-02-26 16:13:00) [30]Единственное, что сразу же бросилось в глаза - не будет ли это полностью "ручная" (как в VisualStudio C++) технология написания программ. В статье нигде не просматривается связь со средствами разработки интерфейсов по технологии RAD или это и есть 2D-редактор?
access_violation, ICQ 161328952 (2003-02-26 15:59:00) [31]Дмитрий, добрый день!!! То, что Вы собираетась делать - просто супер! Если данный язык, вберет в себя, кроме синтаксиса, еще и мощь отдельно взятого языка из выше указанных, то это просто решит практически все проблемы совместимости, как "разноязычных" приложений, так и приложений для различных платформ. Я полностью поддерживаю эту идею и хотел бы участвовать в ее развитии.
Вед. спец., к.т.н., Попов М.Г.
Bartov (2003-02-26 11:27:00) [32]2Ketmar
> Satanas Nobiscum!
Чё за бред?!
Ketmar (2003-02-26 10:44:00) [33]>Bartov (25.02.03 18:48)
спокойнее. дорастёшь до модератора -- будешь командовать.
>SPeller © (26.02.03 09:58)
просто я спеки видел. куда-то они не в ту сторону идут... тяготеют к монстризации. в итоге получим достойного конкурента для CPP. по запутанности и "фичам". вот и критикую. возможно, излишне резко.
Satanas Nobiscum! 26-Feb-XXXVIII A.S.
SPeller (2003-02-26 09:58:00) [34]2 Ketmar
Зачем забивать начинание на корню? Не лучше ли посмотреть что из этого получится? Это ведь ещё зародыш, и от того в каких условиях он будет расти зависит во что он превратиться. Если называть его постоянно свиньёй, то он в конце-концов и захрюкает.
Boguslaw (2003-02-26 02:01:00) [35]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.
centronix (2003-02-26 01:41:00) [36]По поводу утечек памяти - а чем вас MemProof не устраивает ?
Bartov (2003-02-25 23:23:00) [37]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 на ноги поставим!
Есть хорошая русская пословица:
За двумя зайцами погонишься - ни одного НЕ поймаешь!...
Kladov (2003-02-25 18:53:00) [38]Когда Вирт делал Паскаль, стон возмущенной общественности был очень велик :) Как же, помним.
Bartov (2003-02-25 18:48:00) [39]2Ketmar
Слышь нечисть, сгинь с этой ветки.
Ketmar (2003-02-25 18:43:00) [40]>Kladov (25.02.03 17:55)
прошу вас: перечитайте труды Вирта. а если читали -- прочтите еще раз. и подумайте над ними. тогда поймете, против чего я протестую. а то лень цитировать такие кучи текста.
Satanas Nobiscum! 25-Feb-XXXVIII A.S.
| |
Страницы: 