[Опрос] Какие языки программирования вы знаете?

[Андрей]

По теме: на данный момент (JRE версии 6 и выше от Sun) мало чем уступает C/C++ в производительности. Более того, множество последних тестов доказывают, что Java в большинстве случаев быстрее C++, и лишь немногим отстает по быстродействию от C.

И где вам только мозги промывают, жабофилам-то...

Что касается памяти, то таки да, ввиду того, что сама JVM отнимает часть памяти при загрузке приложения + потребляется память, выделяемая под загрузку стандартной библиотеки, Java-приложения потребляют больше памяти, чем, к примеру, приложения написанные на C++. Но не в 10 же раз! Раза в два, не более.

Несинтетические тесты в компании, где я в данный момент работаю, показали обратное. Причем случилось это 1,5 года назад, использовались jre 1.5 и gcc 4.1.1 (или 4.1.2, точно не скажу). Перед началом большого проекта (в который уже вложено более 50 000 человеко-часов) была написано два одинаковых по функционалу приложения, одно -- адептом плюсов, другое -- адептом жабы. Результаты были не в пользу жабки, она использовала в 8 раз больше ОЗУ и была в два раза медленнее. Но мы ведь должны ориентироваться не на результаты реальных тестов в реальных условиях, а на статьи маректологов Sun, так ведь?
К слову, я на дух не переношу плюсы, пишу на Python и C, иногда Scheme и OCaml, раньше немного Haskell. Так вот, если бы мне довелось выбирать между C++ и Java, я бы выбрал меньшее из зол, а именно плюсы, по приведенным выше причинам.

Пара линков (дальше сами googлите и читайте WikiPedia ):

http://en.wikipedia.org/wiki/Java_performance
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

А вот такое видели?

P.S. Авторы последней статьи, как мне кажется, сделали любопытный вывод (с которым я, пожалуй, соглашусь). И это по состоянию на 2003 год... Сейчас с производительностью и потреблением памяти у Java дела обстоят значительно лучше. Хочу лишь сказать: не становитесь жертвой стереотипов.

"Давайте Вы не будете указывать как мне жить, а я Вам не буду указывать куда идти". Жертвой стереотипов, а точнее, маркетологов стали Вы. Существует множество ЯП, превосходящих Java (да и C++) по многим параметрам. Да, у Java есть некий сектор, и называется он (лично мне неприятным) словом Enterprise. Желаю Вам удачи в пропагандировании сего ЯП.

[kion]

И где вам только мозги промывают, жабофилам-то...

Про промывание мозгов - будьте поаккуратней на поворотах, товарищ.

Я перечитал не одни тесты перед тем, как сформировать свое мнение. Из них - не припомню ни одного непосредственно от Sun.

Если б вы уделили минутку времени на просмотр тех нескольких ссылок, которые я подал в качестве примера, то увидели бы, то источники - это WikiPedia (да, Sun могла приложить руку к "народному" ресурсу, но навряд ли все там написано ее маркетологами) и Калифорнийский Институт "Computer Graphics and Immersive Technology Lab".

Извините, конечно, но на фана здесь больше вы похожи (и, похоже, вам везде мерещятся маркетологи ).

Несинтетические тесты в компании, где я в данный момент работаю, показали обратное. Причем случилось это 1,5 года назад, использовались jre 1.5 и gcc 4.1.1 (или 4.1.2, точно не скажу). Перед началом большого проекта (в который уже вложено более 50 000 человеко-часов) была написано два одинаковых по функционалу приложения, одно -- адептом плюсов, другое -- адептом жабы. Результаты были не в пользу жабки, она использовала в 8 раз больше ОЗУ и была в два раза медленнее.

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

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

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

Так я не пропагандировал всеобщий переход на Java. Нравится C++? Python? Ruby? Програмируйте себе на здоровье на любом ЯП. Не надо только "унижать" остальные языки, чтобы убедить самого себя, что язык на котором программируете вы - лучше.
P.S. Лично для меня Java - более интересный ЯП хотя бы только потому, что он кросс-платформенный. Но всегда есть две стороны медали. Для конкретного задания нужно выбирать конкретный инструмент, лучше всего подходящий для достижения целей этого задания.

А вот такое видели?

А вот это действительно непонятно что и непонятно от кого

НО! Я ведь не говорю, что Java - всегда быстрее C/C++. Многое зависит от параметров самого теста. Я говорил про большинство случаев, и вот как раз здесь, все свидетельствует о том, что Java таки немного впереди (между прочим, кроме "официальных" тестов, я перечитал множество независимых, выполненных обычными програмистами, работающими с каждым из языков, которые сравнивались, плюс коментарии публики, так что это обоснованные слова).

"Давайте Вы не будете указывать как мне жить, а я Вам не буду указывать куда идти". Жертвой стереотипов, а точнее, маркетологов стали Вы. Существует множество ЯП, превосходящих Java (да и C++) по многим параметрам. Да, у Java есть некий сектор, и называется он (лично мне неприятным) словом Enterprise. Желаю Вам удачи в пропагандировании сего ЯП.

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

Что до Enterprise Java - что ж,  вы сами ответили на вопрос... На данный момент, Java - ЯП №1 в мире по распостранению (количеству занятых специалистов). Тут есть два варианта: либо спецы всего мира сошлись на том, что для Enterprise уровня Java - лучший инструмент, либо... всех их купила Sun. Верьте во что хотите

[βεερ_βooρ]

Что до Enterprise Java - что ж,  вы сами ответили на вопрос... На данный момент, Java - ЯП №1 в мире по распостранению (количеству занятых специалистов). Тут есть два варианта: либо спецы всего мира сошлись на том, что для Enterprise уровня Java - лучший инструмент, либо... всех их купила Sun.

Больше - не значит лучше.  Почитай The definition of the TIOBE index
Количество занятых специалистов там никто не считает.
Если считать именно к-во то по сатистике  Freshmeat Java Максимум второй 

[kion]

