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

[βεερ_βooρ]

Собсно сабж.
Голосуем и комментируем свой выбор.
Вариант "Я не программирую" не включен,  что бы не портить статистику.
В постах указываем какие языки знаем, и с какими хотим познакомится поближе
____________________________
Пример:
Я знаю C, C++, Java, PHP, Perl, баловался Turbo Pascal и Delphi, Logo, Basic, Ассемблер х86, Unix shell для повседневных задач.
Матлогика подтолкнула к изучению Prolog.
Интересно "пощупать" Python, Ruby, Lisp, Haskell. Но времени как всегда не хватает

[R@MS]

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

[vab]

Pascal, Delphi. Coбиpaюcь вcepьeз зaняться PHP и Java.

[KJIuM]

Turbo Pascal, Turbo C, C++, Delphi

[Taurus]

А варіанти  ,що вивчав (знаю основи... ) підходять?
Якща да, то вивчав :
Pascal, Visual Basic, Delphi, C, C++.

[Андрей]

Основные знания - C, Python. Собственно, за знание этих языков я получаю деньги.
Неплохо знаю C++, Haskell.
В процессе изучения Lisp и Erlang.
Еще в универе был Prolog, но меня не тянет к этому ЯП.

[Bismark]

Я знаком с Бейсиком (школа), Паскалем (универ) и РНР - сам учил
Ну поскольку первые два языка я учил, то и в Визуал Бейсике и в Делфи тоже немножко работал

[linuxdrom]

Turbo-Pascal, Borland Delphi 8

Turbo Pascal, Turbo C

Turbo Pascal  ...  C++ Builder

Сразу видно кто знает язык, а кто ....

[KJIuM]

Сразу видно кто знает язык, а кто ....

Это намек на Turbo,Borland,Builder? Если да, то кто что изучал - то и написал!

[eugeneg]

А я - веб девелопер.. Знаю ПХП давно.., ну и на Перле, и в шеле немного пошаманить могу.. Хотя Перл забываю по немногу...

[fin]

Вариант "Я не программирую" не включен,  что бы не портить статистику.

Наоборот, отсутствие такого варианта статистику и испортит.

[eugeneg]

Наоборот, отсутствие такого варианта статистику и испортит.

Согласен, всеже не так много программеров здесь...

[Mirikamoari]

C, Basic, Pascal — знаю.
Java — работал, изучаю.
Lisp, Prolog, Fortran — универ познакомил.
Asm — на почти минимальном уровне, плюс пару раз включал асмовые процедуры в проги на других языках.
PHP, Perl, Python — позор мне, не знаю. Пока что.

И где Brainfuck, спрошу я?

[linuxdrom]

Это намек на Turbo,Borland,Builder?

Именно.

Если да, то кто что изучал - то и написал!

Ну вот и я о чем говорю 

[βεερ_βooρ]

Наоборот, отсутствие такого варианта статистику и испортит.

Ваш IM-клиент под Linux
Я повторения такой порнографии, когда треть ответивших "лишние" не хочу.
Это все равно, что разрешить всему миру(всем 6-ти с чем-то милиардам) голосовать на выборах в ВР.

И где Brainfuck, спрошу я?

В разделе другие

[SilentMan]

Понемногу учу Unix shell, и Ассемблер для другой платформы - Zasm - это по делам игровым, для Wire Mod'a 

[Fersifex]

Учу C/C++, одним глазом видел (Visual) Basic.

[FireBlade]

 А почему не указал и Delphi?
Хорошо знаю Pascal, C,C++, Assembler . Собираюсь заняться PHP, Delphi, SQL (БД).

[Daligator]

Аж стыдно стало, что ничего не знаю. Все, буду начинать что-то учить.

[giena]

Сначала хотел поставить галку возле Pascal, но подумав не стал этого делать  .
Вообщем не программист я - это точно. В школе изучал Basic и Pascal, в универе - Pascal...
Кстати вариант "я не программирую" мне кажется совсем не лишним(ИМХО)...

[βεερ_βooρ]

А почему не указал и Delphi?

Википедия:

Delphi (Де́льфи) — язык программирования, ранее известный как Object Pascal, разработанный фирмой Borland и изначально реализованный в её пакете Borland Delphi, от которого и получил в 2003 году своё нынешнее название. По сути является наследником языка Pascal с объектно-ориентированными расширениями.

[FireBlade]

 Ясно.
Вообще, считаю, что хорошо знать можно только 2-4 языка. Остальные - так, для общего развития.

[Andru]

Отлично владею Pascal/Delphi, хорошо разбираюсь и в состоянии писать на С/С++ Знакомился с C#(и портировал часть одного кода на сей язык), но не впечатлила ограниченность и "запрещенность" использования указателей и все что с ними связано(понимаю что есть unsafe, но это все геморойно), а также привязка к .NET  или Mono. Немного знаком с основами Ассемблера под х86. Когда-то возился с Basic'ом, и хватит минут 5 чтобы вспомнить как точно на нем прогать Вспомнил еще про язык Gentee, который весьма похож на С++ )

