LINUX.ORG.RU

C# и Linux.


0

0

Как вы думаете, каковы перспективы языка C# на платформе Linux, Mono в сравнении с теми же Java и C++. Я начинающий программист, но образование в области экономики, потому больше интересует ООП, в перспективе - что-нибудь системное. Какое мнение вообще относительно этого языка, вне проблем с лицензией.

anonymous

IMXO никакие

anonymous
()

Язык перспективный, но его широкое распространение под линукс маловероятно.

gpg
()
Ответ на: комментарий от PETER

Но позиционируется как основной язык для платформы .Net Framework. Для этого мелкомягкие заявляют, что C# заменит C++ и значительно лучше сопровождают этот язык, чем C++ в своей Visual Studio. Слышал я, что один известный автор издания O'Reilly по C# восхищался C# и сказал, что лучше пойдет к стоматологу, чем будет писать на managed С++. А в сети выложили очередную версию mono.

anonymous
()
Ответ на: комментарий от anonymous

Что в ней такого плохого, в "ООП-ной параше"? Факториал на C# не рассчитаешь, но считается, что ООП программы в своей сфере надежнее. Ведь Python и Ruby тоже языки ООП, но в Linux признаются.

anonymous
()
Ответ на: комментарий от anonymous

Просто ООП - плохая модель. Ну не плохая, средненькая - без разницы. Плохо, когда из посредственности пытаются вылепить серебрянную пулю...

anonymous
()

ИМХО переспективы никакие... И вот почему - слишком много уже написано в линуксе на C/C++ да еще и Perl'е. Чтобы ввести новый язык, он должен предоставлять очевидные преимущества в работе. Например питон, сочитая мощь полного OOP, имея огромую библиотеку стандартного API и являясь кроссплатформенным стал популярен очень быстро (вы ведь не забыли, что питон еще достаточно молод ;)

А вот скажите мне какие плюсы дает C#? Че то не видно никаких, и сколько я не читал обзоры мелкомягких - так и не проникся им.

svyatogor ★★★★★
()
Ответ на: комментарий от svyatogor

Спасибо за разъяснения :-) Плюсы я вижу в самой платформе .Net Framework. ИМХО для мелкомягких вещь революционная, в плане общих библиотек классов для нескольких языков и управления памятью. К тому же мне C# показался проще C++, который мне вообще в варианте gcc и Visual C++ не дался. От Borland С++ Builder я получил значительно больше удовольствия. Но он очевидно менее гибок. Кстати, эта самая, не совсем любимая мной контора пророчат смерть C++ как "устаревшему бардачному языку" и платформе Java/Corba. Язык мне понравился. Но я хотел бы знать мнения и других людей.

anonymous
()
Ответ на: комментарий от anonymous

А какая модель наиболее перспективна, полезна и оплачиваема? Если только не драйвера писать. В прошлом я занимался математическим анализом результатов статистических условий. Софт нашел только под виндами, программы Statistica и Mathcad с внутренними языками. На мой взгляд, в плане математики ничего лучше не придумали.

anonymous
()
Ответ на: комментарий от anonymous

Не условий, а исследований :-)

anonymous
()
Ответ на: комментарий от svyatogor

А можно ли на Python написать Quake 2? По-моему, у этого языка довольно узкий груг задач, одной из основных является веб. C++ важен там, где нужны сложные вычисления. Наверное, теперь от языков требуются и другие вещи, например, продуктивность разработки. От C# я хотел бы иметь возможность писать под Linux, и под винды, но в Linux. Но не знаю еще, что собой представляет язык, чтобы сказать что-то определенно.

anonymous
()
Ответ на: комментарий от anonymous

Питон не столько для веб..это скорее "клей", т.е. хорош для задач не слишком больших, но зато за счёт высокоуровневости и богатой библиотеке всё предельно компактно и понятно, ну скорость конечно да..

