The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

OpenNews: Сколько языков программирования нужно выучить, opennews (?), 20-Мрт-08, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


16. "Сколько языков программирования нужно выучить"  +/
Сообщение от bsdemon (?), 20-Мрт-08, 17:01 
Ассемблер тут совершенно не причём, с точки зрения решения задач программирования. А вот функциональные языки это сила - вот посмотрите через несколько лет - всё будет написано на них.
Ответить | Правка | Наверх | Cообщить модератору

20. "Сколько языков программирования нужно выучить"  +/
Сообщение от AsphyX (??), 20-Мрт-08, 17:47 
Так говорят с момента их появления :)
Ответить | Правка | Наверх | Cообщить модератору

22. "Сколько языков программирования нужно выучить"  +/
Сообщение от Leshi (ok), 20-Мрт-08, 17:57 
> Ассемблер тут совершенно не причём, с точки зрения решения задач программирования.

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

> А вот функциональные языки это сила - вот посмотрите через несколько лет - всё будет написано на них.

С математической точки зрения "несколько" это больше одного. В этом я согласен полностью. Хотя понятие "несколько" все-таки предполагает конечное количество. Вот с этим не соглашусь :)  Хочу заметить, что функциональные языки никогда не смогут получить широкого распространения. Слишком они сложны для изучения и совсем сложны в приминении. Я скорее поверю, что в обозримом будущем большенство софта будет написано на языках семейства .NET. Хотя узкий круг специализированных задач, особенно инженерных, функциональные языки скорее всего отстоят.

А еще хочу выразить искреннее сожаление, что большенство модных ООязыков не поддерживают множественного наследования. Похоже, что С++ ждет участь функциональных языков. В смысле никто не будет их учить ибо сложно. И они останутся только как примеры "как еще можно вывернуть мозг наизнанку". А все будет писаться на компонентных языках. В смысле "берем ярлычек и тащим его сюда, потом программируем свойства: один, два, тру!".

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

29. "Сколько языков программирования нужно выучить"  +/
Сообщение от thehangedmanemail (ok), 20-Мрт-08, 18:32 
>Хочу заметить, что функциональные языки никогда не
>смогут получить широкого распространения. Слишком они сложны для изучения и совсем
>сложны в приминении.

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

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

А причина по которой широкий интерес к функциональным языкам просыпается именно в наше время лежит на поверхности - доросли мощности. Подавляющее большинство современных языков в той или иной степени поддерживают функциональную парадигму - от того же С++ с его stl/boost/т.п. до ruby/python/java/c#.

>А еще хочу выразить искреннее сожаление, что большенство модных ООязыков не поддерживают
>множественного наследования. Похоже, что С++ ждет участь функциональных языков. В смысле
>никто не будет их учить ибо сложно.

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

Ответить | Правка | Наверх | Cообщить модератору

33. "Сколько языков программирования нужно выучить"  +/
Сообщение от Leshi (ok), 20-Мрт-08, 19:01 
>Насчет сложности в применении - это как-то можно обосновать?

Пожалуйста. Для приминения функциональных языков требуется функциональное мышление. Т.е. глубого технический склад ума. В подавляющем большенстве случаев программисты обладают оным, бесспорно. Теперь берем модель реального мира и смотрим на типичного заказчика софта. Как правило, это человек имеющий деньги и представляющий как работает то, что он хочет автоматизировать. ТЗ, выставляемое заказчиком выглядит потоком сознания. После некоторых преобразований можно разделить предметную область на материальные объекты реального мира. Это совсем не сложно, по сравнению с остальным.
После разделения на объекты реального мира можно, отбросив не важное, перейти к сферическим коням в вакууме, которые уже будут отрожать то, что необходимо написать. Оно все еще объектное. Оно все еще представляет собой набор данных и требуемые действия по преобразованию данных. А вот выполнить переход от преобразования данных к функциям выполнения, основанным на этих данных очень не просто. Самый просто подход в этом случае -- процедурный. Более легкий в сопровождении -- объектный. И ООП как раз ближе к реальному миру, чем к железу.

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

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

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

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

Чушь, простите. ООП кушает больше, чем ФОП.

