Советы по изучению декларативных языков программирования?[закрыто]

Question

Вопрос

Как уже говорилось, есть ли у вас какие-нибудь советы, которые помогут понять/понять/осмыслить декларативные языки программирования?

Или это просто тот случай, когда вам нужно погрузиться в язык и его синтаксис, пока он не проникнет внутрь, пока не наступит тот золотой момент, когда вы Возьми.На самом деле это не вариант, так как я больше не могу запираться в комнате целыми днями, прочитывая полдюжины разных книг по данной теме (обязанности такие, какие они есть, и все такое).

Итак, есть ли какие-нибудь советы или приемы, которые помогли вам при изучении декларативных языков, какие-нибудь идеи, которыми можно поделиться?

P.S.Я лично поддержу первый ответ, в котором говорится: «Заткнись и работай”.

Фон

Мне было 13 лет, когда я впервые начал писать код (базовый, на своих сестрах). Орик-1).

С тех пор я работал со многими новыми концепциями и разными языками, воспринимая все спокойно и достаточно быстро одерживая верх.Объектная ориентация?Не беспокойтесь.Парадигмы, управляемые событиями?Выкури мне копченую рыбу, я вернусь к завтраку.

Сова, Mfc, ActiveX, Vb3, 4, 5 и 6, VB.Net, Паскаль, Delphi, C, C++ и C#.Никто не стоял у меня на пути, по крайней мере, не очень долго.

Однако недавно мой идеальный результат немного пошатнулся.

Пару недель назад я погрузился в Xaml, и ребята, я скорее тону, чем плыву.

Я думаю, что моя главная проблема в том, что это декларативно.Все остальные мои навыки программирования являются процедурными.Я уже сталкивался с этим блоком раньше, работая с MSBuild, я могу скопировать примеры того, как заставить работать MSBuild, но буду потерян, собирая что-то с нуля.

Возвращаясь к Xaml, сейчас я схожу с ума, пытаясь привязать триггеры к свойствам и получить нужный мне эффект.

Возможно, вскоре я опубликую здесь свой конкретный вопрос по Xaml.А сейчас я задаю общий вопрос о «декларативном программировании».

P.S.Нет, на самом деле я не такой дерзкий.Да, я чертовски споткнулся, когда впервые наткнулся на OO и впервые написал пользовательский интерфейс, управляемый событиями (VB3 в Windows 3.11).

Редактировать

Это начинает осознаваться, упорство, благодаря которому я зашел так далеко в этой области, окупается. просто это занимает так много времени на гидроразрыв!

...Я думаю, что я слишком стар для этих вещей...:)

Answer 1

Мне пришлось преподавать XSL (или XSLT, как хотите) в начале века :), и это действительно другой мир.Это, однако, является основой для смены парадигмы:вы должны понимать, что декларативные языки действительно разные.Самый важный совет, который я могу дать, — продолжать изучать решения других людей, работать над ними и действительно попробуй перестать думать в ПОТОКЕ.Хуже всего то, что в XSL есть «если» и «еще», но обычно есть другой способ сделать что-то.

В отличие от изучения ОО, в XSL (или, я полагаю, в любом декларативном языке) вам не удастся сделать то, что вы пытаетесь сделать, если вы не сделаете это декларативно.

Таким образом, ответ отчасти заключается в том, «заткнись и делай работу», как вы предлагаете, но более важным моментом является осознание того, что большая часть работы связана с изменением парадигмы.Итак, настоящий ответ таков: «следите за сменой парадигмы». Вы должны перестать думать в потоке и начать думать с точки зрения правил, которые могут действовать в любом порядке...если они все сделали правильно, не имеет значения, когда они выстрелят.Когда вы, наконец, думаете о правилах, а не о том, КОГДА что-то происходит, вы начинаете чувствовать сдвиг.

Answer 2

Найдите несколько примеров с объяснением «почему» от человека, который действительно знает язык.Именно изучение шаблонов и идиом имеет значение.

