Тенденции в программировании

Как вариант

Куда уж проще-то?

Есть много куда, поверьте.

И да, мне питон не нравится - черт же ногу сломит!

Это у Вас комплексы, так же как и насчет С++. С комплексами надо бороться;-)

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

read_datfile = lambda f : [ map( float, l.split() ) for l in open(f) if l.strip() and l[0]!='#' ]

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

read_datfile - знак подчеркивания потерялся.

> ide под себя можно сделать только своими руками

По затратам труда проще взять готовую.

Я молод, мне можно.

>в сложной ситуации они не помогают, в простой и без них все понятно.

Кому как.

>Я молод, мне можно.

Школоло простительно. ^)

Чёрт ногу сломит в ваших «скриптах». И это в жалких 100~ строках.

> потому что декларативное программирование стоит на уровне более высоком, чем императивное,

Да, но при чем тут функциональные языки?

Вы меня просто выбили из колеи своим комментарием. Я даже не сразу нашелся, что вам ответить на это. Приведу, пожалуй, выдержку из википедии:

Согласно первому определению, программа «декларативна», если она описывает каково́ нечто, а не как его создать. Например, веб-страницы на HTML декларативны, так как они описывают что должна содержать страница, а не как отображать страницу на экране. Этот подход отличается от языков императивного программирования, требующих от программиста указывать алгоритм для исполнения. В типично декларативном языке программирования XSLT, последовательность исполнения зависит, как правило, от входящего XML (в случае с использованием push-модели — «проталкивание»), в случае использования pull-модели (вытягивания), XSLT вырождается в частный случай функционального программирования и легко может быть заменена на аналогичный код в XQuery.
Согласно второму определению, программа «декларативна», если она написана на исключительно функциональном, логическом или языке программирования с ограничениями. Выражение «декларативный язык» иногда употребляется для описания всех таких языков программирования как группы, чтобы подчеркнуть их отличие от императивных языков.

Думаю, так вам станет понятнее, при чем тут функциональные языки, которые по мнению Майка Вильямса должны придти на смену императивным C++ и Java.

Опять сплошная демагогия. Функциональные языки декларативные. Функциональные должны заменить императивные. Очередной бред. Mike Williams хвалит своё болото.

ФП в питоне? Вижу лямбду, функцию высшего порядка (map ??) и list comprehension. Сплошное ФП.

О декларативном программировании и программировании «мышкой» уже говорили в топике?

Это такой новый вид унижения чужого кода? =)

ФОРТРАААН!!!.

Ты что-то путаешь. Функциональные языки (чистые) считаются декларативными, только из-за отсутствия сайд-эффектов. Алгоритмический кошмар можно легко и на них написать, и в реальном (а не факториальном коде) это так и есть. Никакой особой магии позволяющей описывать «что», а не «как», по сравнению с не функциональными языками, в них нет.

Как пример ортогональности понятия «декларативность», можно привести eDSL, которые с успехом пишутся и на функциональных, и на императивных языках.

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

Про eDSL вообще не понял, к чему это? Да, на функциональном языке общего назначения можно писать программы с точно такой же функциональностью, как и на Си. Разве это плохо? Тут вопрос ведь не в возможностях, а в эффективности работы.

а в эффективности работы.

Гы-гы. У тебя эффективность тоже не зависит от стоимости разработки?

И опять мне не понятны ваши сентенции. О какой стоимости работы вы говорите? Если вы о том, что сейчас очень сложно найти разработчика на Erlang или OCaml, то опять вы не правы. Никто не призывает срочно увольнять всех программистов на Си++ и нанимать на работу программистов на OCaml. Переписывать существующий код на другой язык занятие неблагодарное и бессмысленное в большинстве случаев.

Напомню вам, что топик называется «тенденции в программировании», а не «программирование сегодня».

О какой стоимости работы вы говорите?

Оставим в стороне бедных разработчиков и собственно языки. А поговорим об инфраструктуре, IDE, готовых решениях, библиотеках, средствах проектирования и развертывания — все то, чем обросла промышленная разработка (быдло разработка, 95% всех программ) за годы существования. И без чего вообще не приходится говорить о какой-то эффективности.

И что мы видим? Единственный функциональный («декларативный») язык, который унаследовал обвязку у своего императивного собрата и потому имеет хоть какую-то «тенденцию» — это Scala.

А где рекламируемая тройка? В глубокой жопе. Привет из восьмидесятых, с тремя не очень популярными серверами. Унылая академическая поделка вообще без ничего. И модная академическая поделка, но она по крайней мере видит кусочек труселей в виде растущего сообщества фанбоев.

Однако, странно. Я о Scala вообще мало слышал, а вот про Erlang довольно часто слышу, и даже вижу заказы на oDesk на этом языке. Кстати, вижу заказы еще на Ruby и даже, не поверите, на Haskell. А вот про Scala не видел ничего... Странно. Про OCaml и так все ясно: язык умер, но оставил наследника в виде F#. Выживет или нет, время покажет.

