I thought some of you might like to read this

[ArnoldW2]

Which programming languages are most widely used today??
F# enters the top 20 for the first time.

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

[Peter Gibbons]

I saw it:

Finally, a new functional programming language has hit the top 20. Most people thought that hot functional languages such as Scala (#66), Clojure (#107), Haskell (#35) or Erlang (#48) would be the ones that would be the first to compete seriously with the mother of all functional languages Lisp. But it appears to be Microsoft language F#. The recent rise in popularity of F# comes as no suprise. Apart from being a nicely designed language, F# is available in the latest version of Microsoft's Visual Studio (2010).

My money is still on Scala since it's multiplatform and is much more close to OO languages that today's programmers are familiar with. Easier transition.

[Origisaurus]

Appears to be completely *ix oriented.  Which is OK, I suppose.

Back in the 1980s, we were told that Unix and C would take over the world.  That was before the tab for converting billions of lines of COBOL, FORTRAN and PL/1 came in.  And today, "legacy" systems thrive.

So, I suppose for development of new apps in a relative vacuum the listed languages rule.  And for maintenance of legacy systems, the legacy languages rule.

I don't expect to live to see the day when *ix and it's offspring actually run more business apps than the legacy ones do.  Perhaps in my grandchildren's time.

[The Gorn]

Back in the 1980s, we were told that Unix and C would take over the world. 

Even back then, and even though I was a through-and-through pointless geek at the time, I understood reasoning like this to be utterly foolish.

I had a sense that the terseness of C made it unsuitable in business application development. I made mistakes right and left in coding C and I knew that most developers were not as anal retentive as I was, hence, C adoption on a mass scale would be utter chaos. I knew that verbose languages more like BASIC (and by implication COBOL) would be more accepted by the mass of programmers. 

I also had a sense that corporate standards would dictate (well, at the time) VMS or VM over Unix, simply because the autocracy had to be fed.

Unix was too chaotic, ad hoc, and grass-roots to imagine in a serious money handling context.

[Origisaurus]

What you said about Unix and the Bell Labs gurus.

More important is the politics.  The mainframe salesmen (and in those days, they were all male, pre-womens lib) were trained to speak the bean-counting decision-makers' language.  While the Unix and C advocates were all about "cool" and "terse" and so forth - have you ever seen a bean counter who grokked any of the technical advantages of Unix or C?

[Peter Gibbons]

Appears to be completely *ix oriented.  Which is OK, I suppose.

Well, Java runs everywhere - including IBM mainframes - so by default Scala programs will run there too.
Scala just compiles to Java bytecodes.

And since Scala can create programs for the .NET CLR too - the programs will also run everywhere where there is CLR or Mono.
So surprisingly this includes even the iOS platforms (where Java is not allowed) via MonoTouch.

I don't expect to live to see the day when *ix and it's offspring actually run more business apps than the legacy ones do.

I have to be pragmatic. I couldn't care less if some insurance company runs their main COBOL (or even Java) application for the next 50 years. I am not interested in maintaining one of those. And I am certain the insurance company will not hire me to do that.

I have to try to anticipate new trends and position myself appropriately.

Some of the ideas Scala is based on were developed by John McCarthy before I was born.
So it's not that Scala is some unproven shiny toy.
It's just that the programming mainstream could take decades to accept some good ideas that actually make sense.

For example McCarthy invented the Garbage Collection around 1959.
Java made the Garbage Collection mainstream in what - 1999?

I am taking very small calculated risk - I will play with Scala for 2 or 3 months part time, create a small program and see what will happen next. It's quite possible that the current buzz about Scala will subside and maybe something new will become the current 'hot' language.

So what - big deal. I will still have learned a few new things about programming and I could always use Scala for my projects.

I am trying to find my own niche in the software contracting / consulting market.
I just don't believe in the heavy weight enterprise Java frameworks. When I see ads with 5 or 6 of those listed - I move on.

So I don't see myself ever spending some of my free time trying to become an expert in of those is an attempt to become more marketable.

When I talk about Scala is more about putting my thoughts 'on paper' for myself than trying to make other members of the forum to take a serious look.

[Walter Mitty]

For example McCarthy invented the Garbage Collection around 1959.
Java made the Garbage Collection mainstream in what - 1999?

I wrote a garbage collector for a language derived from Lisp in 1971.  It was more intricate than McCarthy's because the language supported arrays, and arrays require contiguous storage, unlike linked lists.  But the concept was the same as McCarthy's.

What surprised me is how long it took this dea to become mainstream.

[The Gorn]

It was more intricate than McCarthy's because the language supported arrays, and arrays require contiguous storage, unlike linked lists. 

A small hijack: not necessarily. In the Standard Template Library in C++, array notation can mean a value data type associated with a key data type (the index.) The data can live any place. The resultant storage location is calculated for every array position, so the array notation is not necessarily just a pointer access with a scaled value.

(I think a "vector" template type in STL implements a physical array in the sense we think of an array. IE, it's supposed to actually allocate a contiguous piece of memory.)

STL has its own garbage collection which (as you would imagine) it uses intensively to implement these programmer conveniences.

[Walter Mitty]

It was more intricate than McCarthy's because the language supported arrays, and arrays require contiguous storage, unlike linked lists. 

A small hijack: not necessarily. In the Standard Template Library in C++, array notation can mean a value data type associated with a key data type (the index.) The data can live any place. The resultant storage location is calculated for every array position, so the array notation is not necessarily just a pointer access with a scaled value.

(I think a "vector" template type in STL implements a physical array in the sense we think of an array. IE, it's supposed to actually allocate a contiguous piece of memory.)

STL has its own garbage collection which (as you would imagine) it uses intensively to implement these programmer conveniences.

Fair enough.  now that you jog my memory,  we actually called these things "vectors" not "arrays" in 1971.  They had to be contiguous.

[Origisaurus]

Appears to be completely *ix oriented.  Which is OK, I suppose.

Well, Java runs everywhere - including IBM mainframes - so by default Scala programs will run there too.
Scala just compiles to Java bytecodes.

OK, so that got me to thinking.  In the traditional mainframe environment, (simplifying) you compile or assemble code into object, which is actually what the processor executes.  So I wonder, what parallel is there with Java?  Does Java object run in the mainframe batch environment?

Am I missing something?  In my experience, Java, etc. run interactively in a *ix or Windoze environment.  What's missing here?

I have read that IBM has Unix running on the bare iron.  Does that look anything like a batch processing system?  I. e., zOS?  Or is it something like a giant timesharing system?  If so, is there any bridge to the batch operations that aren't going away anytime soon?

[TRexx]

I have read that IBM has Unix running on the bare iron.  Does that look anything like a batch processing system?  I. e., zOS?  Or is it something like a giant timesharing system?  If so, is there any bridge to the batch operations that aren't going away anytime soon?

IBM has a version of Unix called AIX. AFAIK (but I may be wrong) it does not run on the Z series (~370 mainframes).  But IBM is very bullish on Linux.  You can run it native on your Z series, or more likely under zVM where you can run literally hundreds of Linux images on one box. 

[Peter Gibbons]

In my experience, Java, etc. run interactively in a *ix or Windoze environment.  What's missing here?

http://www.ibm.com/developerworks/systems/library/es-java-batchz.html

Summary:
Java has many uses on z/OS and OS/390 outside the confines of a Web server environment. Kirk Wolf and Steve Goetze explain how you can effectively run Java programs in a z/OS or OS/390 batch environment through:
Flexible configuration of the Java Virtual Machine (JVM) and environment variables
Routing output directly to JES SYSOUT datasets
Controlling output encoding
Passing condition codes between Java and non-Java steps
Reading and writing MVS datasets from Java
Executing the JVM under the original batch address space
Communicating with the MVS system console

Here are some potential uses for Java in z/OS batch jobs:
Passing datasets created by traditional job steps to Java programs, which convert the data to XML.
Using Java programs to access APIs such as SOAP/Web services, WebSphere MQ client API, Java Database Connectivity (JDBC) databases, custom Transmission Control Protocol/Internet Protocol (TCP/IP) socket services, and so forth.
Employing long-running started tasks for Java that periodically query a database to find new work to process.
Migrating systems written in COBOL to Java in order to reuse Java programming skills and class libraries.
Whereas in the past Java might have been considered slow or too resource intensive, the modern JVMs, with their just-in-time translation (JIT) to machine code, have excellent performance characteristics for many tasks. IBM has recently provided considerable financial incentives to using Java on z/OS with the announcement of the zSeries® Application Assist Processor (zAAP).
In this article, we describe some of the challenges you might encounter when using Java in batch jobstreams and how to seamlessly integrate Java into MVS Job Control Language (JCL). We refer to the operating system as z/OS, even though most of the information applies as well to OS/390, except that SDK 1.4 and above are only supported on z/OS.

So - it looks like Java can run directly on z/OS. And they have very up to date version of Java there:
http://www-03.ibm.com/systems/z/os/zos/tools/java/products/sdk601_64.html


The other option is z/OS running many Linux VMs that in turn can run Java VMs.

[TRexx]

The other option is z/OS running many Linux VMs that in turn can run Java VMs.

IKTANB Linux runs under z/VM not z/OS.

[Walter Mitty]

Appears to be completely *ix oriented.  Which is OK, I suppose.

Well, Java runs everywhere - including IBM mainframes - so by default Scala programs will run there too.
Scala just compiles to Java bytecodes.

OK, so that got me to thinking.  In the traditional mainframe environment, (simplifying) you compile or assemble code into object, which is actually what the processor executes.  So I wonder, what parallel is there with Java?  Does Java object run in the mainframe batch environment?

Am I missing something?  In my experience, Java, etc. run interactively in a *ix or Windoze environment.  What's missing here?

I have read that IBM has Unix running on the bare iron.  Does that look anything like a batch processing system?  I. e., zOS?  Or is it something like a giant timesharing system?  If so, is there any bridge to the batch operations that aren't going away anytime soon?

I'm probably telling you something you already know.  Forgive me.

In languages like Java, there is one more level of indirection than there is in the classical "compile into object code"  pattern.  Bytecode is the machine language for a virtual machine.  The java interpreter "runs" programs written in bytecode by interpreting the virtual machine code. 

This means that, in order to port to a different machine,  all you need is a JVM interpreter on that machine.  An interpreter is lots easier to write than a compiler. 

There is plenty of prior art with regard to virtual machines, going all the way back to 1970.  The Pascal compiler originally written by Niklaus Wirth compiles to something called P-code.  A P-code interpeter on a new platform ports Pascal to that platform. 

I'm presuming that both P-code and bytecode were somewhat optimized with regard to making it possible to write an interpreter that runs pretty fast.  Still, the Turbo Pascal engineers were able to speed up Pascal by tergeting the harware machine instead of a VM. 

[benali72]

About AIX ... I've supported it at various times. It's IBM's unix for the midrange (System p, previously known as the RS/6000). AIX is competitive with Sun Solaris and HP's HP/UX. AIX is really nice with excellent doc and good supporting utilities. I like it a lot.  I could be wrong but I don't think AIX runs on the mainframe. There IBM encourages SUSE and Red Hat (and supposedly Ubuntu sometime in the future) under virtualization.