Хаскель не очень-то и наворочен. Если не брать расширения, то он вообще скорее простой, чем сложный. Все трудности в изучении Хаскеля не от его навороченности, а от того что он очень сильно отличается от всего привычного.
import Data.IORef
proc var = do c <- readIORef var
writeIORef var (c + 1)
readIORef var >>= (putStrLn . show)
main = do var <- newIORef 0
proc var
proc var
proc var
SQL не определяет способ выполнения запроса, поэтому его можно смело называть декларативным. Но вряд ли функциональным — нет first class functions, например.
Linq to Collections четко определяет порядок вычислений. И использует чисто функциональные примочки — функции высокого порядка, например. Linq To SQL же использует несколько другую фичу — expression trees, которые потом транслируются в SQL-запросы. Так что в C# есть элементы и декларативные, и функциональные.
Насчет кривой обучения — да, опыт дает очень много. Но не нужно преуменьшать роль инструмента. На прошлом проекте приходилось писать и на C#3.0, и на C#1.0 в разных местах. При чем пришлось в одном месте алгоритм переписывать с C#3.0 на 1.0. Разница очень заметна.
Я говорил по собственным ощущениям, очевидно что как-то измерить это проблематично.
Ощущения от того, что алгоритмы средней сложности, часто встречаемые в бизнес-приложениях, на LINQ пишутся раза в 2 быстрее, в 2-3 раза компактнее по коду, менее подвержены ошибкам и, особенно, ляпам, а также в разы проще модифицируются.
Плюс лямбды позволяют делать всякие интересные легковесные архитектурные решения без оверхеда.
Я не могу сказать сколько это приносит в итоге процентов, но недооценивать их я бы не стал.
А что аналитики угадали сроки — это, конечно, хорошо, но в сроках масштаб погрешности гораздо больше 5%.
Не забыл, действительно есть заметный прирост. Не в разы, конечно, но сильно ощутимый. Ты же не думаешь что дженерики и лямбды в C# просто для пиара добавили?
Берем команду .net-чиков, активно работающих на .net 3.5 и пересаживаем всех на VBA. Или даже просто держим народ с 2005-го года на первом дотнете. И наблюдаем как народ, начиная с самых толковых, сначала начинает сильно больше материться, а потом и вовсе расползается по другим конторам.
Я писал и на C#1.0, и на 3.0. По количеству ошибок и скорости разработки разница очень приличная, явно больше пяти процентов. А это даже не разные языки.
ИМХО заумность функциональных языков сильно преувеличена. Вон народ уже вовсю пишет лямбдами и LINQ-ой на дотнете и ничего, голова ни у кого не трескается. Скорее даже наоборот скоро все алгоритмы на циклах писать разучатся.
DiHalt — это от команд z80:
di — disable interrupt, запрещает прерывание
halt — останавливает процессор до следующего прерывания
Таким образом последовательность di; halt намертво вешает спектрум. Многие демки заканчивали именно такой последовательностью.
Так что не мудрено что ник и название демопати совпали.
Есть мнение, что они должны сами сделать первый паспорт в 16 лет, и делать новые каждые 20. После этого звонить и просить заехать забрать. Смысл вот этих вот очередей, заявлений, оплат госпошлин в банках, мне глубоко непонятен.
Я как-то искал движок, работающий и на клиенте, и на сервере (.net в моем случае). Ну, т.е. чтобы можно было, например, куски страницы делать динамическими без переписывания шаблонов. Или чтобы изначальный вариант отрендерить на сервере, а потом обновлять на клиенте.
Под .net что-то подобное можно сделать на django templates. Реализации — dojo.dtl и nDjango соответственно. Оба — сыроваты.
Copy local — опция студии вроде. И студия по умолчанию ее включает. А по-хорошему, особенно когда проектов много, им всем нужно перенаправлять output folder в одну кучу. Иначе получится эффект лавины: сборка 1 копируется в папку сборки 2, сборка 2 и сборка 1 копируется в папку сборки 3 и так далее. В результате такие солюшны собираются иной раз по 10 минут, из которых 9 уходит на копирование.
O_O А почему такое большое количество проектов в солюшне? Как показывает практика, так делать неправильно — и студия тормозит, и при загрузке проекта тормозит. Copy local, надеюсь, выключен?
import Data.IORef proc var = do c <- readIORef var writeIORef var (c + 1) readIORef var >>= (putStrLn . show) main = do var <- newIORef 0 proc var proc var proc varВыведет:
1
2
3
В C# никто не запрещает делать функции чистыми. Хотя C# и нельзя назвать функциональным языком, многое оттуда в нем есть.
Linq to Collections четко определяет порядок вычислений. И использует чисто функциональные примочки — функции высокого порядка, например. Linq To SQL же использует несколько другую фичу — expression trees, которые потом транслируются в SQL-запросы. Так что в C# есть элементы и декларативные, и функциональные.
Насчет кривой обучения — да, опыт дает очень много. Но не нужно преуменьшать роль инструмента. На прошлом проекте приходилось писать и на C#3.0, и на C#1.0 в разных местах. При чем пришлось в одном месте алгоритм переписывать с C#3.0 на 1.0. Разница очень заметна.
Я говорил по собственным ощущениям, очевидно что как-то измерить это проблематично.
Ощущения от того, что алгоритмы средней сложности, часто встречаемые в бизнес-приложениях, на LINQ пишутся раза в 2 быстрее, в 2-3 раза компактнее по коду, менее подвержены ошибкам и, особенно, ляпам, а также в разы проще модифицируются.
Плюс лямбды позволяют делать всякие интересные легковесные архитектурные решения без оверхеда.
Я не могу сказать сколько это приносит в итоге процентов, но недооценивать их я бы не стал.
А что аналитики угадали сроки — это, конечно, хорошо, но в сроках масштаб погрешности гораздо больше 5%.
Я писал и на C#1.0, и на 3.0. По количеству ошибок и скорости разработки разница очень приличная, явно больше пяти процентов. А это даже не разные языки.
di — disable interrupt, запрещает прерывание
halt — останавливает процессор до следующего прерывания
Таким образом последовательность di; halt намертво вешает спектрум. Многие демки заканчивали именно такой последовательностью.
Так что не мудрено что ник и название демопати совпали.
Под .net что-то подобное можно сделать на django templates. Реализации — dojo.dtl и nDjango соответственно. Оба — сыроваты.