Оберон-клуб «ВЄДАsoft»

Твердыня модульных языков
Текущее время: 28 мар 2024, 14:55

Часовой пояс: UTC + 2 часа




Начать новую тему Ответить на тему  [ Сообщений: 5 ] 
Автор Сообщение
СообщениеДобавлено: 08 янв 2014, 23:04 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
geniepro писал(а):
Если новичок в программировании изучает оберон, то он просто даже и понять не сможет, чего он лишается, и будет плодить говнокод -- нетипизированные константы вместо перечислений, иерархии записей или прямо работу с адресами в памяти вместо цивилизованных объединений.
Для начала я хотел бы увидеть новичка, который знает только Оберон и более ничего другого. Но раз уж такая забота о новичках пошла, посмотрим что может предложить мэйнстрим вообще и geniepro в частности бедному новичку, который хочет научиться программировать. Оберон не подойдёт, потому что в нём нету объединений и перечислений. ;)

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

У меня хорошая новость для geniepro. В Компонентном Паскале (в реализации BlackBox) есть объединения (тег записей [union]), которые реализованы так как это и нужно. А именно как низкоуровневое средство, которому место в системных модулях и биндингах. На прикладном же уровне вместо объединений предлагается более мощный и совершенный механизм — расширяемые записи. И это весьма правильно. Вообще же подход к отделению мух от котлет системного и несистемного в Оберон-языках потрясающий. В Си, Дельфи это более чем размазано, в Обероне же чётко.

Сам факт наличия объединений в КП/ББ подтверждает мой тезис о том, что добавить фичу в Оберон легко. Гораздо труднее убрать из языка рудимент (типа объединений), заменив его более мощной и высокоуровневой абстракцией, не вызвав при этом гнева тех, кто к этой фишке привык. Пока что все языки движутся по пути утолщения, пожалуй, кроме Оберона (в реинкарнации 07). Он весьма худеет, иногда диета ему даже не на пользу, но доктора Вирта это не смущает. Он понимает насколько просто язык обфичить и насколько сложнее его урезать.

Что же предлагает новичку, который желает стать программистом, наш добрый мэйнстрим? Сперва мэйнстрим говорит новичку, что быть "программистом ваще" у него не получится. Надо быть программистом чего-то и для чего-то. Если ты веб-мастер, то будь любезен освоить одни технологии. Если же разработчик игр под смартфоны, будь любезен — тебе в другую сторону. Далее. Мэйнстрим говорит, что для разработки под десктопы не обойтись без C#. Виндовз 8, дотнет, готовые компоненты, многоязычный подход торчащий, правда, из-под одного каблука — необходимы. Для планшетов и смартов недурно бы освоить Objective C и Java, тоже пригодится. Для сайтов надо всенепременно изучить хотя бы Lamp (Linux - Apache - MySQL - PHP). Си нужен как основа UNIX/Linux (ура! свобода от коммерсантов ;) ) и неувядающая (ну почти) классика, ну просто чтобы не обесценивать историю. А для широты кругозора необходим хотя бы один язык ФП, пусть это будет Хаскел, не возражаем. Что подумает бедный новичок, когда столкнётся с такой фрагментацией, фрагментацией и ещё раз фрагментацией? Он-то хочет быть программистом! Разноразработчиком. Универсалом, чтобы всё уметь. А не три года учиться забивать гвоздь в доску, и потом только узнать, что умеет работать только с одним форматом досок и с одним форматом гвоздей и только от одного производителя ;) Но тут понимает, что ему таки придётся стать гиком-очкариком, убив на всё это годы и годы жизни. Только не забыть бы ему сказать, что лет через 10-15 ему будет крайне желательно забыть всю эту муть, а то она, видите ли, согласно "парадоксу Блаба" будет стоять колом в голове и мешать воспринимать новые сверхпрогрессивнейшие парадигмы, о которых мы сегодня и мечтать не смеем. ;) И, заметьте, после освоения всего этого у новичка будет не просто говнокод от отсутствия перечислений. Да он вообще вкус к жизни потеряет, при этом даже не поняв что такое модульность.