> Подавляющее большинство современных
>языков в той или иной степени поддерживают функциональную парадигму - от
>того же С++ с его stl/boost/т.п. до ruby/python/java/c#.

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

>Ну, С++ разве так сложен.

Да. Очень. Даже очень-очень.

> Просто слишком много проблем у него [C++] (не буду
>провоцировать флейм, начиная перечислять), которые никому не нужны при наличии альтернативы.

Проблем у С++ крайне не много. Одна из них -- наследственность. От С достались функции и макросы, от которых следовало бы отказаться, но в целях совместимости они сохранены.
Вторая проблема (за что многие критикуют С++) это отсутствие асинхронных вызовов в самом языке.
Треться проблема, которая в целом является родителем второй, но почему-то выделяется как правило в отдельную -- это проблема невозможности прозрачно средствами языка создавать многопоточные и распределенные системы.
И над последними двумя наши люди (ну, вы понимаете) уже работают :)

>Что до множественно наследования, так оно просто коряво в нем реализовано.

Это как раз про "Очень-очень сложный язык". МН реализовано не коряво, а изящно :) Просто это сложно понять.

>В том же хаскелле - намного изящней.

Ответить | Правка | Наверх | Cообщить модератору

37. "Сколько языков программирования нужно выучить"  +/
Сообщение от thehangedmanemail (ok), 20-Мрт-08, 19:33 
>Пожалуйста. Для приминения функциональных языков требуется функциональное мышление. Т.е. глубого технический склад ума.

Хм, а для императивного какой?
Если пойти на компромисс с педантичностью, то функциональное мышление - это декларативное мышление (прошу прощения за утрирование). Декларативное мышление во многом ближе к повседневному человеческому мышлению, чем алгоритмическое.

>Самый просто подход в этом случае -- процедурный.

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

>Более легкий в сопровождении -- объектный. И ООП как раз ближе к
>реальному миру, чем к железу.

Только не нужно ООП противопоставлять функциональному подходу, Вы это напрямую не сделали, конечно, но косвенно так получилось.

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

Почему??? Вот уж где сплошная декларативность, при минимуме алгоритмов.

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

Ну нет, программы на ФЯ короче практически всегда. Возьмите вон xmonad - оконный менеджер на Хаскелле, 500 строк. Ну или контрпример приведите, по возможности общего характера, где ФЯ были бы менее эффективны чем ИЯ (допускаю что приведете, но уверен что не сходу..)

>Чушь, простите. ООП кушает больше, чем ФОП.

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

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

Ничего себе. А я думал императивная. Вы уверены, что понимаете, что такое функциональная парадигма?

>Проблем у С++ крайне не много. Одна из них -- наследственность. От
>С достались функции и макросы, от которых следовало бы отказаться, но
>в целях совместимости они сохранены.

Отказаться от функций?

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

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

Вот уж за что мне не пришло бы в голову критиковать С++)

>И над последними двумя наши люди (ну, вы понимаете) уже работают :)

Что тут скажешь.. верной дорогой идете, товарищи)
Да, кстати, ФЯ и параллелятся лучше (ну, вы понимаете)

>Это как раз про "Очень-очень сложный язык". МН реализовано не коряво, а
>изящно :) Просто это сложно понять.

Практически невозможно) То-то оно и используется повсеместно.

Ответить | Правка | Наверх | Cообщить модератору

47. "Сколько языков программирования нужно выучить"  +/
Сообщение от WhiteWind (??), 20-Мрт-08, 21:03 
> Ну или контрпример приведите, по
>возможности общего характера, где ФЯ были бы менее эффективны чем ИЯ
>(допускаю что приведете, но уверен что не сходу..)

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

И обобщая  и так краткий пост, можно сказать, что везде, где есть процесс, ФЯ неприменимы.

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


Ответить | Правка | Наверх | Cообщить модератору