Больше - не значит лучше.  Почитай The definition of the TIOBE index
Количество занятых специалистов там никто не считает.

Ну вобщем-то непосредственно на странице, на которую я дал ссылку, вверху (в предисловии) сказано:

The ratings are based on the number of skilled engineers world-wide, courses and third party vendors.

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

Если считать именно к-во то по сатистике  Freshmeat Java Максимум второй 

Согласен, среди открытых проектов, Java не особо популярен (хотя я сам, например, являюсь автором open source проекта на Java ). Это потому, что его основной уклон - Enterprise Level Applications, которые, к сожалению, в абсолютном большинстве случаев проприетарны...

[βεερ_βooρ]

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

The ratings are calculated by counting hits of the most popular search engines

The number of hits determine the ratings of a language.

То им кажется что они считают специалистов. На самом деле они в прямом смысле слова считают "упоминания в прессе".

[kion]

То им кажется что они считают специалистов. На самом деле они в прямом смысле слова считают "упоминания в прессе".

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

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

[βεερ_βooρ]

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

Тогда в рейтинге явно нехватает Algol68 и значительно недооценен Фортран.

Впрочем, я не говорю, что данный индекс - точный ориентир.

Это очень неточный ориентир. Просто статей как в VB сделать калькулятор или как о новых фичах Java6 намного больше чем об использовании Lisp или Haskell для Quantum computing. Enterpris-y не нужно функциональное программирование и высокие материи - им надо что бы работало здесь и сейчас. В совокупности с активным проталкиванием Java в прессе это способствует намного большему количеству публикаций о написании Yet Another Corporate App, чем о чем-то высоком.

Рекламма - двигатель прогресса далеко не всегда.

[kion]

Тогда в рейтинге явно нехватает Algol68 и значительно недооценен Фортран.

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

Это очень неточный ориентир. Просто статей как в VB сделать калькулятор или как о новых фичах Java6 намного больше чем об использовании Lisp или Haskell для Quantum computing. Enterpris-y не нужно функциональное программирование и высокие материи - им надо что бы работало здесь и сейчас. В совокупности с активным проталкиванием Java в прессе это способствует намного большему количеству публикаций о написании Yet Another Corporate App, чем о чем-то высоком.

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

Рекламма - двигатель прогресса далеко не всегда.

Что-то я не пойму, почему все говорят про рекламу и маркетинг когда речь идет о Java... Неужели вы думаете, что успех Java основан исключительно на результатах маркетинговых компаний Sun?

[βεερ_βooρ]

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

Прикол в том, что Algol68 всегда был популярен в научной литературе. И если составлять результат поиска для публикаций ACM, то Algol68  будет побеждать с большим отрывом. Это к вопросу о объективности использования методики TIOBE.

А я вот считаю, что функциональное программирование - это не "высокие материи".

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

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

Это ООП более гибкое и абстрактное? Не смешите.

Что-то я не пойму, почему все говорят про рекламу и маркетинг когда речь идет о Java... Неужели вы думаете, что успех Java основан исключительно на результатах маркетинговых компаний Sun?

Не исключительно, но в значительной степени.

[βεερ_βooρ]

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

[Varik]

Pascal школа рулит)))

[kion]

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

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

Это ООП более гибкое и абстрактное? Не смешите.

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

[βεερ_βooρ]

Для меня уровень мат-культуры - вообще не признак хорошей культуры программирования.

Ха! Кто бы говорил:

(которую лично я, в отличие от логики (да-да, я их различаю), терпеть не перевариваю).

Да и вообще, не люблю когда математику мешают с программированием. Это абсолютно разные вещи.

Вот тут перечислена парочка людей, смыслящих хоть что-то в программировании и считающих иначе.

Программировать я могу без малейшего знания математики

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

Так вот... функциональное программирование - это вообще не высокие материи (если мы говорим о программировании, а не о математике).

А математика неотрывна от программирования, как бы ты не хотел.

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

Бред. А кстати что такое "суть само программирование"? Прям дао какое-то.

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

Пришел пророк ООП kion и просветил меня в наличии в ООП тахих принципов как абстракция, инкапсуляция и полиформизм. А теперь вполне естественный вопрос: При чем тут это к моему высказыванию:

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

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

Заинтригован.
А можно список этих самых людей, смыслящих хоть что-то в программировании?
1. kion
2. ?

[kion]

Ха! Кто бы говорил:  :PВот тут перечислена парочка людей, смыслящих хоть что-то в программировании и считающих иначе.

Ну и при чем здесь ACM?
Его победители считают иначе?
Где это написано (и кем именно высказано)?
Ссылки в студию
С таким же успехом тот же самый линк мог дать я

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

Если уж так абстрагироваться, то все мы подставляем цифры в формулы...

Бред. А кстати что такое "суть само программирование"? Прям дао какое-то.

Ну да, ну да. Что-то вроде того
Для меня программирование - это суть высокоуровневая ЛОГИКА (АБСТРАКЦИЯ) и низкоуровневая РЕАЛИЗАЦИЯ.

Пришел пророк ООП kion и просветил меня в наличии в ООП тахих принципов как абстракция, инкапсуляция и полиформизм.

Наследование и композицию забыл 

А теперь вполне естественный вопрос: При чем тут это к моему высказыванию...

Ты что-то напутал с порядком высказываний. Это был ответ на:

Это ООП более гибкое и абстрактное? Не смешите.

Заинтригован.
А можно список этих самых людей, смыслящих хоть что-то в программировании?
1. kion
2. ?

Не буду поддаваться на провокации. В мире программирования это факт: ООП более абстрактно и гибко, чем ФП.

Но давайте не будем холиварить. Просто попробуем обосновать свои доводы (да, и поспокойней, плиз, - без провокационных резких высказываний).

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

[FalseMan]

Для меня программирование - это суть высокоуровневая ЛОГИКА (АБСТРАКЦИЯ) и низкоуровневая РЕАЛИЗАЦИЯ.

...