ЗЫ: смотрю тут многие оперируют не языками а системами/средами программирования - Turbo C++, C++Builder и т.д. )

[FireBlade]

 Такой вопрос: на Assembler программёрят мазохисты или проффесионалы?
Серьёзно: ниже уровнем только машинны код.

[Bismark]

Наоборот, отсутствие такого варианта статистику и испортит.

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

Такой вопрос: на Assembler программёрят мазохисты или проффесионалы?
Серьёзно: ниже уровнем только машинны код.

На асме пишут реальные вирмейкеры

[Богдан]

В школе мы учим Паскаль ( *нехороший* язык - чесслово ), а сам я немного выучил С и Бейсик.

[Sirius5]

Turbo Pascal(школа), C++(универ).Скажем так: знаком с этими языками.

[βεερ_βooρ]

Ясно.
Вообще, считаю, что хорошо знать можно только 2-4 языка. Остальные - так, для общего развития.

Ну я из своих перечисленных 10 вариантов где-то столько и знаю хорошо. Остальные либо побочный продукт жизнедеятельности - для расширения сознания(Prolog), либо "давно и неправда"(Logo, Basic)

В школе мы учим Паскаль ( *нехороший* язык - чесслово ), а сам я немного выучил С и Бейсик.

Не обижай патриарха Вирта - он старался

Такой вопрос: на Assembler программёрят мазохисты или проффесионалы?

Проффесиональные мазохисты ;-) ,которым очень важен прирост в быстродействии/размере (напрмер в каком-то кодеке) или когда без этого не обойтись(ОС)

Серьёзно: ниже уровнем только машинны код.

Нет, между ассемблером и машинным кодом существует взаимно однозначное соответствие.

ЗЫ: смотрю тут многие оперируют не языками а системами/средами программирования - Turbo C++, C++Builder и т.д. )

Да, огорчает.

[Bismark]

Нет, между ассемблером и машинным кодом существует взаимно однозначное соответствие.

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

[Andru]

Bismark
Почему не будет? Я на предмете "ЕОМ и микропроцессоры" писал прогу на машинных кодах, жесть еще та ) Жалко правда что вместо связки "готового решение на основе МП" выступал только эмулятор МП с интерфейсом для ввода кода(и естестно моментального его выполнения), но было весьма забавно.

Вот простейшая прога Решает вот такую тупую задачу:

Решить выражение, декрементировать результат на единицу. Использовать следующие числа(N=4):
X1 = 4 * N + 40 = 56
X2 = 0.5 * X1 = 28
X3 = 0.3 * X1 = 17
X4 = 0.1 * X1 = 6

Код Виділити Розширити


0011 1110
0011 1000
0010 0001
1000 0000
1101 0010
0011 0110
0001 0001
1001 0110
0010 1111
0100 0111
0011 1110
0001 1100
0000 1110
0000 0110
1010 1001
1011 0000
0011 1101
0111 0110


Все естестно писалось не с нуля, а использовались мнемокоды и потом шаманскими действиями превращалось в двоичный код ) Если интересно, то у меня еще сохранились сканы вот этого - "Система Команд МП КР580ИК80А"

[Bismark]

Bismark
Почему не будет? Я на предмете "ЕОМ и микропроцессоры" писал прогу на машинных кодах, жесть еще та ) Жалко правда что вместо связки "готового решение на основе МП" выступал только эмулятор МП с интерфейсом для ввода кода(и естестно моментального его выполнения), но было весьма забавно.

Тю, так это мне знакомо
В универе на предмете "Микропроцессоры" мы изучали систему команд проца КР580ИК80А, и естественно был практикум. Были у нас такие "чёрные чемоданы", назывались "Микролаб", в которых были собраны системы на базе этого проца. Также там была небольшая клавиатура для набора 16-ричных чисел (типа 0...9, А, В и т.д.) и индикатор введённых кодов.
Чтоб написать програму для той системы надо было написать её на ассемблере (конечно в версии под тот проц), потом по табличкам перевести в машинные коды и вводить уже эти коды в систему.

[βεερ_βooρ]

Соответствие вообще есть между всеми языками.

ключевые слова взаимно однозначное соответствие.

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

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

[Andru]

Bismark
Блин, те повезло больше У нас таких раритетов аля "черный чемодан" небыло )))

[BASyak]

Pascal/Delphi изучал ещё в школе. Собственно там и привит был интерес к программированию вцелом.
В институте пришлось переквалифицироваться на С/С++, хотя к тому же Делфи приходится иногда обращаться.

[РастВор]

Такой вопрос: на Assembler программёрят мазохисты или проффесионалы?

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

Кстати один препод в универе со всеми желающими может поспорить, что он на С напишет программу, которая работает не медленнее чем ваша на Ассемблере...

[Andru]

Кстати один препод в универе со всеми желающими может поспорить, что он на С напишет программу, которая работает не медленнее чем ваша на Ассемблере...

