Будет ли существовать функциональный язык, который сделает для сообщества Java то же, что F# для сообщества .NET?

F# также не является строго функциональным - вы можете программировать с использованием OO / процедурного, если хотите :-)

Scala: функционал :: C++: объектно-ориентированный

Поздравляю с получением значка "Народник"

Хотя нет никаких аргументов в пользу того, что ML / OCaml намного лаконичнее и функциональнее, чем Scala, трудно подтвердить все утверждения в (несколько устаревшем) сообщении на форуме. Однако я согласен с тем, что Scala не подходит для этой аналогии. F# - это в основном OCaml для среды CLR.

@ Даниэль: Я должен полностью согласиться. Есть несколько сценариев, в которых F# / OCaml предлагает это преимущество, но для большинства повседневных программ (т.е. для большинства людей) это утверждение просто нереалистично.

Автор связанного поста (Джон Харроп) обычно троллит usenet и другие форумы, чтобы расширить свой консалтинговый бизнес. Прислушайтесь к его совету с недоверием - он пытается вам что-то продать.

Этот пост на самом деле не дает никаких советов - просто несколько избранных примеров, сравнивающих OCaml и Scala. Независимо от того, кто является автором, примеры действительны и иллюстративны, если только он не выдвигает соломенный аргумент, приводя плохие примеры на Scala.

Натан, вы говорите, что мне нельзя доверять, потому что мои деньги буквально на OCaml и F#, а не на Scala. Для меня это не имеет смысла, но я полагаю, вы ожидаете, что я буду ценить ваше мнение как студента, который не участвовал ни в одном из этих языковых сообществ?

Я не являюсь большим поклонником Джона, но как программист на Haskell на полную ставку (который переключился с Java на Ruby по своему выбору), я согласен с критикой, которую он высказывает в этом сообщении Usenet, и типом функций, которые он описывает - это то, на что я постоянно полагаюсь в повседневном программировании.

@Curt: Итак, Вы, программист на Haskell, которому плевать? ;-) steve-yegge.blogspot.com/2010/12/…

Не отвечает на вопрос. Даже если F# останется нерелевантным, вопрос может заключаться в эквивалентном нерелевантном языке FP для JVM.

@Jon Harrop: у нас был этот разговор раньше ;-p Но да, безусловно: по большей части я полностью ожидаю, что люди останутся с C#. Есть ниша, в которой может быть желателен F#, но я лично не представляю себе масштабной миграции. Хотите ответить чем-то более конкретным, чем просто "-1"?

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

Возникает вопрос: «Какие языки функционального программирования доступны или находятся в разработке для JVM?». Ваш ответ был аргументом F# против C#. Вы отвечаете не на тот вопрос.

Нет, вопрос был в том, «... что делает для сообщества Java то же, что F# делает для сообщества .NET». - мой ответ просто пытается взглянуть на это с точки зрения перспективы - в противном случае вопрос не имеет смысла.

@Marc: «Постарайтесь ответить чем-то более конкретным, чем просто -1». Несомненно, теперь у миллионов разработчиков есть F# в VS2010, и он имеет явные преимущества, такие как сопоставление с образцом по сравнению с типами вариантов для управления деревьями, вывод типов, обеспечивающий продуктивность динамического языка со скоростью C#, MailboxProcessor, что упрощает параллельное программирование и Поддержка асинхронного ввода-вывода для беспрепятственной обработки десятков тысяч одновременных подключений. Они не собираются годами ждать дооснащения аналогичных функций на C#, если они смогут легко решать свои проблемы уже сегодня, используя F#.