А С# под линуксом имхо никому особо не нужен, ничего особо выдающегося в нём тут нет.. проблем больше (в перспективе). Что реальная кросс-платформеность (на уровне библиотек) будет у Mono, тоже очень сомнительно. Для этого есть java. Ну и "скриптовые" языки запросто работают под linux/win.

anonymous
()
Ответ на: комментарий от anonymous

Перспективных моделей - вагон. ООП - лишь одна, и козлы все те, кто делает из неё панацею... У функциональщиков есть свои методологии разработки, куда как более правильные, чем ООД, есть и всякие там агентные да аспектные подходы...

Вместо Statistica - однозначно http://www.r-project.org/

Вместо Mathcad - Octave и Maxima. Всё это гораздо лучше коммерческих аналогов. А, тут ещё Axiom теперь свободный...

anonymous
()
Ответ на: комментарий от anonymous

Отдельное спасибо за названные программы :-) Насчет новых языков и платформы Microsoft полностью согласен. Но будет ли востребовано функциональное программирование? Ведь програмирование должно обеспечить сносную жизнь самому программисту, участие в проектах и развертывание программ на площадке клиента, где могут быть различные платформы. Нашел список языков функциональной модели - Lisp и т. п. C++ позволяет использовать эту модель в полной мере? Где можно найти программы, написанные с использованием данной модели, чтобы представить примерный список выполянемых задач ?

anonymous
()
Ответ на: комментарий от anonymous

>>Но не знаю еще, что собой представляет язык
C# это блювота и этим все сказано. От C/C++ там только буква названии.

anonymous
()
Ответ на: комментарий от anonymous

э, парень, пока от тебя за версту маркетинговым бредом несет. Про любой язык в книжке а-ля программирование на русском матерном за 21 день пишут что он крут как бараньи яйца, вообще-то язык выбирают наиболее подходящим для решения конкретной задачи и делают это проектировщики, в твоем случае изучать язык тот который пользуется наибольшим спросом у работодателей.

C# - это мс-овская замена java. Пока под платформы кроме МС и API-то на чуть-чуть спортировано (да и сомневаюсь я что оно на всех платформах единообразным будет, скорее всего будет на МС завязано).

Если CBuilder показался легче gcc - неправильно парень мыслишь, сомневаюсь что из ООП в CBuilder-e ты кроме object->method что-нибудь использовал. Реально тебе сейчас нужен _как можно более строгий язык_, изучи хотя бы паскаль.

Если уж так нравится ООП - если хочешь то можешь использовать эту модель и в лиспе, (ну охренели уже, куда только это ООП не пихают), там тоже появилась объектная модель (ищи common lisp object system)

hooj ★★
()
Ответ на: комментарий от hooj

> э, парень, пока от тебя за версту маркетинговым бредом несет. Согласен. Но сюда я зашел для выяснения истины. > Про любой язык в книжке а-ля программирование на русском матерном за 21 день А вот тут были книги издательства O'Reilly, Sybex, M$ Press, не на русском, а на ругательном и немецком. Файлообменные сети и IRC рулят. > да и сомневаюсь я что оно на всех платформах единообразным будет, скорее всего будет на МС завязано И здесь я склонен согласиться, так как серьезно изучал маркетинг - если уж мелкомягкие все это затеяли, им нет особого смысла делать полноценные порты на другие ОС, ведь все это работает и на привязку программистов к M$. > Если CBuilder показался легче gcc - неправильно парень мыслишь, сомневаюсь что из ООП в CBuilder-e ты кроме object->method что-нибудь использовал. Частично это так. Я не привязан конкретно к ООП, я использую все, что мне доступно. Но и первое образование у меня не программиста. Паскаль изучать не хочу и не буду, два года его изучал в профильном классе и успешно писал приложения. gcc в процессе программирования просто не подошел под мои задачи, да и не было нормальной литературы. Если чего посоветуете - буду благодарен :-)

anonymous
()
Ответ на: комментарий от hooj

