Linked by Ersin Akinci on Wed 7th Apr 2010 17:24 UTC
Internet & Networking Websites for over a decade have been transitioning to the Model-View-Controller paradigm, separating data from formatting and user interaction in their code bases. Unfortunately, this has meant not only the end of ugly early 90's vintage Geocities pages, but also of the era of digital, or more specifically computeral craftsmanship. The future of computers will depend on those artists, scholars, and programmers who can reunify content with format and remake programming as an art.
Order by: Score:
The premise lacks vision.
by kristoph on Wed 7th Apr 2010 18:08 UTC
kristoph
Member since:
2006-01-01

The premise of this article - in a nutshell - is that the separation of view and the model, as personified by MVC, reduces the ability of the web site developer to truly craft his or her vision.

First, this is flawed because, frankly, there was never a time when a web site developer could craft their vision. There was always different browser, different standard support, different machines, different monitors etc. We never had the ability to create our exact vision.

Second, the separation of the view and the model, with the data readily accessible to non HTML views means that many a developer can, in fact, craft their vision of a product using Flash/Flex, the iPhoneOS, and any other platform specific code that is much closer then what they could accomplish with HTML.

Finally, I would argue, that once you separate the data and view you are essentially liberating the data so it can be expressed in a much more intuitive or visually appealing manner by those who may not have the skill to build offering as a whole (so the person who wrote TweetDeck may not have been able to build Twitter but he can express his vision of Twitter through his 'view' on Twitter).

]{

Reply Score: 2

RE: The premise lacks vision.
by earksiinni on Wed 7th Apr 2010 18:42 UTC in reply to "The premise lacks vision."
earksiinni Member since:
2009-03-27

The premise of this article - in a nutshell - is that the separation of view and the model, as personified by MVC, reduces the ability of the web site developer to truly craft his or her vision.


Not quite. The separation of view and model threatens a certain way of doing things that I'm calling "craftsmanship", which involves combining view creation and model creation, or more broadly format and content, in a single act just as when we write a sentence on paper it is content and format at the same time. As I wrote in the article, that's not the only way of doing things, nor necessarily the best in all cases, but it has its place in art.

First, this is flawed because, frankly, there was never a time when a web site developer could craft their vision. There was always different browser, different standard support, different machines, different monitors etc. We never had the ability to create our exact vision.


Yes, a very good point here, which I briefly alluded to when I mentioned the browser wars and which you've fleshed out quite well here. I did briefly mention that HTML is not really a good solution, because even if we assumed that it rendered the same on all pages, markup is still separate from content.

Second, the separation of the view and the model, with the data readily accessible to non HTML views means that many a developer can, in fact, craft their vision of a product using Flash/Flex, the iPhoneOS, and any other platform specific code that is much closer then what they could accomplish with HTML.


Right, but my point is not so much about the end product as it is about the nature of the action of creating art. I could achieve the same effects as those silly Angelfire sites I linked to in CSS, but the method is totally different and un-craftsmanlike.

Finally, I would argue, that once you separate the data and view you are essentially liberating the data so it can be expressed in a much more intuitive or visually appealing manner by those who may not have the skill to build offering as a whole (so the person who wrote TweetDeck may not have been able to build Twitter but he can express his vision of Twitter through his 'view' on Twitter).


I find the idea of "liberating the data" absolutely fascinating. The larger point of the article was to suggest an unorthodox view, that not only does content dictate format, but that format also has a role in determining content. If they exist in symbiosis, to what extent can we ever really "liberate data"? Yet at the same time, there are those who seem to engage with content/data/essence in a "direct" way, like mathematicians who see the world in numbers, historians who relive the heat of an argument as they write about it, mystics in direct contact with God, or programmers who...well, that is exactly the issue. What does it mean for a programmer to be engaged in a direct connection with the data? What is the soul of a computer? It is inexpressible, and yet anyone who is lured by a computer knows that its power is real and immersing.

(Edit: typo)

Edited 2010-04-07 18:43 UTC

Reply Score: 2

RE[2]: The premise lacks vision.
by kristoph on Wed 7th Apr 2010 20:17 UTC in reply to "RE: The premise lacks vision."
kristoph Member since:
2006-01-01

I find the idea of "liberating the data" absolutely fascinating. The larger point of the article was to suggest an unorthodox view, that not only does content dictate format, but that format also has a role in determining content.


A typical model is a view on another model. Certainly, there may be what we might consider 'hard data' underlying a model but, in most cases, that hard data is itself a view on some other quantifiable collection of facts or events ( or, if your an analyst, the facts don't even have to quantifiable ;-).

Although you speak of format as a visual representation, the word is actually very appropriate because format is simply a vehicle to present data with a different interpretation. If the interpretation itself adds or alters the meaning of the data then it becomes a new, unique, data model which is, itself, subject to reinterpretation by 'artists' and 'craftsmen' to create yet another interpretation of the same data.

Much of western art, over many centuries, was based on repeated interpretation of a single data model - the bible - and the subsequent reinterpretation of that interpretation by a successive generation of artists and craftsmen. Not even the most conservative of theologians would suggest that there is a 'best' way to interpret that data model.

It is our very nature to interpret data - just as you have done in your article. The broad and liberal availability of data is paramount to our cultural development. Indeed, by facilitating that liberation we create the opportunity for other to create different, possibly better, interpretations.

MVC is the computer industries recognition that there is value in the freedom to reinterpret data in new ways. Initially, this was done simply because an initial view was poor (the UI was bad) and when the model was coupled to the view it was terribly difficult to change or alter the view.

Today, we - as developers - recognize that it's not just about fixing our own stuff but about allowing others to take what we've build and interpret it in new and better ways.

]{

Reply Score: 2

earksiinni Member since:
2009-03-27

Wow, what a breathtaking contemplation--thank you! These words really struck a chord with me:

Although you speak of format as a visual representation, the word is actually very appropriate because format is simply a vehicle to present data with a different interpretation. If the interpretation itself adds or alters the meaning of the data then it becomes a new, unique, data model which is, itself, subject to reinterpretation by 'artists' and 'craftsmen' to create yet another interpretation of the same data.


Yes, that is the key, I think: interpretation and data, or format and content, are one and the same; or, if that's going too far, they are in a symbiotic state. They merge into each other.

First of all, I want to make it clear that I really admire what MVC has done to liberate data, and I cannot stress enough that I like MVC and what it's done for computing. You've really made its case eloquently here. But it's not "craftsmanship" in the way that I mean here, and the entire move from "craftsmanship" to MVC has left a hole. MVC should remain because it does what it does admirably, but it should live alongside craftsmanship.

My reason for saying so is simply that I have yet to discover code or a program that moves me to the bottom of my soul the way that reading a great book or watching an amazing film does. Sure, computers fascinate me and take up all my spare time, but they lack that innate spiritual power that all other art has, and which I feel that it is destined to attain because like all other art it is such a powerful information technology. People have given their lives for Shakespeare, but has anyone given their life for code? Thus, the question is how do information technologies become art, and I think that part of the answer has to do with how computer formats interact with computer content. It behooves us to systematically explore every way of configuring format with content to see what is soul-moving, and the "craftsman" method I outlined is one such approach.

About the liberation of data. If the view becomes the data model, then assuming that the view isn't being constricted by some other view around it, isn't data always liberated? It's like data exists in a race condition, it's always changing depending on who created what view that became the data you're looking at before the instant that you started looking at it. Well, that's the beauty of art--art is crisis.

...

I'm still thinking of the best way to respond to the meat of your post, however. I do see your point about MVC and art, and of all the critical comments I've read so far I think that is the most devastating, yet maybe MVC and craftsmanship aren't incompatible. Perhaps they are two sides of the same coin, because craftsmanship is all about pure creation, but it doesn't take inspiration or interpretation into account. Craftsmanship might be one possible way to achieve the view end of MVC...

But it's really the controller that throws a wrench in the cogs. Going back to your example about the Bible, what's the controller there? Roman Catholic orthodoxy holds that the clergy is the controller, and many heresies (like Protestantism, in part) centered around the idea that people could interpret the Bible for themselves. Yet there, the church impeded the flow of data, and I imagine that Facebook's and Twitter's API's will remain open as long as it benefits those companies, not humanity. So to compare controller-less Bible-based Western art to true MVC-style Bible-based Western art, I think that we'd have to do something like compare the art works of those who heard the Bible only when it was read aloud at sermon (and understood it, since the vernacular was banned for a very long time) with the art works of those who had read the Bible directly. Assuming that we can control for every other variable. Lol.

Then maybe we need better metrics?

Reply Score: 1

pompous stranger Member since:
2006-05-28

Not quite. The separation of view and model threatens a certain way of doing things that I'm calling "craftsmanship", which involves combining view creation and model creation, or more broadly format and content, in a single act just as when we write a sentence on paper it is content and format at the same time.


Let's take this "craftsmanship" contention as this appears to be the one you think most readers misunderstand.

I'd like to point out that most written craft has not been distributed in manuscript form since the Middle Ages. For almost as long as popular writing has been distributed this "single act" you describe consisted of (a) a writer scribbling a "foul" manuscript, (b) a scrivener transcribing this into a finished manuscript, (c) a copysetter or woodcutter formatting this into a print block, (d) the printed copy being produced. By the time the typewriter rolled around this cut the process down to three steps, but it was still true that that which came out of the typewriter was NOT what was represented on the book leaf. Content and format were completely separate acts almost always done by completely separate people.

Reply Score: 1

earksiinni Member since:
2009-03-27

I'd like to point out that most written craft has not been distributed in manuscript form since the Middle Ages. For almost as long as popular writing has been distributed this "single act" you describe consisted of (a) a writer scribbling a "foul" manuscript, (b) a scrivener transcribing this into a finished manuscript, (c) a copysetter or woodcutter formatting this into a print block, (d) the printed copy being produced. By the time the typewriter rolled around this cut the process down to three steps, but it was still true that that which came out of the typewriter was NOT what was represented on the book leaf. Content and format were completely separate acts almost always done by completely separate people.


As you yourself just wrote, the manuscripts were still being written out by hand, but that's besides the point. When I say that there's a "unified act" (I did write "single act" once, a poor choice of words), I don't mean literally one physical movement. As I wrote:

"This is unity in very deep sense: a craftsman's act isn't just a bunch of careful strokes and moments of thoughtful repose strung together, it is a dramatic narrative of those individual time spans brought together by a meta-act, which is the unified vision-creation."

I called this a "dramatic narrative" since drama is that way, really. Characters will do different things with different agendas at different points in time, but the entire play is unified by an overarching action. When we write something by hand, that action is really literal: glyphs are format and content. But in a broader sense, coding with MVC utterly lacks the dramatic unity of, say, designing a building or creating a sculpture.

Reply Score: 1

pompous stranger Member since:
2006-05-28

When we write something by hand, that action is really literal: glyphs are format and content. But in a broader sense, coding with MVC utterly lacks the dramatic unity of, say, designing a building or creating a sculpture.


I disagree with the conjecture that other mulit-step, multi-skill, and often multi-person tasks like publishing, architecture and sculpting are uniquely unified in a way that MVC is not.

Reply Score: 1

earksiinni Member since:
2009-03-27

I disagree with the conjecture that other mulit-step, multi-skill, and often multi-person tasks like publishing, architecture and sculpting are uniquely unified in a way that MVC is not.


Could you elaborate?

Reply Score: 1

very good article, but not 100% convinced
by evert on Wed 7th Apr 2010 18:43 UTC
evert
Member since:
2005-07-06

First, I have to admit that this is a well-written, good article. It opened some interesting thoughts and insights.

But I am not very convinced about the development you are describing here - the move from the hobbyist who is in control of both formatting and content (at the same time) to the writer who has no control over the format.

Partly, those who create their own website have *more* control over the integration of format and layout. Earlier HTML techniques did not allow fine-tuned control about how a webpage would show up in a browser. With CSS, Flash, and so on, you actually have better control over the content - format intergration.

But it is true that the number of people that fully create their own website is decreasing. Most people only deliver content /or/ design (XOR), and rely on content management systems. It's easier. People still can combine format and content, but they no longer want to do so, or are not willing to learn to do it. Which is expected, because the true technologic minded hobbyists constituted the greater part of the netizens in the beginning of the internet age, but now it's a mass product.

Reply Score: 3

A breathtakingly creative analysis
by Ugur on Wed 7th Apr 2010 19:19 UTC
Ugur
Member since:
2010-04-07

This is such an exciting angle on a very important issue (for me) -- whether the web is "closing" or "opening up" to more creative and expressive user participation. I tend to side with the pessimists on this issue but I'll continue to read and think about all the interesting points the author has raised in his seminal post and try to keep an open mind about things that I never considered before. Excellent job, Ersin!

Reply Score: 2

Got a few paragraphs down...
by google_ninja on Wed 7th Apr 2010 19:34 UTC
google_ninja
Member since:
2006-02-05

Until this

"In contrast, the way most of the web was written before MVC was with plain static HTML pages that unified content with its formatting without any intervening controller."

I'm not going to read something when someone starts talking about something he obviously has no idea about.
That sentence is the equivalent to saying that before lemonaid, people had to get up to change their tv channels, and now they can do it from the comfort of their couch. Pure nonsense.

Reply Score: 6

RE: Got a few paragraphs down...
by tyrione on Wed 7th Apr 2010 20:33 UTC in reply to "Got a few paragraphs down..."
tyrione Member since:
2005-11-21

Until this

"In contrast, the way most of the web was written before MVC was with plain static HTML pages that unified content with its formatting without any intervening controller."

I'm not going to read something when someone starts talking about something he obviously has no idea about.
That sentence is the equivalent to saying that before lemonaid, people had to get up to change their tv channels, and now they can do it from the comfort of their couch. Pure nonsense.


He could have done his home work and discovered NeXT WebObjects in 1995 and released in 1996 with it's native MVC from inception back in 1989 turned static content into Dynamically driven Web enterprise sites.

Anyone who is going to do a history on MVC and doesn't cite NeXTStep -> Openstep -> Web Objects -> Java -> etc... seems to have a shallow knowledge of the Web development history.

Reply Score: 2

galvanash Member since:
2006-01-25

Not to nitpick, but NeXT merely applied what came well before them. The concept of MVC was first implemented at Xerox Parc in Smalltalk back the 70s. Anyone doing a history of MVC should at least cite the actual creator.

Reply Score: 3

Thom_Holwerda Member since:
2005-06-29

Don't bother - he worked at NeXT and has the urge to inject NeXT into any conversation. Forcibly, if necessary.

It's kind of endeering ;) .

Reply Score: 2

google_ninja Member since:
2006-02-05

The problem with MVC isn't who invented it, the problem with using MVC like that is that MVC is a way to structure programs, and doesn't have anything to do with the web. If you put <?php echo date("D M d"); ?> in a .php file, that will generate dynamic content, but it has nothing to do with MVC.

Not only that, controllers aren't what change things, views are. Views will change the output based on the model they are given, controllers wire the two together.

As a programmer, reading that paragraph was like watching CSI characters do their techno-wizardy, and throw around terms to make themselves sound good, but don't actually mean anything.

Reply Score: 1

earksiinni Member since:
2009-03-27

The problem with MVC isn't who invented it, the problem with using MVC like that is that MVC is a way to structure programs, and doesn't have anything to do with the web. If you put in a .php file, that will generate dynamic content, but it has nothing to do with MVC.


Aren't many web apps structured around MVC? PHP couldn't be the code for a view in an MVC program?

Not only that, controllers aren't what change things, views are. Views will change the output based on the model they are given, controllers wire the two together.


Exactly my point, there is an intervening controller that separates content from format. The data is not in the same file as the formatting, as it is in static HTML, and dynamically generated HTML doesn't count.

As a programmer, reading that paragraph was like watching CSI characters do their techno-wizardy, and throw around terms to make themselves sound good, but don't actually mean anything.


I'm not entirely sure what you found objectionable. I'm not attacking MVC, nor am I writing about programming or web development.

Reply Score: 1

google_ninja Member since:
2006-02-05

Aren't many web apps structured around MVC? PHP couldn't be the code for a view in an MVC program?


They are, because it is a good fit for the web. But its not "MVC vs Static Content" its "MVC vs Dozens of other Architectures". The web has never been 100% static, there have always been dynamic sites. Dynamic sites have ALWAYS separated code and data, MVC is just one way of doing it. The difference between the early web and now, is that we have made CMSs that are frameworks for designers to create their own dynamic sites without programmers, pretty much fulfilling the dream that this whole thing is about.

Also, MVC and web services have NOTHING to do with each other, javascript has been around for about as long as the web has been accessible to any designer, and css SIMPLIFIES what was there before.

Exactly my point, there is an intervening controller that separates content from format. The data is not in the same file as the formatting, as it is in static HTML, and dynamically generated HTML doesn't count.


But that has NOTHING to do with craftsmanship. Web design is an art form, and saying otherwise is going to get any designer seriously pissed off with you. Just because instead of saying "Price: 15$" you say "Price: <%= price %>$" has no impact in any way to the creativity, skill, and talent required to build a proper web page.

I'm not entirely sure what you found objectionable. I'm not attacking MVC, nor am I writing about programming or web development.


Your whole premise is that the separation of code and data means that things are too complected for artists to create. My problem is that to prove that point, you showed a profound lack of understanding of the web, and how both web design and programming works. If you walked up to one of those carpenters you talked about, and told him what he was doing wasn't a craft because it required education and more then one tool, and that the only way it would ever be any sort of art form is if people invented new ways to work with wood, he would probably punch you in the face. You are doing the equivalent here.

Edited 2010-04-08 13:27 UTC

Reply Score: 3

earksiinni Member since:
2009-03-27

They are, because it is a good fit for the web. But its not "MVC vs Static Content" its "MVC vs Dozens of other Architectures". The web has never been 100% static, there have always been dynamic sites. Dynamic sites have ALWAYS separated code and data, MVC is just one way of doing it. The difference between the early web and now, is that we have made CMSs that are frameworks for designers to create their own dynamic sites without programmers, pretty much fulfilling the dream that this whole thing is about.

Also, MVC and web services have NOTHING to do with each other, javascript has been around for about as long as the web has been accessible to any designer, and css SIMPLIFIES what was there before.

...

But that has NOTHING to do with craftsmanship. Web design is an art form, and saying otherwise is going to get any designer seriously pissed off with you. Just because instead of saying "Price: 15$" you say "Price: $" has no impact in any way to the creativity, skill, and talent required to build a proper web page.


I wish that you had read the rest of the article. As I've said in the comments several times, I am using "craftsmanship" in a very narrow sense here that has absolutely nothing to do with quality, creativity, uniqueness, skill, talent, or anything like that. On page 2, I identify a "craftsman"-style of creating art that spans all professions, which consists of creating format and content in a "unified act". Not all artists are craftsmen, and that's OK. I go on to explain what I mean by a "unified act", which does not mean literally just one action, but rather a series of actions that is unified by dramatic narrative and an overarching, unifying meta-action, the way you have in plays, films, novels, and so on.

Your whole premise is that the separation of code and data means that things are too complected for artists to create. My problem is that to prove that point, you showed a profound lack of understanding of the web, and how both web design and programming works. If you walked up to one of those carpenters you talked about, and told him what he was doing wasn't a craft because it required education and more then one tool, and that the only way it would ever be any sort of art form is if people invented new ways to work with wood, he would probably punch you in the face. You are doing the equivalent here.


No. Nowhere in the article did I write anything about anything being "too complicated". I am making a very narrow argument about a certain style of creating, a style which is not appropriate for all situations but which has its place. Without that style, I don't think that computer systems design as a whole can claim to be art. In my opinion, I think the premise of the article is that format helps dictate content, whereas we usually think of content dictating format.

I've done a good deal of work with web design, with everything from CSS to XML to CMS software to Ruby on Rails. None of it is "too complicated", and if anything, MVC has made making great websites much, much easier. This is not what my point was. You say that "Price: 15$" is no different from "Price: <%= price %>$", and I'm saying that they are, but not because one is "more artistic" and the other is less; but really, comparing the two is a red herring, because all text input for computers is flawed, as I explain at the end.

There is one point where you're right, however, and that is that I'm hinting at the possibility that maybe computer systems design (and thus web design) really isn't an art, albeit definitely not for the same reasons you've listed here. I'm alright with that, because I'm a developer myself, and it's a challenge, not an insult.

Ask yourself, have you ever read code or used a computer interface that when you read/interact with it moves you to the depths of your being, that would make you cry? That might make someone kill themselves or others, put their lives at risk, divorce their spouses? That is the kind of depth and emotion that art can have, and until I see an example in the computer world of that, I'm not convinced that computers are art. Yet, I am convinced that they are destined to be, because all great forms of art were once merely information technologies like computers are today. The question is how do we get there, and I am trying to open up the conversation by discussing one small facet, which is how all arts have this particular group of artists known as "craftsmen", who do things in a particular way that is different from other artists. Is the lack of "craftsmen" among web developers/artists a hindrance? I think it might be.

Reply Score: 1

Interesting article...
by Tuishimi on Wed 7th Apr 2010 19:58 UTC
Tuishimi
Member since:
2005-07-06

...but I don't really see why this view "is" or "has to be". In other words, there may be some truth to it, but it isn't the truth to end all truths regarding content and the common "joe shmoe" from continuing to create and share on the www.

Reply Score: 2

Comment by galvanash
by galvanash on Wed 7th Apr 2010 19:59 UTC
galvanash
Member since:
2006-01-25

Interesting article... Being a web developer myself almost since the beginning I can attest first hand that things have changed dramatically.

In the very old days when the web was relatively new, approaching web development as a programmer required a significant change of perspective. HTTP/HTML simply worked in a completely different way from what most programmers were accustomed to - and you had to adapt to it, you could not adapt it to you. You had to work from within a somewhat strange paradigm - the protocol and presentation language gave you mechanisms to send data to and from your users and format it - but it maintained no state and it had no explicit wiring to actually do anything with the data. Doing stuff with data was not baked in - you had to graft it on somehow. This was mostly done through CGI scripts, and could only be done on the server side originally - clients were the equivalent of dumb terminals for the most part.

This was severely limiting in some ways - but its greatest weakness was also it greatest strength. CGI was a fairly rigid and simple minded interface, but because what you could do with it was never really defined, it encouraged developers to discover what they could do with it. Its lack of definition made it a fertile playground for clever people to come up with ingenious ways to leverage it to good use. PHP, JSP, ASP, etc. all evolved from what were essentially frameworks that more or less converged from what people were implementing in CGI...

Then javascript was introduced, and a 2nd wave of the same kind of thing occurred. Javascript introduced the notion of client intelligence. Now you had 2 different paradigms to tackle that were only tangentially related, but when combined could be very useful. Again, creativity flourished.

All through this developers were seeing the patterns emerge and were building frameworks to make it easier to develop for those patterns. But they were building frameworks for web development using the technologies that were inherent to web development.

They were of course some who tried to make web development more like traditional development. There were some good things that came out of that to be sure. But as this progressed something was lost - namely a deep understanding of the underlying technologies that things were being built on top of. This is when I think things started to go wrong.

Nowadays a developer with almost no knowledge of HTTP can fire up Visual Studio and build a web service. Another developer with no knowledge of HTML can use ASP.NET to build a client for it. Yet another developer can build a desktop application as a client and not even know HTML exists. The protocol that the web was built on is no longer exclusively used by the web, more and more things are using it as mere plumbing. On many levels this is a good thing, I'm not arguing that it is all bad. But there is no art in it, no real creativity. It is incredibly useful, but it has nothing to do with the web itself.

I have, on numerous occasions, heard comments like "no one needs to know HTML anymore" - and I have heard these comments from actual web developers. So yes, I agree with the article - the web (not to be confused with the internet) is dying a slow death. Does HTML5 matter? I think it does, but I also think that in 10 or 15 years it won't anymore. The web will end up being relegated to the status of usenet and mailing list - something that still exists and is widely used by the technical elite but is ignored by most users. The said part is unlike past evolutions of the internet I don't see something fundamentally better replacing it...

The fundamental concept has been lost, namely that everything on the web is part of a homogeneous whole that can all be viewed through the same window. The old mantra of "one client to rule them all" is completely dead now.

Reply Score: 6

Er, no
by steve_s on Wed 7th Apr 2010 20:10 UTC
steve_s
Member since:
2006-01-16

Having read the first paragraph of this article on the OSNews front page I must admit that I felt insulted. I did try to read the article, but only managed to get through about a quarter of it and skimmed the rest, because I fundamentally disagree with the premise. It seems clear to me that the author is not a programmer and does not truly understand software development on any level.

I've been programming professionally for longer than many readers of this site have been alive, and I've written my fair share of non-MVC code. These days virtually everything I do is built with an MVC architecture.

I don't feel in any way that any less "computeral craftsmanship" is involved with how I work today than how I worked 20 years ago. If anything I'd argue the opposite is true. Following an MVC paradigm frees me up to craft elegant solutions, and make decent reuse of significant amounts of code in complex systems. In fact, many of the systems I've worked on are at a level of complexity where they would be impractical to construct without using an MVC architecture.

Reply Score: 2

RE: Er, no
by earksiinni on Wed 7th Apr 2010 20:25 UTC in reply to "Er, no"
earksiinni Member since:
2009-03-27

Having read the first paragraph of this article on the OSNews front page I must admit that I felt insulted. I did try to read the article, but only managed to get through about a quarter of it and skimmed the rest, because I fundamentally disagree with the premise. It seems clear to me that the author is not a programmer and does not truly understand software development on any level.

...

I don't feel in any way that any less "computeral craftsmanship" is involved with how I work today than how I worked 20 years ago. If anything I'd argue the opposite is true. Following an MVC paradigm frees me up to craft elegant solutions, and make decent reuse of significant amounts of code in complex systems. In fact, many of the systems I've worked on are at a level of complexity where they would be impractical to construct without using an MVC architecture.


I think readers may have misunderstood what I meant by "craftsmanship". I'm referring to a very specific way of creating products (more specifically, art) where content and format are generated in a unified act. This act is not just a bunch of events strung together, just as cabinet making (an example I use later in the article) cannot really be described as simply the physical acts of manipulating wood strung together on a timeline; the sum is greater than the parts, and the artist herself engages in a very strange kind of inner rapture that is the artistic process of creation. I elaborate on this toward the end of the article. By no means do I mean "craftsmanship" in the sense of quality or appropriateness, and I've explicitly explained, this particular kind of craftsmanship is definitely not the way to do things for all situations (or even the majority of situations). However, it has its place, and without it, programming will not be able to assume its rightful place in the pantheon of arts next to poetry, painting, music, architecture, and so forth.

As for being a programmer, I do not program professionally, although I have done some paid development for AbiWord in the past and intend to continue my work in this year's GSoC. I'm much more into Linux distribution development, and I'm intimately familiar with the infrastructure programmers use, at least on GNU/Linux systems.

Reply Score: 1

RE[2]: Er, no
by steve_s on Wed 7th Apr 2010 21:01 UTC in reply to "RE: Er, no"
steve_s Member since:
2006-01-16

I think readers may have misunderstood what I meant by "craftsmanship". I'm referring to a very specific way of creating products (more specifically, art) where content and format are generated in a unified act.


I accept that since I didn't properly read your piece I didn't quite get what you meant by "craftsmanship". Your use of the word "art" here is also interesting...

This act is not just a bunch of events strung together, just as cabinet making (an example I use later in the article) cannot really be described as simply the physical acts of manipulating wood strung together on a timeline; the sum is greater than the parts, and the artist herself engages in a very strange kind of inner rapture that is the artistic process of creation. I elaborate on this toward the end of the article. By no means do I mean "craftsmanship" in the sense of quality or appropriateness, and I've explicitly explained, this particular kind of craftsmanship is definitely not the way to do things for all situations (or even the majority of situations). However, it has its place, and without it, programming will not be able to assume its rightful place in the pantheon of arts next to poetry, painting, music, architecture, and so forth.


Your mention of poetry here is an interesting example, which raises in my mind a parallel. Much poetry is largely free form, but off the top of my head there's two forms that impose strict rules, those being haiku and sonnets. They provide a predefined format for the poem. Similar predefined formats exist in many other arts too.

I'd argue that the use of an MVC paradigm is a parallel. MVC defines the format, and sets strict rules for the crafting of software.

The point is that imposing a format on an art form does not prevent it from being art. The widespread adoption of MVC in programming does not prevent it from being an art either.

Reply Score: 1

RE[3]: Er, no
by earksiinni on Thu 8th Apr 2010 03:48 UTC in reply to "RE[2]: Er, no"
earksiinni Member since:
2009-03-27

Your mention of poetry here is an interesting example, which raises in my mind a parallel. Much poetry is largely free form, but off the top of my head there's two forms that impose strict rules, those being haiku and sonnets. They provide a predefined format for the poem. Similar predefined formats exist in many other arts too.

I'd argue that the use of an MVC paradigm is a parallel. MVC defines the format, and sets strict rules for the crafting of software.


That's really a great point, thank you! I hadn't thought of it that way. In that case, it's a bit like saying the model, view, and the controller as a whole make up the artwork. The only "problem", if it can be called that, is that the only spectator in the gallery is the programmer, because he's the only one who can see all the parts together. Maybe we need more open source websites so that more people can enjoy the masterpiece?

The point is that imposing a format on an art form does not prevent it from being art. The widespread adoption of MVC in programming does not prevent it from being an art either.


MVC and all else aside, I think that the fundamental problem with calling programming an art is that in the end the product simply doesn't move us the way that what we generally call art does. "What is art?" I think that question is a red herring, because we can all agree that art is something that stirs us, and even if we don't like the art or it doesn't stir us in particular, most people would appreciate that it probably does stir someone. But it's not just any stirring, it's a special stirring: it's as if art has an innate power and a life of its own. When we read a great book, for instance, the author's intentions of what he meant to tell you are important, but so too is your interpretation and interaction with the book regardless of what the author meant to say; that is, reading is a creative act.

I don't see that kind of innate power in computer systems, the kind that completely overwhelms me and makes me cry the way movies, music, or sculptures do, and I'm a pretty tech savvy guy. What I do see in myself and the people I know is that we are obsessed with computers, but never quite enveloped by them to the point that we forget who we are/that we lose ourselves. Back in the day, they would have said that computers don't "enthuse" us, which is the perfect word really, because its original meaning connotes that God or some spirit is literally entering you ("en" + "theos").

Virtual reality has tried this but failed, and common wisdom says it's because we can't render enough polygons at 30 FPS, but I think that it might have to do with a curious historical trend that I've noticed. Namely, when a new information technology like the book or the computer shows up, one camp reacts against it and another adopts it wholeheartedly, but neither side engages in a deep emotional/spiritual connection with it. They begin to once the technology has matured and, crucially, once formats draw on the unique properties of that technology.

So, for example, we see suspense and surprise endings develop around the same time that books move from scrolls to codices, thus literally allowing "the page-turner" genre to be born. Pages, too, allow for new ways of spatially organizing content and new patterns of reading that are often associated with non-ancient literature. Socrates, to name one commentator, never foresaw any of this, even going so far as to say that writing would harm memory. Now, Socrates was famously illiterate, and his student Plato was among the first generation of ancient Athenians to learn how to read and write, but even the pupil didn't produce anything other than dialogs, or transcriptions (at least, in their model) of conversations. We know that we lost many of Plato's works, but even Plato's student Aristotle, whose treatises aren't anything like Plato's dialogs in format, wrote his works as lecture notes to be recited aloud. None of these guys wrote deeply stirring works, and frankly it's no surprise, because no one wants to read something that's in an oral format. Try reading a radio or comedy show transcript, or ask an actor how difficult it is to turn a printed play into a performance. But conversely, try reading aloud a novel: the convenience of books on tape aside, it's not nearly as enjoyable as reading silently. This, too, is no coincidence, and it wasn't until the sixteenth century (which was around the time when Miguel de Cervantes wrote the world's first novel, Don Quixote) that people began reading inwardly/silently. I would suggest that's because books were still largely based on oral paradigms and that the novel was really one of the first authentically literary formats ever, and accordingly to feel its full effects you must read it quietly in a codex. (It's no wonder that the designers of the Kindle tried to replicate the physical characteristics of a paper book so much.)

