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

Твердыня модульных языков
Текущее время: 29 мар 2024, 01:34

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




Начать новую тему Ответить на тему  [ Сообщений: 8 ] 
Автор Сообщение
 Заголовок сообщения: Резон появления и смысл среды XDev
СообщениеДобавлено: 18 дек 2013, 01:59 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
(Заранее прошу извинить за некоторую сумбурность изложения. Здесь также использованы фрагменты из моей переписки с Хоботом)

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

Взять, например, очередного кандидата на всемассовость — Android. Он даже на десктопы целится. А являет собой добрую подборку проверенных и очень массовых технологий: ядро Linux, библиотеки libc, OpenGL, zlib, SQLite, языки программирования Java, Си и C++, язык разметки XML. Вобщем, не поспоришь. Но барьер вхождения, как по мне, чрезвычайно высок, потому что для профессиональной разработки нужно владеть всем этим добром на чрезвычайно высоком уровне. Здесь дело не в том, что “профи должен владеть всем этим”, здесь дело в том, что набор “этого” через 10-15 лет окажется совсем другим, и профи-гонщик мэйнстрима будет очень бледно себя чувствовать в попытках за всем этим угнаться.

Всё это происходило и раньше, но в гораздо более скромных масштабах. Отчётливо помню время, когда никто даже не задумывался, что на рынке карманных ПК доминировать будет не PalmOS и не Pocket PC, и даже не Symbian, а какой-то Android. Сегодня вобщем-то тоже сложновато предсказать что будет лет через двадцать, но хочется быть во всеоружии, не растеряв всех сил в попытках угнаться за мэйнстримом. В конце концов, сколько можно делать всё те же старые вещи всё более новыми способами. Мне хотелось бы запрограммировать свой планшет на ТурбоПаскале с чрезвычайно низким, как по мне, барьером вхождения. И не нужны мне шаблоны и алгебраические типы, как-нибудь проживу и без них. Совершенно солидарен с высказыванием Last_Alien'а: "Красоты типов нужны только любителям этих красот. Практически нужен хороший язык без излишеств, на котором можно писать не задумываясь о том, какие иероглифы применять. Просто буквы. И чем этих букв меньше, тем меньше отвлекаешься от того что собственно хотел написать."

Итак, что в итоге рисуется. Не чрезвычайно сложный процесс разработки, при котором для создания хелоуворлда нужно знать XML, Java, Android, ООП и ещё тучу всего, а это ж багаж! Душа вопит о возможности писать хотя бы простые проги более простыми средствами, но не тут-то было. Android обфичивается с бешеной скоростью, разработчики еле успевают узнавать новые фишки. Как мы дошли до жизни такой? Темпы взяты столь суровые, что мозг закипает. Вспомните строительные технологии. Гвоздь он и есть гвоздь, и триста лет назад. А бедный ТурбоПаскаль, видите ли, устарел, потому что некие дяди изобрели шаблоны, а другие дяди до сих пор пытаются в них разобраться, плодя, кстати, тонны говнокода. Не без этого.

Ситуация мне видится такой. Когда появились микрокомпьютеры поменьше шкафов — для них сразу начали изобретать интерактивные языки, вшиваемые в ПЗУ, что-то вроде вариаций бейсика. Как самостоятельное нечто эти языки совершенно не имеют ценности, они использовались только благодаря доступности — как способ добраться до возможностей машинок и решать свои задачи. Но из концепта этих "вшитых" языков (BASIC, FOCAL) постепенно сформировались такие монстры как Visual Basic, с той же заточкой на платформу (уже MS Windows). Я нащупал другой путь. А конкретно — основываться не на аппаратной платформе и её особенностях, с "вшитыми" языками, которые появляются почти каждый месяц, но чаще всего ничего интересного из себя не представляют, а основаться на компактном высокоуровневом языке, который не вырос из платформенных особенностей, но из вполне конкретных математических и информационных исследований. Этот язык уже представляет собою кое-что вне контекста отдельно взятой конкретной платформы. Уже понятно, что я про Оберон. И Оберон здесь можно сам рассматривать как платформу. Только не железячную, а языковую.

Платформ много, языков много, разрабатывать под платформу X нормально и без извращений можно часто только на языке Y, что кому-то крайне на руку. Окучиваются новые информационные поля, подрастает поколение любителей сишарпа, которое теряет понимание универсальных средств разработки вместо узкоспециализированных. Хочешь, дядя, программить под платформу X? Учи язык Y. Хочешь программить под X2 ? Учи Y2. И т.д. Т.е. дядя программер, учи миллион языков, тонны интерфейсов и кучу платформенных особенностей. И никто, вовсе никто не даст тебе гарантию, что завтра все эти твои знания будут ещё в цене, потому что предсказать, что будет через десяток лет в этом деле, — практически невозможно. Так что надо сыграть в рулетку. Делайте свои ставки, господа. Ставки сделаны, ставок больше нет. Надо учить, господа вечные студенты и тяжеловесы малоподъёмного мэйнстрима. Учите шарпы и надейтесь пристроиться на работу к поклонникам ms. Или учите Java, на кусочек хлеба авось заработаете. Про html5 и Flash не забудьте. А JavaScript просто-таки необходим для интерактивных веб-страниц. Но также важен и css. А ещё сколько всего есть, успевайте только!

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