48. "Сколько языков программирования нужно выучить"  +/
Сообщение от thehangedmanemail (ok), 20-Мрт-08, 21:19 
>Драйвера, прошивки, задачи реального/квазиреального времени (к последним я отношу, допустим, компьютерные игры.

Драйвера и прошивки - в связи со спецификой не языка, а платформ.

Компьютерные игры - уже не согласен, читал о команде разработчиков (название не помню), которая успешно штамповала игры на лиспе (кажется под PlayStation). Возможно еще примеры есть, хотя не сталкивался.

>С играми, кстати, вообще плохо получается, т.к. там повсюду состояния - именно
>то, от чего стремится избавиться функциональная парадигма.

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

>И обобщая  и так краткий пост, можно сказать, что везде, где
>есть процесс, ФЯ неприменимы.

Этого не понял.

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

62. "Сколько языков программирования нужно выучить"  +/
Сообщение от fresco (??), 21-Мрт-08, 09:57 
Ну вы академики, блин :)
Понимаю, где не правы, а сформулировать -- образования походу не хватает.
Ответить | Правка | Наверх | Cообщить модератору

74. "Сколько языков программирования нужно выучить"  +/
Сообщение от jtootf (?), 21-Мрт-08, 18:15 
В играх ФЯ используются на ура - смотри проект Frag, смотри Yampa и FRP вообще. Игровые абстракции без явного описания состояний выражаются куда как лаконичней - так же как и циклы с явным описанием итератора против рекурсии. Касательно состояний и драйверов - смотри House, ОС на Haskell с использованием пи-логики; смотри seL4 и L4.verified в которых Haskell используется для формальной верификации ядра ОС. А если говорить про области применения в общем, то тут в выразительности выигрывают языки, позволяющие легко реализовывать eDSL для каждого модуля с использованием паттерна Layers в полной мере (как единственный вменяемый контрподход для UN*X-way программирования, при котором эти модули связываются уже в виде бинариев с помощью скриптинга) - а это как раз и есть парафия либо ФЯ, либо метаязыков вроде LISP и Tcl (в которых метапрограммирование является базовой парадигмой). Есть что возразить по существу ?
Ответить | Правка | Наверх | Cообщить модератору

82. "Сколько языков программирования нужно выучить"  +/
Сообщение от Leshi (ok), 23-Мрт-08, 04:57 
> Есть что возразить по существу ?

Есть. Если коротко, то Windows, MS-Office, Unix, Oracle. Я могу удлинить список. И если продолжать меряться (с)писками, то мой получиться длинее. И явно известнее. Я вот например впервые услышал о House и seL4. Про игры я не скажу, я ваще не фанат. Но почему Вы решили, что ФЯ лучше подходят для реализации чего-то вцелом (о, боже, даже оси!), чем процедурные или объектные языки привидя пример чего-то малоизвестного и очень похожего на сферического коня в вакууме?
То, что с помощью ФЯ можно реализовать что угодно тут уже доказали. И что-то мне подсказывает, что если сравнить результаты, которые получились у ФЯ и ПЯ, то мы увидим перевес в сторону ПЯ по простоте сопровождения, функциональности и быстродействию. Ну, по крайней мере мне так кажется, я сравнивал xmonad с metacity. По двум параметрам, правда, но мне этого хватило. Первый это как изменить внешний вид и второй а сколько оно проработает без явных глюков. Метасити победил с явным отрывом.

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


Ответить | Правка | Наверх | Cообщить модератору

102. "Сколько языков программирования нужно выучить"  +/
Сообщение от Аноним (-), 04-Дек-16, 05:16 
> ...я сравнивал xmonad с metacity. По двум параметрам, правда, но мне этого хватило. Первый это как изменить внешний вид и второй а сколько оно проработает без явных глюков. Метасити победил с явным отрывом.

Уважаемый вы выдаете желаемое за действительное. Если с функциональным программированием проблемы, тогда да, заточить xmonad под себя весьма сложно, но по поводу работы без глюков... Я использую xmonad уже больше 3-х лет, настроил под себя и просто не нарадуюсь, как быстро и беспроблемно все работает.
Повторю - БЕСПРОБЛЕМНО!!!

Ответить | Правка | Наверх | Cообщить модератору

66. "Сколько языков программирования нужно выучить"  +/
Сообщение от Leshi (ok), 21-Мрт-08, 15:38 
> Декларативное мышление во многом ближе к
>повседневному человеческому мышлению, чем алгоритмическое.

