Мощная среда ZXDev для разработки НА ПЯТИ ЯЗЫКАХ для ZX готова к тестированию

[Oleg N. Cher]

О, Сергей Губанов - очень серьёзный и известный оберонщик и физик, может даже доктор наук, я точно не в курсе. Он для спектрума кодить не будет. Зато он - автор подсистемы для раскраски синтаксиса для БлэкБокса, которую я использовал в XDev. Так что косвенно он уже участвует.

Да, Оберон-сообщество довольно малочисленное.

---------- Post added at 23:59 ---------- Previous post was at 23:48 ----------

Про объявление переменных по месту. Delphi и FreePascal уже довольно зрелые среды разработки, но ничего подобного объявлению переменных по месту в них не внедрено, хотя внедрено много чего другого. Это вопрос культуры кодинга. Список переменных одним блоком - это как бы секция данных процедуры. Помните выражение "алгоритмы и структуры данных"? Так вот, алгоритмы - то, что после BEGIN, а данные - VAR. И это здорово, что секция данных декларативна, а не размазана по исполняемому коду неизвестно как. Это дисциплинирует имхо. Учит думать более структурно, в терминах "алгоритм отдельно, данные отдельно". Ну да пусть это будет моё имхо и ничего больше.

И ещё знаете что меня удивляет. Что в Паскаль пытаются внедрить какие-то рюхи из плюсов, но даже не смотрят в сторону убирания лишних BEGIN'ов в духе Модулы-2 и Оберона. Да, нарушится совместимость. Но нет, это необязательно - можно ввести обероновские фичи доступными по специальной директиве типа (*Oberon+*)

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

[Advertiser]

[msm]

Про объявление переменных по месту. Delphi и FreePascal уже довольно зрелые среды разработки, но ничего подобного объявлению переменных по месту в них не внедрено, хотя внедрено много чего другого. Это вопрос культуры кодинга. Список переменных одним блоком - это как бы секция данных процедуры. Помните выражение "алгоритмы и структуры данных"? Так вот, алгоритмы - то, что после BEGIN, а данные - VAR. И это здорово, что секция данных декларативна, а не размазана по исполняемому коду неизвестно как. Это дисциплинирует имхо. Учит думать более структурно, в терминах "алгоритм отдельно, данные отдельно". Ну да пусть это будет моё имхо и ничего больше.

Вопрос только - нужно ли в наше время думать структурно. Во времена создания Паскаля структурное программирование действительно было прорывом. Но с тех пор было множество других прорывов. Изменились условия и изменилась элементная база. Сейчас, за счет того, что уперлись в рост тактовой частоты и появилась ставка на параллелизм, в тренде функциональное программирование. Да, там var не в почете, но всякие val, def вовсю используются. Уже по 8 ядер даже в мобильниках, в видеокартах вообще бешенный уровень параллелизма - сейчас совершенно другие концепции, сейчас нужно не каждый такт и байт считать, сейчас чтоб не тормозило нужно как то использовать сразу все ядра, и крайне желательно без синхронизации, чтоб был параллелизм а не concurrency. В императивном программировании тоже совершенно другие концепции, которые были в 70-е годы. Не циклы со счетчиком, а итераторы, например - уже давно стандарт.

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

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

Но насколько я знаю, языки Оберон семейства претендуют на большее, чем использование в ретрокомпьютерах. И в этих условиях я ни черта не понимаю, зачем так цепляться за with. Ну можно было бы для обратной совместимости оставить секцию var. Но также внести оператор val как в scala - хуже от этого точно не будет, это прекрасная замена with. И в циклах со счетчиками тоже разрешить объявлять переменные без явной секции, например тоже как val. Варианты есть для того, чтобы сохранить обратную совместимость, но при этом язык сделать более удобным.

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

[Oleg N. Cher]

Семантика WITH в Обероне отличается от паскалевской. В Паскале with применяется для сокращения длины кода при обращении к группе элементов записи - что-то вроде ручной оптимизации. В Обероне WITH - это охрана типа - безопасное приведение родителя к потомку, которое вызывает исключение если оно некорректно.