А ведь альтернатива виртуальным машинам была предложена — кодогенерирующие загрузчики Франца. Лишены большинства недостатков как виртуальных машин, так и статически сгенерированных (скомпилированных и слинкованных) исполняемых файлов. Недостатки VM и так понятны — искусственный аналог машинного кода, который не исполняется напрямую процессором, а используется что-то вроде интерпретации. А недостатки заранее собранных программ в том, что если прога собрана, например, для i386, а у нас i686, то она не будет использовать возможности, предоставляемые нашим процессором, полностью оставаясь в рамках набора команд i386. Ну а кодогенерирующий загрузчик на лету (при чтении с диска в память) преобразует программу именно к нужному процессору, максимально идеально используя все его фичи и расширенные наборы команд. Подробнее про эту перспективную (и до сих пор не оценённую толком) технологию писали Богатырёв и Франц.

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

Возникает огромное желание избавиться от изучения новых платформ и языков под них, а также от всех сопутствующих SDK, NDK, утилит, освоения тяжеловесного Eclipse и прочее-прочее. Хочу набрать программу на знакомом языке, работающую под знакомым API и нажатием одной кнопки получить её бинарник/дистрибутив под выбранную из списка платформу! Думаете, это невозможно? Да ничего подобного, это более чем возможно. Радует безусловно уже то, что программисты начинают осознавать, ухватывать тенденции, что именно таков путь сред разработки будущего. Это напоминает историческое отношение к кроссплатформенной разработке, которую очень сильно не поощрял ms с одной стороны и любители всяческой халявы линуксоиды с другой (т.е. они поощряли разнопроцессорность и разноархитектурность, но только под никсами, что не намного лучше).

Тем интереснее было мне увидеть проект Monkey, который разработан для !!!

  • Сборки программ, написанных на одном языке (Monkey) для целой кучи платформ (да знаю я про юнити, знаю, ах оставьте вы меня; монстр ещё тот! ;) ).

    А именно:
  • Apple iOS, MS Windows 8, HTML5, Flash (ActionScript), Android и др.

Бэк-энды можно разрабатывать самостоятельно. Проект Monkey является коммерческим, но исходники частично открыты. Почти все. :)

Так вот про резон появления XDev. Мне тут говорили, что не знают, что такое XDev. Пожалуйста, узнайте об этом сейчас. XDev — это мы берём язык программирования с потенциально самым низким барьером вхождения, но при этом универсальный и вполне пригодный для решения широчайшего класса задач. Он может соединить веб-разработку и написание приложений для десктопов, облегчить научные расчёты для экспериментов и разработку для планшетов, решение нетривиальных задач (например, разработку для ретроплатформ, что показывает на практике его универсальность и подчёркивает его самостоятельную ценность) и т.п. Закроем глаза на малую популярность Оберона. Потенциально она большая за счёт простоты. Ведь Оберон — самый простой среди универсальных и самый универсальный среди простых языков программирования. Притом, в отличие от простых языков типа brainf*ck, простота Оберона — практична, даже прагматична. А это значит, что у него, быть может, и не слишком массовое, но несомненно очень интересное будущее. Особенно с учётом того, что его ценители — это обычно очень умные и интересные люди. Не знаю в чём тут секрет, но это так.

Значит взяли мы простой, но мультипарадигменный, объектно-ориентированный и модульный язык. Следующий шаг — это универсальное API, и с этим всё далеко не так просто обстоит. Но Monkey показывает нам, что это возможно! И при всех ограничениях подхода его плюсы превалируют. Т.е. не изучайте десять платформ, десять наборов API и десять языков (или диалектов) программирования для них. Изучите один простой язык, одно простое API и радуйтесь жизни. Хотя бы для вхождения в процесс. Потом, если пойдёт и если выбранное средство достаточно гибко для подстройки к вашим задачам и потребностям, а Обероны именно таковы, это будет значить, что выбор сделан верно. Это нужно уже не корпорациям, не фирмам. А вам, чтобы сохранить вкус к жизни и не превратиться в очкарика-гика, которому ночью в страшном кошмаре снится sudo rm -rf ;)

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

С API вопрос стоит непросто, но решать его нужно, особенно с учётом того, что у нас такой замечательный взят язык. Он просто-таки способствует хорошему проектированию интерфейсов, ибо имеет неподдельную модульность. А секрет хороших кроссплатформенных API крайне прост: придерживаться концептуально уверенных понятий. Т.е. буковка на консоли. Точка. Цвет. А не режим вывода графики, цветовая битовость и разрешение. Первые понятия фундаментальны и могут быть объяснены непрофессионалу достаточно легко. Внутренние же потроха ОС это удел гиков, пусть он им и остаётся. Мы понимаем, что потрохов не избежать, но акценты нужно ставить на более фундаментальном, скрывая внутри детали реализации. Нужно получить аппробированием и последовательным уточнением такое API, которое захотели бы поддержать если не разработчики новых ОС, то хотя бы разработчики библиотек и приложений.