Было бы оно ближе, появилось бы раньше :) На самом деле не ближе. Человеку свойственно создавать алгоритмы. И было свойственно еще до появления математики в современном понимании. Пример? Кулинарные рецепты, религиозные обряды. Сделай то и то, и получишь вот это. Это алгоритмическое мышление.

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

Ну, как можно (мне кажется) понять из остального моего поста, мне таки ближе ООП. А про процедурность это я из собственного опыта и наблюдения за начинающими говорю.

>>Более легкий в сопровождении -- объектный. И ООП как раз ближе к
>>реальному миру, чем к железу.
>Только не нужно ООП противопоставлять функциональному подходу, Вы это напрямую не сделали,
>конечно, но косвенно так получилось.

Секундочку. Я не противопоставляю. Я говорю, что для решения задач, связанных с моделированием нестрогих процессов реального мира больше подходит ООП. Для моделирования строгих процессов (расчет деформации при ударе, например) больше подойдет ФЯ.

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

Где? О_О Там столько возможных вариантов ветвления, что памяти, основанной на состоянии атомов всей вселенной не хватит для реализации требуемых вычислений :) При этом некоторые параметры как правило не определены или могут меняться в широких пределах.

>>Хе, широко распространенное в узких кругах. ФЯ короче, пока на них пишутся
>>алгоритмы функционального поведения. Это скорее синтетические алгоритмы, мир на много сложнее.
>Ну нет, программы на ФЯ короче практически всегда. Возьмите вон xmonad -
>оконный менеджер на Хаскелле, 500 строк. Ну или контрпример приведите, по
>возможности общего характера, где ФЯ были бы менее эффективны чем ИЯ
>(допускаю что приведете, но уверен что не сходу..)

xmonad -- это один из самых неудачных примеров программирования на ФЯ. Кроме того, оконный менеджер это скорее синтетический алгоритм. В смысле узко определенный круг задач. Да еще и возможности несколько недотягивают до современного уровня. Или не слабо дописать xmonad до полноценной замены компизу? ;) Шутка. Сходу, Вы правы, не приведу пример. Не потому, что лень думать, а потому, что не использовал ФЯ в реальных задачах. У меня небыло такой необходимости. Хотя функциональную парадигму в обработке реакций пользователя в интерфейсах я использую. Там она хорошо ложится.

>>Чушь, простите. ООП кушает больше, чем ФОП.
>Во-первых, опять же - не надо противопоставлять ООП и ФОП. Во-вторых, почему
>больше? Обоснуйте. ФОП со своими списками да рекурсиями естественно жрет больше
>(памяти).

В ФОП совсем не обязательно использовать списки. Это кажется начинание лиспа было. И, по большому счету, является протезом для решения более широкого круга задач. Рекурсия используется, но при правильном подходе ее глубина не сильно важна. По сравнению с этим виртуальные функции, шаблоны, рефлекшены и исключения поглатят больше. Хотя, если на ФЯ писать базы данных, то скорее всего в битве у кого длинее стек победят функционалы :)

>
>>Функциональная парадигма изначально заложена во всех языках программирования, ибо она лежит в
>>основе любой железки с логикой.
>Ничего себе. А я думал императивная. Вы уверены, что понимаете, что такое
>функциональная парадигма?

Уверен. Императивная парадигма там тоже есть. И особо удивляться не надо. Их там две :)
Когда мы меняем регистры -- это императивно. Когда мы обращаемся к внешнему оборудованию -- это функционально. Ибо внешнее оборудование никак не влияет на состояние АЛУ.

>>Проблем у С++ крайне не много. [...]
>>от С достались функции и макросы, от которых следовало бы отказаться [...]
>Отказаться от функций?

Что так удивляет? В Java нет функций. Есть методы. И в их пользу надо бы отказатиься. Ну, это конечно только чтобы добиться более строгого соблюдения принципов ООП.

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

Это далего не бесспорный минус. Я бы сказал, что это скорее плюс.

>>[...] отсутствие асинхронных вызовов в самом языке. [...]
>>[...] невозможности прозрачно средствами языка создавать
>>многопоточные и распределенные системы.
>Вот уж за что мне не пришло бы в голову критиковать С++)

Ну, конечно, каждому свое, но в целом это сдерживает переносимость программ на С++ между платформами в современных условиях.