Therefore, what I think will happen eventually is that "computeral" formats will appear that are intrinsically tied to the computer's essence the way that the novel has been tied to the codex, and I seriously doubt that they will much resemble anything we have today. Until then, I don't think that computer programs or computer systems in general will ever really be art. It's not an attack on anyone, it's more of a call and a challenge, and I am on the side of the coders. Every craft in history that became an art had to fight for it. You might be surprised to know that artists had fierce debates during the Renaissance over whether painting could really be considered an art like poetry and sculpture, or whether it was some kind of a ruse or a lowly hobby. People (Giorgio Vasari is one famous name) literally would argue about what made painting art, indeed what art was, and I think that it turned out to be a good thing because it made painters better.

Similarly, I want to trigger a debate over what it means for code or computers to be art, because with dropping literacy rates and people spending less time reading Milton and more time playing Xbox, it's clear that paper books aren't captivating us like they used to. The future is in computers, but if we want it to be a future worth living then there must be an attempt to achieve the same depth and insight that the greatest works of literature or painting or what have you have managed to achieve. We programmers need to find a way not only to keep coding to solve practical problems, but also to reach to the depths of the souls of kids who would have once been reading life changing books in class or on summer vacation, etc. In that sense, I'm not really attacking MVC, I'm trying to show an entirely new usage of computers that needs its own tools and methods. MVC just happens to seem inappropriate to me for that case, but your point above comparing it to sonnets and haikus has got me thinking...

