Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, AlexRK, Вы писали:
ARK>>Просто код, который использует плагины, сам должен быть генерик-кодом.
K>Он может быть дженерик кодом, но не в том смысле в котором вы предлагаете. В T Get() дженерик у нас такой: K>
K>forall T. T <: IPet
K>
K>В случае плагина так не получится. Но получится так: K>
K>exist T. T <: IPet
K>
K>Т.е. мы сможем вернуть из плагина, например, PetBox с этим типом внутри и элиминировать этот ящик, сделав с этим типом что-то, что позволяет интерфейс IPet. При этом "выпустить" тип "наружу" мы не сможем.
Не совсем понял. Если взять C#-подобный язык, то речь идет о классе типа такого:
class PluginContainer
{
private class Internal : IPlugin
{
...
}
void Process(Action<IPlugin> agent)
{
agent(new Internal());
}
}
?
Но ведь нам надо как-то инстанционировать этот сам "ящик" — он ведь будет разный в каждом плагине, раз внутри у него какой-то скрытый тип, у каждого свой. Я понимаю, что в C# подобных штук нет, но может как-нибудь на C#-подобном псевдокоде поясните?
В принципе, никто и сейчас не мешает объявлять функции вида
foo (a, b, c)
и частично применять их
foo.(1, , 2) -- при включенном расширении TupleSections
Да и перегружать такие функции с помощью тайпклассов можно — выглядит это по хаскельным меркам страшно, по по сравнению с мусором в объявлении функции мейнстримного языка — уже не так плохо.
Но популярность такого подхода в хаскеле равна нулю.
В стандартной библиотеке SML функций, принимающих туплы, еще достаточно много, но в целом по фя карринг победил (что не удивительно).
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
AVK>Так ты предлагаешь вообще от интерфейсов отказаться? Ну, чтобы их не рефакторить?
Нет отказываться не надо, нужен другой подход.
Оставить базовый интерфейс IPet — который описывает поведения и взаимодействие IPet с хозяином.
А дальше конкретных Pet создавать в таком стиле — DogPet extends Dog implements IPet {...}
Здравствуйте, AlexRK, Вы писали:
ARK>Практика показывает, что выживают языки, в которые вкладывается много ресурсов. Остальное по большому счету не имеет значения.
Есть такое. Но бабло и пиар не единственные критерии.
ARK>Не думаю, что языковые возможности выживших являются безусловным образцом для подражания.
Безусловно, не являются безусловным образцом. Но их опыт нужно учитывать. И опыт показывает, что людям удобно работать с иерархиями типов. Кстати, это не отрицает возможности работы с объеденениями типов.
Я вообще не понимаю почему Воронков пытается противопоставить иерархии объединениям.
VD>>Кроме того перегрузка она мешает только тем кто не умеет ее готовить (в языках).
ARK>Ну фиг знает. По моему мнению перегрузка облегчает запись, но не чтение.
Я что-то не пойму причем тут чтение. Перегрузка позволяет не выдумывать синтетических имен. Человеку естественно думать о многих вещах как о разновидностях одной и той же сущности. Естественные языки дико перегружены и это нисколько не мешает нам читать написанное на них.
Реальность же такова — многие табу и догмы в программировании рождаются не потому, что что-то плохо (например, перегрузка), а потому, что авторы языка (библиотеки или еще чего-то) не могут качественно реализовать это что-то в своих продуктах (компиляторах, в нашем случае).
Перегрузка, неявные приведения, иерархические системы типов сильно усложняют реализацию компиляторов языков с выводом типов. Но это чисто технические проблемы которые авторы пытаются превратить в идеологические.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AlexRK, Вы писали:
ARK>Согласен. Хотя вроде бы в окамле операторы разные.
Его авторы просто не справились с задачей и перевели проблему в область табу. В F#, например (прямой потомок ОКалма) справились с этой проблемой и тот час же сочли перегрузку допустимой. Но вот с неявными приведениями не справились и опять же не нашли ничего лучше как сделать свою недоработку в компиляторе преимуществом воспеваемым во всех рекламных буклетах. В прочем, перегрузкой они тоже справились условно. Проблем там хватает.
ARK>Вообще тут вопрос неоднозначный. Во-первых, в идеальном сферическом языке в вакууме даже оператор сложения не будет перегружен — будет единый тип "число".
Такой язык будет мало кому нужен, так как он будет тормозом. Разные "числа" имеют разные рзмеры и обрабатываются разными инструкциями процессора. Если делать их объектами с поддержкой полиморфизма, то арифметика станет настолько медленной, что ты сам бросишь этот язык. "Число", кстати, еще и точность имеет. Вот в скриптах на эти детали забивают. Но результат — тормоза.
ARK> Во-вторых, если ближе к реальности, то с такой перегрузкой я согласен — она в одном месте и выглядит естественно, т.к. пришла из математики.
Очередной поиск отмазки. Какая тут на фиг математика? В ней что есть понятие размерности типов или отсутствие плавающей точки? Это все детали архитектуры процессоров влияют.
ARK> Даже специальный синтаксис используется, а не обычный вызов метода.
Это ровным счетом ничего не меняет. Просто традиции.
ARK> А вот другие типы перегрузки как-то не внушают доверия.
Ну, попробуй обосновать свое недоверие. Уверяю тебя скатишься до тех же табу, что и авторы ОКамла. А реальность она прозоична — перегрузка не вписывется в примитивные алгоритмы вывода типов вроде Хиндли-Милнера. Вот и выбрасывают ее чтобы упростить себе жизнь. В Немерле есть и перегрузка, и неявные приведения типов, но проблем при чтении кода (и в других случаях) не возникает. А раз есть хотя бы один пример опровергающий правило, значит это не правило, а подтасовка.
ARK>Кстати, я тут подумал — не припомню в своих проектах интенсивного использования перегрузки (хотя у других людей опыт другой, конечно).
Припоминаю в своих проекта массовое использование перегрузок. Что это меняет?
Как бы разговор о вреде перегрузки — это разговор в пользу бедных. Все самые массовые языки ее поддерживают. Значит в ней точно вреда нет. На сегодня основные библиотеки пишутся как раз для языков с перегрузкой. Если есть желание жить в современном мире и пользоваться современными библиотеками, то поддерживать перегрузку (хотя бы для интеропа) жизненно необходимо. Иначе язык будет сфериоконем вакуумным.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>И как ты себе представляешь ленивый массив?
Это к делу не относится. Мы же не о частных случаях говорим.
VD>>Такие штуки прокатят только чем-то вроде классов типов, когда можно сделать по перегрузке (отдельной реализации) для каждого поддерживаемого типа. VD>>Вот только к исходному вопросу это уже отношение не имеет.
ВВ>Какие такие штуки? Причем тут классы?
Ты точно понял, что я тебе написал? Попробуй прочесть еще раз.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, AlexRK, Вы писали:
ARK>>Вообще тут вопрос неоднозначный. Во-первых, в идеальном сферическом языке в вакууме даже оператор сложения не будет перегружен — будет единый тип "число".
VD>Такой язык будет мало кому нужен, так как он будет тормозом. Разные "числа" имеют разные рзмеры и обрабатываются разными инструкциями процессора. Если делать их объектами с поддержкой полиморфизма, то арифметика станет настолько медленной, что ты сам бросишь этот язык. "Число", кстати, еще и точность имеет. Вот в скриптах на эти детали забивают. Но результат — тормоза.
Не-не, я имею в виду не тот вариант, который применяется в скриптах. Имеется в виду нечто типа языка Ada: http://en.wikibooks.org/wiki/Ada_Programming/Type_System. Т.е. реальные типы всегда имеют конечные размеры и точность, а вот алгоритмы абстрактны — могут работать с любыми Integer или Real.
ARK>> А вот другие типы перегрузки как-то не внушают доверия.
VD>Ну, попробуй обосновать свое недоверие. Уверяю тебя скатишься до тех же табу, что и авторы ОКамла. А реальность она прозоична — перегрузка не вписывется в примитивные алгоритмы вывода типов вроде Хиндли-Милнера. Вот и выбрасывают ее чтобы упростить себе жизнь. В Немерле есть и перегрузка, и неявные приведения типов, но проблем при чтении кода (и в других случаях) не возникает. А раз есть хотя бы один пример опровергающий правило, значит это не правило, а подтасовка. VD>Припоминаю в своих проекта массовое использование перегрузок. Что это меняет? VD>Как бы разговор о вреде перегрузки — это разговор в пользу бедных. Все самые массовые языки ее поддерживают. Значит в ней точно вреда нет. На сегодня основные библиотеки пишутся как раз для языков с перегрузкой. Если есть желание жить в современном мире и пользоваться современными библиотеками, то поддерживать перегрузку (хотя бы для интеропа) жизненно необходимо. Иначе язык будет сфериоконем вакуумным.
Сейчас не готов серьезно обсуждать перегрузку. Мне эта концепция давно не нравится, хотя возможно я не прав. В принципе, если нет иерархий типов и неявных приведений, плюс если можно перегружать по возвращаемому значению, то, возможно, оно не так уж плохо (но это опять же к современным мейнстрим-языкам не относится ).
Здравствуйте, AlexRK, Вы писали:
ARK>Не-не, я имею в виду не тот вариант, который применяется в скриптах. Имеется в виду нечто типа языка Ada: http://en.wikibooks.org/wiki/Ada_Programming/Type_System. Т.е. реальные типы всегда имеют конечные размеры и точность, а вот алгоритмы абстрактны — могут работать с любыми Integer или Real.
Сдается не что Агда и есть тормоз. Есть физические проблемы. Их невозможно преодолеть. Перегрузка это единственное решение не дающее замедление. Тут еще упоминались шаблоны, но специализация шаблонов — это форма перегрузки.
Надо просто понять, что единственный способ получить быстрый код — использовать для хранения типов фиксированные области памяти и генерировать отдельные наборы функций для работы с ними.
ARK>Сейчас не готов серьезно обсуждать перегрузку. Мне эта концепция давно не нравится, хотя возможно я не прав. В принципе, если нет иерархий типов и неявных приведений, плюс если можно перегружать по возвращаемому значению, то, возможно, оно не так уж плохо (но это опять же к современным мейнстрим-языкам не относится ).
Это набор заблуждений пропагандируемый разработчиками языков которые не способны создать современные алгоритмы вывода типов.
Людям удобно думать в терминах иерархий типов, перегрузок и неявных приведений (которые по сути являются разновидностью сабтайпинга).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AlexRK, Вы писали:
ARK>Но ведь нам надо как-то инстанционировать этот сам "ящик" — он ведь будет разный в каждом плагине, раз внутри у него какой-то скрытый тип, у каждого свой. Я понимаю, что в C# подобных штук нет, но может как-нибудь на C#-подобном псевдокоде поясните?
Ну, можно попробовать:
//было IPet Get() - стало:
{exist T where T : IPet} Get()
T Get<exist T>() where T : IPet // или так
{
// было return ((IPet) new Cat()); стало:return {Cat, new Cat()}; // вводим (упаковываем)
}
// так нельзяvoid Foo<forall T1>(Action<T1> kill) where T1 : IPet
// нужны rank-2 типы:void Foo(Action<forall T1> kill) where T1 : IPet
{
var {T2, pet} = Get(); // элиминируем (распаковываем)
// после этого биндинга можно использовать T2:
kill<T2>(pet);
}
// но вот так нельзя:
T2 Foo(Action<forall T1> kill) where T1 : IPet
//ошибка: T2 за пределами области видимости
// так можно:
{exist T where T : IPet} Foo(Action<forall T1> kill) where T1 : IPet
Т.е. если убрать отношения сабтайпинга между классом и реализуемым им интерфейсом и оставить только интерфейсы как констрейнты — нужны экзистенциальные типы и полиморфизм ранга 2.
Если убрать наследование вообще и оставить только имплементацию интерфейсов, то диспетчеризация будет статической ("интерфейсные" вызовы можно вовсе заинлайнить) для всех универсальных (forall) типов (как сейчас для struct и интерфейсов-констрейнтов) и динамической для всех экзистенциальных (exist). Т.е. какой-то оверхед от полиморфизма останется только в тех случаях, когда без него не обойтись. Устранять же всеобщую виртуальность вызовов в тех случаях, где она не нужна (почти везде) хоть и кое-как можно, но это весьма нетривиально.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, vdimas, Вы писали:
V>Нет. Т.е. не обязательно, в этом весь трюк. Там где возможен выбор в compile-time, там классы типов и нафик не упали.
Вот так новости. Классы типов для выбора в компайл тайм и предназначались. Для первого применения тайпклассов — полиморфной арифметики — это вообще критично. Это уже позже появились возможности реифицировать словарь и организовать выбор в рантайме.
V>Не нужен там никакой dictionary. Там для каждого динамического случая нужен кортеж из используемых ф-ий тайпкласса.
Передача кортежа функций и называется dictionary passing style, а кортеж функций называется dictionary.
V>Там ближайший аналог — это реализация тайпклассов через фиктивные АлгТД, в которых хранятся ф-ии тайпкласса
Не через фиктивные, а вполне реальные (до какого-то прохода оптимизатора, по крайней мере).
V>но выбор ф-ий по коду АлгТД и последующий их вызов ничем принципиально от виртуальных вызовов не отличается.
Это касается типов-сумм (вариантов). Словарь тайпкласса же это не сумма, а произведение (кортеж). Нет для кортежей никакой диспетчеризации — выбирать-то не из чего. Поэтому и вызовы не нужны, не то что диспетчеризация. На практике, разрешение тайпклассов вот в таком вот коде:
import Control.Monad
import Control.Monad.Instances
foo :: Int -> Int
foo = join (+)
bar :: Double -> Double
bar = join (+)
main = do
n <- getLine
print . foo . read $ n
print . bar . read $ n
приведет к тому, что foo и bar превратятся просто в
x +# x
x +## x
соотвественно. Т.е. мономорфные сложения интов и даблов. Статичнее уже просто некуда. От словарей не осталось ничего. Словари нужны только для полиморфного кода, лежащего в библиотеке, а выполняется-то мономорфный. Но даже без всякого инлайна, при сохранении словаря — нет никакой диспетчеризации. Потому, что кортеж — не вариант. Аналог структуры, а не аналог (отдаленный) иерархии классов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Instance selection — статический. А наследование там есть. Вообще тему, конечно, стоило про Хаскелл создать.
Кстати, "наследование" тайпклассов в хаскеле — фича сомнительной полезности, да еще и, в некоторых случаях, достаточно проблемная.
Почему сомнительной полезности? И почему проблемная?
Члены тайпкласса "наследника" редко могут быть реализованы в терминах базового класса (тут наследование могло бы помочь), но зато очень часто базовый класс может быть реализован в терминах наследника (тут наследование ничем помочь не может). Возможно, полезность наследованию могли бы придать так называемые дефолтные реализации для суперклассов:
class Functor f => Applicative f where
return :: x -> f x
(<*>) :: f (s -> t) -> f s -> f t
(>>) :: f s -> f t -> f t
fs >> ft = return (flip const) <*> fs <*> ft
-- описываем дефолтный инстанс для суперкласса.instance Functor f where
fmap = (<*>) . return
class Applicative f => Monad f where
(>>=) :: f a -> (a -> f b) -> f b
instance Applicative f where
ff <*> fs = ff >>= \f -> fs >>= \s -> return (f s)
В такой (гипотетической) иерархии нужно было бы реализовывать только самый "нижний" класс в иерархии из тех, что мы могли бы реализовать, получая инстансы для всей вышележащей иерархии автоматически. Проблема, думаю, понятна — пока иерархия линейна — все в порядке, но если у нас дерево — какой дефолтный инстанс из нескольких доступных предпочесть? Разумеется, это расширение не реализовано (есть правда препроцессор, который позволяет с ним поиграть.)
Без этого использовать "наследование" для повторного использования кода затруднительно.
При этом наследование обязывает определять инстансы всей иерархии, большая часть из которых по вышеописанной причине — бойлерплейт.
Принуждение к инстанциации группы классов, теоретически, может быть полезным, практика показывает, что для хаскеля это, скорее, не так. Слишком сильное связывание и все такое. Это не только мое мнение — последние ломающие изменения в base связаны с ликвидацией этой связи между классами. В той, что поставляется с ghc 7.4, убрали наследование Num от Show и Eq. В той, что будет поставляться с ghc 7.6, убрали наследование Bits от Num. При этом добавлять такие связи, наоборот, не спешат (включая и "наследование" Monad от Applicative, о котором так долго говорили большевики). Справедливости ради нужно отметить, что добавление наследования, возможно, связано с большими неприятностями с совместимостью чем удаление.
При этом, уже сейчас в хаскеле есть средства, позволяющие переиспользовать код в инстансах по максимуму без всякого наследования:
class DFunctor f where
dmap :: (a -> b) -> f a -> f b
default dmap :: DMonad f => (a -> b) -> f a -> f b
dmap f = dbind (dreturn . f)
class DApplicative f where
dpure :: a -> f a
default dpure :: DMonad f => a -> f a
dpure = dreturn
dap :: f (a -> b) -> f a -> f b
default dap :: DMonad f => f (a -> b) -> f a -> f b
dap ff fs = ff `dbind` \f -> fs `dbind` \s -> dreturn (f s)
class DMonad m where
djoin :: m(m a) -> m a
djoin = dbind id
dbind :: (a -> m b) -> m a -> m b
default dbind :: DFunctor m => (a -> m b) -> m a -> m b
dbind f = djoin . dmap f
dreturn :: a -> m a
default dreturn :: DApplicative m => a -> m a
dreturn = dpure
-- теперь, если у нас есть инстанс DMonad, то инстансы для
-- DFunctor и DApplicative не нужно реализовывать, только
-- указать, что они нам нужны:instance DFunctor []
instance DApplicative []
-- Или, если есть инстансы для DFunctor и DApplicative,
-- нужно реализоватьтолько тот минимум, который добавляет DMonad:instance DMonad [] where
join = concat
В принципе, это дефолтные суперклассы наоборот (то, какие классы используются для реализации определены в классе, который надо реализовать, а не в классе, который можно использовать для имплементации), но не требующие наследования и других сильных связей (дефолтные реализации используют то, что есть, если ручная реализация не написана) и явно определяющие, какие классы (без всяких супер и суб — наследования-то нет) используются для дефолтных реализаций, без всяких неопределенностей. Никаких неявных инстансов они также не создают.
Наследование, в принципе, позволяет избавиться от огромных контекстов. Но на практике для этого используется редко (городить такую сильную связь ради некоторого уменьшения писанины — спорное решение). Тем более, что в современном хаскеле есть средства куда луше:
type NumAndEq a = (Num a, Eq a)
foo :: NumAndEq a => a -> a -> Bool
foo a b = a * b == a
Т.е. в хаскеле сейчас тенденция такая: отказ от наследования в стандартных библиотеках, добавление более адекватных (это, впрочем, еще время покажет — или не покажет) средств решения проблем без всякого наследования.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, VladD2, Вы писали:
VD>В целом по ФЯ — они слили. В мэйнстрим им не попасть. Туда пойдут гибриды. Ставлю ящик пива, что они будут карринга.
Свою позицию по ФЯ и мейнстриму я уже не раз тут декларировал. Очевидно, что в мейнстрим сначала попадут гибриды. Так обычно и бывает: гибрид — это переходное решение. После гибридов в мейнстрим пойдут чистые ФЯ. Когда они устареют — тотальное программирование. А что после него будет — еще непонятно. Пока паровые машины сырые и ненадежные, пока опыт их эксплуатации не накоплен — в мейнстриме параходофрегаты. Когда паровые машины доведены до приемлемого качества — в мейнстриме пароходы.
VD>Людям не нужны ФЯ. Людям нужно решать свои проблемы. Причем здесь и сейчас.
Мне нужны. ФЯ решают часть моих проблем. Да, уже сейчас, даже принимая во внимание всю их сырость. И, по мере совершенствования, будут решать все болше, а создавать — все меньше.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Свою позицию по ФЯ и мейнстриму я уже не раз тут декларировал. Очевидно, что в мейнстрим сначала попадут гибриды. Так обычно и бывает: гибрид — это переходное решение. После гибридов в мейнстрим пойдут чистые ФЯ.
Готов поспорить на что угодно, что в мейнстриме чистых ФЯ не будет никогда.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Готов поспорить на что угодно, что в мейнстриме чистых ФЯ не будет никогда.
Я бы поспорил, но спор нечестный: я его в принципе не могу проиграть (даже если ФЯ действительно не попадут в мейнстрим никогда), в отличие, например, от спора, что чистые ФЯ не попадут в мейнстрим в ближайшие 10 лет.
А что по-вашему, будет следующим мейнстримом? Или нас ожидает конец истории?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
AVK>>Готов поспорить на что угодно, что в мейнстриме чистых ФЯ не будет никогда. K>Я бы поспорил, но спор нечестный: я его в принципе не могу проиграть (даже если ФЯ действительно не попадут в мейнстрим никогда), в отличие, например, от спора, что чистые ФЯ не попадут в мейнстрим в ближайшие 10 лет. K>А что по-вашему, будет следующим мейнстримом? Или нас ожидает конец истории?
Мне кажется, тут следует вначале задать другой вопрос — а что *нужно* мейнстриму? Я вот не уверен, что мейнстриму нужны языки общего назначения в принципе. Мейнстриму, скорее, нужны крайне ограниченные "доменные" языки, заточенные под решение узкого круга специальных задач. Т.о. программирование превращается скорее в этакую "конфигурацию" софта. Тенденция такая, однако, намечается.
Здравствуйте, Klapaucius, Вы писали:
K>Свою позицию по ФЯ и мейнстриму я уже не раз тут декларировал. Очевидно, что в мейнстрим сначала попадут гибриды. Так обычно и бывает: гибрид — это переходное решение. После гибридов в мейнстрим пойдут чистые ФЯ.
На мой взгляд в чистом виде они никогда не попадут в мэйнстрим. Бессмысленно делать язык для программирования без побочных эффектов на в доску императивном компьютере. Многие задачи по смыслу императивны и эмуляция их на чем-то вроед монад приведет к усложнению, а не к упрощению.
Но часто фишки ФП могут упростить задачу. Так что смесь ФП и МП будет только развиваться.
Когда мэйнстрим полностью впитает ФП, то говорить о чистых ФЯ просто не придется.
K>Когда они устареют — тотальное программирование.
Второй раз слышу это словосочетание. Гугль ничего не объясняет. Что это значит?
K>А что после него будет — еще непонятно. Пока паровые машины сырые и ненадежные, пока опыт их эксплуатации не накоплен — в мейнстриме параходофрегаты. Когда паровые машины доведены до приемлемого качества — в мейнстриме пароходы.
Я ставлю на ДСЛ-и и МП. А ФП, ООП будут позволять упростить генерацию кода для них.
Паровые машины (Лисп) не предлагать. Не тот уровень юзабельности.
VD>>Людям не нужны ФЯ. Людям нужно решать свои проблемы. Причем здесь и сейчас.
K>Мне нужны. ФЯ решают часть моих проблем. Да, уже сейчас, даже принимая во внимание всю их сырость. И, по мере совершенствования, будут решать все болше, а создавать — все меньше.
Ты явно не из числа тех кого можно к мэйнстриму отнести. Тебе и еще кому-то нужны. Но людям в целом — нет. Уровень решения задач все равно крайне низкий. Мозголомство страшное. Не взлетит.
А вот ФП-шные фишки в мэйнстрим впитаются. Лямбды уже тут. Паттерн-матчингу пока мэйнстрим сопротивляется, но в течеии лет 10 сдастся.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Т.о. программирование превращается скорее в этакую "конфигурацию" софта. Тенденция такая, однако, намечается.
Не знаю откуда ты такую тенденцию взял, но почти все новые мейнстрим-языки сложнее своих предков. Безусловно, область "конфигурации" тоже растет и развивается, но то, что конфигурировать, его ведь тоже кто то написать должен.
Вообще, развитие разработки софта идет пока в строгом соответствии с законом развития сложных систем — новый инструментарий постоянно закрывает области, где раньше требовалось рукопашное программирование, но оставшиеся незакрытые растут в объеме еще быстрее, да новые появляются.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Klapaucius, Вы писали:
K>>Когда они устареют — тотальное программирование.
VD>Второй раз слышу это словосочетание. Гугль ничего не объясняет. Что это значит?
Видимо, речь о программах, которые гарантировано и формально доказано не содержат ошибок времени исполнения. А функции, которые имеют ограниченную область определения, не могут быть вызваны вне этой области.