>>И над последними двумя наши люди (ну, вы понимаете) уже работают :)
>Что тут скажешь.. верной дорогой идете, товарищи)
>Да, кстати, ФЯ и параллелятся лучше (ну, вы понимаете)

Ещебы, паралеллизм у ФОП в крови.

>>Это как раз про "Очень-очень сложный язык". МН реализовано не коряво, а
>>изящно :) Просто это сложно понять.
>Практически невозможно) То-то оно и используется повсеместно.

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

Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

73. "Сколько языков программирования нужно выучить"  +/
Сообщение от thehangedmanemail (ok), 21-Мрт-08, 18:04 
>Было бы оно ближе, появилось бы раньше :)

А я ошибусь, если скажу что lisp - старейший из "живых" языков программирования? (точно не уверен, но сдается мне так оно и есть)

>Секундочку. Я не противопоставляю. Я говорю, что для решения задач, связанных с
>моделированием нестрогих процессов реального мира больше подходит ООП. Для моделирования строгих
>процессов (расчет деформации при ударе, например) больше подойдет ФЯ.

Я имел в виду, что функциональную парадигму можно противопоставлять императивной, но не ООП. На функциональных языках можно писать объектно-ориентированно. На тех где нельзя писать классически объектно-ориентированно - есть свои способы создания объектных абстракций.

>Где? О_О Там столько возможных вариантов ветвления, что памяти, основанной на состоянии
>атомов всей вселенной не хватит для реализации требуемых вычислений :) При
>этом некоторые параметры как правило не определены или могут меняться в
>широких пределах.

Не понял, почему для ИЯ хватит а для ФЯ нет, если к тому же ниже утверждается, что ИЯ жрет больше. Причем тут ветвление? замените ветвление на сопоставление с образцом, и получите декларацию.

Вот встречный вопрос - где там алгоритмы. Сплошные данные и декларации.

>В ФОП совсем не обязательно использовать списки. Это кажется начинание лиспа было.
>И, по большому счету, является протезом для решения более широкого круга
>задач. Рекурсия используется, но при правильном подходе ее глубина не сильно
>важна. По сравнению с этим виртуальные функции, шаблоны, рефлекшены и исключения
>поглатят больше.

Алгебра списков - протез? Ну и ну. А что тогда STL?) И - все-таки, для ФЯ это основной тип данных.
А вот упомянутые шаблоны - да, протез, причем на редкость кривой) да и то как они что-то поглотят, они ж компайл-тайм. Да и остальное тоже сомнительно.

Глубина рекурсии, естественно, очень важна, другое дело что при правильном подходе она в цикл разворачивается компилятором и рекурсии не будет.

>Уверен. Императивная парадигма там тоже есть. И особо удивляться не надо. Их
>там две :)
>Когда мы меняем регистры -- это императивно. Когда мы обращаемся к внешнему
>оборудованию -- это функционально. Ибо внешнее оборудование никак не влияет на
>состояние АЛУ.

Хм, нет. Это все императивно, это строго определенная последовательность действий с передачей управления от одного к другому. Никакой функциональной парадигмы там и в помине нет. Сохранение состояния тут роли не играет.

>Что так удивляет? В Java нет функций. Есть методы. И в их
>пользу надо бы отказатиься. Ну, это конечно только чтобы добиться более
>строгого соблюдения принципов ООП.

А С++ - не полностью ООП-ориентированный язык, он, как тут справедливо писали, претендует на универсальность. Поэтому там подобное неуместно. Зачем делать из него яву? А то пусть там все типы данных, включая примитивные, объектными будут, как в smalltalk. Почему б нет. Для более строгого соблюдения.

>Ни с чем не путаете? Множественность интерфейсов и множественное наследование хоть и
>родственнеки, но все же разные вещи. Я вот так сходу, даже
>подумав, не могу вспомнить ни одну широко известную библиотеку для С++,
>которая бы использовала множественное наследование.

Так в ту фразу очевидный сарказм был заложен) Потому и не используется, что кривизна. И видимо совсем уж полная кривизна, потому что страсть зеалотов С++ к использованию кривых инструментов для создания головоломок - притча во языцех)

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