какой наивный препод Он сможет на чистом Си написать операцию умножения матриц(допустим для графического приложения) быстрее чем на асме с использованием инструкций SSE? Вообщем если он не сильно конкретизировал правила спора, я бы поспорил )))

[KJIuM]

какой наивный препод Он сможет на чистом Си написать операцию умножения матриц(допустим для графического приложения) быстрее чем на асме с использованием инструкций SSE? Вообщем если он не сильно конкретизировал правила спора, я бы поспорил )))

Просто преподу не попадались такие студенты, которые прогают на асме! Они бы точно поспорили!
П.С. А сколько будет весить его прога на С, неужели тоже меньше чем на асме!?

[Xella]

Basic - школа, Pascal - школа,институт, C/C++/Objective-C - институт, Java и Perl - бегло 5 курс на уровне лабораторных. Foxpro - не заслужено забыт, программировали в школе в "малой академии наук",  и в институте - был очень классный препод, не только учил толково предмет, но и жизни.
Последнее что писал - была дипломная работа, так получилось что на Delphi и было это в далеком 2003.
С тех пор не программировал, разве что переписывал чуть программы на Auto Lisp  в AutoCAD, но это было больше связано с миграцией с одного автокада на другой.
Вобщем теперь у меня уже второе образование и практически не связанная с программированием професия.
На данный момент я уже не считаю себя программистом.

[Fersifex]

Basic - школа, Pascal - школа

Да что ж за школа такая, а?! У нас информатика появится только в 10-11 классе, и то в 10-ом мы будем учить, что такое комп, инфа и клава, а в 11-ом - что такое ХТМЛ и самые главные дескрипторы! 

[βεερ_βooρ]

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

Нет, меньше не будет.

[Xella]

Да что ж за школа такая, а?! У нас информатика появится только в 10-11 классе, и то в 10-ом мы будем учить, что такое комп, инфа и клава, а в 11-ом - что такое ХТМЛ и самые главные дескрипторы! 

Я заканчивал гимназию, математический класс - информатика с 5 (c 1 по понятиям гимназии) класса.
В 5 классе дети изучают(я не изучал, пришел в гимназию, как она открылась в 7 классе) что то навроде простого алгоритмического языка программирования (Кенго? - точно не помню - но рука манипулятор переставляет ягоду? согласно написаной программы чето типа влево-вправо-вверх-вниз. Помню как выглядит, но внятно описать не могу).
Я же как пришел сразу было программирование на Quick Basic, и в принципе он оставался до 11 класса. А на занятиях малой академии уже в 9,10,11 классах был Turbo Pascal и Foxpro.

[R@MS]

У нас тоже в школе программирование началось во втором полугодии 10 класса

[Daligator]

У нас тоже в школе программирование началось во втором полугодии 10 класса

Это тебе еще повезло, у меня информатика такая же как у Fersifex, и то ее почти не бывает.

[Bismark]

Ассемблер, который по сути является всего лишь удобной мнемонической записью МК

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

[Retaliation]

в школе с 10-ого было жалкое подобие информатики.
я был только на первом уроке, больше не ходил 
сам знаю основы С/С++, ну и немного могу на Паскале.

[Immortiis]

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

[Retaliation]

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

юзай C++ + OpenGL =)

[firefire]

Знаю Turbo Paskal, Delphi
Ужасно знаю C

[Nikolai]

C/C++, Assembly x86, LISP, Q(uick) Basic

Видел в глаза Lua). Только это скрипт помоему.

[Fenix]

Basic, Visual Basic, C++, Delphi, Pascal, Ассемблер х86, Java ну еще копался в Фортране немного, ну вроде все.
Еще выучил HTML но за язык я его не считаю, никаких алгоритмов тупо запомни теги, С++ знаю очень хорошо.

[Brother]

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

[Bismark]

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

Интересно, а для чего тебе асм понадобился?

[Brother]

Интересно, а для чего тебе асм понадобился?

В универе изучаем

[Anton T.]

VBA для Excel/Access/Autocad

[Giltanas]

Java,С++,С#,Pascal,Delphi,Basic сейчас с ссемблером розбираюсь ...в универе нужно

[AL-STALKER]

Знаю основы Паскаля/Делфи + С/С++/С#. Сейчас думаю серьёзно заняться изучением визуал с++.

[Mils]

У нас тоже в школе программирование началось во втором полугодии 10 класса

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

Я голосовал только за С (Borland C) потому что только его нормально знаю. Сейчас в универе, как ни станно, проходим по Ассемблеру.

[Fersifex]

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

Плохо дело у нас в стране с предметом "Информатика"... 

[Mils]

Плохо дело у нас в стране с предметом "Информатика"... 

Нееее... Информатика у меня в школе была, а просто никаких языков прграммирования не изучали.

[psoi]

Ещё в школе и на втором курсе института пришлось программировать на Электроника MK-61.
Там же в школе изучали Turbo-Pascal.
В универе писал прогу для магистерской работы на Delphi.
На работе пробовал связку AutoCad + Delphi (Прикольная софтина получилась)
Пробовал С++ - но эти полиморфизмы инкапсуляции и наследования - отвратили полностью.