"Чужие доспехи либо широки, либо тесны, либо громоздки" (H.Макиавелли) Не поймите уж очень превратно. Просто я новичок в программировании, но уже специалист в области экономики. В связи с появлением платформы .Net и всеми прочими изменениями в мире программирования, мне толком не понятно, какой язык выбрать для задач, связанных с моей областью и на перспективу с другими. Pascal - не мое, есть более перспективные вещи, должны быть.

anonymous
()
Ответ на: комментарий от anonymous

Искать документ под названием "Why functional programming matters", а так же "Being popular" Пола Грэхема (http://www.paulgraham.com/). C++ - позволяет в кастрированной форме, смотреть Intelib и Boost-lambda.

anonymous
()
Ответ на: комментарий от hooj

Это кто ещё охренел? CLOS была, когда C++ и в проекте не было, и Smalltalk-а никто не видел.

anonymous
()
Ответ на: комментарий от anonymous

Нет ничего "перспективного". Нельзя изучать языки - это глупо и подло. Надо изучать программирование вообще - без привязки к языкам.

anonymous
()
Ответ на: комментарий от anonymous

ИМХО лучше это делать на практике. Да и годы не позволяют - диплом с отличием в лучшем экономическом ВУЗе страны сделает студента еще одним безработным. Так как я не 18-летний студент компьютерного ВУЗа, я не могу изучать Pascal для того, чтобы врубиться в основы программирования. Продукт компьютерных знаний должен подлежать продаже с целью обеспечения собственной самостоятельной жизни. В системное программирование я сразу лезть не собираюсь, не моя это сфера, я все-таки получил фундаментальное образование в области экономики и если и напишу программу, то, как минимум, сделаю это с относительно хорошим знанием бизнес-процесса и зачем это надо. Лучшим средством обучения считаю изучение языка параллельно со сдиранием и компиляцией готовых программ, в порядке эксперимента, через старое доброе подражание. Спасибо за все советы и заранее спасибо за возможные в будущем :-)

anonymous
()
Ответ на: комментарий от anonymous

А какова основная сфера применения функционального программирования? Вроде бы оно применяется, в основном, в сфере, где требуются сложные вычисления. Можно ли назвать эту модель универсальной и программировать графику, либо что-нибудь для сети? Можно ли написать программу с GUI, работающую с базами данных? Вроде бы во многих американских университетах преподают тот же Sheme, но программисты на русских форумах не в восторге от этого языка.

anonymous
()
Ответ на: комментарий от anonymous

По поводу программирования вообще. Приходилось быть знакомым со студентами-бухгалтерами. После окончания ВУЗа трудно сказать, что они владеют бухучетом. Все приходит на практике, понимание всех фундаментальных понятий, которые были для них в универе пустым звуком. Пока не почувствуешь цифр в бухучете, не поймешь смысла дебетового сальдо. Пока не начнешь писать программы - имхо не поймешь, что такое объект, с самым золотым Страуструпом.

anonymous
()
Ответ на: комментарий от anonymous

Ну это же очевидно. Создание программ:-).

А функциональные, OO-ные, логические или еще какие - это просто "метод" "разбиения" исходной задачи на более простые(или уже готовые) составляющие, и последующей сборки из полученых компонент готового решения. При OO подходе - это простые обьекты с состоянием, обменивающиеся сообщениями, при ф-ном - более простые функции, и т.д.

>Можно ли назвать эту модель универсальной и программировать графику, либо что-нибудь для сети

Вполне. При достаточном наборе примитивов "функции" ничем не хуже обьектов. А часто лучше.

>в ... университетах преподают ... Sheme, но программисты на русских форумах не в восторге от этого языка

Я тоже - Хаскель лучше, IMHO:-). Но я подозреваю, что ему(как впрочем и схеме со товарищи) просто _некому_ учить русских студентов. А переучиваться трудно.

Резюме(IMO): Если программирование - не твоя основная специальность учить нужно высокоуровневые декларативные языки(функциональные или нет - зависит от решаемых задач). В противном случае - нужно знать много разных языков. А начинать с империтивных языков - в любом случае вредно.