Ответить | Правка | Наверх | Cообщить модератору

76. "Сколько языков программирования нужно выучить"  +/
Сообщение от Leshi (ok), 21-Мрт-08, 20:06 
>>Было бы оно ближе, появилось бы раньше :)
>
>А я ошибусь, если скажу что lisp - старейший из "живых" языков
>программирования? (точно не уверен, но сдается мне так оно и есть)

http://people.ku.edu/~nkinners/LangList/Extras/famous.htm
Я в истории не силен, но судя по всему, все-таки фортран старее.
Живость его можно подтвердить в любом отечественном НИИ.


[.. Проскипано без возражений ..]

>>Где? О_О Там столько возможных вариантов ветвления, что памяти, основанной на состоянии
>>атомов всей вселенной не хватит для реализации требуемых вычислений :) При
>>этом некоторые параметры как правило не определены или могут меняться в
>>широких пределах.
>
>Не понял, почему для ИЯ хватит а для ФЯ нет, если к
>тому же ниже утверждается, что ИЯ жрет больше. Причем тут ветвление?
>замените ветвление на сопоставление с образцом, и получите декларацию.

Во! Я кажется начинаю понимать суть проблемы :) Вы пытаетесь применить ФОП ко всему подряд. Это и вызывает утверждение, что ФЯ потребляет больше ресурсов. Да, на определенном классе задач, для которых ФЯ не предназначены, ресурсы будут потребляться сильно. Зато на своем поле им нет равных (ИИ, например, проще всего реализовывать на ФЯ)

>Вот встречный вопрос - где там алгоритмы. Сплошные данные и декларации.

Алгоритмы? Хм.. Ну что-нибудь алгебраическое... Алгоритм расчета продажной цены товара исходя из себестоимости, затрат на логистику, комиссии менеджеру, супсидирования рекламных компаний, колебаний курса валюты и репутации партнера. А теперь нужна вилка "от" и "до" при известной себестоимости. И еще хочу, чтобы любой из этих параметров можно было по отдельности задавать или не задавать. А еще чтобы вилка вычислялась с учетом прошлых продаж человека, который сейчас заполняет заявку. А еще хочу, чтобы опционально учитывалась или не учитывалась динамика роста каждого из этих параметров.
Это из жизни. Было реализовано. Было не просто, особенно с удовлетворением постоянно растущих "хочу".
Просто на ФЯ каждое дополнительное "хочу" прибавляет расход памяти, не сопоставимый с решаемой задачей. Кроме того, потребуется несопоставимо больше переделывать с каждым "хочу" (хотя здесь могу ошибаться, не силен). И уж точно последнее "хочу график динамики продаж в реальном времени" убивает всю идею использования ФЯ, ибо циклы не предусмотренны парадигмой. А бесконечный цикл, реализованный рекурсией, как не сложно догадаться убивает машину, на которой запускается.

>Алгебра списков - протез? Ну и ну. А что тогда STL?)

Именно протез. Переход из одномерного пространства в n-мерное. Это как комплексные числа. Вроде они есть, но это существо виртуальное.
А STL -- плод весьма больного воображения наших соотечественников. Причем, не первый, который оказался весьма удачным. Вообще, идеалогия шаблонов в принципе это попытка уйти от строгой типизации данных, сохранив ее. Мне кажется, удачная попытка для первого раза.

> И - все-таки, для ФЯ это основной тип данных.

Бесспорно. Иначе на них не решить нематематических задач. И математические не все.

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

Они компил-тайм в текущей реализации. Стандарт не накладывает никаких ограничений на этот счет. Стандарт вообще не заставляет компилировать код на С++ в бинарный. Стандарт определяет только поведение написанной программы.
Если бездумно пользоваться шаблонами, то минимальный код превращается в кучу бинарного мусора, делающего одно и то же со смежными типами данных. Так что шаблон шаблону рознь.

