Здравствуйте, Gajdalager, Вы писали:
G>Здравствуйте, FR, Вы писали:
FR>>Здравствуйте, Gajdalager, Вы писали:
G>>>Однако для разных задач — разные подходы, поэтому удобно в "настоящем" программировании использовать язык, который позволяет делать и так, и эдак. К сожалению, из языков, которые декларируют такой подход, я знаю только Скалу (ну и еще читал доку и образцы кода Немерла, однако, поскольку даже его компилятора нет, не могу сказать, что я его "знаю")..
FR>>lisp (и схема), Ocaml, Dylan, кроме того в питоне с руби тоже вполне удобно программировать в функциональном стиле. G>Не, ну я знаю, что таковые существуют.. Я имел в виду, на них не программировал, посему не могу о них рассуждать... Правда питоновские __что-то__, мягко говоря, отпугивают..
Ну возьми руби
G>В перле тоже прикрутили ООП опосля, и оно там совсем некрасиво выглядит.. Раздражает, допустим, необходимость в методе fetch-а ссылки на себя как параметра
В питоне ООП практически всегда был, просто он немного минималистский и с уклоном в ОО в стиле смалталка.
G>>> (ну и еще читал доку и образцы кода Немерла, однако, поскольку даже его компилятора нет PI>>а что тебе мешает его заиметь? G>Не знаю .Net'а, так придеться учить и его, и язык одновременно.. Скала, походу, довольно похожа, а либы можно пользовать Жавишные, которые лучше знаю..
жава и дотнет — сестры
но если ты сидишь на жаве, то тебе так же бессмысленно будет переходить на дотнет, как и мне, допустим с дотнета на жабу
тут, по сути только такие пункты:
+ жаба реально кросс-платформенна
— она тормозит
— в скале нет макросов
это по сравнению с дотнетом
в принципе, можно остаться на жаве и быть счастливым со Скалой
можно даже "экскурсии" в дотнет совершать (благо Скала компилится и под дотнет)
но то, что в ней нет макросов для меня на Скале ставит крест
Здравствуйте, Mirrorer, Вы писали:
M>Здравствуйте, Gajdalager, Вы писали:
M>>>Там есть присваивание, можно соорудить for при желании и прочая, прочая, прочая.
G>>Правильно.. Однако согласись, что написать for на С(и наследниках его синтаксиса, есно — ++, Java, # и прочая) или, к примеру, Paskal, намного проще и естественней, чем на Схеме.. M>Писать в каком стиле ? С для ООП подходит слабо. Остальные хороши для ООП но слабо подходят для FP. Для некоторых задач вообще лучший выбор это Prolog. Это еще одна точка зрения на задачу.
M>На функциональных языках сложно писать, потому, что смотришь на решение задачи через призму старых привычек, пытаешься сделать так, как ты бы сделал в знакомых тебе языках. Но соль в том, что нужно делать по другому. Нужно пытаться мыслить в категориях FP. Поначалу это сложно. Как допустим научиться ходить. Я тоже сейчас изучаю FP, и не могу сказать что для меня это просто. Но понимание растет, и теперь для некоторых задач я могу искать решение в двух плоскостях — OOP & FP. В одни случаях лучше одно, в других — другое. M>И чем больше опыта, тем проще понять, какой подход в данном случае лучше.
Я с этим и не спорю. Однако, если писать на Схеме, без того, чтобы "пытаться мыслить в категориях FP", никак не обойтись. Это замечательно, поскольку поначалу придётся долго думать, как реализовать задачи, которые в привычных языках решаться на автомате, "слетают с кончиков пальцев". Так легче выучить новую парадигму. Однако я хотел сказать, что Схема не заточена под императив. На ней можно писать в императивном стиле(так же, как и в Жаве в функциональном), но это будет неудобно. Я хочу сказать, что языки, которые помогают тебе "искать решение в двух плоскостях — OOP & FP" и позволяют естественно комбинировать подходы, можно считать более успешными кандидатами на "мэйнстрим"(хотя это слово сродне слову "попса", другого не подберу )
Здравствуйте, Gajdalager, Вы писали:
G> Я хочу сказать, что языки, которые помогают тебе "искать решение в двух плоскостях — OOP & FP" и позволяют естественно комбинировать подходы, можно считать более успешными кандидатами на "мэйнстрим"(хотя это слово сродне слову "попса", другого не подберу )
Ну дык Lisp под твой критерий попадает, равно как и OCaml. Только фишка в том, что они больше функциональные, а Scala и Nemerle больше императивные.
Это скорее как инь-янь. Любая сила в момент своего максимума несет в себе зерно своей смерти. Точно так же и с FP/Imperative.
Здравствуйте, FR, Вы писали: FR>Кстати for в лиспе — схеме вполне нормально смотрится:
FR>
FR>(for (x 1 10 2) (println x))
FR>
Эм.. помоему, работать не будет. Нуна так:
(for 0 1 10 2
(lambda (x) (println x)))
А еще лучше проверку на конец фора и инкремент тоже передавать как лямбды.. Чтобы по честному, как в Сях. Можно сделать. Но в языках, для которых базовая структура, это удобней.
Здравствуйте, Mirrorer, Вы писали:
M>Здравствуйте, Gajdalager, Вы писали:
G>> Я хочу сказать, что языки, которые помогают тебе "искать решение в двух плоскостях — OOP & FP" и позволяют естественно комбинировать подходы, можно считать более успешными кандидатами на "мэйнстрим"(хотя это слово сродне слову "попса", другого не подберу )
M>Ну дык Lisp под твой критерий попадает, равно как и OCaml. Только фишка в том, что они больше функциональные, а Scala и Nemerle больше императивные.
M>Это скорее как инь-янь. Любая сила в момент своего максимума несет в себе зерно своей смерти. Точно так же и с FP/Imperative.
Ок.. Однако у Скалы/Немерле по сравнению с Лиспом/Окамлом я вижу еще 2 преимущества:
1. Порог вхождения для программистов на традиционных языках (С++/#/Java) ниже
2. Наличие огромного набора библиотек(а еще на есть на халяву управляемая среда, так что не надо писать свою ВМ и ГЦ)
Здравствуйте, PhantomIvan, Вы писали:
PI>тут, по сути только такие пункты: PI>+ жаба реально кросс-платформенна PI>- она тормозит
Тормоза, имхо, местами сильно преувеличины. Я тут для пробы, сравнил производительность двух примеров на C++ со Scala. Первый, это пример, который упоминал Андрей Хропов
. Второй мой собственный замер организации очереди передачи сообщений между двумя нитями. Пример с BinaryTrees вообще был в два раза быстрее C++ного варианта под Digital Mars C++ и в три раза быстрее, чем Visual C++. Пример с многопоточностью показал скорость передачи сообщений в Scala на 200000 сообщений больше, чем в C++ (800K против 600K).
PI>можно даже "экскурсии" в дотнет совершать (благо Скала компилится и под дотнет)
Компилировалась до версии 1.4, если точнее. Scala2 уже не работает под .NET. Кстати, описание Scala на RSDN уже порядком устарела, Scala2 существенно отличается от Scala1.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Gajdalager wrote: >(а еще на есть на халяву управляемая среда, так что не надо писать свою ВМ и ГЦ)
А для какого из названных языков нужно писать свою ВМ и ГЦ?
Здравствуйте, Gajdalager, Вы писали:
G>Ок.. Однако у Скалы/Немерле по сравнению с Лиспом/Окамлом я вижу еще 2 преимущества: G>1. Порог вхождения для программистов на традиционных языках (С++/#/Java) ниже
Тут однозначно +1. Джае +10
G>2. Наличие огромного набора библиотек(а еще на есть на халяву управляемая среда, так что не надо писать свою ВМ и ГЦ)
У лиспа ГЦ было от рождения, да и библиотек тоже навалом. Я ими не пользовался, но когда смотрел — их действительно много. Конечно может быть меншье чем для джавы, но все равно очень немало.
select (
"age" is smallint,
"name" is clob,
"salary" is int )
from ("persons" naturalJoin "employees")
where (
"gender" == "M" and
("city" == "lausanne" or "city" == "geneva"))
orderBy "age"
Но блин, их API Reference это сплошное издевательство. Такое впечатление, что комментариев при написании библиотек они вообще не делали. И примеров с гулькин нос. Только ScalaByExample и спасает местами.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gajdalager, Вы писали:
G>Здравствуйте, FR, Вы писали: FR>>Кстати for в лиспе — схеме вполне нормально смотрится:
FR>>
FR>>(for (x 1 10 2) (println x))
FR>>
G>Эм.. помоему, работать не будет. Нуна так:
Работает, for стандартная команда для newLISP (схемоподобный язык)
G>
G>(for 0 1 10 2
G> (lambda (x) (println x)))
G>
G>А еще лучше проверку на конец фора и инкремент тоже передавать как лямбды.. Чтобы по честному, как в Сях. Можно сделать. Но в языках, для которых базовая структура, это удобней.
Здравствуйте, PhantomIvan, Вы писали:
PI>Компонентно-Ориентированное Программирование
Спасибо
PI>кстати, как ФВП расшифровывается?
Функции высшего порядка
PI>немерле очень молод, и с этим связана его непопулярность PI>неприятие немерле рсдн-ом пугает PI>одно из двух — либо тут собрались "маргиналы" (фанатики "маргинальных" языков), решающие весьма специфичные задачи, PI>либо немерле обладает каким-либо концептуальным изъяном.
Нет никакого неприятия Немерле. Есть неприятие лозунга "Немерле наше всё, всё остальное сосёт!"
PI>а если толпа идёт куда-то не туда, то что ж придётся проявить некоторую индивидуальность и сообразительность PI>если бы я не считал, что самому (самим) прикрутить к немерле не получится то, что мне нужно, я бы остался с толпой, и ждал бы, пока появится сотня-тысяча программеров на немерле...
Я стараюсь не заниматься ремонтированием молотков, не то, чтобы мне это неинтересно, но времени на это совершенно нет.
PI>что ж, если мы останемся "четырьма людьми, программящим на немерле", то и хорошо — это значит лишь, что мы получаем дополнительные преимущества в конкуренции с "толпой"
А также дополнительные недостатки.
L>>Слушай, а скажи мне, пожалуйста, по секрету. Ты что действительно считаешь, что нет такого пункта, по которому бы Немерле отсеился, а если есть (типа тех что я привёл) — то это зло?
PI>тут проскочил термин "настоящее"-программирование PI>это не "ковыряться", не "изучать", не "лабать дома" PI>это когда есть реальные задачи, которые нужно реализовать, обеспечив взаимодейтсвие с десятком технологий PI>и неважно чего именно не хватает для фортрана (к примеру) — гуи, xml-либы, tcp-классов, тест-фреймворка PI>если не хватает хотя бы одного пункта, то можно фортран вычеркивать из списка PI>это имелось в виду
А что такое "настоящее программирование" оценивают, конечно, немерлисты?
L> А что такое "настоящее программирование" оценивают, конечно, немерлисты?
Когда я говорил про "настоящее" программирование, предполагалось, что его оценивают заказчик
Здравствуйте, PhantomIvan, Вы писали:
VD>>>Ищи в Википедии описание КОП.
L>>Не нашёл. Как расшифровывается?
PI>Компонентно-Ориентированное Программирование
Посмотрел, не понял каким оно боком к "управляемым динамическим возможностям"?
И вообще не понял зачем сравнивать КОП, который есть "набор определенных ограничений, налагаемых на механизм ООП, когда стало ясно, что бесконтрольное использование ООП приводит к проблемам с надежностью больших программных комплексов." с языками в которых таких проблем нет? Типа вот у нас есть такая проблема в языке и мы её вот так красиво решаем! А вы эту проблему в своём языке и не решите так никогда, потому что у вас этой проблемы нет. Бе-бе-бе!
Здравствуйте, lomeo, Вы писали:
L>Вот я Скалу тоже ковыряю.. Верней, уже вроде расковырял. Не скажу, чтобы я её по работе использовал. Хотелось бы, но этот язык не подходит для моей работы
Давай конкретней. Почему не подходит (если не принимать во внимание малораспространенность и вопросы совместимости с другими языками — это слишком банально и понятно)?
Что лучше? Lisp?
L> Это намёк.
На что?
Здравствуйте, Gajdalager, Вы писали:
G>Ок.. Однако у Скалы/Немерле по сравнению с Лиспом/Окамлом я вижу еще 2 преимущества: G>1. Порог вхождения для программистов на традиционных языках (С++/#/Java) ниже
А зато для бывших дельфистов OCaml будет ближе
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, lomeo, Вы писали:
L>>Вот я Скалу тоже ковыряю.. Верней, уже вроде расковырял. Не скажу, чтобы я её по работе использовал. Хотелось бы, но этот язык не подходит для моей работы
АХ>Давай конкретней. Почему не подходит (если не принимать во внимание малораспространенность и вопросы совместимости с другими языками — это слишком банально и понятно)?
С совместимостью как раз всё в порядке. У меня jvm.
Во-первых, я работаю не один, во-вторых, у нас есть набор инструментов, которым мы пользуемся и в который Скалу не воткнёшь. Переписывать же эти инструменты на Скалу нет никакого желания. (Зачем?!) Хотя, говоря откровенно, иногда её можно использовать, только это получится использовать Скалу ради Скалы, преимуществ такого использования я не вижу.
АХ>Что лучше? Lisp?
Кстати, да. Да, не в смысле, что лисп лучше , просто иногда мне удавалось пописать на схеме (по работе) в силу того, что у неё были преимущества перед имеющимся у нас инструментарием.
L>> Это намёк. АХ>На что?
На то, что на фичах языка свет клином не сошёлся, как и на самих языках.
Что то программисты постоянно забывают, что языки это то, как мы на них смотрим. Есть инструменты для работы, а есть для развлечений.
Я много узнаю, когда беру язык, в котором есть что то новое. Но это не значит, что я буду на нём работать. А уж Немерле не годится ни для моей работы (чего там более полезного для меня, чем у меня есть?), ни для фана (чего там нового то для меня?).
Ну и в довесок, даже если бы мощность языка (всё таки абстрактное и субъективное понятие) определяло бы его выбор (что совсем не так, судя по моему опыту), то я бы выбрал не Немерле.
PI>>немерле очень молод, и с этим связана его непопулярность PI>>неприятие немерле рсдн-ом пугает PI>>одно из двух — либо тут собрались "маргиналы" (фанатики "маргинальных" языков), решающие весьма специфичные задачи, PI>>либо немерле обладает каким-либо концептуальным изъяном. PI>>последнее я не списываю со счетов, хотя врубился в 99% заложеных концепций, и написал кучку немерле-кода. PI>>и мое мнение (если им кто-то интересуется) сейчас такое, что тот мизер, которого мне не хватает по сравнению с сишарпом,
M>Есть еще несколько вариантов.
M>Кого-то просто не устраивает .NET
о таких речь не идёт
M>Кого-то устраивает .NET, но не устраивает сырость компилятора,
в компиляторе 2 стороны: генерация exe (msil) и его внешний интерфейс
первое уже стабильно
только на 2 проекте на немерле я столкнулся с багом (некомпиляция корректного сорца), в довольно специфичной ситуации
в дотнете тоже есть баги, ну и что все ж его юзают, хотя мелкософт и не спешит эти баги исправлять
а чтобы "вылизать" компилятор полностью, это извини меня, сначала должно появиться много программеров на немерле
яйца-курица, кто будет первым?
M> отсутствие ИДЕ,
я уже запрограммил 1 проект на этой "несуществующей" IDE
эту ИДЕ я же, в числе других героев нашего времени, докручиваю функционально
"вылизывать" ИДЕ-поддержку ещё долго надо будет (в условиях несуществования комьюнити)
причем я дотошно вычищать баги в ней не собираюсь — что-то будет не хватать — прикручу, что-то будет мешать — поправлю
прикручу то, что мне надо (рефакторинг) — объявлю на тестинг, буду по ходу править баги, о чем народ попросит (народа пока нет)
M> опасения относительно обратной совместимости этц,
если ты о дотнетовском коде, который уже написан — все пучком
если на что-то наткнешься — включишь в солюшен сишарповский гейтвей
M> но сам язык люди могут считать весьма неплохим. Однако бросать все и переходить на него они пока не собираются (к этой категории отношусь собственно я).
что ж, поздравляю, ты в "толпе"
в принципе, и без толпы мы разберёмся
а что, приятно, когда говорю "мы", подразумеваю конкретных людей...
M>У кого-то довольно большой объем кода на других языках,
мы обсуждаем дотнет платформу — и остаемся в рамках нее — здесь языки совместимы
M> и устраивать зверинен из языков на проекте им не хочется.
сишарп-немерле это не зверинец, это два брата — старший и младший (немерле старший)
вместе живут вполне нормально (см. проект интеграции, например)
M> И таких людей я вполне понимаю.
я тоже понимаю — закостенелость мышления это порок, но повсеместность распространения выносит его за рамки обсуждений
M>Кого-то просто напрягает шум создаваемый рекламой Немерле.
ты думаешь, зачем я, Влад и другие здесь распинаемся?
потому что если бы нас, рульных чуваков, было бы больше, мы бы уже делали то, чего на старых мейнстримовых языках сделать невозможно, а все необходимое для работы уже было бы реализовано (потому что ничего военного в этом нет, только ресурсов мало)
M>Кто-то боится, что на большом проекте могут возникнуть неожиданный грабли, связанные с Немерле.
чем боятся и молчать, спросите нас какие грабли могут возникнуть, и мы честно ответим, в меру опыта нашего общения с Немерле
M> Это дополнительный риск в проекте, а от них стараются избавляться.
мне не интересны подходы корпораций, хотя я в курсе этих подходов
хорошо было раньше, когда были люди, знающие вообще все в программировании
хорошо, когда один в поле — воин...
но все равно, на уровне софт-компаний, кто поймет, что немерле даст конкурентные преимущества, тот и сядет на немерле
пока я списываю все на инерцию мышления, но скоро появится дополнительное объяснение — тупизна манагеров и страх нового (что означает, что никто не разобирается в ситуации)
M>Кто-то ... M>Я думаю пунктов можно написать множество.
и выделить из них 2 основных — инерция мышления и страх нового
M>Неприятие Немерле РСДН-ом(по крайней мере людей, связанных с .NET) ИМХО означает больше неприятие его в таком виде как он есть сейчас, а не неприятие языка вообще.
маловато что-то вперёдсмотрящих на рсдн-е
консерваторы какие-то пособирались...
в общем, не флейма ради, спасибо, что мыслишь и говоришь на эту тему, но выводы не совсем правильные
придётся проявить некоторую индивидуальность и сообразительность