DonkeyHot ★★★★★
()
Ответ на: комментарий от anonymous

Графику? Смотри на Pan или Pacito или Fran. Морды? Смотри на WASH и Fudgets. Вообще в функциональщине абсолютно всё делается гораздо удобнее и приятнее, чем в императивщине. А на русских форумах - не программисты, а быдло, не слушай их.

anonymous
()
Ответ на: комментарий от DonkeyHot

Посмотрел Хаскель, выкачал большинство из названных сред разработки. Программы можно представлять в виде exe-файла? Какая среда будет получше? Есть ли доки на русском? Насчет сложности согласен - синтаксис вроде приятный.

anonymous
()
Ответ на: комментарий от anonymous

Для быстрой разработки и отладки - Hugs. Для компиляции быстрого бинарника - ghc.

На русском - документации вроде бы и нет, есть курсы лекций и некоторые переводы.

Советую смотреть сюда для начала: http://www.softcraft.ru/paradigm/dp/dpref.shtml

anonymous
()
Ответ на: комментарий от anonymous

Hugs - таки обязателен, GHCi его не заменяет.

По поводу того форума - дурачьё там собралось. Почти не видно грамотных людей, сплошные соплежуи. Никто даже не упомянул про такую ГЛАВНУЮ особенность Схемы (и её дедушки-Лиспа), как макры, и наличие полноценного языка в момент развёртки макросов (так что любителям темплейтов в C++ заткнуться и не жить). Так же никто ни разу про Форт не заикнулся. Давить это безмозглое безграмотное мудачьё, короче.

anonymous
()
Ответ на: комментарий от anonymous

Ты скажи, Уважаемый, после твоих ценных советов в стиле "как хороша была бы идеальная жизнь" этот чел. спрашивающий работу себе найдёт после ковыряния с хаскелями и пр.???

С императивщины, как завещал один изобретатель биореактора может и вредно для мозгов начинать, зато платят неплохо. А когда платят хорошо, то можно в своё удовольствие в свободное время уже и хаскели всякие изучать. А по-поводу императивщины/неимперативщины советую прикинуть -- сколько ПО на чём пишут, а уже потом давать охрененные советы..

>Давить это безмозглое безграмотное мудачьё

гы гы гы, сразу видно, долго думал, прежде чем писать. И что примечательно, товарищ даже тебя послушал, вроде. Наверно, проникся советами "гуру".

eRazor ★★★
()
Ответ на: комментарий от eRazor

>этот чел работу себе найдёт после ковыряния с хаскелями и пр.

Это зависит от его желаний. Ели хочется зарабатывать кодерством - _сегодня_ лучше учить Java/PHP/C*/... - популярные но относительно слабые языки. Ежели хочется ставить/разрабатывать/решать задачи - лучше это делать с более мощными средствами. Хаскель во многих случаях подойдет.

>С императивщины ... платят неплохо ... можно в своё удовольствие в свободное время уже и хаскели всякие изучать.

Оппонент забыл учесть, что кодирование в империтивных языках - достаточно тесный рынок. Так что платить там должны не очень хорошо. Да и времени на "своё удовольствие" останется не так много.

>советую прикинуть -- сколько ПО на чём пишут,

Ну, и посмотри на (мягко говоря)качество этого (грубо говоря)ПО :-) Аргумент про миллионы мух не работает.

DonkeyHot ★★★★★
()
Ответ на: комментарий от eRazor

Тот, кто реально много зарабатывает (или хотя бы хочет много зарабатывать) - сам решает, на чём ему писать. И когда он пишет на правильных, а не мудатских языках, он работает намного эффективнее, и, сталобыть, зарабатывает больше. Кому может быть интересна карьера кодера, который делает, что ему прикажут? Тем более, если человек - и так специалист в своей области, ему не надо работать подмастерьем, ему надо решать *свои*, *профессиональные* задачи.