Так как же они (ФЯП) могут предоставлять более высокий уровень абстрактности и гибкости, чем ООЯП?

В ООЯП приходится задумываться над реализацией .

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

[kion]

В ООЯП приходится задумываться над реализацией .

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

Как раз в ООЯП в большинстве случаев НЕ приходится задумываться над реализацией, так как правильнее вынести ее на абстрактный уровень. Более того, это дает свободу выбора любой реализации алгоритма без "вшивания" зависимости от одной конкретной реализации (архитектурный паттерн Strategy вам в помощь).

[βεερ_βooρ]

Ну и при чем здесь ACM?
Его победители считают иначе?
Где это написано (и кем именно высказано)?
Ссылки в студию
С таким же успехом тот же самый линк мог дать я

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

Если уж так абстрагироваться, то все мы подставляем цифры в формулы...

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

Для меня программирование - это суть высокоуровневая ЛОГИКА (АБСТРАКЦИЯ) и низкоуровневая РЕАЛИЗАЦИЯ.

При таком раскладе:

Да и вообще, не люблю когда математику мешают с программированием. Это абсолютно разные вещи.

Программирование для тебя низкоуровневая РЕАЛИЗАЦИЯ, которая реализует высокоуровневую АБСТРАКЦИЮ, которую ты не понимаешь, и не собираешься понять - вам это неинтересно. Тут дао и не пахнет 

Не буду поддаваться на провокации. В мире программирования это факт: ООП более абстрактно и гибко, чем ФП.

Значит поттверждение своих слов выгуглить не смог, что и неудивительно. Засчитывать слив?

Но давайте не будем холиварить. Просто попробуем обосновать свои доводы (да, и поспокойней, плиз, - без провокационных резких высказываний).

Я жду:

ООП более абстрактно и гибко, чем ФП.

Данное утвердение крайне нетривиально и требует доказательства. Более того - оно неверно.

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

Отсутствие математической культуры сказывается...
Всего 338 байт а уже 2 серьезных "проседания" в логической части.
1) Именно эти принципы подразумевают более высокий уровень абстракции
Потрудился бы уже указать более высокий уровень абстракции по сравнению с ЧЕМ.
2) и, соответственно, гибкости
С этим я спорить буду. Ибо это верно только наполовину.

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

Помимо степени абстракции(от которой напрямую зависит сфера применимости) гибкость подразумевает минимализм и простоту. А вот с минимализмом у ООП боооольшие проблемы.

В функциональных ЯП все это отсутствует по определению.

Не по определению, а за ненадобностью.

Так как же они (ФЯП) могут предоставлять более высокий уровень абстрактности и гибкости, чем ООЯП?

*тонко намекаю* Помимо ООП есть другие высокоуровневые абстракции...

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

О большем уровне абстракции ООП, чем у ФП - это еще более неверное утверждение.

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

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

[kion]

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

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

При таком раскладе:Программирование для тебя низкоуровневая РЕАЛИЗАЦИЯ, которая реализует высокоуровневую АБСТРАКЦИЮ

Ну вот, вы сами к этому наконец-то пришли

, которую ты не понимаешь, и не собираешься понять - вам это неинтересно. Тут дао и не пахнет 

Пез перехода на личности и оскорблений. Кто тут что не понимает не мне/вам судить. Дискуссия и только дискуссия (и, может быть, она и родит истину). Вы ведь взрослый человек а не фанбой, верно?

Значит поттверждение своих слов выгуглить не смог, что и неудивительно. Засчитывать слив?

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

Впрочем, для понимания вопроса хватает банальной WikiPedia:

http://ru.wikipedia.org/wiki/Объектно-ориентированное_программирование
http://ru.wikipedia.org/wiki/Функциональное_программирование

Читайте и просвещайтесь, там все написано.

Но специально для вас, раз для вас это так принципиально, я сделаю пару цитат:

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

Из статьи об ООП:

...
Основные понятия

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

(в статье о ФП упоминания об абстракции отсутствуют как таковые)

Я жду:Данное утвердение крайне нетривиально и требует доказательства. Более того - оно неверно.Отсутствие математической культуры сказывается...

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

Помимо степени абстракции(от которой напрямую зависит сфера применимости) гибкость подразумевает минимализм и простоту.

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

А вот с минимализмом у ООП боооольшие проблемы.

Разве что у вас

Не по определению, а за ненадобностью.

Согласен!!! 100% попадание. Наконец-то вы, опять таки, сами пришли к правильному выводу. ФЯП не нужны все эти вещи, относящиеся к ООЯП и дающие им более высокий уровень абстракции/гибкости.

*тонко намекаю* Помимо ООП есть другие высокоуровневые абстракции...

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

О большем уровне абстракции ООП, чем у ФП - это еще более неверное утверждение.

Но вы ведь так и "не выгуглили" соответствующих доводов. Если просто хочется поспорить - поспорьте с кем либо другим. Споры в стиле "-Да! -Нет!" - не мое.

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

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

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

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

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

Спасибо за дискуссию.

[Garfield]

Пока не знаю ни какой, но с нового учебного года буду изучать C++

[βεερ_βooρ]

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

Элементарно, Ватсон!(с)
Лауреаты премии Тьюринга явно  смыслят что-то в программировании  (спорить не будете?)
Все лауреаты премии Тьюринга были МАТЕМАТИКАМИ, так как Computer Science строго говоря является одной из областей прикладной математики.
http://www.math.niu.edu/~rusin/known-math/index/beginners.html

By design of the MSC, literature concerning specific computations and algorithms is classified with the area of mathematics to which the computations are applied. But mathematics can return the favor and study the process by which computers carry out their information handling.
68: Computer science, today more accurately a separate discipline, considers a number of rather mathematical topics. In addition to computability questions arising from many problems in discrete mathematics, and logic questions related to recursion theory, one must consider scheduling questions, stochastic models, and so on.
94: Information and communication includes questions of particular interest to algebraists, especially coding theory (related to linear algebra and finite groups) and encryption (related to number theory and combinatorics). Many topics appropriate to this area can be expressed in graph-theoretic terms, such as network flows and circuit design. Data compression and visualization overlap with statistics.
For mathematical analysis of computation see Numerical Analysis.

