31–40 of 53 posts
Their apprehension of tackling code is one I don't immediately understand, but I do get that they don't want to think about the how, rather the what. It's a funny parallel.
Here's a great video by Bret Victor who saw this problem, and tried to fix it for animation:
I really like SQL. Sure, the language has warts but the ability to concisely represent WHAT you want, not HOW you want it, makes it very readable once you understand the simple constructs and how to properly design tables and indexes (not very hard). For example, consider the problem of finding the second largest value in a set. In SQL, I'd do something like: SELECT MAX( col ) FROM table WHERE col It's pretty readabl…
Aside: Python is similar to Ruby, albeit using the sorted() function rather than the sort() method. sorted(vals)[-2]
Earlier quoted context omitted.
Aside: Python is similar to Ruby, albeit using the sorted() function rather than the sort() method. sorted(vals)[-2]
The pedant in me squirms at seeing a quadratic-time solution to something so linear. Use a heap or a scan, sir!
Prolog is declarative programming take to the maximum (excluding things like Answer Set Programming/clingo etc). In Prolog you ask questions. For example: subset([1,2],[2]). then it goes away and says "yes". Or you want to know if any subsets exist: subset([1,2],B). B = [] B = [1] B = [2] This makes it really really nice for some surprising tasks (Windows NT used to ship with a prolog interpreter for setting up the n…
Ooh, I forgot all about prolog! I worked through the 7 languages in 7 weeks book, and solving a sudoku with prolog blew my mind. I think the first "real" programming I did was a sudoku solver in Excel and VBScript (yeuch).
Its fairly trivial to write a checkers AI in prolog if you can define what you want + need:
Earlier quoted context omitted.
The pedant in me squirms at seeing a quadratic-time solution to something so linear. Use a heap or a scan, sir!
Oh, now I have to yell at myself. No doubt Python's sorted is some n*logn quicksort, and not actually in quadratic time. Crow for all!
It is not just as programmers. Consider, most cookbooks. Then consider the directions that come with Ikea furniture. Of course, the real beauty of both of those examples, is that they are a mix of declarative and imperative instructions. For some reason, it seems we programmers are adamant that it must be one or the other. Consider all of the examples, either purely imperative or purely declarative. Why not both?
Ideally, we would all write programs by assembling declarations, imperative code would be limited to internal implementations. That's largely the reason it's good practice to abstract away implementation behind APIs - what you have left is almost a pure declarative language, or DSL, that maps 1:1 your problem domain, without looping or branching or I/O (which are computation details). Taking the example from the orig…
elements = [1,2,3,4];
doubledElements = doubleElements(elements)
Of course, in the cooking methaphor, I'm ok with mutating elements and just doing:
elements = [1,2,3,4];
doubleElements(elements);
Step #2 is doing whatever is necessary to make that code work. Sometimes this means using the more interesting stuff like reflection, dynamic objects, expression tree visitors, etc. but I find that subsequent issues keep getting easier to deal with. This is because step #1 is naturally building a DSL for your problem domain and you start to find that what you did in step #2 is quite reusable.
I've been programming for a while, so I have experience with the imperative, "write the code that solves the problem" approach and it works too, but I am having fun with the "write the code that describes the problem" approach more.
Just my two cents.
Earlier quoted context omitted.
so what would be declarative programming ? does it even exist? i mean, at some point you need to write some logic , and logic is imperative. Let's take a html file. It is declarative. but the underlying logic is written somewhere else. so you cant really have pure declarative programming? if it is possible how ?
An evaluation strategy is imperative but the logic that the strategy operates on doesn't have to be.
Earlier quoted context omitted.
The pedant in me squirms at seeing a quadratic-time solution to something so linear. Use a heap or a scan, sir!
Oh, now I have to yell at myself. No doubt Python's sorted is some n*logn quicksort, and not actually in quadratic time. Crow for all!
Earlier quoted context omitted.
Ideally, we would all write programs by assembling declarations, imperative code would be limited to internal implementations. That's largely the reason it's good practice to abstract away implementation behind APIs - what you have left is almost a pure declarative language, or DSL, that maps 1:1 your problem domain, without looping or branching or I/O (which are computation details). Taking the example from the orig…
And, see, I would actually invert further. The declaration should be: elements = [1,2,3,4]; doubledElements = doubleElements(elements) Basically, if you see the words map, fold, reduce in your code, you are probably not as easy to understand as you'd like to think. Of course, in the cooking methaphor, I'm ok with mutating elements and just doing: elements = [1,2,3,4]; doubleElements(elements); This clearly has issues…
But then you lose pureness, right? The whole point of using high-order functions is allowing you to be as declarative as mathematics, so you can just operate functions together.
Consider that in the first example, I only need to write the implementation for doubling a number n, while the `doubleElements` implementation is too specific, would throw the other half of the code back into imperative land.