anonymous
()
Ответ на: комментарий от DonkeyHot

>>этот чел работу себе найдёт после ковыряния с хаскелями и пр.

>Это зависит от его желаний. Ели хочется зарабатывать кодерством - _сегодня_ лучше учить Java/PHP/C*/...

Зависит не только от желаний, а ещё и от того, что рынок предлагает. А предлагает он, в основном, императивщиной зарабатывать. Не буду отрицать, имеются вакансии, к примеру, для ML, но их крa-aйне мало..

>популярные но относительно слабые языки.

Абсолютно необоснованное утверждение. Где мера силы/слабости языка?

>Ежели хочется ставить/разрабатывать/решать задачи - лучше это делать с более мощными средствами. Хаскель во многих случаях подойдет.

Чушь. Что в твоём понимании является ЗАДАЧЕЙ? Причём такой, что решется она именно с пом. функционального программирования и никак иначе?

Как показывает практика, ставят задачи и решают их несколько разные люди, выполняющие разные функции. А решатели ЗАДАЧ сейчас ненужны становятся, потому как после ухода из конторы подобного решателя, второго такого непонятно где искать надо будет. И все здравомыслящие люди понимают это и поэтому раработаны/разрабатываются методики написания сОфта в рамках которых все выполняют свои функции и никакие решатели с большой буквы там нах не сдались.

>Оппонент забыл учесть, что кодирование в империтивных языках - достаточно тесный рынок. Так что платить там должны не очень хорошо. Да и времени на "своё удовольствие" останется не так много.

Да ладно тебе, Уважаемый. На хлеб с маслом и икрой хватает, а также на всё, что потребоваться может для комфортного проживания..

>Ну, и посмотри на (мягко говоря)качество этого (грубо говоря)ПО :-) Аргумент про миллионы мух не работает.

Стало быть, те кто пишут на функциональных языках шедевры выдают? Ха ха ха ха ха...

eRazor ★★★
()
Ответ на: комментарий от anonymous

>Тот, кто реально много зарабатывает (или хотя бы хочет много зарабатывать) - сам решает, на чём ему писать. И когда он пишет на правильных, а не мудатских языках, он работает намного эффективнее, и, сталобыть, зарабатывает больше. Кому может быть интересна карьера кодера, который делает, что ему прикажут? Тем более, если человек - и так специалист в своей области, ему не надо работать подмастерьем, ему надо решать *свои*, *профессиональные* задачи.

Ты скажи, ты теоретик? Сам решать прораммер на чём писать может в крайне редких случаях, например, когда работает в шаражке в которой вообще до балды, напишет он что-то или нет. А во всех остальных местах, где распиздяйством социалистическим не пахнет, сначала деньги подсчитывают -- во что обойдётся написание программы и прикидывают как не пролететь с данным проектом, а наоборот заработать на нём. И прикидывают эти вещи уж никак не программеры, которые необходимыми знаниями и навыками для этого не обладают.

А бред про мастеров и подмастерьев придумали товарищи из ещё тех совковых НИИ и прочих подобных контор, которые своей копейкой никогда ни за что не отвечали.

Есть такая вещь как разделение труда. Профессиональная задача программиста это правильно и эффективно программы писать, а не решение задач вселенского масштаба.

eRazor ★★★
()
Ответ на: комментарий от eRazor

>Абсолютно необоснованное утверждение. Где мера силы/слабости языка?

Обоснованое, на самом деле. Мощность, как известно, пропорциональна работе и обратно пропорциональна времени ее выполнения. Пессимисты утверждают, что отказ от империтивности уменьшает время создания проги всего лишь в 4 раза(оптимисты говорят про 10). Некоторое кол-во проведеных опытов подтверждают это(может быть с точностью до положительного коэффициента < 1). Следовательно утверждение про мощность справедливо(я употребил "слабые" в смысле "маломощные" - в русском языке это допускается IMO).