Но дело не в конкретной реализации идеи ФП или ЛП, а в принципе в постепенной замене старого императивного подхода к разработке программ к более современному декларативному подходу. Пока затраты огромны, но со временем ситуация будет меняться. Особенно, если новые проекты будут изначально ориентировать на новый стиль разработки.


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

Так и вижу ситуацию... 23 век. Среднестатистическая программа содержит 30к строк кода и все еще пишется на Си++, отлаживается 3 года и только после этого запускается в опытную эксплуатацию... Как страшно будет жить.

человек говорит, что в питоне,по его мнению, чёрт ногу сломит — а вы ему в качестве опровержения показываете некий однострочник, в котором чёрт ногу сломит. :)

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

Есть еще вариант, когда вы - не автор. Опять-таки - отладка и тут не обязательна, но с ней все значительно упрощается.

У Ваших чертей остеопороз, срочно поите их кальцием! Что в этом примере непонятного O_O?

Вот именно :)

Вообще ничего.

> Но дело не в конкретной реализации идеи ФП или ЛП, а в принципе в постепенной замене старого императивного подхода к разработке программ к более современному декларативному подходу. Пока затраты огромны, но со временем ситуация будет меняться. Особенно, если новые проекты будут изначально ориентировать на новый стиль разработки.

Не такой уж и новый подход. О нем Грэм писал в 90-е, а до него, наверное, еще раньше. Новых идей в программировании уже давно нет. Как минимум, более двадцати лет, а, может быть, и больше. Но ничего кардинально не меняется.

собственно, как я и предполагал :)

и да — у меня пример проблем не вызвал, на таком уровне я питон знаю.

Это ФП в чистом виде, правда, с небольшими побочными эффектами. К питону относится постольку-поскольку.

Задача заточена под питонофп.

На F# это будет выглядеть практически также. Поменяем lambda на fun, а list comprehension на sequence или list expression. На Common Lisp будет несколько многословнее, но по духу будет тоже самое. В этом примере питоновским является только синтаксис.

open(f) - открываем файл, получаем файловый объект, который является итерируемым

[ EXPR for l in open(f) if COND ] - получаем список из результатов вычисления выражения EXPR, для l удовлетворяющих условию COND, поскольку l пробегает все строки файлового объекта

l.split() - разбивает строку l на подстроки по пробелам и символам табуляции, возвращает список подстрок

map( float, l.split() ) - действует функцией float (которая делает число из всего из чего может) на все элементы списка l.split(), возвращает список результатов (т.е. список чисел)

l.strip() - удаляет все пробелы, табы и переводы строк сначала и с конца.

Тут объяснять дольше чем делать на питоне, но меньше чем делать на С;-) С-шный код для таких вещей у меня выбивает слезу, это ж надо иметь такие развитые склонности к садо-мазо что бы с Сями над этим трахаться...

это ж надо иметь такие развитые склонности к садо-мазо что бы с Сями над этим трахаться...

Зато понятно: getline + sscanf или же strtok + atof.

Оно понятно, потому что привычно. Потратьте уже неск. часов, прочитайте че нить по питону (руби, яве и тд - к чему душа больше лежит) и будет так же понятно + гораздо короче.

Все равно ведь все эти питоны годятся лишь для временных наколенных поделок. Не больше.

вот это жесть

Еще один, блин.

Учи CL --- он годится

ну если тебе нравится не программировать, а танцевать гопак ...

?

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

Слишком много возьни с деталями, которые не относятся к задаче. Вторые две программы вообще на перле надо делать.

всё правильно говорит. хотя я бы предпочёл что-нибудь на замену C - чисто процедурное, но уровня хотя бы Cyclon

В списке еще Лиспа не хватает :)

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

> В списке еще Лиспа не хватает :)

В списке Лисп и не нужен, а вот модернизированный Си очень не помешал бы.

Его покусал VSL?

А по теме - C++ не нужен.

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

> Помогает. Быстрее поставить бряку в нужном месте и в нужный момент и посмореть переменные чем часами логи разгребать.

У меня три вложенных цикла по 10^3 шагов каждый, в 100500м шаге вылетает сегфолт. Бряка тут увы не поможет... а вот valgrind да.

> А по теме - C++ не нужен.

Продолжайте и дальше информировать нас о том, что Вам нужно а что нет - это жутко интересно и животрепещуще!

Поможет. Бряку можно по кондишену ставить.

> Все равно ведь все эти питоны годятся лишь для временных наколенных поделок. Не больше.

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

Связка С++-питон позволяет в итоге на порядок поднять скорость разработки (по сравнения с просто С++) без потери производительности и делать вещи, к-е на С/С++ вообще фиг сделаешь (типа генерации интерфейса командной строки на основе интроспекции).

Вы башем пользуетесь? Так вот питон в ряде случаев куда удобней.