OberonCore

Итак, почему я (пока?) не нашлось задачи для Оберонов/ББ.

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

Это лишь мой опыт. У меня так. У кого-то может иначе. Никаких холиворов. Никаких пристрастий. Никаких опять 25. Не интересно.

Итак, чем я занимаюсь? Занимаюсь я всякой более-менее забавной всячиной, как на работе, так и в свободное от ничегонеделания время, т.е. дома, just for fun.

Ну, начнем с дома. Я тут немного и весьма эпизодически занимаюсь не то чтобы компиляторами, а скорее анализаторами кода. Немного (весьма) пишу, и в этом почти профан. Но пишу. Кроме того моя сестра занимается примерно тем же (стохастические грамматики), так что есть с кем что обсудить. Программист она не суровый, не профессиональный, в отличае от меня. Поэтому когда встала задача написать некий анализатор кода, первое что пришло в голову -- взять ББ и там радостно и с использованием Coco/R это дело наваять. Язык (КП) простой, Coco/R тоже простой. Так что вроде бы это хороший выбор для не профессионала, для профессионала же тоже неплохой. Однако случились грабли. Оказалось что Coco/R для КП старинный и бажный. Что он не переваривает грамматику Оберона. Увы. Нет, можно было конечно закопаться в него и пофиксить, или же вообще портировать с явы или шарпа актуальную версию, но зачем? Нам не шашечки, но ехать. В результате остановились на java + Coco/R. Анализатор для сестры был написан на ура. Быстро просто. Работает.

Правда для моих задач Coco/R таки тесен. Его впритык хватает на реальный (а не описаный в сообщении о языке) Оберон-2, и я не уверен что таки его хватит. Потому я всё больше смотрю и экспериментирую с haskell+parsec. На этой связке просто делается всё что угодно.

Ещё я занимаюсь всякой мелочевкой, иногда всякой алгоритмикой например. Но тут особых преимуществ у ББ нет, и как бы даже наоборот. У меня на домашнем ноуте линукс, и ставить wine ради ББ (и только ББ) как-то не слишком хочется. Да и не вижу тут особой разницы каким императивным языком пользоваться, тут ведь даже сборщик мусора не нужен -- память можно просто не высвобождать Эксперимент же. Впрочем, для тех же плюсов сборщик мусора тут есть.

Работа. Работа у нас интересная. Перспективные разработки. Отдел. Да.
Суть -- есть некие области компанией до сих пор не изведанные. Непонятно насколько перспективно развивать то или иное направление. Во всех смыслах слова. Неизвестно востребовано это будет или нет. Неизвестно будет это работать вообще или нет. Неизвестно какие ресурсы могут потребоваться. Наш отдел это такой разведотряд, который должен максимально быстро провести разведоперацию на этой неизведанной территории, и выяснить это всё. Важно скорость, мобильность, гибкость. Ресурсов мало -- разведотряд же. Максимум -- человека 3. Это потом. если направление для наступления окажется перспективным, в дело вступят регулярные войска, где ресурсов на порядок а то и на полтора больше. Будут двигаться медленно и планомерно. Но это будет потом.

Да, занимаемся мы VoIP'ом и всем что к этому может иметь хоть какое-то отношение. Ну, например IM. Или скажем rtmp. Или что-то ещё что взбредет в голову

Когда начинается разработка, непонятно где и когда она заверщится, как изменится "ТЗ" через месяц. ТЗ в кавычках, т.к. никакого ТЗ по сути нет, есть направление исследования. В использовании инструментария мы практически никак не ограничены. Другое дело, что выбор инструментария должен быть оправдан. Ну, например создание скажем sip-телефона. Нужен он был под windows, тут вроде бы ага, давайте ББ. Но сразу много но. Но номер раз -- многопоточность. Она там нужна. Номер два -- DirectX (DirectSound), DirectShow. Номер три -- у нас разные морды, в частности морда на .net'e (она гламурна и быстро лепится, вообще это выбор писателя gui и он оправдан), а ещё морда на Direct3D. А ещё на Win32 API. В общем тут были бы некоторые проблемы. Не сильно большие, но были бы. И тормознули бы разработку. Да, нужно для кодеков ещё использовать ffmpeg, нужно использовать ipp. Биндинги можно сделать, не проблема. Но это время. 1-2 дня. А может и больше. Это МНОГО. На обероне, если мне моя эрудиция не изменяет, нет ни одной реализации rtp, sip, соответственно джиттер-буферов. Следовательно в случае чего быстро позаимствовать код не выйдет. Да, это тоже можно сделать, портировать. Это просто. Но это время.

