Programming languages and thinking styles (incl. AS vs. NT)

Post Reply New Topic

I have worked with a number of programming languages over the years. My very first was C, though I barely studied it at the time (not long enough to learn pointers, for instance). Then I learned Java, in college I took a class using a LISP dialect called Scheme, then I learned Python, and then lately for some work-related things I've had to learn some R.

To me, it seems that languages like R and Python (especially the former) are fundamentally designed for a different kind of programming mindset than the other languages I had learned earlier. I would call it a "more social" or "more NT" style, because much more of the time is spent thinking about how someone else thought to implement something, and how to copy that as closely as possible. There are a LOT of functions already built in, a huge speed advantage to using them for even simple tasks as opposed to writing something yourself using the basic control flow tools provided, and the relationship between the syntax and the performance (or even sometimes the outcome) is not governed by simple rules. In contrast, in more traditional language, the most time is spent thinking about how to arrange instructions in time or data in memory to make things efficient, which can be predicted from a rather small set of first principles (e.g., passing objects by reference avoids making copies, allocating a fixed size array is more efficient than dynamically growing one, etc.).

Of course, the languages don't HAVE to be used in the "most idiomatic" way all the time. It's certainly possible, provided that the task is not too computationally demanding, to "write C in Python", which I do quite often when playing around with math, sort of like how BASIC would have been used decades ago. Things are done in procedural loops and if statements, without much use of dictionaries, object orientation, etc. Some Pygame games are also made like this. It's also quite possible to have a C++ program that consists largely of a number of calls to external libraries, is full of highly generic code that hides the implementation of things, etc. However, there is generally a different style that is encouraged by the way the languages are designed.

I can't help but think that the rise of languages like Python and R has something to do with the fact that more "normal people" are getting into programming, people who don't have a traditional "programming mindset". They think more naturally in terms of following a "template" created by others rather than how to translate a mental model of a complex process into a sequence of operations. They already think like others, so the capacity to write their own different implementation of something from scratch is not a feature they place much if any emphasis on. What do you all think?

It's nice that you're using more polite language to reflect the people that think Python is a well-designed language.

To an extent you're right, if you can't easily keep track of white space, then Python is going to be more of a nightmare than it needs to be. Most of the stuff that I see people pointing to as making the language easier, are dumb things that shouldn't be necessary. It's stuff like the lack of curly braces and forcing formatting, both of which shouldn't really take very long to learn compared with the actual work of knowing what you want to do and how to reflect that with the correct code.

Personally, I prefer a language that spells more of the stuff out, especially with modern IDEs being able to handle the tedious bits like ensuring that grouping symbols be closed and autocompletion.

I would hazard a guess that you've never taught an intro computer science course and never had to grade thirty students' programs with lousy indentation.

There's a reason why teachers (of whatever subject) tend to make such a big deal about standardized style in the visual appearance of an assignment: Without rigid adherence to standardized style/format guidelines, it takes much longer for the teacher/grader to visually scan and grade the assignment. Busy adjuncts and grad assistants just don't get paid enough to deal with this.

So it's no surprise that computer science teachers would fall in love with Python as a first language. Other languages can be taught later, after the student has learned to indent properly.

On the other hand, from the point of view of the student's ability to learn, a big advantage of Python over, say, Java, is Python's absence of boilerplate for simple programs. In Java, even the simplest "Hello world" program requires a class and a main method. In Python, it's just one line.


In my experience, students learn best by first writing very simple programs in a very simple environment, without an IDE. They can then use IDE's later, to become more productive when writing longer programs.

This has been happening since the 90's, and it doesn't have anything to do with the languages or the social tendencies of the programmers.

What is happening is that people in the field are nowadays more concerned about what people will think of their solution than they are in accomplishing their task. You must now demonstrate your mastery of doing complex things, rather than solving actual problems. "Best practices" is to use a set of features and tools and techniques? Then you better do it that way, even if the task doesn't call for it, because if someone looks at your code and you haven't demonstrated an ability to use those tools and features in the prescribed way, then you must not know what you are doing.

The result is that things that used to be simple are no longer simple. It used to be that a simple solution was considered clever. And it was helpful, because compute resources were limited. Now, a complex solution is necessary to demonstrate mastery.

I would argue that JavaScript represents the most extreme example of this tendency - why write a function to determine whether a number is odd when you can just download and import an entire package https://www.npmjs.com/package/is-odd to do it for you?

There's two separate threads of thought I think you've touched on I'll try to separate.

The first is a tendency to search for tools or existing solution instead of writing and implementing something yourself. This is a reasonable strategy to produce working code when you happen to be using a language or set of frameworks that support it. Python is at one extreme end of the spectrum here - it's got such a massive community, long history, and well-developed tooling that if you have a problem, it's likely that someone else has already written something to do it. It's a less useful strategy when you're using a language that doesn't (for example, Golang), or when you're simply trying to learn how to write software. I would argue that these are simply different strategies, and I've always found myself personally more drawn to understanding how to implement something myself from the electrons up. Maybe that's an autistic thing - I don't know :p Definitely fits into the "special interest" category.

The second thread has to do with the level of abstraction of programming languages, and choosing an appropriate level of abstraction for the problem you are tackling. Back in the day, everything was "written" in terms of wires - you had to physically change the connections of these primitive "programs" to modify them. You needed an intimate understanding not just of computing, but electrical engineering. Then we moved up a level to writing things in "binary" - in the form of punchcards. You now need less electrical engineering understanding, but you had to keep track of every bit in your program. Then we had assembly, which abstracted away these ones and zeros into operations on data in registers. Then we had compiled languages like C, and now we have interpreted languages like python. They allow for the same idea to be expressed in fewer lines of code, and for programmers to concern themselves less with the how and more with the what.

I do agree that these languages in some way reduce the barrier to entry for programming - a lot of it just becomes working off others' templates. Again, JavaScript and web development comes to mind as the epitome of this. However high-level languages also introduce abstractions which can make programming *more* difficult but also more powerful. Python's type system, for example, is pretty darn intellectually meaty, as are the concepts of first-class functions, decorators, metaclasses, multiple inheritance, asynchronous programming, and many other concepts that lower-level languages lack. My two cents is that the rise of LLMs will actually force software engineers to think less about implementations and algorithms and more about architecture and design. GPT-4 writes about 70% of my code and tests these days, and that number is only gonna go up p I suspect the ability to handle complexity and understand how things work will always be valuable, but we as software engineers will likely continue to be pushed up more levels of abstraction in the future.

Lisp.

Lisp thinks like I do.

But it is hard to find a job doing lisp.

I find OO languages to be very different than the way I think.

I like a REPL and a terse language.

I like Oracle SQL and awk.

For some reason on code interviews C lang is the easiest for me to recall without looking things up. Even though I have not done C professionally for years.