Здравствуйте, eao197, Вы писали:
E>Ну... Научиться программировать вообще, это в моем случае (надеюсь), уже пройденый этап. E>А вот необходимость научиться программировать на конкретном еще одном языке программирования -- это вполне конкретный вопрос. Ответ на который зависит от многих факторов. Можно, например, прочитать tutorial по OCaml, а можно еще раз "Язык программирования С++" или книгу про Boost или ACE. От последних практической пользы получается достаточно много. А вот от OCaml... Хотелось бы услышать или увидеть, чтоже в нем такого-эдакого. Только популярно.
Вопрос. Откуда ты можешь знать, что решаешь некую задачу оптимально, если ты просто банально не знаешь, какие еще подходы к ее решению существуют?
Я вот как узнал про "функциональные" фишки (типа map/foldl/и.т.д), так теперь каждый раз кодируя обработку данных (коллекции, деревья, и.т.д) на Java, плююсь на этот недоязычек.
Здравствуйте, WFrag, Вы писали:
WF>Вопрос. Откуда ты можешь знать, что решаешь некую задачу оптимально, если ты просто банально не знаешь, какие еще подходы к ее решению существуют?
Потому, что я знаю подходы к решению этой задачи на данном языке. А если мне больше нравятся подходы, принятые в другом языке, то я пытаюсь взять другой язык. Если это не возможно по техническим/организационным/политическим причинам, то меня не волнуют другие, но недоступные возможности и подходы.
Может возникнуть вопрос о том, а как я могу выбрать язык, если я других подходов не знаю?
А по большому счету, нужно ли знать? Есть языки общего назначения (универсальные). На которых можно решить большинство задач с приемлимой трудоемкостью. Да еще с другими бенефитами политического и организационного плана.
Кроме того, есть ниши, в которых подходы и используемые языки устоялись. И для успешного решения задач в этих нишах уже давно созданы мощные фреймворки. Например, J2EE для Java. Или ACE для C++. Так что понять, на чем решаются задачи в конкретной области не так уж и сложно. И при необходимости изучить новый язык, который еще не знаешь и нужный для работы.
WF>Я вот как узнал про "функциональные" фишки (типа map/foldl/и.т.д), так теперь каждый раз кодируя обработку данных (коллекции, деревья, и.т.д) на Java, плююсь на этот недоязычек.
Так почему же не меняешь?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
WF>>Вопрос. Откуда ты можешь знать, что решаешь некую задачу оптимально, если ты просто банально не знаешь, какие еще подходы к ее решению существуют?
E>Потому, что я знаю подходы к решению этой задачи на данном языке. А если мне больше нравятся подходы, принятые в другом языке, то я пытаюсь взять другой язык. Если это не возможно по техническим/организационным/политическим причинам, то меня не волнуют другие, но недоступные возможности и подходы.
E>Может возникнуть вопрос о том, а как я могу выбрать язык, если я других подходов не знаю? E>А по большому счету, нужно ли знать? Есть языки общего назначения (универсальные). На которых можно решить большинство задач с приемлимой трудоемкостью. Да еще с другими бенефитами политического и организационного плана.
Что значи "приемлимая трудоемкость"? Откуда ты знаешь, может ты за счет дополнительных знаний (даже не за счет языка) можешь свою продуктивность, скажем, процентов на 20 повысить?
E>Кроме того, есть ниши, в которых подходы и используемые языки устоялись. И для успешного решения задач в этих нишах уже давно созданы мощные фреймворки. Например, J2EE для Java.
Угу. А как я узнал, что такое REPL, так плевался когда портировал огромную J2EE апликуху на другой сервер приложений. Заметь — REPL чуждый Java подход. А тем не менее я вижу, что он сильно бы мне помог. Вот не знал бы я его — не плевался бы, думал бы что оптимально задачу решаю.
E>Или ACE для C++. Так что понять, на чем решаются задачи в конкретной области не так уж и сложно. И при необходимости изучить новый язык, который еще не знаешь и нужный для работы.
E>Так почему же не меняешь?
За что платят — не том и работаю Тем более, наличие функций высшего порядка, замыканий и REPL — не единственный критерий выбора языка. Есть множество других как технических, так и политических.
К тому же, я говорю не о языках, а а знаниях. Причем не привязанные к конкретному языку. От которых ты отплевываешься.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, reductor, Вы писали:
E>>>Ну... Научиться программировать вообще, это в моем случае (надеюсь), уже пройденый этап.
R>>Я так думал несколько раз. Последний раз понял, что это не так, когда стал программировать на Haskell.
E>А я вот не разубеждался пока. Программирование -- это процесс раскладывания по полочкам всего, что нужно для достижения цели. Если этот процесс освоен, то конкретный подход (структурный, ООП или логический, как в Прологе) не имеет значения. E>
E>>>Хотелось бы услышать или увидеть, чтоже в нем такого-эдакого. Только популярно.
R>>Не хочу повторяться. Можно сделать поиск здесь или в гугле и получить тонну sales talks на эту тему
E>Жаль.
Можно я встряну с длинной цитатой из Грэхема, все это уже читали, и не раз, но тем не менее:
This idea is rarely followed to its conclusion, though. After a certain age, programmers rarely switch languages voluntarily. Whatever language people happen to be used to, they tend to consider just good enough.
Programmers get very attached to their favorite languages, and I don't want to hurt anyone's feelings, so to explain this point I'm going to use a hypothetical language called Blub. Blub falls right in the middle of the abtractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.
And in fact, our hypothetical Blub programmer wouldn't use either of them. Of course he wouldn't program in machine language. That's what compilers are for. And as for Cobol, he doesn't know how anyone can get anything done with it. It doesn't even have x (Blub feature of your choice).
As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.
When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.
By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs.
Здравствуйте, WFrag, Вы писали:
WF>Что значи "приемлимая трудоемкость"? Откуда ты знаешь, может ты за счет дополнительных знаний (даже не за счет языка) можешь свою продуктивность, скажем, процентов на 20 повысить?
Мы говорим о языках и связанных с языком особенностях или об алгоритмах?
Ну знаю я, что такое делегат в C# или что такое code block в Ruby. Что мне толку от этого в C++?
К тому же, такая ли высокая цифра 20%? Может, если изменить дизайн приложения на том же языке получится в разы проще?
E>>Кроме того, есть ниши, в которых подходы и используемые языки устоялись. И для успешного решения задач в этих нишах уже давно созданы мощные фреймворки. Например, J2EE для Java.
WF>Угу. А как я узнал, что такое REPL, так плевался когда портировал огромную J2EE апликуху на другой сервер приложений. Заметь — REPL чуждый Java подход. А тем не менее я вижу, что он сильно бы мне помог. Вот не знал бы я его — не плевался бы, думал бы что оптимально задачу решаю.
Что такое REPL?
WF>За что платят — не том и работаю Тем более, наличие функций высшего порядка, замыканий и REPL — не единственный критерий выбора языка. Есть множество других как технических, так и политических.
Ну а если зуб неймет, то чего лишний раз облизываться и слюньки глотать?
WF>К тому же, я говорю не о языках, а а знаниях. Причем не привязанные к конкретному языку. От которых ты отплевываешься.
Знания, они же разные. Есть алоритмы, есть принципы проектирования и анализа.
А есть знания конкретных языков. Которые могут быть совершенно бесполезными. Так не лучше ли вместо изучения, для любопытства, очередного ЯП изучить что-нибудь другое?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Ну знаю я, что такое делегат в C# или что такое code block в Ruby. Что мне толку от этого в C++?
Тем, что ты можешь подумать как это знание можно применить.
E>>>Кроме того, есть ниши, в которых подходы и используемые языки устоялись. И для успешного решения задач в этих нишах уже давно созданы мощные фреймворки. Например, J2EE для Java.
Так кажется на первый взгляд. Но всегда есть место для улучшения
E>Что такое REPL?
Чтоб знать, что есть куда стремиться
E>А есть знания конкретных языков. Которые могут быть совершенно бесполезными. Так не лучше ли вместо изучения, для любопытства, очередного ЯП изучить что-нибудь другое?
Ты хочешь сказать, что изучив, скажем, Haskell, ты изучишь Haskell и ничего больше? Ты глубоко заблуждаешься.
Здравствуйте, z00n, Вы писали:
Z>Можно я встряну с длинной цитатой из Грэхема, все это уже читали, и не раз, но тем не менее:
И дальше? Ну хвалят Lisp. Только программировать на нем не торопяться. Равно как и на Haskell-е.
К тому же один человек успешно решает какую-то задачу с помощью C++, а другой это же задачу на C++ обязательно завалит. Но не Lisp-е, например, наоборот, сделает. Потому, что у первого лучше получается мыслить на C++, а у другого на Lisp-е.
Опять же, тема начиналась с того, чтобы оценить, насколько функциональные языки универсальные, т.е. пригодные к применению в различных условиях. Вот C, C++, Java -- уже доказали свою универсальность. Так же, как и Python, Perl, Ruby, Smalltalk и Lisp. Пускай теперь Haskell-и и OCaml-ы доказывают. Только скептически я к ним настроен (как и GlebZ
). Поскольку OCaml, будучи ровесником Python-а и Ruby (reductor говорит, что OCaml-у 15 лет) такой же популярности не снискал.
Вот и интересно, если я захочу выбрать для себя другой универсальный язык, вместо C++, то имеет ли смысл смотреть в сторону того же OCaml?
И если стоит, то почему.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, WFrag, Вы писали:
E>>Ну знаю я, что такое делегат в C# или что такое code block в Ruby. Что мне толку от этого в C++?
WF>Тем, что ты можешь подумать как это знание можно применить.
Если говорить конкретно о достоинствах Ruby, то никак их не применить в C++.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, z00n, Вы писали:
Z>>Можно я встряну с длинной цитатой из Грэхема, все это уже читали, и не раз, но тем не менее:
E>И дальше? Ну хвалят Lisp. Только программировать на нем не торопяться. Равно как и на Haskell-е.
Чооо?
Да я ... да ты ... да вы ...
---
Нет, правда, что за голословные утверждения. Я программирую. И все программируют, кто их знают.
Хотя бы для себя. Я имею счастье еще и по работе.
И Пол Грэм программирует — напрограммировал вон уже на $50 000 000
---
кстати этот форум безбожно глючит в браузере Safari
Здравствуйте, z00n, Вы писали:
Z>Я старался, чтобы в цитате Lisp встречался как можно реже. Обратите внимание на ход рассуждений.
Да, тут недолго осталось до того, чтобы слово Лисп сигналом *beep* заменять.
Я думаю, надо нам прекращать пропаганду. А то будет, как с Обероном и синтаксическим оверхедом. Все конструктивное сказано, дальше будет только "война народная, свяще-е-енная война!".
з.ы. вступайте в нашу секту! победа будет за нами! Кодт с нами!
Здравствуйте, reductor, Вы писали:
E>>И дальше? Ну хвалят Lisp. Только программировать на нем не торопяться. Равно как и на Haskell-е.
R>Чооо? R>Да я ... да ты ... да вы ...
R>Нет, правда, что за голословные утверждения. Я программирую. И все программируют, кто их знают. R>Хотя бы для себя. Я имею счастье еще и по работе.
Ну и что? Мне-то что с того?
Вообще идеальный потребительский подход — смотреть на чью-то популярность.
E>Я вот на C++ программирую. И все программируют, кто его знает. E>Я и для себя на С++ программирую, да еще и на работе.
E>Так что наши личные пристрастия здесь не показатель.
Ну в моем случае у меня еще и практическая сторона присутствует.
Я всегда выбираю наиболее подходящий инструмент.
reductor wrote:
> E>Ну посмотри, сколько для себя на Lisp и его диалектах программируют: > http://sourceforge.net/softwaremap/trove_list.php?form_cat=160 > E>Самые популярные как раз C++ и Java. > Ну и что? Мне-то что с того? > Вообще идеальный потребительский подход — смотреть на чью-то популярность.
Вообще-то популярность языков на sf.net — это очень неплохой показатель,
так как там (в основном) не коммерческие проекты, а "персональные"
проекты, для которых обычно выбирают "любимый" язык.
Кстати, лет 6 назад я удивился большому количеству проектов на Питоне в
sf.net (и решил посмотреть что это за язык). Тогда про Питон почти
ничего слышно не было, а проекты на sf.net уже были.
Здравствуйте, Cyberax, Вы писали:
>> Ну и что? Мне-то что с того? >> Вообще идеальный потребительский подход — смотреть на чью-то популярность.
C>Вообще-то популярность языков на sf.net — это очень неплохой показатель, C>так как там (в основном) не коммерческие проекты, а "персональные" C>проекты, для которых обычно выбирают "любимый" язык.
C>Кстати, лет 6 назад я удивился большому количеству проектов на Питоне в C>sf.net (и решил посмотреть что это за язык). Тогда про Питон почти C>ничего слышно не было, а проекты на sf.net уже были.
Посмотрите, пожалуйста, на заголовок этой ветки.
Меня, как человека, использующего эти технологии, не очень сильно волнует их популярность.
Даже скорее с позиции бизнеса я заинтересован, чтобы они продолжали оставаться тем, где сейчас есть.
И меня, например, сильно пугает та скорость, с которой набирает обороты Haskell. За последний год поток новостей о нем увеличился в несколько раз.
А то что я здесь фактически против своих интересов действую — это так, донкихотство и некоторым образом романтика.
И я кстати не думаю и не надеюсь, что у меня получится переубедить здесь многих. А тех, что удастся... Что ж, может найду интересных людей для плодотворных дискуссий. Может даже еще и поработать когда-нибудь вместе выйдет ;)
>> E>Ну посмотри, сколько для себя на Lisp и его диалектах программируют: >> http://sourceforge.net/softwaremap/trove_list.php?form_cat=160 >> E>Самые популярные как раз C++ и Java. >> Ну и что? Мне-то что с того? >> Вообще идеальный потребительский подход — смотреть на чью-то популярность.
C>Вообще-то популярность языков на sf.net — это очень неплохой показатель, C>так как там (в основном) не коммерческие проекты, а "персональные" C>проекты, для которых обычно выбирают "любимый" язык.
C>Кстати, лет 6 назад я удивился большому количеству проектов на Питоне в C>sf.net (и решил посмотреть что это за язык). Тогда про Питон почти C>ничего слышно не было, а проекты на sf.net уже были.
В общем, "брейк" (сказал судья и получил в рыло от обоих боксеров )
Cyberax wrote: > >> Вообще идеальный потребительский подход — смотреть на чью-то популярность. > > Вообще-то популярность языков на sf.net — это очень неплохой показатель, > так как там (в основном) не коммерческие проекты, а "персональные" > проекты, для которых обычно выбирают "любимый" язык.
И что с того? Кто на чем пишет на работе, тот на этом же будет писать и
для себя (в среднем). Кроме того, вполне очевидно, что необходимость
поставить какой-нибудь экзотический компилятор отпугнет возможных
пользователей программы, особенно если программа опенсорсовая (т.е.,
собирать ее должен пользователь).
Здравствуйте, eao197, Вы писали:
E>>>Это вряд ли. Ничто не дается даром. Тонкие моменты нужно знать. Вот, например, в Ruby 1.8.0 есть обычные блоки кода и получаемые с помощью оператора lambda. С виду одно и тоже. В чем же разница?
R>>Я мало что помню про руби конечно, но рискну предположить — в замыкании лексического контекста? Или кто-то из них компилит функцию из строки типа Function в javascript?
E>Умный термин "замыкания лексического контекста". Даже не знаю о чем это.
Определенно, это становится модным — не знать основных терминов, принятых в языках программирования. Об этом теперь принято заявлять с гордостью, вместо того, чтобы потратить 5 минут на чтение википедии. Так, штоли?
E>Разница в том, как отрабатывает оператор break внутри обычного (raw) code block и внутри lambda. Тонкое различие, но его незнание может дорого обойтись.
Если бы вы знали, что такое лямбда-функции и лексические замыкания (lexical closures), то это различие не показалось бы вам "тонким" даже при первом чтении мануала по языку.
Возвращаясь к нашим автомобильным аналогиям — это примерно то же самое, что перепутать бензобак с расширительным бачком системы охлаждения. Незнание тонкого различия между ними тоже может дорого обойтись.
