Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Selecting a Programming Language for Your Next Application

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Selecting a Programming Language for Your Next Application

    The danger in an article like this is that when an IBM employee fails to mention RPG someone will read that as a signal that IBM intend to let RPG fall by the wayside. An additional bit of insight might be had with a discussion of compiled vs interpreted languanges; especially the flexibiity of interpreted languages. One final note: there isn't a mention of a multiple-language environment. It's quite viable to do the reports and back-end in RPG, the web stuff in Java, each calling APIs written in C (for performance). Perl and ReXX for the odd utility isn't a bad idea either. --buck

  • #2
    Selecting a Programming Language for Your Next Application

    RPG most certainly is alive and kicking. The article is geared towards providing methodologies and things to consider when building your next application, not necessarily explicitly stating "Use LanguageX for ProjectY." In response to your comment on the multi-language environment, you're certainly correct there. The thought is that these applications can be logically broken into various pieces (e.g., back-end, web-based, etc.) and the same set of rules should be applied to each logical application within the "larger" application. Thanks for the feedback! Regards, Joe

    Comment


    • #3
      Selecting a Programming Language for Your Next Application

      Buck wrote: "An additional bit of insight might be had with a discussion of compiled vs interpreted languanges; especially the flexibiity of interpreted languages." I'll bite! Compiled languages have the advantage of providing the best run-time performance, and so are ideal for compute-bound applications. Optimizing back-ends are darn good these days, and can easily produce better machine code than the best assembler coders. However, what you gain in performance, you lose in flexibility. In order to produce good code, compilers like to know as much about the data types in the program as possible, and restrict operations that may be troublesome at codegen time. Why choose a compiled language? Compiled languages provide the best performance. This is important for compute-bound apps, or for mission critical apps on heavily loaded systems. (If you're spending 7 figure dollar amounts on computing hardware, you want to make sure it's running at 95% or capacity or better.) Interpreted languages, on the other hand, can be amazingly functional and powerful, and yet easy to program. Some Python fans argue that they are 10 times as productive using Python than any other language. Compare Python's object model with that of C++ or Java. OO programming is very easy in Python compared to OO programming in compiled languages. Again, the difference is that compilers need to know types at compile time. But in an interpreted system, type checking can be delayed until run-time. Thus, in an iterpreted language, you don't need to define variables as being of specific types. (Here is an interesting page comparing Java and Python.) Performance is an interesting issue. Some Perl afficionados would argue that a well written Perl program can run almost as well as an equivalent C++ program. Why? Written properly, a Perl program will spend most of its run-time within the built-in routines (and not the Perl interpreter), which are written in C compiled using the highest optimization levels possible. In general, here are some reasons to use an interpreted language: 1) Rapid prototyping. Write the code quickly to establish a proof of concept, then rewrite into a compiled language (if performance is needed). 2) Ease of maintenance. Compiled languages are generally easier to work with. 3) Performance is not a major issue. This may be true for tools that are run occasionally. Or when I/O or network latencies overwhelm the performance of the program anyways. Java is a funny case. Java bytecode is interpreted at run-time, but the language has all the baggage of compiled OO languages. Cheers! Hans

      Comment


      • #4
        Selecting a Programming Language for Your Next Application

        Just some quibbles over some of Joe's points: 1) Java may be a "compiled" language, however, the Java compiler produces a bytecode that is interpreted. Actually, this is the way that other interpreted languages like Perl and Python work too. So, Java should be more appropriately called an interpreted language (but with all the excess baggage needed for a compiled language). On the other hand, You could argue that Java has things like JIT compilers, which convert bytecode to machine code. Then again, you can also compile Perl into executable binaries as well if you really wanted to. Would that help Perl programs? Some would argue that a well-written Perl program can run almost as fast interpreted as a C++ program. 2) C and C++ are not platform independent?!? These languages are pretty much ubiquitous in the computing world. If you know how to write C/C++ for one system, you can write C/C++ for any other system. True, you can write system specific code in C/C++ if you try hard enough, but that's also true of most other programming languages. For example, check out Chapters 20, 21, and 22 of the Python Library Reference, and you'll see a few system specific class libraries. But in general, it's not all that difficult to write system independent code in C or C++. 3) "Ruby on Rails" is not a language, it's an application framework implemented in the language Ruby. It's like Python and TurboGears, which has been described as a sort of "Python on Rails". Yeah, I know, your table is entitled "Some of Today's Hottest Languages and Frameworks". But it would be better to compare language against language and framework against framework in two separate tables. Or better yet, in two separate articles. (BTW, I've always felt I should learn Ruby. However, the language looks too much like a pointless cross between Perl and Python. I just can't seem to find the motivation to learn it.) 4) No comparison of programming languages can be complete without a discussion of a few other dimensions, such as readability of programs, development tools, on-line discussion groups, availability of 3rd party class libraries, and speed of development. Cheers! Hans

        Comment


        • #5
          Selecting a Programming Language for Your Next Application

          Hans, Thanks for the feedback. I've commented on your feedback by number, respectively. 1) You could potentially go either way on this. Technically-speaking, Java *is* a compiled language. Though its compiled form is certainly not machine instructions, it's still compiled. And like you said, some of the available Just In Time (JIT) compilers can do a pretty good job of further converting/optimizing the Java bytecode. 2) C and C++ are most certainly not platform-independent. While it's true that if you can read C++ on Windows, you can probably read C++ on Linux (or any other platform), (in most cases) you most certainly can't take C++ code and move it from one platform to another and expect it to compile (unless it's full of environmental #ifdef/#endif preprocessor directives). This is of course due to the large differences in system calls and available static/shared libraries. 3) Right on, it's not a language (hence the title of the table, as you even noted)! It's there as more of an attempt to include the technology as it's definitely a common present-day IT buzzword these days when discussing programming languages. 4) Readability is definitely an important factor, but I don't personally feel that's a dimension per-se. A good programmer will write readable code, regardless of the language. For instance, some people argue that Perl promotes "messy" code, but the truth is, you can write "messy" code in any language. The readability factor is usually independent of the language and is more a factor of the programmer. Though, I will give you that languages like PROLOG and LISP, regardless of the programmer, are difficult to read. :-) Online discussion groups...excellent point! Regards, Joe

          Comment


          • #6
            Selecting a Programming Language for Your Next Application

            A programming language choice is often a matter of deployment and runtime contexts, which I suspect takes precedence in most cases, where the runtime context is more than just a particular virtual machine or platform. Say you have a runtime context supporting development, test, evaluation, and production environments, a context supporting multiple clients - where commingling of client data is not allowed - where access to data is controlled, a context where fiscal year snapshots of tables are made available, a systems operations context, a management context, an authentication and authorization context, a portal context, a context with an established code base - perhaps implementing established business rules, an object security context, and the list could go on. A programmer may prefer a PC runtime context, but in doing so may elect himself to become a system operator, a DP manager, and elect his laptop to host the application. If he gets a job in another department, the department head may ask him to leave his laptop so his replacement can take over the administration of the application. The point is, that language choice is often a matter of whether the application will integrate with established contexts, and whether support for the language exists within those contexts, and norms. The type of application and the strengths of a programming language are a consideration, but it seems that supported runtime contexts trump them in most business and organizational settings. It seems that programmers and language experts may take the myopic view of considering the attributes of a virtual machine and individual language elements, while IT managers see things from a higher-level business and operational perspective. Is that the reason that Joe left RPG out of the list? Is platform independence an attribute of a language, as suggested? Or is platform independence an attribute of a virtual machine? Someone said, Java is not platform independent - it's a platform! Even under I5/OS an instance of the Java Virtual Machine runs within a job running in the native virtual machine. Regarding performance, does execution speed trump scalability? If the application is accessed by multiple concurrent users, does each user experience similar performance characteristics, or do some transactions wait while others fly - unimpeded by bottlenecks. To support scalability, is there a requirement to deploy and manage applications across server farms? A context may be a virtual machine, and runtime libraries, and development tools. But it may be much broader, too. Nathan Andelin

            Comment


            • #7
              Selecting a Programming Language for Your Next Application

              "A good programmer will write readable code, regardless of the language". Nobody argues that a bad programmer can write bad code in any lanugage. However some languages limit how bad a programmer can code. A language not allowing GOTO and other forms of "Glorified GOTOs" avoids "sphaghetting" of the code. The question is, how readable can a programmer code in an inflexible language. RPG and RPGII were gawd damned languages that were reading nightmares. One had to put a template on the listing to see if a character appeared in column 35 or 34, unless you had the luxury of your own terminal which was rare those days and you had to depend on printouts. For this reason I and many refused to switch from Cobol to RPG/RPGII when System 34 arrived to replace timesharing of 360 and 370. This was despite heavy pressure from IBM that programming in Cobol was very inefficient. Luckily, my management did not see me as an old dog refusing to learn new tricks. I was only 22-23 years old, knew four languages (Cobol, Assembler, Plan, Fortran), and was learning new languages all the time.

              Comment


              • #8
                Selecting a Programming Language for Your Next Application

                1) By your definition, Perl and Python also count as compiled languages. Perl and Python first compile the program to an intermediate form which is then interpreted. By default, Python converts modules into .pyc files, and so these don't have to be compiled again. One difference is that the other languages don't require a separate compilation step. Another is that the other languages don't come with the baggage usually associated with compiled OO languages. 2) I know from personal experience that C is (or can be) platform independent. My last project was the RPG IV compiler. It began as the SAA RPG 370 compiler. It was then ported to OS/2 and Windows as the RPG program verifier, and again as VisualAge RPG. Later, it was ported to the AS/400. In all cases, changes had to be made, but very few of these changes had anything to with system differences. My other point is that system specific code can be written in any language if you try hard enough. 3) Buzzwords - Yucchhh! And as someone else already pointed out, you neglected to include RPG as one of the language possibilities that most readers of this web site are interested in. 4) Again, I can say from my own experience that some languages do promote readability and maintainability better than others, and some are worse. For example, even though I worked with RPG for decades, I never really could get the hang of "straight-line" code. On the other hand, considering the syntactical rules of Python, it's hard to write unreadable code in that language. (Or at least, easier to write readable code.) Cheers! Hans

                Comment


                • #9
                  Selecting a Programming Language for Your Next Application

                  Hans, thanks for pointing out the java comparison page. It bolsters my opinion that Java is next to useless. Python looks interesting. Most, not all, but most of us on the 400 build business applications. RPG and Cobol are business application langauges. That is, they have facilities built into them to easily aquire validated business data (such as codes, quantities, dollar amounts, and descriptions)from a user, store them in a data base, then fetch and present the information in both printed and display forms. That very consisely sums up what we do repeatedly in varying levels of complexity on daily basis. When I code in RPG, I don't have to code a call to QDBPUT with a large quantity of parameters which is the way most of the other languages get things done. I simply code WRITE RECORD. COBOL operates similarly. I have always said C is a syntax not a language. This opinion ticks some people off and makes others laugh. I have spent years with C. Think about it, you can't do anything with C unless you have an enormous amount of function libraries. It can't do any I/O, just logic. And then the function libraries (many purchased separately) of course most of those weren't written by the same person so they each have differing methodologies that don't necessarily work well together. C is a good systems language but nobody would build large business applications in it unless they first built a framework of functions to make it easier. Essentially to make it more like RPG and COBOL. Why do I keep yaking about C, well because nearly everything in every OS, compiler, and tool we use is built with C. Wasn't always that way (thank god because RPG and COBOL would have never been born) but it is now. As Hans pointed out the RPG compiler is built in C. RPG is a HIGHER level business specific language. The way C handles character fields (called strings and buffers) is why Windows is so prone to crashes and viruses. What RPG and COBOL programmers take for granted are fixed length character fields. When RPG moves something into a character field the programmer would never expect that to affect any other part of memory. Not so in C, where you can move a large string into a variable not large enough to contain it and nothing stops it from just moving it right over the top of what ever was next to the target field. C programmers will be quick to point out that is just bad programming and that you should surround your "MOVE" with several other functions to limit its scope to the target field. Sure. Or you could write a C "move" routine (function) that works like RPG, which is what I did. My first language was RPG, C came later. So where does that leave Java since it borrows its syntax from C. Java is finger numbingly verbose to code in (see Hans' reference to Joe's page). Where RPG would READ FILE, Java requires a procedure to be built for each field in the file being read. Java is interpreted so it is slower than C. It has no built in way of performing the afore mentioned daily business functions of aquire, store, and output. Not that people haven't attempted to use it despite these and other problems. But it takes thousands upon thousands of lines of code to do it. And don't forget the accepted output is a web page not written in Java, but rather HTML and Java script. Just another example of something not designed for business. HTML can only input and output a text string, leaving you to pick up the slack. I am not the first one to point these things out. Hopefully, someday soon IBM will put the B for business back in their name. If I have to buy a third party tool to make the 400 work for business basics.....why bother. Long live RPG.

                  Comment


                  • #10
                    Selecting a Programming Language for Your Next Application

                    I don't see any appreciable difference between Java, C++, and PHP5 and the other OO scripting languages. And is Java with a packed decimal class and AS/400 Toolbox for Java really that much different from /free? As far as I'm concerned, that should be the /free syntax (minus the new keyword). I've been thinking on whether a language with the volume of libraries that Java and PHP have is something that RPG lacks, and for the life of me, I've never ever in all the RPG systems I've written said, gee, I wish I had an API or access to a Java or PHP or C library function (or XTools for that matter). And that includes writing an entire full featured jobs web site in RPG in three months with every jobs site feature you can think of. Just didn't come close to needing anything else, ever. So on the one hand I'm wondering about the value of accessing those Java and PHP environments on the 400 for their function libraries, and on the other if it's useful, it's probably already covered in Cozzi's and other's third party libraries. Plus I saw a reference here the other day to accessing the C function library with ILE binding if an AS/400 shop did want to pursue supplementing development with that. By the way, the many security exploits are primarily based on programmers using those C library functions, the basis for it being that the functions copy data from source to destination until a null byte is found. Being horizontal code with nested function calls (like /free), they can't be bothered to do the necessary error checking because it messes up their neat terse set of calls all feeding into the next, and voila, they have no clue they just copied an exploit from a web page far beyond the destination into the stack. I can see the i5 Java or PHP environments being I/O handlers for RPG programs, Java for Swing or HTML or PHP for HTML, but the RPG server session has to have complete control as we do now, not be a replacement for Visual Basic for event driven code when some random crap arrives from the cloud. rd

                    Comment


                    • #11
                      Selecting a Programming Language for Your Next Application

                      And another environment that would be very useful for I/O handling from our RPG programs is Mono. Does it run under PASE yet? rd

                      Comment


                      • #12
                        Selecting a Programming Language for Your Next Application

                        Also, more integration IBM needs to do with the i5: - All OS partitions see each other's directories (with permissions on a per user basis). Linux, AIX, and Windows file directories show up in IFS, i5/OS mounts in Linux, all partitions show up in Windows explorer, etc. All it takes is remote file system drivers and sockets. You already have virtual memory, use it. - DDM works against at least DB2 in other partitions, and with drivers other databases as well, especially the open source ones. Again, the sockets or equivalent is behind the scenes in i5/OS and the hypervisor. We should be able to read and populate database tables in other partitions by opening a DB2/400 DDM file, and tables in databases in other OS partitions can be front ends for DB2/400 by pushing data on to a DDM call interface. - Other OS partitions extend our library list namespace. We can call any program in any partition with an RPC call doing the work behind the scenes for library list entries for other partitions. They should appear as virtual ILE modules in our activation group. - Each i5/OS job should have a local socket IP address based on the job number, pseudo numbering if necessary, but guaranteed access internally from any OS partition to job x via the local socket given authority to access it. - An i5/OS virtual controller type should be made available that is seen by interactive programs as a terminal, but converts the 5250 buffer to XML with 5250 DDS keywords and distributes onward to registered connection socket for the job. An exit call API allows us to pre-process the XML buffer on the way out and then on the way back in before being converted back to a 5250 buffer for the EXFMT instruction of the interactive program. - Java and PHP should be part of ILE. We should be able to call programs or library functions in those environments seamlessly. We are single threaded and they may launch threads as part of the call, but that's fine. A JVM per subsystem with a thread per job when activated should be available to eliminate JVM startup overhead. - The /free compiler should accept and parse Java Toolbox for the AS/400 syntax into /free syntax for compiling. I shouldn't have to switch among funky kludge syntax that's just because and standard syntax. The compiler should accept ==, !=, { for ;, and } for END in addition to converting Java Toolbox function calls to equivalent /free statements. - IBM should showcase the Eclipse RCP GUI interface for i5/OS screens and provide a standard way for us to access from interactive, even if it's just a Java canvas with font, 32 bit color, image, and standard component availability over the current 5250 text interface. The Lotus Java component project should be given life as i5/OS components, with the spreadsheet component being a virtual subfile spreadsheet direct against DB2/400 data, same with the other office components. - Our desktop clients need to parallel the integration on the i5 server. We need to leverage Eclipse RCP in that desktop integration as a partner with the server integration of the i5. rd

                        Comment


                        • #13
                          Selecting a Programming Language for Your Next Application

                          ** This thread discusses the Content article: Selecting a Programming Language for Your Next Application **
                          0

                          Comment


                          • #14
                            Selecting a Programming Language for Your Next Application

                            ShanePoad wrote: I have always said C is a syntax not a language. I always thought that "C" and "C++" were grades. Dave

                            Comment

                            Working...
                            X