Здравствуйте, nikov, Вы писали:
VD>>Их больше чем может показаться. Причем их качество в разы выше среднего уровня. N>А цена?
Многократно окупается качеством.
Алгоритмически сложные вещи ты на жапошарпах просто озвереешь писать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Главным образом, их туда вводили для интероперабельности с джавовскими wildcards (которые тоже являются урезанной разновидностью экзистенциальных типов).
Ну и, вообще, это сильный инструмент для абстракции.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Пельмешко, Вы писали:
П>>Scala намного более дружественна и можно разрабатывать практически как на java с плюшками.
VD>Видимо потому, что ты с Явы перепрыгивал. Да?
Нет, никогда на Java ничего не писал, лишь интересовался некоторыми особенностями generic'ов. Я просто слышал распространённое мнение, что можно на Scala можно писать очень java-like, у меня сложилось точно такое же впечатление.
П>>(у меня никак не получается въехать в параметрический полиморфизм высших порядков и экзистенциональные типы, а особенно в их юзкейсы).
VD>Ты случаем F# и Haskell не перепутал? Перечисленные фичи есть только в расширениях (если не ошибаюсь пока что нестандартных) Haskell-я. В F# используется система типов адаптированная для дотнета.
Я про Scala говорил же, внимательнее
П>>Мне кажется, что если Scala не будут переусложнять всяким матаном и неявными параметрами, то получиться вполне себе великолепный мейнстрим-язык, замена Java.
VD>Да он уже получился. Что ждать то?
Мне кажется можно вполне очень легко разрабатывать, практически игнорируя матан, который там есть сейчас — но это сугубо ИМХО. Всякими IDE скрыть implicit-параметры, сигнатурки попроще станут и т.п...
П>> И мне в .net-стеке будет очень завидно, что в java-стеке есть такой язык
VD>Немерл ничем не уступает Скале. Более того он как раз удовлетворяет твоим критериям — он очень простой. VD>Ну, а макросы делают его на порядок мощнее Скалы и F# вместе взятых.
Мне очень хочется познакомиться с макросами лиспа/немерле, но это лишь из любознательности. "Задела на будущее" не вижу никакого, к сожалению.
И ещё, честно говоря, не представляю как у вас там в Немерлях дебажится код, пропущенный через десяток макросов.
Здравствуйте, WolfHound, Вы писали:
VD>>>Их больше чем может показаться. Причем их качество в разы выше среднего уровня. N>>А цена? WH>Многократно окупается качеством. WH>Алгоритмически сложные вещи ты на жапошарпах просто озвереешь писать.
Вот и получается такая ниша: проекты с большим количеством алгоритмически сложных вещей и немаленьким бюджетом, например, финансовая сфера. Как я вижу, ее уверенно занимает F#.
Здравствуйте, VladD2, Вы писали:
M>>Лично мне тяжело перестраиваться под такой стиль, как по минному полю идешь. VD>Можно примеры? Точнее обще, объяснить о каком минном поле идет речь?
Очень просто, берешь простую задачу, пытаешься ее решить и буксуешь, не в состоянии найти решение. Или борясь с непонятными ошибками. Да, на Nemerle можно писать в императивном ключе, но... смысл? Просто использовать другой синтаксис? Если брать книгу Душкина по Haskell, то там надо кучу интеллектуального труда только для того, чтобы разобраться в том, как вся работа со списками выражается через три общие функции. Такой высокий полет сознания мне недоступен. Если брать макросы Nemerle, то после того, как я понял, что адский синтаксис на нем реализовать нельзя, то немного охладел к ним. По крайней мере, я не знаю, как их написать.
Вторая проблема в том, что мне наиболее близка императивная форма. Когда я вижу что-то декларативное, которое вроде бы делает то, что мне надо, но я в этом не уверен на все 100%, я начинаю нервничать. И пока все не переведу в императивный вид, не успокоюсь. Соответственно лишняя работа, падение скорости разработки.
Здравствуйте, WolfHound, Вы писали:
VD>>>Их больше чем может показаться. Причем их качество в разы выше среднего уровня. N>>А цена? WH>Многократно окупается качеством. WH>Алгоритмически сложные вещи ты на жапошарпах просто озвереешь писать.
А много ли их, сложных вещей, в мейнстриме?
Здравствуйте, vmpire, Вы писали:
V>Здравствуйте, WolfHound, Вы писали:
VD>>>>Их больше чем может показаться. Причем их качество в разы выше среднего уровня. N>>>А цена? WH>>Многократно окупается качеством. WH>>Алгоритмически сложные вещи ты на жапошарпах просто озвереешь писать. V>А много ли их, сложных вещей, в мейнстриме?
мало. Но иногда бывает. ИМХО сила Nemerle или Scala в том, что на них мона писать так же как в C#/Java, но при случае — заюзать макросы или этот параметрический полиморфизм высших порядков... В рамках одного языка. Ну и конечно всякие приятные "мелочи" типа АТД и патерн мачинга.. Это то мона вобоще в любом проэкте заюзать с пользой..
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, nikov, Вы писали:
WH>Алгоритмически сложные вещи ты на жапошарпах просто озвереешь писать.
Их пишу на чистом C Что-то не видно много сильных шахматных программ на всяких функциональных языках. Алгоритмическая сложность часто завязана на производительность...
Здравствуйте, Mystic, Вы писали:
M>Вторая проблема в том, что мне наиболее близка императивная форма. Когда я вижу что-то декларативное, которое вроде бы делает то, что мне надо, но я в этом не уверен на все 100%, я начинаю нервничать. И пока все не переведу в императивный вид, не успокоюсь. Соответственно лишняя работа, падение скорости разработки.
Для этого обычно разобраться лишь в том, что там под капотом. Всё переписывать совсем не обязательно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Для этого обычно разобраться лишь в том, что там под капотом. Всё переписывать совсем не обязательно.
Разобраться мало, надо научиться этим пользоваться. Читаешь Душкина, вроде все понятно. Доходишь до упражнений, и сразу: "Э-э-э-э... Как??!! Дайте мне переменные и циклы!!!" Вторая проблема в том, чтобы набраться терпения и довести что-то до конца. Мучаешься, мучаешься, потом забиваешь и делаешь на чем-то более понятном. Или просто забиваешь
Здравствуйте, nikov, Вы писали:
N>F# изобретен в Microsoft Research, и Microsoft уже сделал на него ставку.
Когда начали продвигать F# в иНете появились заметки из серии "F# and WPF". Однако, как потом оказалось, в F# нет public static readonly полей. А без этого в WPF никуда. Это я о том, как всякие мелочи мешают задействовать этот язык даже при желании.
Здравствуйте, Mystic, Вы писали:
WH>>Алгоритмически сложные вещи ты на жапошарпах просто озвереешь писать. M>Их пишу на чистом C Что-то не видно много сильных шахматных программ на всяких функциональных языках. Алгоритмическая сложность часто завязана на производительность...
На производительность завязана вообще-то ресурсоёмкость алгоритмов, а не их алгоритмическая сложность. Сложность там как раз появляется в попытке решить одновременно в одном месте как саму основную задачу, так и алгоритм её оптимизации. Отсюда якобы сложность завязана на производительность. На самом деле всё совсем наоборот — в погоне за производительностью мы усложняем задачу.
Основным же инструментом для решения алгоритмически сложных задач в перечисленных языках является паттерн-матчинг, который позволяет десяток запутанных if-ов заменить одним простым и понятным паттерном. Плюс конечно же множество других плюшек и полезняшек, которые в итоге сильно повышают выразительность конкретного языка как инструмента разработки.
Ко всему прочему в Немерле мы ещё имеем макросы. Как известно, сложность разрабатываемого продукта не может превышать на порядок сложности инструмента, на котором этот продукт разрабатывается. Так вот макросы Немерле позволяют самостоятельно разрабатывать такие инструменты и получать уже два порядка, а не один.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Jack128, Вы писали:
WH>>>Алгоритмически сложные вещи ты на жапошарпах просто озвереешь писать. V>>А много ли их, сложных вещей, в мейнстриме?
J>мало. Но иногда бывает. ИМХО сила Nemerle или Scala в том, что на них мона писать так же как в C#/Java, но при случае — заюзать макросы или этот параметрический полиморфизм высших порядков... В рамках одного языка. Ну и конечно всякие приятные "мелочи" типа АТД и патерн мачинга.. Это то мона вобоще в любом проэкте заюзать с пользой..
Это в теоретической реальности. А в реальной — 80% ищущих работу на .NET и C# толком не знают.
А макросы или прочие "мелочи" — так это вообще высший пилотаж. Там же надо, страшно подумать, документацию читать!
С другой стороны — для мейнстрима нужна критическая масса заказчиков, которые согласятся вложить свои собственные деньги в проект на языке, поддерживаемом никому особо не известной французской университетской группой LAMP Group (Scala) или другими студентами, только из Польши (Nemerle), а не одним из лидеров отрасли (MS или Sun).
Здравствуйте, Mystic, Вы писали:
WH>>Алгоритмически сложные вещи ты на жапошарпах просто озвереешь писать.
M>Их пишу на чистом C Что-то не видно много сильных шахматных программ на всяких функциональных языках. Алгоритмическая сложность часто завязана на производительность...
Перебирать варианты это сложный алгоритм? Хотя, может хорошая шахматная программа и сложная, но написать любую программу можно и на асемблере, особенно когда все процессорное время занимает маленький кусок кода.
На ФП все-таки многие алгоритмы компактнее, а оптимизацией программ должен заниматься компьютер а не человек, если эти оптимизации сильно портят код (раздувают и искажают).
Функциональные программы потенциально легче поддаются оптимизации компилятором.
Хотя, пока к сожалению компиляторы MS не очень хотят заниматься оптимизацией.
Вот пример на F#, функция складывающая два числа:
let public TestFunc p1 p2=
let (e1,e2) = match p1 with
|p1 when p1>0 -> (p2,p1)
| _ -> (p1,p2)
e1+e2
Это после компиляции в release с оптимизацией. Такое показывает рефлектор.
Сложение двух чисел через динамическую память
[CompilationArgumentCounts(new int[] { 1, 1 })]
public static int TestFunc(int p1, int p2)
{
Tuple<int, int> tuple = (p1 <= 0) ? new Tuple<int, int>(p1, p2) : new Tuple<int, int>(p2, p1);
return (tuple.get_Item1() + tuple.get_Item2());
}
Здравствуйте, vmpire, Вы писали:
V>Это в теоретической реальности. А в реальной — 80% ищущих работу на .NET и C# толком не знают. V>А макросы или прочие "мелочи" — так это вообще высший пилотаж. Там же надо, страшно подумать, документацию читать! V>С другой стороны — для мейнстрима нужна критическая масса заказчиков, которые согласятся вложить свои собственные деньги в проект на языке, поддерживаемом никому особо не известной французской университетской группой LAMP Group (Scala) или другими студентами, только из Польши (Nemerle), а не одним из лидеров отрасли (MS или Sun).
Вот интересно, Влад и тебя так же грязью обольет, как и меня, когда я те же самые слова писал с год назад? Или тебя все-таки минет чаша сия?
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, Mystic, Вы писали:
WH>>>Алгоритмически сложные вещи ты на жапошарпах просто озвереешь писать.
M>>Их пишу на чистом C Что-то не видно много сильных шахматных программ на всяких функциональных языках. Алгоритмическая сложность часто завязана на производительность...
S_> Перебирать варианты это сложный алгоритм? Хотя, может хорошая шахматная программа и сложная, но написать любую программу можно и на асемблере, особенно когда все процессорное время занимает маленький кусок кода.
Шахматная программа это не только перебор вариантов при помощи альфа-бета. Это еще и быстрая генерация ходов, завязанная на конкретном представлении позиции (например, magic bitboard), это настройка оценочной функции, это всякие эвристики, управляющие перебором (например, форсированный вариант, ходы-киллеры, нулевой ход, Z-Orbice). Еще надо модифицировать перебор под режим анализа (предлагать несколько линий). Плюс сложность в том, что непонятно, как то или иное новшество повлияет на силу игры. И надо предлагать методы исправления некоторых слабостей программы, чтобы при этом не сильно задеть все остальное. Плюс многопоточность + создание вычислительного кластера.
Сложность задачи характеризует хотя бы тот факт, что программа Deep Blue, которая выполнялась на компьютере, который в несколько раз по производительности обходит персоналки, сейчас по качеству игры проигрывает персоналкам.
Вроде бы, с одной стороны, программирование шахмат как раз отвечает всем преимуществам фунциональных языков, а на практике...
Здравствуйте, nikov, Вы писали:
N>F# изобретен в Microsoft Research, и Microsoft уже сделал на него ставку.
Сам по себе F# достаточно приятный и фичи и синтаксис и интеграция с .Net
Но. Мейнстрим как я понимаю это большие проекты кучи файлов разбросанных по разным папкам.
В связи с этим философский вопрос. Почему они сделали F# без поддержки заглядывания вперед, forward declarations (или как там оно называется). Все что выше по тексту F# вобще не видит.
Это из-за того что компилятор пока не смогли хороший написать, или в самом языке некоторые фичи принципиально не позволяют это сделать? Считают это за нормальную фичу и не собираются исправлять?
Сделали специальную команду в менюшке, чтобы задавать в каком порядке компилировать файлы проекта.
Сделали header файлы как в C++ чтобы forward declarations задавать. От этой гадости мэйнстрим начал уходить, а тут опять предлагают header файлы.
И непонятно почему F# даже внутри списка параметров функции не может вперед заглянуть. Это временные недостатки компилятора, или так и задуманно?
//ошибка, не может определить тип e, надо писать fun (e:SomeStruct) -> ....
let F (lst:List<SomeStruct>) : List<int> =
List.map (fun e -> e.Fld1 - e.Fld2) lst
//если lst перекинуть вперед то тип определяется
let F (lst:List<SomeStruct>) : List<int> =
lst|> List.map (fun e -> e.Fld1 - e.Fld2)
Если нам не помогут, то мы тоже никого не пощадим.