@Jon: с нулевого дня у нас был полностью асинхронный ввод-вывод в .NET. Это может показаться неприятным, но любой, кто не может «разобраться» с исходным API наверное, основанным на обратных вызовах, не должен пытаться написать асинхронный код в любом случае: делать его легче печатать (через F# или материал C# 5) на самом деле не так. устраните любые тонкие сложности асинхронного кода. Кроме того, хотя я понимаю, что вы сторонник (достаточно справедливо), иметь его под рукой - это не то же самое, что они его используют. Фактически, буквально на этой неделе я был ...

@Jon пишет некоторый асинхронный код (конвейерный, мультиплексированный, IOCP-ориентированный, в очереди, обратные вызовы и т. д.; Все эти приятные вещи). Именно в нулевые пути я обнаружил, что не хватает обычного .NET. Так получилось, что я использовал C#, но подойдет любой язык .NET.

@Jon и другие "преимущества" - опять же, это отличный ответ на проблему, которой у меня, нет, и у большинства других разработчиков, которых я знаю, нет. Я полностью согласен с тем, что в определенной нише (или нишах) это очень полезно; но большинству людей это не нужно, так зачем им «решать» эту проблему (которой у них нет), переходя на F#?

@Marc: Я не согласен с тем, что программисты должны иметь возможность писать асинхронный код низкого уровня вручную, прежде чем использовать альтернативы высокого уровня. Не больше, чем они должны быть в состоянии выполнить TCO на ассемблере вручную или реализовать барьер записи перед использованием GC. Если этот стиль async настолько плох, почему F# взял его из OCaml и почему C# теперь берет его из F#?

@Jon, и все же у нас все в порядке ... И сосредоточение внимания на async, вероятно, здесь в любом случае не лучший аргумент, а именно потому что асинхронного CTP C# - т.е. если это идет (доступно сейчас с производственной лицензией) на C#, зачем мне нужно учитывать f # для async?

@Marc: "но мы все в порядке". Люди говорят, что каждый раз языки программирования развиваются.

@Marc: "зачем мне рассматривать f # для async?" Зачем мне нужно быть впереди всех?

@Jon - это просто удобный синтаксис ... и в некотором смысле меньше, а не аналогичные вещи, такие как "блоки итератора"; еще раз хочу сказать: это не проблема, которая вызывает ежедневную боль, даже при написании кода с высокой степенью асинхронности. Это определенно приятно, и я приветствую это (я уже разработал некоторые асинхронные библиотеки в стиле C# 5 и т. д.). Но: я также написал точно такой же код без для асинхронного CTP. Конверсия была абсолютно минимальной. Сила аргумента async / F# чрезвычайно непропорциональна реальному повседневному асинхронному кодированию, которое живо и хорошо без F# или C# 5.

@Marc: «который жив и здоров без F# или C# 5». Конечно, вы также можете выполнять асинхронность в C++, Fortran или ассемблере. Если это слишком далеко, посмотрите, как разработчики C# обращались с универсальными шаблонами .NET, когда они приземлялись (при условии, что вы используете универсальные шаблоны): blogs.msdn.com/b/dsyme/archive/2011/03/15/…

@Jon - вы продолжаете кататься по сути: факт в том, что с асинхронным CTP или без него, для подавляющего большинства разработчиков C#, пишущих асинхронный код, не является существенной проблемой, которую нужно исправить с помощью языковой смены. Конечно, сделать его красивее с помощью языковой поддержки - это Добро пожаловать.

@Marc: Вам не нужно менять языки на .NET. Просто выберите подходящий для задачи.

@Jon Я обычно так и делаю :) однако я сильно подозреваю, что мы можем принять разные решения по этому (в конечном итоге субъективному) вопросу дизайна.

@RoelSpilker: Это не я. Зашел на сайт, скачать спец не удалось. Быть потомком Fortran не подходит для функционального языка? Я ошибаюсь?

Хотя на первый взгляд он выглядит как новая версия Fortran, на него также повлияли Scala и Haskell. И способ, которым разработан язык, поддерживает как объекты, так и черты характера. Смотрите также FAQ: research.sun.com/projects/plrg/faq/index.html#five

@RoelSpiker: +1 ... Звучит неплохо, но мне интересно, какова общая динамика, стоящая за этим. Их «дорожная карта» пока никуда не ведет. : s

интересно, но наверняка провалится! Я все же проголосую!

Sun сделала проект с открытым исходным кодом сразу после того, как они не получили продление от DARPA, даже несмотря на то, что у них был работающий прототип / доказательство концепции. С тех пор многие люди участвовали и помогали улучшать Fortress. Но я не мог найти, кто руководит проектом.

+1, потому что это правильно, и это ставит вас на 10, что дает Джопу его значок популистов

Я бы хотел, чтобы синтаксис Lisp был более приятным ;-)

То же самое. О, если бы вам понравилось видеть море паренс и постоянный мысленный синтаксический анализ снизу вверх, который вам приходится выполнять из-за непрерывной записи префиксов ... Я бы использовал Лисп. Я думаю, что я единственный человек, который считает языки ML синтаксически красивыми.

Это ничего не меняет ... Я сказал, что «такие же распространенные, как и другие языки .NET», и я буду придерживаться этого. Я ожидаю, что в большинстве бизнес-систем в течение значительного времени будет больше кода, отличного от FP, чем кода FP.

Вероятно, это должен был быть комментарий, а не пост, кстати.

@Marc: Я не уверен, что означают ваши предсказания. Является ли IronPython основным языком .NET? Разве на практике большая часть кода F# не является FP? Я думаю, что FP часто является отвлекающим маневром в контексте F#. Люди цепляются за FP, потому что слышат хайп о Haskell, но на практике это не очень важно. Практические преимущества F# заключаются в другом ...

И снова Джон Харроп рассказывает нам сказки о том, что «хвостовые вызовы - это требуется» (выделено мной) для функционального кода. Кто бы это ни читал - это просто неправда. Конечно, приятно иметь поддержку хвостового вызова - точно так же, как хорошо иметь FPU, но не требуется для вычислений с плавающей запятой.