I have spent my life hopping from one rental car to another. The doors all work the same, the steering wheel works the same but other controls might take a few minutes to figure out. I hop from LHD to RHD, from 55mph to the Autobahn...I always get to where I need to be.
What's the big deal?
People tend to get attached to the details of the language they're most familiar with and think of even a minor deviation as being intolerable. "I can't possibly get anything done with this language because I have to type a semi-colon at the end of each statement!". In fact, if you know one procedural language you can probably learn another very quickly if you don't allow yourself to get stuck on minor details. I can write code in C, Spin, JavaScript, Python, BASIC, and probably a lot of other languages and I'm not a rocket scientist. It just takes a bit of willingness to try something new. I still fault myself in not taking the time to learn Forth. I find it an intriguing language and Tachyon certainly makes the effort to learn it worthwhile. I just need to allocate a chunk of time to get my mind wrapped around it on something other than just a superficial level. The fact that I don't know it is my problem not a problem with the language itself.
There is no problem Mikster. Many of us use a few different languages. Many of us have used more languages than we care to remember. Coral 66, Lucol, Ada, Algol, PL/M 86, BASIC, Pascal anyone?
Problem comes when one has ten man years worth of effort in some code base that is now useless and or un-maintainable because because the language or compiler is obsolete and unavailable. Or the architecture in ran on has disappeared.
Then you start to think using a language with multiple vendor support, a large developer community and proper standards, preferably open source everything, is a good idea...
That pretty much just leaves C/C++ and Javascript now a days.
@vangbe if you're still monitoring this thread, I encourage you to check out Spin.
Spin is by far my favorite language.
I've posted links to some Spin and PASM tutorials in this post. I learned Spin from the old (v1.0) Propeller Manual (there's a link to this book included in the list of links).
I made a "Fun with Spin" playlist on my YouTube channel. You can see some of the things one can do using Spin on the Propeller.
The Propeller's multiple cogs are a great match for a lot of robotic projects. You can simultaneously control multiple motors/servos and monitor sensors. You don't have to do these things one after the other as you do with other microcontrollers.
The Propeller can control up to 32 servos.
Pretty cool IMO.
The Propeller Project Board is a good price for what you get. It's a relatively inexpensive way to trying out the Propeller.
@vangbe if you're still monitoring this thread, I encourage you to check out Spin.
Spin is by far my favorite language.
I've posted links to some Spin and PASM tutorials in this post. I learned Spin from the old (v1.0) Propeller Manual (there's a link to this book included in the list of links).
I made a "Fun with Spin" playlist on my YouTube channel. You can see some of the things one can do using Spin on the Propeller.
The Propeller's multiple cogs are a great match for a lot of robotic projects. You can simultaneously control multiple motors/servos and monitor sensors. You don't have to do these things one after the other as you do with other microcontrollers.
The Propeller can control up to 32 servos.
Pretty cool IMO.
The Propeller Project Board is a good price for what you get. It's a relatively inexpensive way to trying out the Propeller.
That's pretty cool! How do you have the work distributed? Are you using all 8 COGs to control the servos, 4 each?
That's pretty cool! How do you have the work distributed? Are you using all 8 COGs to control the servos, 4 each?
I think there are just two active cogs. One cog is running Beau's servo driver and the other is running the position algorithms. Here's a link to the project. I've sure I'd do things differently today (I think I'd have better algorithms).
I had to use switches on pins 28 - 31 so the Propeller would boot properly. Once the program was up and running, I'd switch this I/O pins over to the servos.
18 servos for the legs and 4 more for the eyes. (I know you've seen this but this thread seemed like a good excuse to post it again.)
Both these servo control videos used a QuickStart board as the controller but the Propeller Project Board would have worked just as well.
BTW, love the 16 servos on a BS2. I wouldn't have thought it possible.
There is no problem Mikster. Many of us use a few different languages. Many of us have used more languages than we care to remember. Coral 66, Lucol, Ada, Algol, PL/M 86, BASIC, Pascal anyone?
Problem comes when one has ten man years worth of effort in some code base that is now useless and or un-maintainable because because the language or compiler is obsolete and unavailable. Or the architecture in ran on has disappeared.
Then you start to think using a language with multiple vendor support, a large developer community and proper standards, preferably open source everything, is a good idea...
That pretty much just leaves C/C++ and Javascript now a days.
wrong.
As always I have to throw in COBOL again.
From the start it was made to be machine and vendor independent and still is.
COBOL programs tend to be very long and verbose, mostly because the 'basic' idea was that non programmers could follow the source code to inspect/check/verify the implemented business logic.
And for a non programmer 'add 1 to customer-count giving total-customers' might be easier to understand then 'total_customer = customer_count + 1'. That was actually one of the design decisions made for COBOL at that time.
Writing COBOL programs is a typing exercise, but you need barely any comments, the source is readable like a subset of the English language.
Normal COBOL setups in the wild consist of 500+ sub programs with tons of lines of code written by programmers mostly retired or dead now and still running on big iron. But porting to another Compiler/Architecture? Usually easy done.
Sure - it is usually a TUI not a GUI but platform independent.
Ah yes COBOL. Let's see how it stands up to my language selection criteria:
Proper standards - Check. CODASYL, ANSI, ISO. But note that the last revision of the standard that any one uses and is widely implemented is from 1985. COBOL does not get much love.
Multiple vendor support - Check. IBM, Micro Focus, Microsoft Visual, GNU
open source - Check. GnuCOBOL
large developer community - FAIL. COBOL Does not show up on Github or Bitbucket. I have only ever met one COBOL programmer in decades of being surrounded by programmers. She wasn't much into thinking about it outside work. The only person I have actually discussed details of COBOL with is msrobots!
Well, COBOL meets all my criteria except one. Perhaps one should not judge how good or bad a thing is by it's popularity. But the availability of a large language user community certainly makes it easier to get into the language, get answers to problems and find ready made solutions.
If COBOL had any strikingly desirable features that might cause one to ignore it's unpopularity. So far I have not found any such features.
I never understood the reasoning behind using "add" instead of "+", "giving" instead of "=" and so on. Is it so that COBOL programmers have never been to school and learned elementary arithmetic so they don't know what the symbols mean?
No, not the programmers.. but maybe the managers. Those who were supposed to be able to understand what the programmers wrote. Well, msrobots said 'non-programmers', but even most of those would have learned elementary arithmetic. Which leaves the managers..
sadly most COBOL code is not open sourced, not even buyable, but closed as closed can be. Neither the US Post office nor major banks want their sources freely available.
COBOL jobs are usually plastered with NDA's and big iron usually has no access to bitbucket or github. This might change now with z/os Linux and companies moving off big iron because of the financial strain to run 440V at huge amperes 24/7 and pay huuuuuge amounts monthly/yearly to even have a running Operating System.
On the other hand I/O processors used on big iron have a throughput not matched by any PC based solution. That is the major hurdle in moving off the big ones, most often.
COBOL85 is a very old standard, there is some COBOL 9X out for a while and the latest published standard is now COBOL2012(14?) or so.
But it is all backward compatible. Just run your old source thru the new compiler. Rarely you need to change/adapt it.
As of language features COBOL has a lot of stuff missing in other languages. Just think about the data definitions able to contain output formatting or declarative actions (something like exceptions but way better to use and manage).
My current beloved COBOL compiler is indeed GnuCobol, actually a transpiler(?) creating c/c++ out of COBOL source and then running it with gcc/clang/msc or any other c compiler. Sadly except PropGCC. By now it needs dynamic linking. Version 2.x is supposed to support static linking also. That may open a way to run COBOL via PropGcc on a P2.
The first computer I was allowed to program was a Wang Model 2000. Naturally it supported BASIC. Then a TRS80, and how? BASIC and some assembler. Both computers did cost more then my yearly income at that time. So I never owned one. Then came the big iron time with COBOL for me, now we are talking about a livelong income to buy one of those.
My first own one? A Atari 130XE. And mostly programmed in BASIC and Assembler.
Most BASIC dialects are so alike, I never had problems to switch from one to the other. It's like riding a bicycle. Once you got it, you got it.
I can well imagine that banks and the like don't want to share their crown jewels. Given that they are the only people using COBOL there is no user community out in the wild.
It's a bit old fashioned though. Imagine if they all open sourced their banking systems and put them up on github. Then they could all use each others code. Fix the bugs and add features communally. Their software development would be pooled. They could fire 90% of the COBOL developers they have because they are not all endlessly reinventing wheels for themselves. They could increase their profits or, God forbid, give us cheaper banking services.
I know, I'm dreaming...
I wonder about the oft' mentioned throughput of the I/O processors used on big iron. Seems to me that if it was so good people like Google, Facebook, etc would be using big iron. They have the money to do so. Perhaps it's not such a good solution to the through put problem after all.
My understanding is that nobody uses COBOL features that came with recent standards. But what do I know.
I'm curious. Could you give us simple and short examples of those output formatting and declarative actions of COBOL? Other languages may not have those baked into the language syntax but I wonder if there aren't ways to do it anyway.
Yes, switching from language to language may be easy for the individual. It's switching huge code bases between systems that is the problem.
I'm surprised to read this far without seeing anyone mention Lua. I've got two different platforms suddenly that both use Lua, one in particular because the developers noticed that it's the World of Warcraft scripting language and that kind of makes it today's BASIC for finding self-taught script kiddies. And while Lua is a weird, weird platform with the way it uses lists instead of arrays or structures, it is a lot more like BASIC than C or Javascript in its syntax. I've adapted to it easily, despite the fact that the two platforms have very fundamentally different capabilities and hardware libraries.
I'm wondering why you say Lua is more like BASIC than Javascript. I always thought Lua and JS were amazingly similar. Neither of them work like any BASIC I have ever used.
The use of lists only seems weird because the world forgot about languages like Lisp and Scheme that are list based. Javascript is list based as well. Whilst it has a syntax for arrays everything is objects (lists) under the hood.
Consider:
let a = [42, 77] // A JS array
console.log(a[1]); // => 77
console.log(a['1']) // => 77
let b = {'0': 32, '1': 95} // A JS object (list)
console.log(b[1]) // => 95, accessed as an array!
console.log(b['1'])
// Or lets get weird:
let c = [43, 27] // A JS array
c.x = 9 // With an object property set on it !
console.log(c[1]) // => 27, Array access
console.log(c.x) // => 9, Object access
console.log(c) // => [ 43, 27, x: 9 ]
Lua got sidelined for me since JS and node.js does everything and has a huge support community.
That might change if I get into messing with those ESP WIFI gizmos that run Lua.
Comments
-Phil
Problem comes when one has ten man years worth of effort in some code base that is now useless and or un-maintainable because because the language or compiler is obsolete and unavailable. Or the architecture in ran on has disappeared.
Then you start to think using a language with multiple vendor support, a large developer community and proper standards, preferably open source everything, is a good idea...
That pretty much just leaves C/C++ and Javascript now a days.
Spin is by far my favorite language.
I've posted links to some Spin and PASM tutorials in this post. I learned Spin from the old (v1.0) Propeller Manual (there's a link to this book included in the list of links).
I made a "Fun with Spin" playlist on my YouTube channel. You can see some of the things one can do using Spin on the Propeller.
The Propeller's multiple cogs are a great match for a lot of robotic projects. You can simultaneously control multiple motors/servos and monitor sensors. You don't have to do these things one after the other as you do with other microcontrollers.
The Propeller can control up to 32 servos.
Pretty cool IMO.
The Propeller Project Board is a good price for what you get. It's a relatively inexpensive way to trying out the Propeller.
I think there are just two active cogs. One cog is running Beau's servo driver and the other is running the position algorithms. Here's a link to the project. I've sure I'd do things differently today (I think I'd have better algorithms).
I had to use switches on pins 28 - 31 so the Propeller would boot properly. Once the program was up and running, I'd switch this I/O pins over to the servos.
Still only 32? I mean, a vanilla BS2 can run 16 servos using BASIC!
Agreed. It started with "Languages" being misspelled and went downhill from there.
That's it without external hardware. Beau posted code and schematics showing how to control up to 144 servos but I have yet to need more than 22 for my projects.
18 servos for the legs and 4 more for the eyes. (I know you've seen this but this thread seemed like a good excuse to post it again.)
Both these servo control videos used a QuickStart board as the controller but the Propeller Project Board would have worked just as well.
BTW, love the 16 servos on a BS2. I wouldn't have thought it possible.
wrong.
As always I have to throw in COBOL again.
From the start it was made to be machine and vendor independent and still is.
COBOL programs tend to be very long and verbose, mostly because the 'basic' idea was that non programmers could follow the source code to inspect/check/verify the implemented business logic.
And for a non programmer 'add 1 to customer-count giving total-customers' might be easier to understand then 'total_customer = customer_count + 1'. That was actually one of the design decisions made for COBOL at that time.
Writing COBOL programs is a typing exercise, but you need barely any comments, the source is readable like a subset of the English language.
Normal COBOL setups in the wild consist of 500+ sub programs with tons of lines of code written by programmers mostly retired or dead now and still running on big iron. But porting to another Compiler/Architecture? Usually easy done.
Sure - it is usually a TUI not a GUI but platform independent.
my 2 cents.
Mike
Proper standards - Check. CODASYL, ANSI, ISO. But note that the last revision of the standard that any one uses and is widely implemented is from 1985. COBOL does not get much love.
Multiple vendor support - Check. IBM, Micro Focus, Microsoft Visual, GNU
open source - Check. GnuCOBOL
large developer community - FAIL. COBOL Does not show up on Github or Bitbucket. I have only ever met one COBOL programmer in decades of being surrounded by programmers. She wasn't much into thinking about it outside work. The only person I have actually discussed details of COBOL with is msrobots!
Well, COBOL meets all my criteria except one. Perhaps one should not judge how good or bad a thing is by it's popularity. But the availability of a large language user community certainly makes it easier to get into the language, get answers to problems and find ready made solutions.
If COBOL had any strikingly desirable features that might cause one to ignore it's unpopularity. So far I have not found any such features.
I never understood the reasoning behind using "add" instead of "+", "giving" instead of "=" and so on. Is it so that COBOL programmers have never been to school and learned elementary arithmetic so they don't know what the symbols mean?
@Heater,
sadly most COBOL code is not open sourced, not even buyable, but closed as closed can be. Neither the US Post office nor major banks want their sources freely available.
COBOL jobs are usually plastered with NDA's and big iron usually has no access to bitbucket or github. This might change now with z/os Linux and companies moving off big iron because of the financial strain to run 440V at huge amperes 24/7 and pay huuuuuge amounts monthly/yearly to even have a running Operating System.
On the other hand I/O processors used on big iron have a throughput not matched by any PC based solution. That is the major hurdle in moving off the big ones, most often.
COBOL85 is a very old standard, there is some COBOL 9X out for a while and the latest published standard is now COBOL2012(14?) or so.
But it is all backward compatible. Just run your old source thru the new compiler. Rarely you need to change/adapt it.
As of language features COBOL has a lot of stuff missing in other languages. Just think about the data definitions able to contain output formatting or declarative actions (something like exceptions but way better to use and manage).
My current beloved COBOL compiler is indeed GnuCobol, actually a transpiler(?) creating c/c++ out of COBOL source and then running it with gcc/clang/msc or any other c compiler. Sadly except PropGCC. By now it needs dynamic linking. Version 2.x is supposed to support static linking also. That may open a way to run COBOL via PropGcc on a P2.
The first computer I was allowed to program was a Wang Model 2000. Naturally it supported BASIC. Then a TRS80, and how? BASIC and some assembler. Both computers did cost more then my yearly income at that time. So I never owned one. Then came the big iron time with COBOL for me, now we are talking about a livelong income to buy one of those.
My first own one? A Atari 130XE. And mostly programmed in BASIC and Assembler.
Most BASIC dialects are so alike, I never had problems to switch from one to the other. It's like riding a bicycle. Once you got it, you got it.
Enjoy!
Mike
I can well imagine that banks and the like don't want to share their crown jewels. Given that they are the only people using COBOL there is no user community out in the wild.
It's a bit old fashioned though. Imagine if they all open sourced their banking systems and put them up on github. Then they could all use each others code. Fix the bugs and add features communally. Their software development would be pooled. They could fire 90% of the COBOL developers they have because they are not all endlessly reinventing wheels for themselves. They could increase their profits or, God forbid, give us cheaper banking services.
I know, I'm dreaming...
I wonder about the oft' mentioned throughput of the I/O processors used on big iron. Seems to me that if it was so good people like Google, Facebook, etc would be using big iron. They have the money to do so. Perhaps it's not such a good solution to the through put problem after all.
My understanding is that nobody uses COBOL features that came with recent standards. But what do I know.
I'm curious. Could you give us simple and short examples of those output formatting and declarative actions of COBOL? Other languages may not have those baked into the language syntax but I wonder if there aren't ways to do it anyway.
Yes, switching from language to language may be easy for the individual. It's switching huge code bases between systems that is the problem.
I'm wondering why you say Lua is more like BASIC than Javascript. I always thought Lua and JS were amazingly similar. Neither of them work like any BASIC I have ever used.
The use of lists only seems weird because the world forgot about languages like Lisp and Scheme that are list based. Javascript is list based as well. Whilst it has a syntax for arrays everything is objects (lists) under the hood.
Consider:
let a = [42, 77] // A JS array console.log(a[1]); // => 77 console.log(a['1']) // => 77 let b = {'0': 32, '1': 95} // A JS object (list) console.log(b[1]) // => 95, accessed as an array! console.log(b['1']) // Or lets get weird: let c = [43, 27] // A JS array c.x = 9 // With an object property set on it ! console.log(c[1]) // => 27, Array access console.log(c.x) // => 9, Object access console.log(c) // => [ 43, 27, x: 9 ]Lua got sidelined for me since JS and node.js does everything and has a huge support community.
That might change if I get into messing with those ESP WIFI gizmos that run Lua.