Так вот в итоге просто хотелось бы, как я уже сказал, нажать кнопочку и собрать единый код для выбранной платформы. В Monkey этого достичь удалось, но конечно со многими ограничениями. Ничего страшного, главное, суть подхода ухвачена, нужно развивать его дальше. Для ретро-платформ всё будет намного сложнее, но уже как-то получается совместить такие несовместимые платформы как ZX Spectrum и MS Windows. Да, не будем считать всё это дело окончательным, там тоже есть над чем почесать тыковку, много чего ждёт своего уточнения или банальной оптимизации, до которой ещё не дошли руки. Но макет рабочий, вот что ценно. Теперь, уважаемый программер, можно писать на этом код. А когда появится платформа X10 — не нужно будет уже изучать язык Y10, а просто делать по мере необходимости новые бэк-энды. И целесообразность такого шага будет более чем оправдана за счёт большого количества готового кода под эту технологию.

Конечно в идеале хотелось бы заставить всех производителей поддержать единый язык и единое API, но сами понимаете ситуацию. Это просто недостижимая блажь. Это корпоративность. А голова пухнет у девелопера, который сегодня кодит игру на X1 под Y1, завтра на X2 под Y2 и послезавтра на X3 под Y3, потом в конец ему это надоедает, что произошло и со мной. Можете считать, что я сломался, но — хе-хе, посмотрите на себя в зеркало эдак через десять лет, и может узнаете. ;)

Здесь очень деликатное различие между универсальным подходом к API и подменой настоящей кроссплатформенности одной-единственной платформой. Позже я, быть может, сделаю об этом развёрнутый пост. Пока же скажу так. Видите, я был бы очень не прочь покодить (хотя бы простенькие вещи) для MSX, NES (Nintendo), Агат (аналог Apple и Apple-II с процем-аналогом 5802), да даже и для БК-шки, той, самой первой (0010) с мини-объёмом ОЗУ. Однако же даже до хеллоу ворлда барьер офигенный — освоить все эти платформы, их тонкости построения, ассемблеры и архитектуру команд, какие есть языки на них и какие реализации, какие библиотеки (ага! а ведь никто не ставил целью собрать всё это в кучу!) — превращает такую идею просто в утопию. Заниматься освоением ретро-платформ никто не будет, потому что на носу бог весть какие планшеты с Android и прочие айфоны. И кодинг для них тоже очень непрост. Тоже требуется освоение новых языков, языков разметки, декларативных языков запросов и прочея. Так вот. После долгих лет программинга возникает желание это всё упорядочить и унифицировать, упростить процесс разработки на базе единого языка и единостильного подхода. Тем интереснее увидеть в действии разницу различных архитектур и платформ, чтобы ещё более углубить своё понимание ситуации. Короче говоря, XDev — это по задумке среда с суперлёгким барьером вхождения, в которой (предположительно) новичок может написать злосчастный хелоуворлд на Обероне и собрать его для тучи разных ретро- и ново- платформ и простым нажатием на одну кнопку сразу запустить, не вникая ни в какие более тонкости. Подход безусловно имеет свои проблемы и ограничения, и даже суровые, но зато он позволяет получить некоторый приток новых людей на старые платформы, повторно пробудить интерес к ним и зафиксировать разработку, а также безусловно понизить барьер вхождения в разработку для новых платформ, как бы оставляя проверенные и здравые вещи в работе, не вышвыривая их на помойку как позавчера суперпрогрессивные (тот же Турбо Паскаль), вчера очень приемлемые (Дельфи), а сегодня “устаревшие”. Но у меня в мозгу не помещается: как самый здравый способ записи алгоритмов можно называть устаревшим?

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

http://habrahabr.ru/post/159377/

XDev же — это ретроплатформы в первую очередь, потому что я неплохо знаю Спектрум, DOS, да и винду пришлось изучить. Но ничего не имеем и против новых платформ, поддержку которых сделать можно и нужно, притом на базе того же (!) Оберона (и его расширений). Вот так-то. Не более и не менее, но, заметьте, я буду чрезвычайно рад увидеть подобные же проекты, ибо это очень меня интересует. Спасибо за внимание.

P.S. Хотел эту статью на Хабр, но потом передумал. Неприятные воспоминания. ;) Наслаждайтесь ею здесь на форуме, мои дорогие единомышленники. ;) Надеюсь, что объяснил доходчиво из каких именно побуждений растут ножки у XDev. И спасибо товарищу Хоботу за то, что помог сформулировать.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 22 дек 2013, 12:06 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
geniepro писал(а):
Сколько тебе лет-то? Я помню, что ты вроде бы моложе меня (80-х годов рождения кажется), но запамятовал насколько именно, извини..
Мне в январе 2014-го будет 36. Почти старый чудак. ;) Да, людей 18-25 лет считаю молодёжью, они воспринимаются уже не как наше поколение. И молодёжи всегда кажется, что впереди вечность, а старики чудаки, а у стариков жизненного опыту побольше, это ценно. Но именно поэтому юношеское патетическое увлечение красивым языком программирования не следует путать со зрелым мнением, подтверждённым боевым опытом.

