Здравствуйте, Voivoid, Вы писали:
V>Здравствуйте, Максим, Вы писали:
М>>Как думаете, более глубокое изучение функциональных парадигм и языков (haskell, ocaml или что-то подобное) поможет в этом? Там все таки система типов гораздо серьезней проработана... Или пустое это?
V>Опыт работы с функциональными языками считаю значительно поможет, т.к.
V>1) Частичная специализация в C++ это по сути тот же pattern matching в функциональных языках ( точнее частичная специализации это даже круче чем pattern matching, это унификация, как в prolog'е )
салют коллега. у меня любимый вопрос на собесах — что общего между SFINAE и жадностью.
V>2) Шаблонное метапрограммирование иммутабельное, как в чисто функциональных языках
вы имеете в виду что нельзя сделать i=i+1 ? like of prolog? надо понимать, что С++ образовался, и надо сказать образовывается как .. как jazz. у меня коллега джавист высказал фразу, что шаблонное программирование (имеется в виду рекурсивная инстанциация шаблона) была открыта как остров. ) да замечательно.
V>Конечно знакомиться с этими концепциями можно начинать и на C++, но это будет куда как сложее и менее продуктивно,
вы много назовете проектов, где будет такая возможность? если мы говорим о профессии. эо должно очень повезти, чтобы тебе на проекте позволили найти выделенный scope, чтобы внедрять что-то написанное на haskell, rust etc..
V>чем если сразу начинать с haskell'а. При этом глубоко изучать haskell ( ну или любой другой чисто функциональный язык ) не надо, достаточно вот этих двух концепций — иммутабельность и паттерн-матчинг. Ну и про унификацию в prolog можно после этого чутка почитать, чтобы понять чем он от pattern матчинга отличается.
я предлагаю таки учить это на практике, именно на практических задачах, чтобы ты видел как оно взлетает
Re[3]: Философско-практические вопросы про метапрограммирование
Здравствуйте, ботаныч, Вы писали:
Б> вы имеете в виду что нельзя сделать i=i+1
Да, но в первую очередь конечно иммутабельные структуры данных и алгоритмы. Те же typelist'ы, краеугольный камень шаблонного метапрограммирования, это стандартная структура данных в haskel'е. Без базового знакомства с функциональным программированием я практически уверен, что будет совершенно непонятно почему все именно так и что вообще со всем этим можно делать.
Думаю никто не будет спорить, что код на haskell
data List a = Nil | Cons a (List a)
map _ Nil = Nil
map f Cons(head, tail) = Cons(f(head), map(f, tail))
понятнее и легче воспринимается чем аналогичный код на C++
Тем более что по haskell куда больше книг и туториалов( по сравнению с материалами по шаблонному метапрограммированию ). А стоит ли говорить про сообщения об ошибках? По c++ ошибкам в таких делах будет практически невозможно понять что вообще нет так, что особенно фатально, когда только начинаешь со всем этим знакомиться.
Б> вы много назовете проектов, где будет такая возможность? если мы говорим о профессии. эо должно очень повезти, чтобы тебе на проекте позволили найти выделенный scope, чтобы внедрять что-то написанное на haskell, rust etc..
Так а зачем это в рамках рабочих проектов делать? Мне видится, что достаточно просто часов 20-30 потратить на базовое знакомство с haskell'ем, необходимости что-то в production'е на нем делать нет никакой.
Б> я предлагаю таки учить это на практике, именно на практических задачах, чтобы ты видел как оно взлетает
Это ж не rocket science, там ж не прям что-то такое, чего нельзя было бы осилить за 1-2 недели неспешных экспериментов с учебными примерами.
Re[3]: Философско-практические вопросы про метапрограммирование
Здравствуйте, Максим, Вы писали:
М>Спасибо большое! А вот эти std::false_type/std::integral_constant они как-то на уровне компилятора реализуются (в том плане, что программист их написать не может используя просто конструкции языка)?
Есть такой ресурс — http://en.cppreference.com/w/
там часто приводятся типичные/упрощённые/эквивалентные определения всяких вещей "просто используя конструкции языка".
Здравствуйте, Кодт, Вы писали:
К>Есть такой ресурс — http://en.cppreference.com/w/ К>там часто приводятся типичные/упрощённые/эквивалентные определения всяких вещей "просто используя конструкции языка".
С возвращением! Ты насовсем вернулся?
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[5]: Философско-практические вопросы про метапрограммирование
вот прежде всего, я собирался писать совсем другой пост, о он вышел как вышел .. а сейчас, я попытаюсь высказать квентиссенцию ..
простота разрабатываемых в хацкеле тайплистов лучше вероятно, чем изобретенных в С++
V>Здравствуйте, ботаныч, Вы писали:
Б>> вы имеете в виду что нельзя сделать i=i+1 V>Да, но в первую очередь конечно иммутабельные структуры данных и алгоритмы. Те же typelist'ы, краеугольный камень шаблонного метапрограммирования, это стандартная структура данных в haskel'е. Без базового знакомства с функциональным программированием я практически уверен, что будет совершенно непонятно почему все именно так и что вообще со всем этим можно делать.
V>Думаю никто не будет спорить, что код на haskell V>
V>data List a = Nil | Cons a (List a)
V>map _ Nil = Nil
V>map f Cons(head, tail) = Cons(f(head), map(f, tail))
V>
V>понятнее и легче воспринимается чем аналогичный код на C++
это выглядит как мотив. мотив для вас ) вам не нравится С++ в этом, в котором собственно метапрограммирование было не спроектировано, а открыто "как остров" (хотя сфинай). я относительно недавно доказал себе, что эппроач реализуем, я реализовывал в с++ ограниченный синтаксис регекпов (с компиляцией компайл тайм строк), с довольно шустрой рантайм мoделью. ну я понимаю, до этого я подобным занимался в других масштабах, но я просто доказал себе, что это реализуемо, инородный синтаксис в С++, но вы можете реализовать тоже самое, в С++ довольно недолго, если вопрос касается тайп листов — мгновенно. вопрос куда это все лепить? о тайп листах кстати
они сейчас такие
template <typename ... > struct type_list;
главное для чего все это? где это в практике применить?
я знаю, где такое применимо .. — в коде который писался десятилетия разными программерами. с разными, почти всегда олдовыми концептами. где размер кода зашкаливает. и над принять решение, когда паутина архитектуры строится с таким дикими изначально приближениями о том, что этот концепт таки удовлтворителен для использемых его кейсов.
V>Тем более что по haskell куда больше книг и туториалов( по сравнению с материалами по шаблонному метапрограммированию ).
да, потому, что ) всегда так бывает ))
V> А стоит ли говорить про сообщения об ошибках? По c++ ошибкам в таких делах будет практически невозможно понять что вообще нет так, что особенно фатально, когда только начинаешь со всем этим знакомиться. невозможно вопрос — спорный (и где? gcc msvc?)
Б>> вы много назовете проектов, где будет такая возможность? если мы говорим о профессии. эо должно очень повезти, чтобы тебе на проекте позволили найти выделенный scope, чтобы внедрять что-то написанное на haskell, rust etc.. V>Так а зачем это в рамках рабочих проектов делать? Мне видится, что достаточно просто часов 20-30 потратить на базовое знакомство с haskell'ем, необходимости что-то в production'е на нем делать нет никакой.
))) 20 30 ). кошмар. ну у меня на знакомство с перл (исключительно в рамках базовой задачи) ушло 2- часа. я почему-то так и прочитал ваше 20-30. откуда у меня 20-30. для чего?
Б>> я предлагаю таки учить это на практике, именно на практических задачах, чтобы ты видел как оно взлетает V>Это ж не rocket science, там ж не прям что-то такое, чего нельзя было бы осилить за 1-2 недели неспешных экспериментов с учебными примерами.
в одном из своих проектов я как-то ляпнул с дуру, что в принципе я бы понял
Здравствуйте, ботаныч, Вы писали:
Б> ... вопрос куда это все лепить? о тайп листах кстати Б>они сейчас такие Б>
Б>template <typename ... > struct type_list;
Б>
Б>главное для чего все это? где это в практике применить? Б> я знаю, где такое применимо .. — в коде который писался десятилетия разными программерами. с разными, почти всегда олдовыми концептами. где размер кода зашкаливает. и над принять решение, когда паутина архитектуры строится с таким дикими изначально приближениями о том, что этот концепт таки удовлтворителен для использемых его кейсов.
Например, я использую такое, кроме прочего, для "автоматизации работы с АПИ"
Пример его использования, для описания API некоего "объекта Future", состоящего из неких "свойств" и "методов": https://github.com/vopl/dci-core-qml/blob/master/include/dci/qml/qmeta/def/cmtFuture.hpp#L94
далее этот лист (вместе с листами остальных "объектов") просовывается в qml и там можно объект Future использовать, работать с его свойствами и методами. Если бы эти АПИ проводить не через лист — пришлось бы изыскивать какие то другие средства для представления "набора сущностей", как например в Qt делается за счет ее мета-подсистемы. В общем, с тайплистами — получается вполне удобно. И весьма по сиплюсплюсному — максимум работы проделывается в компайл-тайм, а на рантайм остается только необходимый минимум.
Re[6]: Философско-практические вопросы про метапрограммирова
Здравствуйте, ботаныч, Вы писали:
Б> я понимаю, зачем нужньі тайп листьі в С++. я задавал применимо к хацкелю.
хацкель затем чтобы познакомиться с иммутабельными рекурсивными структурами данных и алгоритмами, паттерн матчингом и алгебраическими типами данных не отвлекаясь при этом на чисто c++'ные проблемы неизбежно возникающие при попытке все вышеперечисленное использовать