Ну и наконец - сделал сайт с софтиной по дистанционному съему показаний с тепловых счётчиков на PHP

[βεερ_βooρ]

Пробовал С++ - но эти полиморфизмы инкапсуляции и наследования - отвратили полностью.

А в Delphi их как будто нет. Почему такое мнение сложилось о С++? Сложность изучения?

[KJIuM]

В этом году в универе начали изучать Lisp, в следующем Prolog. Пока в список их не пишу.

[eQui]

Pascal/Delphi на уровне лабораторных университета, но у меня вообще то возникает вопрос к тем, кто пишет, что знает много языков: само значение слова "знает" можно трактовать как "в совершенстве"?

[βεερ_βooρ]

Pascal/Delphi на уровне лабораторных университета, но у меня вообще то возникает вопрос к тем, кто пишет, что знает много языков: само значение слова "знает" можно трактовать как "в совершенстве"?

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

[eQui]

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

Именно это я и имел ввиду

[snegoviK]

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

В моём понимании знать язык - уметь его использовать для решения поставленной задачи. Впринципе, я думаю, написав красивую программу на Haskell, можно также красиво её написать, например, на Java. Дальше следует градация носитель языка/просто знающий язык. Также как носитель языка знает сленг, различные фразеологизмы и поговорки, часто используемые выражения, носитель языка программирования знает трюки и хаки, которые впринципе знать для достижения цели необязательно, но которые очень полезно знать. :> Например, очень простой трюк абстракции классов а-ля Java в обычном С (С99).

Абсолютно не согласен со сравнением С++ с человеческими языками. Любой язык программирования однозначный по определению, в то время как человеческие языки двусмысленные. Этим все и сказано, впринципе. Как я писал выше, всегда существуют трюки и хаки, но впринципе о языке программирования нельзя сказать "его нельзя выучить полностью как немецкий или русский". Можно.

Проголосовал за C/C++/Java/Haskell/PHP/Prolog/Lua. Также программировал на OCCAM, VHDL и Matlab. :] А еще я как-то писал ассемблер для упрощенной архитектуры MIPS32. Я еще компилятор для чего-то там писал, но впринципе там набор инструкций стандартный был, ничего сложного.

[βεερ_βooρ]

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

как показывает практика, это понимают немногие  

Абсолютно не согласен со сравнением С++ с человеческими языками. Любой язык программирования однозначный по определению, в то время как человеческие языки двусмысленные. Этим все и сказано, впринципе.

Однозначные говорите?
Примеры:

Код Виділити Розширити

printf("%i\n",sizeof(int));

Другой пример - поведение оператора new в С++ зависит от настроек компилятора и поддерживаемых им стандартов.

В той же Wikipedia куча примеров, касающихся С++.

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

Вы полностью выучили С++? Назубок помните все 310 страниц стандарта(а он к примеру не включает описание стандартной библиотеки), а так же дополнительные материалы(например стандарты реализации под конкретную платформу)?

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

[snegoviK]

Однозначные всмысле unambiguous. Я не знаю правильного русского термина. Каждая строчка - определённый набор инструкций. То что можно писать i = i + 1, или ++i, или i++ не в счет (последние 2 варианта, разные вещи между прочим). Это не то. Зависимость от платформы (ваши примеры) тоже не то.

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

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

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

[βεερ_βooρ]

Однозначные всмысле unambiguous. Я не знаю правильного русского термина.

Недвусмысленный, точно выраженный. Т.е. однозначный.

Зависимость от платформы (ваши примеры) тоже не то.

new зависит не от платформы, а от того, какой стандарт поддерживает(и использует по умолчанию) компилятор и результат будет зависеть от того, что взбредет ему в голову. С++ - очень комплексный и сложный язык, поиск в гугле по фразе "ambiguity of C++ syntax" сразу находет кучу ссылок на задачки-головоломки(основанные на неоднозначности толкования компилятором) и фразы в стандартах вроде:

c) Complication of the Standard
-------------------------------

In cases where default int leads to an ambiguity,
it is necessary to write special disambiguating rules.
This serves to complicate the Standard and has
the potential to leave holes where no one has noticed
that an ambiguity might exist. Deprecation or banning leaves
no doubts that such ambiguities will never be
resolved in favour of default int.

In particular, default int makes specifying
the syntax of C++ difficult and particularly
sensitive to context.

А о специфике платформы всегда лучше помнить...

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

Если "выучить язык"

Речь шла, о "выучить досконально язык"

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

Если уж учить досконально так досконально.

Тут скорее идеть речь о различных сферах применения и о требованиях в этих сферах

...которые надо учитывать.

[snegoviK]

Учитывать и досконально знать язык это разные вещи. Тем неменее, я понял вашу точку зрения. У меня очень странное чувство мы говорим о похожих вещах, просто выражаемся немного по-разному. :]

