Стоит ли разрабатывать новый язык програмирования?
Стоит ли разрабатывать новый язык програмирования?
Собственно уже не раз задавался себе вопросом о избыточности
и излишней универсализации существующих решений…
Дело в том что оптимальных решений в области компиляторов
и языков програмирования на сегоднешний день НЕТ.
И вот почему:
— оптимизация под конкретную архитектуру процесора (CPU иль GPU) вещь довольно абстрактная и решается совсем не опытными системами и даже не эвристикой а простым ДКА (if...then) из-за возможных больших нагрузок. Это, казалось бы, решение довольно логичное и оптимальное, но с приходом облаков, кластеров и прочих паралельных плюшек можно было бы найти какое-то «более быстрое» комплексное решение, и оно таки есть… только кому надо придумывать велосипеды с турбонадувом?
— человек решает проблемы абстракции приложений в большинстве случаев императивным
«чёрным ящиком» и пачкой шаблонов (в идеале 2-3), так появляются на свет шаблоно-зомби, и прочие недопроджекты. «0_о я открыл для себя мир erlang'a» — сказал Юра. «А нам пофиг.» — сказала team'a.
И так уже было со мною не раз — в одном случае ООП в другом функционал… в третьем brainfuck и сайт на fasm'e. кому какое дело?.. всем пофиг — «лишь бы работало» никто не задумывается о скорости и эфемерной «оптимальности». Так вот я скажу что у людей слишком много свободы! Абстракция на то и абстракция что бы сказать this is a ball. а вот что внутри пускай решает сам язык, если нужен метан — будет метан, если нужно серебро будет серебро.
— 0_о нам всем нравится STL он такой мягкий и пушистый… в нём столько много плюшек =)
зачем нам учить те долбаные алгоритмы? зачем задумываться о структуре данных?
Она может быть избыточна?,- да что же ты несёшь… работает вот и хорошо, пускай даже медленно…
но ведь работает. И так каждый день… люди часто стараются решать задачу вычисления оптимальности алгоритмов для конечной реализации, но почти всех и всегда ждёт полный epic fail.
Как говорил дядя Кнут: «Низкоуровневая оптимизация — корень всех проблем.»
И тут тоже у людей слишком много свободы…
СОбственно о чём это я?.. а мораль довольно проста:
существующие решения являются отчасти комплексными но ввиду апаратных нагрузок ключевые моменты обобщены и «универсализированы» что ведёт к потери «оптимальности» выходной продукции.
То есть Универсальные решения не могут быть оптимальными, лишь комплексные…
А огромной проблемой в наше время является именно оптимизация, не важно под что многоядерность, многопоточность, распределение нагрузок, низкоуровневая…
Пускай у нас для этого будет такой себе эфемерный торрент-компилятор аля СкайНет.
Нас не волнует ни апаратное время, ни объём памяти.
Нам нужен компилятор «без компромисов» и парадигм времён і386.
Собственно ПО никогда не блестало производительностью — а апаратная платформа уже далеко впереди.
Вот собственно и всё, думаю причины «упадка компиляторовединья» всем понятны.
Интересует стандартный вопрос: «а стоит ли овчинка выделки?»
Я занялся разработкой подобного «чуда», пока (к сожелению) за 1.5 года идеально отточена мат. часть.
Просто не хочу повторять google wave.
Не хочу быть кем-то купленым.
Хочу найти единомышлеников.
P.S. Зарание прошу прощения за возможно допущеные ошибки — русский не мой нативный язык.
Также прошу прощения за излишнюю сумбурность изложения.
Надеюсь на ваше понимание… Просто «это всё» уже на порядок достало.
Мне лично тоже очень стыдно за специфику «народных» разработок, уж больно часто видал ГосПО обсчётов субсидии и прочее… это просто, это просто тема отдельного поста =)
… да но у меня чуть больше опыта для того что бы просто что-то форкнуть (это стыдно),
по этому поводу можете не беспокоиться.
На ранних стадиях (сейчас) используется:
Qt, boost, Intel TBB (вытесняется boost'ом), CUDA (opencl). cudasm, decuda,corepy
Да тут есть чуть-чуть python'a, но только там где это не может испортить мне настроение =)
Этот список скорее всего будет ограничен до простого Qt (иль gtk). =)
То есть главный вопрос это труд и реклама?..
Первое решается довольно сложно но решается,
а вот с «маркетингом» действительно могут быть проблемы.
Хотя… У меня ещё осталась пара сотен «тузов в рукаве» =)
Если вы хотите разрабатывать для собственного удовольствия — стоит однозначно.
Если вы думаете, что ваша разработка решит целый пласт абстрактно описанных проблем и станет нужной везде — забейте. Не будет такого.
Да в принципе я пишу эту дрянь и для удовольствия тоже…
И уверен что она решит класс этих самых проблем, потому что она уже их решает.
Если не было бы proof concepta я давно бы забил на это всё…
Просто до релиза ещё слишком рано, и это не совсем OpenSource.
Я здесь не для того что-бы раскрывать свои секреты…
О количествах тузов в рукавах давайте будем потом «размышлять»
Я просто спрашиваю Стоит Ли? если есть PoC и время.
Нет, не стоит.
Посмотрите на существующие языки и платформы, получившие признание и внесшие новые техники в разработку. Знаете, что есть общим в большинстве из них? Их разрабатывали не 19-летние студенты, а люди с огромным багажом опыта (в том числе массы неудачных попыток) и теоретических знаний.
О секретах и «тузах» в данном контексте смешно читать.
Не вам судить о моём опыте… а даный пост является самомотивацией ввиду жизненых обстоятельств.
Не все 19-ти летние студенты, такие 19-ти летние как может показаться на первый взгляд.
Он почти год назад обещал рассказать про свои технологии супер-оптимизации: habrahabr.ru/blogs/personal/77231/#comment_2248442
За почти год его заметка так и не увидела свет, хотя обещана была вечером 4 декабря 2009 года.
Теперь он обещает раскрыть свои скереты еще через год, в 2011 году.
Такими темпами к концу своей разработки он будет уже далеко не 19-летним :D
Вот по-этому я и говорю что не хочу быть тем чуваком что кубик-рубик собирал лет так 25…
вот и задался вопросом: а стоит ли?.. чисто такой мотивационный вопрос.
Не публикую ибо не зачем. «Професиональное мнение» мне не нужно, ибо будут одни холивары.
Тем более что у меня есть несколько «своих» технологий полиморфной компиляции, о которых смысла рассказывать всем и всея нет.
Сформулируйте цели проекта, задачи, которые решит новый язык, более явно. Вплоть до формальной подробной формулировки.
Как только у Вас это получится, должно прийти понимание, нужно ли оно, и сколько стоит овчинка, а сколько выделка.
Я уже давно предельно точно сформулировал задачу которую требуется решить.
К сожелению я не могу очень точно представить результат работы такого компилятора, он в прямом смысле этого слова «не чёткий» и выдаёт иногда такие вещи от которых «крышу сносит»,
а иногда «висит». Тоесть это что-то наподобие ловли энергетических флуктуаций вселенной и материализация их в виде алгоритмов. Вот такое вот эзотерическое «чудо». Полный рандом-эффект.
Но это работает… и работает довольно интересно. Остался только вопрос наполнения стандартной библиотеки.
… спокойствие, только спокойствие — всему своё время, оглашать до 2011 года врятли собераюсь,
так что потерпите уж до Нового Года хотя бы, а там будет видно (это связано с законодательством)
Но цыкл статей этой epic story с реально существующими персонажами я вам уж точно в скором времени (1-2месяца) поведаю.
Можно писать программы на языке, заточенном под одну-единственную железку, и она будет работать быстрее, чем программы на «универсальных» компьютерах. Но что бы использовать возможности железа на 100%, надо под каждую железку писать свою программу на своем языке программирования.
Другой подход — то о чем вы писали, «универсальность». Палка о двух концах. Требования рынка диктуют потребности в быстрой разработке софта — так появляются всякие высокоуровневые языки программирования. А ведь когда-то чистый Си считался непозволительно «раздутым» по сравнению с тем же асмом. Но «рынок» сказал — «нам нужно чтоб работало здесь и сейчас, и что бы специалисты могли легко осваивать новые языки, и писать софт под наше железо». Производительностью пришлось пожертвовать — это называется «компромисс».
Резюмируя, и отвечая на ваш вопрос: если вы хотите потренироваться в разработке оригинальных технологий, научиться наступать на грабли, и замечать их издали в будущем — создавайте свой собственный ЯП.
Оригинальные технологии… да идея уже есть и подкреплена мат. частью.
Моё решение абсолютно комплексное и учитывает все особенности целевых платформ.
Соответсвенно проблемы оптимизации и заточки под что-то решаются довольно нестандартными путями, и это работает… на грабли я уже наступал за этот год 3 раза, за прошлый 2.
И то это просто были проблемы научной формулировки происходящих процесов.
Та да. Может и будет над чем посмеятся. Не хочу быть тем чуваком что кубик-рубик вечность крутил.
На rsdn? Ну возможно, но нет времени тролить =) нада кодить…
Чем новый язык будет отличатся от известных? Какие задачи он будет решать, каковы выгоды его использования? Вот, на что разработчику следует ответить перед созданием детища.
Ну во первых это язык NP-формулировки.
То есть мы поэтапно вводим что входит а что выходит, причём это могут быть абстрактные данные.
Сначала в глобальном решении, потом в конкретных локальных. По юнит тестам, которые мы вводим либо которые генерируются автоматом, ЯП определяет коректность работы программы а также принимает решения о структуре данных и используемых алгоритмах работы…
Таким образом можно решить все описаные проблемы, полное TDD и XP с коробки.
Во вторых stdlib будет ооочень большой.
В даной реализации должна пресудствовать огромная база готовых решений на основе которых будут созданы новые. То есть в случае смены апаратной платформы грозит полная перекомпиляция, либо смена критерия оптимизации по «желанию» пользователя.
Этакий «black box» сам генерирующий «странные» и быстрые алгоритмы.
Я студент факультета компьютерной инженерии — я имею прямое отношение к железу.
… хм свой асм? да я люблю fpga'шки но это для меня пока слишком.
Обучение студентов или хобби? Я не препод, и я ненавижу свой преподавательский состав…
Это уж точно не хобби, уж больно фанатично много времени я уделяю этому делу.
Вопрос Спроса и Предложения… а я просто хочу сделать этот мир чуть-чуть лутше.
С Ассемблером не согласен в корне. В данном случае виртуальный ассемблер, byte-code или еще как, требуется при создании полноценного компилятора/транслятора, без него по сути невозможна кроссплатформенность.
И не всегда нужно отношение к железу, в моей практике был проект, в котором нужна была возможность внедрения некоторой логики и оказалось проще было написать свой простенький транслятор, чем брать существующего монстра.
Про транслятор абсолютно согласен… сам пробывал вкуривать разнообразные LL(*) LALR(1) парсеры, в конце концов просто написал свой glr'ный (*),
Про байт-код ввиде триплетов ДКА — я не решаю вопросы кодогенерации промежуточным байткодом,
но всё же примочки для реализации кросплатформенности есть (а куда ж без них).
Как пример: база данных комманд процессоров в виде гиперграфа для компиляции в гетерогенном кластере (r* дерево 3-го порядка). пока осуществленна поддержка і386 і видеокарт gf8*00 (ptx-asm), так для тестов на моём ящике.
Думаю это утопия. Если придерживаться поговорки — Каждый программист должен написать свой язык программирования, то может и стоит, для удовлетворения своих порывов. А вот в качестве серъезного языка программирования думаю не стоит, это колосальный труд и одному, даже небольшой командой будет очень сложно довести до конца, а еще потом и поддерживать. Если же делать опенсорсный проект, то лишь бы не получилось как со всякими PHP, когда вышел релиз 5.2.0, в котором была убита передача параметров в функции по ссылкам.
Время программистов стоит дороже железа. Поэтому оптимизируют время написания (легче писать, существующие библиотеки) чем время исполнения ( всякие оптимизации).
По этому параметру лучше существующие языки (уже известные программистам), чем новые (которые надо учить)
Моей задачей была «супер апаратная оптимизация» с использованием всех современных парадигм разработки… TDD,XP,patterns,agile and so on. прямо с коробки.
Вы так говорите как будто ASM это что-то паранормальное? Для компиляторов это основной ингридиент который нужен для реализации низкоуровневых оптимизаций.
У меня специальность процессоры разрабатывать… не интересно уже и очень дорого (ПЛИСок много нада). А вот с языками с точностью до наоборот — их много, а толку — мало.
Простой
