You know, technically there are more recent Fortran specs. Fortran gets hauled out in the form of FORTRAN77 every time someone wants to talk trash about an old language. However, just like C or C++ or Java, the language has evolved. Fortran 2003 has objects, a pretty cool module system and basic thread support. Fortran 2008 will have explicit support for splitting data over multiple cores (co-arrays). I don't know much about COBOL, except that some of the largest codebases in the world are written in COBOL.
I fail to see the force you are ascribing to them -- if you don't like it, don't use it, right? I am still in perpetual awe of the software that I use and the generosity of the people who work on it for free. I suppose it's when that awe wares off that one starts expecting even more.
Re:Nope, it's the putative new users problem
on
Linux Needs Critics
·
· Score: 1
The unanswered question here is "what reason does that guy have not to put in those 4 commands?". I really wonder about the motivation of guys developing these "friendly" GUIs. Where I work I often write a couple of scripts to automate some of my repetitive work. I am then often reproached by colleagues for not making them easier for them to use. Now, I have tried and failed at the whole GUI thing -- I get so fed up that I am no longer solving my problems that I just toss the whole thing and go back to my CLI. Surely only the paid guys working for Red Hat or Suse can afford to work on making their stuff user friendly in ways that make it harder for them to use.
To put it shortly: If the developers thought it was bad, they would change it (and would appreciate a new perspective they agreed with), but when they disagree about the usability, what motivation do they have to change it?
From what I've read the figures seem to suggest two things: 1. Programmers produce similar lines of code per hour in most languages. 2. Language expressiveness differs, so some languages get more things done per line of code. These two things translate to my idea of using the most expressive language I can get my hands on. Existence of libraries and such also factor into the equation, which is probably why APL doesn't see such a lot of use.
Now, it is also true that some compilers/interpreters are more efficient than others (note that languages aren't efficient per se). But rewriting code is a lot faster than writing it for the first time regardless of language. The efficient compilers tend to be paired with the less expressive languages (mostly because it's harder to write compilers for the more expressive languages), but you can make up for it by profiling your short program and rewriting the parts that are slow in a language for which an efficient compiler exist.
As for not seeing productivity gains from writing less lines of code, remember that was what the assembly guys said when Fortran came out.
I don't really get that from reading anything he's ever written on the subject. He's definitely not making big bank now, and when he wants to use software he either writes it himself or uses Free Software. He's not forcing anyone to do the same, and I guess his idealism reminds one of religious types, but at least he's consistent and has done more good than harm.
Language convention is a way of reducing the load of communication, just like programming language conventions. If you're not following the conventions (appropriate to the time) you place a larger cognitive burden on your audience. You also run the risk of being misunderstood (as in the ambiguity of the 47% quoted in the summary). While it is true that this is not a right or wrong issue, and that accepted usage varies widely even for the same language, it seems reasonable to encourage people who are using ambiguous or non-conventional language to adhere to the conventions.
My experience is that people with programming experience develop a skill for seeing errors in spelling and grammar as potential bugs in programming languages, because compilers tend to be quite strict about these things. This skill then transfers to human language, leading to an urge to correct these errors. They also tend to appreciate being corrected, so the whole group feeds back this behaviour.
I love my Mac, but I must say that application installation is not always that easy. These days many applications have.pkg installers (even some from Apple) and it is entirely non-obvious how to uninstall these applications. Even worse, to make sure I have the latest version of the application I use, each one has to check for newer versions individually when I happen to be using them (instead of when I want to update all of them). I really miss package management on my mac.
Excel is programming as much as Prolog or Haskell is programming. It is declarative and functional, but it is still programming. I would bet that, given an infinite spreadsheet, you would find Excel is Turing complete. I don't like Excel for big programming jobs myself, but you have to realise how much it is being used.
Of course you're going to sell a single GUI program to the market these days, but I was talking about programming to get stuff done. But that seems to be a big theme I missed -- the idea of someone programming to get their job done instead of paying money for someone else to write a GUI to do their job is fading. So much so that even the people wanting to program for themselves are better off using the tools that the other programmers use because there's more support for that approach.
Know it, don't like it, doesn't do the things I want to do (data processing and matrix/vector math) all that well or as quickly as a combination of scripting for the text stuff and Fortran for the numerics. Perhaps with some Python for higher-level stuff. Perhaps with Java for cross-platform GUI. I know plenty of "All C, all the time" guys and they seem content. They also spend a lot of time coding around C. The existence of other languages that were developed after C basically proves that C is not the last word.
I happen to be a control engineer, so I spend most of my time processing large amounts of data from measurements and experiments. I find C/C++ syntax terrible for matrix/vector stuff, while Fortran (>=95) is well-suited for it, including having damn efficient compilers. I started with Matlab at University, but the licensing issues really got me down.
This is exactly what I'm talking about -- I've chosen languages based on what works in terms of syntax, performance and suitability to the job at hand, but these days popularity and homogeneity seem to be more important for long-term success.
The premise is that the modern approach seems to be to learn one language and its associated libraries well instead of learning several languages and when each applies to a problem. Basically, the Java for everything guys and the c or c++ for everything guys. This is supported by huge, well-developed and supported environments like VS and Eclipse, well-organized sets of documentation and an ever-increasing community.
When I started on the whole linux thing, what I am doing now was the default position -- you had to learn a lot about the terminal and low-level stuff just to get Linux going. Once you figured the Unix Way out, it helps you to be very productive and you end up building a lot of tools to help you. You may build some of them in different languages, just because certain languages match certain types of problem. A lot has changed since '97, and I'm wondering whether it's time to press through in C++ when I know the job I'm doing now is really suited to xsl or awk or whatever.
I think you missed the emphasis in that question. I already know and use several imperative languages (primarily Fortran as I do a lot of numeric work, but I also know and use both c and c++). I was not asking whether I should learn c++, but whether I should learn to use it for things that I don't use it for now. I would rather use awk/perl/python for basic text-processing type tasks or 'throw-away' scripting and once I have an awk script that does exactly what I want I would rather not rewrite it in c++ just because I want everything to be in one language.
If that were true wouldn't there just be one language by now? I have studied the fundamentals of CS and one thing that one learns is that Turing completeness is a very low bar. Observe the many Turing tarpits and the or the proliferation of domain specific languages. I have not spent my time learning all these languages because I am ignorant.
I get worried when a lowish UID person on slashdot is so blase about the commandline. I own a mac and I do most of the file stuff in the command line. On my work machine, I don't even have a GUI file browser installed. When you are handling lots of files, nothing else really makes sense, unless you are doing something common enough to have been GUIfied, like MP3 or photo management.
I have tried many times to use file managers, but I always feel like my hands are chopped off when I try to do even basic stuff like 'move all the PDFs in directory A to directory B', or 'find all the files in my Documents folder that are newer than File A'. Probably the only place where a graphical interface contributes is if the files have a reasonable graphical interpretation and are not named consistently, like a random dump of images from someone's flash disk.
paste said commands to a file to execute later once I see they work
pretty up the commands
rewrite in Python
rewrite parts in some compiled language if things are too slow
wrap a GUI over parts of it if other people need to use it
.
The advantages are rapid prototyping, and many places to stop putting work into the project without losing functionality. If you have a really well defined large project, big design up front makes sense, but shell scripts tend to grow out of "man, that's like the third time today I had to build that pipeline, let's save it". Now, of course, the scripts are brittle and don't give good feedback on what exactly went wrong, but the tasks they do are not so time consuming that it justifies creating a well-written program to do them.
Slashdot Mirror
You know, technically there are more recent Fortran specs. Fortran gets hauled out in the form of FORTRAN77 every time someone wants to talk trash about an old language. However, just like C or C++ or Java, the language has evolved. Fortran 2003 has objects, a pretty cool module system and basic thread support. Fortran 2008 will have explicit support for splitting data over multiple cores (co-arrays). I don't know much about COBOL, except that some of the largest codebases in the world are written in COBOL.
I fail to see the force you are ascribing to them -- if you don't like it, don't use it, right? I am still in perpetual awe of the software that I use and the generosity of the people who work on it for free. I suppose it's when that awe wares off that one starts expecting even more.
The unanswered question here is "what reason does that guy have not to put in those 4 commands?". I really wonder about the motivation of guys developing these "friendly" GUIs. Where I work I often write a couple of scripts to automate some of my repetitive work. I am then often reproached by colleagues for not making them easier for them to use. Now, I have tried and failed at the whole GUI thing -- I get so fed up that I am no longer solving my problems that I just toss the whole thing and go back to my CLI. Surely only the paid guys working for Red Hat or Suse can afford to work on making their stuff user friendly in ways that make it harder for them to use.
To put it shortly: If the developers thought it was bad, they would change it (and would appreciate a new perspective they agreed with), but when they disagree about the usability, what motivation do they have to change it?
You know, that begs the question: "is there a methodology for improving literacy?"
From what I've read the figures seem to suggest two things: 1. Programmers produce similar lines of code per hour in most languages. 2. Language expressiveness differs, so some languages get more things done per line of code. These two things translate to my idea of using the most expressive language I can get my hands on. Existence of libraries and such also factor into the equation, which is probably why APL doesn't see such a lot of use.
Now, it is also true that some compilers/interpreters are more efficient than others (note that languages aren't efficient per se). But rewriting code is a lot faster than writing it for the first time regardless of language. The efficient compilers tend to be paired with the less expressive languages (mostly because it's harder to write compilers for the more expressive languages), but you can make up for it by profiling your short program and rewriting the parts that are slow in a language for which an efficient compiler exist.
As for not seeing productivity gains from writing less lines of code, remember that was what the assembly guys said when Fortran came out.
How many people on Slashdot listen to old Stones? Nice one.
I don't really get that from reading anything he's ever written on the subject. He's definitely not making big bank now, and when he wants to use software he either writes it himself or uses Free Software. He's not forcing anyone to do the same, and I guess his idealism reminds one of religious types, but at least he's consistent and has done more good than harm.
Not to mention that the plural of Mac would be Macs.
Language convention is a way of reducing the load of communication, just like programming language conventions. If you're not following the conventions (appropriate to the time) you place a larger cognitive burden on your audience. You also run the risk of being misunderstood (as in the ambiguity of the 47% quoted in the summary). While it is true that this is not a right or wrong issue, and that accepted usage varies widely even for the same language, it seems reasonable to encourage people who are using ambiguous or non-conventional language to adhere to the conventions.
My experience is that people with programming experience develop a skill for seeing errors in spelling and grammar as potential bugs in programming languages, because compilers tend to be quite strict about these things. This skill then transfers to human language, leading to an urge to correct these errors. They also tend to appreciate being corrected, so the whole group feeds back this behaviour.
I love my Mac, but I must say that application installation is not always that easy. These days many applications have .pkg installers (even some from Apple) and it is entirely non-obvious how to uninstall these applications. Even worse, to make sure I have the latest version of the application I use, each one has to check for newer versions individually when I happen to be using them (instead of when I want to update all of them). I really miss package management on my mac.
Excel is programming as much as Prolog or Haskell is programming. It is declarative and functional, but it is still programming. I would bet that, given an infinite spreadsheet, you would find Excel is Turing complete. I don't like Excel for big programming jobs myself, but you have to realise how much it is being used.
I highly recommend you read Guns, Germs, and Steel for a well-thought out argument on this topic.
So, either you think that Mono is great or that I should not only learn .net, but also learn Windows development even though I am quite happy in linux?
Of course you're going to sell a single GUI program to the market these days, but I was talking about programming to get stuff done. But that seems to be a big theme I missed -- the idea of someone programming to get their job done instead of paying money for someone else to write a GUI to do their job is fading. So much so that even the people wanting to program for themselves are better off using the tools that the other programmers use because there's more support for that approach.
Know it, don't like it, doesn't do the things I want to do (data processing and matrix/vector math) all that well or as quickly as a combination of scripting for the text stuff and Fortran for the numerics. Perhaps with some Python for higher-level stuff. Perhaps with Java for cross-platform GUI. I know plenty of "All C, all the time" guys and they seem content. They also spend a lot of time coding around C. The existence of other languages that were developed after C basically proves that C is not the last word.
I happen to be a control engineer, so I spend most of my time processing large amounts of data from measurements and experiments. I find C/C++ syntax terrible for matrix/vector stuff, while Fortran (>=95) is well-suited for it, including having damn efficient compilers. I started with Matlab at University, but the licensing issues really got me down.
This is exactly what I'm talking about -- I've chosen languages based on what works in terms of syntax, performance and suitability to the job at hand, but these days popularity and homogeneity seem to be more important for long-term success.
The premise is that the modern approach seems to be to learn one language and its associated libraries well instead of learning several languages and when each applies to a problem. Basically, the Java for everything guys and the c or c++ for everything guys. This is supported by huge, well-developed and supported environments like VS and Eclipse, well-organized sets of documentation and an ever-increasing community.
When I started on the whole linux thing, what I am doing now was the default position -- you had to learn a lot about the terminal and low-level stuff just to get Linux going. Once you figured the Unix Way out, it helps you to be very productive and you end up building a lot of tools to help you. You may build some of them in different languages, just because certain languages match certain types of problem. A lot has changed since '97, and I'm wondering whether it's time to press through in C++ when I know the job I'm doing now is really suited to xsl or awk or whatever.
I know many languages and their strengths -- the question wasn't about not knowing any language, but not wanting to use just one on a given project.
It is the Unix philosophy, as expressed in many places like The art of Unix programming or here (first paragraph, "small, sharp tools") or the Pragmatic Programmers (under Occam's razor).
I think you missed the emphasis in that question. I already know and use several imperative languages (primarily Fortran as I do a lot of numeric work, but I also know and use both c and c++). I was not asking whether I should learn c++, but whether I should learn to use it for things that I don't use it for now. I would rather use awk/perl/python for basic text-processing type tasks or 'throw-away' scripting and once I have an awk script that does exactly what I want I would rather not rewrite it in c++ just because I want everything to be in one language.
If that were true wouldn't there just be one language by now? I have studied the fundamentals of CS and one thing that one learns is that Turing completeness is a very low bar. Observe the many Turing tarpits and the or the proliferation of domain specific languages. I have not spent my time learning all these languages because I am ignorant.
"A witty saying proves nothing" - Voltaire.
I get worried when a lowish UID person on slashdot is so blase about the commandline. I own a mac and I do most of the file stuff in the command line. On my work machine, I don't even have a GUI file browser installed. When you are handling lots of files, nothing else really makes sense, unless you are doing something common enough to have been GUIfied, like MP3 or photo management.
I have tried many times to use file managers, but I always feel like my hands are chopped off when I try to do even basic stuff like 'move all the PDFs in directory A to directory B', or 'find all the files in my Documents folder that are newer than File A'. Probably the only place where a graphical interface contributes is if the files have a reasonable graphical interpretation and are not named consistently, like a random dump of images from someone's flash disk.
.
The advantages are rapid prototyping, and many places to stop putting work into the project without losing functionality. If you have a really well defined large project, big design up front makes sense, but shell scripts tend to grow out of "man, that's like the third time today I had to build that pipeline, let's save it". Now, of course, the scripts are brittle and don't give good feedback on what exactly went wrong, but the tasks they do are not so time consuming that it justifies creating a well-written program to do them.