[βεερ_βooρ]

Учитывать и досконально знать язык это разные вещи. Тем неменее, я понял вашу точку зрения. У меня очень странное чувство мы говорим о похожих вещах, просто выражаемся немного по-разному. :]

Несовершенство естественного языка.

[snegoviK]

*goes away building EBNF constructs*

[No_name]

Сейчас в школе (7 класс) прохожу Pascal (Turbo Pascal - в школе, Delphi 7 - учу сам) и для себя учу Objective-C (Xcode 3.0 (Mac OS))

[ricardo]

У меня тоже в школе не было програмирования, даже HTML сам осваивал(и это действительно язык не поворачивается назвать языком програмирования).

З.Ы.А если и включать в опрос вариант "не знаю языков", то только при условии наличия коментаря: какой собирается выучить.Например "Не владею языками, но собираюсь выучить"; а остальное в коментарий.

[Mils]

... даже HTML сам осваивал(и это действительно язык не поворачивается назвать языком програмирования). ...

Потому что это не язык программирования.

[Mr.V@MPIRe]

PHP для веб-дизайну треба.

[βεερ_βooρ]

Потому что это не язык программирования.

Это язык разметки(как и ТеХ)
Языки раметки вместе с PROLOG и РЕФАЛ - представители сентенциального подхода к программированию и служат(имеются ввиду языки разметки, а не PROLOG и РЕФАЛ) для описания информации(в основном текста), его внутренней стуктуры и представление при отображении.

[artlite]

Я учусь в 11-ом классе Pascal учу в школе, Pyton, Visual Basic, HTML, С++ изучаю сам. И еще пытаюсь Java, но пока ничего не выходит.

как показывает практика, это понимают немногие

А с этим я согласен, у нас программирование понимают 2 человека в классе, а в школе человек 6 максимум.

[snegoviK]

А вот интересно, я С++ попробовал после Java и C... А вот как оно наоборот? То есть, C++ потом Java.

[βεερ_βooρ]

То есть, C++ потом Java.

Я пробовал именно так.

Как бы поточнее выразить свои ощущения... Сначала я прочел книгу по Java(возможно это из-за того, что авторы работают в Sun, но элемент морального превосходства над С++ как старьем посматривался), прям революция - смотрите как элегантно все сделали, бла-бла-бла, ООП рулит, бла-бла-бла. По окончании семестра я согласился с Виртом:
http://www.osp.ru/os/1998/01/179366/

К.П.: Еще один очень популярный язык сегодня - C++. Я знаю, что Вы не испытываете особого восторга от него, и во многих случаях лучше бы использовать более безопасный язык. Однако, не будет ли мудрее помочь программистам вместо того, чтобы бороться с ними. Например, во многих случаях, C++ - программисты были бы рады использовать более безопасную версию этого языка, тем более, что далеко не все связаны необходимостью поддерживать 100% совместимость с языком Cи. Версия C++, в которой указатели и массивы были бы ясно разделены, и где можно было бы получать предупреждающее сообщение, когда, к примеру, вы присваиваете значение с плавающей точкой переменной целого типа и т.д., могла бы помочь в создании лучших программ - и без необходимости изучать совершенно новый язык. Я понимаю, что много более приятно спроектировать концептуально чистый язык, чем попытаться сделать может быть не идеальный, но широко используемый более безопасным: но ведь если этот превосходный "чистый" язык используется только ограниченным кругом людей, то продвигаем ли мы на самом деле вперед состояние дел в области разработки программного обеспечения?

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

К.П.: Тогда что Вы думаете о Java? Этот язык очень быстро набирает популярность, но во многих отношениях, он как раз не слишком отличается от того "очищенного" C++, о котором я говорил.

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

[FalseMan]

Я знаю Basic, Visual basic, pascal, delphi,c++. Хочу выучить Java и Unix Shell. Не подскажете книгу?(лучше электронную, а то у меня в городе всего 3 книжных магазина, которые продают детективчики )

[βεερ_βooρ]

Unix Shell. Не подскажете книгу?(лучше электронную, а то у меня в городе всего 3 книжных магазина, которые продают детективчики )

Advanced Bash-Scripting Guide (Версия 2.5 15 февраля 2004, Ru)
http://tldp.org/LDP/abs/html/ (Версия 5.1 10 November 2007)

UNIX: инструментальные средства, 2-е издание

[FalseMan]

Advanced Bash-Scripting Guide (Версия 2.5 15 февраля 2004, Ru)
http://tldp.org/LDP/abs/html/ (Версия 5.1 10 November 2007)

UNIX: инструментальные средства, 2-е издание

Спасибо! Хорошо, что знаю английский! Ну а по Java на русском(ИМХО лучше понимаешь на родном языке)?

[ssovez]