>Чушь... Что ... является ЗАДАЧЕЙ ... что решется ... с пом. функционального программирования и никак иначе?

Я не говорил про "никак иначе". Все программистские задачи могут быть решены многими способыми. Просто некоторые способы проще/быстрее/эффективнее других.

>поэтому раработаны методики написания сОфта ...

Как кто-то писал "Это есть средство писать программы, а не написать их".

>На хлеб с маслом и икрой хватает...

Конечно. Но методы ориентируются на то, что исполнители часто заменяются. Посему нет смысла создавать им идеальные условия...

>Стало быть, те кто пишут на функциональных языках шедевры выдают

Ты сказал. То, что при _развитых_ империтивных методиках программы получаются "кривыми" свидетельсвует об недостатках этих методик. А про ф-ные шедевры - стоило бы сравнить качество программ среднего размера, написаные за одинаковое время 2мя группами программистов эквивалентной квалификации с использованием разных языков по одной постановке. Что-то похожее делается в рамках IFCP - но там очень жесткое время и ненормирована квалификация.

DonkeyHot ★★★★★
()
Ответ на: комментарий от DonkeyHot

>Обоснованое, на самом деле. Мощность, как известно, пропорциональна работе и обратно пропорциональна времени ее выполнения. Пессимисты утверждают, что отказ от империтивности уменьшает время создания проги всего лишь в 4 раза(оптимисты говорят про 10). Некоторое кол-во проведеных опытов подтверждают это(может быть с точностью до положительного коэффициента < 1).

Гм, с трудом верится. А где почитать можно -- чта за задачи в этих тестах решались, статистику там всякую? А то может это был отдельо взятый опыт проведённый на отдельно взятой группе? который показывает лишь, что данная конкретная группа для решения данной конкретной задачи эффективнее использовала функциональный подход?

>>На хлеб с маслом и икрой хватает...

>Конечно. Но методы ориентируются на то, что исполнители часто заменяются. Посему нет смысла создавать им идеальные условия...

Конечно, но не всё так мрачно в этом королевстве. Акулы капитализма не занимаются повальным питиём крови у несчастных программистов. Бывает, что создают весьма хорошие условия для работы.

>>Стало быть, те кто пишут на функциональных языках шедевры выдают

>Ты сказал. То, что при _развитых_ империтивных методиках программы получаются "кривыми" свидетельсвует об недостатках этих методик. А про ф-ные шедевры - стоило бы сравнить качество программ среднего размера, написаные за одинаковое время 2мя группами программистов эквивалентной квалификации с использованием разных языков по одной постановке. Что-то похожее делается в рамках IFCP - но там очень жесткое время и ненормирована квалификация.

Не верю! Звучит как панацея от всех проблем. Если это так, почему за 20-30 летние существование функционального подхода от императиного почти полностью не отказались повсеместно?

Где прочитать можно о сравнении качества? Или это только твоё мнение?

eRazor ★★★
()
Ответ на: комментарий от eRazor

>с трудом верится. А где почитать можно

Цифра 10 - по моему от Ericsson - они придумали "erlang"(он, впрочем, не очень функциональный, afaik), переучили программеров и говорили о таком приросте производительности. Еще где-то в инете есть статья про проводившийся US-овскими военными эксперименте по определению "лучшего языка для прототипирования". Там оценивавшие результат отказывались верить, что им представлена работающая программа на Haskell и говорили что-то типа "это слишком круто, чтобы быть приемлемо". Еще кто-то за пару месяцев в свободное от работы время соорудил полнофункциональный HTTP сервер...

Разумеется, такие "опыты" очень субьективны и зависимы от задачи. Они могут только показать, что разложение задачи на компоненты типа "функция" _может_ быть очень эффективным решением. Разумеется не всегда. К тому же это все было давно - империтивщики тоже на месте не стояли.

>Не верю! Звучит как панацея от всех проблем

