Здравствуйте, z00n, Вы писали:
Z>Я старался, чтобы в цитате Lisp встречался как можно реже. Обратите внимание на ход рассуждений.
Да, тут недолго осталось до того, чтобы слово Лисп сигналом *beep* заменять.
Я думаю, надо нам прекращать пропаганду. А то будет, как с Обероном и синтаксическим оверхедом. Все конструктивное сказано, дальше будет только "война народная, свяще-е-енная война!".
з.ы. вступайте в нашу секту! победа будет за нами! Кодт с нами!
Молотком можно забить гвоздь, Топором можно забить гвоздь. Пассатижами — тоже. Даже лампочкой можно забить гвоздь!
Но транзистором гвоздь забить нельзя. Поэтому транзистор не универсален.
Пусть на меня не обижаются приверженцы этих языков, но действительно интересно понять, отчего же, если OCaml, Haskell, SML и пр. насколько хорошие языки, позволяют писать мало кода и получать высокую скорость работы, они все еще не мейнстрим?
Есть у меня подозрение, что универсальность этих языков э... несколько ограничена. Но насколько?
Вирт считал скорость самокомпиляции одним из важнейших критериев оценки качества компилятора. А вот я думаю, а почему бы не взять в качестве критерия оценки универсальности языков программирования наличие IDE, написанных на этом языке? Ведь написание даже текстового редактора -- это уже не простая задача (не зря же GoF использует текстовый процессор для иллюстрации основных паттернов). А уж IDE, в которой текстовый редактор, это только небольшая часть, еще более сложный продукт.
На самом деле, не сложно привести примеры IDE для C++ созданных на C++.
Равно как и IDE для Java на Java.
Как и IDE для Smalltalk на Smalltalk.
Даже на скриптовых языках (вроде Ruby и Python) пишутся IDE (хоть и используются в них C/C++ компоненты вроде Scintilla, FOX, wxWidgets или Qt).
А вот что извесно про IDE для OCaml на самом OCaml? (Cameleon, последняя стабильная версия которого, судя по сайту, вышла в октябре 2003-го).
А для Haskell?
А для SML и других языков ML-группы?
Я знаю про наличие плагинов для Emacs-ов, Vim-ов, Eclipse-ов, jEdit-ов и даже Visual Studio. Только плагины, имхо, это далеко не полноценная реализация IDE.
На самом деле даже я расцениваю этот вопрос не как самый серьезный (изрядная доля шутки в нем есть), но все же...
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, reductor, Вы писали:
R>>Вам не кажется, что лучше один раз увидеть, чем 100 раз услышать? R>>Не проще ли выучить пару таких языков и написать что-нибудь, чтобы попробовать "на зуб"?
E>Нет, не проще. Есть масса вещей, которые хотелось бы знать или уметь. Но выучить их не представляется возможным в силу ограниченного ресурса времени и, прошу, прощения, мозгов. И если у меня есть выбор между изучением Scheme (OCaml, SML, Haskell) или доработкой собственных проектов, то я выберу доработку. Потому что вижу, что это мне даст сейчас и как это может отразиться на мне завтра. Я могу потратить месяц на изучение Scheme и понять, что у меня нет проектов, в которых я могу применять Scheme, либо я могу потратить тот же месяц на доработку, к примеру, RuCodeGen
Знаете, я затруднюсь назвать точное количество языков, что я когда-то учил, но одно несомненно — 3/4 из них я бы назвал "бесполезными"
Но жалею ли я, что учил их и тратил на них время?
Ни одной секунды. Они дают тот ценный вид знаний, который приходит только с очень большим опытом — как делать не нужно.
Вообще каждый язык, который учишь, потом оставляет свой след в том, _как_ ты потом программируешь. Своеобразный акцент. Как в виде использования каких-то конструкций, так и в виде избегания других.
А вот как можно спрашивать совета у тех, кто реально не пробовал что-то, я тем не менее не понимаю.
Или думаете коллективное незнание стоит большего, чем незнание персональное?
Хотя я понимаю ваши чувства, я сам тяжело переживал каждую смену и критику основного языка пока их не набралось достаточное количество чтобы вообще не думать на эту тему. А если мне щас кто-нибудь покажет неизвестный мне язык и начнет хвалить — я сначала его выучу без секунды раздумий и рефлексии, а потом начну разбираться.
E>А если язык не универсальный, то совершенно нет уверенности в надобности его изучения. Вот выучу я латынь или суахили. И что? Я же не лингвист, не врач, не организатор туристических туров в Африку. Вот так же и с функциональными языками. Ну может быть они хорошие, может быть очень хорошие. И что? Петь им диферамбы, но работать на C++/Java/C#/Python/Perl/Ruby? Пытаться делать на них проекты, для которых хорошо подходят мейнстримовые технологии? Или же лучше относиться к ним, как к фундаментальной науке: она нужна, она двигает прогресс, но ее занимаются где-то там и результаты до нас доходят спустя время и в очень адаптированном к среднему потребителю виде. И учиться следует не столько тому, как работают монады в Haskell-е или lambda в Scheme, а тому, во что это превращается в обычных универсальных языках. Например, как использовать блоки кода в Ruby, lambda в Python, функторы в C++ или делегаты в C#.
Это вам сейчас кажется, что все эти блоки в руби и делегаты в C# нужно учить, да еще и отдельно.
На самом деле все они имеют одну природу и человек, который понимает что вообще такое лямбда-выражение и замыкание получает знание и умение ими пользоваться во всех этих языках "даром".
И универсальных языков не бывает (без флеймов плиз) ;) Иначе зачем бы вам тот же ruby, unix shell, sql и прочие пришлось учить.
И между прочим монады — это не свойства хаскеля как языка. Это всего лишь определения в его библиотеке. Использовать их можно и в С++. Но чтобы узнать как — лучше знать такой язык как хаскель или clean.
А они стоят того, чтобы их использовать.
Вообще,
"Лучше день потерять, но потом за 5 минут долететь" (с) м/ф Крылья, Ноги, Хвост
Здравствуйте, eao197, Вы писали:
E>Пусть на меня не обижаются приверженцы этих языков, но действительно интересно понять, отчего же, если OCaml, Haskell, SML и пр. насколько хорошие языки, позволяют писать мало кода и получать высокую скорость работы, они все еще не мейнстрим?
Так это же хорошо, что они не мэйнстрим . В этом их прелесть — пока кто-то там рассуждает, мэйнстрим они или нет, другие люди используют их в работе и получают конкурентные преимущества . Я лично — за то, чтобы такая ситуация до какой-то степени сохранялась. http://www.rsdn.ru/Forum/Message.aspx?mid=1504996&only=1
E>Есть у меня подозрение, что универсальность этих языков э... несколько ограничена. Но насколько?
Эмулятор машины тьюринга на них написать можно. Со всеми вытекающими.
E>Вирт считал скорость самокомпиляции одним из важнейших критериев оценки качества компилятора. А вот я думаю, а почему бы не взять в качестве критерия оценки универсальности языков программирования наличие IDE, написанных на этом языке? Ведь написание даже текстового редактора -- это уже не простая задача (не зря же GoF использует текстовый процессор для иллюстрации основных паттернов). А уж IDE, в которой текстовый редактор, это только небольшая часть, еще более сложный продукт.
Почему на легковых машинах не возят железную руду и не пашут грядки? С таким подходом, рекомендую вам купить в семью универсальную машину — штоб и грядку пахать, и в кольцевых гонках учавствовать.
P.S.: От души желаю вам писать бухгалтерию на С, IDE на Фортране, оперсистему на Java, а численные расчеты на PHP. До достижения полного просветления.
Здравствуйте, reductor, Вы писали:
R>Вам не кажется, что лучше один раз увидеть, чем 100 раз услышать? R>Не проще ли выучить пару таких языков и написать что-нибудь, чтобы попробовать "на зуб"?
Нет, не проще. Есть масса вещей, которые хотелось бы знать или уметь. Но выучить их не представляется возможным в силу ограниченного ресурса времени и, прошу, прощения, мозгов. И если у меня есть выбор между изучением Scheme (OCaml, SML, Haskell) или доработкой собственных проектов, то я выберу доработку. Потому что вижу, что это мне даст сейчас и как это может отразиться на мне завтра. Я могу потратить месяц на изучение Scheme и понять, что у меня нет проектов, в которых я могу применять Scheme, либо я могу потратить тот же месяц на доработку, к примеру, RuCodeGen
Фокус в том, чтобы за повседневностью не проморгать появление нового перспективного направления в программировании. И когда внезапно возникает шумиха вокруг очередной серебрянной пули, то становится интересно узнать, какая проба на этой пуле поставлена. Например, простым вопросом: а можно ли на функциональных языках делать IDE?
А что? Вопрос, как вопрос. IDE -- это сложная задача. Раз на конкретном языке ее можно решать, значит язык заслуживает внимания для того, чтобы быть использованным в сравнимых по сложности задачах.
R>А вот что точно никогда не даст правильного ответа — это голосование какой вкус у устриц среди тех, кто устриц не пробовал.
Я не ставлю вопрос о вкусе устриц. Скорее я ставлю вопрос о том, имеет ли смысл вообще заниматься потреблением устриц. Вполне возможно, что полезнее для здоровья и безопаснее для кошелька будет вообще не связываться с этим процессом.
R>Вообще, можно по-другому подходить к вопросу, оценивать языки по тому признаку — нужен ли им IDE. R>Тоже неплохо получится.
Это уже другой вопрос.
IDE -- это пример задачи, которую можно решить с помощью языка программирования. Универсальные языки (т.е. те, которые могут применяться для широкого спектра задач) с этой задачей справляются.
А если язык не универсальный, то совершенно нет уверенности в надобности его изучения. Вот выучу я латынь или суахили. И что? Я же не лингвист, не врач, не организатор туристических туров в Африку. Вот так же и с функциональными языками. Ну может быть они хорошие, может быть очень хорошие. И что? Петь им диферамбы, но работать на C++/Java/C#/Python/Perl/Ruby? Пытаться делать на них проекты, для которых хорошо подходят мейнстримовые технологии? Или же лучше относиться к ним, как к фундаментальной науке: она нужна, она двигает прогресс, но ее занимаются где-то там и результаты до нас доходят спустя время и в очень адаптированном к среднему потребителю виде. И учиться следует не столько тому, как работают монады в Haskell-е или lambda в Scheme, а тому, во что это превращается в обычных универсальных языках. Например, как использовать блоки кода в Ruby, lambda в Python, функторы в C++ или делегаты в C#.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
reductor wrote:
> E>Ну посмотри, сколько для себя на Lisp и его диалектах программируют: > http://sourceforge.net/softwaremap/trove_list.php?form_cat=160 > E>Самые популярные как раз C++ и Java. > Ну и что? Мне-то что с того? > Вообще идеальный потребительский подход — смотреть на чью-то популярность.
Вообще-то популярность языков на sf.net — это очень неплохой показатель,
так как там (в основном) не коммерческие проекты, а "персональные"
проекты, для которых обычно выбирают "любимый" язык.
Кстати, лет 6 назад я удивился большому количеству проектов на Питоне в
sf.net (и решил посмотреть что это за язык). Тогда про Питон почти
ничего слышно не было, а проекты на sf.net уже были.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, eao197, Вы писали:
E>>Здравствуйте, Gaperton, Вы писали:
G>>>Хе-хе . Допустим, я на КамАЗ-е вожу дерьмо, а по выходным в ресторан ежжу на 300-м мерседесе . Так — можно?
E>>Так да.
E>>Только интересно, в такой интерпритации, к примеру, OCaml -- это мерс или таки Камаз?
G>Это "Чорный Бумер, чорный бумер, а попробуй догони"!
Не, не, не так.
OCaml — это маленький грузовичок Форд с 400-сильным V-образным двигателем, обгоняющий на 400 метров порше Бокстер, и способный при этом везти в багажнике полтонны дерьма . Не так давно про него рассказывали в Top Gear по телеку. Вот, что такое OCaml
Здравствуйте, eao197, Вы писали:
E>Ну... Научиться программировать вообще, это в моем случае (надеюсь), уже пройденый этап. E>А вот необходимость научиться программировать на конкретном еще одном языке программирования -- это вполне конкретный вопрос. Ответ на который зависит от многих факторов. Можно, например, прочитать tutorial по OCaml, а можно еще раз "Язык программирования С++" или книгу про Boost или ACE. От последних практической пользы получается достаточно много. А вот от OCaml... Хотелось бы услышать или увидеть, чтоже в нем такого-эдакого. Только популярно.
Вопрос. Откуда ты можешь знать, что решаешь некую задачу оптимально, если ты просто банально не знаешь, какие еще подходы к ее решению существуют?
Я вот как узнал про "функциональные" фишки (типа map/foldl/и.т.д), так теперь каждый раз кодируя обработку данных (коллекции, деревья, и.т.д) на Java, плююсь на этот недоязычек.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, reductor, Вы писали:
R>> Они дают тот ценный вид знаний, который приходит только с очень большим опытом — как делать не нужно. R>>Вообще каждый язык, который учишь, потом оставляет свой след в том, _как_ ты потом программируешь. Своеобразный акцент. Как в виде использования каких-то конструкций, так и в виде избегания других.
E>Ок. Возвращаемся к конкретике. Языки со сборкой мусора: E>Сделали в C++ так же как в Java, отгребли проблемы.
Ну вот видите, вы уже различаете языки со сборкой и без сборки.
Знали бы один, получили бы проблемы.
E>По мне, так лучше хорошо знать язык на котором программируешь постоянно, чем держать в голове массу идиом из разных языках и пытаться бездумно использовать Ruby-стиль в C++ или C++ стиль в Ruby.
Почему бездумно. можно и думая
R>>А вот как можно спрашивать совета у тех, кто реально не пробовал что-то, я тем не менее не понимаю. R>>Или думаете коллективное незнание стоит большего, чем незнание персональное?
E>Я разве спрашивал мнения большинства о функциональных языках?
Именно это вы и делали. Причем, заранее желая и ожидая определенного ответа, хочу заметить.
R>>Хотя я понимаю ваши чувства, я сам тяжело переживал каждую смену и критику основного языка пока их не набралось достаточное количество чтобы вообще не думать на эту тему.
E>Не думаю, что понимаешь. Я могу за короткое время освоить любой язык и начать на нем писать. Проблемы здесь две: E>-- хорошо ли я буду писать; E>-- нужно ли вообще на нем писать.
На нем не на нем — язык — это кроме синтаксиса и низкоуровневых технических подробностей еще и определенный стиль мышления и характерные приемы и тп.
Которые неочевидны в других языках, потому что нетривиальны там.
Как STL, который на самом деле является тем самым лисп-акцентом степанова в С++.
или там какие-то части boost
Они потому и кажутся таким сложными для изучения, что их стиль в С++ облагается большим налогом и на синтаксис и на семантику. В лиспе или схеме это совершенно простые и тривиальные вещи. Но не зная лиспа и схемы изучить их в С++ действительно сложно, а придумать — так и просто почти нереально.
E>К вопросу о хорошо. Когда мне потребовалось выбрать скриптовый язык, мне было совершенно все равно, что это будет, важно было, чтобы он работал на большом количестве платформ. В конце-концов я делал выбор из Perl, Python и Ruby. Выбрал Ruby и за месяц написал на нем то, что хотел. Однако сейчас, спустя год, я отчетливо вижу, что это была не Ruby программа, на написанная на Ruby С++ программа. А вот чтобы научиться на Ruby писать именно в стиле Ruby требуется много времени.
А обратного не замечали? когда на С++ в руби-стиле?
впрочем, оба они слишком много всего намешивают в себе, чтобы выделять их характерный стиль.
Вообще интересен ваш выбор, хочу сказать.
Руби — далеко не самый последовательный язык.
Последний раз я с ним играл года 3 назад и ощущения у меня осталось смешанные.
E>К вопросу о необходимости выбора какого-то языка вообще. Есть такое понятие "народная мудрость" -- т.е. какое-то мнение или утверждение, которое доказало свою состоятельность временем и поколениями. В IT больше известно его извращенное представление "миллионы мух не могут ошибаться". Вот народная мудрость доказала жизнеспособность и восстребованность Perl, Python-а, Ruby, C, C++ (которые никто не рекламировал и не проталкивал). Однако с функциональными языками такого не произошло. Информация к размышлению, так сказать.
Знаете, уж что-что, а "востребованность" синонимом качества никогда не являлась. Алла Пугачева и Макдональдс — очень даже востребованы. Не-не, если кого задело, Пугачева и Макдональдс — прекрасны. Но все же.
E>И поскольку я не теоретик, а практик, то мне хотелось бы понять, на какой язык стоит обратить внимание, чтобы и время зря не потратить, и в последствии на нем программировать можно было. Вот Java в свое время, и Ruby сейчас как раз такими языками и стали.
Знаете, я тоже практик. Даже более чем — я в своих проектах еще и своими деньгами и репутацией рискую.
E>Теперь речь идет о функциональных языках. Вещь мне не ведомая. Оглядываюсь по сторонам... Ба, а хоть IDE для этих языков на самих этих языках пишут?
да пишут, че не писать. Вот например: http://www.cs.ru.nl/~clean/
или вот DrScheme вместе с IDE идет: http://www.drscheme.org/
Для Common Lisp куча IDE
Только IDE — это вообще само по себе очень коммерческое понятие. Оно свидетельствует о рынке, а не о достоинствах или недостатках языка.
R>>Это вам сейчас кажется, что все эти блоки в руби и делегаты в C# нужно учить, да еще и отдельно. R>>На самом деле все они имеют одну природу и человек, который понимает что вообще такое лямбда-выражение и замыкание получает знание и умение ими пользоваться во всех этих языках "даром".
E>Это вряд ли. Ничто не дается даром. Тонкие моменты нужно знать. Вот, например, в Ruby 1.8.0 есть обычные блоки кода и получаемые с помощью оператора lambda. С виду одно и тоже. В чем же разница?
Я мало что помню про руби конечно, но рискну предположить — в замыкании лексического контекста? Или кто-то из них компилит функцию из строки типа Function в javascript?
Не думаю, что здесь есть много вариантов.
E>Так что я не верю в постулат о том, что знание нескольких языков программирования помогает лучше программировать на одном конкретном языке. Могу утверждать, что программирование на Ruby и C++ -- суть разные вещи. И знание C++ для Ruby бесполезно, равно как и Ruby для C++.
Разные вещи, да. безусловно.
Только вот программирование на python или scheme — это уже гораздо ближе к ruby.
есть несколько больших подходов, "парадигм", в рамках которых отличия в основном чисто косметические.
То есть после руби питон или перл учить — почти ничего не стоит.
R>>И универсальных языков не бывает (без флеймов плиз) Иначе зачем бы вам тот же ruby, unix shell, sql и прочие пришлось учить.
E>Бывают. Есть языки общего назначения. На них можно решать широкий спектр задач, пусть даже конкретные решения будут проигрывать специализированным языкам. Например, Ruby в большинстве случаев может заменить C++ и наоборот. SQL или даже Unix shell этого сделать не могут.
Тем не менее, разница между ruby и C++ очень большая.
Вы всегда будете делать осознанный выбор и мотивировать чем-то.
Так всегда.
E>Если ты считаешь, что у функциональных языков такая же ограниченная ниша, как у sql или unix shell, значит они действительно не универсальны. И не удивительно отсутствие IDE на них написанных. Значит критерий оказался не таким уж плохим.
Ну-ну — не нужно такого фрейдизма, не присваивайте мне слов, которых я не говорил
Они не менее универсальны, чем руби или с++.
Впрочем, вам, конечно, виднее
--
что-то опятль километровая простыня с флеймом получилась. давайте, если есть возражения по делу, то коротко. а то мыслью по подоконнику растекаться — толку мало.
Здравствуйте, eao197, Вы писали:
E>Навеяно увлеченными рассказами про функциональные языки программирования в темах
E>Пусть на меня не обижаются приверженцы этих языков, но действительно интересно понять, отчего же, если OCaml, Haskell, SML и пр. насколько хорошие языки, позволяют писать мало кода и получать высокую скорость работы, они все еще не мейнстрим?
E>Есть у меня подозрение, что универсальность этих языков э... несколько ограничена. Но насколько?
Вам не кажется, что лучше один раз увидеть, чем 100 раз услышать?
Не проще ли выучить пару таких языков и написать что-нибудь, чтобы попробовать "на зуб"?
Это не агитация, а просто предложение наилучшего способа найти ответ на этот вопрос, который когда-то меня мучил точно так же как вас.
А вот что точно никогда не даст правильного ответа — это голосование какой вкус у устриц среди тех, кто устриц не пробовал.
E>Вирт считал скорость самокомпиляции одним из важнейших критериев оценки качества компилятора. А вот я думаю, а почему бы не взять в качестве критерия оценки универсальности языков программирования наличие IDE, написанных на этом языке? ;) Ведь написание даже текстового редактора -- это уже не простая задача (не зря же GoF использует текстовый процессор для иллюстрации основных паттернов). E>А уж IDE, в которой текстовый редактор, это только небольшая часть, еще более сложный продукт.
Напоминает заседание какого-нибудь вселенского собора 397 года с выяснением стоит ли осуждать монофизитство.
Проголосовали и решили осудить.
Вообще, можно по-другому подходить к вопросу, оценивать языки по тому признаку — нужен ли им IDE.
Тоже неплохо получится.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, eao197, Вы писали:
E>>А разве Лисп -- это функциональный язык? GZ>IMHO Лисп — это большая помойка различной функциональности. Это касается Schema но особенно касается CLISP(в принципе это два разных языка). Мне от него, прямо говоря, плохо стало. Там есть императив, но в основном юзается функциональный стиль. Зато SML попал в струю. Классно выверенный и концептуально чистый язык. Если захочешь познакомится с функциональными языками, начинай лучше с него(или его последователями).
Это математически строгий и простой Scheme — помойка? Грязный SML, вызывающий рвотный рефлекс — "классно выверенный и концептуально чистый язык"?! Начинать с него?!! Да... Советы у вас...
Здравствуйте, eao197, Вы писали:
E>Пусть на меня не обижаются приверженцы этих языков, но действительно интересно понять, отчего же, если OCaml, Haskell, SML и пр. насколько хорошие языки, позволяют писать мало кода и получать высокую скорость работы, они все еще не мейнстрим?
Что на рынок пропихивается — тем и пользуются. "Мало кода", "скорость" — это все мимо рынка. Даже синтаксис жавы был позаимствован у c/c++ чтоб жаба выглядело не сильно иначе и лучше продавалась.
Здравствуйте, eao197, Вы писали:
G>>Почему на легковых машинах не возят железную руду и не пашут грядки? С таким подходом, рекомендую вам купить в семью универсальную машину — штоб и грядку пахать, и в кольцевых гонках учавствовать.
E>Почему на БелАЗах не ездят по городу, в путешествия и на дачу? С таким подходом желаю тебе попробовать проделать все это, если не на БелАЗ-е, то на КамАЗ-е или ЗИЛ-е
E>
Хе-хе . Допустим, я на КамАЗ-е вожу дерьмо, а по выходным в ресторан ежжу на 300-м мерседесе . Так — можно?
G>>P.S.: От души желаю вам писать бухгалтерию на С, IDE на Фортране, оперсистему на Java, а численные расчеты на PHP. До достижения полного просветления.
E>
E>Не, я как нибудь на C++ пока перебиваться буду. С помощью Ruby.
Выкрутился, однако
E>Кстати, а разве сейчас JavaOS совсем нет?
Я вполне допускаю и существование бухгалтерских программ на С .
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
G>>Хе-хе . Допустим, я на КамАЗ-е вожу дерьмо, а по выходным в ресторан ежжу на 300-м мерседесе . Так — можно?
E>Так да.
E>Только интересно, в такой интерпритации, к примеру, OCaml -- это мерс или таки Камаз?
Это "Чорный Бумер, чорный бумер, а попробуй догони"!
Здравствуйте, 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.
Здравствуйте, reductor, Вы писали:
R> Они дают тот ценный вид знаний, который приходит только с очень большим опытом — как делать не нужно. R>Вообще каждый язык, который учишь, потом оставляет свой след в том, _как_ ты потом программируешь. Своеобразный акцент. Как в виде использования каких-то конструкций, так и в виде избегания других.
Ок. Возвращаемся к конкретике. Языки со сборкой мусора:
public Image getImage( string fileName );
C++
Image get_image( std::string file_name );
Сделали в C++ так же как в Java, отгребли проблемы.
По мне, так лучше хорошо знать язык на котором программируешь постоянно, чем держать в голове массу идиом из разных языках и пытаться бездумно использовать Ruby-стиль в C++ или C++ стиль в Ruby.
R>А вот как можно спрашивать совета у тех, кто реально не пробовал что-то, я тем не менее не понимаю. R>Или думаете коллективное незнание стоит большего, чем незнание персональное?
Я разве спрашивал мнения большинства о функциональных языках?
R>Хотя я понимаю ваши чувства, я сам тяжело переживал каждую смену и критику основного языка пока их не набралось достаточное количество чтобы вообще не думать на эту тему.
Не думаю, что понимаешь. Я могу за короткое время освоить любой язык и начать на нем писать. Проблемы здесь две:
-- хорошо ли я буду писать;
-- нужно ли вообще на нем писать.
К вопросу о хорошо. Когда мне потребовалось выбрать скриптовый язык, мне было совершенно все равно, что это будет, важно было, чтобы он работал на большом количестве платформ. В конце-концов я делал выбор из Perl, Python и Ruby. Выбрал Ruby и за месяц написал на нем то, что хотел. Однако сейчас, спустя год, я отчетливо вижу, что это была не Ruby программа, на написанная на Ruby С++ программа. А вот чтобы научиться на Ruby писать именно в стиле Ruby требуется много времени.
К вопросу о необходимости выбора какого-то языка вообще. Есть такое понятие "народная мудрость" -- т.е. какое-то мнение или утверждение, которое доказало свою состоятельность временем и поколениями. В IT больше известно его извращенное представление "миллионы мух не могут ошибаться". Вот народная мудрость доказала жизнеспособность и восстребованность Perl, Python-а, Ruby, C, C++ (которые никто не рекламировал и не проталкивал). Однако с функциональными языками такого не произошло. Информация к размышлению, так сказать.
И поскольку я не теоретик, а практик, то мне хотелось бы понять, на какой язык стоит обратить внимание, чтобы и время зря не потратить, и в последствии на нем программировать можно было. Вот Java в свое время, и Ruby сейчас как раз такими языками и стали.
Теперь речь идет о функциональных языках. Вещь мне не ведомая. Оглядываюсь по сторонам... Ба, а хоть IDE для этих языков на самих этих языках пишут?
R>Это вам сейчас кажется, что все эти блоки в руби и делегаты в C# нужно учить, да еще и отдельно. R>На самом деле все они имеют одну природу и человек, который понимает что вообще такое лямбда-выражение и замыкание получает знание и умение ими пользоваться во всех этих языках "даром".
Это вряд ли. Ничто не дается даром. Тонкие моменты нужно знать. Вот, например, в Ruby 1.8.0 есть обычные блоки кода и получаемые с помощью оператора lambda. С виду одно и тоже. В чем же разница?
Так что я не верю в постулат о том, что знание нескольких языков программирования помогает лучше программировать на одном конкретном языке. Могу утверждать, что программирование на Ruby и C++ -- суть разные вещи. И знание C++ для Ruby бесполезно, равно как и Ruby для C++.
R>И универсальных языков не бывает (без флеймов плиз) Иначе зачем бы вам тот же ruby, unix shell, sql и прочие пришлось учить.
Бывают. Есть языки общего назначения. На них можно решать широкий спектр задач, пусть даже конкретные решения будут проигрывать специализированным языкам. Например, Ruby в большинстве случаев может заменить C++ и наоборот. SQL или даже Unix shell этого сделать не могут.
Если ты считаешь, что у функциональных языков такая же ограниченная ниша, как у sql или unix shell, значит они действительно не универсальны. И не удивительно отсутствие IDE на них написанных. Значит критерий оказался не таким уж плохим.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
>> 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 уже были.
В общем, "брейк" (сказал судья и получил в рыло от обоих боксеров )
<skipped>
E>... а почему бы не взять в качестве критерия оценки универсальности языков программирования наличие IDE, написанных на этом языке? Ведь написание даже текстового редактора -- это уже не простая задача (не зря же GoF использует текстовый процессор для иллюстрации основных паттернов). А уж IDE, в которой текстовый редактор, это только небольшая часть, еще более сложный продукт.
Поддерживаю, критерий совсем не плох. В каждой шутке, что называется.
В нормальных императивных языках в качестве похожего критерия есть такая красивая задача — написать транслятор своего языка на самом себе, но эти функционалы и интерпретаторы со своей идеологией "интерпретатор из 10 строчек" все испортили )
E>>А для Haskell? GZ>На ленивых языках в особенности сложней писать подобные вещи. Их мощность в большей степени предназначена для плохо написанных алгоритмов. IMHO Но для большогоЮ распределенного между программистами, приложения ленивость не лучшее свойство.
Ну уж нет, хаскель прекрасен как средство программирования GUI.
взять хотя бы wxhaskell.
Сравниться с ним здесь могут разве что только Tcl/Tk или XUL
А ленивость очень может даже помочь — например, при программировании электронных таблиц. Или интерфейсов к базам данных.
Но, честно говоря, в случае с ним я как-то особой потребности в автоматизации не ощущаю.
Простого редактора + маленького мейкфайла мне пока хватало для любых проектов
Не знаю с чем это связано.. отсутствие синтаксического оверхеда (хороший кстати эвфемизм для похмелья или название панк-группы)? :)
Здравствуйте, Gaperton, Вы писали:
G>Так это же хорошо, что они не мэйнстрим .
Для кого-то и Ruby не мейнстрим, к примеру (на розовых слонов пальцами показывать не будем
G>В этом их прелесть — пока кто-то там рассуждает, мэйнстрим они или нет, другие люди используют их в работе и получают конкурентные преимущества . Я лично — за то, чтобы такая ситуация до какой-то степени сохранялась. G>http://www.rsdn.ru/Forum/Message.aspx?mid=1504996&only=1
Читал-читал. Уникальное в какой-то степени предложение. А о результатах расскажешь?
Имхо, результаты нужно будет смотреть не после первого релиза, а года через 4-5 развития.
G>Почему на легковых машинах не возят железную руду и не пашут грядки? С таким подходом, рекомендую вам купить в семью универсальную машину — штоб и грядку пахать, и в кольцевых гонках учавствовать.
Почему на БелАЗах не ездят по городу, в путешествия и на дачу? С таким подходом желаю тебе попробовать проделать все это, если не на БелАЗ-е, то на КамАЗ-е или ЗИЛ-е
G>P.S.: От души желаю вам писать бухгалтерию на С, IDE на Фортране, оперсистему на Java, а численные расчеты на PHP. До достижения полного просветления.
Не, я как нибудь на C++ пока перебиваться буду. С помощью Ruby.
Кстати, а разве сейчас JavaOS совсем нет?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>А разве Лисп -- это функциональный язык?
IMHO Лисп — это большая помойка различной функциональности. Это касается Schema но особенно касается CLISP(в принципе это два разных языка). Мне от него, прямо говоря, плохо стало. Там есть императив, но в основном юзается функциональный стиль. Зато SML попал в струю. Классно выверенный и концептуально чистый язык. Если захочешь познакомится с функциональными языками, начинай лучше с него(или его последователями).
Здравствуйте, GlebZ, Вы писали:
GZ>Зато SML попал в струю. Классно выверенный и концептуально чистый язык. Если захочешь познакомится с функциональными языками, начинай лучше с него(или его последователями).
Не знаю, не знаю.
С чем есть желание познакомиться поближе и попрограммировать чего-нибудь, так это со Smalltalk-ом. Именно пропрограммировать, а не книжки почитать.
Еще интересен Erlang, поскольку мы на C++ сделали framework для мультипоточного и распределенного программирования, где взаимодействие сущностей осуществляется только через отсылку сообщений. Интересно было бы сравнить.
Но на это катастрофически не хватает времени.
Что же касается разных Haskell-ей и OCaml-ов, пока не зацепили они меня. Получается что-то вроде анекдота:
-- Знаешь, а Карузо не такой уж великий певец.
-- А ты что, слушал Карузо?
-- Нет, но мне друг по телефону напел.
Не хватает каких-то фрагментов, которые бы показали: вот на Haskell-е (OCaml-е) это делается всего двумя строчками, а на C++ (Java/C#) или Ruby/Python -- 150 строк, да еще и потенциально опасных. Пока, мне кажется, идет скандирование: функциональный стиль -- это круто! И пожелания походить по google, поискать, почитать чего-нибудь, чтобы быть в теме.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, reductor, Вы писали:
E>>Ну... Научиться программировать вообще, это в моем случае (надеюсь), уже пройденый этап.
R>Я так думал несколько раз. Последний раз понял, что это не так, когда стал программировать на Haskell.
А я вот не разубеждался пока. Программирование -- это процесс раскладывания по полочкам всего, что нужно для достижения цели. Если этот процесс освоен, то конкретный подход (структурный, ООП или логический, как в Прологе) не имеет значения.
E>>Хотелось бы услышать или увидеть, чтоже в нем такого-эдакого. Только популярно.
R>Не хочу повторяться. Можно сделать поиск здесь или в гугле и получить тонну sales talks на эту тему
Жаль.
... << 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 и ничего больше? Ты глубоко заблуждаешься.
Ну и что? Мне-то что с того?
Вообще идеальный потребительский подход — смотреть на чью-то популярность.
E>Я вот на C++ программирую. И все программируют, кто его знает. E>Я и для себя на С++ программирую, да еще и на работе.
E>Так что наши личные пристрастия здесь не показатель.
Ну в моем случае у меня еще и практическая сторона присутствует.
Я всегда выбираю наиболее подходящий инструмент.
Здравствуйте, eao197, Вы писали:
E>>>Это вряд ли. Ничто не дается даром. Тонкие моменты нужно знать. Вот, например, в Ruby 1.8.0 есть обычные блоки кода и получаемые с помощью оператора lambda. С виду одно и тоже. В чем же разница?
R>>Я мало что помню про руби конечно, но рискну предположить — в замыкании лексического контекста? Или кто-то из них компилит функцию из строки типа Function в javascript?
E>Умный термин "замыкания лексического контекста". Даже не знаю о чем это.
Определенно, это становится модным — не знать основных терминов, принятых в языках программирования. Об этом теперь принято заявлять с гордостью, вместо того, чтобы потратить 5 минут на чтение википедии. Так, штоли?
E>Разница в том, как отрабатывает оператор break внутри обычного (raw) code block и внутри lambda. Тонкое различие, но его незнание может дорого обойтись.
Если бы вы знали, что такое лямбда-функции и лексические замыкания (lexical closures), то это различие не показалось бы вам "тонким" даже при первом чтении мануала по языку.
Возвращаясь к нашим автомобильным аналогиям — это примерно то же самое, что перепутать бензобак с расширительным бачком системы охлаждения. Незнание тонкого различия между ними тоже может дорого обойтись.
Здравствуйте, aik, Вы писали:
E>>Пусть на меня не обижаются приверженцы этих языков, но действительно интересно понять, отчего же, если OCaml, Haskell, SML и пр. насколько хорошие языки, позволяют писать мало кода и получать высокую скорость работы, они все еще не мейнстрим?
aik>Что на рынок пропихивается — тем и пользуются. "Мало кода", "скорость" — это все мимо рынка. Даже синтаксис жавы был позаимствован у c/c++ чтоб жаба выглядело не сильно иначе и лучше продавалась.
Рынок в данном случае -- это отмазка. Для Python, Perl и Ruby не было никакой коммерческой поддержки. Тем не менее, они популярны. И IDE для них пишутся, часто силами одиночек-энтузиастов.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>>>Пусть на меня не обижаются приверженцы этих языков, но действительно интересно понять, отчего же, если OCaml, Haskell, SML и пр. насколько хорошие языки, позволяют писать мало кода и получать высокую скорость работы, они все еще не мейнстрим? aik>>Что на рынок пропихивается — тем и пользуются. "Мало кода", "скорость" — это все мимо рынка. Даже синтаксис жавы был позаимствован у c/c++ чтоб жаба выглядело не сильно иначе и лучше продавалась. E>Рынок в данном случае -- это отмазка. Для Python, Perl и Ruby не было никакой коммерческой поддержки. Тем не менее, они популярны. И IDE для них пишутся, часто силами одиночек-энтузиастов.
Эти мрачные языки могут только мечтать о популярности Java или VisualBasic. Даже на JavaScript больше лабают.
Разве что Perl тут некоторое исключение, он вовремя появился и занял рынок быстрых парсеров. И то в ASP его не шибко любят и с ростом количества серверов его популярность будет падать.
Здравствуйте, eao197, Вы писали:
aik>>Даже синтаксис жавы был позаимствован у c/c++ чтоб жаба выглядело не сильно иначе и лучше продавалась.
E>Разве Java продавалась?
А C++ продавался? А C# продаётся?
Я думаю, в этом контексте речь идёт об использовании Java девелоперами, что влечёт за собой покупку софта для серверов (ну и по мелочи — средства разработки и т.д.).
Здравствуйте, eao197, Вы писали:
aik>>Даже синтаксис жавы был позаимствован у c/c++ чтоб жаба выглядело не сильно иначе и лучше продавалась. E>Разве Java продавалась?
Конкретно Java компилятор и SDK — нет. А софт, тренинги всякие — еще как.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, _vovin, Вы писали:
_>>Каждая имплементация сразу идет с IDE. Идеологически иначе невозможно, пропадет то самое sea of live objects.
Д>ну вот например ObjectStudio Д>тянет за собой MFC-шные библиотеки, и если посмотреть спаем, то по стилям окон видно, что они написаны на MFC Д> :xz:
VisualWorks
Smalltalk/X
Squeak
Еще вроде Visual Age, но тут не уверен — пару раз видел только.
Но конечно называть то, что идет со смоллтолком IDE — это слишком.
Ну то есть в случае с ним сочетание "Integrated Development Environment" лишено всякого смысла.
Кстати еще забавно указание его в теме про "функциональные" языки. в смоллтолке же лямбда на лямбде сидит и лямбдой погоняет.
он больше функциональный, чем ОО-язык.
Здравствуйте, aik, Вы писали:
aik>Эти мрачные языки могут только мечтать о популярности Java или VisualBasic.
aik>Даже на JavaScript больше лабают.
Откуда дровишки?
aik>Разве что Perl тут некоторое исключение, он вовремя появился и занял рынок быстрых парсеров. И то в ASP его не шибко любят и с ростом количества серверов его популярность будет падать.
Есть такая платформа HP NonStop (в девичестве Tandem), супер-пупер надежная, супер дорогая и пр., для серьезного бизнеса (банки, биржи, телекоммуникации, AOL и пр.). Посмотри на список софта, который туда спортировали: http://www.itug.org/member/ituglib/user/search.cfm (достаточно просто нажать "I Agree, Begin Search" чтобы получит полный список).
Как не странно, там есть Perl, Python, Ruby и Tcl. Казалось бы, зачем серьезным дядькам из HP заниматься портированием на серьезную платформу для серьезного бизнеса такие мрачные, не популярные, и никому не нужные языки?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, reductor, Вы писали:
R>Здравствуйте, Дарней, Вы писали:
Д>>Здравствуйте, _vovin, Вы писали:
_>>>Каждая имплементация сразу идет с IDE. Идеологически иначе невозможно, пропадет то самое sea of live objects.
Д>>ну вот например ObjectStudio Д>>тянет за собой MFC-шные библиотеки, и если посмотреть спаем, то по стилям окон видно, что они написаны на MFC Д>>
ObjectStudio — win-only диалект, так что ситуация вполне возможна
R>VisualWorks R>Smalltalk/X R>Squeak
R>Еще вроде Visual Age, но тут не уверен — пару раз видел только.
Тот же принцип, что и в SWT.
R>Но конечно называть то, что идет со смоллтолком IDE — это слишком. R>Ну то есть в случае с ним сочетание "Integrated Development Environment" лишено всякого смысла. R>Кстати еще забавно указание его в теме про "функциональные" языки. в смоллтолке же лямбда на лямбде сидит и лямбдой погоняет. R>он больше функциональный, чем ОО-язык.
Здравствуйте, Voblin, Вы писали:
V>Молотком можно забить гвоздь, Топором можно забить гвоздь. Пассатижами — тоже. Даже лампочкой можно забить гвоздь! V>Но транзистором гвоздь забить нельзя. Поэтому транзистор не универсален.
Хорошая аналогия, но не к месту. Все же молоток не является полупроводником, и транзистор не является молотком. А вот Scheme, OCaml, SML, Smalltalk, Ruby, Python, C++, Java -- все это языки программирования.
Лучше сравни универсальность молотка, киянки и кувалды.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, mrozov, Вы писали:
M>Браво! Ты только что доказал, что .net — не универсальный язык, хуже smalltalk и питона.
Да на NET вроде как целую ОС пишут
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, aik, Вы писали:
aik>Разве что Perl тут некоторое исключение, он вовремя появился и занял рынок быстрых парсеров.
Дук у него синтаксис тоже на С похож
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, eao197, Вы писали:
E>Пусть на меня не обижаются приверженцы этих языков, но действительно интересно понять, отчего же, если OCaml, Haskell, SML и пр. насколько хорошие языки, позволяют писать мало кода и получать высокую скорость работы, они все еще не мейнстрим? E>Есть у меня подозрение, что универсальность этих языков э... несколько ограничена. Но насколько?
Мое мнение уже писал: Re[19]: Goto's are evil?
E>А вот что извесно про IDE для OCaml на самом OCaml? (Cameleon, последняя стабильная версия которого, судя по сайту, вышла в октябре 2003-го). E>А для Haskell?
На ленивых языках в особенности сложней писать подобные вещи. Их мощность в большей степени предназначена для плохо написанных алгоритмов. IMHO Но для большогоЮ распределенного между программистами, приложения ленивость не лучшее свойство. E>А для SML и других языков ML-группы?
Ocaml — из ML группы. Такие языки легко проследить по окончанию.
E>На самом деле даже я расцениваю этот вопрос не как самый серьезный (изрядная доля шутки в нем есть), но все же...
Не думаю что данный вопрос кого-то останавливает. Все по моему сложнее.
Здравствуйте, Глеб Алексеев, Вы писали:
ГА>Здравствуйте, GlebZ, Вы писали:
GZ>>Когда-то был Turbo-Prolog. Поставлялся вместе с IDE. ГА>И отличная была вещь, доложу я вам .
Ага. У меня до сих пор дома стоит. (в свое время стибрил с института).
Здравствуйте, Трурль, Вы писали:
E>>Например, Ruby в большинстве случаев может заменить C++ и наоборот. SQL или даже Unix shell этого сделать не могут.
Т>А может ли C++ заменить SQL?
Легко. Зная API доступа к какому-либо низкоуровневому API я могу на C++ запрограммировать условие поиска и выбора.
В ранних объектных СУБД, которые OQL не поддерживали программирование выборки объектов осуществлялось как создание нескольких C++ объектов и их хитрое провязывание. Например, в POET так было.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Легко. Зная API доступа к какому-либо низкоуровневому API я могу на C++ запрограммировать условие поиска и выбора. E>В ранних объектных СУБД, которые OQL не поддерживали программирование выборки объектов осуществлялось как создание нескольких C++ объектов и их хитрое провязывание. Например, в POET так было.
Ага. Это все равно что новый язык Слишком много ограничений и определений. Декларативные OQL/SQL рулят.
Здравствуйте, reductor, Вы писали:
R>Ну уж нет, хаскель прекрасен как средство программирования GUI. R>взять хотя бы wxhaskell. R>Сравниться с ним здесь могут разве что только Tcl/Tk или XUL
Ты об этом?http://wxhaskell.sourceforge.net/
wxHaskell is a portable and native GUI library for Haskell. The goal of the project is to provide an industrial strength GUI library for Haskell, but without the burden of developing (and maintaining) one ourselves.
wxHaskell is therefore built on top of wxWidgets – a comprehensive C++ library that is portable across all major GUI platforms; including GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library (in development since 1992) that supports a wide range of widgets with the native look-and-feel, and it has a very active community (ranked among the top 25 most active projects on sourceforge).
R>А ленивость очень может даже помочь — например, при программировании электронных таблиц. Или интерфейсов к базам данных.
Электронные таблица — может быть. Но что касается интерфейсов к многопользовательским базам данных, то там ленивость по боку, и даже вредна. Там слишком важно детерменировано получать данные и также детерменированно в один момент их записывать.
R>Но, честно говоря, в случае с ним я как-то особой потребности в автоматизации не ощущаю. R>Простого редактора + маленького мейкфайла мне пока хватало для любых проектов R>Не знаю с чем это связано.. отсутствие синтаксического оверхеда (хороший кстати эвфемизм для похмелья или название панк-группы)?
А какого рода программы делаешь?
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, reductor, Вы писали:
R>>Ну уж нет, хаскель прекрасен как средство программирования GUI. R>>взять хотя бы wxhaskell. R>>Сравниться с ним здесь могут разве что только Tcl/Tk или XUL
Да
а к чему такая полная цитата?
R>>А ленивость очень может даже помочь — например, при программировании электронных таблиц. Или интерфейсов к базам данных. GZ>Электронные таблица — может быть. Но что касается интерфейсов к многопользовательским базам данных, то там ленивость по боку, и даже вредна. Там слишком важно детерменировано получать данные и также детерменированно в один момент их записывать.
Что зачем детерминировано?
Можно расшифровать мысль?
R>>Но, честно говоря, в случае с ним я как-то особой потребности в автоматизации не ощущаю. R>>Простого редактора + маленького мейкфайла мне пока хватало для любых проектов R>>Не знаю с чем это связано.. отсутствие синтаксического оверхеда (хороший кстати эвфемизм для похмелья или название панк-группы)? :) GZ>А какого рода программы делаешь?
Околобанковскобиржевые ;)
На самом деле разные и еще для души совсем разные.
Здравствуйте, reductor, Вы писали:
R>Только IDE — это вообще само по себе очень коммерческое понятие. Оно свидетельствует о рынке, а не о достоинствах или недостатках языка.
Об этом, насколько я понял, и идёт речь. Пригодны ли языки к рынку. То что, они хороши, и так понятно.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, reductor, Вы писали:
R>Знали бы один, получили бы проблемы.
Наоборот. Я видел, как люди после Java делают подобные вещи, не понимая, что возвращают и передают аргументы по значению.
E>>По мне, так лучше хорошо знать язык на котором программируешь постоянно, чем держать в голове массу идиом из разных языках и пытаться бездумно использовать Ruby-стиль в C++ или C++ стиль в Ruby.
R>Почему бездумно. можно и думая
В том-то и фокус, что для того, чтобы думать, нужно много узнать. А чтобы много узнать, нужно много времени и усилий.
R>На нем не на нем — язык — это кроме синтаксиса и низкоуровневых технических подробностей еще и определенный стиль мышления и характерные приемы и тп.
Наконец-то, дошло о чем я постоянно говорю.
R>Которые неочевидны в других языках, потому что нетривиальны там.
И польза от перетаскавания этих приемов в языки, где это неочевидно, лично для меня, сомнительна.
R>Они потому и кажутся таким сложными для изучения, что их стиль в С++ облагается большим налогом и на синтаксис и на семантику. В лиспе или схеме это совершенно простые и тривиальные вещи. Но не зная лиспа и схемы изучить их в С++ действительно сложно, а придумать — так и просто почти нереально.
А может и не зачем. Хороший пример -- библиотека ACE. Написана, как многим кажется, на "С с классами". Тем не менее, C++ там задействуется весьма широко и удачно. В отличии от boost-а (имхо).
R>А обратного не замечали? когда на С++ в руби-стиле?
Нет, не получается. Хотя C++ шаблоны позволяют делать что-то типа Duck Typing-а, но отсутствие в C++ code blocks или можножностей метапрограммирования из Ruby делают это совершенно бесполезным занятием. В C++ свои рецепты, в Ruby -- свои.
R>Вообще интересен ваш выбор, хочу сказать. R>Руби — далеко не самый последовательный язык.
А я его не за последовательность выбирал. А за распространенность (в смысле числа поддерживаемых платформ). А у Perl-а и Python-а он в начале выиграл из-за своего синтаксиса (нет такого количества спецсимволов как Perl и не нужно структурировать программу пробелами, как Python). Это потом уже я другие качества Ruby рассмотрел. Короче, выбирал конкретный язык для конкретной задачи.
R>Знаете, уж что-что, а "востребованность" синонимом качества никогда не являлась. Алла Пугачева и Макдональдс — очень даже востребованы. Не-не, если кого задело, Пугачева и Макдональдс — прекрасны. Но все же.
А Jean-Michel Jarre, Pink Floyd, Кино и Крематорий? Неужели они не восстребованны?
R>Только IDE — это вообще само по себе очень коммерческое понятие. Оно свидетельствует о рынке, а не о достоинствах или недостатках языка.
А рынок, вообще-то, халтуру не очень жалует.
E>>Это вряд ли. Ничто не дается даром. Тонкие моменты нужно знать. Вот, например, в Ruby 1.8.0 есть обычные блоки кода и получаемые с помощью оператора lambda. С виду одно и тоже. В чем же разница?
R>Я мало что помню про руби конечно, но рискну предположить — в замыкании лексического контекста? Или кто-то из них компилит функцию из строки типа Function в javascript?
Умный термин "замыкания лексического контекста". Даже не знаю о чем это.
Разница в том, как отрабатывает оператор break внутри обычного (raw) code block и внутри lambda. Тонкое различие, но его незнание может дорого обойтись.
R>То есть после руби питон или перл учить — почти ничего не стоит.
А зачем их вообще учить после Ruby?
R>Вы всегда будете делать осознанный выбор и мотивировать чем-то.
Да, но выбирая между распространенными языками есть гарантия того, что проект не зачахнет из-за недостатка программистов со знанием нужного языка.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>Хе-хе . Допустим, я на КамАЗ-е вожу дерьмо, а по выходным в ресторан ежжу на 300-м мерседесе . Так — можно?
Так да.
Только интересно, в такой интерпритации, к примеру, OCaml -- это мерс или таки Камаз?
E>>Не, я как нибудь на C++ пока перебиваться буду. С помощью Ruby. G>Выкрутился, однако
А то
E>>Кстати, а разве сейчас JavaOS совсем нет? G>Я вполне допускаю и существование бухгалтерских программ на С .
Я вообще-то к тому, что сейчас же есть масса умных устройств, на которых J2ME должна работать. На каких-то, вполне возможно, и операционка на Java написана.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>В том-то и фокус, что для того, чтобы думать, нужно много узнать. А чтобы много узнать, нужно много времени и усилий.
Да. Чтобы программировать научиться вообще нужно много времени.
R>>На нем не на нем — язык — это кроме синтаксиса и низкоуровневых технических подробностей еще и определенный стиль мышления и характерные приемы и тп. E>Наконец-то, дошло о чем я постоянно говорю.
Ха. Ха.
R>>Которые неочевидны в других языках, потому что нетривиальны там. E>И польза от перетаскавания этих приемов в языки, где это неочевидно, лично для меня, сомнительна.
Ну это все сомнительно, пока сравнивать не с чем.
E>А я его не за последовательность выбирал. А за распространенность (в смысле числа поддерживаемых платформ). А у Perl-а и Python-а он в начале выиграл из-за своего синтаксиса (нет такого количества спецсимволов как Perl и не нужно структурировать программу пробелами, как Python). Это потом уже я другие качества Ruby рассмотрел. Короче, выбирал конкретный язык для конкретной задачи.
Syntax sucks (c) comp.lang.lisp
E>Неужели они не восстребованны?
Не-не-не. Только без холивор в области музыки.
R>>Только IDE — это вообще само по себе очень коммерческое понятие. Оно свидетельствует о рынке, а не о достоинствах или недостатках языка.
E>А рынок, вообще-то, халтуру не очень жалует.
Сравним объем рынка пугачевой и крематория?
E>Умный термин "замыкания лексического контекста". Даже не знаю о чем это.
Так узнайте. Или не хотите узнать?
R>>То есть после руби питон или перл учить — почти ничего не стоит. E>А зачем их вообще учить после Ruby?
Чтобы знать как еще можно делать _это_. Меня вот от руби подташнивает. А когда-то я перлу радовался как ребенок.
E>Да, но выбирая между распространенными языками есть гарантия того, что проект не зачахнет из-за недостатка программистов со знанием нужного языка.
Да ладно. Лично я на знания языков не смотрю. Если человек вменяемый, он выучит то, что нужно.
Это в общем основной критерий отбора — готовность учиться.
Здравствуйте, reductor, Вы писали:
E>>В том-то и фокус, что для того, чтобы думать, нужно много узнать. А чтобы много узнать, нужно много времени и усилий. R>Да. Чтобы программировать научиться вообще нужно много времени.
Ну... Научиться программировать вообще, это в моем случае (надеюсь), уже пройденый этап.
А вот необходимость научиться программировать на конкретном еще одном языке программирования -- это вполне конкретный вопрос. Ответ на который зависит от многих факторов. Можно, например, прочитать tutorial по OCaml, а можно еще раз "Язык программирования С++" или книгу про Boost или ACE. От последних практической пользы получается достаточно много. А вот от OCaml... Хотелось бы услышать или увидеть, чтоже в нем такого-эдакого. Только популярно.
E>>А рынок, вообще-то, халтуру не очень жалует. R>Сравним объем рынка пугачевой и крематория?
Во-первых, рынка музыки Пугачевой я вообще не вижу
Ну а серьезно, называть работу Пугачевой халтурой я бы не стал. Да, ее музыка мне не нравится. Но в ее профессионализме я не сомневаюсь.
E>>Умный термин "замыкания лексического контекста". Даже не знаю о чем это. R>Так узнайте. Или не хотите узнать?
А зачем?
R>>>То есть после руби питон или перл учить — почти ничего не стоит. E>>А зачем их вообще учить после Ruby?
R>Чтобы знать как еще можно делать _это_.
А зачем, если я _это_ и так делаю на Ruby, и я знаю, что на Perl или Python существенной разницы не будет?
Так просто, для банальной эрудиции?
R>Меня вот от руби подташнивает. А когда-то я перлу радовался как ребенок.
Мне уже давно кажется, что при выборе языка слишком сильную роль играют личные предпочтения. И, как бы это сказать, совместимость языка и программиста. Я вот пока учился и Бейсик пробовал, и Паскаль, и C, и Пролог. Паскаль нравился, но не цеплял. А вот когда взялся за C++ почувствовал -- мое это. И до сих пор C++ для меня родной. Затем другие языки пробовал, но еще раз такое впечатление возникло в Ruby.
Сдается мне, что у многих такая же симпатия к Lisp-у, OCaml-у, Haskell-у, Erlang-у и пр. Ну ваши это языки. Думаете вы на них, как я на C++.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>>>В том-то и фокус, что для того, чтобы думать, нужно много узнать. А чтобы много узнать, нужно много времени и усилий. R>>Да. Чтобы программировать научиться вообще нужно много времени.
E>Ну... Научиться программировать вообще, это в моем случае (надеюсь), уже пройденый этап.
Я так думал несколько раз. Последний раз понял, что это не так, когда стал программировать на Haskell.
E>А вот необходимость научиться программировать на конкретном еще одном языке программирования -- это вполне конкретный вопрос. Ответ на который зависит от многих факторов. Можно, например, прочитать tutorial по OCaml, а можно еще раз "Язык программирования С++" или книгу про Boost или ACE. От последних практической пользы получается достаточно много. А вот от OCaml... Хотелось бы услышать или увидеть, чтоже в нем такого-эдакого. Только популярно.
Не хочу повторяться. Можно сделать поиск здесь или в гугле и получить тонну sales talks на эту тему :)
E>>>Умный термин "замыкания лексического контекста". Даже не знаю о чем это. R>>Так узнайте. Или не хотите узнать? E>А зачем? :shuffle:
Из любопытства.
R>>>>То есть после руби питон или перл учить — почти ничего не стоит. E>>>А зачем их вообще учить после Ruby?
R>>Чтобы знать как еще можно делать _это_.
E>А зачем, если я _это_ и так делаю на Ruby, и я знаю, что на Perl или Python существенной разницы не будет? E>Так просто, для банальной эрудиции?
Для небанальной.
E>Мне уже давно кажется, что при выборе языка слишком сильную роль играют личные предпочтения. И, как бы это сказать, совместимость языка и программиста. Я вот пока учился и Бейсик пробовал, и Паскаль, и C, и Пролог. Паскаль нравился, но не цеплял. А вот когда взялся за C++ почувствовал -- мое это. И до сих пор C++ для меня родной. Затем другие языки пробовал, но еще раз такое впечатление возникло в Ruby. E>Сдается мне, что у многих такая же симпатия к Lisp-у, OCaml-у, Haskell-у, Erlang-у и пр. Ну ваши это языки. Думаете вы на них, как я на C++.
Я меня такая симпатия возникала раз 10. В т.ч и к С++ очень давно.
Слава богу, ненадолго.
Здравствуйте, 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 — не единственный критерий выбора языка. Есть множество других как технических, так и политических.
К тому же, я говорю не о языках, а а знаниях. Причем не привязанные к конкретному языку. От которых ты отплевываешься.
Здравствуйте, 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++.
Здравствуйте, 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
Здравствуйте, reductor, Вы писали:
E>>И дальше? Ну хвалят Lisp. Только программировать на нем не торопяться. Равно как и на Haskell-е.
R>Чооо? R>Да я ... да ты ... да вы ...
R>Нет, правда, что за голословные утверждения. Я программирую. И все программируют, кто их знают. R>Хотя бы для себя. Я имею счастье еще и по работе.
Здравствуйте, Cyberax, Вы писали:
>> Ну и что? Мне-то что с того? >> Вообще идеальный потребительский подход — смотреть на чью-то популярность.
C>Вообще-то популярность языков на sf.net — это очень неплохой показатель, C>так как там (в основном) не коммерческие проекты, а "персональные" C>проекты, для которых обычно выбирают "любимый" язык.
C>Кстати, лет 6 назад я удивился большому количеству проектов на Питоне в C>sf.net (и решил посмотреть что это за язык). Тогда про Питон почти C>ничего слышно не было, а проекты на sf.net уже были.
Посмотрите, пожалуйста, на заголовок этой ветки.
Меня, как человека, использующего эти технологии, не очень сильно волнует их популярность.
Даже скорее с позиции бизнеса я заинтересован, чтобы они продолжали оставаться тем, где сейчас есть.
И меня, например, сильно пугает та скорость, с которой набирает обороты Haskell. За последний год поток новостей о нем увеличился в несколько раз.
А то что я здесь фактически против своих интересов действую — это так, донкихотство и некоторым образом романтика.
И я кстати не думаю и не надеюсь, что у меня получится переубедить здесь многих. А тех, что удастся... Что ж, может найду интересных людей для плодотворных дискуссий. Может даже еще и поработать когда-нибудь вместе выйдет ;)
Cyberax wrote: > >> Вообще идеальный потребительский подход — смотреть на чью-то популярность. > > Вообще-то популярность языков на sf.net — это очень неплохой показатель, > так как там (в основном) не коммерческие проекты, а "персональные" > проекты, для которых обычно выбирают "любимый" язык.
И что с того? Кто на чем пишет на работе, тот на этом же будет писать и
для себя (в среднем). Кроме того, вполне очевидно, что необходимость
поставить какой-нибудь экзотический компилятор отпугнет возможных
пользователей программы, особенно если программа опенсорсовая (т.е.,
собирать ее должен пользователь).
Здравствуйте, Gaperton, Вы писали:
E>>Умный термин "замыкания лексического контекста". Даже не знаю о чем это. G>Определенно, это становится модным — не знать основных терминов, принятых в языках программирования.
Да, воинствующая безграмотность. Не знаниями, а нахрапом.
Методом brute force много чего достичь можно
Я проиронизировал по поводу термина, потому что, имхо, его можно было проинтерпритировать несколькими способами:
-- что будет доступно lambda из контекста вызывающий функции;
-- что будет доступно внутри lambda и будут ли сохраняться эти значения от вызова к вызову;
-- какое влияние выход из lambda будет оказывать на вызывающий контекст.
G>Об этом теперь принято заявлять с гордостью, вместо того, чтобы потратить 5 минут на чтение википедии. Так, штоли?
E>>Разница в том, как отрабатывает оператор break внутри обычного (raw) code block и внутри lambda. Тонкое различие, но его незнание может дорого обойтись.
G>Если бы вы знали, что такое лямбда-функции и лексические замыкания (lexical closures), то это различие не показалось бы вам "тонким" даже при первом чтении мануала по языку.
Возможно.
Тогда, вероятно, легко предугадать результаты работы в следующем примере:
def test_block &b
b.call "a", "b"
puts "done"
end
def test_lambda l
l.call "a", "b"
puts "done"
end
test_block { |x,y| puts x + y; break }
test_lambda Proc.new { |x,y| puts x + y; break }
test_lambda lambda { |x,y| puts x + y; break }
Прав был VladD2, на "вы" здесь переходят только при выяснении отношений.
G>Возвращаясь к нашим автомобильным аналогиям — это примерно то же самое, что перепутать бензобак с расширительным бачком системы охлаждения. Незнание тонкого различия между ними тоже может дорого обойтись.
А я не автомобилист, эта аналогия мне ровно ничего не сказала
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Ведь написание даже текстового редактора -- это уже не простая задача (не зря же GoF использует текстовый процессор для иллюстрации основных паттернов). А уж IDE, в которой текстовый редактор, это только небольшая часть, еще более сложный продукт.
С таким подходом, рекомендую вам купить в семью универсальную машину — штоб и грядку пахать, и в кольцевых гонках учавствовать.
Грязный SML, вызывающий рвотный рефлекс — "классно выверенный и концептуально чистый язык"?! 
