Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Multilingual in an ILE World

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

  • Multilingual in an ILE World

    ** This thread discusses the article: Multilingual in an ILE World **
    ** This thread discusses the Content article: Multilingual in an ILE World **
    0

  • #2
    Multilingual in an ILE World

    ** This thread discusses the article: Multilingual in an ILE World **
    Joe, You are entitled to your opinions about ILE, JAVA, RPG, Microsoft, and everything else. Your expertise about Java, Eclipse, and other ISeries areas in unquestioned. When you bash Microsoft, you just sound like a bigot. They make good products that work, like it or not. By inference and association, yout makes all of us look like kids who can't get along outside of the clique. In fact, you come across a lot like Joe Dinonsaur, the Microsoft mascot. Nobody says you have to like or use Microsoft products. Your continual and uninformed ranting makes the rest of look like kids who can't adapt and need a bit of outsourcing. Why not just look for another source code editor to write about.

    Comment


    • #3
      Multilingual in an ILE World

      ** This thread discusses the article: Multilingual in an ILE World **
      wrote: "When you bash Microsoft, you just sound like a bigot. They make good products that work, like it or not. By inference and association, yout makes all of us look like kids who can't get along outside of the clique. In fact, you come across a lot like Joe Dinonsaur, the Microsoft mascot." I must agree with this comment. I'm a long time user of IBM midrange products since 1973 and currently support a staff of 10 on an iseries. On the other hand, I also have 10 .NET developers that have developed a website that has $50+ million in revenue on MS IIS using SQL Server and Dell hardware. It works flawlessly and the site has only been down once in the last 4.5 years due to any problems regarding Microsoft products. In fact -- and this is my experience -- our iSeries has been down more often than the MS based web site. It's a shame but personally, I can't state that the iSeries is a more reliable platform than Wintel. A side note to : Not stating your name in a forum undermins YOUR credibility! chuck Opinions expressed are not necessarily those of my employer.

      Comment


      • #4
        Multilingual in an ILE World

        ** This thread discusses the article: Multilingual in an ILE World **
        Chuck Ackerman wrote: > A side note to : Not stating your name in a forum undermins > YOUR credibility! I believe it's been discovered that this is a bug in the Website software. Bill

        Comment


        • #5
          Multilingual in an ILE World

          ** This thread discusses the article: Multilingual in an ILE World **
          Bill, Ah, I never use the website. Newsreaders are much more efficient. chuck Opinions expressed are not necessarily those of my employer. "Bill" wrote in message news:1B1FFBB4228AEE24F05B3724185654EE@in.WebX.Wawy ahGHajS... > Chuck Ackerman wrote: >> A side note to : Not stating your name in a forum undermins >> YOUR credibility! > > I believe it's been discovered that this is a bug in the Website software. > > Bill > >

          Comment


          • #6
            Multilingual in an ILE World

            ** This thread discusses the article: Multilingual in an ILE World **
            Those who know me know I like to nitpick. Here are a few obvious ones: ..., the ability to pass values as modifiable parameters is simply unknown in most other languages, ... That's not true. Reference parameters go back at least 40 years, at least back to PL/I. And Pascal had both address and value parameters back in 1971. To modify an object in a calling routine in a language like C, you have to pass a pointer and go through all the issues of referencing and dereferencing. Well, that's not too big a deal. To pass a parameter by reference, just pass the address: "&var". To deal with the parameter within the function, code it as "*var". It's just syntax, and not all that complicated syntax either. (If it's too complicated for you, C++ offers a syntax you might find more natural.) but the ILE designers were very savvy about that, making sure that you had fine-grained control over how your parameters were handled, through the keywords CONST and VALUE. CONST and VALUE are RPG keywords, not ILE keywords. And the concepts certainly didn't originate with RPG (or ILE) either. For example, in PL/I, you could pass something as an unmodifiable parameter by enclosing the parameter in parentheses. As an expression, the address of a temporary would be passed instead. In order to mitigate some of the danger, the ILE structure provides for the concept of a prototype, which strictly defines the interface for a procedure. ILE doesn't provide the concept of a prototype. Again, that's something provided by certain ILE languages, such as RPG and C. (Prototypes in RPG were actually inspired by C's prototypes.) It can mitigate some of the danger, but it's the programmers responsibility to ensure that the prototypes in the caller and callee match. Nothing in ILE will stop you if you don't have matching prototypes. Unlike loosely typed languages like JavaScript or Python, ... This is a common misconception. Python is definitely a strongly typed language. For example, if you try to add a number to a string, you get a TypeError exception. The difference between Python's strong typing and C's strong typing is that the C compiler will let you know about the type mismatch at compile time. (Skipping down a bit...) ... the JVM is designed to support a single language (Java) on every platform. There's nothing stopping anyone from implementing a compiler that generates Java Bytecode for any other language, and it's already been done. One example is the VARPG compiler. Another is Jython, a version of Python that runs on the JVM. That's enough nitpicking for now. Cheers! Hans

            Comment


            • #7
              Multilingual in an ILE World

              ** This thread discusses the article: Multilingual in an ILE World **
              Hi Joe, I would just like to clarify a couple of points you made regarding .Net & the iSeries in your article. "But most of all, from an iSeries standpoint, there is currently zero ability to run .NET code under OS/400 or i5/OS, which means that the integration of .NET with ILE is non-existent." This is not 100% correct from my experience, understandably, you could not be unaware of this when you wrote the article. Arterial software did a native port of Portable.Net (DotGNU) to the iSeries a while back (no PASE required). We had it compiling and running .NET .EXE and .DLL files from the IFS etc. The problem we encountered was with PNet's conservative Garbage Collector (http://www.hpl.hp.com/personal/Hans_Boehm/gc/) requirement to directly access/manipulate CPU hardware registers, not possible on the iSeries the way IBM has abstracted things. The same Garbage Collector code is also used by Mono (another open source .NET implementation) and many other applications and languages (http://www.mono-project.com/Main_Page). Portable.NET, is an implementation of the Common Language Infrastructure (CLI), more commonly known as ".NET", includes everything that you need to compile and run C# and C applications that use the base class libraries, XML, and Systems.Windows.Forms. Currently supported CPUs: x86, ppc, arm, parisc, s390, ia64, alpha, mips, sparc. Supported operating systems: GNU/Linux (on PCs, Sparc, iPAQ, Sharp Zaurus, PlayStation 2, Xbox,...), *BSD, Cygwin/Mingw32, Mac OS X, Solaris, AIX. http://www.southern-storm.com.au/portable_net.html http://www.dotgnu.org/ To try get around this we asked IBM if any API existed for the iSeries Garbage collection code implemented in SLIC for Java. Answer was no API exists nor was any contemplated, dead end. Our conclusion was we will need to write our own memory management code natively for iSeries. In the future we will revisit this. any IBMers listening? So, .NET code from other platform can run natively on iSeries, just runs out of memory eventually! "Of course, .NET doesn't support Java..." This is not strictly correct either. Portable.NET can alternately compile C# code to either JVM or IL byte code. Hope this helps. Regards, Bob

              Comment


              • #8
                Multilingual in an ILE World

                ** This thread discusses the article: Multilingual in an ILE World **
                Hi! Thanks for your input. I guess I'm just a little confused: which part of my message do you consider "bashing"? I say these things so often that I get a little confused myself, and I know that I can sometimes state the obvious, so maybe I'm just missing something. In this article, I devote less than a fourth of the column to Microsoft, and in that, the only thing I say that might not be strictly fact-based is that Microsoft dumbs down the IT message with its brainless Office commercials. But really, do those commercials speak to the IT professional in us? My other points about Microsoft: they want to wipe the iSeries and the JVM off the planet. They ruthlessly practice "embrace, extend, extinguish" to thwart competition. And the CLR is really nothing new. While not necessarily statements likely to put me in the Microsoft Lovers Hall of Fame, I'm trying hard to see why they rate as "bashing". Could it be that they're coming from me? It seems that there are people who will argue against anything I say. I say that Winter is cold, they say, "Not compared to inter-stellar space". I find I have to ignore those folks. Or is it just that my message--there is never a good reason to move iSeries applications to Windows--is so annoying to Microsoft advocates? I honestly don't know. Please, I value your input. Tell me which phrases in the article you found to be "Microsoft bashing" (and why) so that I can try to avoid them in the future, or at least try to temper my rhetoric a bit. I really don't want to sound like a bigot; I use Windows all the time, for better or for worse. Joe

                Comment


                • #9
                  Multilingual in an ILE World

                  ** This thread discusses the article: Multilingual in an ILE World **
                  Ah Hans. So you want to pick some nits, eh? And you use PL/I and Pascal as your examples?!?! You realize this puts you VERY close to that category of people who argue with me just to prove me wrong, correct? Had I said "common business languages", neither PL/I nor Pascal would apply, the former being a wonderful language but even more obscure outside of IBM than RPG, and Pacal never being intended to be a production language in the first place. I still contend that RPG's modifiable parameters make it much cooler than other commonly used business languages. But you're absolutely right, some other languages have them. And no, I WON'T argue the relative obscurity of PL/I. I'll let your bit about C remain as your opinion. Personally, I think pointers are the single thing most error-prone programming construct; the lack of pointers is something I really like about Java. As to CONST and VALUE, you got me there, Hans! Rigth between the eyes! I handily admit that in this article I often switched between the merits of ILE as an architecture and ILE RPG as an implementation of it. Please don't tell my wife... she'd be so ashamed... "Nothing in ILE will stop you if you don't have matching prototypes." This one I honestly don't understand. If I don't have the matching prototype, the modules won't bind, will they? I've never tried to deliberately use an incorrect prototype for a procedure, so maybe I'm just giving the binder some credit that is purely due to the compiler. "Python is definitely a strongly typed language." Ah, semantics. Guido van Rossum (the creator of Python) himself calls Python loosely typed: "So the fact that the language doesn't enforce types at either the compiler level or the implementation level is actually helpful." Since it's van Rossum himself who pronounces Python as loosely typed, I'll go with his definition. But really, yours is good, too. And yes, you're absolutely right, you can write a Java bytecode generator for any language. But I'm reasonably certain the JVM was designed to support Java; other languages are just a perk. Anyway, by my count, you definitely squashed several nits. Thanks! Joe

                  Comment


                  • #10
                    Multilingual in an ILE World

                    ** This thread discusses the article: Multilingual in an ILE World **
                    Thanks for your update, Bob! While I had heard of the Mono project, I had no knowledge whatsoever of an iSeries port of Portable.Net; that's great news! Personally, given the flux of the .NET world (for example, the phasing out of EnterpriseServices for Indigo) and the fact that Mno still doesn't even have a working Windows.Forms interface, I still have reservations as to the eventual real world usefulness of these projects. It seems likely that Microsoft could pull the rug out from under any such project, even inadvertantly, with each release of Windows (and since DotGNU seems to be pretty virulently anti-Microsoft, I wouldn't put it past Redmond to whack DotGNU upside the head a little). But on the plus side, the iSeries doesn't worry about little things like GUIs, so that makes porting to the iSeries a little easier perhaps than the desktop operating systems. Joe

                    Comment


                    • #11
                      Multilingual in an ILE World

                      ** This thread discusses the article: Multilingual in an ILE World **
                      Regarding matching prototypes, there is nothing in ILE that will prevent you from binding modules with mismatching prototypes. You may well get an error if there are differences in symbol names, but if one procedure expects a parameter of type reference to packed(15,3) and you actually pass a parameter of type reference to character array, ILE will happily bind away and you may have some fun tracking down the resulting bugs. RPG (and also C) doesn't mind either if you lie about the prototypes. It's only good practice (and nothing more) that obligates you to define your prototypes in /COPY members and include them in all your using modules. Regarding strong versus loose typing, I think I may have used the wrong terminology. GvR uses the term loose-typing when talking about Python. However, the language does require "types" to match when it really matters, at run-time. You might have had some experience with languages with no or loose type checking. (I have.) In languages like those, it doesn't really matter much how something is defined. For example, you can add an integer with a CHAR(4) and the compiler will emit an ADD instruction. But in Python, you may have no type checking when the program is loaded (call it "compile-time" if you will), but the type-checking at run-time is still quite strict. To get some understanding of some of the issues involved, read Bruce Eckels comments on Python. (As you might know, Bruce used to be a big Java fan.) The issue can be subtle, I agree. But strict type checking at run-time makes a lot of sense for a dynamic OO language like Python. Look at how compiled OO languages like Java handle strong compile-time type checking. Compilers like to know as much about the program semantics as possible in order to generate the most efficient code possible. (Some like to think strong compile-time type checking is there to "help" programmers!) However, in many cases in an OO program, you can't really know the type of an object until run-time. As a result, compiled OO languages add lots of language features to help the compiler try to understand the types in the program. Crufty features like type casting and interfaces are really there to help the compiler, but also serve to make the lives of programmers more difficult. Don't forget that even Java sometimes has to check the types of objects at run-time. Oh yeah, regarding pointers. Well, I had something to do with implementing them in the first release of RPG IV. I'd like to take this opportunity to apologize for that. ;-) Cheers! Hans

                      Comment


                      • #12
                        Multilingual in an ILE World

                        ** This thread discusses the article: Multilingual in an ILE World **
                        Thanks for the clarification on binding. It's interesting to know that the binder doesn't do any type checking of prototypes at bind time. That could allow some sneaky tricks to be played, but as long as you follow the convention of using the same protoype in both the caller and callee, you're fine. As to strong/loose typing, I agree, you may have used the wrong terminology . Seriously, though, I do understand the capabilities of soft typing; I make heavy use of it in my JavaScript functions. It allows for some incredibly terse method calling, which is very important when working under bandwidth constraints. And I accept your apologies vis-a-vis pointers . I use them, and even overuse them occasionally. Interestingly enough, they've bitten me at just about the same frequency in RPG as they have in every other language where I've used them (and this harkens back to the H/L registers in the old 8-bit Intel processors). Joe

                        Comment


                        • #13
                          Multilingual in an ILE World

                          ** This thread discusses the article: Multilingual in an ILE World **
                          Hans wrote: Regarding matching prototypes, there is nothing in ILE that will prevent you from binding modules with mismatching prototypes. I'm behind on responses but in reading the thread here on Joe's article I am puzzled. It should be well known that most people who gave an opinion questioned the requirement for a prototype declaration as well as the expected procedure declaration. Rather than justify this, responses ran to the tune of "gee, it's easy to make a copy and Wdsc even does it for you." Something that shouldn't be there doesn't cease to shouldn't be there because it's put there automatically, but I guess that's the level of thinking we have in IT these days. Now to my puzzlement. I had been thinking what if Java programmers were told everytime they created a method, make a copy of the header and copy it to the top of the class. At least I don't remember doing anything that dingy when I was writing Java, although it's been a few weeks since I've been able to get back to it. I was thinking about this when I read in the RPG manual the other day that the two copies are there to make sure it is what was intended, or something to that effect. I admit my mind wandered there at the time pondering such a statement. I wondered what in the world was the logic behind that. And now I see that where the ILE RPG compiler requires two copies to be in a program to match just because, across modules they don't even have to match? I see no point in these prototypes. It seems to me it should work like Java and interfaces used only when needed for a real purpose, not sort of required to be there all the time to check the copying capability of programmers or Wdsc. Of course, I could be all wrong, but either way I'm confused. rd

                          Comment


                          • #14
                            Multilingual in an ILE World

                            ** This thread discusses the article: Multilingual in an ILE World **
                            Hi Hans! I happened to have a few minutes free, so I wanted to engage you on the subject of typing. It may be a bit esoteric, at least at first, but as I peel back the layers of the onion, it appears to me that typing might be the most salient characteristic when deciding on a language for a specific task. But I digress; first I'd just like to know a little more. Hans: As a result, compiled OO languages add lots of language features to help the compiler try to understand the types in the program. Crufty features like type casting and interfaces are really there to help the compiler, but also serve to make the lives of programmers more difficult. This is both interesting and a little one-sided, I think. While casting and interfaces do indeed help the compiler, I don't think they're necessarily evil for a programmer, and a lot of that ca be gotten around as languages evolve. The generics in Java 5 definitely go a long way towards removing the casting burden for programmers, at least when processing homogenous lists. While not all lists are homogenous, they certainly are for a lot of business processes, and so I'd estimate that at least half (and probably much more) of your casting is eliminated with generics. The only place left for casting is heterogenous lists and downcasting within subclasses to reclassify an object from interface to concrete class. Can you think of other areas where strict typing gets in the way of the programmer? More importantly, though, is the idea of JIT compilation. The more the compiler knows about a piece of code, the better it can optimize it. That's simply the nature of the beast. And so, if the compiler has no idea what sort of data may be contained in an object, there's really not a ton of optimization to be done. Am I missing something there? Later, when I have more time, I want to get into the idea of how typing can play a role in language choice. To me, it's an issue of performance versus flexibility, and while you may have practically unlimited horsepower on a desktop, performance is more of an issue when you're dealing with servers (especially as we see the industry trending back towards server consolidation). But that's a different discussion . Joe

                            Comment


                            • #15
                              Multilingual in an ILE World

                              ** This thread discusses the article: Multilingual in an ILE World **
                              Am I missing something there? No, I don't think so. Keep in mind that I do tend to exaggerate (sometimes). I suppose my point is that many programming teachers have been telling us that strong compile-time type checking is good for us, like bran fiber or cod liver oil. If you back look at the history of programming, it may well have been true back when Pascal first came on the scene. At the time, in the early 1970's, programmers certainly did need a lot more structure and discipline in their craft. But the professors never told us that the other big reason for strong compile-time type checking was to make the life of the compiler writer easier. Don't forget that the first Pascal compilers were fast one-pass compilers, and could fit in a small amount of store. (I remember doing class assignments on a PDP-11/03, with the O/S, a source editor, Pascal compiler, and linker all on a 240KB floppy.) It all boils down to balancing different trade-offs. In any situation, some factors are more important than others. For example, performance. I don't know what the corresponding iSeries number is, but I've heard than in the mainframe world (my world now!), systems tend to run steadily, 24 hours a day, 7 days a week, at over ~90% utilization. Anything less, and the system owner is paying too much for his MIPS. So of course, in that kind of environment, run-time performance is vital, and a good optimizing compiler is very important. In other environments, rapid turnaround in the development cycle is more important. In these cases, performance bottlenecks can often be solved by adding a couple more servers. (I suppose Google is one of the most extreme examples of this.) For me, I've programmed in languages with late type checking (like Perl, REXX, and Python). And I've programmed in languages with early type checking (like Java and C). In my own experience, I can write working code much much faster in Python than in anything else. My experience isn't unique - others have noted the same. One reason is that you don't waste cycles chasing down nitpicky compiler diags. I found that in Java, I was always having to add a type cast or an exception handler, then recompile, and recompile again. There was nothing wrong with the logic I coded - it's just picky language rules. True, most lists tend to be homogenous, and not just for business programming, but that makes the necessary type casting even more annoying. I haven't fully formed an opinion on generics yet. I sort of lump it in with other cruft needed for early type checking - it is yet another thing which isn't needed at all in a late typed language. But on the other hand, I certainly don't disagree with their usefulness in a compiled OO language. Of course, at work, you have few choices. Most of us program in the languages our bosses tell us to. But when I can, I write tools using Python. And so far, I haven't had any complaints. (BTW, Java optimization was one of the topics in the course I took last week!) Cheers! Hans

                              Comment

                              Working...
                              X