И правильно. На последнем ICFP соревновании первые 2 места были за C++ :-) Человеческий фактор все еще гораздо больше этих 4-10 раз. Но большинство программ пишется все-таки не "гениями" - посему даже 2х-кратное преимущество должно быть привлекательным.

>почему за 20-30 летние существование функционального подхода от императиного почти полностью не отказались повсеместно

1. Слабость компютеров совмещенная с недостаточно проработаными методами оптимизации делала невозможным достаточную скорость выполнения ф-ных программ. Сегодня тот же Хаскель подбирается вплотную с Java с C++, Оcaml иногда обгоняет C, а программы и вовсе пишутся на интерпретирующих языках - этот фактор исчез.

2. Пойди скажи среднему Java/C*/... программисту о том, что писать нужно на языке не содержащем изменения значения переменных, методов указания порядка выполнения операторов, циклов - и посмотри, как он на тебя посмотрит:-). А деньги обычно вкладываются в массовые вещи. Инерция очень велика.

>о сравнении качества? Или это только твоё мнение?

Это даже не мнение - не на чем его основать. Хотелось бы провести сравнение Java vs Python vs C++ vs Ocaml vs Haskell ... Причем сегодня - а не 10 лет назад. Увы, готового такого я не видел.

DonkeyHot ★★★★★
()
Ответ на: комментарий от DonkeyHot

PS: почему за 20-30 летние существование

3. Я однажды видел, как в PL/SQL было написано руками(посредством циклов) декартово произведение 4х таблиц - при том, что sql сам это делает гораздо проще и эффективнее. Трудно заставить программиста думать "по другому". А тем более - "совсем по другому":-)

DonkeyHot ★★★★★
()
Ответ на: комментарий от DonkeyHot

>Цифра 10 - по моему от Ericsson - они придумали "erlang"(он, впрочем, не очень функциональный, afaik), переучили программеров и говорили о таком приросте производительности. Еще где-то в инете есть статья про проводившийся US-овскими военными эксперименте по определению "лучшего языка для прототипирования". Там оценивавшие результат отказывались верить, что им представлена работающая программа на Haskell и говорили что-то типа "это слишком круто, чтобы быть приемлемо". Еще кто-то за пару месяцев в свободное от работы время соорудил полнофункциональный HTTP сервер...

Ну это совсем другой разговор уже. Практически, ты смог сослаться только на результаты исследований некой фирмы и американских военных, которые непонятно где искать. Это не является результатом ислледований какого-то специального института занимающегося данной проблемой, а просто иследованиями непонятно кем и когда проводимые.

Подобной информации явно недостаточно для утверждений в духе "А лучше Б" и программисты на "А" пишут быстрее/эффективнее программистов на "Б". А следовательно, мне непонятно вообще на чём основывались советы изучать функциональные языки. Рынок -- мал, то что на них программы эффективнее -- далеко не факт (если факт, дайте мне статистику задокументированную). Для расшитрения кругозора если только..

>Разумеется, такие "опыты" очень субьективны и зависимы от задачи. Они могут только показать, что разложение задачи на компоненты типа "функция" _может_ быть очень эффективным решением. Разумеется не всегда. К тому же это все было давно - империтивщики тоже на месте не стояли.

Во во во. Только многие апологеты функциональщины или не знают об этом или не понимают этого.

>На последнем ICFP соревновании

А что это такое?

>Пойди скажи среднему Java/C*/... программисту о том, что писать нужно на языке не содержащем изменения значения переменных, методов указания порядка выполнения операторов, циклов - и посмотри, как он на тебя посмотрит:-)

;-) ну, не все мы такие тёмные люди.

eRazor ★★★
()
Ответ на: комментарий от eRazor

>Это не является результатом ислледований какого-то специального института

А ты знаешь институт, занимающийся этими проблемами? IMO при принятии решения лучше основываться на хоть какой-то информации. Есть у тебя результаты _исследований_, показывающие преимущества Явы(или что ты предпочитаешь) над (например)Хаскеллем? А какого же ты его используешь:-)?