geniepro писал(а):
То, что я меньше внимания уделяю другим языкам, так это потому, что мне Хаскель просто бльше нравится, кроме того именно в хаскелле сейчас идут наиболее активно всякие разные исследования -- софтверная транзакционная память там, исследования в области систем типов и т.д.
Вокруг Оберона тоже немало исследований вертится. Ты посмотри. Исследования в области ООП, в области БД. Оберон потенциально может заменить Фортран в науке, он вполне того достоин. Сегодня в рассылке проскочило:
Claudio Nieder писал(а):
Hi,

>> would be more of a challenge to rewrite the lowlevel part of the source
>> in (sorry) gcc or Python so that the new Oberon could be ported to
>> proven hardware.


As I am not active in Oberon anymore I should keep my mouth shot, but this idea sounds so wrong to me, that I can't keep quite. I see Oberon as a way to build a whole system - OS, Compiler, User Interface - in a rather simple manner and formulated in a single programming language, so that it is possible that a single person can understand it as a whole. To mate this with a monster of several millions of lines of codes written in a foreign programming language seems just plain wrong.

I think that adapting the Oberon System to a new processor architecture isn't very difficult as proven by Oberon V4 which was available for several OS (Windows, Solaris, AmigaOS, ...) and processors (x86, Sparc, PA-RISC, 68k, ...). What was IMHO done wrongly at that time is, that the different implementations where not part of a coherent code base, but handled more like independent forks. So not only was e.g. Solaris/Sparc Oberon ported to HP-UX/PA_RISC but also modules of the system independent part improved without backporting the improvements to Solaris/Sparc leading to unnecessary fragmentation. More on this later on.

Furthermore once a port is made, the amount of maintenance is very low given the basic assumption of Oberon being a simple system. With preferring a simple and readable compiler over one that strives for maximum performance of generated code at a cost of being a monster like gcc one would not have to follow processor evolutions as one would never e.g. try to optimise code by supporting the latest vector instructions etc. E.g. most probably the last change to be followed on the intel processor family would have been the inclusion of x86-64 about a decade ago, and since then the compiler would have remained untouched.

>> A good start would be to port Native Oberon to gcc but the sources of Native Oberon
>> are very hard to get.


One remark to your mention of Native Oberon. If by that you mean really native i.e. running on the bare hardware, then you run into a challenge which is much bigger than adapting to different processor architectures. After all there are just a handful or at most a dozen architectures which are really interesting. Running natively means you have also to support gazillions of different peripherals. Not only the numbers work against you, but also change is much more common in this area then with processor architectures. My gut feeling is, that the developer base in the Oberon community is too small to keep a native system up to date for any useful definition of up-to-date. I remember having had a look at Native Oberon at the time it was most actively developed and even though I had a fairly standard, i.e. not using very exotic chip sets, laptop computer I could not make Native Oberon run on it in any usable way. I will come back to this too.

Some 15 years ago after working on Oberon4Amiga and seeing the fragmentation issue, once I found some spare time I decided to unify back the different V4 ports. Unfortunately my period of spare time ended too soon, I was not able to find enough other people who would share my idea both because I am not the born leader but also because a lot of people interested in Oberon preferred System 3 over V4, which had lead to ever more variants of Oberon. Nowadays we have also AOS. Each of these has its followers because the needs of each of them seems to be different. Some people on this list care mostly about the TUI and are happy having that with any other kind of OS running beneath of it. Others might even hate the TUI because the mouse-interclicks cannot be translated to touch screens but on the other hand like to have a nice programming language and a small footprint, understandable OS they can use on limited resources devices. In this context going native might even make sense, when the target platform is small, strictly defined with only few peripherals that are expected not to change significantly over a large period of time.

In addition to fragmentation in the code there is also fragmentation in the objectives and desires of the Oberon-lovers and this is in my opinion the main reason why you don't see Oberon brought to more hardware, not enough resources devoted to do it. I don't see how mating Oberon with gcc could change that a single bit.

If you want to go forward and get Oberon running on a particular platform you care for, than I would suggest to proceed like this:

    - Identify whether you want to have it running on bare metal or with some other helping OS beneath it.
    - Look around for Oberon sources which are as near as possible to what you need to support your target platform.
    - Analyse what the gap is between the sources you find and what you need to have to support your target platform.
    - Estimate whether you would be able to do the work by yourself. If this is not possible see if you can find enough other people also interested in seeing Oberon happen on that particular platform. When doing your estimates take into account maintenance. How much is the platform expected to change over time and what resources do you need to keep track with these changes.
    - Once you find you got enough resources committed to it, do it and make the (Oberon) world know about it.

