Цитата из обсуждения на RSDN:
Всё, что ты делаешь (и я делаю, и кто-либо ещё делает в районе проектирования любых ЯП), направлено на уменьшение количества ошибок, допускаемых программистами.
Это единственная разумная точка зрения. "Мы все уменьшаем количество ошибок наших пользователей".
Не могу согласиться. Думаю, что основная цель разработчиков языков программирование – уменьшение количества работы программиста. Количество ошибок – это уже побочный эффект.
После некоторого раздумья: Мы все уменьшаем объем работы наших пользователей и упрощаем их работу. (Упрощение так же важно, т.к. уменьшение объема не всегда является упрощением)
Полностью согласен!!
ОтветитьУдалитьПример: каков бы ты не был грамотен в родном языке, чем длиннее текст тебе нужно написать, тем больше вероятность что ты совершишь грамматическую ошибку, допустишь очепятку, пропустишь запятую, и т.д.
Каков бы ни был глубок умом - в большом тексте повышается вероятность логических неувязок, незаконченности мысли в абзаце, неоднозначности употребления терминов без разъяснения контекста для понимания смысла читателем (=компьютером).
Учесть ошибки пользователя - это добавить код для их обработки, то есть написать еще текста.
С объемом текста все на так однозначно, к сожалению. Имхо, на сложных задачах сокращение объема исходников достигается за счет "компрессии" -- меньшее количество знаков, но значимость каждого знака существенно возрастает.
ОтветитьУдалитьВ качестве примера можно посмотреть на Haskell. Что-нибудь вида:
f <- \x -> x*x
содежит столько же смысла, сколько:
var f = x => x*x;
или
function<T, T> f = [](T x) { return x * x; };
Фактически, все три варианта эквивалентны (в определенных контекстах). Первый лаконичнее, то эта лаконичность имеет большую стоимость, т.к. требует от программиста больше знаний и внимания. Соответственно, ошибка в сильно сжатом исходнике будет обходиться дороже.
Поэтому-то я и сказал, что важно как уменьшение работы (т.е. сокращение объема текста), так и ее упрощение (сокращение стоимости восприятия и сопровождения текста).
А автор оригинальной цитаты, наверняка, говорил о том, что целью современных языков программирования является существенное ограничение возможностей совершить ошибку (типа исключения Null-ссылок, принципиальная невозможность выхода за пределы массива при итерации по нему, принципиальная невозможность целочисленных переполнений, зависимые типы и пр. лабуда). Вот как раз с этим я не согласен -- все эти вещи, наверное хорошо, но подобного рода ошибки не имеет ничего общего с функциональными ошибками. Например, они не защищают от того, что разработчик при реализации обращения к WebService забудет указать адрес HTTP-прокси. А ведь от разработчика в первую очередь ждут прикладной функциональности. И именно упрощение написания прикладного кода и является главной движущей силой.
эта лаконичность имеет большую стоимость, т.к. требует от программиста больше знаний и внимания
ОтветитьУдалитьВозвращаясь к своей аналогии:
Тексты бывают разные. Скажем - массово пишутся тексты о психологии. А дай любителям психологии почитать Фрейда, Маслоу, Лейнга - и все эти знатоки застрянут на первых главах.
А автор оригинальной цитаты, наверняка, говорил о том, что целью современных языков программирования является существенное ограничение возможностей совершить ошибку
Да, есть такое поветрие. Новый вид "серебрянной пули", на смену RUP, ООП, Agile, ..., - "Вот в чем была проблема - не было дуракозащищеных языков! Даешь ЯП на котором и первокурсник напишет правильный код"
Как я понимаю это поветрие вызвано самими студентами, которым интернет предоставляет возможность высказаться на равных с более опытными. Их мечтой - поменьше учиться, и побыстрее писать программы за которые платят деньги.
thesz - редкое исключение, почитываю его блог. Но напрочь пока не заинтересовало ФП, потому что все примеры что приводятся, вокруг которых идут Дебаты - немногим сложней задачи - вывести в консоль "Hello world!"
И именно упрощение написания прикладного кода и является главной движущей силой.
Именно так. И за это упрощение приходится платить. И эта оплата неприемлима для "системного кода".
Но студенты-лентяи думают что "сборщик мусора" - это от их дурости защита. Для того придуман. Как рассуждения ребенка - "скалы острые, чтобы животные могли бочок почесать"
Ну а thesz'ам хочется верить и верят что шум вокруг ФП - это от большого ума, и потому радостно поддакивают - да, защитит тебя ФП от собственной глупости.
Имхо, на сложных задачах сокращение объема исходников достигается за счет "компрессии" -- меньшее количество знаков, но значимость каждого знака существенно возрастает.
ОтветитьУдалить"В этом примере, как и в случае x++, традиционная форма явно выигрывает у OO-формы, если считать, что целью является уменьшение числа нажатий клавиш. Объектно-ориентированная технология вообще не является оптимальной на микроуровне (игра, в которой выигрывают языки типа APL или современные языки сценариев типа PERL). Выигрыш достигается на уровне глобальной структуры за счет повторного использования, за счет таких механизмов, как универсальность (параметризованные классы), за счет автоматической сборки мусора, благодаря утверждениям. Все это позволяет уменьшить общий размер текста намного больше, чем уменьшение символов в отдельной строке. Мудрость локальной экономии зачастую оборачивается глобальной глупостью. Б. Мейер "Объектно-ориентированное конструирование программных систем".
2Quaker: самое забавное, что на эту же книгу я сослался в своей последней заметке (http://eao197.blogspot.com/2009/10/compprogthoughts_13.html). Еще, кажется, у Страуструпа было предупреждение, что при использовании ООП начальные расходы будут существенно выше, чем при структурном программировании.
ОтветитьУдалитьА термин "компрессия" я взял из статьи "Повторное использование против сжатия" (http://eao197.narod.ru/desc/reuse_versus_compression.pdf) Ричарда Гэбриеля. Он в ней как раз указывал, что в случае ООП происходит "компрессия" -- уменьшение объема решения за счет усиления контекста.
Все это весьма спорно, на выразительных языках легко делаются EDSL которые часто дают очень заметный выигрыш, в том числе и по сравнению с ООП, именно на глобальном уровне.
ОтветитьУдалить2Rustam: по поводу широкого использования разных eDSL -- это еще нужно посмотреть, во что все это выльеться со временем на больших проектах. А то ведь есть пример Lisp-а, который вроде как есть, а вроде как...
ОтветитьУдалитьLisp вполне есть. Даже Forth в своей нише все еще тоже есть. Ну и EDSL в lisp и EDSL в hasskell/ocaml вещи разные. Обычные ФВП часто по сути уже EDSL.
ОтветитьУдалить2Rustam: Lisp вполне есть.
ОтветитьУдалитьLisp есть так, что если с его помощью кто-то захочет зарабатывать себе на жизнь, то у него будет очень небольшой выбор: либо линять в буржуиндию и искать работу там, либо начать собственный бизнес и разрабатывать софт очень маленькой командой (читай в одиночку). Имхо, и то, и другое на мейнстримовых языках делать проще.