К вопросу о мэйнстриме в ЯП

Сейчас придет Луговский и вызовет Оккама.

> Сейчас придет Луговский и вызовет Оккама.

Это мысль. Хотя я могу попробовать и сам - навыки не те, конечно, но надо же на ком-то практиковаться =)

Давайте Луговского, я ему санитаров вызову. :) Хотя каких там санитаров - в морг сразу.

Ну и зачем смешивать в одну кучу всё, что есть на белом свете? Уж сделали что можно писать на разных языках и строить их взаимодействие дык и оставили бы эту светлую идею. А так получается очерередной монстрик, который просто всасывает в себя фичи и смешивает подходы.

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

Да, конечно, все это уже есть. Но - не в мэйнстриме. Моя основная надежда в данном случае на то, что втыкание этих фич в новый шарп их несколько популяризует. Глядишь, и в жабке что-то такое годика через три появится... =)

> Да, конечно, все это уже есть. Но - не в мэйнстриме. Моя основная надежда в данном случае на то, что втыкание этих фич в новый шарп их несколько популяризует. Глядишь, и в жабке что-то такое годика через три появится... =)

Ну не нужно оно там. Получится ещё один монстр, аки C++. C# мне в самом начале даже нравился немного. Такой был небольшой и приятный язык... Не по наке они языки проектируют и не по уму.

кстати, int19h. Читал недавно обсуждение языков, и ты там сказал, что типа хороший язык - это тот, что умеет хвостовую рекурсию и прочие там вкусности. Возник вопрос - а зачем всё это ? Разве хороший язык не тот, который наименее геморойно и наиболее безопасно позволяет решить текущую задачу ?

Спасибо.

>кстати, int19h. Читал недавно обсуждение языков, и ты там сказал, что типа хороший язык - это тот, что умеет хвостовую рекурсию и прочие там вкусности. Возник вопрос - а зачем всё это ? Разве хороший язык не тот, который наименее геморойно и наиболее безопасно позволяет решить текущую задачу ?

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

Java ведь не поддерживает, но соответствует вышеперечиленным качествам :)

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

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

Опоздал. Похоже будет флейм:-).

>Java ведь ... соответствует

В свое время я яву забросил, т.к. tcl со товарищи были выразительнее. Они потом проиграли питону. А теперь кажется, что он довольно гемороен - монад и пр. не хватает (-;притом в совсем тривиальных скриптах;-). И как вы в больших проектах обходитесь?

> tcl со товарищи были выразительнее. Они потом проиграли питону.

Кто сказал? Пистону до tcl ещё десяток лет говном плыть, tcl это же почти lisp.

Почитал новую спецификацию си шарпа - чуть не блеванул. Очередное гигантоманское уебище на свет рождается. Они туда даже SQL-подобный язык интегрировали. Фтопку такие решения.

> - expression trees to represent lambdas as data rather than code (AST! даешь макры! ;)

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

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

Во-первых - хвостовую рекурсию "умеет" в основном не язык, а оптимизатор конкретного компилятора/интерпретатора языка. Во-вторых "умеет хвостовую рекурсию" это чрезвычайно узколобый подход к определению практической ценности языка программирования. SQL, например, не умеет хвостовой рекурсии впринципе, за ненадобностью.

> SQL, например, не умеет хвостовой рекурсии впринципе,

Умеет.

Продемонстрируйте пжлста

>Пистону до tcl ещё десяток лет говном плыть

Не спорю. К сожалению он не выдержал конкуренции за умы разработчиков библиотек.

> Почитал новую спецификацию си шарпа - чуть не блеванул. Очередное гигантоманское уебище на свет рождается.

Гм, что есть CL, как не... ;)

> Они туда даже SQL-подобный язык интегрировали.

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

> Так полноценные макры с помощью такой бодяги не сделаешь

О полноценных речь не идет однозначно, тем более, как я понял, ковырять эти самые expression trees можно только в рантайме (но есть надежда, что там есть завязка на Reflection.Emut, и дерево можно после ковыряния скомпилить и выполнить) - но все равно, по сравнению с тем, что было, это прогресс.

> Конечно. Просто для того, чтобы "наименее геморойно и наиболее безопасно" как раз и нужны эти самые вкусности. Следовательно язык без них - не хороший:-)

В качестве иллюстрации к вышесказанному, рекомендуется сравнить систему типов Java и, например, O'Caml, и посмотреть на то, как в последнем реализовано ООП.

Интересно, никто не подсчитывал, как часто люди пытаются изобрести PL/1?

Как обычно, M$ создаёт монстра ... который может всё ... но оччень плохо ... на заборах то же много всего пишут .... а там обычно дрова лежат. :)

C# - это будет "язык для всех," абсолютное большинство "писателей" на
нем даже не будут знать, что такое ФП и как его готовить. Те же, кто
хочет интересных возможностей + .net уже имеют Nemerle. В итоге из C#
получится обычный bloatware.

recursive with в DB2. Если интересует, посмотри в DB2 SQL Cookbook, там целый раздел называется "Recursive SQL"

ИМХО он повторит судьбу висуалвасика, и это правильно. Майнстримом пока называть рано, скорее мода такая.

Это наверное S.P. Jones дорвался таки до руля. И R. Milner с ним за компанию.

А где ты видел хоть одну mainstream поделку, которую бы проектировали по науке да по уму? Они - продукт эволюции, а эволюция логикой не балуется, у ней другие методы.