TYPE
  ChlenSemyi = RECORD END;
  Syn = RECORD (ChlenSemyi) END;
  Doch = RECORD (ChlenSemyi) END;

VAR semyanin: POINTER TO ChlenSemyi;
BEGIN
  ...
  WITH semyanin: Syn DO (* Вот здесь вылетит, если семьянин - не сын *)

У простого компилятора есть достоинства. Его легче дорабатывать малыми силами, переориентировать на другие платформы, обфичивать, наконец. Вы просто привыкли к готовым фирменным инструментам, которые делаются огромнейшими силами. Кстати, я не верю в прогресс. Я верю скорее не в то, что скоро мобильники стоядерные будут у каждого, а в то, что люди заползут в пещеры и скатятся к каннибализму. Оптимист я, понимаете. Но это так, отступление.

---------- Post added at 18:46 ---------- Previous post was at 18:37 ----------

А думать структурно - всегда полезно. У вас вещи в шкафу лежат стопками или кучей - грязное с чистым вперемешку? Человеку свойственно упорядочивать пространство вокруг себя, это его суть, родовая задача. Ментальное пространство тоже. Чем лучше оно упорядочено - тем проще жить. С программированием то же самое.

Я, занимаясь настройкой компов, заметил, что состояние компьютера напрямую зависит от уровня интеллекта человека, его использующего. У "охламонов" всё кучей и навалом - чёрт ногу сломит, фильмы - куски vob'ов, скопированные с DVD не целиком, шансон вперемешку с фотками "я бухаю на днюхе" и остатками когда-то установленных игр. У интеллектуалов - учителей, студентов - порядка на компе гораздо больше. Всё разложено по папочкам, которые аккуратно названы и т.д. Если вам не нравится такая аналогия с программистами, не парьтесь, как говорится.

---------- Post added at 19:07 ---------- Previous post was at 18:46 ----------

Хочу приятно порадовать сишников и плюсистов, которые пару лет назад с пеной у рта доказывали мне, что в Си есть модульность. Таки свершилось! Фича, которая была в Модуле-2 30 лет назад - теперь и в C++, и это очень прогрессивно, господа. Я правда рад. И не издеваюсь. Только вопрос: если в Си уже была модульность, то что они тогда ввели, в чём, так сказать, цимес?

[Alcoholics Anonymous]

Не ошибаетесь. Но я имел в виду ZX-библиотек для работы из SDCC, что и обозначил.

SDCC можно использовать из z88dk теперь дает ему доступ к значительной части z88dk библиотек SDCC в сочетании с z88dk генерирует двоичные файлы 5-50% меньше, но чаще всего в диапазоне 10-20%. Программы, которые используют библиотеки кода см крупнейшие сокращения в размере и улучшения в скорости.

Скрытый текст

sdcc can be used from z88dk now, giving it access to a large part of the z88dk libraries sdcc in combination with z88dk generates binaries 5-50% smaller but most typically in the 10-20% range. Programs that make use of library code see the largest reductions in size and improvements in speed.

[свернуть]

SDCC имеет лучшую кодогенерацию из всех открытых компиляторов для Z80.

Это не то, что четкая. SDCC генерирует код плохое, когда дело доходит до контакта с статика, длинных и поплавков. sccz80 генерирует лучший код для этих трех случаев. Дело статика очень важно, потому что для того, чтобы получить лучшую производительность скорость-мудрый и размер мудрый на z80, программы должны делать, как много локальных переменных, как разумно в статике. z88dk добавил много правил глазок специально для улучшения управляемости SDCC в статики и теперь в точке, где SDCC может генерировать примерно такой же код, как размер компилятора sccz80 z88dk, когда имеем дело с статике. До этого, SDCC был генерации кода на 10% больше, чем sccz80 почти все время и размер кода очень проблема при программировании на C на z80. Теперь это только порождает гораздо большую код для длинных и поплавков, которые менее важные случаи.

Скрытый текст

