Здравствуйте, Sinclair, Вы писали:
L>>Угу, в курсе, что под ОО обычно понимают совсем не то, что создатель термина. Однако, имелось в виду несколько другое. Пусть ООП — это инкапсуляция, наследование, полиморфизм. Однако даже в таком случае реализаций очень много. Вот модификаторы доступа — public, private, protected и каждый язык добавляет какие ему надо. Можем ли мы задавать свои? Например, поля, которые видны только из классов из пакета ааа с именем AAASome* Это что касается инкапсуляции. Подобные примеры можно придумать и для наследования и полиморфизма. (Вспомним хотя бы вечные споры о множественном наследовании). S>Не надо, ради байта, ничего придумывать. Private/protected/public/internal и т.д. это не совсем инкапсуляция. Это возможность предоставлять различные контракты различным потребителям. Классификация потребителей зависит от того, какие предикаты можно вычислить на паре типов. В С++ это ровно три предиката: тождественный TRUE, коммутативный Equals, и транзитивный InheritsFrom.
Неверно. Предикаты на чем?
Если на классах, то в C++
1) есть отдельные функции вне классов, как насчет них?
2) есть еще разные типы наследования, которые не вписываются в твою картину:
class A{
protected: int a;
public: A() : a(0) {}
};
class B : private A {
protected: int b;
public: B() : b(1) {}
};
class C : private B {
protected: int c;
public: C() : c(2)
{ a = 3; } // нельзя, т.к. наследование private, хотя предикат InheritsFrom(C,A) верен
};
int main()
{
C c;
return 0;
}
Особенно интересная картина возникает если еще примешать множественное и виртуальное наследование:
class A{
protected: int a;
public: A() : a(0) {}
};
class B1 : virtual private A {
};
class B2 : virtual public A {
};
class C : private B1, public B2 {
public: C()
{
// К одной и той же переменной доступ получить...
//B1::A::a = 3; // ...нельзя
B2::A::a = 2; // ...можно :)
}
};
int main()
{
C c;
return 0;
}
3) Есть using:
class A{
protected: int a;
public: A() : a(0) {}
};
class B : A {
public:
using A::a; // хоп, и protected член стал public :)
};
int main()
{
B b;
b.a = 1; // пожалуйста :)return 0;
}
4) Есть friends
class B;
class A{
friend class B;
private: int x;
public: A() : x(0) {}
};
class B {
A a;
public: B()
{ a.x = 2; } // пожалуйста :)
};
int main()
{
B b;
return 0;
}
S>Если преподавать это, то потом не возникнет дурацких вопросов типа "а protected — это инкапсуляция или нет?".
Много умных слов о предикатах и транзитивности, да не о сути, как мне кажется. Предикаты можно вычислять какие угодно — хоть то, что названия типов с одной буквы начинаются. Вопрос в другом — какой смысл несут эти предикаты. Поэтому вопросы "а protected — это инкапсуляция или нет?" совершенно справедливо возникают.
+ Ты забыл сказать что в C++ есть еще разные типы наследования (в т.ч. виртуальное), using, friends, которые не вписываются в эту стройную картину.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, lomeo, Вы писали:
L>>Что такое управляемые динамические возможности, из-за которых Хаскель и Окамл пролетают?
VD>Ищи в Википедии описание КОП.
Не нашёл. Как расшифровывается?
L>>Вопрос — почему Скала не столь мощна в этом вопросе как Немерле?
VD>Я этого не говорил. Скала имеет практически такую же поддержку ФПО.
4. Функции как первоклассные значения. (ФВП — это просто не верный термин, так как почти во всех современных ЯП есть ФВП). Тут конкурентами Немерле являются: C#, Руби, Питон, Смолток, O'Caml, Хаскель, Скала, Эрэнг. Причем только O'Caml и Хаскель столь же мощьны как Немерле. Отсальные языки как имеют те или иные проблемы в этом вопросе
L>>ООП слишком сложный вопрос. ОО — всего лишь слово. Разных ОО моделей — вагон и маленькая тележка. Лисп позволяет написать нужный тебе ОО,
VD>ООП в Лиспе это еще то извращение. Можно конечно его называть эдаким альтернативным взглядом, но практика показала, что такой взгляд не принимается большинстовом.
Я не говорю про CLOS. В лиспе можно написать ОО аля дотнет.
Что касается "ООП в Лиспе то ещё извращение" — то это твоё мнение, которое является несомненным фактом?
L>> а вот Немерле разрешит мне написать ОО на прототипах?
VD>Прототипы это не ООП. Обычно подобные языки называют "объектными". Собственно одно то, что подобный подход приводит к существенному замедлению кода лично для меня ставит на нем крест. К тому же у него опять же наблюдаются проблемы с зашитой.
Блаб мнение. Те кто использует прототипы думает иначе.
VD>В общем, лично мое мнение, что прототипный подход — это зло. По крайней мере для высокопроизводительного сложного софта разрабатываемого более чем одним человеком.
Мнения меня не интересуют. Мы обсуждаем наличие/отсутствие фич. Мнение о том, что что-то — зло всего лишь мнение блаб-программиста, который видит чёрное в том, что не использует. Ты вот писал на прототипном ОО?
L>>Насчёт наличия. Вот скажем в Хаскеле есть O'Haskell (ещё много чего на самом деле). Зачем же его выкидывать? Или вот CLOS гораздо мощнее дотнетовского ОО
VD>Это далего не так. Лично для меня очень важными факторами являются простота, понятность и удобство. Они в CLOS отсуствуют на проч.
Блаб-мнение. Те кто использует CLOS думают иначе.
VD>А дотнетный ООП как раз самая что ни на есть классика проверенная временем и кучей народа. Единственное что есть в CLOS — это мультиметоды (причем весьма странные). Ну, так они элементарно реализуются где угодно. Было бы желание. Лично мне пока что достаточно паттерн-матчинга (для организации множественной диспетчерезации).
"Пока что достаточно" — это уже прогресс. Уже меньше блаба.
VD>Мне кажется всем любителям экзотики надо понимать, что если экзотику не приняли на протяжении 30 и более лет, то проблема именно в ней, а не в окружающих. Это как в том анегдтоте когда на замечание, что какой-то идиот едет по встречной полосе товарищь отвечать, что их здесь тысячи...
Т.е. поскольку на Немерле пишет всего лишь Влад и ещё четыре человека значит, что проблема именно в Немерле?
В общем, это тоже сплошной блаб.
L>>А TemplateHaskell — это не сюда?
VD>TemplateHaskell именно сюда.
Тогда почему ты выкинул этот язык из списка?
VD>Меж тем реальный Хаскель его возможностями не обладает.
Этой фразу не понял. реальный Хаскель не обладает возможностями TH? Что такое "реальный Хаскель"?
VD>Мне кажется пора остановиться. А то следующим притянутым за уши извращением станет ImperativeHaskell. VD>Есть огромная разница между Немерлом и любыми эксперементальными языками. Немерле будет зарелизен в ближайшее время и на нем можно без какого либо дискомфорта писаль практически любые приложения. Хаскель же так и останется игрушкой цель которой продемонстрировать возможности и подходы. А его эксперементальные ответвления вообще даже бессмысленно обсуждать. Это чисто научные работы. Они стольк долеки от жизни, что о них и говорить не стоит.
Блаб-мнение. Те кто используют Хаскель думают иначе.
L>>Нет-нет, не факт, а твоё мнение.
VD>Если повторять себе это перед сном, то в это можно даже поверить. По как-что из фактов я от тебя ничего не услышал.
Аналогично. Одни блабы. "Этого в Немерле нет, потому что это зло"
L>>Например, у меня Немерле по этому же списку отсеился в нескольких пунктах. А если бы я ещё и свои добавил! VD>По каким? Давай обсудим.
Зачем тебе ещё и мои блаб-мнения? Ещё раз повторю — у меня есть своё мнение о Немерле, от этих пунктов оно у меня не изменится. У тебя твоё тоже. Тогда к чему всё это?
Слушай, а скажи мне, пожалуйста, по секрету. Ты что действительно считаешь, что нет такого пункта, по которому бы Немерле отсеился, а если есть (типа тех что я привёл) — то это зло?
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Это сводится к философскому спору хорошо ли когда все позволено.
Да нет же. Я же это писал не для философских вопросов. Влад написал список, в котором Немерле выиграл всех своих соперников. Я хотел подчеркнуть бесполезность подобных выкладок. Хотя бы в силу того, что можно составить список, в котором вылетать будет Немерле. И выглядеть он будет столь же разумно и пользы от него будет ровно столько же, то есть никакой.
L>>Это уже неважно. Не будем забывать о блаб программистах и будем оперировать понятиями не достоинство/недостаток (которое может быть сильно субъетивным), а фича. Важно, что эта черта у дотнета, а следовательно у Немерле отсутствует, я прав?
АХ>У Немерле есть такая мощная штука как макросы, поэтому утверждать что это невозможно не возмусь . АХ>Другое дело, что в целом это не совсем вписывается в его (Nemerle) идеологию.
Это между прочим очень важно. В лиспе ты сам можешь выдумать себе идеологию, а в Немерле привязан к одной. Споры что лучше one-way или выбор идут постоянно. У обоих путей есть как достоинства, так и недостатки. Так что, по одному пункту пролетит лисп, по другому Немерле.
АХ>Ну попробуй, но опять же как и в Лиспе в Немерле можно ОЧЕНЬ многое сделать с помощью макросов.
Я в этом списке смысла не вижу.
L>>Угу, например. Или аспекты (method combination). АХ>В смысле AOP (aspect-oriented programming)?
АХ>А пример можно как это делается на CLOS?
Да я в общем то имел в виду функции :after, :before, они ближе к контрактам, самих аспектов как таковых (на pointcut'ах) нет, но есть MOP (meta-object protocol), очень похожим образом решающий те же задачи.
АХ>>>А то что там можно на лету менять реализацию методов или добавлять их по мне так не является достоинством. L>>Опять таки это всего лишь мнение. Ты пробовал писать на селфе или чём то подобном? АХ>нет. Да, вроде как JavaScript а него похож в смысле прототипирования, я слышал.
Я хочу подчеркнуть, что если человек что то не использовал и говорит, что это нехорошо (ты более мягко выражаешься чем Влад, конечно ), то есть повод задуматься о том, а не блаб ли это мнение.
L>>А зачем? Это будет всего лишь моё мнение. Толку от этого списка ноль. АХ>Не 0. Мы тут собственно обсуждаем различные идеи в дизайне языков. Если есть хорошие идеи которые Влад не упомнянул, а ты можешь о них сказать, заодно аргументировав почему они на твой взгляд важны, то всем будет интересно.
Честно говоря, лень. Много есть хорошего, чего он не упомянул. Кое что я уже сказал. Не думая, сходу — REPL, констрейнты, тут недавно STM обсуждался — это на Немерле возможно?
А вообще советую взглянуть на Oz, в плане приёмственности идей очень симпатичный язычок. Взята небольшая база и на её основе разворачиваюся остальные концепции. Прикольно. И книжка с ним идёт замечательная.
L>> Если хочешь своё мнение я могу сказать и так. АХ>давай
Немерле — обычный язык со своими достоинствами и недостатками. По отдельным пунктам лучше других языков, по отдельным — хуже Мне он неинтересен, потому что изучая его я вряд ли что новое узнаю (пока по крайней мере ничего принципиально нового продекларировано не было), а использовать его мне нет смысла, потому что есть более подходящие языки для моих задач.
L>Немерле — обычный язык со своими достоинствами и недостатками. По отдельным пунктам лучше других языков, по отдельным — хуже Мне он неинтересен, потому что изучая его я вряд ли что новое узнаю (пока по крайней мере ничего принципиально нового продекларировано не было), а использовать его мне нет смысла, потому что есть более подходящие языки для моих задач.
Лично мне кажется, что достоинство Немерле(или, в моем случае, Скалы, которую я ковыряю дома) заключается в том, что есть возможность использовать различные подходы(императивный + функциональный) и "на халяву" заиметь кучу библиотек, которые уже написаны для .NET/Java. В то же время изучать какой-либо подход следует на языке, который на него ориентирован. Например, я учил(впрочем, ещё учу ) ФП по SICP и Схеме, которая заставляет делать все в функциональном стиле. В Хаскеле, наверное, хорошо учиться применять ленивость(и он в списке языков, которые я собираюсь поковырять), итд. Однако для разных задач — разные подходы, поэтому удобно в "настоящем" программировании использовать язык, который позволяет делать и так, и эдак. К сожалению, из языков, которые декларируют такой подход, я знаю только Скалу (ну и еще читал доку и образцы кода Немерла, однако, поскольку даже его компилятора нет, не могу сказать, что я его "знаю")..
Здравствуйте, Gajdalager, Вы писали:
G> Например, я учил(впрочем, ещё учу ) ФП по SICP и Схеме, которая заставляет делать все в функциональном стиле.
Схема не засатваляет
Там есть присваивание, можно соорудить for при желании и прочая, прочая, прочая.
G>Однако для разных задач — разные подходы, поэтому удобно в "настоящем" программировании использовать язык, который позволяет делать и так, и эдак. К сожалению, из языков, которые декларируют такой подход, я знаю только Скалу (ну и еще читал доку и образцы кода Немерла, однако, поскольку даже его компилятора нет, не могу сказать, что я его "знаю")..
Здравствуйте, Gajdalager, Вы писали:
G>Лично мне кажется, что достоинство Немерле(или, в моем случае, Скалы, которую я ковыряю дома) заключается в том, что есть возможность использовать различные подходы(императивный + функциональный) и "на халяву" заиметь кучу библиотек, которые уже написаны для .NET/Java. В то же время изучать какой-либо подход следует на языке, который на него ориентирован. Например, я учил(впрочем, ещё учу ) ФП по SICP и Схеме, которая заставляет делать все в функциональном стиле. В Хаскеле, наверное, хорошо учиться применять ленивость(и он в списке языков, которые я собираюсь поковырять), итд. Однако для разных задач — разные подходы, поэтому удобно в "настоящем" программировании использовать язык, который позволяет делать и так, и эдак. К сожалению, из языков, которые декларируют такой подход, я знаю только Скалу (ну и еще читал доку и образцы кода Немерла, однако, поскольку даже его компилятора нет, не могу сказать, что я его "знаю")..
Вот я Скалу тоже ковыряю.. Верней, уже вроде расковырял. Не скажу, чтобы я её по работе использовал. Хотелось бы, но этот язык не подходит для моей работы Это намёк.
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>Это сводится к философскому спору хорошо ли когда все позволено.
L> Да нет же. Я же это писал не для философских вопросов. Влад написал список, в котором Немерле выиграл всех своих соперников. Я хотел подчеркнуть бесполезность подобных выкладок. Хотя бы в силу того, что можно составить список, в котором вылетать будет Немерле. И выглядеть он будет столь же разумно и пользы от него будет ровно столько же, то есть никакой.
Еще раз — макросы Немерле сравнимы по гибкости с макросами Лиспа.
L>>>Это уже неважно. Не будем забывать о блаб программистах и будем оперировать понятиями не достоинство/недостаток (которое может быть сильно субъетивным), а фича. Важно, что эта черта у дотнета, а следовательно у Немерле отсутствует, я прав?
АХ>>У Немерле есть такая мощная штука как макросы, поэтому утверждать что это невозможно не возмусь . АХ>>Другое дело, что в целом это не совсем вписывается в его (Nemerle) идеологию.
L>Это между прочим очень важно. L>В лиспе ты сам можешь выдумать себе идеологию,
нет, в Лиспе ты привязан к S-выражениям и префиксной записи.
В нем все выглядит одинаково "(a (b c))".
L> а в Немерле привязан к одной.
Мне кажется она достаточно гибкая. А на макросах с произвольным синтаксисом в принципе можно такого наворотить, что волосы дыбом встанут, только не стоит этого делать .
L> Споры что лучше one-way или выбор идут постоянно. У обоих путей есть как достоинства, так и недостатки. Так что, по одному пункту пролетит лисп, по другому Немерле.
L>>>Угу, например. Или аспекты (method combination). АХ>>В смысле AOP (aspect-oriented programming)?
АХ>>А пример можно как это делается на CLOS?
L>Да я в общем то имел в виду функции :after, :before, они ближе к контрактам, самих аспектов как таковых (на pointcut'ах) нет, но есть MOP (meta-object protocol), очень похожим образом решающий те же задачи.
На Немерле это тоже сделать не вопрос.
АХ>>>>А то что там можно на лету менять реализацию методов или добавлять их по мне так не является достоинством. L>>>Опять таки это всего лишь мнение. Ты пробовал писать на селфе или чём то подобном? АХ>>нет. Да, вроде как JavaScript а него похож в смысле прототипирования, я слышал.
L>Я хочу подчеркнуть, что если человек что то не использовал и говорит, что это нехорошо (ты более мягко выражаешься чем Влад, конечно ), то есть повод задуматься о том, а не блаб ли это мнение.
Динамические языки я использовал (MATLAB, в частности, довольно много) — не понравилось.
L>>>А зачем? Это будет всего лишь моё мнение. Толку от этого списка ноль. АХ>>Не 0. Мы тут собственно обсуждаем различные идеи в дизайне языков. Если есть хорошие идеи которые Влад не упомнянул, а ты можешь о них сказать, заодно аргументировав почему они на твой взгляд важны, то всем будет интересно.
L>Честно говоря, лень. Много есть хорошего, чего он не упомянул. Кое что я уже сказал. Не думая, сходу — REPL, Nemerlish, хотя у него есть некоторые ограничения.
L> констрейнты,
типа Design by Contract или Constraints on type variables ?
L> тут недавно STM обсуждался — это на Немерле возможно? Ну это даже в C# возможно.
I'll take a look at writing some Nemerle macros to make the syntax nice.
L>>> Если хочешь своё мнение я могу сказать и так. АХ>>давай
L>Немерле — обычный язык со своими достоинствами и недостатками.
Ну мне он показался гораздо мощнее большинства языков. Дальше пожалуй только Lisp.
Но сделать такие же проверки типов как в Немерле на Лиспе я боюсь весьма нетривиально.
L> По отдельным пунктам лучше других языков, по отдельным — хуже L>Мне он неинтересен, потому что изучая его я вряд ли что новое узнаю (пока по крайней мере ничего принципиально нового продекларировано не было)
Немерле — это скорее эволюция, чем революция. Но он очень изящным образом включил в себя очень многие известные ранее идеи.
L>, а использовать его мне нет смысла, потому что есть более подходящие языки для моих задач.
Кому-то и C достаточно
Здравствуйте, Gajdalager, Вы писали:
G>Однако для разных задач — разные подходы, поэтому удобно в "настоящем" программировании использовать язык, который позволяет делать и так, и эдак. К сожалению, из языков, которые декларируют такой подход, я знаю только Скалу (ну и еще читал доку и образцы кода Немерла, однако, поскольку даже его компилятора нет, не могу сказать, что я его "знаю")..
lisp (и схема), Ocaml, Dylan, кроме того в питоне с руби тоже вполне удобно программировать в функциональном стиле.
VD>>Ищи в Википедии описание КОП.
L>Не нашёл. Как расшифровывается?
Компонентно-Ориентированное Программирование
кстати, как ФВП расшифровывается?
VD>>Мне кажется всем любителям экзотики надо понимать, что если экзотику не приняли на протяжении 30 и более лет, то проблема именно в ней, а не в окружающих. Это как в том анегдтоте когда на замечание, что какой-то идиот едет по встречной полосе товарищь отвечать, что их здесь тысячи...
L>Т.е. поскольку на Немерле пишет всего лишь Влад и ещё четыре человека значит, что проблема именно в Немерле? L>В общем, это тоже сплошной блаб.
немерле очень молод, и с этим связана его непопулярность
неприятие немерле рсдн-ом пугает
одно из двух — либо тут собрались "маргиналы" (фанатики "маргинальных" языков), решающие весьма специфичные задачи,
либо немерле обладает каким-либо концептуальным изъяном.
последнее я не списываю со счетов, хотя врубился в 99% заложеных концепций, и написал кучку немерле-кода.
и мое мнение (если им кто-то интересуется) сейчас такое, что тот мизер, которого мне не хватает по сравнению с сишарпом,
я допишу сам... а так — все что я раньше делал в сишарпе, теперь делаю в немерле, чему и рад
ведь, можно не только это, а гораздо больше
а если толпа идёт куда-то не туда, то что ж придётся проявить некоторую индивидуальность и сообразительность
если бы я не считал, что самому (самим) прикрутить к немерле не получится то, что мне нужно, я бы остался с толпой, и ждал бы, пока появится сотня-тысяча программеров на немерле...
что ж, если мы останемся "четырьма людьми, программящим на немерле", то и хорошо — это значит лишь, что мы получаем дополнительные преимущества в конкуренции с "толпой"
L>Слушай, а скажи мне, пожалуйста, по секрету. Ты что действительно считаешь, что нет такого пункта, по которому бы Немерле отсеился, а если есть (типа тех что я привёл) — то это зло?
тут проскочил термин "настоящее"-программирование
это не "ковыряться", не "изучать", не "лабать дома"
это когда есть реальные задачи, которые нужно реализовать, обеспечив взаимодейтсвие с десятком технологий
и неважно чего именно не хватает для фортрана (к примеру) — гуи, xml-либы, tcp-классов, тест-фреймворка
если не хватает хотя бы одного пункта, то можно фортран вычеркивать из списка
это имелось в виду
Здравствуйте, Mirrorer, Вы писали:
M>Здравствуйте, Gajdalager, Вы писали:
G>> Например, я учил(впрочем, ещё учу ) ФП по SICP и Схеме, которая заставляет делать все в функциональном стиле. M>Схема не засатваляет M>Там есть присваивание, можно соорудить for при желании и прочая, прочая, прочая.
Правильно.. Однако согласись, что написать for на С(и наследниках его синтаксиса, есно — ++, Java, # и прочая) или, к примеру, Paskal, намного проще и естественней, чем на Схеме.. Просто потому что for есть конструкция императивного стиля, а Схема заточена под функциональный, а использование императивного — как довесок. С другой стороны, допустим, на Жабе писать, используя ФВП — это Жава — императивный язык(конечно, объектно-ориентированный, но это другая ось координат). Это лично мои впечатления, которые базируются на том, что я знаю и вполне вероятно, что ложные.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Gajdalager, Вы писали:
G>>Однако для разных задач — разные подходы, поэтому удобно в "настоящем" программировании использовать язык, который позволяет делать и так, и эдак. К сожалению, из языков, которые декларируют такой подход, я знаю только Скалу (ну и еще читал доку и образцы кода Немерла, однако, поскольку даже его компилятора нет, не могу сказать, что я его "знаю")..
FR>lisp (и схема), Ocaml, Dylan, кроме того в питоне с руби тоже вполне удобно программировать в функциональном стиле.
Не, ну я знаю, что таковые существуют.. Я имел в виду, на них не программировал, посему не могу о них рассуждать... Правда питоновские __что-то__, мягко говоря, отпугивают.. В перле тоже прикрутили ООП опосля, и оно там совсем некрасиво выглядит.. Раздражает, допустим, необходимость в методе fetch-а ссылки на себя как параметра
Здравствуйте, PhantomIvan, Вы писали:
G>> (ну и еще читал доку и образцы кода Немерла, однако, поскольку даже его компилятора нет PI>а что тебе мешает его заиметь?
Не знаю .Net'а, так придеться учить и его, и язык одновременно.. Скала, походу, довольно похожа, а либы можно пользовать Жавишные, которые лучше знаю..
PI>немерле очень молод, и с этим связана его непопулярность PI>неприятие немерле рсдн-ом пугает PI>одно из двух — либо тут собрались "маргиналы" (фанатики "маргинальных" языков), решающие весьма специфичные задачи, PI>либо немерле обладает каким-либо концептуальным изъяном. PI>последнее я не списываю со счетов, хотя врубился в 99% заложеных концепций, и написал кучку немерле-кода. PI>и мое мнение (если им кто-то интересуется) сейчас такое, что тот мизер, которого мне не хватает по сравнению с сишарпом,
Есть еще несколько вариантов.
Кого-то просто не устраивает .NET
Кого-то устраивает .NET, но не устраивает сырость компилятора, отсутствие ИДЕ, опасения относительно обратной совместимости этц, но сам язык люди могут считать весьма неплохим. Однако бросать все и переходить на него они пока не собираются (к этой категории отношусь собственно я).
У кого-то довольно большой объем кода на других языках, и устраивать зверинен из языков на проекте им не хочется. И таких людей я вполне понимаю.
Кого-то просто напрягает шум создаваемый рекламой Немерле.
Кто-то боится, что на большом проекте могут возникнуть неожиданный грабли, связанные с Немерле. Это дополнительный риск в проекте, а от них стараются избавляться.
Кто-то ...
Я думаю пунктов можно написать множество.
Неприятие Немерле РСДН-ом(по крайней мере людей, связанных с .NET) ИМХО означает больше неприятие его в таком виде как он есть сейчас, а не неприятие языка вообще.
Такие дела
Есть два цвета, черный и белый
Но есть оттенки, которых больше
Мы, дети проходных дворов
Найдем сами свой цвет
(с) Виктор Цой
PI>немерле очень молод, и с этим связана его непопулярность PI>неприятие немерле рсдн-ом пугает PI>одно из двух — либо тут собрались "маргиналы" (фанатики "маргинальных" языков), решающие весьма специфичные задачи, PI>либо немерле обладает каким-либо концептуальным изъяном.
Есть такой изъян, но вполне исправимый, должна выйти релизная стабильная версия, до этого годится только для ковыряния.
Ну и кроме того думаю большинству немерле не так и нужен, одним по причине что есть другие инструменты не хуже, другим просто лень даже посмотреть.
Ну и конечно агрессивная реклама как я уже говорил во многом оталкивает, я вот вчера scala скачал, будет свободное время лучше его поковыряю
PI>а если толпа идёт куда-то не туда, то что ж придётся проявить некоторую индивидуальность и сообразительность
А зачем тебе толпа?
PI>тут проскочил термин "настоящее"-программирование PI>это не "ковыряться", не "изучать", не "лабать дома" PI>это когда есть реальные задачи, которые нужно реализовать, обеспечив взаимодейтсвие с десятком технологий
Пока для "настоящего" программирования немерле непригоден, выйдет релиз, будут хоть какие-то гарантии что проект не забросят тогда да. Сейчас похоже та же scala в этом отношении в более выгодной позиции.
PI>и неважно чего именно не хватает для фортрана (к примеру) — гуи, xml-либы, tcp-классов, тест-фреймворка PI>если не хватает хотя бы одного пункта, то можно фортран вычеркивать из списка
Из какого списка? Нет никакого такого Списка пригодного для всех и всего. У каждого разработчика, проекта свои списки и часто с очень разными критериями.
Здравствуйте, Gajdalager, Вы писали:
M>>Там есть присваивание, можно соорудить for при желании и прочая, прочая, прочая.
G>Правильно.. Однако согласись, что написать for на С(и наследниках его синтаксиса, есно — ++, Java, # и прочая) или, к примеру, Paskal, намного проще и естественней, чем на Схеме..
Писать в каком стиле ? С для ООП подходит слабо. Остальные хороши для ООП но слабо подходят для FP. Для некоторых задач вообще лучший выбор это Prolog. Это еще одна точка зрения на задачу.
На функциональных языках сложно писать, потому, что смотришь на решение задачи через призму старых привычек, пытаешься сделать так, как ты бы сделал в знакомых тебе языках. Но соль в том, что нужно делать по другому. Нужно пытаться мыслить в категориях FP. Поначалу это сложно. Как допустим научиться ходить. Я тоже сейчас изучаю FP, и не могу сказать что для меня это просто. Но понимание растет, и теперь для некоторых задач я могу искать решение в двух плоскостях — OOP & FP. В одни случаях лучше одно, в других — другое.
И чем больше опыта, тем проще понять, какой подход в данном случае лучше.
Здравствуйте, Gajdalager, Вы писали:
G>Правильно.. Однако согласись, что написать for на С(и наследниках его синтаксиса, есно — ++, Java, # и прочая) или, к примеру, Paskal, намного проще и естественней, чем на Схеме.. Просто потому что for есть конструкция императивного стиля, а Схема заточена под функциональный, а использование императивного — как довесок. С другой стороны, допустим, на Жабе писать, используя ФВП — это Жава — императивный язык(конечно, объектно-ориентированный, но это другая ось координат). Это лично мои впечатления, которые базируются на том, что я знаю и вполне вероятно, что ложные.
Не путай императивность и синтаксис, схема вполне императивный язык, просто с синтаксисом у него туговато Можешь посмотреть еще на язык rebol (www.rebol.com) он насквозь императивен, а синтаксически чуть украшенный лисп
Кстати for в лиспе — схеме вполне нормально смотрится:
если был, поделись впечатлениями 
возникает если еще примешать множественное и виртуальное наследование:
Жава — императивный язык(конечно, объектно-ориентированный, но это другая ось координат). Это лично мои впечатления, которые базируются на том, что я знаю и вполне вероятно, что ложные.