Ну и раз уж зашла речь о кривизне, можно поинтересоваться, а что Вы посоветуете использовать вместо шаблонов? И вообще, для начала давайте определимся, понимаете ли Вы всю широту решаемых с помощью шаблонов задач? Вы знаете, что шаблоны могут быть рекурсивными? Вы знаете, что с помощью шаблонов можно вычислить факториал, например (это из книжки про шаблоны)? Я не хочу Вас обидеть, просто у меня складывается ощущение, что мы разговариваем об одном и том же, но стоя с разных сторон одной планеты (- Это вы там ходите вверх ногами! - Нет! У нас небо сверху, а вы ходите ногами к нашим ногам, значит у вас небо снизу!).
Просто я не считаю себя гуру функционального программирования. Я его изучал как хобби. Основные мысли мне ясны, я ими проникся и примитивные вещи иногда использую в практической работе. Зато С++ мой родной язык, о котором я думал много плохого, пока его изучал, но когда привык к мышлению в стиле ООП стало легко и просто. И многих вещей из С++ мне сейчас нехватает, ибо занимаюсь другими вещами.

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

Будем считать, что как защитник ФОП Вы сморозили глупость :) Ибо как защитник Вы должны отстаивать идеалы ФОП, а не перекладывать на компилятор более оптимальную реализацию на процедурном языке.
Если все-таки это нетак, так чего бы сразу не написать цикл и не ломать голову?

>Хм, нет. Это все императивно, это строго определенная последовательность действий с передачей
>управления от одного к другому. Никакой функциональной парадигмы там и в
>помине нет. Сохранение состояния тут роли не играет.

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


>А С++ - не полностью ООП-ориентированный язык, он, как тут справедливо писали,
>претендует на универсальность. Поэтому там подобное неуместно.

А вот и зря. Ему было бы легче.

> Зачем делать из него
>яву? А то пусть там все типы данных, включая примитивные, объектными
>будут, как в smalltalk. Почему б нет. Для более строгого соблюдения.

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

>[оверквотинг удален]
>>родственнеки, но все же разные вещи. Я вот так сходу, даже
>>подумав, не могу вспомнить ни одну широко известную библиотеку для С++,
>>которая бы использовала множественное наследование.
>Так в ту фразу очевидный сарказм был заложен) Потому и не используется,
>что кривизна. И видимо совсем уж полная кривизна, потому что страсть
>зеалотов С++ к использованию кривых инструментов для создания головоломок - притча
>во языцех)
>
>В отличие от множественного наследования интерфейсов, да. Удобный механизм, и применяется в
>разных языках без особых проблем.

:) Можно я вместо ответа на эту часть личный вопрос задам? Можете не отвечать, но мне просто интересно. Вы ведь не участвовали в крупных коммерческих проектах на С++. Причем именно на С++, это важно. Соответственно Вы не могли использовать множественное наследование в полную силу на протяжении долгого времени и посмотреть на чужой код, в котором реализовано это множественное наследование. Исходя из этого, и того, что Вы утверждаете, что МН и шаблоны в С++ реализованы криво (я верю, что это только из-за недостатка опыта) и так хорошо ориентируетесь в ФЯ и ФОП в частности могу предположить два варианта: либо Вы научный работник (аспирант, например), либо инженер AutoCAD. Я прав?

Ответить | Правка | Наверх | Cообщить модератору

77. "Сколько языков программирования нужно выучить"  +/
Сообщение от thehangedmanemail (ok), 22-Мрт-08, 00:40 
>Я в истории не силен, но судя по всему, все-таки фортран старее.

Возможно, я не был уверен)

>Во! Я кажется начинаю понимать суть проблемы :) Вы пытаетесь применить ФОП
>ко всему подряд. Это и вызывает утверждение, что ФЯ потребляет больше
>ресурсов.

Нет, пока не пытаюсь, а утверждение что ФЯ потребляет больше ресурсов было почерпнуто из литературы и принято, каюсь, на веру.

>Алгоритмы? Хм.. Ну что-нибудь алгебраическое...

Алгебраическое - это формулы) Для них ФЯ - естественный выбор.

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

И то и другие - непонятно, почему.

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

Так рекурсия разворачивается в цикл, см. ниже..

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

Я не понял, Вы STL тут похвалили или нет? Что касается строгой типизации данных, то модель типизации Хиндли-Милнера, безусловно, удачнее. Да и старее)

>Они компил-тайм в текущей реализации.