>From my past experience let me express one wish if you actually do such a project: Make sure you integrate somehow your new work with the source you based from to avoid increasing the fragmentation we already have. E.g. if you base on Oberon V4 and take a source from http://sourceforge.net/p/oberon/oberonv ... ster/tree/ then arrange so that your additions get back into this repository instead of being an independent fork on another repository.

-- Claudio Nieder
Оберон может жить на любом железе и любой платформе, а раз он минималистичен, то и реализовать его проще. Не нужно ждать когда фирмы догадаются скопировать Оберон целиком, а не по частям с добавлением корявостей. ;) Он воспринимается оберонщиками именно как такой интеръязык. При всех имеющихся недостатках он (после Модулы-2) видится самым удачным кандидатом на роль минимального современного универсального ЯП. В нём практически нет избыточных семантических средств, которые можно было бы с воплями назвать корявыми или устаревшими. Так что Оберон минималистичен семантически, однороден синтаксически и целостен концептуально (что, впрочем, никак не мешает уточнять его и уточнять, получив, впрочем, для начала опыт его использования). Но чем это тебе не достоинства, которые ставят Оберон впереди других языков по крайней мере для очень многих ниш использования, где другие средства просто неприменимы?

Я вообще стремлюсь развивать что-то существенное, значительное, с большим потенциалом. А не изобретать усовершенствованный способ как затыкать дыры в js. Никогда не любил таких задач, мелких, капостных и противных. ;) И всё равно через пару лет никому не нужных. Получается: "— Чего делаете, мастера?" "— Я мешу грязь" "— Я сижу по уши в цементе" "— Я только что получил по ноге кирпичом" "— А я строю Шартрский собор" (гордо). Чувствуется разница? ;) Именно потому я не в восторге от скрещивания О и js. Слой js не нуждается в перекраске, его нужно вообще выбросить. Тупо игнорируя, что он поддержан во всех браузерах и есть на миллионах сайтов. Дурное надо выкорчёвывать без жалости, но с корнем. Мотивация? Пожалуйста. Чем принципиально отличается программная разработка на клиентской и серверной стороне, чтобы широко использовать для неё принципиально различные, но не универсальные, а узкоспециализированные языки? Причём слепленные наспех на коленке для внутреннего пользования (так появился PHP), с игнорированием почти всех наработок в области языкостроения, а часто и основанные на дурных привычках и заимствовании. Не кодил на встроенном скриптовом языке IRC-клиента mIRC? Мне довелось. ;)

А js как язык имеет какие-то уникальные преимущества перед универсальными языками, без которых нельзя обойтись на клиентской стороне? PHP имеет их для серверной стороны? Правильный ответ — нет. Но и там, и там — интерпретация, только прифинтифлюшенная. Надо избавляться от корня проблемы, а не маскировать её поверх дополнительными слоями, в т.ч. языковыми. Раз не удалось заточить один достаточно универсальный язык под клиент и сервер, значит этому есть причины. Взять C++. Полный C++ не пойдёт на клиентской стороне, он "опасный", нужно отделять подмножества, городить песочницы. А для серверной на сверхбольшом C++ разработка получается слишком трудоёмкой, PHP проще оказался. Значит C++ при всей своей (вроде бы) универсальности — не тот язык, надо городить ещё языков. Но пухнет голова у простого девелопера, которому приходится при таких обстоятельствах изучать не пять языков, а сто пять, причём почти все — узкоспециализированные. Девелопер чувствует себя обманутым. Ему обещали, что C++ заменит всё, а хренушки, давай учи быстро js и PHP. Не обойдёшься. Ему обещали, что "Java: напиши однажды, исполняй везде", а получилось: "напиши однажды, будет тормозить везде". Ну вот, ситуация примерно такая.

А вот язык КП. С соответствующим набором модулей может прекрасно работать на клиентской стороне ("опасные" модули не будут включены), и с тем же успехом и на серверной. Не надо подмножеств, не надо песочниц. Разработка простая и однородная для любой из сторон. А если ещё и кодогенерирующие загрузчики Франца прикрутить — вообще конфетка получится, во всех смыслах.

    + Проще язык. И один язык для сервера и клиента
    + Производительнее (нету интерпретации и нету виртуальной машины)
    Комитеты, стандарты, массовые привычки, пристрастия, предвзятость. Ментальные барьеры преодолеваются значительно сложнее физических.

(Про Juice конечно же знаю. Почему не взлетело — вопрос не ко мне, но, видимо, были причины. Технологически там всё шикарно, хотя конечно же не модерново — парк браузеров сменился)

geniepro писал(а):
Оберон неплохо может подойти для программистов-одиночек типа Вирта. Для промышленного же программирования Оберон мало приспособлен.
Но его можно приспособить. Т.е. обфичить, стандартировать, поддержать и т.д. Но я же тоже одиночка. Типа (но не масштаба конечно) Вирта. :) И посмотри на FreePascal, тоже развивается, и без комитетов и международных стандартов. Тоже языковая платформа. Вырос из DOS/Windows, а сегодня на нём даже делаются попытки разрабатывать для Андроида. Одиночками конечно делаются, для масс нет ничего кроме Джабы. ;-) Но ведь возможно же! И практически без изменения самого языка. Всё благодаря здоровому Паскаль-началу. Или, если угодно, Алгол-началу. ;)