It's not that clear-cut. sdcc generates poor code when it comes to dealing with statics, longs and floats. sccz80 generates better code for those three cases. The statics case is very important because in order to get the best performance speed-wise and size-wise on the z80, programs should be making as many local variables as reasonable into statics. z88dk has added many peephole rules specifically to improve sdcc's handling of statics and it is now at a point where sdcc can generate approximately the same size code as z88dk's compiler sccz80 when dealing with statics. Before that, sdcc was generating code 10% larger than sccz80 almost all the time and code size is very much a problem when programming in C on the z80. Now it only generates much larger code for longs and floats which are less important cases.

[свернуть]

Единственное, SDCC действительно есть движение для него это единственный компилятор Z80 С, что близко к / пытается быть полностью соответствуют стандартам. Я считаю, это намного удобнее использовать для этой причине, и что функция, вероятно, очень важно для проекта, который переводит к C в качестве промежуточного шага.

Скрытый текст

The one thing sdcc does have going for it is it's the only z80 C compiler that is close to / attempting to be fully standards compliant. I do find it much more comfortable to use for that reason and that feature is going to be very important for a project that translates to C as an intermediate step.

[свернуть]

[shurik-ua]

когда дело доходит до контакта с статика, длинных и поплавков.

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

[Oleg N. Cher]

Okay, okay, you have convinced me, Alcoholics Anonymous! z88dk is very cool. You did a good work.

Хочу ещё за многоядерность и функциональное программирование сказать для msm. Как всегда Оберон впереди планеты всей - Юрг Гуткнехт, понимая направление развития железа, делает ОС A2/AOS/Bluebottle и многопоточный диалект Active Oberon, обладающий очень легковесными потоками, они намного легче тредов (нитей) и процессов Windows и fork UNIX/Linux - где-то ~ в 30 раз эффективнее, но цифру говорю наобум, если интересно - загуглите. Притом AO делается маленьким коллективом. Т.е. Оберон удалось легко перенацелить и применить для многопроцессорных систем, запараллеливание делается ядром системы и исходники, основанные на активных объектах, работают одинаково хорошо и на одном ядре CPU, и на 8-и. В случае с любимыми нами C++, C#, Java (я не знаю, насколько хорошо они готовы к большому количеству ядер и насколько трудно будет переписать существующие программы) - эти языки будут затачиваться на это огромными силами, и мы, как всегда, не имеем никакой возможности влиять на направление этого процесса, как всегда смутно догадываясь почему запад всё время нас опережает в технологиях и где тут собака зарыта. Но только лишь смутно.

ФЯ я особо не занимался, но с моей невысокой колокольни я не вижу особых ниш для их применений. Ядро ОС? Нет. Мобильные приложения? Тоже нет, там процы ещё слабоваты. Микрокотроллеры? Опять нет по той же причине. Веб-сайты? Нет. Прикладной софт для десктопов и ноутов для горизонтального рынка софта? Нет. Игры? Опять нет. Ну ладно, может быть частично, да. Выскоконагруженные сетевые сервера и веб-сервисы? Опять нет.

Барьер вхождения в ФЯ выше, чем в старое доброе императивное программирование. Ладно, может сейчас на ФЯ пишется много софта? Да нет же, хорошо если 1% от общей массы. Ниша эта - наука, главным образом. Так что рано ещё хоронить императивные языки, пожалуй.

Да, конечно я знаю про функциональные элементы, внедрённые в императивные языки. Но это языки большие. Оберон же маленький, юркий. И подходит для всех вышеперечисленных задач в той или иной (достаточно большой) степени.

[s_kosorev]

многопоточный диалект Active Oberon

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

Я я особо не занимался, но с моей невысокой колокольни я не вижу особых ниш для их применений. Ядро ОС? Нет. Мобильные приложения?

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

Веб-сайты? Нет.

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

Ладно, может сейчас на ФЯ пишется много софта?

тут не только ФЯ, методики ФП сейчас применяются вдоль и поперек

---------- Post added at 05:56 ---------- Previous post was at 05:55 ----------

применять можно где и обычные языки

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

---------- Post added at 05:57 ---------- Previous post was at 05:56 ----------

Барьер вхождения в ФЯ выше, чем в старое доброе императивное программирование.

ничего подобного

---------- Post added at 06:00 ---------- Previous post was at 05:57 ----------

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

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

---------- Post added at 06:01 ---------- Previous post was at 06:00 ----------

