Tips for grokking declarative programming languages?

Question

Question

As stated, have you any tips to help grok / understand / get-your-head-around declarative programming languages?

Or is it simply a case that you’ve to immerse yourself in the language and it’s syntax, until it seeps in, until you get that golden moment where you Get It. This isn’t really an option as I can no longer lock myself in a room for days on end, poring over half a dozen different books on the subject matter (responsibilities being what they are and all)

So, any tips or tricks that helped you when you tackled declarative languages, any insights to pass on?

P.S. I’ll personally upvote the first answer that says “Shutup and put in the work”.

Background

I was 13 years old I when I first started wring code (basic, on my sisters Oric-1).

Since then I’ve worked with many new concepts and many different languages, taking all in my stride, me taking the upper hand quickly enough. Object Orientation? Not a bother. Event driven paradigms? Smoke me a kipper, I’ll be back for breakfast.

Owl, Mfc, ActiveX, Vb3, 4, 5 & 6, VB.Net, Pascal, Delphi, C, C++ & C#. None have stood in my way, at least not for very long.

However recently my perfect score has taken a bit of a battering.

A couple of weeks ago I threw myself into Xaml, and folks, I’m more sinking than swimming.

I think my main problem is that it’s declarative. All my other programming skills are procedural. I’ve hit this block before with MSBuild, I can copy examples of how to get MSBuild things working, but would be lost putting something together from scratch.

Back to Xaml, currently I’m going insane trying to wire triggers to properties and get the effect’s I need.

I may post my specific Xaml question here soon enough. For now I’m asking this general “declarative programming” question.

P.S. No, I'm not actually this cocky. Yes, I stumbled like hell the first time I hit OO and the first time I'd to write an event driven UI (VB3 on Windows 3.11).

Edit

It's starting to sink in, the tenacity that got me this far in this field is paying off, it just takes so much fracking time!

. . . I think I'm getting too old for this stuff . . . :)

Answer 1

I find the easiest way to "grok" a language is simply to start using it exclusively for all your coding. With a completely new language I would say for me the learning curve is approximately 2 weeks of coding about 4-5 hours a day. After that point it suddenly "clicks" and you can start relying less on manuals and docs.

Answer 2

Find some examples, with explanations of the "why", from someone who really knows the language. It's learning the patterns and idioms that makes a difference.

I suspect you're trying to do imperative things in declarative land, which means you think in terms of steps. Write the dataflow down in terms of required inputs + stateless function of those inputs and see if that helps.

Try a functional or functionalesqe language like ML or Scheme.

Answer 3

I don't know what your specific problems with Xaml are (and I haven't used it myself) , but I've found that when using XML based technologies like XSLT, a little LISP or Scheme experience can go a long way. You might want to look at playing with the excellent scheme system available free from http://www.plt-scheme.org.

Answer 4

I took a class in college (Programming Languages). It pretty much felt like I was repeatedly slamming my head against a brick wall, but about 3/4 of the way through the class, I realized the wall wasn't there anymore; I had been beating my head against nothing for a few weeks. It was a pretty surreal feeling.

I think any other way won't have the same charm. Read Godel, Escher, Bach; listen to a lot of Emerson, Lake, and Palmer and Kaikhosru Sorabji; smoke some ganja, and put in the time.

Answer 5

Consider your favorite “programmer ignorance” pet peeve. The first code snippet is obviously procedural. In the second snippet you make a declarative statement that for the percentage to be valid it has to be between 0 and 100.

So i'd guess you'll have no trouble grokking declarative programming languages as long as you work on it hard enough... there is no royal road to geometry

Answer 6

I can see where this may be blowing your mind. All those languages you list are indeed quite similar (procedural).

Once you get this down, I highly encourage you to learn a functional language as well. You may also find it tough going, but learning it will help your general coding skills greatly. You'll have a whole new bag of tricks (even in procedural languages), and you will never be afraid of recursion again.

Answer 7

Like Binary Worrier, I had a long history with things like C, C++, MFC, etc and have been coming up to speed on XAML, WPF, and C#. I had a side trip through HTML, Javascript, and XSLT which I think helped a great deal in preparing me for XAML.

The basic idea behind XAML is fairly straightforward - it's all about what you show, not what you do. The hard part with XAML is that there is just a ton of implementation details to learn and you wind up learning them all at the same time in order to be able to get much of anything done.

I could probably be more helpful if the question was more specific.

Answer 8

I had to teach XSL (or XSLT, as you wish) a bunch at the beginning of the century :), and it's a different world, really. That, however, is the basis for the paradigm-shift: you have to realize that declarative languages really are different. The most important advice I have is to keep studying other people's solutions, put the work in, and really try to stop thinking in FLOW. The worst thing is that, in XSL, there is an "if" and an "else," but usually there's another way to do things.

Unlike learning OO, in XSL (or any declarative language, I suppose) you will not manage to do what you're trying to do unless you do it declaratively.

So the answer is in part, "shut up and do the work" as you suggest, but the more important point is to realize that a lot of the work is getting your head around the paradigm shift. So the real answer is, "keep your eyes peeled for the paradigm shift." You have to stop thinking in flow and start thinking in terms of rules that can fire in any order... if they're done right, it doesn't matter when they fire. When you are finally thinking in rules instead of WHEN stuff happens, you're beginning to grok the shift.