>дайте мне статистику задокументированную

Не сочти оскорбление, но (-:иди ты на гугл!:-). Там ты найдешь результаты исследований, показывающие, что скорость написания программы в строках/время - (практически) не зависит от языка. Теперь осталось сравнить размеры эквивалентных программ на разных языках. Осталось найти эти программы. Или написать.

"Functional programmers argue that there are great material benefits - that a functional programmer is an order of magnitude more productive than his conventional counterpart, because functional programs are an order of magnitude shorter. Yet why should this be? The only faintly plausible reason one can suggest on the basis of these "advantages" is that conventional programs consist of 90% assignment statements, and in functional programs these can be omitted!"

>А что это такое ICFP

International Conference on Functional Programming. Они проводят такое-себе программистское соревнование: кто лучше решит задачу за 24 и за 72 часа.

DonkeyHot ★★★★★
()
Ответ на: комментарий от DonkeyHot

>А ты знаешь институт, занимающийся этими проблемами? IMO при принятии решения лучше основываться на хоть какой-то информации. Есть у тебя результаты _исследований_, показывающие преимущества Явы(или что ты предпочитаешь) над (например)Хаскеллем? А какого же ты его используешь:-)?

В данном споре про то, что учить стоит, я оцениваю положение дел с позиций количества имеющихся вакансий, которые можно без труда для разных стран найти. Если я хочу сказать, учите Java т.к. количество вакансий для неё на столько-то процентов больше чем на ML, то я нахожу нужную страницу в инете в доказательство если кто спорить начинает. Ты высказал мысль, что фукциональщина по эффективности обгоняет императивщину, в доказательство приведя непонятные исследования, и ты же говоришь а докажите мне обратное.. Не кажется несколько нелогичным данный подход? Мне кажется более логичным свои утверждения подкреплять _самим_ найденой статистикой, а не ответом в стиле -- "не веришь, докажи мне обратное". Если ты мне не веришь, что количество вакансий для программистов на императивных языках в разы больше чем для программистов на функциональных языках, я готов потратить время и пособирать для тебя статистику по Европе, к примеру, кто требуется. А, вот, сможешь ли ты какую статистику найти в доказательство своим словам? То, что "кажется, американские военные исследовали" и т.п. доказательством достаточным не является, я тебе об этом пытался намекнуть.

А посылать искать инфу для доказательства _своих же_ утверждений -- это кто угодно сможет, только несерьёзно это..

eRazor ★★★
()
Ответ на: комментарий от eRazor

>ответом в стиле -- "не веришь, докажи мне обратное"

Это не мои слова. Я, основываясь на доступной в инете информации, утверждаю, что фукциональщина эффективнее. К сожалению, не могу сейчас указать url-и - но я их не выдумал:-). И я не прошу тебя доказывать обратное - просто указываю, что я не видел таких результатов, и ты, вероятно, тоже - это просто неисследуемая область.

Я знаю про количество вакансий.

>То, что "кажется, американские военные исследовали" и т.п. доказательством достаточным не является

Каковы твои требования к "достаточному доказательству"? Нужна подтвержденная нотариусом подпись начальника какого-либо института? Я не могу этого предоставить. Есть только опубликованые в инете статьи, воспоминания, обзоры. Подтверждаемые только тем, что искажение информации не сулит никаких бонусов исказившему.

>А посылать искать инфу для доказательства _своих же_ утверждений -- это кто угодно сможет

Ну, извини. Лежал haskell.org - потому найти не получалось. Вот есть бородатое(10лет уже) воспоминание об военных: http://www.haskell.org/papers/NSWC/jfp.ps.

Про erlang: A reasonably complex problem involving distribution and fault tolerance will be roughly five times shorter in Erlang than in C.

Давай завтра сравним, cкажем, парсер HTML или XML валидатор - проблем найти реализации не будет. Только не понятно, как сравнивать обьемы - там кучи коментариев и функциональность может расходиться.

DonkeyHot ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.