Reply Score: 1

RE: Er, no
by galvanash on Wed 7th Apr 2010 20:40 UTC in reply to "Er, no"
galvanash Member since:
2006-01-25

I find the author placed too much emphasis on MVC - but at the same time while I don't agree with some of his arguments I do agree with the conclusion.

As for MVC itself. The fundamental purpose of MVC is sound, by separating each facet of the implementation it becomes much easier to manage changes to each part as long as the interfaces between them remain compatible. This is CS 101. I in no way see this as bad, it is a good thing.

But you have also introduced the notion that you can replace the client with anything - you are no longer necessarily doing web development, you could be simply using HTTP for your protocol. I think the point he is trying to make is that MVC helped to create the mindset that the details of the client don't much matter.

Is that bad? Certainly not in the grand scheme of things. But it HAS fractured the web to some degree, because by merely creating MVC applications you are creating an application that no longer relies on the web to function. Sure it requires HTTP, but that is not the web - the web is HTML...

I don't think MVC itself is bad, in fact I think it is a good thing. But that doesn't change the fact that it (along with other efforts to make web development more like conventional development) has facilitated the decline of HTML. That doesn't make it bad - it is simply a side effect.

Reply Score: 3

RE[2]: Er, no
by steve_s on Wed 7th Apr 2010 21:34 UTC in reply to "RE: Er, no"
steve_s Member since:
2006-01-16

But you have also introduced the notion that you can replace the client with anything - you are no longer necessarily doing web development, you could be simply using HTTP for your protocol. I think the point he is trying to make is that MVC helped to create the mindset that the details of the client don't much matter.


I don't think that MVC has had all that much of a role to play in creating a mindset that the client details are unimportant. I think that mindset instead comes from developers that have no appreciation of user interface design.

Is that bad? Certainly not in the grand scheme of things. But it HAS fractured the web to some degree, because by merely creating MVC applications you are creating an application that no longer relies on the web to function. Sure it requires HTTP, but that is not the web - the web is HTML...


That's not really true. When one creates an MVC web application one potentially has the ability to create a front-end that does not rely on "the web" to function. It's not compulsory though. There's plenty of MVC web apps out there in the wild that only serve out HTML.

Reply Score: 1

RE[3]: Er, no
by galvanash on Wed 7th Apr 2010 22:06 UTC in reply to "RE[2]: Er, no"
galvanash Member since:
2006-01-25

I don't think that MVC has had all that much of a role to play in creating a mindset that the client details are unimportant. I think that mindset instead comes from developers that have no appreciation of user interface design.


Fair enough. I don't want to nitpick.

That's not really true. When one creates an MVC web application one potentially has the ability to create a front-end that does not rely on "the web" to function. It's not compulsory though. There's plenty of MVC web apps out there in the wild that only serve out HTML.


An MVC app that "only serves out HTML" is implying that the interface between the view and the controller is not done over HTTP. That is certainly a common design. But it is also quite common in many frameworks to implement the controller as a web service and have the view communicate through HTTP calls (ajax).

In these types of applications, you have created an application that is no longer necessarily "web" based - anyone can come along and build a client if they want to, and the client does not need to be HTML. Again, I stress that I am NOT saying this is a bad thing - simply that it has eroded HTML's status as the language of choice for clients.

A client to such an application that is not written using HTML is simply not part of the web. That doesn't mean it is bad or evil - but it is still not part of the web. It can't be linked to, it can't be crawled because it is invisible to the web itself. It is a stand-alone application. The idea of the web was that it was ONE application - everything was part of a whole.

Reply Score: 2

A vision I don't share
by skandalfo on Wed 7th Apr 2010 20:21 UTC
skandalfo
Member since:
2010-04-07

Do you want to have full control over the integration of content and formatting? Just upload a bitmap image to the server. Here are your pixels.

And if you find your graphics editor too arcane to handle, just draw your "content" on a piece of paper and scan it.

-- end of the extrapolation beyond the limit of the absurd --

Yes. Nowadays many people tries to separate data from presentation and interaction. And handling each part of the puzzle is going to require knowledge in a different field. So a given person wants to build his own website that way, he's going to study a little bit more than when everything was pure HTML.

Of course things have got more elaborate... if you want to handle everything. But it's being done that way for good reasons, flexibility being the chief one.

I mean, having different ways to access the same content is actually a good thing. You don't want to take your 24 inch monitor with you in your pocket when travelling by train, for instance. And accessibility is no more than another facet of that flexibility. If you are visually impaired, just move to a theme with a bigger font or extreme contrast, or let the data be processed by an automated screen reader.

If you don't want to discriminate against some user or another one, your craftsman would have to render every combination (M messages times N medias), while separation allows to reduce the overall work required (M messages plus N medias), and to assign each kind of work to someone who specializes to do it well once and forever.

Reply Score: 2

Bad article.
by Bill Shooter of Bul on Wed 7th Apr 2010 21:38 UTC
Bill Shooter of Bul
Member since:
2006-07-14

I'd have to add my voice to the descenting posters. To find at the end, that the author is a PHD history candidate is no surprise. Its academic style punches me in the eyeballs and upper cuts my sanity.

On top of the stylistic assault on the English language, I also disagree pretty strongly with the premise, but its like arguing about which blue is bluer. Its not that important that one is right and the other is wrong.

Reply Score: 3

RE: Bad article.
by drstorm on Thu 8th Apr 2010 02:09 UTC in reply to "Bad article. "
drstorm Member since:
2009-04-24

I'd have to add my voice to the descenting posters. To find at the end, that the author is a PHD history candidate is no surprise. Its academic style punches me in the eyeballs and upper cuts my sanity.

Agreed. My head hurts when someone writes so much and yet, says so little.

On top of the stylistic assault on the English language, I also disagree pretty strongly with the premise, but its like arguing about which blue is bluer. Its not that important that one is right and the other is wrong.

The man clearly does not know what he's talking about. They don't call the 90's "the bad old days of the Internet" for nothing. It was a mess, and I'll even argue that it really showed just how many people have no artistic abilities whatsoever. But, that's not the point.

The point is MVC has nothing to do with art. It is just the proven way of doing things right and it is completely optional. If you want to create "art" you can still squish data and formatting together to make a website that will likely look bad (or at least inconsistent) and be almost impossible to update.

If I understand correctly, what is arguably missing today is the ability to create the whole thing at once and thus keep the single inspiring emotion. Well, websites are not so much like poems as they are like paintings. They take time and require a sequence of semi-independent tasks. You start with a sketch, (i.e. a prototype), hence capture the emotion, and you slowly progress to the whole thing.

All in all, perish the thought of the "craftsmanship" of the 90's returning.

Reply Score: 2

What a load of shit
by lucas_maximus on Wed 7th Apr 2010 22:01 UTC
lucas_maximus
Member since:
2009-08-18

I didn't actually read the article and wrote a load of shit

Edited 2010-04-07 22:06 UTC

Reply Score: 1

cringe
by dacresni on Thu 8th Apr 2010 03:42 UTC
dacresni
Member since:
2009-08-26