ыскоконагруженные сетевые сервера и веб-сервисы? Опять нет.

Это вообще самая целевая точка применения ФП

[Vitamin]

они намного легче тредов (нитей) и процессов Windows и fork UNIX/Linux

А что насчет тредов (нитей) в UNIX/Linux? А то какое-то кривое сравнение...

В случае с любимыми нами C++, C#, Java (я не знаю, насколько хорошо они готовы к большому количеству ядер и насколько трудно будет переписать существующие программы)

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

[msm]

Я бы поспорил относительно "впереди планеты всей". Сейчас в тренде далеко не многопоточность. Многопоточность в ЯП используется уже не один и не 2 десятка лет. Сейчас в тренде - параллелизм. Да и то, параллелизму тоже не один десяток лет. Параллелизм идет не только на уровне ядер процессора, но даже на уровне команд. SIMD инструкции массово появилисись еще в Pentium MMX, а скорее всего гораздо раньше. Вот только эффективно это все использовать не так то и просто. В видеокартах, в современных игрушках, параллелизм научились весьма эффективно использовать. В обычных приложениях параллелизм массовым пока не стал. И текущий передний край - это не многопоточность, а параллелизм. Параллелизм уже поддерживается языками программирования, всякие map, reduce, filter, scan из функционального программирования - как раз и решают задачи использования параллелизма в массовом обычном программировании. Но пока это все еще в зачаточном состоянии, хотя прогресс виден отчетливо.

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

Так вот, именно бейсик для ZX ужасен. С Си в принципе потягаться можно попытаться, я вполне допускаю что именно для ZX Оберон может подойти гораздо лучше. Так что если хочется что написать - можно попробовать сначала сделать на Обероне, а затем ручками оптимизировать узкие места на ассемблере. Может выйти неплохо, и я в принципе всеми руками за такое использование.

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

[Oleg N. Cher]

А что насчет тредов (нитей) в UNIX/Linux? А то какое-то кривое сравнение...

http://rsdn.ru/forum/design/816814.1

Кстати, вот (относительные) времена переключения контекстов процессов в Aos и в Linux

Aos 0.014
Linux 0.433

То есть, Aos-совские активные объекты работают в 30 раз быстрее чем если бы их эмулировали в Linux-е.

Вот ещё по теме ссылка: http://rbogatyrev.livejournal.com/9919.html

Не нужно мне задавать хитрых вопросов по многопоточности, я не специалист. За что купил - за то и продаю. Но замечу, что в отличии от Форта (на котором испытывали параллелизм на куче ядер), языка для железа, Оберон - язык для человека; он читаем.

Кстати, как в обычном обероне с многопоточностью?

Что значит "в обычном"? Какой-то кривой вопрос.

Оберон и Оберон-2 на уровне языка не предлагают никаких средств для многопоточности, оставляя это на откуп среде исполнения и библиотекам. Ровно также как C и C++. Это значит, что в среде Windows можно использовать механизмы, предлагаемые WinApi, в среде Linux свои и т.д.

Что касается диалектов, которые претендуют, так сказать, на "промышленное применение".

В Active Oberon - хорошо, для того и создавался.

В BlackBox можно так:

Параллельное программирование на языке Component Pascal – подсистема времени выполнения Active BlackBox

GPCP вообще поверх JVM и .NET, поэтому унаследовал их модель и механизмы.

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

И.Е.Ермаков. О преимуществах кооперативной многозадачности

Напомню, Оберон - не промышленный язык и мало освоен. Поэтому брызгаться слюной как бы нет смысла. Кроме того, вы не представляете до чего сложно стыковать простые вещи со сложными чтобы получилось просто. Как использую Оберон я? Да просто пытаюсь делать на нём то, что уже сделано на Си или Дельфи - к винапи пристыковываюсь и т.д. В этом Оберон всегда будет отставать. Но изначально ETH Oberon создавался для решения задач малыми коллективами - и как можно более просто, хотя и непривычно. Текстовый интерфейс - развитие архаичной командной строки. И т.д. И, как по мне, это лучшее развитие программирования, чем подменять простые понятия сложными - итераторами, ленивыми вычислениями, "более эффективными" (Вы это сами проверяли?)