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

[AlexG]

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

А кто Вам сказал что ОБЯЗАТЕЛЬНО надо "Монады, например. Паттерн матчинг. И тому подобное." и еже с ними в корячивать в разные языки программирования. У каждого языка своя сфера применения. ровно как и у каждой методики программирования своя сфера.
Как применит (к примеру "Монады") к реализации UDP-протокола ?
То что хорошо для работы с базами данных - не работает с алгоритмом управления лампочкой в подъезде.

[msm]

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

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

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

А управлять лампочкой в подъезде не составляет даже в машинных кодах, это ИМХО не ниша вообще, здесь в большинстве случаев даже микропроцессор будет не нужен.

[AlexG]

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

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

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

А управлять лампочкой в подъезде не составляет даже в машинных кодах, это ИМХО не ниша вообще, здесь в большинстве случаев даже микропроцессор будет не нужен.

Из этих речей следует "каждому сверчку свой шесток". Любой язык имеет право на существование. И быть ОПТИМАЛЬНЫМ для своего назначения. так что расслабитесь и не "впаривайте" "свои парадигмы" во все щели. ПС: любой язык ("высокого уровня") изначально реализуем только через язык самого вычислительного устройства (процессор "ассемблер") - это аксиома. Я даже спорить и доказывать не буду.

[Oleg N. Cher]

В общем, предлагаю схлестнуть наши компиляторы (XDev и ZX Like Pascal) лоб в лоб, тесты прогнать на целочисленных переменных и массивах. Посмотреть качество кодогенерации.

Для компании можно взять z88dk еще.

Это безусловно полезное предложение. Вот только наверно логично будет брать не ZXDev, а сразу SDCC?

Sergey, HiTech C v3.09 - последняя доступная версия? Как его юзать - из под эмуля Profi с CP/M или можно под каким-то эмулятором CP/M?

( что-то мне с трудом верится, что компилятор 80-х годов, занимающий пару десятков Кб, обойдёт SDCC по плотности кода )

---------- Post added at 14:00 ---------- Previous post was at 13:52 ----------

Как там с библиотеками в Обероне?

Знаете, слабенько. Многие библиотеки (например, для работы с XML или VisualOberon для GUI) есть только для отдельных реализаций Оберона, ибо используют местные расширения. Я же говорю - писать некому, сообщество маленькое.

Можно ли на Обероне реализовать современные концепции с приятным синтаксисом?

Смотря что считать приятным. Но будет громоздко, да. И без кучи фигуристых скобок, которые уже не одно поколение программеров считает неизменным атрибутом приятного синтаксиса. Если углубиться в это, то в Обероне нет конкатенации (в КП есть). Приходится писать:

String.Concat( String.Concat(a, b) , c);

И, вероятно, это будет ваш приговор громозкости синтаксиса Оберона. А он просто простой язык.

Монады, например. Паттерн матчинг.

Не скажу за патерн матчинг - не знаю, что это такое. Если бы сказали по-русски - может я бы понял. Но вот взять декларативный язык запросов к БД - SQL. Его не встраивают в другие языки на уровне синтаксиса. Зачем. Просто работают с ним из библиотек. Это как раз и есть Оберон-вей. В том числе и всякую функциональщину с лямбдами можно так реализовать, если потребуется.

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

[s_kosorev]

String.Concat( String.Concat(a, b) , c);

для чистых строк можно и покороче записать a+b+c, зато если a,b,c массив или коллекция строк, уже гораздо лаконичней получается.

---------- Post added at 16:42 ---------- Previous post was at 16:40 ----------

Его не встраивают в другие языки на уровне синтаксиса. Зачем. Просто работают с ним из библиотек.

Минимум 2 языка знаю где встраивают X++ и linq в C#

[Sergey]

Sergey, HiTech C v3.09 - последняя доступная версия? Как его юзать - из под эмуля Profi с CP/M или можно под каким-то эмулятором CP/M?

последняя. Официально свободная. работает из под эмуля для DOS (командная строка Windows).

( что-то мне с трудом верится, что компилятор 80-х годов, занимающий пару десятков Кб, обойдёт SDCC по плотности кода )

c версией 3.5 почти не сравнивал, а SDCC v3.4 нервно курит в сторонке.

[s_kosorev]

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

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