Думаете, я утрирую? А ничуть. Дайте определение самого важного что есть в программировании — модульности и её свойств. Из чего нам строить кубики — понятно, из языков программирования. Но что такое кубик — никто точно не знает, интуитивно чувствуют что это часть чего-то общего, но не более (А где стандарты? Чем занимаются комитеты по стандартизации, помимо всякой блажи? Почему они не застандартизировали самое основное?). И у нас кубиков таких уже много, построенных сверху карточного домика и в середине доминошной дорожки. Разного размера, цвета, формы, запаха, вкуса и т.д. Строить из них — невозможно. Если бы такие кубики показали строителю, он бы застрелился сразу.

Обероновская же модульность — сбалансированный эталон, независимый от платформы и чётко отвечающий на вопросы что такое модуль, что такое объект и что такое процедура и т.д. И эти определения компактны, что крайне необходимо, чтобы стыковать разнородные средства. И Оберон-технологии прекрасно с этим справляются, проверено.

В краткосрочной перспективе, чтобы новичок готовил себя к лучшей жизни в роли затычки для законодателей мод мэйнстрима, новичку ничего не остаётся, кроме пути, обозначенного выше. Впрочем, он может ограничиться только Lamp и сайтами. Потом флэш прибавит, и будет уверенный специалист. Многие так делают. И ничего, живут, вроде даже довольны. Или ограничиться C# на практике, Адой в теории и Хаскелом чтобы тешить чувство прекрасного. ;)

Что предложит geniepro? А вот что.
geniepro писал(а):
Ну, тут мне особо нечего предложить, это правда.
Самым качественным универсальным императивным языком я считаю Аду, но по своей работе предпочитаю С# -- при его недостатках он, в принципе, вполне устраивает, учитывая что мне приходится не в одиночку программы писать. Аду мало кто знает, а учить что-то новое -- ещё меньше кто хочет, увы...
"Аду люблю, Хаскел целую, а работать приходится всё равно на C#"? ;) Знаю. Ты предложил бы C# и Хаскел. Так сказать, для широты кругозора. Но оба они неидеальны и не универсальны. Даже, я бы сказал, не всепроникающи. И не избавляют от необходимости осваивать что-то ещё. Но новичка будет сбивать с толку двуязычие, это точно (проверено практикой). Или мы предложим ему использовать модульность Модулы, рандеву Ады, перечисления цэ шарпа и систему типов Хаскела? Ты только не советуй жену так выбирать, а то "нравятся губки от одной, глазки от другой, ножки от третьей. Но где эта женщина есть целиком?" ;)

Дикий мир фрагментации. Мы пишем не программу и не компонент. Мы пишем "программу под ту-то версию той-то системы" и компонент "для того-то языка с той-то версией библиотеки". Мы так погрязли в этом, что новички даже не представляют себе глубину этого падения. Им трудно объяснить, что на винапи цветная точечка ставится так, а на Андроиде эдак. И даже не на одном языке. И даже не одним способом. А черти его знают как, и, более того, ни один чёрт не знает как это будет завтра.

Это всё краткосрочная перспектива. Надо затыкать дыры сегодня. Надо затыкать их буквально вчера. Код, который надо писать, через неделю, месяц или год потеряет свою цену, потому что сменится среда разработки, язык, версия библиотеки или ОС. Никого не интересует код, который мог бы не устареть. Если ты пишешь игру, ты пишешь её для чего-то и подо что-то. Он "Сибирь" Сокаля вышла для Андроида. Планшетоносцам это хиханьки, только программисты понимают насколько трудно было сделать фактически техническую работу — перенести готовую игру на готовую платформу. Если я хочу писать код так, чтобы он работал через 20 лет, у меня просто нет никакого выхода. Только Оберон. Потому что я не знаю какие языки, парадигмы и платформы будут нам подсовывать завтра. И я предлагаю Оберон не потому что сделал его поддержку для любимой ретроплатформы, а потому что уверен, что новичок, который начнёт с Оберона и напишет игру, сможет, став матёрым оберонщиком, реализовать Оберон-среду для любой платформы, для которой понадобится. И развернуть там свой вечный код. Проверено лично, мин нет.

Так что же важнее — отсутствие объединений (которые вообще низкоуровневое средство) или таки простота и широта применимости?

Представим на миг. Приходит geniepro в магазин электротоваров розетку купить. И видит сто моделей розеток и хитрых продавцов, которые шныряю вокруг. Один подходит и говорит хитренько так: "я закончил тут трёхмесячные курсы палачей, море удовольствия, море! Если бы не проклятый "парадокс Блаба", то все бы поняли эту парадигму. Так что розетку надо брать обязательно ту, у которой отдельный канал для подключения электрического стула, всенепременно, да! Мой вам совет, не пожалеете! Остальные уроды, нет, не понимают экспрессии, туповаты-с".

Всё-таки что важнее? Канал под электрический стул или возможность отремонтировать розетку самому, когда сломается? Или нужно сверхсложную суперрозетку, которая сама умеет соединяться с интернетом и варит кофе? А ведь интерфейсы должны быть простыми. Посмотрите на интуитивно понятный и универсальный интерфейс вскармливания грудного ребёнка. Ещё никто не жаловался, всем подходит. ;) Это к вопросу как соединять наработки на разных языках, уменьшая фрагментацию. Господь же сам подсказывает — делайте всё просто и единостильно, соединяется всё со всем на ура, вскармливание происходит. ;) Более того, такой интерфейс даже не только детям нравится. ;) Прям как модульность Оберона. Не только совершенная, но и простая. И не нужно отдельно ООП плодить. Только вот если добавить перечисления — модульность уже усложнится. Надо будет как-то поддерживать эту фичу во всех языках, которые будут заявлены для поддержки этого подхода (единый стиль розеток). Так чего удивляться доминированию процедурных и ОО-интерфейсов? Но в ОО вообще мрак, до общего определения что такое объект ещё не все доросли. Каждый лепит своё и называет ОО. Тут тебе и конструкторы, и деструкторы, и множественное наследование, и дружественный класс, и исключения. А их в самом компоненте обрабатывать или вынести на уровень выше? Как тогда стыковать с другими языками? А что такое вообще объект, ну или ладно, класс и каковы его свойства? Это понятие застандартизировано? Приняты минимальные, средние и сверхбольшие требования к ОО-классам? Может хотя бы в процедурном вопросе всё ништяк? А не тут-то было. Помимо просто процедур у нас ещё есть процедуры с переменным числом параметров, модели вызова, вынесенный в отдельный биндинг хидер и — упс — от розетки уже потянуло запахом кофе, шипением электрического стула и пространство огласилось криками. Где в этом вопросе баланс между простым и сложным, господа? Вопрос был риторический, ибо выбор ясен. По крайней мере, с моей стороны. :D

Что предлагаю я новичку в качестве долгосрочной перспективы.

Дорогие друзья новички. Вам обязательно начнут рвать мозг на части и рисовать прелести сложности. На самом деле всё очень сложно, особенно выбрать правильный первый язык. Сам я знаю их много, но не все из них одинаково полезны. Мой список из двух языков:

  1. Компонентный Паскаль (и вся Оберон-парадигма, по возможности)
  2. Пролог

