I've been thinking about this thread, and how I view certain programming languages. Except for C++, the languages I program in recreationally are usually not the languages I use for my job. For over two decades I've been programming in C/C++, C#, Java, JavaScript, and occasionally Objective C. But recreationally I've programmed in all manner of languages including: C++, Forth, Lisp, Logo, PBasic, Spin, PHP, and Python.
The languages in the first group tend to have high startup costs, and discourage exploration. But they tend to encourage consistency and division of labor which becomes useful in large teams.
The languages in the second group tend to have low overhead and start up costs, be fun to use, and encourage exploration. They tend to encourage a single person to run with the whole project, but often with idiosyncratic solutions.
The obvious question is why wouldn't I want to use the fun to use languages at work? I think the issue is I've been working on large teams which creates a situation where you're always fighting anarchy and entropy. High levels of structure are needed to prevent a project from getting bogged down. It's also not uncommon for code to be in production for a decade, all the original team is long gone, and it suddenly requires modification. At that point you have to reverse engineer the whole thing and clear straight forward design patterns with good comments are a godsend.
For example the structure of a Java Web project is so consistent, that when you encounter orphaned code it's perfectly obvious how to proceed with reverse engineering it. If you are lucky the original authors used Java doc comments and all their classes have documented API's. But while I've had fun writing some Forth code, it's too idiosyncratic to use in this manner.
So for work languages I'm always asking myself 'how likely is this language to encourage entropy and anarchy?" But for fun I'm always asking "what fun things will this language enable me to do?"
The obvious question is why wouldn't I want to use the fun to use languages at work? I think the issue is I've been working on large teams which creates a situation where you're always fighting anarchy and entropy.
That's first good reason I've ever seen anyone give for avoiding Perl!
Perl is pretty much a one-person dev tool. I cannot imagine assigning -- or being assigned -- just part of a large Perl programming project. But I'm just a one-man shop, and I don't play nice with others. So Perl suits me fine.
People have have had a lot to say about that over the years, that's why we have programming methodologies and languages like C++, Ada, Eiffel etc that support, functions, classes, objects, methods, modules, namespaces and whatever. Thousands of books have been written about it and lot's of gurus have gotten rich consulting on it.
This is not about programming a computer, after all you computer does not care if you have a class hierarchy or not, it's about organising teams of people and enabling them to work together. It's about design, it's about divide and conquer, identifying parts, putting boundaries around them, specifying their function and their interfaces, and so on.
The reason for all that extra text you have to type in C++ or Ada is more to do with communicating intent to other programmers on the team than it is about checking types for correctness. It's about making abstractions, patterns that are commonly understood.
"Programming in the large" is nothing to do with the size of the finished program. For example you can easily create a program today that uses, oh I don't know, HTTP, websockets, XML, encryption, a database and so on. One man can do all that in a day. Sometimes I marvel at this because back in the 80's I have worked in huge project teams where they were building such things from the ground up. Thousands of man hours, millions of lines of code. Today it's just a line of JS and library away!
No, "programming in the large" is about people, lot's of them, working together and how to divide that work up in sensible, meaningful and productive ways. Languages designed for programming in the large are the way such people communicate.
This of course all breaks down on the web.
In my company we have: Major chunks of code, the cleaver stuff, written in Pascal. Server side stuff in C++, PHP, Python, Javascript. All selected for very good reasons no doubt by whoever was responsible for whatever it is. In that mess I would include, HTML, CSS, and SQL. At the client end we have JS in browsers, C++ in applications.
What a mess. Not atypical I believe.
All of a sudden, all those nice features put into C++, Ada, Eiffel etc for programming in the large are not helping one bit. The "large" is now "out there" a tower of Babel of different technologies. Where is the design for all of that? Where are the partitions and interfaces defined?
Nowhere.
Perhaps in in the specs and documentation. If you are lucky there are XML schema defined for your interfaces. The design is certainly not expressed formally in any of the languages in use.
In that mess many have concluded that they might as as well do it all in a dynamic language to the same effect.
"Programing in the Large and Programming in the small" is quite interesting... especially since this was written in 1975.
It pretty much valibates JavaScript at one extreme and Forth at the other. Personally, I have long avoided "Programming in the Large" as programming is a hobby for me and the smallest offers me more personal satisfaction. But the truth is that everyone has different ambitions and enjoys a different level of social interaction with their own creative processes.
I just may have to buy a copy of the PDF for $15USD. In 1975, UC at Santa Cruz was a very actively player in software development. http://dl.acm.org/citation.cfm?id=808431
This thread has included a lot of talk about statically typed vs dynamically typed languages. And now we get on to "programming in the large" which has always been the killer argument in favour of statically, and strongly, typed languages.
But now I make a strange observation:
One of the largest software projects on the planet ever, in terms of code size, number of contributors, rate of change, complexity and longevity is the Linux kernel.
Oddly enough Linux is written in C. A language that has a very poor type safety system whilst at the same time lacking the luxuries of dynamic languages.
What's up with that?
The sheer magnitude of the Linux project and it's resulting reliability seems to demonstrate that all that rigorous type checking is not actually required for programming in the large.
Linux developers will happily admit that it's impossible to test the kernel and drivers. At least not in the way that you might with unit tests and so on. So my "rely on testing instead of static type checking" goes out the window as well!
Oddly enough Linux is written in C. A language that has a very poor type safety system whilst at the same time lacking the luxuries of dynamic languages.
What's up with that?
Good programmers can write good programs in any language. Bad programmers need all the help they can get. Unfortunately, not all programmers are good, and often you only find that out during a code review, just before code freeze. At that point the senior programmers on the team often have to rewrite modules as fast as possible, over the weekend. I've had a number of nasty surprises dropped in my lap over the years, and frankly I hate it. Usually in the more flexible languages result in more nasty surprises. Hence my suspicion of JavaScript and Perl. Forth would be an absolute nightmare.
The Linux guys have a huge advantage of a nearly unlimited pool of labor to draw upon, most other shops often struggle to fill openings. So when the labor pool has a much higher degree of variation you need better structure.
Years ago I worked, as a freelance contractor, on a military communications project. One day the project manger was angrily throwing listings into the bin (See how long ago that was). After which he turned to me and said "Why do I have to have all these guys working for me if I have to come in every weekend and rewrite what they have done?"
He was a odd chap by the way. He confided in me that he had no formal education after leaving school and spend the first decade of his adult life making a living by dealing dope and writing mods for the 8 bit video games. Reverse engineering and hacking the binaries! He was one mean programmer who looked at me very sourly when I first arrived on the job. "Here is another one" he must have thought. We ended up getting on very well and my contract kept getting extended so I guess I met his approval eventually.
Whilst we are on war stories:
A few years back I had a team of three bright young C++ contractors working for us on an embedded project. When the project end date arrived and they were all let go I found they had left me with a ton of memory leaks that would eventually bring the system down. Nothing could be deployed until I fixed them. Which was interesting as that was my first C++ project and I had yet to realize the full horror of how huge and tangled the C++ language is.
Thank goodness for valgrind! That and some seriously long days saved us.
Conclusion: Again, testing as you go is very important. The static, compile time, checking of C++ did not prevent that disaster.
As for the Linux thing. The magic about Linux is that there is no "pool of labour". There is just a bunch of people and groups throwing code at it for whatever reason they have. Linus Torvalds and his "lieutenants" can accept or reject that code as they please. If it bad or if it does not get written then it just does not exist. They cannot order it from a pool of labor.
This thread has included a lot of talk about statically typed vs dynamically typed languages. And now we get on to "programming in the large" which has always been the killer argument in favour of statically, and strongly, typed languages.
But now I make a strange observation:
One of the largest software projects on the planet ever, in terms of code size, number of contributors, rate of change, complexity and longevity is the Linux kernel.
Oddly enough Linux is written in C. A language that has a very poor type safety system whilst at the same time lacking the luxuries of dynamic languages.
What's up with that?
The sheer magnitude of the Linus project and it's resulting reliability seems to demonstrate that all that rigorous type checking is not actually required for programming in the large.
Linux developers will happily admit that it's impossible to test the kernel and drivers. At least not in the way that you might with unit tests and so on. So my "rely on testing instead of static type checking" goes out the window as well!
From what I have read, Linus Torvalds still reads all the Linux kernal code and feels that C++ is in appropriate. I suspect the argument is 'the dependency on a flawless language" versus "the dependency on the professional skills of the programmer." Somebody actually has to be be the project manager and be able to oversee the project. Such a person exerts their leadership by the choice of tools.
A few years back I had a team of three bright young C++ contractors working for us on an embedded project. When the project end date arrived and they were all let go I found they had left me with a ton of memory leaks that would eventually bring the system down. Nothing could be deployed until I fixed them. Which was interesting as that was my first C++ project and I had yet to realize the full horror of how huge and tangled the C++ language is.
Thank goodness for valgrind! That and some seriously long days saved us.
...
Conclusion: Again, testing as you go is very important. The static, compile time, checking of C++ did not prevent that disaster.
Actually the conclusion is that people with no long term interest in a project won't be likely to be all that diligent.
As for the Linux thing. The magic about Linux is that there is no "pool of labour". There is just a bunch of people and groups throwing code at it for whatever reason they have. Linus Torvalds and his "lieutenants" can accept or reject that code as they please. If it bad or if it does not get written then it just does not exist. They cannot order it from a pool of labor.
In a sense their "pool of labor" are volunteers from the entire planet. If someone in Moldavia really needs a USB 3.0 driver for some obscure hardware, and the quality is is high enough, the Linux kernel gets support. Most projects don't have that luxury. Even if they went open source they wouldn't draw volunteers to contribute code. This means they have to pay for each line of code contributed, and since resources are finite this narrows their labor pool.
That attitude really pisses me off and it's not always the temporary contractors that have it.
For many years I worked as a freelance programmer in England and spent time in many different companies large and small. Most of the "peer contractors" I worked with were very enthusiastic and dedicated to getting projects working. Partly because that is the kind people they were and partly because having well known and successful projects on your resume is a good idea. For myself I was often thrilled at being involved projects, I could not imagine being unenthusiastic about it's success. I mean, how did I ever end up getting to play with huge 3D phased array radars or Boeing fly by wire systems or Rolls Royce jet engines and so on.
On the other hand there worst cases were often the permanent staff in big companies. They clock in, they clock out, they seem to get no joy out of what they are doing, they do enough to get by. I often wondered why they must have worked so hard to get to such positions if it bores them so much.
Religion is a very personal thing. My religion is best for me.
The P2 is eventually going to host its own development… when that day comes, we are going to want the P2 to direct a lot of resources through some kind of scripting interface…. and vice versa.
Isn't Javascript the only viable cross platform candidate, since it is the most widely adopted and supported?
Isn't Javascript the only viable cross platform candidate, since it is the most widely adopted and supported?
Until Node.js came along I had only seen JavaScript used in two environments. The browser where it scripted DOM manipulations, and Windows Scripting Host (WSH) as one of the supported scripting engine. I hadn't seen it used in any other environment. It's starting to spread, but it isn't nearly as ubiquitous as something like Python or Perl.
Isn't Javascript the only viable cross platform candidate, since it is the most widely adopted and supported?
Until recently I would have thought that anyone suggesting JS on a micro-controller was out their minds. I mean, JS engines are huge. They need loads of memory to run in, JS is interpretted and will be horrible slow.
That is until Gordon Williams turned up with his TinyJS for micro-controllers and now the Espruino project.
And then as if by magic we now have Micro Python which also runs on micro-controllers. I have never seen it in action so I don't know how well it works.
Ok, I fetched an "Execute JS" plugin for my Mozilla browser. Simple things appear to work. This didn't. No result. I don't know enough yet to understand what else might be needed.
O.M.G. Look! It's the new PERL with a little Mindf*** mixed in. (Moderators, yes I know, but that is the real name of it! What's a guy to do? I thought about linking it...)
Somebody had to author that with a program. Please tell me they did.
And look! Heater got me to install the JS tool. Now I can play with things in my idle time... JS sure is easy that way. Really.
The output of that program goes to console.log so in the browser you will need to open up it's Javascript console to see anything. The console is under Tools in the Chrome menu. No idea about other browsers. No idea what happens with the Execute JS plugin.
I thought I thought about thinking about it too. But perhaps I just imagined thinking that thought. Then I thought about thinking about something else instead. I thought that was too hard to think about so ended up thinking this. I think.
Oh you said "linking". I thought all that for nothing
Anyway, you are on the right track with brain****.
I have no idea what JS tool that is. I suggest installing node.js. http://nodejs.org/ You will be building web applications for controlling your Propellers via serial port in no time.
Yep, I found the console and the execute thing simply provides a nice UI to execute code. I've plugged in some simple JS and got the expected output. Maybe this mess is getting formatted somehow... I'll attempt it again later on.
I will end up doing the installation as that is a place I want to go, just not yet.
For all those lost souls out there that have yet to be enlightened as to the wonders of JavaScript I offer a belated Christmas present.
Who will be the first to run the following under node.js or in the browser and reveal the message it outputs?
Very clever! I just ran it under nodejs - I have no idea how it is doing what it is doing or how you came up with it but very clever!
(it's kind of frightening what might be going on inside that head of yours!)
Comments
The languages in the first group tend to have high startup costs, and discourage exploration. But they tend to encourage consistency and division of labor which becomes useful in large teams.
The languages in the second group tend to have low overhead and start up costs, be fun to use, and encourage exploration. They tend to encourage a single person to run with the whole project, but often with idiosyncratic solutions.
The obvious question is why wouldn't I want to use the fun to use languages at work? I think the issue is I've been working on large teams which creates a situation where you're always fighting anarchy and entropy. High levels of structure are needed to prevent a project from getting bogged down. It's also not uncommon for code to be in production for a decade, all the original team is long gone, and it suddenly requires modification. At that point you have to reverse engineer the whole thing and clear straight forward design patterns with good comments are a godsend.
For example the structure of a Java Web project is so consistent, that when you encounter orphaned code it's perfectly obvious how to proceed with reverse engineering it. If you are lucky the original authors used Java doc comments and all their classes have documented API's. But while I've had fun writing some Forth code, it's too idiosyncratic to use in this manner.
So for work languages I'm always asking myself 'how likely is this language to encourage entropy and anarchy?" But for fun I'm always asking "what fun things will this language enable me to do?"
Perl is pretty much a one-person dev tool. I cannot imagine assigning -- or being assigned -- just part of a large Perl programming project. But I'm just a one-man shop, and I don't play nice with others. So Perl suits me fine.
-Phil
Now you are talking. What you are coming to has often been referred to as "programming in the large".
http://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small
People have have had a lot to say about that over the years, that's why we have programming methodologies and languages like C++, Ada, Eiffel etc that support, functions, classes, objects, methods, modules, namespaces and whatever. Thousands of books have been written about it and lot's of gurus have gotten rich consulting on it.
This is not about programming a computer, after all you computer does not care if you have a class hierarchy or not, it's about organising teams of people and enabling them to work together. It's about design, it's about divide and conquer, identifying parts, putting boundaries around them, specifying their function and their interfaces, and so on.
The reason for all that extra text you have to type in C++ or Ada is more to do with communicating intent to other programmers on the team than it is about checking types for correctness. It's about making abstractions, patterns that are commonly understood.
"Programming in the large" is nothing to do with the size of the finished program. For example you can easily create a program today that uses, oh I don't know, HTTP, websockets, XML, encryption, a database and so on. One man can do all that in a day. Sometimes I marvel at this because back in the 80's I have worked in huge project teams where they were building such things from the ground up. Thousands of man hours, millions of lines of code. Today it's just a line of JS and library away!
No, "programming in the large" is about people, lot's of them, working together and how to divide that work up in sensible, meaningful and productive ways. Languages designed for programming in the large are the way such people communicate.
This of course all breaks down on the web.
In my company we have: Major chunks of code, the cleaver stuff, written in Pascal. Server side stuff in C++, PHP, Python, Javascript. All selected for very good reasons no doubt by whoever was responsible for whatever it is. In that mess I would include, HTML, CSS, and SQL. At the client end we have JS in browsers, C++ in applications.
What a mess. Not atypical I believe.
All of a sudden, all those nice features put into C++, Ada, Eiffel etc for programming in the large are not helping one bit. The "large" is now "out there" a tower of Babel of different technologies. Where is the design for all of that? Where are the partitions and interfaces defined?
Nowhere.
Perhaps in in the specs and documentation. If you are lucky there are XML schema defined for your interfaces. The design is certainly not expressed formally in any of the languages in use.
In that mess many have concluded that they might as as well do it all in a dynamic language to the same effect.
It pretty much valibates JavaScript at one extreme and Forth at the other. Personally, I have long avoided "Programming in the Large" as programming is a hobby for me and the smallest offers me more personal satisfaction. But the truth is that everyone has different ambitions and enjoys a different level of social interaction with their own creative processes.
I just may have to buy a copy of the PDF for $15USD. In 1975, UC at Santa Cruz was a very actively player in software development. http://dl.acm.org/citation.cfm?id=808431
But now I make a strange observation:
One of the largest software projects on the planet ever, in terms of code size, number of contributors, rate of change, complexity and longevity is the Linux kernel.
Oddly enough Linux is written in C. A language that has a very poor type safety system whilst at the same time lacking the luxuries of dynamic languages.
What's up with that?
The sheer magnitude of the Linux project and it's resulting reliability seems to demonstrate that all that rigorous type checking is not actually required for programming in the large.
Linux developers will happily admit that it's impossible to test the kernel and drivers. At least not in the way that you might with unit tests and so on. So my "rely on testing instead of static type checking" goes out the window as well!
Good programmers can write good programs in any language. Bad programmers need all the help they can get. Unfortunately, not all programmers are good, and often you only find that out during a code review, just before code freeze. At that point the senior programmers on the team often have to rewrite modules as fast as possible, over the weekend. I've had a number of nasty surprises dropped in my lap over the years, and frankly I hate it. Usually in the more flexible languages result in more nasty surprises. Hence my suspicion of JavaScript and Perl. Forth would be an absolute nightmare.
The Linux guys have a huge advantage of a nearly unlimited pool of labor to draw upon, most other shops often struggle to fill openings. So when the labor pool has a much higher degree of variation you need better structure.
Years ago I worked, as a freelance contractor, on a military communications project. One day the project manger was angrily throwing listings into the bin (See how long ago that was). After which he turned to me and said "Why do I have to have all these guys working for me if I have to come in every weekend and rewrite what they have done?"
He was a odd chap by the way. He confided in me that he had no formal education after leaving school and spend the first decade of his adult life making a living by dealing dope and writing mods for the 8 bit video games. Reverse engineering and hacking the binaries! He was one mean programmer who looked at me very sourly when I first arrived on the job. "Here is another one" he must have thought. We ended up getting on very well and my contract kept getting extended so I guess I met his approval eventually.
Whilst we are on war stories:
A few years back I had a team of three bright young C++ contractors working for us on an embedded project. When the project end date arrived and they were all let go I found they had left me with a ton of memory leaks that would eventually bring the system down. Nothing could be deployed until I fixed them. Which was interesting as that was my first C++ project and I had yet to realize the full horror of how huge and tangled the C++ language is.
Thank goodness for valgrind! That and some seriously long days saved us.
Conclusion: Again, testing as you go is very important. The static, compile time, checking of C++ did not prevent that disaster.
As for the Linux thing. The magic about Linux is that there is no "pool of labour". There is just a bunch of people and groups throwing code at it for whatever reason they have. Linus Torvalds and his "lieutenants" can accept or reject that code as they please. If it bad or if it does not get written then it just does not exist. They cannot order it from a pool of labor.
From what I have read, Linus Torvalds still reads all the Linux kernal code and feels that C++ is in appropriate. I suspect the argument is 'the dependency on a flawless language" versus "the dependency on the professional skills of the programmer." Somebody actually has to be be the project manager and be able to oversee the project. Such a person exerts their leadership by the choice of tools.
Actually the conclusion is that people with no long term interest in a project won't be likely to be all that diligent.
In a sense their "pool of labor" are volunteers from the entire planet. If someone in Moldavia really needs a USB 3.0 driver for some obscure hardware, and the quality is is high enough, the Linux kernel gets support. Most projects don't have that luxury. Even if they went open source they wouldn't draw volunteers to contribute code. This means they have to pay for each line of code contributed, and since resources are finite this narrows their labor pool.
That attitude really pisses me off and it's not always the temporary contractors that have it.
For many years I worked as a freelance programmer in England and spent time in many different companies large and small. Most of the "peer contractors" I worked with were very enthusiastic and dedicated to getting projects working. Partly because that is the kind people they were and partly because having well known and successful projects on your resume is a good idea. For myself I was often thrilled at being involved projects, I could not imagine being unenthusiastic about it's success. I mean, how did I ever end up getting to play with huge 3D phased array radars or Boeing fly by wire systems or Rolls Royce jet engines and so on.
On the other hand there worst cases were often the permanent staff in big companies. They clock in, they clock out, they seem to get no joy out of what they are doing, they do enough to get by. I often wondered why they must have worked so hard to get to such positions if it bores them so much.
Edit: My most favourite project ever was a version of this:
http://www.radartutorial.eu/19.kartei/karte112.en.html
http://www.flickr.com/photos/rinkratz/8179868863
The P2 is eventually going to host its own development… when that day comes, we are going to want the P2 to direct a lot of resources through some kind of scripting interface…. and vice versa.
Isn't Javascript the only viable cross platform candidate, since it is the most widely adopted and supported?
Don't know… just asking:)
Rich
Until Node.js came along I had only seen JavaScript used in two environments. The browser where it scripted DOM manipulations, and Windows Scripting Host (WSH) as one of the supported scripting engine. I hadn't seen it used in any other environment. It's starting to spread, but it isn't nearly as ubiquitous as something like Python or Perl.
This is why I must act now to stop it!
Until recently I would have thought that anyone suggesting JS on a micro-controller was out their minds. I mean, JS engines are huge. They need loads of memory to run in, JS is interpretted and will be horrible slow.
That is until Gordon Williams turned up with his TinyJS for micro-controllers and now the Espruino project.
And then as if by magic we now have Micro Python which also runs on micro-controllers. I have never seen it in action so I don't know how well it works.
So I was reading this thread, and then looking at your avatar started hearing it in Marvin's voice...
Suddenly made this thread very depressing...
Maybe that's his problem, programmed in JS maybe?
C.W.
Too funny.
Funny indeed!
http://www.elijahmanor.com/angry-birds-of-javascript-series/
C.W.
Who will be the first to run the following under node.js or in the browser and reveal the message it outputs?
O.M.G. Look! It's the new PERL with a little Mindf*** mixed in. (Moderators, yes I know, but that is the real name of it! What's a guy to do? I thought about linking it...)
Somebody had to author that with a program. Please tell me they did.
And look! Heater got me to install the JS tool. Now I can play with things in my idle time... JS sure is easy that way. Really.
I thought I thought about thinking about it too. But perhaps I just imagined thinking that thought. Then I thought about thinking about something else instead. I thought that was too hard to think about so ended up thinking this. I think.
Oh you said "linking". I thought all that for nothing
Anyway, you are on the right track with brain****.
I have no idea what JS tool that is. I suggest installing node.js. http://nodejs.org/ You will be building web applications for controlling your Propellers via serial port in no time.
I will end up doing the installation as that is a place I want to go, just not yet.
Unfortunately, quoting the post sent my browser "toes up".
Very clever! I just ran it under nodejs - I have no idea how it is doing what it is doing or how you came up with it but very clever!
(it's kind of frightening what might be going on inside that head of yours!)