[Oleg N. Cher]

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

Я тут нагуглил, что для Active Oberon есть компилятор PACO. Расшифровывается Parallel Compiler. Так что всё-таки наверное в AO параллелизм, а не просто многопоточность?

Также на форуме Oberoncore людям удалось запустить параллельные вычисления в среде BlackBox на многокластерной и многоядерной машине - через какую-то готовую библиотеку для этого.

Господа, у вас слово Оберон вызывает какие ассоциации? У Vitamin'а - наверное хочется прибить Oleg N. Cher'а Слово Java вызывает у американцев приятные воспоминания о вкусе кофе, а у меня почему-то образ загорелой красавицы легко одетой, но это так, отступление. Маркетолог сказал бы, что Оберон распространяется плохо из-за неверной маркетинговой стратегии, и конечно же был бы прав.

Вы читали какие-нить произведения в жанре киберпанк? Там обычно хакеры-одиночки "ангелы", которые иногда собираются в группы, чтобы что-нить похачить, противостоят мега-корпорациям. Так вот я бы не хотел такого мрачного будущего для всех нас. Однако сравнивать возможности корпораций и одиночек - это вообще неправильно. Путь эволюции программера-одиночки в руках его самого. А корпорации всегда требуют играть по их правилам (писать на чём скажут). Оберон - язык не для корпораций. Даже если вдруг корпорация займётся им - она перекроит его до неузнаваемости. Рассматривайте проект XDev как попытку переосмыслить программирование на доступном для средних способностей индивида уровне. Без претензий на паттерн-матчинг.

В 2000-м году я, программист средних способностей и ниже средней производительности, знал приблизительно 25 ЯП (мог работать на них) и как минимум о 50 имел представление. Но по мере того как время шло и новые языки появлялись, мне всё это нравилось всё меньше и меньше. Да, каждый новый язык нёс что-то новое, иначе зачем бы он появлялся. Но программисты как шкафы - покрываются молью и становятся архаичными. Какого-то древнего фортранщика не впечатлишь паттерн-матчингом, если он даже вкурит что это такое. Я захотел остановиться на одном языке, но который удовлетворял бы всем моим требованиям. И я выбрал его осмысленно и взял со всеми его недостатками. Ну и пилю щас потихоньку свой идеальный велосипед. Однако в случае С. Свердлова - это не просто программист с очень оригинальным мировоззрением. Это человек академических кругов, который смог донести свои оригинальные идеи до других влиятельных дяденек, занимающих посты. А это наверно неспроста. И пусть у нас с образованием не так хорошо как в штатах, но книга у него получилась прекрасная. Не про паттерн-матчинг конечно. Про методы трансляции. Будет полезна любому писателю компиляторов.

Что такое по своим качествам язык Оберон в ряду остальных?

Ф. В. Ткачёв когда-то показывал его место на плоскости из двух осей: быстродействие (=комплируемость) и гибкость (расширяемость).

Часть языков группируются вдоль первой оси, часть - вдоль второй (динамические языки) - и очень мало - в верхнем правом углу. Как пример проблемы - постоянная гибридизация пар языков, допустим, в игрострое или системных задачах, или "научке" - одного быстрого для ресурсоёмкой части (С++, например) и второго, удобного для скриптования и интерактивной работы (Python, Lua, Юникс-скрипты всяческие - тот Python, TCL/Tk, Shell). Оберон оказывается именно в этом углу. Спорный вопрос - кто там ещё и насколько сопоставим, но что таких немного - это понятно. Те же Java и C# сейчас обыгрывают Оберон по быстродействию только за счёт эффективных новых реализаций и отсутствия инвестиций в современные компиляторы Оберона. Обыгрывают с супер-сложными рантаймами, нивелирующими их языковые проблемы (типа только динамических структур и т.п.). Если же считать одной из составляющих гибкости-расширяемости не только рефлексию и динамическое связывание компонент - а ещё и общую простоту... Ведь что легче сопровождать и развивать, на протяжении двух-трёх десятков лет? И для написания сиюминутного "клея" что легче использовать (если человек берётся за программу раз в полгода - что ему легче вспомнить?)

Я бы выделил для выяснения места Оберона в ИТ-экосистеме другие 3 оси:

Простота - жёсткость - расширяемость.