Выбрав КП, я получил во-первых мощнейший аппарат модульности, не имеющий аналога в других языках (самый приближённый вариант реализован в Delphi и FreePascal, но по сравнению с обероновским у него есть недостатки!). А это средство, прямо помогающее делать программы из кубиков, и эти кубики достаточно универсальны (а вовсе не узкопривязаны). Сегодня имеющимися готовыми средствами вы сможете разрабатывать компоненты и модули как для Java-платформы (Java, Jme, Android), так и для .NET, не останется закрытой от вас и родная (нативная) разработка программ для разных платформ, и веб-программирование, и системное программирование. И надёжность ваших программ при этом будет повыше, чем у "сионистов" и "пасквилянтов". Да за модульность Оберон-парадигме можно простить почти все недостатки, которые в ней же и легче всего исправить, что вы постепенно научитесь делать, улучшая и обживая это пространство. Оно привлекательно. При всей груде макулатуры в других областях здесь я нахожу потрясающие мысли и идеи, подпитываюсь, по новому осознаю некоторые вещи. В общем, путь не для тех, кто любит ходить строем. Путь ищущих и творящих. Может как раз малочисленность оберонщиков и даёт им шанс быть в сторонке от этих гонок почём зря и куда попало. Конечно Оберон не решит всех проблем, особенно сегодня, но оставить свой след вы в нём сможете, новички, будущие программисты.

Почему Пролог? Это необязательный пункт. Просто для общего развития. Очень интересный способ для накопления и обработки данных, который позволяет описать их взаимоотношения и взаимодействие. Интересно. Даже как сам подход оцениваю его сильно круче, чем SQL, XML, БД и даже файлы. За этим будущее. Я, вероятно, подтянусь к данному подходу тоже, когда сделаю на КП свою реализацию. Если жизни хватит. ;)


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 09 янв 2014, 12:06 
Не в сети

Сообщения: 203
Zorko писал(а):
У меня хорошая новость для geniepro. В Компонентном Паскале (в реализации BlackBox) есть объединения (тег записей [union]), которые реализованы так как это и нужно.
Вот только они не описаны в сообщении о языке. И получается vendor lock -- привязка к конкретному компилятору конкретного производителя. Хочешь перейти на другой компилятор? А там нету этих недокументированных расширений из КП/ББ!!!

Zorko писал(а):
Сам факт наличия объединений в КП/ББ подтверждает мой тезис о том, что добавить фичу в Оберон легко.
И легко получить новый несовместимый диалект. И это ты предлагаешь после стенаний о том что программеры не могут договориться между собой, в отличие от электриков...

Zorko писал(а):
Или мы предложим ему использовать модульность Модулы, рандеву Ады, перечисления цэ шарпа и систему типов Хаскела?
Ну конкретно по этим пунктам: модульность Модулы и Оберона уступает по полезности модульности Ады, перечисления в Аде тоже есть, так что можно ограничиться Адой и Хаскеллом )))

Zorko писал(а):
Дикий мир фрагментации.
И ты предлагаешь его фрагментировать ещё больше, заставляя программистов переделывать компилятор когда им понадобится новое полезное средство. Fixed.

Zorko писал(а):
Если я хочу писать код так, чтобы он работал через 20 лет, у меня просто нет никакого выхода. Только Оберон. Потому что я не знаю какие языки, парадигмы и платформы будут нам подсовывать завтра.
Печально, что я могу сказать. Тогда узнай о том, что до сих пор используется софт, которому десятки лет, написанный на Коболе и Фортране... ))

Zorko писал(а):
И я предлагаю Оберон не потому что сделал его поддержку для любимой ретроплатформы, а потому что уверен, что новичок, который начнёт с Оберона и напишет игру, сможет, став матёрым оберонщиком, реализовать Оберон-среду для любой платформы, для которой понадобится. И развернуть там свой вечный код. Проверено лично, мин нет.
Возникает вопрос. Почему же до сих пор никто так и не удосужился портировать тот же любимый тобою КП/ББ на линукс или хотя бы Win x86-64? Ведь это так просто, мин нет...

Zorko писал(а):
Так что же важнее — отсутствие объединений (которые вообще низкоуровневое средство) или таки простота и широта применимости?
Простота -- хуже воровства.
Оберон -- язык, который оказался слишком простым.

Zorko писал(а):
Представим на миг. Приходит geniepro в магазин электротоваров розетку купить. И видит сто моделей розеток и хитрых продавцов, которые шныряю вокруг.
Если серьёзно, то тех же разновидностей розеток и разъёмов в электронике и электротехнике куда больше чем сто. Возможно, даже на порядок больше...

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