Ну вот, вы сами к этому наконец-то пришли

Не надо разрывать фразу, вторая часть тут важна 

Пез перехода на личности и оскорблений. Кто тут что не понимает не мне/вам судить. Дискуссия и только дискуссия (и, может быть, она и родит истину). Вы ведь взрослый человек а не фанбой, верно?

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

Вот оно что... Я вобщем-то и не собирался прибегатьк гуглу в данной ситуации...

Зря. Сравните результат поисковых запросов "Волга впадает в Каспийское Море" и "ООП более абстрактно и гибко, чем ФП". Первый факт истинный и гугль это с легкостьюподтверждает. Втоой - ложный. Соответственно  единственный пруфлинк гугля - это обсуждение.

Но эта фраза многое объясняет... Вы, надобно понимать, не на опыте свои суждения строите а на "выгугливаниях"?...

Ну если я выгугливаю, то ты придумываешь.

Но специально для вас, раз для вас это так принципиально,

Принципиально, принципиально. На этом форуме уже доказывали, что ание - не мультипликация. Почему? Смотрите в вики, там все написвно! Читаем:

Аниме` (['anʲɪmə, ənʲɪ'mɛ] ср., нескл., яп. アニメ (info) [anʲime], от англ. animation — мультипликация) — японская анимация.

Ну и что в таком случае имел ввиду собеседник?

я сделаю пару цитат:

Из статьи об ООП:

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

Алло! Мы с чем сравнивали?
Ну и кто вы после этого? Я вас попросил ответить на конкретный вопрос, а не процитировать кусочек статьи, причем не в тему.

(в статье о ФП упоминания об абстракции отсутствуют как таковые)

Прочитайте определение абстракции, а потом перечитайте статью о ФП. Еслли в статье нету маркетинговой таблички АБСТРАКЦИЯ!, то это не знчит, что она не применяется в ФП. Более того, ОНА ТАМ ЕСТЬ. И она там применялась когда ООП вообще не существовало. 

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

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

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

Простота является следствием здорового минимализма. Или вы проектируете классы с 141596 полями 18289545 методами?

Согласен!!! 100% попадание. Наконец-то вы, опять таки, сами пришли к правильному выводу.

Неа, это вы пришли к неправильному.

ФЯП не нужны все эти вещи, относящиеся к ООЯП

... ибо у них есть свои методы, которые обеспечивают абстракцию/гибкость

и дающие им более высокий уровень абстракции/гибкости.

Ну вот опять утверждение о превосходстве арийской расы ООП. Давайте вы его сначала таки докажите?

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

Но вы ведь так и "не выгуглили" соответствующих доводов. Если просто хочется поспорить - поспорьте с кем либо другим. Споры в стиле "-Да! -Нет!" - не мое..

Хорошо, сами разбираться не хотите. Ну и лпдно. А мне тут гуглить и не придется 

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

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

А высокоуровневую абстракцию я отдам на разработку (или сам выполню) девелоперу с глубоким знанием архитектурных паттернов и ООП, который воспользуется ими для составления высокоабстрактной и гибкой архитектуры приложения (дабы кодер-математик потом не задумывался о высоких материях,

Бесконечномерное функциональное гильбертово пространство - высокая материя или нет?

а просто подставил формулы в нужные места). Вот как оно выглядит в реальной жизни.

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

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

Данная дискусия возникла из следующего утверждения:

ООП более абстрактно и гибко, чем ФП

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

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

[kion]

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

Но на самом деле выглядит все именно так как описал я, а не так, как хотелось бы вам

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

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

[βεερ_βooρ]

Но на самом деле выглядит все именно так как описал я, а не так, как хотелось бы вам

Не люблю когда меня не читают 

Вот как это должно выглядить в реальной жизни:

А на практике все зависит от бюджета.

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

Проработаете в данной области еще лет 5 - тогда и поговорим. 

[S!N]

Delphi, Basic, Java, PHP, курс универа, короче

[kion]

Не люблю когда меня не читают

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

Проработаете в данной области еще лет 5 - тогда и поговорим. 

Договорились

[βεερ_βooρ]

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

Ну я же написал:

А на практике все зависит от бюджета.

Ну и можно дописать "и от объема/сложности задачи".

Относительно все не так - вы же не можете доказать что абсолютно во всех случаях "все не так"
Ибо
Данное утвердение крайне нетривиально и требует доказательства. Более того - оно неверно.

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

[kion]

вы же не можете доказать что абсолютно во всех случаях "все не так"

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

Но. Я работал на клиентов из Украины, Голландии, Германии, Великобритании, США и т.д. И делали мы не блокнотики и калькуляторы, а ПО для банковской и инвестиционной сферы, електронных систем голосования/выборов, аэро-портов и т.д. (тоесть почти все проекты - Enterprise level).

И во всех случаях работали мы именно по такой схеме, которую описал я, а не вы. НЕЗАВИСИМО ОТ БЮДЖЕТА.

Как я уже сказал, сперва проработайте в данной области хотя бы лет 5 и получите соответствующий опыт - вот тогда и пообщаемся.

Удачи.

[Андрей]

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

Но. Я работал на клиентов из Украины, Голландии, Германии, Великобритании, США и т.д. И делали мы не блокнотики и калькуляторы, а ПО для банковской и инвестиционной сферы, електронных систем голосования/выборов, аэро-портов и т.д. (тоесть почти все проекты - Enterprise level).

И во всех случаях работали мы именно по такой схеме, которую описал я, а не вы. НЕЗАВИСИМО ОТ БЮДЖЕТА.

Как я уже сказал, сперва проработайте в данной области хотя бы лет 5 и получите соответствующий опыт - вот тогда и пообщаемся.

Удачи.

(убрал выделение трех слов написанных в верхнем регистре -- не надо делать *два* усиления, тем более, что цель одна и таже)
Ваша позиция ясна -- если *Вы* не используете парадигму, то она не нужна. Ваша позиция является и Вашим заблуждением, но это Вы признать отказываетесь. Ваше право.
Насчет "области", то в Enterprise работает много винтиков, которые можно спокойно выбрасывать, опосля использования, и заменять новыми, более дешевыми. Незаменимых в Enterprise нету, а людей, которые интересуются чем-то другим (ФП, логическое программирование, array programming, декларативное программирование в общем, структуры данных, алгоритмы, etc) реально мало. Поэтому многие программисты на том же Haskell могут в любой момент перейти в Enterprise, но обратное движение отсутствует.
В общем, варитесь себе в Enterprise дальше, но так узко мыслить не стоит -- бесполезных вещей не существует.

[kion]

(убрал выделение трех слов написанных в верхнем регистре -- не надо делать *два* усиления, тем более, что цель одна и таже)

Ок, сорри.

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

Хмм... Не стоит так однозначно судить о Enterprise... Все зависит от конкретного случая.

В общем, варитесь себе в Enterprise дальше, но так узко мыслить не стоит -- бесполезных вещей не существует.

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

[βεερ_βooρ]

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

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

Но. Я работал на клиентов из Украины, Голландии, Германии, Великобритании, США и т.д. И делали мы не блокнотики и калькуляторы, а ПО для банковской и инвестиционной сферы, електронных систем голосования/выборов, аэро-портов и т.д. (тоесть почти все проекты - Enterprise level).

И ваше ПО было уникальным, совершенно не имеющем аналогов? Вряд ли, иначе бы это не был Enterprise, который решает в основном типовые задачи. И отличия от калькулятора тут только в масштабах. В моем примере именно матмодель определяла дизайн - не зная как себя ведет управляймый объект им невозможно управлять. 

Как я уже сказал, сперва проработайте в данной области хотя бы лет 5 и получите соответствующий опыт - вот тогда и пообщаемся.

Ну а вы сначала расширьте свой кругозор дальше Enterprise и научитесь четко формировать доказательства своих слов.

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

Хмм... Не стоит так однозначно судить о Enterprise... Все зависит от конкретного случая.

Статистика  :

И во всех случаях работали мы именно по такой схеме, которую описал я, а не вы.

А кто сказал, что я мыслю узко

Палитесь 

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

Если одна парадигма более абстрактная и гибкая, то "проигравшая" автоматически становится если не бесполезной, то нишевой. А что вы пытались доказать? Большую гибкость ООП с вытекающей отсюда бесполезностью ФП

[kion]

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

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

И ваше ПО было уникальным, совершенно не имеющем аналогов?

Некоторое - именно таковым и есть. Давайте не будем путать Enterprise и Mainstream.

Ну а вы сначала расширьте свой кругозор дальше Enterprise и научитесь четко формировать доказательства своих слов.

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

Палитесь 

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

Если одна парадигма более абстрактная и гибкая, то "проигравшая" автоматически становится если не бесполезной, то нишевой.

Странное утверждение... Тоесть если соотношение составляет, к примеру, 60/40, то второй вариант (40%) - уже нишевый? Запомните: каждая парадигма программирования доказала свое право на существование (и соответственно применение в реальных проектах) хотя бы потому, что она существует (само понятие "парадигма" для вас хоть ясно?). Каждая из них предназначена для решения конкретного типа задач. Там где "царствует" ФП, объектно-ориентированному программированию делать нечего и наоборот. Я же доказывал, что область применения ООП - те проекты, где нужна большая абстрактность и гибкость, потому что это и есть "конек" ООП. В отличии от менее абстрактного/гибкого ФП, которое предназначено для решения другого типа задач (математические модели, алгоритмика и т.д.). Однако, я даже не думал спорить о том, что ФП - менее значимо, чем другие парадигмы программирования.

И еще одно: я даже не утверждал, что ООП - более распостранено, чем ФП. Меня даже не расстроил бы факт нишевости ООП В который раз повторяю: я дискутировал лишь о уровне абстрактности и гибкости ООП/ФП, а не о превосходстве/большей популярности/и т.д. какой-либо одной парадигмы.

Так что перестаньте с пеной у рта доказывать то, что никто и не оспаривал.

А что вы пытались доказать? Большую гибкость ООП с вытекающей отсюда бесполезностью ФП

Что я пытался доказать, вы, как я вижу, совсем не поняли. Так что не вижу смысла тратить время на дискуссию с вами. Прекращаем.

[Андрей]

Хмм... Не стоит так однозначно судить о Enterprise... Все зависит от конкретного случая.

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

ФП является частным случаем декларативного программирования, в то время как ООП -- вырожденный случай программирования императивного. Декларативное программирование описывает не процесс получения результата, а сам результат. Мне почему-то всегда казалось более абстрактной конструкцией "Дайте 300 грамм сыра", нежели "Возьмите нож, отрежьте кусок обьема X*Y*Z и взвесьте его". Надеюсь, понятно, где в даной аналогии ФП, а где ООП.
Но, всё-таки, надо отметить, что в рамках каждого проекта мы можем выходить на гораздо более высокие уровни абстракции, к примеру, в случае использования DSL. Так что, чисто теоретически ФП является абстракцией более высокого уровня, нежели ООП, но в пределах одного проекта мы можем даже в рамках процедурного программирования создавать абстракции высочайшего уровня.

[kion]

ФП является частным случаем декларативного программирования, в то время как ООП -- вырожденный случай программирования императивного. Декларативное программирование описывает не процесс получения результата, а сам результат. Мне почему-то всегда казалось более абстрактной конструкцией "Дайте 300 грамм сыра", нежели "Возьмите нож, отрежьте кусок обьема X*Y*Z и взвесьте его". Надеюсь, понятно, где в даной аналогии ФП, а где ООП...

...Так что, чисто теоретически ФП является абстракцией более высокого уровня, нежели ООП

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

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

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

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

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

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

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

[FalseMan]

думаю не будете доказывать что большинство специалистов со всего мира отдают предпочтение именно ООП, а не ФП, без какой-либо разумной на то причины?).

Просто потому что нет книжек "Освой ФП за 24 часа! Стань кулхацкером и специалистом всего за сутки!"

[kion]

Просто потому что нет книжек "Освой ФП за 24 часа! Стань кулхацкером и специалистом всего за сутки!"

1) Берете не одну а сразу пару таких книг и не сутки а целых пару недель времени. А потом посмотрим, получится ли у вас стать "кулхацкером и специалистом" (знаем мы таких скептиков, считающих, что это как два бита переслать)...

2) Чисто из интереса - не порекомендуете ли хоть одну такую книгу (я так понял, что вы намекали на то, что присутствует множество книг вроде "Освой ООП за 24 часа")? Уж очень интересно (впрочем, книг "освой за 24 часа" издано огромное количество на любую тематику, так что это в любом случае не аргумент, ведь такие книги - это лишь самое базовое "посвящение" в основы; ни фотошопом, ни ФП/ООП, ни конкретным ЯП, ни чем нибудь другим со схожей сложностью за 24 часа (в полной мере) овладеть невозможно;)

[Андрей]

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

Основное здесь выражение -- это "на практике". Дело в том, что на практике, понять ФП удается не каждому, мягко говоря. Об этом говорил Joel Spolsky, Steve Yegge и куча других известных программистов. На практике, ООП оказывается отличным инструментом по подготовке сотен тысяч кодеров, которые не в состоянии мыслить. На практике, малый процент программистов Enterprise в состоянии понять Y combinator и работу с указателями. На практике, программистов Enterprise заменяют более дешевыми программистами Enterprise, в то время как программисты, которые поняли ФП зачастую более высокооплачиваемы.
Вся современная практика сводится к тому, что программист -- это офисный планктон, а практика программистов Java и C#, языков, в которых "невозможно выстрелить себе в ногу", в которых не надо думать, потому что за вас уже подумали, так вот, практика этих программистов говорит о том, что оплата за труд программиста уже давно не соответствует уровню самих программистов. Да и среди этих сотен тысяч программистов мало людей, которые в состоянии формализовать задачу, привести ее к чистой дискретной математике или лямбда-исчслениям. Для того, чтобы программировать на жабке или сишарпе знание теории автоматов, структур данных или рекурсивных лябмд излишне, что Вы, кстати, доказали своей фразой:

"создавал математическую модель, которая определяет дизайн" - это, извините, даже звучит смешно

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

[kion]

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

Ах вот оно что
Я еще и мыслить не умею...

На практике, малый процент программистов Enterprise в состоянии понять Y combinator и работу с указателями.

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

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

Да вы что? Действительно? Можно поинтеросоваться: а эти данные откуда? Надеюсь также из личного опыта работы в индустрии... Ну или хотя бы из результатов аналитических исследований рынка труда IT?

Кажется мне, вы скорее фантазируете, чем оперируете реальными фактами...

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

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

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

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

Пока Вы смеетесь и считаете, что подход "чото надумали и кодим" единственно правильный (потому что Вы использовали только даный подход)

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

, компании уровня Google, Facebook, RedHat использует именно подход "формализация на уровне математических абстракций -> детализация -> реализация".

С этого места поподробней
Вы ведь не просто так это написали? (Факты в студию!)

Именно поэтому эти компаниии предоставляют новационные решения, в то время как Ваш Enterprise сводится к простейшим задачам "достань из базы, пересчитай, положи в базу".

А ФП тогда сводится к одной простейшей задаче "возьми два числа, подставь в формулу, верни результат"?

Основная задача ООП (и для Enterprise это актуально в абсолютном большинстве случаев) - не кодирование, а проектирование. Так что с "базой" - это вы явно "не в кассу".

[βεερ_βooρ]

Не понял наезда...

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

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

Поэтому я отвечу не по конкретным цитатам, а по написаны вами утверждениям, которые вызывают критику.

ООП более абстрактно и гибко, чем ФП

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

В отличии от менее абстрактного/гибкого ФП, которое предназначено для решения другого типа задач (математические модели, алгоритмика и т.д.).

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

Если ФП настолько круто, то почему лидирющей парадигмой является ООП?

Вам уже ответили:

Основное здесь выражение -- это "на практике". Дело в том, что на практике, понять ФП удается не каждому, мягко говоря. Об этом говорил Joel Spolsky, Steve Yegge и куча других известных программистов. На практике, ООП оказывается отличным инструментом по подготовке сотен тысяч кодеров, которые не в состоянии мыслить.

Вы обиделись, но вы противоречите сами себе:

Ах вот оно что
Я еще и мыслить не умею...

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

Да вы что? Действительно? Можно поинтеросоваться: а эти данные откуда? Надеюсь также из личного опыта работы в индустрии... Ну или хотя бы из результатов аналитических исследований рынка труда IT?

Кажется мне, вы скорее фантазируете, чем оперируете реальными фактами...

За реальным фактом далеко ходить не надо:

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

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

С этого места поподробней
Вы ведь не просто так это написали? (Факты в студию!)

Вот вам факты. Я только для большей наглядности воспользуюсь опять таки "месным" примером:

Да Если б надо было - сделали бы... Вот только нафиг оно надо?
Подобные вещи актуальны в ФП, но не в ООП.

И во всех случаях работали мы именно по такой схеме, которую описал я, а не вы.

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

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

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

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

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

И будете неправы. Математическая культура - страшная штука 

А ФП тогда сводится к одной простейшей задаче "возьми два числа, подставь в формулу, верни результат"?

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

[kion]

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

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

(это я язвлю в ответ, можно не отвечать взаимностью)

Я уже пятый раз пытаюсь вам указать на некорректность этого утверждения. (И меня это раздражает).

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

Кроме того рискну предположить что вы слабо себе представляете сферу применения ФП...

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

ФП тербует намного более высокого математической культуры и большего объема специальных знаний.

Спорный вопрос. Но спорить я уже устал...

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

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

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

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

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

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

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

Я постараюсь последовать вашему совету Хотя, если вам интересно, когда я уходил из своей школы после 8-го класса - был лучшим математиком всех 8-х классов (математика давалась мне так легко, что я попросту никогда ею даже не занимался - все домашние задания себе и 2-3-м одноклассникам выполнял на переменке, теоремы мог доказать без подготовки и т.п.; про олимпиады - не буду и упоминать). В лицее (9-11 класс после школы) я математику просто хорошо знал (также не учил, но всегда сдавал экзамены и зачеты без каких-либо проблем) и она уже становилась для меня скучной (тогда я как-раз познакомился с программирование и полюбил "чистую логику"). А вот в институте я окончательно к математике "остыл" и посреди учебы ушел работать разработчиком в IT... (и между прочим, чтобы здать екзамены по полугодичным курсам некоторых предметов, вроде "теории вероятности" и "мат-анализа", на лекциях которых я ни разу не присутствовал, мне приходилось изучать полный курс за неделю - денег за их здачу я не платил - здавал своими силами)

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

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

И будете неправы. Математическая культура - страшная штука.

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

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

Несильна разница  

[Андрей]

Ах вот оно что
Я еще и мыслить не умею...

Я Вас лично где-то обвинил в этом? Не надо из себя делать обиженного, пожалуйста.

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

Как ни странно, из личного опыта и общения.

Да вы что? Действительно? Можно поинтеросоваться: а эти данные откуда? Надеюсь также из личного опыта работы в индустрии... Ну или хотя бы из результатов аналитических исследований рынка труда IT?

Личный опыт, lispjobs, haskell jobs, erlang jobs, друзья и знакомые, которые используют ФЯП, Dice. Да даже ITJobsWatch подойдет:
http://www.itjobswatch.co.uk/default.aspx?page=1&sortby=3&orderby=1&q=&id=900&lid=2618

Кажется мне, вы скорее фантазируете, чем оперируете реальными фактами...

Вы бы голословными утверждениями не увлекались, ага.

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

memory leak в ФЯП? Головой не шибко больно бились? Вы знаете, где появился сборщик мусора впервые? Думаете в жабке вашей энтерпрайзной? Советую посетить en.wikipedia.org.
Вы даже не пытаетесь понять, что Вам пишут. Я уж молчу, что в цитируемом отрезке нету ни одного упоминания о ЯП, которые работают напрямую с памятью. Ну, куда уж Вам, внимательно читать собеседника, Вы же в Enterprise рабоаете, Вы-то уж точно лучше всех всё знаете.

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

О боги. Глупость на глупости глупостью погоняет. Почитайте про ФП, хоть на вики английской-то.

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

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

С этого места поподробней
Вы ведь не просто так это написали? (Факты в студию!)

http://research.google.com/pubs/papers.html
Приходите обратно, когда осилите.

А ФП тогда сводится к одной простейшей задаче "возьми два числа, подставь в формулу, верни результат"?

Вы бы хоть узнали, что есть ФП. Не надоело позориться?

Основная задача ООП (и для Enterprise это актуально в абсолютном большинстве случаев) - не кодирование, а проектирование. Так что с "базой" - это вы явно "не в кассу".

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

[kion]

Я Вас лично где-то обвинил в этом? Не надо из себя делать обиженного, пожалуйста.

Смайл видите? Это была ирония...

Как ни странно, из личного опыта и общения.

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

Это данные только по Британии. В мировом масштабе все может (существенно) отличаться. Хотя, признаю, ваше утверждение по крайней мере от части верно (в обоснованные факты я верю ).

Вы бы голословными утверждениями не увлекались, ага.

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

memory leak в ФЯП? Головой не шибко больно бились? Вы знаете, где появился сборщик мусора впервые? Думаете в жабке вашей энтерпрайзной? Советую посетить en.wikipedia.org.

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

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

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

О боги. Глупость на глупости глупостью погоняет.

Если все ФП-программисты так же невоспитанны и резки как вы, то о какой культуре программирования мы говорим? Сперва нужно культуру общения пофиксить...

Мало того, такие задачи, которые паттерны не покрывают, в Enterprise не появляются.

Неверно. Еще как появляются.

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

Да ладно вам, не утрируйте.
При соответствующем опыте - не так уж и трудно.

Не позорьтесь, в общем.

Взаимно!

Приходите обратно, когда осилите.

Вернулся не осилив - видать слишком таки туп
Может разжуете каким именно образом данная ссылка подтверждает ваше высказывание?

Вы бы хоть узнали, что есть ФП. Не надоело позориться?

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

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

Не нужно цепляться к словам. Вы ведь достаточно образованны (хоть и не воспитанны) чтоб понять, что я хотел сказать.

[dojik]

Жесць... Ассемблер знают блольше, чем шелл О_О

[Андрей]

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

Программист ФП не знает, что есть fixed point combinator? Насмешили. Это основа лямбда-исчислений.
А вот если Вы PM, то пройдитесь по отделу и спросите, сколько людей знает, что это такое. Ждем результатов теста.

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

? То есть, вы не программист, а PM? Так я Вам скажу, что ООП и ФП есть детали реализации с Вашей высоты.

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

Хорошо, перефразирую:
Предоставьте список функциональных языков программирования, работающих с памятью напрямую, без сборки мусора. Ждем-с.

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

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

О боги. Глупость на глупости глупостью погоняет. Почитайте про ФП, хоть на вики английской-то.

Если все ФП-программисты так же невоспитанны и резки как вы, то о какой культуре программирования мы говорим? Сперва нужно культуру общения пофиксить...

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

Неверно. Еще как появляются.

Да ладно вам, не утрируйте.
При соответствующем опыте - не так уж и трудно.

Я рад. Только вот большинство паттернов на самом деле всего-лишь обходят убогость языка. Для нормальных, современных ЯП все эти паттерны являются пустым звуком, потому что это уже часть языка. Хотя, даже старенький Lisp, а конкретнее Common Lisp содержит в себе почти все известные паттерны. Для дальнейшего ознакомления, читайте:
http://norvig.com/design-patterns/

Вернулся не осилив - видать слишком таки туп
Может разжуете каким именно образом данная ссылка подтверждает ваше высказывание?

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

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

Кто Вам сказал, что я не знаю, что есть ООП? Или в Python, Ruby, CLOS нету ООП?
Проектирование? Да, простите, практического опыта мало. Математическая формализация задачи -- есть такой опыт. Что хотите доказать, что проектируещему проект важно, какой парадигмы будет придерживаться программист? Сказать честно, проектировщику это должно быть до одного места, он ставит временные и экономические рамки, но никак не указывает программисту используемый ЯП. ЯП может указать тим-лид, но он к проектированию он должен присоединяться уже вместе с коммандой, после того как проект уже был создан. Он может вернуть проект на доработку, но проектировщика все равно не должен волновать выбор ЯП.

Не нужно цепляться к словам. Вы ведь достаточно образованны (хоть и не воспитанны) чтоб понять, что я хотел сказать.

Нет, я не понял, что вы хотели сказать. Расшифровывайте:

Основная задача ООП (и для Enterprise это актуально в абсолютном большинстве случаев) - не кодирование, а проектирование.

[kion]

? То есть, вы не программист, а PM? Так я Вам скажу, что ООП и ФП есть детали реализации с Вашей высоты.

PM - Project Manager. При чем здесь это понятие вобще? ООП-проектирование и Проектный Менеджмент - вобще не сравнимые вещи. И еще меня в некомпетентности упрекаете...

Хорошо, перефразирую:
Предоставьте список функциональных языков программирования, работающих с памятью напрямую, без сборки мусора. Ждем-с.

Да при чем здесь garbage-collector'ы по отношению к ФЯП? Я где-то сказал, что ФЯП не имеют сборщиков мусора? В крайнем случае, можно банально заглянуть в соответствующую страницу WikiPedia и понять, что мне нет смысла доказывать подобные глупости. Вот вы снова спорите о том, о чем я даже не упоминал.

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

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

А вы забываете о том, что я имел ввиду программистов, *программирующих на ООЯП, а не на ФЯП*, которым это действительно нафиг надо Я же не говорил, что это ненужная вещь для всех программистов (да я так и не думаю!)...

Выходит вы еще и слова мои перекручиваете... Совсем плохо дело...

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

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

Я рад. Только вот большинство паттернов на самом деле всего-лишь обходят убогость языка.

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

Для нормальных, современных ЯП все эти паттерны являются пустым звуком, потому что это уже часть языка.

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

Хотя, даже старенький Lisp, а конкретнее Common Lisp содержит в себе почти все известные паттерны. Для дальнейшего ознакомления, читайте:
http://norvig.com/design-patterns/

Надеюсь, мы все-таки разобрались в данном вопросе и теперь вам ясно, что паттерны можно использовать в любом ЯП, Lisp - лишь частный случай. И паттерны вовсе не являются его (как и любого другого ЯП) частью!

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

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

Кто Вам сказал, что я не знаю, что есть ООП? Или в Python, Ruby, CLOS нету ООП?
Проектирование? Да, простите, практического опыта мало. Математическая формализация задачи -- есть такой опыт. Что хотите доказать, что проектируещему проект важно, какой парадигмы будет придерживаться программист?

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

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

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

Нет, я не понял, что вы хотели сказать. Расшифровывайте:

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

Надеюсь мы таки прояснили наконец кто о чем говорил и что имел ввиду.

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

За сим откланиваюсь, еще пообщаемся

[Ivan_32]

ИМХО : Заявить о своем знание какого либо языка все равно что сказать что вы являетесь его единственным разработчиком с неимоверной памятью и всю жизнь только тем и занимались что писал на нем самые заковыристые приложения Потому говорить что я знаю какой либо язык я не буду))
Изучал C#.NET , немного знаком с ILASM, для развлечения пишу на ASM, в редких случаях(когда уже ничего не помогает) пишу на MASM, также изредка пишу на C++ , в процессе обучения : программирование драйверов под Win32.( В драйверах меня интересует только одно : получить R0 доступ  ) Pascal и все подобные языки на вид не переношу, но в институте ознакомится все же пришлось(благо я очень быстро забыл этот ужас) Ну и любимый язык это С, так как он лаконичный и производительный ну и потом когда на нем пишешь всегда можно мысленно просмотреть будущий объектный. К слову и на нем я тоже немного писал, была такая надобность. Ну а собственно я считаю что до нормального системного программиста мне еще далеко так как программы мои представляют из себя пока что какофонию и до симфонии им еще далеко. Был прототип своего языка, компилятор его я писал на C#, но разработка его спецификации не могла сосуществовать с "учебой" в институте так что синтаксис был успешно забыт...
PS: А что программирование на С уже считается низкоуровневым ?) Что то мне кажется что об

[Phantom of the Opera]

Я занаю Pascal благодаря школе, и сам решил покопаться в  Visual Basic

Те саме. Вибрав Бейсик, а не Дельфі, бо Мікро$офт вміє робити свої продукти актуальними. А так програмування - це в мене таке хоббі 

[Jack1834]

Я знаю Pascal благодаря школе, больше из языков программирования ничего не знаю Буду учить.

[I.g.I]

Pascal - любимая школа.
Delphi - любимый универ.
C++ - нелюбимая часть любимого универа (знаю только его поверхности).

[reboot]

немного использовал fortran, assembler, но в голосовании указал только perl, поскольку пользуюсь им постоянно.

[firefire]

Update: выучил пхп 

[Хакон]

Logo (LOL), Pascal, C/C++, C#, Assembler