Я подозреваю, что вы пытаетесь делать императивные вещи в декларативной стране, а это значит, что вы мыслите в рамках шагов.Запишите поток данных в виде требуемых входных данных + функцию этих входов без сохранения состояния и посмотрите, поможет ли это.

Попробуйте функциональный или функциональный язык, например ML или Scheme.

Answer 3

Я не знаю, каковы ваши конкретные проблемы с Xaml (и я сам им не пользовался), но я обнаружил, что при использовании технологий на основе XML, таких как XSLT, небольшой опыт работы с LISP или Scheme может иметь большое значение.Возможно, вы захотите поиграть с отличной системой схем, доступной бесплатно на http://www.plt-scheme.org.

Answer 4

Я понимаю, что это может поразить вас.Все перечисленные вами языки действительно очень похожи (процедурно).

Как только ты это запишешь, я высоко призываю вас изучить функциональный язык также.Вам также может показаться, что это сложно, но изучение этого значительно поможет вашим общим навыкам программирования.У вас появится целый набор новых трюков (даже в процедурных языках), и вы больше никогда не будете бояться рекурсии.

Answer 5

Рассмотрим свой любимый «невежество программиста» — любимая мозоль.Первый фрагмент кода, очевидно, процедурный.Во втором фрагменте вы сделать декларативное заявление что для того, чтобы процент был действительным, он должен находиться в диапазоне от 0 до 100.

Так что, я думаю, у вас не возникнет проблем с изучением декларативных языков программирования, если вы будете над этим работать достаточно усердно... к геометрии нет королевской дороги

Answer 6

Как и Binary Worrier, я имел большой опыт работы с такими вещами, как C, C++, MFC и т. д., и постепенно осваивал XAML, WPF и C#.У меня было дополнительное знакомство с HTML, Javascript и XSLT, которое, я думаю, очень помогло мне подготовиться к XAML.

Основная идея XAML довольно проста: все дело в том, что вы показывать, не то, что ты делать.Самое сложное в XAML заключается в том, что нужно изучить массу деталей реализации, и вам придется изучать их все одновременно, чтобы иметь возможность сделать многое.

Вероятно, я мог бы быть более полезным, если бы вопрос был более конкретным.

Answer 7

«Программирование – это предоставление компьютеру последовательности инструкций».

Большинство программистов отнеслись к этому заявлению невозмутимо.Это почти как..."да?"

Но именно вера в это утверждение вызывает у людей проблемы с пониманием других парадигм программирования.Его нет правда, и не было уже очень давно.Чтобы лучше понять программирование, многим может быть полезно задуматься о том, почему это утверждение неверно.

Даже если вы программируете на чистом ассемблере, современные процессоры будут переупорядочивать ваши инструкции, выполнять прогнозирование ветвей и пытаться одновременно выполнять несколько потенциально взаимозависимых инструкций.Таким образом, они мыслят в терминах логических зависимостей, а не последовательностей.Метафора последовательности — это ложное представление о том, что инструкция логически зависит от всего, что ей предшествовало.Если бы это было правдой, лучшим способом рассуждать о программах было бы изучение потока управления.Но это неправда.

Под эту метафору не подходит не только декларативное программирование, но также параллельное и асинхронное программирование.

Answer 8

Я считаю, что самый простой способ «понять» язык — это просто начать использовать его исключительно для всего вашего кода.Что касается совершенно нового языка, я бы сказал, что кривая обучения для меня составляет примерно 2 недели программирования по 4-5 часов в день.После этого момента внезапно «щелкает», и вы можете начать меньше полагаться на руководства и документацию.

Answer 9

Я посещал курсы в колледже (языки программирования).Было такое ощущение, будто я постоянно бился головой о кирпичную стену, но примерно на 3/4 урока я понял, что стены больше нет;Несколько недель я бился головой ни о чем.Это было довольно сюрреалистическое чувство.

Я думаю, что любой другой способ не будет иметь такого же очарования.Читайте Гёделя, Эшера, Баха;много слушаю Эмерсона, Лейка, Палмера и Кайхосру Сорабджи;выкури немного ганджи и потрать время.