Zorko писал(а):
Почему Пролог? Это необязательный пункт. Просто для общего развития. Очень интересный способ для накопления и обработки данных, который позволяет описать их взаимоотношения и взаимодействие. Интересно. Даже как сам подход оцениваю его сильно круче, чем SQL, XML, БД и даже файлы. За этим будущее. Я, вероятно, подтянусь к данному подходу тоже, когда сделаю на КП свою реализацию. Если жизни хватит. ;)
А зачем тебе тратить время на то, что бы сделать свою реализацию пролога на КП? Ведь есть куча готовых реализаций, которые наверняка надёжнее и быстрее, чем твоя возможная в будущем реализация на КП.
А если ты имел в виду, что хочешь иметь пролого-подобный движок для КП в виде библиотеки, то такие движки давно уже есть и для других языков, для тех же лиспов и хаскелей...

В-общем, чудес не бывает, в них только верующие веруют )))


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 10 янв 2014, 10:28 
Не в сети
Аватара пользователя

Сообщения: 65
geniepro писал(а):
Возникает вопрос. Почему же до сих пор никто так и не удосужился портировать тот же любимый тобою КП/ББ на линукс или хотя бы Win x86-64? Ведь это так просто, мин нет...
Это куда проще, чем даже кажется. На самом деле.

geniepro писал(а):
Простота -- хуже воровства.
Оберон -- язык, который оказался слишком простым.
Неверно понимаемая простота Оберона даёт обширное поле для троллинга.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 29 янв 2014, 10:24 
Не в сети

Сообщения: 25
Zorko в viewtopic.php?p=988#p988 писал(а):
... Мой список из двух языков:
  1. Компонентный Паскаль (и вся Оберон-парадигма, по возможности)
  2. Пролог
...
Вы не одиноки:
Влад Жаринов в http://oberspace.dyndns.org/index.php/t ... ml#msg7828 писал(а):
...
И в общем - язык программирования систем д.б. не только императивным? Например, нужно иметь реализации "чего-то типа Оберона" и "чего-то типа SQL"?..
Да... + логические языки...
...
- только у Усова, насколько можно понять, подразумевается реальное применение неимператива в работе над программными системами. Для моделирования системы в предметной области вроде как. Ваше понимание применения Пролога, кстати, встречал в некоторых работах по программированию учебной среды...


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 29 янв 2014, 11:27 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Влад, моё понимание Пролога — сугубо восхищение дилетанта, который читал, немного юзал и оценил подход, но всё-таки не вникал серьёзно. Трындёж, короче говоря. ;)

Но вызывает уважение сам посыл Пролога. Вместо всё более изощрённого кодирования предлагается что часть работы по накоплению и классификации данных будет делать механизм логического вывода. А я всегда мечтал о программе "Домашний электронный секретарь", которая будет понимать не элементарные клики мышью по кнопкам, а более интеллектуальные речевые команды-задания (заказать товар, сделать платёж, найти статью, запустить музыку, посмотреть какая завтра погода, напомнить о дне рождения и т.д.). Шаг от кучи программ к единой среде исполнения заданий. Пролог — шаг в этом направлении. Но шагов таких предстоит сделать ещё много, особенно с учётом того, что Windows, Linux, MacOS да и Android двигаются не в этом направлении, а в более традиционном клико-мыше-сенсорном.

Идея встраиваемых языков стара как мир. В BASIC для ZX Spectrum (~198x-е) был встроен оператор PLAY, который позволяет закодировать многоголосую мелодию для музыкального сопроцессора в текстовой строке. Подобным же образом можно встраивать дополнительные (например, функциональные) средства, например, в Оберон.

Так что в основе всё равно императив. А поверх уже нанизываем чего требуется.


Вернуться к началу
 Профиль  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 5 ] 

Часовой пояс: UTC + 2 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
© VEDAsoft Oberon Club