How languages affect thinking:

[Peter Gibbons]

If you search for "How languages affect thinking" you will find many articles that talk about the subject.

I also subscribe to the idea that computer languages affect the way we think while programming.
Here two example programs that do exactly the same thing:


Java:

Code: [Select]

import java.lang.*;
import java.util.*;

public class Cities {
    public Cities() {
        List<String> cities = new ArrayList<String>();
        cities.add("Paris");
        cities.add("London");
        cities.add("Tokyo");
        cities.add("New York");
        cities.add("Toronto");

        List<String> citiesWithT = new ArrayList<String>();
        Iterator<String> iter = cities.iterator();
        while (iter.hasNext()) {
            String city = iter.next();
            if (city.startsWith("T")) {
                citiesWithT.add(city);
            }
        }

        Iterator<String> iter2 = citiesWithT.iterator();
        while (iter2.hasNext()) {
            String city = iter2.next();
            System.out.println(city);
        }
    }

    public static void main(String[] args) {
        new Cities();
    }
}


Scala:

Code: [Select]

object Cities {
  def main(args: Array[String]) {
    var cities = List("Paris", "London", "Tokyo", "New York", "Toronto")
    var citiesWithT = for (city <- cities if city.startsWith("T")) yield city
    for (city <- citiesWithT) println(city)
  }
}

The Scala program is also strongly typed however since the types are inferred the code is not littered with <String>

The second line of the main method in Scala is the most interesting.

It just says: "Build a new list from the original that contains only the elements that start with 'T'"
(Python has this feature too - List comprehensions - and also allows very succinct programs.)

It's quite different from the original program where we iterate over the original list, test every item to see if it starts with 'T' and if it does add it to the new list.

Basically the idea of functional languages is to tell the computer what to do - not how to do it.

SQL is functional:

select * from employees where name = 'peter'

but SQL is not general purpose language and without the vendor specific extensions is somewhat limited in what it can do.

By the way - not only is the Scala program much shorter - the Scala List class has much more powerful methods that allow further modifications to be made more easy and done with fewer lines of code.

Speaking about expressiveness:
Ruby and Python are also very expressive languages that will allow programs to be just as short.
However they are dynamically typed and much slower even in the case of Jython and JRuby when running on the JVM. In contrast Scala is almost as fast as Java.

By the way I remember when I switched from Turbo Pascal to C one of the things I really liked was the fact that I don't have to type BEGIN and END for every block of code. {} is much nicer.

Of course Python is the best in this respect. Just use the indentation to delimit the blocks.
Brilliant idea - that's why Python code looks so clean and simple.

The lack of "language noise" really must affect the programmer - allowing more clear thinking about the business problem that must be solved.

COBOL is on the other end of the language spectrum.
I wrote couple of very small school projects using modern version of the language and coming from C background COBOL killed me with it's verbosity.

Yes COBOL works great for banks and insurance companies but have you heard of a startup using COBOL?

So I guess not only the languages affect thinking but they also affect the culture of a company.
Or maybe it's the other way around?

Why all this matters?

I believe writing your ISV/startup product in language that is short and to the point will give you the ability to allocate much more time to marketing and other important business related activities.

[Walter Mitty]

Another language that is quite succinct yet powerful when it comes to specifying inclusion criteria is SQL.  It's also succinct yet powerful when it comes to specifying join conditions.  And the join is just so powerful that it's difficult to describe to somebody that's never done one.

I've learned maybe about 8 languages up some level of proficiency over the course of almost 50 years.  What's really embarassing for me is to look back at my first efforts with a language that's new to me.  I tend to code in the new language, using the "idiom" of a language I already know.  The result is awkward at best.

[Peter Gibbons]

To be honest Walter - I have not done any joints.

But I have heard that they are indeed very powerful.

[The Gorn]

Gee, doesn't Java's container and iterator operations look like STL containers and iterators in C++!

Gawrsh! I wonder why thay're thah same?

Golll-lleeee. *

</obviousman>