Жёсткость - в смысле возможности создать статически проверяемый "каркас жёсткости" для программы. Как приятное следствие - возможность разрабатывать "почти готовое ПО" без обильного покрытия тестами каждого мелкого кубика.

Трудно найти много соседей Оберону в верхнем дальнем углу этих трёх осей.

Жёсткость - расширяемость: Ada, C#, Java, Haskell

Простота - жёсткость: ну, это скорее к языкам прошлого поколения (Modula-2, старый Pascal, нераздутый Fortran в некоторой мере, наверное...)

Простота-расширяемость: Лиспы всякие, Луа и прочие.

А всё вместе? Только что-то близкое, та же Modula-3. Может быть, нечто из компактного статически типизированного компилируемого функционального (OCaml какой-нибудь?).

Далее, недавно отвечал для себя на вопрос о различиях между той же Modula-3 и КП. Modula-3 нравится и на "оторванный от конкретики", чисто эстетический взгляд может смотреться более гармоничной. Однако что-то где-то лично меня напрягает. Как с теми же перечислимыми типами и проч.: вроде, для инженера и "эстетично, надёжно" и т.п. Но... Потом сформулировал своё ощущение: это уже попытка дать какие-то базовые вещи, полезные для предметных областей, для выражения семантики задачи. Но это скользкий путь - ибо задачи столь многообразны, что любые такие кубики быстро начинают жать (кому-то ещё и единицы измерения нужно контролировать - и чем больше зарываешься, тем более многообразия. Единицы измерения же контролировать можно уже с таким количеством нюансов, что не сделаешь заранее ничего, пригодного для широкого круга задач). Отсюда становимся на путь не определять в языке, а давать определять части языка динамически - и получаем взрыв безумия типа Nemerle и ко. Таким образом, имеет смысл вообще исключить из языка всё, сколь-нибудь ориентированное на прикладную специфику. А оставить языку 3 функции: 1) классно абстрагировать от физической машины, при этом оставляя полную прозрачность в отображении на императивный вычислитель; 2) давать "рёбра жёсткости" - средства статического контроля, позволяющие отсеять процентов 80 наиболее досаждающих ошибок, не гоняясь за каждой остальной мелочью, коих туча разных. Не нужно думать, что от контроля прикладной семантики мы отказываемся. Всегда есть возможность заложить уже свои рёбра жёсткости в фреймворках, чтобы уже защитить себя от каких-то нарушений прикладной семантики. 3) Давать средства расширения (полиморфизм и динамическое связывание), пригодных для безболезненного включения в систему компонентов, неизвестных на этапе её создания. Эти 3 функции в точности и оставлены в том же КП. При этом КП расширен над Обероном только по линии этих 3 функций, никаких "реверансов" в сторону прикладной семантики.

Читать дальше

[Oleg N. Cher]

И вот с этой позиции, которую я горячо поддерживаю, внедрение SQL прям на уровне синтаксиса языка выглядит реверансом в сторону прикладной семантики. Что является во-первых переусложнением, во-вторых слишком неоправданно за счёт узкой специфики применения, ну и в-третьих является большим препятствием для мультитаргетности - SQL-сервер вряд ли будет непременным атрибутом микроконтроллера; а стандарт языка - требует; это похоже на привязку старинного TurboPascal к PC-шной консоли - непременно 80x25 и непременно 16 цветов. В эпоху ДОС такое прокатило, сегодня это неактуально. Более того, если пойти дальше, то следует включить в язык и регулярные выражения, и работу с XML, и поддержку различных кодировок текста, и меры длины и веса, и многозадачность и ещё очень и очень многое. Получим монстра, обладающего ещё одним недостатком, помимо сложности - это будет реализация многозадачности только одним способом. Работа с регулярными выражениями - только одним способом. И так далее. Ну а расширяемые языки на практике не обладают рёбрами жёсткости - на том же Форте можно писать так, что без знания специфики словарей в коде не разберёшься.

Впрочем, Обероны присматриваются к расширяемости. В ETH Oberon, например, есть перегрузка операторов. Поэтому встроить конкатенацию привычным способом - можно. И лямбды наверное тоже, просто я не пробовал.

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

Интерпретатор Оберона на Go. Познавательно.

[Vitamin]

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