Your article, though thought provoking, made me cringe often enough to be compared with the Sera Palen interviews. You demonstrated glaring misunderstandings of the subjects of which you speak (the html spec, MVC design pattern, Software development/engineering) to the point that you alienated your primary audience here at OS news. Frankly it asked a lot of questions that could be more poignant if asked in a better manor. The steps to create a computer program in a crafty way as to implicate computer craftmenship could be exemplified in MenuetOS (http://www.menuetos.net). Works of art like the Apple 2 are still being created today in a different form. Another example would be this web framework TPD, (http://github.com/vii/teepeedee2) menuetOS mentions software designed to waste cpu cycles, this project is (it could be argued) looks like what they had in mind. When you craft something to be both engineered and a work of art, the line between the 2 blur. One can not reduce the art of a project to its aesthetic qualities or those of it's visible form. Sometimes the Function is the art part instead of the form as you characterize it in web development.
Above all, DON'T think form was supposed be interleaved with function in HTML, thats why they created css, < br > is a violation of the spec because its a single tag with no close, its proper form is < br / >. the question is, even with MVC, where do you see the separation? have u ever used [la]TEX

Reply Score: 1

RE: cringe
by earksiinni on Thu 8th Apr 2010 04:30 UTC in reply to "cringe"
earksiinni Member since:
2009-03-27

Your article, though thought provoking, made me cringe often enough to be compared with the Sera Palen interviews. You demonstrated glaring misunderstandings of the subjects of which you speak (the html spec, MVC design pattern, Software development/engineering) to the point that you alienated your primary audience here at OS news.


I don't doubt it, and I'm glad to hear everyone's input, though as a semi-amateur programmer and a devout follower of OSNews, I consider myself to be part of the audience. Anyway, it's my first foray into writing for a techie audience!

Frankly it asked a lot of questions that could be more poignant if asked in a better manor. The steps to create a computer program in a crafty way as to implicate computer craftmenship could be exemplified in MenuetOS (http://www.menuetos.net).


In what way is MenuetOS an example of craftsmanship? I've always admired it from afar, and I even ran it once, but I've never gotten into the code. How does it combine content with form seamlessly? What is the content, really? Keep in mind that I'm using craftsmanship in a very narrow sense, not just to mean "good quality". I take issue with any window-based desktop paradigm--hell, any desktop paradigm, really--because windows themselves are separate from content.

Works of art like the Apple 2 are still being created today in a different form.


Not sure quite what you mean here: do you mean that works of art like the Apple II are being created in a different form, or that works of art like Apple are also being created in a different form? Either way, I think that one of the most obvious things from the reactions to my article is that everyone has a different perception of art, and it would have been helpful if I had elaborted further. I wrote about this at length in a comment above, but I will repeat it briefly here: whatever we think art is, something that sets art aside from other stuff is that it has the ability to totally take over us, to make us forget who we are. It's not just about being really engrossing or interesting; it's almost as if art has an innate power independent of the artist, an ability to enter and penetrate us to the deepest levels of who we are and make us forget who we are, or make us cry, etc. I haven't yet felt that with any computer system that I've encountered. Instead, I and just about everyone I know is obsessed with computers, but I also see how common it is that we feel emotionally drained after five hours of Wikipedia or World of Warcraft. To the extent that we feel emotion, it's more of an excitement or a shallow happiness rather than a deep sense that we've been nourished or enriched. That's what only great art can do.

Also, I know it's hard to make comparisons like that, because not everyone who's a great coder is a great reader and vice versa. Someone might say, "Well, I think I'm enriched when I write great code", but how will they ever be able to compare it to, say, reading Shakespeare unless they have the same skill level in coding as they do in reading literature. I wish that I could overcome this problem, but until then, I'm stuck with imperfect inferences from what the people I ask tell me. So I ask you, is programming an emotionally/spiritually nourishing activity for you that you feel has the potential to make you weep or risk your life for the way that people have done for poems and films? Do you feel the same way about reading code?

Another example would be this web framework TPD, (http://github.com/vii/teepeedee2) menuetOS mentions software designed to waste cpu cycles, this project is (it could be argued) looks like what they had in mind.


I will definitely look into this, thanks.

When you craft something to be both engineered and a work of art, the line between the 2 blur. One can not reduce the art of a project to its aesthetic qualities or those of it's visible form. Sometimes the Function is the art part instead of the form as you characterize it in web development.


Yes, I was trying to make a similar point by emphasizing that craftsmanship is a "style" of doing things, or a function. For this article, I wasn't all that interested in the aesthetics of web pages, I'm more interested in *how* the web pages get written, and I was trying to point out that the tools for doing the craftsman-style are not being developed.

Above all, DON'T think form was supposed be interleaved with function in HTML, thats why they created css, < br > is a violation of the spec because its a single tag with no close, its proper form is < br / >.


Sorry, I didn't understand your point here. How can form be interleaved with function? I meant that in HTML, formatting is interleaved with content to determine both the document's format and its internal structure. It's not a perfect craftsman-like approach, but static HTML is a lot closer to one than MVC is.

the question is, even with MVC, where do you see the separation? have u ever used [la]TEX


Haven't used LaTeX (looked at it briefly once), but isn't it a markup language like HTML? Same promise of content being so closely integrated with formatting, same disappointment of not having gone all the way. In MVC, the separation is between data, which reside in databases and are typically administered by database professionals, and formats/views, which are developed by a web designer, UI-guy, etc. The craftsman model means that the same person does the both in the same document in a single act, and for computers I don't think that we have the tools yet to do that.

Reply Score: 1

RE[2]: cringe
by galvanash on Thu 8th Apr 2010 07:23 UTC in reply to "RE: cringe"
galvanash Member since:
2006-01-25

In what way is MenuetOS an example of craftsmanship? I've always admired it from afar, and I even ran it once, but I've never gotten into the code. How does it combine content with form seamlessly?


I think you are missing the point because when you say "craftsmanship" to a programmer what comes to their mind is the elegance in which a particular piece of functionality is expressed in the source code. What the code does, i.e. the result - is not really the point. To a programmer, craftsmanship is writing beautiful code. Sure, the result matters - but the art of programming is how you got the result, not the result itself.

I wrote about this at length in a comment above, but I will repeat it briefly here: whatever we think art is, something that sets art aside from other stuff is that it has the ability to totally take over us, to make us forget who we are. It's not just about being really engrossing or interesting; it's almost as if art has an innate power independent of the artist, an ability to enter and penetrate us to the deepest levels of who we are and make us forget who we are, or make us cry, etc. I haven't yet felt that with any computer system that I've encountered.


I completely understand what you are saying, but to a programmer the art is the program itself - and you article is mostly being criticized by programmers (I think) because you are emphasizing the wrong things (to them).

I am a programmer - I can't say I have ever seen code that has made me cry (well some has been so bad that I have almost cried, but I think you meant cry in a good way). But I HAVE seen code that has been so elegantly constructed that it does affect me much in the same way as art. Sometimes it isn't elegance, but cleverness or conciseness that does it - the first time I was exposed to the source code for Duff's Device

http://en.wikipedia.org/wiki/Duff%27s_device

it affected me quite dramatically - I would say that little bit of programming history is definitely "art". And all it did was copy bytes...

Someone might say, "Well, I think I'm enriched when I write great code", but how will they ever be able to compare it to, say, reading Shakespeare unless they have the same skill level in coding as they do in reading literature. I wish that I could overcome this problem, but until then, I'm stuck with imperfect inferences from what the people I ask tell me. So I ask you, is programming an emotionally/spiritually nourishing activity for you that you feel has the potential to make you weep or risk your life for the way that people have done for poems and films? Do you feel the same way about reading code?


I would say yes - it is definitely spiritual on a certain level. I don't know about risking my life, but I can't think of a poem or film I would do that for either. It sounds like you have a genuine interest in the philosophical aspects of programming, i.e. the Zen of it and what it means to those who practice it. I think one important point you miss is that (to a lot of programmers) the more developed the tools are the _less_ interesting it all becomes. Or to put it another way, the more challenging it is to create elegance the more "weight" is given to the effort (by other programmers).

Creating better tools can create better results and can increase productivity, lower defect rates, yada yada - but it can rob the programmer of the act of discovering better ways to do things on their own and the tools generally act as abstraction layers of some kind between the programmer and what actually happening.

A really good programmer uses the tools because they make things faster and easier for them - but they also strive to know and understand exactly what the tools are doing for them. As such, they are simply a productivity add.

I would use the analogy of a typesetter - they originally carved the fonts and laid out each page by hand, but as soon as full page printing casts became feasible they were used because it was much more productive. But the "art" of it was still in the design of the type itself - the castings were just a productivity tool.

To a modern computer user, you can certainly say that type selection is a form of artistic expression - but they don't actually create the type, they are simply selecting it. I would wager those mostly really old and now dead guys that created those fonts would find that awfully insulting - that is how an experienced programmer might feel when they see people who don't know what they are doing using their tools as crutches. From the programmer's point of view there is no art in it. I'm not saying this feeling is logically justified - but that doesn't change the fact that it is there. The tools in a sense diminish the art of it all.

Reply Score: 2

RE[3]: cringe
by earksiinni on Thu 8th Apr 2010 17:03 UTC in reply to "RE[2]: cringe"
earksiinni Member since:
2009-03-27

I think you are missing the point because when you say "craftsmanship" to a programmer what comes to their mind is the elegance in which a particular piece of functionality is expressed in the source code. What the code does, i.e. the result - is not really the point. To a programmer, craftsmanship is writing beautiful code. Sure, the result matters - but the art of programming is how you got the result, not the result itself.


Lol. Yes, I can see now that my fatal flaw was that I defined what I meant by "craftsmanship" near the end of the second page. As I've said elsewhere in the comments, by no means did I mean that people who code with MVC or any paradigm write inelegant, ugly code, or that they lack talent or artistry or any of that. I'm using craftsmanship in a very specific sense, it's on page 2 of the article and also elsewhere in these comments. I think I've also made it clear that I myself am a programmer, albeit not as my profession and I haven't gone as deeply as many others have into it, so I really don't mean any of this in an adversarial tone.

I am a programmer - I can't say I have ever seen code that has made me cry (well some has been so bad that I have almost cried, but I think you meant cry in a good way). But I HAVE seen code that has been so elegantly constructed that it does affect me much in the same way as art. Sometimes it isn't elegance, but cleverness or conciseness that does it - the first time I was exposed to the source code for Duff's Device

http://en.wikipedia.org/wiki/Duff%27s_device

it affected me quite dramatically - I would say that little bit of programming history is definitely "art". And all it did was copy bytes...


Wow...that is really elegant. Thank you for sharing this with me, it's definitely moving...though I wouldn't say (for myself) on the same level as an excellent poem, but maybe that's just because I can't appreciate it as much. As I become a better programmer, I hope that I will be able to appreciate elegant code more and more. Are there any other examples like this that you know of? I do code, but I'm not versed in these sorts of things.

I would say yes - it is definitely spiritual on a certain level. I don't know about risking my life, but I can't think of a poem or film I would do that for either. It sounds like you have a genuine interest in the philosophical aspects of programming, i.e. the Zen of it and what it means to those who practice it. I think one important point you miss is that (to a lot of programmers) the more developed the tools are the _less_ interesting it all becomes. Or to put it another way, the more challenging it is to create elegance the more "weight" is given to the effort (by other programmers).

...

I would use the analogy of a typesetter - they originally carved the fonts and laid out each page by hand, but as soon as full page printing casts became feasible they were used because it was much more productive. But the "art" of it was still in the design of the type itself - the castings were just a productivity tool.


From what I understand, you've made two really great points: first, that the act of coding is the art itself, and second, that the tools are only secondary to that art. I think that your second point is treating tools differently than I had thought of, and if we're talking about, say, gdb or valgrind or nm or something like that, then yes, I agree with you 100%. The experience is about the coding (the font design, not the castings) itself.

But the core of my argument has to do with the interaction between content and format, and in this regard maybe we need to revisit the principles behind vi or emacs or Eclipse; or "tool" in a different sense, like keyboards and mice, or HTML. Now, if the art is in the document we create, which is what I was assuming, then it really is important to talk about these tools and question how sane they are. To take it back to your typesetter analogy, the codex and the page would be the "tools" under consideration rather than the castings, which have to do with the typesetter's act rather than the writer's act, and these tools are completely bound up with the content/art because they give the content/art its format. Moreover, how you create that content depends on which of those formatting tools are available, and in that sense the craftsman-style of creating content is dying out in computers because the appropriate tools are not being developed...

BUT, what you're saying, if I understood you correctly, is very different and also really interesting: the act of coding is the art itself, which is also true of the craftsman, whose act of creating is itself art (I will get to that once I reply to your next post in this thread). I have to think about this for a while, because there are some really complicated issues at play: is the programmer the writer and the typesetter? Are formatting tools relevant for the art if the art is the act of writing the code itself, or even perhaps writing the formatting itself? If not, where does that leave the code--can that be art, the way that a novel is art? Etc. When I write back hopefully you'll still be interested and this thread won't be dead =).

Reply Score: 1

RE[2]: cringe
by galvanash on Thu 8th Apr 2010 08:19 UTC in reply to "RE: cringe"
galvanash Member since:
2006-01-25

The craftsman model means that the same person does the both in the same document in a single act, and for computers I don't think that we have the tools yet to do that.


You have said something along these lines multiple times in your article and in your posts and it puzzles me... You gave the example of a cabinet maker as a craftsman, so I assume you consider cabinet making "craftsmanship".

I make websites. I use many different technologies. I use HTML to present content, CSS to format it, javascript to make it do different things, databases to store it, web servers to move it around, etc. etc. I often work with others in a team to accomplish this, but I certainly can do it alone (and often do).

A cabinet maker makes cabinets. He/she uses a saw to cut the wood, a sanding block to shape it, stain and a brush to give it color, etc. etc. He/she can work in a team to accomplish this, but can certainly do it alone also.

How is that any different? If the difference is not the quality of the product, then it must be the method used to create it. I would assume you would say if a cabinet was built by hand by a cabinet maker it would represent "craftsmanship", but if it came of a machine assembly line it wouldn't be. You can usually (but not always) tell the difference by simply looking at the end product - but sometimes the machined product is so good it is hard to tell.

I see nothing that separates cabinet making from web development. They both require multiple tools and experience in multiple disciplines to create an end product - and they require multiple "acts" to achieve their ends. Where does the distinction lie?

Reply Score: 2

If anyone's still reading
by earksiinni on Thu 8th Apr 2010 05:44 UTC
earksiinni
Member since:
2009-03-27

Seems like a lot of people see a lot of gaps in my knowledge of MVC and programming--fair enough! What specifically? I was hoping someone could point out my factual errors so that I can correct them in the future.

Thanks!

Reply Score: 1

Comment by Paradroid
by Paradroid on Thu 8th Apr 2010 09:22 UTC
Paradroid
Member since:
2010-01-05

Maybe I'm not understanding the core point here, but let's remember that a web browser (or even a developer reading the HTML page markup) generally has no idea if a web app is MVC or not. Regardless of the backend techonlogy, a browser always gets given what appears to be a static HTML page, it's just that behind the scenes it is (in 2010) unlikely to be stored on the server that way.

MVC is a backend technology for writing web apps, in fact I would say it makes HTML 5 all the more important. Certainly in the ASP.NET world, you used to write pages using ugly server controls that wrote out their own markup which you had little control over. With the MVC framework for ASP.NET you're back to coding pure HTML again, it's just that in certain sections of the HTML you're merging in data from your model.

The 'beauty' is behind the scenes (as you've indicated) in the massive gains in code reuse, and the great OO code that now powers web apps.

I disagree that the web is splintering too. Thanks mainly to Firefox, web standards have come a long way and most sites now make a fair attempt at outputting fairly standards compliant HTML&CSS. This means that more mobile devices can read it, not less. Yes of course there are ways of writing mobile device apps that are specific to that device, but that's only if you must have native client functionality.

At my workplace, 12 months ago we were talking about writing an iPhone app version of our site. Thankfully we didn't. Now, with Android taking off and Windows Phone 7 round the corner (plus others), it's more likely we'll write a mobile site that will work across them all.

Reply Score: 1

Comment by antwarrior
by antwarrior on Thu 8th Apr 2010 09:41 UTC
antwarrior
Member since:
2006-02-11

Ersin, I actually liked the article. It is a bit long, though, but nice job. One small thing ( actually it's quite big). "Computeral" - What on earth does this word mean?

The word only appears twice in the article, in the heading and in the first paragraph and then only 3,290 google hits with no hint of definition. Could you please use more ..uhm... accessible language in your titles next time. That is the only caveat. I look forward to more articles from you.

Reply Score: 1

RE: Comment by antwarrior
by earksiinni on Thu 8th Apr 2010 17:11 UTC in reply to "Comment by antwarrior"
earksiinni Member since:
2009-03-27

Thanks very much, antwarrior. To answer your question, "computeral" is a term I've coined to replace "digital" in a lot of cases where "digital" really isn't cutting it. By computeral, I mean something that is computer-like in its essence, in the same way we might say that a song is a form of oral communication or a book is literary (the root word for both "literary" and "literal" having to do with the same root for our word "letter", i.e. it is intrinsically related to letters and glyphs). Often times we talk about digital technology or digital formats, but I think that often using "digital" is an abuse of the term, which really implies something about the technical aspect (i.e., zeros and ones, or digits) without really touching on what's obvious to everyone, that these things are unique to computers and only make sense in the context of computers. It wouldn't make much sense to write out an MP3 file on paper in binary or hex, and yet "digital" kind of connotes that.

I probably should have included a more thorough explanation in the article, but as you said it was already growing long and so I only briefly alluded to it having to do with the "essence" or "soul" of a computer. I also included a link to an entry on my blog, http://www.whatdigitalrevolution.com/?p=108, where I first coined the term.

Reply Score: 1