Хороший язык - это тот, который позволяет наименее геморройно сделать из себя другой язык, заточенный под твою текущую задачу. Те языки, в которых есть first class functions, currying, closures, корректная хвостовая рекурсия, и т.п., позволяют достигать бОльших уровней абстракности - читай, преобразовывать себя в более узкозаточенные языки, чем те, в которых конструкции более фиксированные и убогие (паскалеобразные язычки всяческие, из которых ничего, кроме паскаля и не сделаешь никогда). И уж совсем полная свобода (и, соответственно, мощь языка) достигается, когда язык предоставляет возможности метапрограммирования - макросы или сплайсы.

Какими это качествами Java обладает? Она не заточена ни под какую конкретную задачу. Она не позволяет решать ни одну встречающуюся на практике задачу НАИБОЛЕЕ адекватным образом. Так что Java - отстой.

У tcl отмороженный GC. Да и с модулями туговато.

>Да, конечно, все это уже есть. Но - не в мэйнстриме. Моя основная надежда в данном случае на то, что втыкание этих фич в новый шарп их несколько популяризует. Глядишь, и в жабке что-то такое годика через три появится... =)

Майнстрим это популярность? Если так, то популярность делают пользователи. Все это и еще больше есть в CL. Забавно смотреть как санки и мелкософт пыжатся делая то, что уже давно есть и работает. Однако идея понятна - раскрутка и контроль. Только с этих позиций M$ обыгрывает санок. В жабке чтото такое уже непоявится. Делать что то с лагом в три года непрактично - никто ждать небудет. На самом деле непонятно будет ли это в C# - какая раскрутка без трепа и пыли в глаза? Будь то C# или глюкоза со сташевским. Однако есть движение движение (или видимость?), а это привлекает. А у санок тишина... жаль санок...

> C# - это будет "язык для всех," абсолютное большинство "писателей" на нем даже не будут знать, что такое ФП и как его готовить.

Не "будет", а уже есть =)

Попробую однако же пояснить мысль. Вот сейчас в каком-нибудь институте читают лекции по C#. При этом обычно описывается весь язык, и в дальнейшем рекомендуется грамотное использование его фич. Т.н. "быдлокодеры" практически все знания выносят именно из стен своего учебного заведения. Если в языке появится лямбда и type inference, то в курсе они появятся тоже, а значит, очередное поколение "быдлокодеров" будет частично облагорожено знанием о таких доселе заоблачных вещах. Да, нормально использовать они его все равно уметь не будут, как сейчас не умеют использовать ООП. Но, во всяком случае, языки с этими фичами не будут автоматически записываться в категории "academic" и/или "esoteric" - и это хорошо.

> На самом деле непонятно будет ли это в C# - какая раскрутка без трепа и пыли в глаза?

Сходи на их сайт - там уже лежит альфа компилятора...

Так быдлокодеров все эти страшные слова отпугнут в сторону VB.net итд. Я не понимаю цели MS.

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

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

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

А ты что, не видел языки для слабоформализуемых предметных областей? Слабая формализуемость - тоже формальное свойство :)

> ибо разработать специальный язык или хотябы наречие - требует большей квалификации

Нет. Это гораздо проще, чем противоестественная и маловнятная объектная декомпозиция. Любой баран справится.

> А ты что, не видел языки для слабоформализуемых

Видел пару раз. С работы заполночь йдёш - ещё и не такое увидиш. Однако обычно проще нашлёпать груду if/else чем изготавливать и присобачивать модуль на прологе например.

> чем противоестественная и маловнятная объектная

Насчёт объектной согласен, она иногда в точности такая, как ты ея изобразил, а в остальных случаях ещё ужасней. Другие же для для (за исключением особых случаев) в самый раз. Небольшой пример: средь потока слов нужно выявить такое, у которого есть в начале цифра либо вторая буква "у", а всего букв три, либо есть твёрдый знак после гласной. Все случаи обрабатываются по-разному. Я могу это решать наворотив груду условий, либо создав спецнаречие. Спецнаречие можно делать либо универсальным, что превысит потребности данной задачи и явно будет превышать как по объёму конструкции, так и по сложности отладки/последующего восприятия упомянутую груду условий, либо в точности соответствущим поставленной задаче, и в этом случае оно сведётся к той же груде условий, но полученных более замысловатым путём. (Можеш предложить вариант наречия и его реализации для такого случая?) Плюс ещё мне конечно потребуется освоить средства и методы создания наречий. И так по большей части всегда, кроме больших и сложных, однако типовых, задач, для которых соответствующие наречия ужо давно созданы.

> Однако обычно проще нашлёпать груду if/else чем изготавливать и присобачивать модуль на прологе например.

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

Да и if-else - это для формализуемых задач. Для плохоформализуемых нужна байессианская сетка, а уж её ручонками на сях кодировать станет только полный отморозок.

> Можеш предложить вариант наречия и его реализации для такого случая?

А чего тут предлагать? Банальных регвыров разве мало? Всё уже готово.

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

> Ну так лупить таких по чайнику, пока не поймут, что все их привычки - дерьмо, и каждый, кто тупо держится за привычки - дрянь.

Да! Да! И подметать улицы, профессор!

> Проще оно может быть только с непривычки.

Это субъективное мнение. Мой пост - тоже. Как же достоверно выявить более простое?

> А чего тут предлагать? Банальных регвыров разве мало? Всё уже готово.

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

('0' <= 0 [p] && '9' >= 0 [p] && (case1 (), 1)) || (3 == strlen (p) && 'у' == 1 [p] && (case2 (), 1)) || (is_hard_sign_after_vowel (p) && (case3 (), 1)) || (printf ("no suitable cases found\n"), 0);

Описания функции int is_hard_sign_after_vowel (char *) не привожу, оно очевидно.