dizer писал(а):
Скорее всего будет, но интерестно, Илья в качестве области применения ББ называл системное программирование (даже более того "смело рекомендовал ") -я не могу не подтвердить ,не опровергнуть это (не занимался этим) - я так понял что область ваших интересов лежит в этой плоскости....
Итак, почему я (пока?) не нашлось задачи для Оберонов/ББ.
Оговорюсь сразу о терминологии: системное программирование, это программирование инструментария для программиста (в том или ином виде). Это не обязательно низкоуровневое программирование. Низкоуровневое программирование может быть весьма и вполне прикладным. Системное программирование может быть очень высокоуровневым.
Это лишь мой опыт. У меня так. У кого-то может иначе. Никаких холиворов. Никаких пристрастий. Никаких опять 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 для реализации протокола? Да нет проблем, если это приближает к результату и позволяет избежать каких-то грабель.
Выбор должен быть разумен.
