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 568230
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Art? Try Craft...
by acobar on Sun 28th Jul 2013 23:47 UTC 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