I agree that UPDATE statements in SQL are essentially imperative. But SELECT statements are definitely declarative; there’s no sequence of instructions, just a list of fields, joins, and functions which behave as filters. For example, consider a statement like
SELECT s.foo, s.bar, UPPER(s.baz), q.plork
FROM sometable s
JOIN othertable q ON q.sid = s.id
WHERE q.plotz = "farfegnugen"
There’s a lot of stuff going on here – a join between two tables, converting one column to uppercase, filtering one table to only include rows where plotz is “farfegnugen”, and so on. But the order that these things happen is determined by the query engine and not the programmer.
Obviously, this does not include SQL supersets designed for writing stored procedures, like T-SQL and PL/SQL. Stored procedures are of course procedural for the most part.
Not at all. The query is still describing what to do, not how. The imperative approach would be to tell the computer to loop over every row, check all the necessary conditions, and then make an assignment if the record matches what you’re looking for.
(I don’t want to hijack, but it’s never been quite clear to me exactly what distinction allows SQL to be a programming language but not HTML. I don’t think there is any actual set of objective criteria that will include the languages most developers want, and exclude the languages they don’t.)
But telling the computer what to do, even if not how, is still imperative, no? I’d put the distinction between declarative and imperative mainly on whether one gives the computer orders or asks the computer questions (what is the value of this function? Is this statement satisfiable?).
The book I wanted to recommend was *Java Software Solutions *by Lewis and Loftus. I used the 3rd edition (2003), but it appears they’re now up to the 6th edition (2008). Hopefully the quality has remained consistent!
You’re talking about low-level code. Yeah, functions like these look the same in any non-ancient language. Modern languages have moved on to grappling with much larger, more complex issues. The solutions to those issues will look quite different from language to language.
You may be a low-level program, and so am I, but high-level programming of GUIs, networks, multiprocessing, etc. is all a very different beast. You don’t need to have massive book learning about “algorithms” and “datastructures” for that, lol. Such low-level programming still undoubtedly matters, but it hasn’t been the mainstream since the 70s.
There was a time when C was a high-level language. Sigh.
I disagree completely. My main source of work is about as high-level as you can get, and I benefit daily from my basic CS knowledge about algorithmic complexity, optimization, and data structures. I may be writing code in a loosely-typed, OOP scripting language, but knowledge of the fundamentals informs my choices every day, almost always for the better.
Data structures and algorithms cannot be dismissed so easily, especially since making the correct choice between multiple data structures/algorithms that all do similar things often relies upon understanding how they work.
Not really, declarative programming simplistically is a description of what the inputs and outputs are, and you let the computer figure out the middle. Imperative programming requires that the programmer specify how exactly to get from input to output.
Take for example the UPDATE statement, You are telling the computer that for some relation you want the values to change in accordance to a set of rules. The input is the relation and the output is the changed relation. The query processor however analyzes your rules and figures out the best(?) way to make it happen. It may select an index based or iterative based approach depending on the keys specified and the expected number of updated rows along with other decisions that it might make.
The objective criteria is that SQL supports the generic programming constructs: sequence, selection/branching, iteration and subprocessing (functions or repeatable blocks, or in SQL’s case subqueries). AFAIK html does not, feel free to correct me, I’m not more than an HTML novice.
I don’t agree with you at all. I work with Java EE, which is about as high level as I care to get. I have daily use of knowing what datastructures to implement for best efficiency, not to mention theoretical knowledge of OO, encapsulation and programming patterns which aren’t language inherent. I spend a sizable portion of my day correcting poorly designed code by previous employees of my company who were less familiar with these concepts. The high technical debt of bad coding (which translates into real life debt in the end) is why I’m stressing the fact that simply learning a language is not enough.
Completely wrong. Correct choice of datastructures is still critical, and will probably become even more so with the widespread move to parallel/multicore programming within the next few years. What works in the Java world, for instance, doesn’t work in the essentially stateless world of Haskell or ML (see Okasaki’s PhD thesis for details on functional datastructures), and that’s where we’re heading if we are going to make any sense at all out of all these cores that are appearing within processors.
Hardly any of them, in fact. Apart from tail-call optimisation to consider, there’s also Haskell’s lazy evaluation strategy (with its pros and cons) to consider: