Здравствуйте, 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>он больше функциональный, чем ОО-язык.
<skipped>
E>... а почему бы не взять в качестве критерия оценки универсальности языков программирования наличие IDE, написанных на этом языке? Ведь написание даже текстового редактора -- это уже не простая задача (не зря же GoF использует текстовый процессор для иллюстрации основных паттернов). А уж IDE, в которой текстовый редактор, это только небольшая часть, еще более сложный продукт.
Поддерживаю, критерий совсем не плох. В каждой шутке, что называется.
В нормальных императивных языках в качестве похожего критерия есть такая красивая задача — написать транслятор своего языка на самом себе, но эти функционалы и интерпретаторы со своей идеологией "интерпретатор из 10 строчек" все испортили )
Здравствуйте, 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. ГА>И отличная была вещь, доложу я вам .
Ага. У меня до сих пор дома стоит. (в свое время стибрил с института).
Здравствуйте, 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 минут долететь" (с) м/ф Крылья, Ноги, Хвост
Здравствуйте, 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>>А для Haskell? GZ>На ленивых языках в особенности сложней писать подобные вещи. Их мощность в большей степени предназначена для плохо написанных алгоритмов. IMHO Но для большогоЮ распределенного между программистами, приложения ленивость не лучшее свойство.
Ну уж нет, хаскель прекрасен как средство программирования GUI.
взять хотя бы wxhaskell.
Сравниться с ним здесь могут разве что только Tcl/Tk или XUL
А ленивость очень может даже помочь — например, при программировании электронных таблиц. Или интерфейсов к базам данных.
Но, честно говоря, в случае с ним я как-то особой потребности в автоматизации не ощущаю.
Простого редактора + маленького мейкфайла мне пока хватало для любых проектов
Не знаю с чем это связано.. отсутствие синтаксического оверхеда (хороший кстати эвфемизм для похмелья или название панк-группы)? :)
Здравствуйте, Трурль, Вы писали:
E>>Например, Ruby в большинстве случаев может заменить C++ и наоборот. SQL или даже Unix shell этого сделать не могут.
Т>А может ли C++ заменить SQL?
Легко. Зная API доступа к какому-либо низкоуровневому API я могу на C++ запрограммировать условие поиска и выбора.
В ранних объектных СУБД, которые OQL не поддерживали программирование выборки объектов осуществлялось как создание нескольких C++ объектов и их хитрое провязывание. Например, в POET так было.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Ведь написание даже текстового редактора -- это уже не простая задача (не зря же GoF использует текстовый процессор для иллюстрации основных паттернов). А уж IDE, в которой текстовый редактор, это только небольшая часть, еще более сложный продукт.