C/C++/ - много программил в лицее,институт
(Visual) Basic    - тока лицей
Java - институт и щаз иногда)   
PHP - постоянно)) по работе
C# + asp.net  - немного,щаз тоже по работе начинаю сильнее с ним работать   
Pascal/Delphi лицей,институт и щаз иногда знакомым кто еще учится в универе помогаю лабы делать))) недавно пришлось даже Turbo pascal вспомнить,а запустить по ХР не мог) пока не поставил DosBox
Unix shell в универе, иногда по работе
Ассемблер х86 тока в универе,хоть недавно капельку вспоминал)

[snegoviK]

2 beep_boop, на самом деле в Java воплощены многие очень интересные идеи и язык очень приятный. На нём просто удобно программировать. Я очень редко испытывал дискомфорт используя Java. Язык нельзя назвать революционным и все отмечают средства затраченные Sun на продвижение своего детища, есть некоторые неудобства и проблемы с быстродействием. Тем неменее, Java нужно отдать по заслугам. Более того, со времени 1998-го года многое изменилось. Например, та же JVM притерпела колоссальных изменений, например, появился JIT. На данный момент, соотношение быстродействия C : Java не более 1 : 2, что очень неплохо.

Впринципе, я считаю, что Java:

1) Почти такой же быстрый язык, как С.
2) Более чистый язык чем С++.
3) Намного безопаснее чем С.
4) Имеет просто изумительный набор стандартных библиотек, особенно для Regexp и работы с датами.
5) Имеет некоторые недостатки. Например, идиотское I/O, класс Byte не unsigned, инконсистенции в названиях классов и функций (ArrayList, arraycopy, substring, HashMap, length/size).

С++, с другой стороны, для меня довольно новый язык, я начал на нём программировать только на этом курсе и после Java. Язык оказался очень сложным, beep_boop был абсолютно прав и я забираю назад свои слова написанные раннее в этом топике. Что мне понравилось?

1) Оверлоадинг операторов (хотя это хак для введения принципов ООП).
2) iostream (просто супер!).
3) Указатели (!!!! java u suk).
4) Это С поддержкой ООП (С the best!).
5) Темплейт классы. Хотя, в Java generic классы тоже интересные.

Что не понравилось? Грязь, грязь, грязь и еще раз грязь. Чтобы хорошо программировать на С++ нужно быть очень дисциплинированным инженером. Из лучшего, что есть в С и Java может получится самое худшее. Иногда язык просто становится настолько уродливым, что просто хочется закрыть редактор и больше никогда не программировать (оверлоадинг оператора <<). С++ уже давно не является индустриальным стандартом, на нём пишут ширпотреб, где пара-тройка багов сям-там не играют особой картины. Более серьезные, узкопрофильные проекты уже давно не пользуются С++.

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

[ricardo]

beep_boop, что скажешь об этом:
http://www.parser.ru/
Твое мнение?

[Андрей]

beep_boop, что скажешь об этом:
http://www.parser.ru/
Твое мнение?

Вопрос хоть и не ко мне, но выскажу свое мнение -- Тёма придумал PHP. Только синтаксис еще страшнее.

[snegoviK]

А че в PHP не так с синтаксисом? Упрощенный сишный. Миленький такой. =)

[Андрей]

А че в PHP не так с синтаксисом? Упрощенный сишный. Миленький такой. =)

Назову пару основных минусов:
- бардак в именовании библиотечных функций (with_underscores, CapStyle, withoutunderscores)
- отсутствие понятия namespace (>3000 функций в глобальном пространстве имен)
- префикс $ для переменных (мое персональное фу)
Это недостатки _синтаксиса_.

[FalseMan]

- префикс $ для переменных (мое персональное фу)

И мое!

[βεερ_βooρ]

beep_boop, что скажешь об этом:
http://www.parser.ru/
Твое мнение?

Я с Парсером не работал и не интересовался (только пару раз видел в сети заметки/новости)
но на основе беглого анализа его документации пожалуй соглашусь:

Вопрос хоть и не ко мне, но выскажу свое мнение -- Тёма придумал PHP. Только синтаксис еще страшнее.

Назову пару основных минусов:
- бардак в именовании библиотечных функций (with_underscores, CapStyle, withoutunderscores)
- отсутствие понятия namespace (>3000 функций в глобальном пространстве имен)

+1

- префикс $ для переменных (мое персональное фу)
Это недостатки _синтаксиса_.

И мое!

Та дался вам тот $. Это можно сказать наследственность:
shell -> perl(он же shell на стероидах ) -> PHP

Название PHP — рекурсивная аббревиатура, означающая «PHP: Hypertext Preprocessor» (ранее акроним расшифровывался как «Personal Home Page Tools»). Изначально PHP создавался в качестве надстройки над Perl для облегчения разработки веб-страниц.

Впринципе, я считаю, что Java:

1) Почти такой же быстрый язык, как С.

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

2) Более чистый язык чем С++.

Вот только эту самую чистоту язык постепенно теряет. Это одна из причин, по которым мне не понравилась Java.

4) Имеет просто изумительный набор стандартных библиотек, особенно для Regexp и работы с датами.

Вот только это разрастание лишает Java основного приимущества С над С++ - компактности.