Так а мы о потреблении памяти в какой реализации говорили, будущей? Впрочем, это несущественный момент.

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

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

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

Да, да, читал я Ваши "книжки про шаблоны", честно. Я помню каким культурным шоком было для меня чтение Мейерса, Александреску, копание в исходниках boost и loki. Я действительно считал С++ великим языком. А потом было просветление, когда оказалось, что на свете есть языки программирования, которые могут то же самое, но без этих evil mind tricks. Более того, оказалось что теперь, с новым знанием, эти трюки оказались возможны да почти на любом языке программирования, я для тренировки даже реализовал синтаксически-естественные лямбда-функции, list comprehensions и определения функций через сопоставления с образцом на, прошу прощения, Delphi, без всяких шаблонов (правда, признаю, и без сохранения компайл-тайм типизации). Я не призываю Вас следовать за мной по этому пути, но давайте не будем считать шаблонные извращения чем-то эзотерическим и массовому пониманию недоступным.

>но когда привык
>к мышлению в стиле ООП стало легко и просто. И многих
>вещей из С++ мне сейчас нехватает, ибо занимаюсь другими вещами.

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

>Будем считать, что как защитник ФОП Вы сморозили глупость :) Ибо как
>защитник Вы должны отстаивать идеалы ФОП, а не перекладывать на компилятор
>более оптимальную реализацию на процедурном языке.

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

И никакой я не защитник ФЯ, я скорее вступился за идеи высказанные в комментируемой статье.

>Если все-таки это нетак, так чего бы сразу не написать цикл и
>не ломать голову?

Да вспомните классический пример - реализацию быстрой сортировки в одну-две строки на любом ФЯ.. Разве это не убедительный аргумент в пользу того чтоб не ломать голову циклами?)

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

Сарказм, да. И, кстати, С++ в этом не одинок. Таких больших библиотек куча для большинства императивных нединамических языков, которые думают, что они ООП. По каждому поводу и без повода - пытаются все обобщить, будь то сериализация, RPC, RTTI, etc.. С разной степенью успешности. И каждый язык использует для этого свои козыри, свою мощь.. С++ - шаблоны, Delphi - RTTI..

>:) Можно я вместо ответа на эту часть личный вопрос задам? Можете
>не отвечать, но мне просто интересно. Вы ведь не участвовали в
>крупных коммерческих проектах на С++.

В коммерческих на С++ - да, в относительно крупных - да, в крупных коммерческих на С++ - нет.

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

Что до множественного наследования, то его и без меня немало критикуют, не буду распространяться.

>либо Вы научный
>работник (аспирант, например), либо инженер AutoCAD. Я прав?

Не прав.. Да и в ФЯ не особо хорошо ориентируюсь, вон jtootf написал комментарии - видно что ориентируется, а я так, учусь.

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

Ответить | Правка | Наверх | Cообщить модератору

79. "Сколько языков программирования нужно выучить"  +/
Сообщение от Leshi (ok), 23-Мрт-08, 04:23 
Славный был холивор :) Но я таки в одной фразе резюмирую свое мнение.

Есть много языков программирования. И для каждой задачи найдется свой.

Ответить | Правка | Наверх | Cообщить модератору

55. "Сколько языков программирования нужно выучить"  +/
Сообщение от serg1224 (ok), 20-Мрт-08, 23:48 
>Именно ассемблер
>позволяет понять как сделать алгоритм более быстрым и менее требовательным.

Часто от ПРИКЛАДНОГО (НЕмашинного) языка требуется другое. Например, свести к минимуму ошибки кодировщика, повысить читабельность текста, уменьшить время изучения, приблизить язык к предметной области. Не надо забывать и о смене поколений программеров и групповой разработке, когда приходиться иметь дело с чужим кодом.

Перед учеными, коммерсантами, военными, медиками и производителями железа стоят ОЧЕНЬ разные задачи и решают их с помощью РАЗНЫХ языков программирования. Иначе бы мы до сих пор дырочки в перфокартах сверлили :-)

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

23. "Сколько языков программирования нужно выучить"  +/
Сообщение от Аноним (23), 20-Мрт-08, 18:00 
Ну - ну ... "через 10 лет театров не будет!"(С) ~1963
Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру