Что вас останавливает от изучения нового языка? - Философия программирования

Здравствуйте, WolfHound, Вы писали:

V>>И нафига там, все-таки, прикидка по весам, хоть убей не пойму? Это типа такой эвристики, наподобие алгоритма инлайнера компилятора gcc? Чья идея? Это же не из той области. В стандартном шаге упрощения систем правил производят ПОЛНУЮ подстановку (!!!), т.е. до тех пор, пока не натыкаемся на рекурсию. Заметь, пофиг веса абсолютно.
WH>Ну так и знал.
WH>Теоретик.

Отчего же, не только теоретик.

WH>После некоторого размера инлайн ничего не дает.
WH>Но размер генерируемого кода раздувает очень сильно.

Это смотря как делать. Бо еще делают так, что ровно наоборот: размер генерируемого кода зависит только от общего кол-ва нетерминалов, и чем оно меньше, тем меньше кода. Т.е. избавление от промежуточных нетерминалов, не являющимися целевыми, идет на пользу. Тело правил — табличное. И оно по быстродействию ручному switch/case вовсе не уступает, а местами ровно наоборот, бо вызовов и косвенности меньше при полном раскрытии.

Ну а ты как обычно пускаешь понты и пузыри. Первый парсер в твоей истории, что ли? Эдак тебя прет.

WH>Короче обсуждать с тобой парсер я более не намерен.
WH>Толку нет.
WH>Ибо ты ничего не угадал. Совсем.

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

Здравствуйте, hardcase, Вы писали:

H>Цель парсера, построенного с помощью нашего макроса — разобрать исходник и построить его AST.

Я тут выше намекал уже на парсер SAX, и на парсер XML-DOM. Второй получается из первого, путем добавления модуля постройки этого DOM. Похожую схему я как наблюдал неоднократно, так и делал сам, — очень удобно, рекомендую. Особенно в целях тестирования и гибкости доработки построителя модели, в вашем случае ACT. А wolfhound просто воткнуть никак в этот намек не может.

H>Абракадабра получается после трансформации некоторых правил в конечный автомат (но даже тогда вполне читаемая и наглядная). В остальном все вполне читаемо и приемлемо для отладки и профилирования.

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

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, hardcase, Вы писали:

H>>Цель парсера, построенного с помощью нашего макроса — разобрать исходник и построить его AST.

V>Я тут выше намекал уже на парсер SAX, и на парсер XML-DOM. Второй получается из первого, путем добавления модуля постройки этого DOM. Похожую схему я как наблюдал неоднократно, так и делал сам, — очень удобно, рекомендую.

Именно это и происходит. Для правил вызываются обработчики.

Здравствуйте, vdimas, Вы писали:

V>Да я уже понял, что у вас даже конечный автомат не табличный. Хотя, учитывая тормоза дотнета по чтению из массивов, может оно и правильно.

Что значит даже? Автомат как автомат. На goto.

Здравствуйте, hardcase, Вы писали:

H>Что значит даже? Автомат как автомат. На goto.

Да их куча техник исполнения. Кстати, если исполнение на switch/case/goto, то неминимизированный по кол-ву состояний ДКА работает примерно вдвое быстрее (в общем случае), чем минимизированный. Только надо провести минимизацию по входному алфавиту, чтобы получить наилучший профит от разреженной таблицы переходов. Если табличная техника — то чуть быстрее работает минимизированный (по кол-ву состояний).

Здравствуйте, VladD2, Вы писали:

VD>Вот модель радио тут не причем. Ну, разве что если сравнивать гетеродинный приемник метрового диапазона и современные стереофонический FM-риемник. Но и это не корректное сравнение, так как кроме повышения качества тут ничего не будет. А в случае языков разница приципиальная. С языком ты получаешь новые концепции. После изучения которых ты сможешь мыслить другими категориями. Это именно как сменить звук на картинку со звуком.
ну давай. Слушаешь ты по радио новости. Как обычно: треп ведущих, шансон или другое Г..., реклама. И вот тебе предлагают радио заменить на телевизор. Звук меняешь на звук + изображение. Ну и что тебе это даст, при условии, что тебе от радио надо только новости и фон? А ничего. Ну да, появятся ток-шоу, фильмы. Если оно тебе не надо — то и обмен не нужен, не так ли?

Здравствуйте, hardcase, Вы писали:

V>>Ты отдели на досуге собственно парсер от построителя документа, то бишь AST. А остальное увидишь сам.

H>Пользователь макроса задает грамматику, и обработчики для некоторых её правил, в которых изготавливает узлы AST. Макрос генерирует парсер, который вызвает после каждого успешно разобранного правила его обработчик. Задача парсера в формировании AST сводится к "протаскиванию" результатов одних обработчиков (либо информации о разобранном тексте — NToken) в аргументы других.

Речь шла об АСТ выражений ПЕГ-грамматики, по которым целевой парсер строится.

Здравствуйте, robin_of_the_wood, Вы писали:

A>>>http://en.wikipedia.org/wiki/List_of_programming_languages
___>Скролишь и думаешь — а вдруг убрали.

Monsanto go home!

On 22.04.2011 19:19, VladD2 wrote:

Скоро уже у меня будет ещё одна причина останавливаться в изучении
новых языков -- необходимость читать такие вот супер-мега топики.
Народ, вам ещё не надоело ?

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, VoidEx, Вы писали:

VE>Здравствуйте, alpha21264, Вы писали:

A>>>>Тебе сколько лет?

VE>>>Максималист тут не я.

A>>Я не говорил, что ты максималист. Я говорил, что ты отрицаешь очевидные факты про метро.

VE>Максималист ты, и подтверждаешь это нижеследующим сообщением очередной раз.

VE>>>Даже я ручку выбираю не от балды. Писать-то всякая может, но некоторыми удобнее. А уж писатели и подавно.

A>>Ну если тебе нравится эта аналогия, то ты пытаешься утверждать, что писатель не важен,
A>>достаточно дать хорошую ручку любому алкоголику, и он сразу станет Львом Толстым.

VE>Я такого не утверждаю, перестань кидаться в крайности. У тебя либо одно не важно, либо другое.

A>>А я говорю, что ручка не важна. Чтобы стать Толстым нужно поучаствовать в обороне Севастополя.

VE>Важно и то, и другое. Ручка менее важна, но это не повод писать гусиным пером.

С тебя доказательство того, что сейчас есть хоть один язык, который можно сравнить с гусиным пером.
Я готов предоставить доказательство (в виде примера), что между С++ и русским языком разница не очень велика.
Русский язык примем за недостижимый идеал. Абсолют.

VE>>>Разумеется. Но если знаю, то мерседес предпочтительней.

A>>Мерседес предпочтительнее, если он бесплатный.

VE>Либо если денег достаточно.

Сия аналогия должна означать, что у тебя ОЧЕНЬ много времени. То есть, ты бессмертен.

A>>А изучение нового языка (и всех сопутсвующих вещей) не бесплатно.
A>>Оно стоит года (а то и нескольких) жизни.

VE>При знании концепций язык можно изучить далеко не за год. А при незнании — польза будет в изучении этих самых концепций.

Концепции — вещь внеязыковая. И лучше их именно так и изучать. На русском языке.

VE>>>GC, замыкания, АлгТД, лямбды, ФВП, легковесные потоки, иммутабельность: все эти на твой взгляд незначимые плюшки дают возможность писать тот самый алгоритм, а не в очередной раз бороться с языком (в этом плане C++ и правда эталон). Для неспецифических задач (где легковесные потоки, например, позволят на порядок проще написать) разница в простоте написания будет не в разы, но всё же будет заметна.

A>>Я не понял, так ты слил что-ли? Все, что ты перечислил никак не помогает решить названную задачу. Вот то есть совсем.
A>>Спорим, что я с помощью С++ (плюс голова, разумеется) решу эту задачу быстрее чем ты (любыми средствами)?

VE>Спорим, начинай. Я, правда, не понимаю, что ты этим собираешься доказать, что не языком единым? Так этого никто и не утверждал, а ты всё упрямо опровергаешь.

Начинай ты. Покажи мощщщь языка.

Я утверждаю (поднимись выше по ветке), что язык С++ настолько мало проигрывает идеальному решению,
что изучение нового языка даст очень мало. А переход на новый язык может не только что-то дать, но и что-то забрать.
По этому, гораздо, ГОРАЗДО, ГОРАЗДО рациональнее потратить время на изучение чего-то неязыкового.
Алгоритмов, паттернов, искусственного интеллекта, андроида, математики, иностранного языка.

A>>Хочешь еще задачку с сайта Яндекса?
A>>Есть Террабайт текстов на русском языке.
A>>Нужно найти миллион самых частотных сочетаний из двух слов.

VE>Давай лучше что-нибудь под Erlang возьмём, а ты это на Си++ начнёшь писать?

Под чего возьмем? Ты задачу назови.

Я это (задачу про террабайт текстов) на РУССКОМ начну писать.
А когда решу задачу на русском, то переведу её на любой язык программирования.
Таки да, в данном случае на С++.

Даже выражение такое есть программируйте не "на языке" а "с использованием языка".
В умных книжках так пишут.

Таки резюмирую. Тема называется — "что вас останавливает от изучения языка".
И я даю ответ — "Новый язык дает очень мало, почти ничего не дает, иногда даже забирает".
Потому что на высшем уровне любая задача будет выглядеть примерно так:

int main( void )
{
   перевести_слова_файлов_в_номера_слов(); // для ускорения сортировки на последующих этапах
   сформировать_список_пар_слов();
   внутренняя_сортировка_пар_со_слиянием(); // сортировка кусков, влезающих в ОЗУ методом qsort
   внешняя_сортировка_пар_со_слиянием();   // методом слияния списков
   выбрать_первый_миллион_пар();   
   return 0 ;
}

У тебя не возникло желание русский язык поучить? Видишь, какие в нем интересные программные концепции есть?

Здравствуйте, VladD2, Вы писали:

VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.
VD>Для затравки дам некоторые возможные ответы:
VD>1. Синтаксические различия. Скажем, привык к сишному синтаксису, а в новом языке переменные по другому описываются (типы через двоеточие) и параметры типов задаются иначе. Если бы язык был полным супесетом того языка который я знаю, то изучил бы.

Нет. Абсолютно всё равно.

c=a+b
c:=a+b
c<-a+b
+= a b c
a + b -> c

VD>2. Идеологические отличия. Например, язык не ООП, а я привык к ООП.

нет. Как раз наоборот. Если, скажем, в языке нет переменных, то это уже интересно...

VD>3. Политические предпосылки — "Все равно не смогу применять его на работе...".

нет.

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

VD>Так же интересно что останавливает от применения языков. Насколько часто бывает так, что язык вы изучили, а использовать его не можете?

Ну потому, что: изучить язык для его применения мало, надо ещё:
1. изучить библиотеку, среду разработки, ошибки и ограничения компилятора, трудности инсталяции программы, которую написал...
2. найти людей, которые будут за всё это платить...
3. найти людей, которые тоже изучили всё это...

Здравствуйте, WolfHound, Вы писали:

A>>Думаешь это так просто? Вот пример. Есть объект типа T: T obj. Я для него зову boost::begin(obj). Как ты думаешь, что нужно этому типу иметь, чтобы данный вызов работал? А ответ заключается в том, что в C++ понятие интерфейса типа гораздо шире, чем набор методов этого типа.
WH>Читай про классы типов в хаскеле.

Это понятно, и чем-то похоже на Checked exception в Java — заставит блюсти всю иерархию, коль бы сложная она не была. В этом примере лишь показано, что налепив сюда контракт, мы обрежем себе возможность делать специализации шаблонной boost::begin() для своих уникальных типов, не отвечающих контрактам. В итоге, явная и частичная специализация шаблонов потеряет в гибкости (не сможет нарушать контракт, т.е. потеряется сама суть — сделать специализацию чего-либо под уникальный тип, а не подтип/"подконтракт" исходного), и вместо этой техники придется городить статические обертки (адаптеры/фасады), обеспечивающие контракт.

Здравствуйте, dimgel, Вы писали:

WH>>Типизация выполняется полностью на этапе компиляции.
WH>>Но из-за того что отсутствуют типы типов ошибка компиляции появляется черт знает где, а не там где она действительно произошла.

D>Это я понимаю. Но это уточнение не прибавит аргументов FR-у.

Ты так и не понял аргумент насчет шаблонов C++, очевидно.

Здравствуйте, dimgel, Вы писали:

D>На зеркало не пеняй. Я вынужденно бью тебя твоим же оружием.

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

Здравствуйте, VladD2, Вы писали:

VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.

О, не про табы и пробелы, а полрсдна участвует... Вот еще взгляд программиста-маргинала, даже бомжа — мой.

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

VD>Для затравки дам некоторые возможные ответы:
VD>1. Синтаксические различия. Скажем, привык к сишному синтаксису, а в новом языке переменные по другому описываются (типы через двоеточие) и параметры типов задаются иначе. Если бы язык был полным супесетом того языка который я знаю, то изучил бы.

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

VD>2. Идеологические отличия. Например, язык не ООП, а я привык к ООП.

Программировать объектно-ориентированным образом можно на Си и ассемблере. А в итоге все сводится к производительности труда при решении задач. Здесь надо учитывать затраты на изучения языка. Студент, формально выучивший язык в институте, должен на нем отработать годик-другой, чтобы котироваться на рынке труда. А, казалось бы, практические языки — это всего лишь "раствор" для склеивания предметных "кирпичей" (или материал для скульптора — как нравится), не более того.

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

VD>3. Политические предпосылки — "Все равно не смогу применять его на работе...".

Вспоминаются, например, дискуссии об использовании NET и java в шароваре. Мне в свое время нравилось "расслабленное" программирование на java, но использовать ее сейчас лично мне негде. Ограничения "политические", думаю, редки, они обычно технические, рациональные. Хотя я сталкивался и с "историко-политическими", когда в одной конторе ту же джаву пихали в каждое отверстие, или когда я был вынужден покодить на Бэйсике из-за чисто политических глупостей. Но это исключения.

VD>Так же интересно что останавливает от применения языков.

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

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

VD>...

VD>Насколько часто бывает так, что язык вы изучили, а использовать его не можете?

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

п.с.
Имхо, в этой теме кое-что навалено в кучу. Есть промышленные разработки, есть академические. Не обязательно в масштабах ИТ, это может быть в рамках одной фирмы: есть череп, который слабает алгоритм в Матлабе и отдаст кодировать на Си юниорам или еще как-то. В итоге есть массовые языки — промышленные стандарты, а есть "штучные". Массовые, "штучные", академические... — вот это было бы неплохо попытаться разделить, как-то яснее будет.

Массовый язык в основе должен быть понятен дятлу и с минимальной вероятностью приводить к катастрофам. Здесь большая инерция.

п.п.с.
Интересно вспомнить 80-е, когда языки плодились со страшной силой. Это было время новых задач, больших, как запуск Гагарина: языки-всемогуторы; ИИ, базы знаний, компы 5-го поколения; параллельные вычисления и все такое. Потом наступило относительное затишье. Сейчас стало поживее. Вот мне кажется (именно кажется, я на самом деле не знаю), что сейчас это в массе связано с исканиями для промышленного программирования: производительность труда, безопасность... Тоже похоже на космос: уже в основном чистая прагматика, без романтики. Но может, я отстал от жизни.

Здравствуйте, Vasilich3333, Вы писали:

V>я бы переделал твое предложение так
V>Необходимость МОЖЕТ ПОЯВИТСЯ, если ты поймешь концепции заложенные в эти языки и научишься применять их на практике.

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

Здравствуйте, VoidEx, Вы писали:

VD>>Я тебе сейчас переведу этот код. Вот как это будет выглядеть на доступных для тебя языках:

VE>Плохо переводишь. Неаккуратно. Можно как-нибудь так:

Ты напиши. Не как-нибудь так, а конкретный код, матчащий Not(Not(rule)).

Чтобы он делал именно это и не был завязан на реализацию Not:

if (r is Rule.Not)
{
  var rNot = (Rule.Not)r;
  if (rNot.rule is Rule.Not)
  {
    var rule = (Rule.Not)rNot.rule;
    return optimize(new Rule.And(r.Location, rule));
  }
}

После этого покажи аналог 6 строчек с ПМ.

        | Not(Not(rule))                => optimize(Rule.And(r.Location, rule))
        | And(Not(rule))                => optimize(Rule.Not(r.Location, rule))
        | Not(And(rule))                => optimize(Rule.Not(r.Location, rule))
        | And(And(rule))                => optimize(Rule.And(r.Location, rule))
        | Not(rule)                     => Rule.Not(r.Location, optimize(rule))
        | And(rule)                     => Rule.And(r.Location, optimize(rule))

VE>С учётом написания not = typeof(Not) и другого boilerplate в 2-3 строки код станет не сильно хуже изначальной лапши.

Как бы я видел реализации ПМ на функциях, все они сильно хуже поддержки компилятора.

VD>Так же интересно что останавливает от применения языков. Насколько часто бывает так, что язык вы изучили, а использовать его не можете?

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

Ответ простой: не нужен

Это почти что "3. Политические предпосылки — Все равно не смогу применять его на работе....", но не совсем.

Дальше идет мало отформатированный и плохо сформированый поток сознания

Итак, последние пару месяцев я периодически (по работе и для души) писал на:
— PHP
— Python
— Javascript
— Java
— Erlang

Оказалось, что эти 5 языков покрывают мои нынешние и будущие потребности, как бык корову. И куда и зачем впихивать туда еще один язык программирования —

То есть совсем непонятно, какие проблемы этот язык решит лично для меня.

— PHP. Мне за него платят. Так что приходится

— Python. На нем решаем проблемы, с которыми РНР не справляется. Быстрее, чем РНР, скриптовый, достаточно простой и лаконичный — то, что доктор прописал именно для скриптов (1000 строчек — практически потолок).
— Javascript. Ну, в вебе без него никуда

— Java. Потому что в graph databases она сейчас рулит со страшной силой, а я все думаю, куда эти самые базы применить
— Erlang. Потому что я все же подсел на Zotonic CMS ну и вообще он мне нра

Ну и не говоря о плюшках, которые каждый из этих языков предлагает (да, и РНР тоже):
— PHP. LAMP или LNMP (N == nginx). Проверенная годами связка
— Python. Скрипты + некоторая изящность самого языка + уже готовые удобные библиотеки типа Mysqldb/PIL и некоторых других
— Javascript. В вебе без него никуда

А также ExtJS, jQuery И т.п.
— Java. Потому что мегакрутые фичи для graph databases на Java.
— Erlang. Думаю, и так понятно

Асинхронность, параллельность и тыды и тыпы.

А зачем мне нужен Немерле?

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

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

Не даром в качестве killer-фичи языка в последнее время приводится именно Nemerle.Peg. Ведь несмотря на то, что формально язык позиционируется, как язык общего назначения, (подавляющее?) большинство разговоров о нем сводится имено к парсингу и/или компилятору.

Если бы я интересовался этими вопросами, то, возможно, меня Немерле и заинтересовал. Но, увы

Даже для того самого PEG у меня на руках есть Neotoma для Erlang'а

Как-то так

... << RSDN@Home 1.2.0 alpha 5 rev. 1498>>

От:	hardcase	http://nemerle.org
Дата:	27.04.11 07:48
Оценка:

	От:	vdimas
	Дата:	27.04.11 09:13
	Оценка:	-2

	От:	vdimas
	Дата:	27.04.11 09:19
	Оценка:	-1

От:	hardcase	http://nemerle.org
Дата:	27.04.11 09:25
Оценка:

От:	hardcase	http://nemerle.org
Дата:	27.04.11 09:27
Оценка:

От:	kochetkov.vladimir	https://kochetkov.github.io
Дата:	27.04.11 15:02
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	28.04.11 19:23
Оценка:	+1

От:	Mamut	http://dmitriid.com
Дата:	29.04.11 07:16
Оценка:	28 (5)