Linked by Thom Holwerda on Sun 28th Jul 2013 14:06 UTC
General Development "There is a reason I use 'old' languages like J or Lush. It's not a retro affectation; I save that for my suits. These languages are designed better than modern ones. There is some survivor bias here; nobody slings PL/1 or Cobol willingly, but modern language and package designers don't seem to learn much from the masters. Modern code monkeys don't even recognize mastery; mastery is measured in dollars or number of users, which is a poor substitute for distinguishing between what is good and what is dumb. Lady Gaga made more money than Beethoven, but, like, so what?" This isn't just a thing among programmers. The entire industry is obsessed with user numbers, number of applications, and other crap that is meaningless when you consider programming to be art. When I post a new item about some small hobby operating system, the comments will be filled with negativity because it's no Windows or iOS, whereas only ten years ago, we'd have lively discussions about the implementation details. And then people wonder why that scene has died out.
Thread beginning with comment 568207
To read all comments associated with this story, please click here.
Art? Try Craft...
by jockm on Sun 28th Jul 2013 21:16 UTC
jockm
Member since:
2012-12-22

While I am sure some code can be art, and some approach it as artistry, I have yet to see good code from anyone *I* know who calls themselves that. I am less disdainful of those who call it science, but lets face it most people who call themselves computer scientists aren't actually doing science.

Programming is craft. A little artistry, a little engineering, a and a whole lot of hard work makes it a craft. My title says software engineer, but I think of myself as a craftsman. We all should really.

APL is an interesting language, every budding computer science student should learn a little of it, as they should Smalltalk and Lisp. But I have spent my 25+ year career with someone or another trying to convince everyone to switch to APL, or Lisp, or {functional language of the year}, or whatever.

Most of these languages have their place, and are very useful in their domains. However so many of them — APL, J, Lisp, Scheme, MUMPS, C++, et al — are prone to produce write only code in the hands of inexperienced coders.

Programing languages are tools, we should use them like that. Carpenters don't get into arguments that philips head screwdrivers encourage bad carpentry and we should all switch to torx. They use the best took for the job. There is no one programming language for all tasks, and we should stop this fiction that one language is somehow magically "better" than all the rest.

The article linked to was more or less useless. The writer says that "Comparing, say, Kx systems Q/KDB ... to Hive or Reddis is an exercise in high comedy", but does nothing to explain why this is the case or — god forbid — provide any proof.

He says "APL languages were developed a long time ago, when memory was tiny compared to the modern day, and disks much slower. They use memory wisely." But languages don't specify memory usage, implementations do. COBOL was first written for computers with less memory than a Apple ][+, but this doesn't mean they somehow produce tighter code or magically use less memory; and it is asinine to think it does.

I see nothing in this blog post that makes it worthy of discussion...

Reply Score: 8

RE: Art? Try Craft...
by lucas_maximus on Sun 28th Jul 2013 22:22 in reply to "Art? Try Craft..."
lucas_maximus Member since:
2009-08-18

While I am sure some code can be art, and some approach it as artistry, I have yet to see good code from anyone *I* know who calls themselves that. I am less disdainful of those who call it science, but lets face it most people who call themselves computer scientists aren't actually doing science.

Programming is craft. A little artistry, a little engineering, a and a whole lot of hard work makes it a craft. My title says software engineer, but I think of myself as a craftsman. We all should really.

...

Programing languages are tools, we should use them like that. Carpenters don't get into arguments that philips head screwdrivers encourage bad carpentry and we should all switch to torx. They use the best took for the job. There is no one programming language for all tasks, and we should stop this fiction that one language is somehow magically "better" than all the rest.


Couldn't have said it better myself.

Reply Parent Score: 3

RE: Art? Try Craft...
by acobar on Sun 28th Jul 2013 23:47 in reply to "Art? Try Craft..."
acobar Member since:
2005-11-15

While I agree to most of your points I do not think the article is useless, but I do feel there are some misconceptions on it.

Like when he complains about 'scanf'. 'scanf' was used a lot because a long time ago there were a multitude of hardware architectures, some cpu were big endian, some were the little endian and the numeric internal representation of numerical types would, and many times were, different. The only "safe" way to exchange data was to put it on ascii. Only after Intel got so dominant it became an almost non issue. "Now" (what really means, for some time) we even have libraries to facilitate data exchange. Also, if you were using PC computers on 80's there were no easy way to handle things that could not fit on available memory, the hardware and the OS were not ready. This is a non-issue now and his comments about mapped memory is somewhat dated. We use mapped memory when we see fit, at least on C or C++, and I don't see why it should be the default way to handle "automatically" reads and writes.

We had a long way from the "old" days to now. My old 'C' and 'Fortran' programs had only to deal with a couple of input files and dump the result on some output files. Programs now are way more complex and so we use libraries that are way more complex too. GUI's, networks, multithread, concurrency and so on and so forth.

There is a reason why Turbo Pascal could fit on a 360 KB disk and leave ~ 320 KB free on it. It did not has to deal with the plethora of things modern compiler and libraries have to. It did not has to deal with the plethora of things we have today. Even if we don't make use of them, they are there.

With the growing complexity, most of the limitations of the computer languages started to show up, to reveal its shortcomings, and had to be revised, new ones were created. Anyway, the hard part of programming to me never was the new syntax or the new concepts. This is something everyone can handle expending some time. The hard part is to become proficient on the "hard part" of the tools available, the libraries, their do's and their don't's.

We focus a lot on concepts, on "System Architecture/Engineering" but I feel that we should not neglect so much the libraries limits like we do when training the new generation. That is one of the reasons we had so much trouble when everything got networked. Once again, things were a bit different way, way back on past, you were supposed to be very aware of the limitations and every fault (almost, sans bugs) was "your" fault. Now libraries are supposed to handle "stupid things" because the "average" programmer do not care to check the limitations they carry. And we all blame the language or the library for that.

To couple with that we created managed code. And we encapsulated the old libraries on "nice" costumes. Is this really the best option? Do we create better developers this way? Letting them ignore the limitations? I don't know but, sure, learn how to do "Hello world!" on 10 different languages because "this should be handled automatically" or "differently" does not looks like the right answer to me.

Reply Parent Score: 4

RE: Art? Try Craft...
by Soulbender on Mon 29th Jul 2013 02:28 in reply to "Art? Try Craft..."
Soulbender Member since:
2005-08-18

I wish I could mod you up but alas, we are still not treated like grownups here.

Reply Parent Score: 2