* Use Gomer Pyle style speech patterns for authenticity in reciting this.

[Origisaurus]

Gee, doesn't Java's container and iterator operations look like STL containers and iterators in C++!

Gawrsh! I wonder why thay're thah same?

Golll-lleeee. *

</obviousman>



* Use Gomer Pyle style speech patterns for authenticity in reciting this.

Shaza'am !

[Peter Gibbons]

I thought you guys are going to catch my joke

And the join is just so powerful that it's difficult to describe to somebody that's never done one.

To be honest Walter - I have not done any joints.

I guess I have no choice but continue writing code

[The Gorn]

Sometimes with what gets written on this board I wonder what people are smoking...

[Walter Mitty]

If you search for "How languages affect thinking" you will find many articles that talk about the subject.

Basically the idea of functional languages is to tell the computer what to do - not how to do it.



SQL is functional:

select * from employees where name = 'peter'

but SQL is not general purpose language and without the vendor specific extensions is somewhat limited in what it can do.

SQL is intended to be used in the context of access to a database.  Languages like PL/SQL extend the language to cover much more of the space that a general 3GL type language covers, but it's still a database language.

By the way - not only is the Scala program much shorter - the Scala List class has much more powerful methods that allow further modifications to be made more easy and done with fewer lines of code.

shortness of source code, within limits, is one of the less important points of comparison, IMO.

By the way I remember when I switched from Turbo Pascal to C one of the things I really liked was the fact that I don't have to type BEGIN and END for every block of code. {} is much nicer.

Don't get me started on syntactic preferences between languages.  Ultimately, it just a case of de gustibus non disputandum est.

Yeah, sure, the open and close brace is easier on the eye than "begin" and "end".  On the other hand, the requirement to put a semicolon before the close brace is simply moronic.  It was bad language design in 1970, and it's still bad language design in 2011.  Any parser worth its salt should be able to figure out that the end of a code block implies the end of the last statement contained in the block.

The semantics of a language are more important than the syntax, and there are two considerations that are more important than both of them.

The first one was pointed out by gorn some years back.  Over time, a language begins to evolve into little more than glue that binds together library calls.  The functionality of the libraries begins to matter more than the language.

The second one has to do with the programming culture, and who reads source programs,  how often, and why.  Well written code is ultimately more valuable than stuff that's just thrown together, and is lucky enough not have any compiler errors or obvious bugs.

So I guess not only the languages affect thinking but they also affect the culture of a company.
Or maybe it's the other way around?

The culture of the company, the relationship of code to the clients, the choice of languages tools and methodologies are all intimately bound up with each other.

[The Gorn]

I guess I must be some kind of utterly brilliant high level thinker.

Basically the idea of functional languages is to tell the computer what to do - not how to do it.

For years I have dealt with ALL programming languages functionally, as "functional languages". 

I believe that any decent developer is professionally obliged to learn how to do this.

The mediocre seat warming ones are those who think "in" the one language they know and never deviate. I don't even have to give concrete examples of this on this board.

For example...

I do not not really consider this:

Code: [Select]

for (city <- citiesWithT) println(city)
To be altogether THAT different from this:

Code: [Select]

        Iterator<String> iter2 = citiesWithT.iterator();
        while (iter2.hasNext()) {
            String city = iter2.next();
            System.out.println(city);
In any environment, I tend to formulate my programming like this:

"Gee, I want to operate on every element in (this list) in (this way). Order (does, or does not) matter (and if it does, here is the ordering.) I want to start (from the beginning, or from a particular element) and end (at, or one element before) the element (at the end, or, the element that fulfills this condition, or, a particular element.)"

That's how I have reasoned for about the last 15 years of programming life, really.  I find it really hard to NOT think functionally like this. I have a task. What does the damned tool provide to accomplish this task? Ok, so do it. Then move on.

Does that make me: ordinary; highly experienced; guru like; jaded; naive?

In my opinion, knuckleheads, fanbois, and newbies flounder around pontificating on the most efficient or most stylish way to implement what is just a vanilla list iteration operation.

The major difference we see in your examples appears to be that one language has more features such as knowledge of higher level constructs like lists built into it, as well as operations on those constructs like list iteration built in, than does the "procedural" language. And in the more "advanced" language there exists shorthand for routine operations like looping across an iterator collection.

I do consider something like SQL to be entirely unique because you do not think in terms of the order of execution at all there, in fact, that can often screw you up.

I grant everything you guys are saying. But, I consider it a sign of professional maturity in this industry when the developer stops thinking about every single new language with novel semantics as the Second Coming and the Epiphany.

Aside - I am not saying that you are doing this, Peter. I consider your interest research-oriented. Just that the type of programmer that, say, the body shops are looking for, for commodity temp programming positions, DOES tend to reason this way.

If you write enough code you eventually start noticing more similarities between different tools than differences. 

{ } or BEGIN END? Trifles. Use a macro replacement for things like that, you're done.

[Walter Mitty]

To be honest Walter - I have not done any joints.

But I have heard that they are indeed very powerful.

If you've never done any joins, you're really not in a position to evaluate SQL.  I hestiate to try to teach you joins in a forum.  In the first place, I don't want to give you examples without testing them, because I make mistakes.  In the second place, joins are an integral part of a whole cluster of concepts,  including but not limited to,  the relational data model, data normalization, database transactions and ACID, database design, and how databases fit into a strategic data architecture.

Teaching joins in isolation would just make you ask why anybody would want to do things that way.

Maybe some other  contributor can point to a great tutorial, if you're interested.

[Peter Gibbons]

I do consider something like SQL to be entirely unique because you do not think in terms of the order of execution at all there, in fact, that can often screw you up.

Gorn,

Scala is not purely functional. Here is quicksort in Erlang:

Code: [Select]

qsort([]) -> [];
qsort([H | T]) -> qsort([ X || X <- T, X < H ]) ++ [H] ++ qsort([ X || X <- T, X >= H ]).

Here you also don't have to think in terms of the order of execution.

1. Sorting of empty list returns empty list
2. Sorting of list with head H and tail T results in ... ...

I am not crazy about purely functional languages like Haskell. I have work to do.

However if Scala allows me to write the same code in 3 lines instead of 10 lines in Java - I will take it.

[Peter Gibbons]

If you've never done any joins, you're really not in a position to evaluate SQL.

Walter I apologize.

I have done joins. Everybody on this board must have used them.
I was trying to make a silly joke by using play of words.

Obviously I am not good at this and have to keep programming

[Peter Gibbons]

I grant everything you guys are saying. But, I consider it a sign of professional maturity in this industry when the developer stops thinking about every single new language with novel semantics as the Second Coming and the Epiphany.

Gorn,

There are about 10 Java developers around me where I work.
I am almost certain that not a single one of them has even heard about Scala - let alone even played with it.
The ones I have mentioned it to - didn't know such thing existed.

So the maturity you are talking about is already here. Shops have standardized on Java or .NET.
When I spoke to the back end services manager at Microsoft I asked him if they use F#.
He said that C# is working fine for them so they saw no reason to use anything else ...

I am really the odd man out here.

[Peter Gibbons]

I guess I must be some kind of utterly brilliant high level thinker.

I think you are

You can see value in Python after many years of using C++.

There are - I am sure - many, many C++ and Java developers that think Python is useless 'scripting' language.

"I can do the same thing in C++ / Java!"

[The Gorn]

Python felt sooo familiar after working with it a little. It has semantics (not syntax) not unlike C++, it has more advanced and useful data types useful for common data-munging, it allows true classes to be constructed, and it's relatively easy to work with (easier than C++.)

There are - I am sure - many, many C++ and Java developers that think Python is useless 'scripting' language.

"I can do the same thing in C++ / Java!"

And that thinking is the flip side of pointless infatuation with minor implementation details. Equally odious is the knucklehead who makes everything a hard, heavy duty software development exercise and who will not compromise on tools.