Вот, например, относительно Хаскеля существует мнение, что у него высокий входной порог, в результате чего сообщество состоит из квалифицированных программистов. Что же отпугивает неквалифицированных программистов от ЛИСПа, как считаете?
Если хотелки заказчиков скачут настолько хаотично, что никакой способности меняться не напасёшься, то вся аналогия в корне неверна. В противном случае текущий вид с большей вероятностью к ним уже готов, коли успешно существует продолжительное время.
На РСДН встречал такую аналогию с эволюцией: новый вид не образуется на уже занятой нише, так как в ней уже существует наиболее приспособленный вид, который не даст развиться новому. Виды образуются путём ухода в новую нишу.
Соот-но основой успеха становится выявление ещё незанятых ниш, где [пока] нет конкурентных видов.
Теперь про софт: бывает ПО, хорошо работающее здесь и сейчас. Но будет ли оно работать завтра или послезавтра?
Оно будет переписано с использованием накопленного преимущества. Зачем быть универсальным текущей версии софта или кода? Т.е. почему это необходимо?
Должна быть реализована (не QML-ем, а мной) возможность выставить обработчик по ключу. Приходилось генерировать дополнительно property key, хотя казалось бы.
пока еще QtComponents для QML не доделаны, а там как раз и есть стандартный набор управляющих элементов
Что ж, хорошо. Значит скоро дела будут намного лучше.
В своей практике я сделал выбор в сторону WPF. Стояла задача сгенерировать из одного описания GUI какое-либо другое (дабы потом показать диалог). Из-за практически идентичности языков был выбран QML. Однако наличие id только в дизайн-тайм (нельзя найти контрол по id, так как в рантайм его уже просто нет) и отсутствие стандартных контролов (я знаю про обходной способ вставки QWidget в QML, но элементы автоматом не лайаутится, надо обрамлять ещё одним элементом, до и попробуйте вставить туда QWidget'ный список, содержащий в себе другие QML-элементы; описано всё предельно невнятно), убило всю идею. На WPF же всё перенеслось за день. Не хочу говорить о QML только плохое, но создалось ощущение какой-то сырой технологии, в отличие от WPF. От него впечатления куда лучше.
А так сами сравните, десяток вложенных foreach или do
fileName <- enumDirectory "."
line <- readLines fileName
word <- words line
if word == "bla" then ... else ...
Куча проверок на null или do
f <- findSmth
r <- doSmthWith f
return (f, r)
Вызывать на каждом ходу BeginSmth с передачей callback'а, или do
f <- download "file1"
g <- download "file2"
return (length f == length g)
Вот с чем действительно у Хаскеля непорядок, так это с трансформерами монад. Они не вписываются органично и потому ExceptionalT String (StateT Int IO) a смотрится жутко.
Я придерживаюсь прямо противоположного мнения. Чего стоит впихивание в языки всяких конструкций для асинхронного ввода-вывода, тогда как это всё выражается в терминах монад.
> Если сравнить дом из 1000 брёвен и 1000 брёвен кучкой, то сложнее будет как раз последняя
> Данный пример скорее, наоборот, подтверждает обратное тому, что Вы хотите сказать
Вы противоречите сами себе, ибо я как раз хочу сказать, что сложность зависит не только и не столько от количества, и вы с этим согласились. Что именно считать сложнее (дом или кучку) — частность.
И почему-то я сомневаюсь, что при таких исходных данных, эта задача у вас вызвала бы какие-то затруднения и необходимость читать сотни статей. Разве что недоумение «какого чёрта».
Не думаю, что только мне повезло встречаться с кривыми решениями достаточно регулярно, чтобы этому не удивляться; поэтому никак не могу понять, чем же конкретно это кривое решение от МС кривее большинства остальных, что заслужило такой порки с одновременным оправданием всех тех бездарей, которые с ним столкнулись, но не справились.
У него нет недостатков, недостатки есть у нехаскель программистов!
Соот-но основой успеха становится выявление ещё незанятых ниш, где [пока] нет конкурентных видов.
Оно будет переписано с использованием накопленного преимущества. Зачем быть универсальным текущей версии софта или кода? Т.е. почему это необходимо?
Что ж, хорошо. Значит скоро дела будут намного лучше.
onAccept.А так сами сравните, десяток вложенных foreach или
fileName <- enumDirectory "."
line <- readLines fileName
word <- words line
if word == "bla" then ... else ...
Куча проверок на null или
f <- findSmth
r <- doSmthWith f
return (f, r)
Вызывать на каждом ходу BeginSmth с передачей callback'а, или
f <- download "file1"
g <- download "file2"
return (length f == length g)
Вот с чем действительно у Хаскеля непорядок, так это с трансформерами монад. Они не вписываются органично и потому
ExceptionalT String (StateT Int IO) aсмотрится жутко.> Данный пример скорее, наоборот, подтверждает обратное тому, что Вы хотите сказать
Вы противоречите сами себе, ибо я как раз хочу сказать, что сложность зависит не только и не столько от количества, и вы с этим согласились. Что именно считать сложнее (дом или кучку) — частность.
Речь не о процессорах, а о сравнении процессора и мозга. Про устройство второго мы знаем мало что.
В тред врывается Haskell-программист!
Можно ли по одному количеству судить о сложности?
Не думаю, что только мне повезло встречаться с кривыми решениями достаточно регулярно, чтобы этому не удивляться; поэтому никак не могу понять, чем же конкретно это кривое решение от МС кривее большинства остальных, что заслужило такой порки с одновременным оправданием всех тех бездарей, которые с ним столкнулись, но не справились.