5) Имеет некоторые недостатки. Например, идиотское I/O, класс Byte не unsigned, инконсистенции в названиях классов и функций (ArrayList, arraycopy, substring, HashMap, length/size).

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

Язык оказался очень сложным, beep_boop был абсолютно прав и я забираю назад свои слова написанные раннее в этом топике.

О, да! Я знал по личному опыту  

1) Оверлоадинг операторов (хотя это хак для введения принципов ООП).

Вообще то оверлоадинг операторов не имеет к ООП какого-то отношения. Это элемент обобщенной парадигмы программирования(Generic programming).

2) iostream (просто супер!).

Мне больше нравятся printf сотоварищи. Влияние привычки от С + с ними удобнее поддерживать интернационализацию.  

4) Это С поддержкой ООП (С the best!).

Ну не совсем, полной совестипости с С нету...  С с поддержкой ООП - это Objective C

Что не понравилось? Грязь, грязь, грязь и еще раз грязь.

Да, это вам хардкорный BDSM, а не ваниль

Чтобы хорошо программировать на С++ нужно быть очень дисциплинированным инженером. Из лучшего, что есть в С и Java может получится самое худшее.

Не ново:

In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg.
Bjarne Stroustrup

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

А чем он уродлив?

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

Бу-га-га

Более серьезные, узкопрофильные проекты уже давно не пользуются С++.

Это слишком сильное/громкое заявление.

[Ethereal_horror]

С++ уже давно не является индустриальным стандартом, на нём пишут ширпотреб, где пара-тройка багов сям-там не играют особой картины. Более серьезные, узкопрофильные проекты уже давно не пользуются С++.

почти все игры (я имею в виду ААА-проекты) пишутся на С++.

[snegoviK]

Игры это ширпотреб. Игровая индустрия не отражает тенденции Software Development.

2 beep_boop: сейчас Java очень быстрый язык (performance ratio 2:1, часто еще меньше) и наличие больших стандартных библиотек никак не влияет на компактность / громоздкость. Всё зависит от программиста.

Мне лично, С++ понравился. Особенно, когда я привык к нему и у меня началось получаться. Jav-у я пока закинул. Но язык хороший, не игнорьте его. Да и как написали выше, в некоторых отраслях Software Engineering знание С++ обязательно. Если хотите делать игры, то нужно полюбить С++.

У меня сейчас интересное задание, называется System Integration. Нужно написать эмулятор простой системы с процессором, памятью, шиной и т.д. и для этого эмулятора написать мини-ОС с настоящим кернелом. Многие "слакеры" решили писать на Java, другие пишут на C++, а я решил написать ассемблер (который у меня валялся еще с первого курса) и эмулятор на С, а потом ОС и пару системных программ на С++. Вот посмотрим, что у меня получицо. Лектор, сказал в прошлом году кто-то написал эмулятор на Haskell, это конечно не Brainf*ck, но тоже вызывает уважение.

[Андрей]

Игры это ширпотреб. Игровая индустрия не отражает тенденции Software Development.

А что отражает?

2 beep_boop: сейчас Java очень быстрый язык (performance ratio 2:1, часто еще меньше) и наличие больших стандартных библиотек никак не влияет на компактность / громоздкость. Всё зависит от программиста.

Память вот только надо покупать.
Причем памяти для программы на жабке надо на порядок больше, чем для аналогичной программы на плюсах. Скорость разработки примерно та же при этом остается. А если у вас есть достаточно ОЗУ, то лучше Common Lisp/Haskell использовать - вдвое сократить обьем кода по сравнению с Java получится без особого труда.

[snegoviK]

А что отражает?
Память вот только надо покупать.
Причем памяти для программы на жабке надо на порядок больше, чем для аналогичной программы на плюсах. Скорость разработки примерно та же при этом остается. А если у вас есть достаточно ОЗУ, то лучше Common Lisp/Haskell использовать - вдвое сократить обьем кода по сравнению с Java получится без особого труда.

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

Память? Интересно, а на чем построена Symbian? Если на вашей target-платформе настолько мало памяти, что на ней не работает Java... Может тогда вообще на ассемблере написать? Это беря во внимание то, что DRAM дешевеет на глазах и стоит копейки.

Haskell хорош, но он медленнее Java. Lisp? Старенький.

[Андрей]

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

То есть, вы считаете что там самые современные технологии используют? Алгоритмы и автоматическое доказательство теорем - различные ФЯП, это ведь наука. Системы навигации - Ada, ибо надежность превыше всего. Где там Java?

Память? Интересно, а на чем построена Symbian?

На Java ME. Ну, к этой платформе никаких претензий - она просто единственная. Но мы же обсуждали Java SE/EE, с чего бы я сравнивал полноценный CL/Haskell/D/C++ с обрезанной жабкой? Лучше уж тогда lua вспомнить, который в эмбеде за последние несколько лет стал самым популярным встраиваемым ЯП.

Если на вашей target-платформе настолько мало памяти, что на ней не работает Java... Может тогда вообще на ассемблере написать?

Моя таргет платформа - embedded devices. 8 кб NOR Flash'а - жабка там что-то сможет продемонстрировать? C + Python/lua -- смогли.

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

Предположим, программа на плюсах требует (в пике загрузки) 2 ГБ ОЗУ. Аналогичное ПО на джаве требует не менее 20 ГБ. Принятой практикой является оставлять минимум 50% свободной оперативной памяти на сервере. Итак, ПО на джаве потребует 40 ГБ DRAM, в то время как ПО на плюсах (или даже D, там ведь есть механизм сборки мусора, он же должен жрать больше памяти) -- 4 ГБ. Разница в 36 ГБ обойдется примерно в 600 долларов. На каждый сервер. Круто, нет слов. Я специально утрировал, чтобы Вы мою мысль правильно поняли -- не всегда всё можно решить просто докупив пару планок, зачастую это экономически невыгодно.

Haskell хорош, но он медленнее Java.

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&lang2=ghc
Ы?

Lisp? Старенький.

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

[βεερ_βooρ]

Игры это ширпотреб.

Зато продаются намного лучше, чем ПО для матмоделирования

Игровая индустрия не отражает тенденции Software Development.

Да, это вообщем то правда - рынок игр функционирует в условиях довольно жесткой конкуренции и очень немногие компании могут поступать как Blizzard - указывая в графе дата выхода "когда будет готово". Очередная игра по Гарри Поттеру должна быть выпущена вместе с фильмом и т.д. Вообщем постоянная нехватка времени на разработку выливается в "ковбойство" - кое-как, зато вовремя; в патчах потом подправим.

2 beep_boop: сейчас Java очень быстрый язык (performance ratio 2:1, часто еще меньше)

Я уже писал на старом форуме ДПК, какое на меня впечитление произвели 15 одновременно работающих Eclipse...

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

Вы не правильно меня поняли, я имел компактность не в смысле компактности синтаксической конструкции и в таком духе:
http://www.catb.org/~esr/writings/taoup/html/ch04s02.html

Compactness is the property that a design can fit inside a human being's head. A good practical test for compactness is this: Does an experienced user normally need a manual? If not, then the design (or at least the subset of it that covers normal use) is compact.

Что отражает? Разработка систем навигации для авиалайнеров

... написаных на С

или алгоритмы для параллельного умножения больших матриц.

Linpack написана на Фортране, вы не знали?

Lisp? Старенький.

На это я не могу написать вминяймый комментарий. Бу-га-га.

[snegoviK]

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

[Antivirus]

Паскаль, только начал учить

[kion]

Предположим, программа на плюсах требует (в пике загрузки) 2 ГБ ОЗУ. Аналогичное ПО на джаве требует не менее 20 ГБ. Принятой практикой является оставлять минимум 50% свободной оперативной памяти на сервере. Итак, ПО на джаве потребует 40 ГБ DRAM, в то время как ПО на плюсах (или даже D, там ведь есть механизм сборки мусора, он же должен жрать больше памяти) -- 4 ГБ. Разница в 36 ГБ обойдется примерно в 600 долларов. На каждый сервер. Круто, нет слов. Я специально утрировал...

Вот уж действительно утрировали так утрировали

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

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

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

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

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

Our answer probably lies somewhere in sociology or psychology. Programmers, despite their professed appreciation of logical thought, are not immune to a kind of mythology, though these particular "myths" are arbitrary and relatively harmless.

[Андрей]

По теме: на данный момент (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

[Antivirus]

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

[Garfield]

Теперь я знаю Pascal.

[βεερ_βooρ]

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

Один из лучших учебников по паскалю, из виденых мною - за авторством Фаронова.

[firefire]

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

Заумно... Где ты такую книгу нашел? 
Могу посоветывать "Паскаль для Персональных Компьютеров", Бородич, Вальвачев, Кузьмич. Но не знаю сейчас выпускают такие книги или нет 

[FalseMan]

Один из лучших учебников по паскалю, из виденых мною - за авторством Фаронова.

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

[Ndakota]

Почему в вариантах нет Action Flash ?
Лично использую Delphi,Pascal-для школы
Python - для моего N82

[Klaxonn]

Начал изучать BASIС на информатике
Если понравится, начну углублятся в эту тему.

[Xella]

Начал изучать BASIK на информатике
Если понравится, начну углублятся в эту тему.

Угу оно и видно что начал - вообще то Basic

[Klaxonn]

Угу оно и видно что начал - вообще то Basic

А ну да.....но стоп!
Это же абривеатура!
Да! Так что это вы не правильно пишите...правильно BASIC

[Ndakota]

Не првильней Бейсик...

[Lensky]

Сейчас учу в универе C/C++/Objective-C.

[Advokat_Smerti]

изучал сам и в школе Паскаль.
в институте пока учу Асемблер и С++

[Тьома]

я еще незнаю никакого языка, но учу С++..

[Factiosus]

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