Но это всё цветочки. Ягодки начинаются потом. Итак, ягодки: через некоторое время выясняется, что нам неплохо бы ещё и этот вот сип-телефончик иметь под WinMo. Времени, замечу, на это, ну месяц примерно. Ну два от силы. Какие шансы либу писаную на и под ББ перетащить за месяц на WinMo? А ведь там ещё проблемы с устройствами и вообще множество особенностей.

А потом выясняется что нам это же, надо под linux. Причем морда должна быть на яве (это железное требование). Насколько просто на ББ написать JNI модуль? А сделать google protobuf для ББ? А всё это под линукс произвольной версии? Времени, ну, месяца где-то три. Да, причем это с расширением функционала -- теперь нужны и видеозвонки. А это нагрузка. А ещё надо уметь работать с иксами, причем не чистыми, а с расширением X Video, иначе тормоза. А ещё желательно уметь unix domain sockets.

Итого, если бы мы с самого начала выбрали бы Оберон (любой!) в качестве основного языка реализации, это было бы серьезной ошибкой.

И не надо думать что для нас С++ это такая суровая необходимость. Зависит от задачи. Например гейт smpp<->xmpp на erlang'e? Почему нет? rtmp<->sip на ерланге? опять таки, почему нет. Гуй на шарпе? Да пожалуйста. Google protobuf для реализации протокола? Да нет проблем, если это приближает к результату и позволяет избежать каких-то грабель.

Выбор должен быть разумен.

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

Ничего не понял, но проникся.

Новые примеры для старых наблюдений:
давление толпы (в широком смысле) и краткосрочных (приматических) соображений заставляют "идти в строю".

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

Это не так.

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

Краткосрочные соображения не всегда приматические. Я же кажется написал что мы делаем. По сути это макеты-прототипы. Они почти всегда выбрасываются. Тут просто нет долгосрочной перспективы. Наш продукт не программа, а знание.

У Компонентного Паскаля (как и у Оберонов) преимущества проявляются в долгосрочном ПО, когда новые модули заменяют старые, в поддержке ПО на длительный срок, когда нужна модульность и расширяемость. А также когда требуется дисциплина программирования.

Никто ж и не спорит. Я никого не обвиняю, не обличаю и не срываю покровы. Меня спросили, я ответил.

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

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

Точно.

Я бы не назвал тот же питон например чисто скриптовым. Скриптовый -- это не свойство языка, это область примерения. Вот erlang это скриптовый язык? А java?

Ну, кроме того тот же питон не для любых задач подходит. Для наших например он не подходит ну никак вообще.

Но я согласен с тем, что скажем в web'e именно поэтому питон, php, ruby столь популярны. Низкий порог вхождения + наработаный инструментарий => можно новую идею попробовать очень очень быстро. Если пошло, если народу нравится, то тогда уже можно начинать думать о архитектуре, масштабируемости и проч.

Сомневаюсь. Но надо подумать.

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

Впрочем, в своей научной возне я еще с 1992 сильно понизил порог, когда "почеркушки" начинают переводиться в графический редактор. И имею возможность поражаться собственной дальновидности

С другой стороны, КП/О как язык макетирования, вроде, на высоте. Но если речь опять о библиотеках, то это всё те же краткосрочности, которые предохраняли динозавров от вымирания.

Это не совсем почеркушки. По сути, это эксперимент. Т.е. после почеркушечек. Эксперимент будет ли это востребовано (потенциальные клиенты не могут сказать нужно им это или нет, до тех пор пока не пощупают), и не обнаружится ли внезапных граблей при реализации. Побыстрому, на скруточках попробовать. В отрыве от окружения (библиотеки, системы и проч) задача смысла не имеет. Умозрительно не решается. Взаимодействие с окружающим миром (клиентами) необходимо.

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

Впрочем, мы что-то слишком зациклились на второй половине моего письма. Первая тоже не безыинтересна

Щас мы ещё поспорим, что такое почеркушечки

Я-то говорил про почеркушечки у себя родного, у физика-теоретика. Точто тот эксперимент, только в мире формул. Спросите хоть у близко от Вас сидящего Сергея Юрьевича

Я прекрасно знаю что это такое . Просто аналогия не совсем точна, вот и всё.

Просто я говорю, что Вы не на то место смотрите

Укажите на что смотреть.

"Please would be nice" (C) Mr. Vincent Vega

Неохота упиратца из-за ерунды, уж извините

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

И низкоуровневым прикладным Для того же sip-телефончика нужна и работа с устройствами (естественно со всякими mmap'ами и прочими системными вещами), и работа с памятью ручками чтобы не тормозило, и битики перекладывать.