Platform Specific
Got this from a mailing list. Interesting read.
---------
Take: Platform Specific
By Alan Zeichick
A long time ago, in a galaxy far, far away, I designed and coded mainframe applications in COBOL. And FORTRAN. And PL/1. Sometimes there was a little RPG thrown in for good measure.
As a developer and systems analyst, I had a worldview that was rather narrow, focused mainly on the problem domain, but also with a heavy dose of the fundamentals of software development and of the programming languages that I used. What I rarely thought about was the runtime platform, beyond the peculiarities of the FORTRAN G and FORTRAN H compilers. Even when I wrote software for 3270-series terminal users, the amount of knowledge required was easily acquired. I could port my code to other systems, and indeed occasionally I built software for VAX, Data General and other minicomputers, in addition to my comfortable System/370.
As a programmer, my tool was the programming language, and maybe some common libraries. It was all very portable, and had little to do with specific companies or products. Even in the mainframe world, IBM was little more than a nameplate on the box.
Twenty-five years ago, I considered myself a crackerjack FORTRAN, COBOL or PL/1 programmer, as well as a systems analyst experienced with IBM's big iron. Programming languages defined me as a developer, because in that era, the runtime environment was largely abstracted away.
Times have changed: At conferences like Microsoft Tech-Ed, JavaOne or LinuxWorld, it's all about platform internals. That's particularly true at the Microsoft and Linux events, but holds true in the Java universe as well. Dive deep into the Microsoft Foundation Classes, or the Java EE 5 packages or the .NET Framework. Master the art of ASP.NET coding, or become an expert on Red Hat packages. It's not about the language; it's about the runtime. And the runtime's
manufacturer.
Even when languages are mentioned, they're in a vendor context. When someone refers to herself as a Visual Basic or C# programmer, she's telling the world, "I'm a Windows developer." If she calls herself a Java developer, she's probably not promoting her language skills, but rather her mastery of the specific Java Standard Edition or Enterprise Edition specifications, like JDO, JAX-RPC, JSP 1.2 or JDBC 3.0. If someone programs in ABAP or PL/SQL or T-SQL, you know which brand of software their employer uses.
Those ABAP and JDBC and .NET skills are necessary, of course. But they aren't very portable. A C++ developer for Linux would have trouble getting up to speed on Visual C++ for .NET, and vice versa. A Java SE expert would have to work hard in order to become a native .NET expert—and vice versa. Even moving skills between different runtimes of the same platform, WebSphere and WebLogic, or SQL Server to Oracle to DB2, is nontrivial.
We've gone from a world of portable programmers, whose tools were languages defined by researchers and standards bodies, to a world of platform programmers, whose tools are vendor-specific APIs. I can't help but feel that something's been lost during this transition.
---------
Take: Platform Specific
By Alan Zeichick
A long time ago, in a galaxy far, far away, I designed and coded mainframe applications in COBOL. And FORTRAN. And PL/1. Sometimes there was a little RPG thrown in for good measure.
As a developer and systems analyst, I had a worldview that was rather narrow, focused mainly on the problem domain, but also with a heavy dose of the fundamentals of software development and of the programming languages that I used. What I rarely thought about was the runtime platform, beyond the peculiarities of the FORTRAN G and FORTRAN H compilers. Even when I wrote software for 3270-series terminal users, the amount of knowledge required was easily acquired. I could port my code to other systems, and indeed occasionally I built software for VAX, Data General and other minicomputers, in addition to my comfortable System/370.
As a programmer, my tool was the programming language, and maybe some common libraries. It was all very portable, and had little to do with specific companies or products. Even in the mainframe world, IBM was little more than a nameplate on the box.
Twenty-five years ago, I considered myself a crackerjack FORTRAN, COBOL or PL/1 programmer, as well as a systems analyst experienced with IBM's big iron. Programming languages defined me as a developer, because in that era, the runtime environment was largely abstracted away.
Times have changed: At conferences like Microsoft Tech-Ed, JavaOne or LinuxWorld, it's all about platform internals. That's particularly true at the Microsoft and Linux events, but holds true in the Java universe as well. Dive deep into the Microsoft Foundation Classes, or the Java EE 5 packages or the .NET Framework. Master the art of ASP.NET coding, or become an expert on Red Hat packages. It's not about the language; it's about the runtime. And the runtime's
manufacturer.
Even when languages are mentioned, they're in a vendor context. When someone refers to herself as a Visual Basic or C# programmer, she's telling the world, "I'm a Windows developer." If she calls herself a Java developer, she's probably not promoting her language skills, but rather her mastery of the specific Java Standard Edition or Enterprise Edition specifications, like JDO, JAX-RPC, JSP 1.2 or JDBC 3.0. If someone programs in ABAP or PL/SQL or T-SQL, you know which brand of software their employer uses.
Those ABAP and JDBC and .NET skills are necessary, of course. But they aren't very portable. A C++ developer for Linux would have trouble getting up to speed on Visual C++ for .NET, and vice versa. A Java SE expert would have to work hard in order to become a native .NET expert—and vice versa. Even moving skills between different runtimes of the same platform, WebSphere and WebLogic, or SQL Server to Oracle to DB2, is nontrivial.
We've gone from a world of portable programmers, whose tools were languages defined by researchers and standards bodies, to a world of platform programmers, whose tools are vendor-specific APIs. I can't help but feel that something's been lost during this transition.
posted by JPG at
12:04
|
0 comments
