-
Languages like C and Pascal don't really do less than a language like Python (because you can write Python in C).. they just make you type more. I don't think it's creative at all, just redundant.
-
One might similarly talk of how restrictions in spoken languages lead to different creative exercises in communication - though no human tongue is as restrictive as the most open programming language.
Most of what you're running into are differences in *expressive* power - you're always writing less than you're thinking (your writing may be more rigorous, but always less abstract) about the problem at hand - the question is just how far you have to go to actually talk to the machine, and what do you leave out of what the next programmer needs to see.
-
When I think of restrictive programming languages I think of things like recursion being the only loop construct and no state variables. In my experience languages like Prolog, Scheme or Haskell can force you to be creative. Whereas other standard imperative like Java just make you be more verbose (as compared to Python).
-
It depends in what domain you want to be creative. I've seen some very creative C code (see ThreeStarProgrammers on the c2 Wiki) and some pretty horrible hacks to accomplish what would be simple in higher level languages. So it may make you creative, but in a problem domain where it is probably counter-productive to be creative.
A creative interpretation of a specific business problem domain is useful. A creative use of a legacy programming language is not.
-
C,Pascal -> [Creativity] -> Java
OR
Java,C# -> [Creativity] -> Python,Ruby
OR What you ever will
The Restriktion in one Language create another (better?) Language
-
There's a bad parallel in there. Programming with a language which is a poor fit to your way of conceptualizing is like trying to paint using pigments that change to an unknown color when they dry. It doesn't stimulate creativity, because it's an exercise in futility.
The right parallel for painting using only yellow and blue in programming is more along the lines of programming without your most-used loop construct.
-
Hmm. I think you've got a false analogy here.
When I think of restrictions in art, it usually has to do with making creative use of a limited set of tools or materials.
The appropriate programming analogy would be a language that has a minimal syntax (such as Python or Lisp).
When I think of restrictions in a programming language, I think of having to work around what I'm allowed to do with those tools. The appropriate analogy in the art world is censorship.
-
I have to agree with Michael and Daniel somewhat. The "restrictions" you mention in art are self-imposed limits created by the artist to challenge their current way of thinking. Much in the same way a weightlifter adds more weight when he or she reaches a strength training plateau.
The strongly-typed languages are enforcing a design on you that isn't as flexible as an interpreted language and narrows the number of ways you can skin a cat.
To me the frustration you experience when moving from a language like Python to a compiled language like Java is more analagous to going into a building where the architect decided stairs are a better, safer, more reliable way to get to the 10th floor instead of an elevator which makes getting to your office so much easier. There are drawbacks to elevators and stairs are just fine but there is some frustration when someone imposes their design on you and doesn't give you enough choices about how to safely and efficiently reach your goal.
-
The comparison of programming to art is a key issue here. I think art has an advantange in that people are trained to value art for its creativity, whereas they are trained to value software for its functionality.
If we were to reverse these value judgements what would we get? Say a guy commissions a portrait of his dog? If the artist had only blue and yellow paint, but still produced a reasonable likeness to the dog, would the customer say "what a creative use of color" or would he say "$!@#, my dog is black, not blue and yellow!". In the same way, when someone pays you to write software they aren't going to complement you on the creative way you worked around the Java type system, but a fellow programmer who's been struggling with that issue would.
-
"""When I think of restrictions in a programming language, I think of having to work around what I'm allowed to do with those tools. The appropriate analogy in the art world is censorship."""
Censorship is just another restriction though. Indeed, I mentioned self-imposed restrictions in the blog post, but there is really no reason why these restrictions cannot come from elsewhere -- for art, a teacher telling you what to do, a government imposing laws, social rules, etc. Censorship is just a more extreme form of restriction. It hasn't stopped people from finding creative ways to get around it, though.
My point being, the source or reason of these restrictions doesn't really matter as much as the fact that there *are* restrictions.
-
Wow, some good stuff here. If nothing else, at least this article got people thinking. (Including me...)
-
A a lot of tautology in the article, and a lot less depth that some might think.
The author first says that restrictions in Pascal fuel creative solutions that turn out to be not so desirable since the end result is the same. Then he says how strange that in art creative solutions are very desirable while the end results are not the same.
Then we ponder the mystery. Hello! The answer is right there...
If the end result is the creative solution itself then we want it. If the "creativeness" of the solution does not matter then we don't need it.
Nothing to see here, moving on.
-
I had to reread my post carefully to see if I really said all those things. I don't think so. :-)
It is true that in art, these restrictions force a different end result (a different painting, story, etc). In programming, the end result for the user, the functionality, should roughly be the same, no matter what language or technique I use. But the *code* can be very different. This is one area where art and programming are unalike, and maybe I have been comparing apples to oranges.
However, my point is, that the creative process should make you a better programmer, and change the way you think about programming. The restrictions imposed by languages like Pascal don't really qualify, since I usually don't *want* to write my own linked list, or dict, or compensate for a language's lack of dynamism, etc. The example of a Lisp-like language and recursion is better: here, the restriction does make me a better programmer, and what I learned will be valuable elsewhere, even in languages that don't have this restriction.
-
Worth thinking about the difference between languages that come from computer science, and those that evolve from having to perform work in a particular and narrow domain.
The language I have spent most time coding in is good old proprietary IBM RPG. It is probably the most restrictive language bar none. And billions of dollars of software asset is coded with it. Ie. maybe not aptly described as creative solutions, but certainly abundant.
RPG formerly only allowed a single op-code per line. And the structure of a line of code was fixed (until very recently). Since the programs developed using it run banks and other huge application areas like manufacturing and distribution, the ability to audit every single line of code (and the date of changing/creating it) has proved useful.
Also the ability to write code generators and re-formatters is much easier with a fixed format, one statement-one line programming language.
IBM RPG has gone all free format on us now, however.
Since the values have changed for a database heavy-weight. What I want now is to replace my traditional tool with an unfettered Python but with built in support for database (not SQL but up down and left, right), data structures, interactive data entry screens and spooled, externally described reports.
Thought I would just get that off my chest here...apologies.
-
It is certainly a truism (and one I have long believed and often quoted) that restrictions can enhance creativity. As many here concur, there are times when the resultant creations may be admired for artistic or aesthetic reasons, but not because they are useful. Consider, for example, almost any algorithm written in a simple Turing machine such as Brainf**k. Depending on your sensibilities, such an algorithm may or may not be beautiful, but it almost certainly won't be useful.
Personally, however, I think the assertion in the original article that "The type of restriction hardly matters" is not, strictly speaking, correct. Writing an algorithm in Brainf**k, painting using only two colors, or writing a novel without any "e"s are tasks which are certainly mentally stimulating, in the same sort of way as solving a crossword puzzle or a word problem, or pursuing any of a number of other leisure activities.
However, I think some of the best art, and some of the best satisfaction to be gained when creating art, comes from _externally imposed_ constraints. An artist carving a fancy walking stick will ideally come up with art which will, in fact, work well as a walking stick, and this is the sort of constraint which can really get the creative juices flowing, and which can garner more accolades for the accomplishment after the fact.
The same sort of satisfaction can be gained from dealing with real-world constraints when programming, but when you have seen the exact same constraints over and over, and you know not only how to get around them but also that in a different situation (e.g. using a different language) you might not have to contend with those particular constraints, and you know from past experience that the constraints might lead to days or weeks of extra debugging time, the constraints can become enervating rather than energizing. So, I think a more accurate thesis might be that _novel_ (new to the creator, not necessarily to all of humanity) constraints can enhance creativity.
You could take it as a challenge to use a language with less capability to perform a given task, just as a painter could take it as a challenge to create a masterpiece with a broken brush.
but if your primary goal is to create a useful program, and his primary goal to create a beautiful painting, new tools might be in order in both instances. Fortunately, in programming, it is often quite easy to create new tools to take some of the drudgery out of coping with non-novel
constraints (such as by writing special purpose code generators), so it is usually possible to inject at least a little fun and creativity into even the most boring jobs.