Ровно так же мы можем развивать и Оберон. Но чтобы нам с тобой лучше понимать друг друга, хочу прояснить, что в слово "Оберон" я чаще всего вкладываю "Оберон-2 или Компонентный Паскаль". Танцы Вирта с бубном вокруг Оберона-07 я не готов принять, считаю эти все ревизии, уточнения и кастрации (да-да, и никак иначе) не попыткой получить удобный и практичный язык программирования, а попыткой подсократить сотню-другую строк в листинге компилятора. Понимаешь, Вирту надоело писать компиляторы, устал он от этого. ;)

Оберон-07 я считаю малопригодным для разработки, особенно для микроконтроллеров. Разве что моторчики по сигналам от фотоэлемента на стендах крутить. Он попросту неудобен.

А КП достаточно стабилен как язык. И как базис вполне надёжен и готов послужить основой для обфичивания. Портирование кода как с Оберона-07, так и Оберона-1 и Оберона-2 на КП не должно вызывать никаких трудностей.

geniepro писал(а):
Я когда-то думал об этом, но потом пришёл к выводу, что подобные изменения системы типов уж слишком изменят язык для того что бы он мог называться обероном.
Именно. Заметь, BlackBox предлагает для построения GUI гораздо более прогрессивные средства, чем Дельфи, но многие программисты просто не готовы принять этот концепт. Именно поэтому не следует пресекать разработку GUI-библиотек с классическим а-ля VCL подходом, потому что они могут сосуществовать. Ровно также и Оберон работает в ортодоксальной системе типов, потому что хаскелевскую много людей принять не в состоянии, даже не станут с ней разбираться.

geniepro писал(а):
Вот, например, Зоннон. В нём изменения по сравнению с Обероном незначительны, однако ортодоксальные оберонщики уже отказывают ему в праве называться обероном...
Не скажу за всех, но в моём понимании Зоннон утратил некоторые ценные достоинства Оберона, а их желательно бережно сохранить. Там в язык добавлено то, что имхо надо выносить в библиотеки (шаг назад от Оберона к Паскалю — встроенный в язык WriteLn, а это предполагает привязку языка к текстовой консоли (или хотя бы к потоковому вводу-выводу) — и понеслось). Утерян (ну или смягчён) стиль ключевых слов заглавными буквами, а это тоже несомненное достоинство, можем и его обсудить, но вкратце скажу, что я признаю все высказанные на Оберон-форумах аргументы в его пользу. Да, в Зонноне можно и большими, но ведь никто не будет. Или будет, но один исходник так, другой эдак. Вобщем, бардак. Это сходу, я не разбирался досконально, т.к. вроде реализация Зоннона есть только на .NET? Это наверное самое (для меня) неприемлемое. У меня злосчастный .NET стоит только ради VisualStudio, пришлось поставить, иногда нужно бывает.

Zorko писал(а):
geniepro писал(а):
А знаешь что ты щас сказал? Что идеальной в твоём понимании нотации для публикации алгоритмов на данный момент вообще просто нету в готовом виде. Это очень печально, друг! ;)
Ага, нету. Питон ближе всех подходит, но тоже неидеален.
Однако это не является особой проблемой для меня лично...
Извини, но это напоминает Сеню из "Бриллиантовой руки": "Такой же, но с перламутровыми пуговицами? Будем искать". ;) Вот же готовая почти идеальная нотация, которую надо всего лишь уточнять, чем и занимается Вирт, но, быть может, не всегда вызывая своими действиями одобрение. А вообще не уточнять её нельзя, иначе она устареет.

geniepro писал(а):
Для публикации алгоритмов, имхо, лучше всего подходит некое подмножество Питона, с ясным двумерным синтаксисом, с минимумом синтаксического мусора в виде {} или BEGIN END. Выбросить из Питона ООП-составляющую -- все эти классы -- и нет ничего лучше для публикации алгоритмов. Но это моё частное имхо, конечно же...
Ты к BEGIN не придирайся. Может в Паскале это и синтаксический мусор. В Модуле же и Обероне BEGIN имеет крайне важное значение разделителя между декларативной и императивной составляющей, если угодно, между данными и исполняемым кодом, т.е. алгоритмом и структурой данных. Это необходимо чисто психологически, упрощает чтение и разбор кода. Плюс так все данные сгруппированы, их сразу можно увидеть одним блоком. Это дисциплинирует. А вот в Си-подобных языках всё размыто, данные идут вперемешку с кодом, можно получить в одной единственной функции стопку вложенных областей видимости, внутренние локальные переменные с одним (с областью видимости повыше) именем, и эту грязную привычку говнокодеры-"крутяки" отстаивают как жизненно важную, вот им как раз и не нравится BEGIN, потому что мусорить не даёт.

К вопросу о том, заменить ли слова закорючками. Если да, то тут сам бог велел вместо BEGIN'а скобки, это безусловно. Но словарно программа читается и конечно же воспринимается легче. Из закорючек её надо "распаковывать в голове, проговаривая мысленно". Это увеличивает нагрузку на мозг, закономерно понижая его ресурс для решения других задач.

Кстати, ты упоминал, что оберонщики плодят тонны говнокода, так позволь поинтересоваться. Ты под говнокодом в этом контексте понимаешь конечно же ETH Oberon, A2/AOS, BlackBox, Ofront, OO2C или что-то другое?


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 26 дек 2013, 20:49 
Не в сети
Администратор
Аватара пользователя

Сообщения: 273
Откуда: Россия
Zorko писал(а):
А в недостатки Оберона давайте не будем углубляться. Никто не отрицает, что его тоже нужно совершенствовать и притирать к задачам, которые перед ним ставятся.
А я вот возьму и углублюсь! :)
В нашем грешном вещественном мире нет ничего абсолютно идеального. Оберон тоже не идеал, он имеет недостатки. И анализ этих недостатков и причин их возникновения является, на мой взгляд, большим уважением к ЯП и его автору(авторам), чем слепофанатичное восхваление.
А недостатки можно разделить на такие группы:
Недостатки, которые возникли по недосмотру. Они могут быть исправлены без ущерба для существующих достоинств и ЯП станет лучше. Некоторые из таких недостатков изложены в работе Patrik Reali (перевод М.В. Андрева). Действительно, нет никаких доводов в пользу неоднозначности символьной константы, это, по видимому, просто упущение Вирта, которое следовало бы исправить. Также и синтаксис приведения типов «Т1(:Т2)» вместо «Т1(Т2)» представляется более наглядным и снимает нарушение LL(1)-грамматики в данном случае. Хотя, исправление недостатков часто само имеет недостаток — несовместимость с ранее написанным кодом.
Другие же недостатки являются обратной стороной достоинств. Они возникли намеренно, как следствие намеренно выбранного подхода, приносящего эти достоинства. И эти недостатки нельзя устранить, не отказавшись от достоинств.
Так например, необходимость указания типа заставляет тратить усилия на описания переменных (недостаток), но обеспечивает контроль за ошибками и эффективную компиляцию (достоинство). И никто еще не смог совместить ловлю опечаток в идентификаторах и возможность вводить новые переменные «на лету»!
Индексирование массивов с нуля также имеет недостаток — дополнительные усилия на «+\-1» при создании программ для предметной области с иным отсчетом (например, в векторной алгебре индексы начинается с 1). Достоинства (упрощение синтаксиса, эффективный контроль за границами, упрощение совместимости типов, распространенность такой индексации в других ЯП) перевешивают.
Однако следует понимать, что недостатки не исчезают от того, что их перевесили. И не следует выдавать недостатки за достоинства (тоже признак фанатичного подхода). Недостатки сами по себе не являются достоинствами, но могут быть неизбежным следствием достоинств, что оправдывает их наличие.
Кроме того, может быть какие-то особенности ЯП некоторые считают недостатком, другие достоинством. Скажем, возможность написать что-то вроде «++---++++i----++++j--» некоторые считают достоинством Си-подобных языков (и проявлением ущербности Паскаля\Оберона, где такое нельзя). А возможность замаскировать вызов процедуры присваиванием (что позволяют свойства — property), Вирт посчитал не только бесполезным, а прямо вредным. И я с этим полностью согласен, хотя кому-то пришедшему из Дельфи такого поначалу может не хватать.
Итак, Оберон — не идеал, Оберон — это компромисс между достоинствами и недостатками. Причем компромисс очень удачный, потому что достигаются многие достоинства за счет небольших недостатков. В большинстве случаев.
Тут, конечно, не удержусь от замечания про FOR :) Стандартный обероновский цикл FOR и его семантика, конечно, имеет и свои достоинства (например, простоту реализации, в чём,увы, я уже успел убедиться), но недостатки, по-моему, перевешивают. Серьезные недостатки, уж лучше бы никакого FORа не было, чем такой!

Что касается сферы применения Оберона и среды XDev. Как нет вещей идеальных, так нет и вещей абсолютно универсальных. Как бы мы нож не совершенствовали, в некоторых случаях не обойтись без отвертки, а в некоторых без пилы. И уж вряд ли кто-то захочет применять нож вместо веника.
Сфера применения Оберона не всеохватывающа, но весьма широка. По крайней мере, потенциально очень широка. Как Олег писал выше, можно было бы использовать Оберон везде — в микроконтролерах, десктопах, планшетах и браузерах. Не вижу технических (быстродействие, память) препятствий для замены Обероном технологий на Си (хоть с плюсами хоть с диезом), Jave, любом бейсике и пр. Технически видится только выигрыш. Но есть и другие препятствия кроме технических. Сама по себе концепция ЯП Оберон и вообще Оберон-технологий великолепна, но мэйнстрим ориентируется не на продуманный синтаксис или эффективность компилятора, увы!

_________________
А кроме того, я думаю, что корFORген должен быть разрушен!


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 07 мар 2015, 21:39 
Не в сети

Сообщения: 12
Zorko писал(а):
Вспомните строительные технологии. Гвоздь он и есть гвоздь, и триста лет назад.


кстати, я строитель, построил много многоэтажных домов, рассчитывая их численными методами. Просто к сведению сообщаю. Конечно, скорость изменений в строительстве не такая, как в компьютерном, тем более мобильном мире, но иногда происходит глобальная схема парадигм. Так, при СССР было массовое использование сборного железобетона, а сейчас в массе перешли на монолит. Помнится, в момент перехода специалисты были в некотором состоянии растерянности, так как многолетние навыки становились ненужными. А сейчас приходят конструкции из тонкого гнутого листа - так у них вообще проблема с адекватным численным моделированием - динамика+нелинейная геометрия=очень сложная математическая задача, грубо упрощают и еще неизвестно, к каким авариям это упрощение может привести. Так что, мне не по наслышке известна пословица "если бы строители строили так, как программисты пишут программы, то первый залетевший дятел разрушил бы земную цивилизацию" ;) .

Но это не главное. Я хотел привлечь Ваш интерес в сторону малобитных PIC и AVR микроконтроллеров, может быть, Ваш опыт работы с XDev пригодится для создания Оберон инструментария для этой важной сферы человеческой деятельности, ведь не все устройства делаются на 32 битных микроконтроллерах?


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

Сообщения: 1019
Откуда: Днепропетровская обл.
Разработка новых подсистем для таргетов PIC и AVR на базе XDev (Ofront для трансляции Оберона в Си + готовый сишный компилятор) видится вполне несложной задачей. Так что были бы программисты с навыками работы с микроконтроллерами на Си и с пониманием преимуществ Оберона. И решили бы помаленьку все сопутствующие проблемы, как-то: отсутствие отладчика прямо в крутой IDE с пошаговым исполнением программы и отображением списка регистров и дампа памяти и т.п. А так — я достаточно оторван от задач, связанных с микроконтроллерами, чтобы заниматься такими вещами абстрактно, просто потому что это можно сделать. В подтверждение рациональности подхода добавлю, что ZXDev, построенная на этом принципе, показывает отличные результаты. Сейчас я портирую игру для 8-битного компьютера ZX Spectrum (48 кб ОЗУ) на Оберон-2 (ZXDev), транслирую в Си и собираю SDCC. Основной модуль на Обероне-2 — ~1600 строк транслируется Ofront'ом и компилируется SDCC в 24 кб целевого кода для процессора Z80 (после упаковки архиватором hrust — 16 кб), скорость его работы очень приемлема. Придумал кучу трюков для высокоуровневой и низкоуровневой оптимизации, получил полезный опыт.

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


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 08 мар 2015, 05:03 
Не в сети

Сообщения: 12
Zorko писал(а):
Так что если будут конкретные вопросы или задачи за денежку, которые можно делать на удалёнке, пишите. Всегда мечтал зарабатывать программированием на любимом языке.


Насчет денежки можем воспользоваться опытом FireBird. Они организовали фонд, собирают деньги с тех, кому нравится эта СУБД и разместили список задач. Кто из опенсурсников решает задачи из этого списка, получает средства с этого фонда.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 09 мар 2015, 03:34 
Не в сети
Аватара пользователя

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


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

Сообщения: 12
Zorko писал(а):
Да, это весьма хорошо. Уверен, для продвижения Оберон-технологий нужно показать их коммерческую применимость, создать рабочие места для специалистов, ими владеющих. Это будет очень сильный козырь за Оберон, пробивающий даже закоренелых скептиков. Так что, получается, дело за организаторами, имеющими отношение и к бизнесу, и к сфере образования в области IT.


У меня есть план. За основу надо взять не прибыль непосредственно с программирования, а прибыль с улучшения какого-либо существующего процесса обработки информации.

Один из таких процессов - подготовка документации для строительства зданий. Это как раз насыщенный информационный процесс. И он нужен везде, на него выделяют от 2 до 7 % денег, расходуемых на строительство в целом. Применение Оберон технологий здесь поможет радикально ускорить некоторые производственные задачи.

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

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

Подготовка документации для строительства хорошо аутсурсится. На Западе, в арабских странах есть индийские компании, занимающиеся таким аутсурсингом. Из-за этого в Америке даже нет специалистов-строителей младше 50 лет, так как эту нишу заняли индийские аутсурсеры.

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

Альтернативные платформы (.net, web, Android, микроконтроллеры), а также численные методы - все это можно с выгодой применить в нашем процессе, используя Оберон-технологии в качестве универсальной основы.

Так что, кто реально хочет продвинуть Оберон и на этом заработать, пора засучить рукава.


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

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


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

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


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

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