On an average, how much time does it take to become proficient in development using JD Edwards? Is it easy to learn? Are there any prerequisites?
I'm assuming you're interested on learning the development skills of JD Edwards, not the business processes that the system actually implements.
There are 2 versions of JDE. One runs over AS/400 plataforms, DB2 database and uses RPG (language) to implement reports and functionalities. I'm not acquainted with that version (did very few interface jobs and they were all complicated due to DB2's differences from my usual flavours of databases - Oracle or SQL Server).
The other version is EnterpriseOne (formerly OneWorld). I started developing for this version in 2000 and kept active until 2006. It's very easy to achieve the basic level of development and then you get to face the oddities and known issues from the system and how to dodge them and that's when you become experienced.
All development tools are internal to JDE. There's a table designer, a query designer (with a grid interface that resembles any visual query designer), an interactive programs designer (forms), a report designer and a business rules designer.
If you have experience with any RDA tool (like Visual Studio, for instance) and development for databases, you will be able to use this knowledge to ease the learning curve. In my case, I was a SQL programmer and I had a lot of experience with Visual Basic and Microsoft Access. I was able to use that experience by understanding the underlying concepts of the system and adapting for them. It took me about 25 hours of training with a more seasoned programmer to get me ready to at least do basic stuff on real customers. This amount of hours varies from person to person, obviously.
However, I can say that I only started to feel that I was understanding the tools and the process after 6 months of daily work on my first customer. After about 12-18 months, I was ashamed of the first applications that I wrote, so I actually went back and rewrote some on my own time... :-)
The thing about JDE is: there's very little coding/functionality on the database side (because it used to be flexible on databases choices). All the forms and reports are written inside the actual system by way of the designers.
All "coding" is done by way of a simple (and sometimes dumb) point-and-click interface. For instance: you don't write an assignment statement, like var = value. You select the Assignment button, then you select the variable in a list, then you select the value in a list (or enter the value, if it's fixed).
All the rules behind forms, reports and business rules are created that way. One exception: when you're writing a business rule, you can opt between using this approach (called Named Event Rule - NER) or using the C language (called Business Function).
If you choose NER, after you finish, the system actually converts that to C.
There are debug functionalities for forms, reports and business rules.
This is basic development. There are other tools and functionalities that are usually assigned to developers and so you will be able to do a lot more. I've worked a lot with interfaces, interoperability, workflow and more.
Also noteworthy is that JDE has an internal tool for managing objects, version control, checkins, checkouts and transfering objects from one environment to another to complete the development cicle.
As a developer, the more you learn about the business processes being implemented, the better. You get to learn the inside (code, specs) and outside (process) for the functionalities and this helps you as a developer and helps you in your career (and paygrade).
Now, my only caveat regarding my answer: as I've mentioned, it's been a while since I left JD Edwards development. As far as I know, things are pretty much the same, but I can't say for sure.
Best advice I can offer: go to www.jdelist.com for specific questions and help with issues. Be polite, try to ask questions about specific matters instead of general questions (I mean: if you ask those guys how long does it take to learn JDE, they will probably ignore you, but if you ask stuff like "in your opinion, what are the most complex tasks for a JDE developer to master?" you will probably get some pretty good answers).
Hope it helps and wish you good luck with JDE. After the initial bump, I enjoyed my ride on it quite a lot.
You can start with the JD Edwards EntepriseOne Developer guide to learn about object management work bench, design tools for table, form and reports and API for Business Functions.
https://docs.oracle.com/cd/E53430_01/nav/development.htm
As far as I can tell, it depends on the version of JDE. There are a lot of different components, and different versions (from what I can tell.) For example, a sister company of ours is running JDE over terminals to an AS/400. It's all "Green Screen" text-based screens, typing three letter commands at a command prompt, and using the cursor to move around the screen.
I haven't tried to learn it in depth yet, but trying to learn enough to do basic support has taken me several months at a few hours a week. Think of JDE as a baby version of SAP, that gives you an idea of the scope of your question.
I taught some classes about JDEdwards EnterpriseOne Development.
One of my students who never programmed before took about 320 hours of trainning to be able to do some developments on JDEdwards. Nowadays he's a coworker and a good programmer.
His 320 hours of trainning was:
During 5 months I taught on saturdays, 8 hours
Then he got another trainning which was 4 hours week and 8 hours on saturdays for 5 weeks
As I've said after all this, he has being able to perform all tasks of a JDEdwards Developer.
And my advice to who is going to study this is to have a good knowledge of SQL and have programmed before in any compiled language, it helps a lot.
Related
I am wondering about operating systems on where they are made. Just like windows, what is the programming language that Mr. Bill Gates used to achieved that OS. Any answers are welcome.
..operating systems..where they are made?
In the minds of outstanding fearless guys with their hands during endless sleepless nights and days while influenced by shining inspiration
..Windows, what is the programming language that Mr.Bill Gates used..?
History of Windows is long story. Some assembly language, some C, some C++, some shell scripting languages, combined together it is joint effort resulting in several millions of lines of code.
Taking into account that average developer can produce only a few lines of code per day, success of this project can not be easily repeated using scenario where one smart guy picks the right programming language and one day the sun shines and that guy becomes rich and happy and the world stands still with mouth wide open (I guess that was the original idea behind your question)
..what is the programming language that Mr. Bill Gates used to achieved that OS?
According to Wikipedia: DOS the OS sold by Mr.Bill Gates was actually developed by Mr.Tim Paterson and the historical articles available at his site indicate that it was written in assembly language
Even today, there are some cool guys able to create complete OS with GUI and networking etc. in assembly language, like those behind the MenuetOS.net project.
And then there are another cool guys able to create complete OS in C, like Mr.Linus Torvalds and his https://github.com/torvalds/linux
And then there are guys able to create complete computer as an environment supporting imagination built from visions and dreams with OS and applications and development environment and everything, like those behind the Squeak project which is based on the smalltalk language
...to be continued by ?...
Although your question seems like too broad without any research effort shown, I find it actually very good question. Every programmer needs to answer this question to (him/her)self one day, somehow. Hope that helps
In addition to really good answers, I want to share an interesting project about the topic. A project called COSMOS let you create your very own operating system by using C# language. Of course, there was no C# and COSMOS at the time when Bill Gates and his friends create their OS.
Check the link below.
https://cosmos.codeplex.com/
An Instructable is written for this. You can apply these step to create yours.
http://www.instructables.com/id/Make-A-Simple-Operating-System/?utm_source=base&utm_medium=related-instructables&utm_campaign=related_test
We are a team working on legacy code which is pretty old and written in languages of initial programming days. As the team members are trained in latest technology and are now put to work on legacy code, they are not happy. How to motivate them to work in legacy code also?
Send your team to meet users and watch them use software. They should find out what are most critical problems users have with that software.
Getting to know users makes work more real - your team will know that adding new functionality or eliminating some bugs will help some real person. That should motivate programmers to get boring job done.
Only cash can not make the developers happy. You should provide them good environment so that they can pay attention to their work.
Another thing is no technology is bad OR legacy OR older. Thing is if your company needs to maintain it, then you must keep it going. But keep all standards for designing, coding, testing, code review, interactive sessions etc..
Also you can motivate them to convert your legacy code to some new platform for better performance and maintainability. Every company does that even once i think, because they want to compete with other market products.
Also provide them some cool sessions for other technologies which are used in your company but they don't know or use. Let them be deeply in the things, give them proper time and support for problem solving. Main goal is to deliver on time with less rework and bugs.
Provide some rewards towards their work and keep them happy about their work.
thanks.
i really like "Send your team to meet users and watch them using software"
If i have to motivate my team, I will really ask my developer to visit the use and find out how much user is happy with the product.
I will really like to take challenge on how we can make it more better then what exist.
Do you have some scope for retiring the legacy code in the foreseeable future? If so, "we only need to keep this going until..." might sweeten the pill.
Are the team members experienced in the languages/environments which the legacy code is written in? If not, it might be simple reluctance to do something that they don't know how to operate. Possibly scheduling in some time for them to gain at least a passing familiarity might be in order; provided it's not too much of a paradigm shift from latest technology, it shouldn't be all that hard?
Are the team members only allowed to work on the legacy code team or can their time be split between different projects? I don't think anyone is going to be happy about spending a 40 hour week on FORTRAN debugging. But if you have to spend a few hours on the legacy code knowing that you can take breaks during the day to work on something you actually enjoy it's a little less painful.
And I'll reiterate what was said before about making sure the team members have time to learn and gain experience with the old technologies before throwing them in there. Try to make the training enjoyable too. Our legacy code training was set up as a competition to see who could come up with the fastest/shortest/most complete/etc solution to interesting problems rather than having to look exclusively at the code we were to be working on. Really, that could be applied to the team's plan even if you don't have time set aside for training. Add a little competition to the task at hand or allow a little bit of time for challenging and competitive side projects.
How are they getting rewarded for working on these legacy products? Do you know what motivates them? Some people may prefer timely recognition and praise while others may expect cash or understanding that this isn't necessarily what they signed up for when they initially took the job. I'd be tempted to suggest having 1:1 meetings to see what would they like that would make them happier. Is it more money? More flexibility in time off? Training in the legacy technologies? Affirmation that they are doing good work on these ancient systems, as the initial programming days makes me think of mainframes and other really old tools that one may wonder, "How much longer will this run really?"
Cash isn't the answer. Free food, soft drinks, whatever, that only goes so far at alleviating the drudgery of legacy code work. What about trying to change their perspective?
"Anyone can do good work with modern code that has a nice IDE with refactoring built in, a ton of resources just one Google search away, but we proud few, we band of brothers, we are good enough to do this with ancient procedural languages. We'll tame this awful mess of code and do it with one hand behind our backs and create processes and tools to make sure the next poor bastards won't have it so bad."
I would say the simplest way to attract the most positive emotion from developers to legacy coding would be to make the old new in some way.
Have a session or two to identify what it is that the legacy code does, and then get an idea of what it would take to do it anew on a new architecture. The "new architecture" part is key, because 9/10 times, it's the architecture that is dreaded (spaghetti code, pre-standard conventions, etc...).
If you can't get your re-write estimates approved, then at least work out a plan to get your refactoring of legacy code into the daily maintenance. At the very least your developers will feel as though they are working towards something, and something new at that, instead of just monkey-wrenching the old decay that no one wants to even remember.
Just my 2ยข.
You can for example try to do fancy things on the testing side. Try out mocking frameworks etc.
Try also emphasize that handling legacy code is a good experience if you want to become a solid programmer, since every technology becomes eventually legacy.
Extra cash? :) Don't know anything else...
Even if it's new technologies legacy code it's not always a pleasure to work on such code, so on "initial technologies"... i guess the only motivating thing is to discover how programming was these days...
The amount of Time required in spending motivating the team and learning the legacy code and fixing it half heartedly can easily be used to build the same stuff in new platform , given the amount of resources , IDEs , expertise , frameworks etc available for free, the Good news you have the system in place you just need to meet the same behavior in new platform unlike we have to build something new for some product whose behavior and user experience we dont know .
A job came in to me that's built with CodeCharge - had a look at it and seems to be a pretty basic point-and-click site builder tool. Has anyone got any in-depth experience with it? My first reaction is one of horror and to just rebuild the code in Rails or PHP but I thought I'd ask the question first, maybe i'm missing something...
I'm currently evaluating it for use in quickly producing a back-office environment, and it seems a very comfortable way of getting an interface up and running quickly.
Once the code is generated it is simple, but easily modified for any special needs you have.
In short it is a very good tool (though it would seem that Iron Speed Designer is much better though much more expensive) for what it does - fast prototyping and almost no coding approach to developing a web application. In my opinion, not much different than a Ruby On Rails application in terms of functionality, and, I can generate the code in any language I want.
You have to realize, it is all about speed - some quality is thrown in, but it is a very generic of quality - this is NOT a custom application, mind you, the resulting code you get here might not be pretty but it is a few level higher than your average script kiddie code.
I'm seriously considering this tool for creating back-office applications for sites I develop - a fast and easy solution instead of mucking around in tables of data and useless and repetitive SQL code.
Codecharge is a powerful tool that I have used for over 10 years to build very large content management systems, CRMs and many other management type tools.
Its far from simple once you get into it, and honestly when you use a tool like Codecharge to cleanly generate your user interfaces, you end up with a healthier application that can last many many years.
For instance, I have three clients that have been running Codecharge created portals for over 10 years and they always comment how bug free they have been.
There is a learning curve to learning CodeCharge but it will also teach you what entire applications should have in place and it will please the executives every time because they can get functionality within hours or days rather than weeks or never.
Development teams will often not like it though, because they would rather hand code everything or use the latest and greatest approach to development.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
The organization that I currently work for seems to be heading in the direction of dictating to software developers which tools, languages, frameworks, etc. must be used. However, nobody has convinced me that this is a good thing. The main argument I have heard is that it will make training easier. But, after developing software for over 10 years, I've never relied on training to learn how to use an IDE, programming language, or anything else; so I just can't relate.
With the rapid speed at which technology evolves, and the s-l-o-w-n-e-s-s at which I know the standards will adapt, I am concerned that my customers will have requirements that I won't be able to easily implement or won't be able to implement as efficiently as I should. For example, if there is a UI requirement for an auto-complete feature in a web app, and no API has been approved for this yet, I would need to implement auto-complete myself as opposed to using one of the many APIs that provide it out of the box.
A more radical example is if my customers wanted to have Google Wave features. In that case I would want the flexibility of configuring my development environment (including the IDE) and selecting appropriate frameworks (ex: GWT) to use.
Please provide feedback on whether or not you think that software developer tools, languages, etc should be standardized and a few points to support your argument.
There is a lot of benefit for standardization. My organization has fairly set standards on what technology we will use. We realize strong benefits in the following areas ...
Hiring. It is easy to describe what technologies we are looking for and make sure our recruiters are looking for the right people.
License/Software costs. I can buy enterprise licenses easily. It gives me the opportunity to keep costs down by letting me spend more with a smaller number of vendors and thus get more leverage.
Consistency of delivery. Our teams have a very good idea of what projects will take to build, rollout and maintain because they have done it with success before (and they know the pitfalls too).
Agility. I can have one team take over for another or one individual take over for another more easily because of standardization.
Quality. We have peer reviews across teams as well as QA across teams.
Without a consistent use of a technology stack, tools, languages and frameworks, these types of benefits would be more difficult to realize. I am not closed off to new technologies, but there has to be a concrete reason beyond "what if I want to ..."
A major issue with standardization is that once standards are out there, they get stamped in concrete and are difficult to change. This is why our corporate IT environment is stuck on IE 6, and the best change control system we have access to is CVS. Given this situation, some developers break the rules, and some find jobs at more innovative companies.
You have a mixed bag here.
I wouldn't standardize on IDEs, because every developer works differently. Those who are insanely proficient in emacs may see their performance suffer if forced to use Visual Studio. I optimize my Visual Studio experience with a 30" monitor and find it incredibly productive.
However, standardizing on some tools, such as SCons or make or something to build products is perfectly reasonable.
Banning some libraries and having a process where new libraries are either approved or not is also very reasonable. I know lots of companies that ban boost, or JQuery, or ban open source libraries in general, etc. And they had good reasons for doing it. I know I got fairly upset when an intern incorporated some random "security" library he found on the internet without running it by anyone.
In the end every company is different. You have to be standardized enough to avoid serious complications and issues as people come and go, or as new products are formed and organizational structures change. But you have to be flexible enough to avoid re-inventing every wheel you need.
The important thing is to have clear reasons for adopting a certain tool or banning some other tool or library. You can't just have management dictate that thou shalt use this and not that without consulting the engineering team and making the decision for good reasons. And once decisions are made those reasons should be written down and clearly communicated.
And also, if, in the end, your favorite tool or library isn't adopted, please don't whine about it. Be adaptable and do your job, or find a new one that makes you happier.
I once worked for a manager who felt the need to innovate at every level of his software development operation. Every development tool had to be cutting edge (preferably in beta). Many of the tools he asked us to use didn't have good documentation, and training was not available. Ultimately, most of the technology we tried simply didn't work. We wasted a lot of time churning through new technologies, only to dump them when it became clear we couldn't make progress.
I tried to make the case that innovation is perfect in the area where your value proposition lies. Innovation can also be used judiciously where standard techniques fail. But for most mundane tasks, using tried-and-true tools and methods should be the default. Less risk, less cost, less management attention needed. So you can focus time and energy on the areas where innovation has the most benefit.
So I think standardization has an important role. But blindly saying everything must be standard is just as sure to fail as my manager who thought everything must be innovative.
The number one argument in favor of standardization is that it maximizes the ability of the organization as a whole to use a common body of knowledge. Don't know how custom web controls are built in ASP.NET/C#? Ask Bill down the hall who has the knowledge. If you use different tools, such organizational wisdom is cut off at the knees. While it is not good to be restricted to a least common denominator (and hopefully your management will realize this) you should not overlook the benefits of shared experience!
UPDATE: I do not agree that innovation and standardization are polar opposites. Indeed, would we have nearly the level of web innovation if we still had the mishmash of networking standards characteristic of the 1980s? No we would not. Of course, we might have more innovation on new low-level networking protocols but is that really worth it? In its place, we've had an explosion of creativity within the bounds of TCP/IP and the Web standards (http, html, etc.)
The trick is knowing how to standardize without using it as an argument for closing down all new exploration. For example, we use only ASP.NET/C#/SQL Server in my company but I'm perfectly open to the use of new tools within this framework (we recently adopted the DevExpress reporting package, for example, supplanting the earlier standard).
Standardization is a must for a productive development team. However that doesn't mean that you can't revist the standards from time to time to adjust them to new technologies and trends.
Whether you develop operations software for internal clients, or products for external clients, there is no compelling reason not to standardize. You certainly did not give one.
Had you seen how companies are struggling with holding heterogenous products together that have been maintained for 10 years or more, and are now a conglomerate of various technologies that developers at some point thought made sense, you would not have asked this question.
From the top of my head, I could name at least 2 well-known software companies that will be driven out of business because their cost of maintenance has become so high that they can no longer compete (but I won't).
I think the misconception here is that suppressing individualism would supress innovation. That is simply not true. It is poor technical leadership that suppresses innovation.
One unpleasant consequence of standardization is that it tends to stifle innovation.
Innovation is scary. It involves cost and risk.
Standardization is not scary. It reduces cost and risk in the short term. Until your competitors have created a game-changing innovation. Then standardization is very costly.
It depends on the organization I think. One like Microsoft, yes, there should be a bit of a standard. A small business with one IT department, no. A larger business with several offices around the world ... maybe.
it all depends :-P
Assuming the organization has a broad suite of enterprise applications to manage, I'd say no for the following reasons, though I may be taking the message of everything being the same a bit too literally:
Compromise on using best-of-breed for systems, e.g. if all the databases are to be MS-SQL then any Oracle DB solution is thrown out. This would also apply to the fact that everyone using an IDE has to use the same one whether they be doing Data Warehouse report development, web applications, console applications or winForms. I'm thinking of systems like ERP, CRM, SCM, CMS, SSO and various other TLAs, FLAs, and SLAs. (LA = Letter acronyms for a decoding hint if you need it)
Upgrading by committee is another interesting issue. Where if each team can choose their tools and have one person that decides it is to upgrade things, e.g. start using Visual Studio 2008 instead of Visual Studio 2005, now have to determine at what threshold is it worth it to upgrade everyone simultaneously which may be a big headache if there are more than a few developers. For example, over the past 10 years when would there be IDE changes, framework changes, etc.?
Exceptions to the standards. Could a contractor bring in something not used in the organization if they believe it helps them build better software, e.g. Resharper or other add-ons that some contractors believe are very worthwhile that the organization doesn't want to spend the money to get? What about legacy systems that may make the standard become a bit unwieldy, e.g. this was built in ASP.Net 1.1 and so everyone has to have VS 2003 installed even if most will never use it?
Just my thoughts on this.
There are several good reasons to standardize.
First, it allows the enterprise better organizational flexibility, if everybody is more or less familiar with the same things. It also allows people to help each other better. I can't help with problems in the ASP.NET stuff, and there's not all that many people who can help me on the C++ side.
Second, it reduces support problems and expenses. Oracle and SQL Server are both decent products, but using both for similar functions is only going to cause problems. Not to mention that I've been in shops using several widely different platforms to do similar things, and it wasn't fun.
Third, there are some things that just have to be standardized. We couldn't operate half with VS 2005 and VS 2008, since we keep project files under source control. We had to pick a time and convert over.
Fourth, in some businesses, it simplifies the regulatory problems. I don't know what business you're in. I work at a place where we can get away with making mistakes right now, but I've also contracted at a bank and a utility, where it's necessary to be able to show auditors that everything is going in a standard way.
Fifth, it can simplify procurement, if you're dealing with software that costs money.
This doesn't particularly limit us, since if there's something we need that isn't standardized on we just go ahead and get it or do it.
If you want to make a business case against standardization, you'll need to have a business-related argument. Your argument seems to be that you won't be able to implement features the user wants, and that is a consideration. Got another argument?
There's nothing wrong with standardizing on an IDE that is rich enough to be configured for individual developers.
However, do make sure that you don't prevent individual developers from using additional tools, as long as the tools are licensed and that the use of the tool by one developer doesn't require all other developers to use it.
For instance, I happen to use NORMA to help me design databases. The output is SQL Server DDL (or anything else I want). I can make the DDL part of the project without making my NORMA source part of it. Later developers do not need to use NORMA to work on the project.
On the other hand, if I decided to use the Configuration Section Designer to create configuration sections, then future developers would also have to use it. A decision would need to be made about whether to use that tool.
The company I work for uses C#, ASP.NET, JavaScript and generates HTML. The advantages over and above those mentioned above are that there is a perception of improved velocity for maintenance and adaptive changes. The disadvantages include generating some boredom for people who are technically savvy (geeky) and prefer to use a mix and match of languages, depending on what they fancy is better suited, or for 'performance reasons'.
Technical and personal supervision is always good to have when you are developing as fast as you can to meet tight deadlines and competing in a highly saturated market for web development.
Guess no new project is implemented in languages like Modula, Ada , Oberon .. anymore (right?). But still there are legacy systems floating around, popping out here and there looking for their creators. They cant find them because they might be retired sitting at a beach somewhere enjoying themselves.
Serious:
1) I am wondering if there are still active (experienced) Modula programmers around ?
2) Anyone experience with porting Modula code to a new hardware generation ?
3) Does anyone know about a tool that can re-engineer, means map Procedures and Mod-files in a graphical way. These tools are available for eg. C programs.
Sure, Modula Syntax is not that breathtaking in comparison to todays .net and Java API's with 1000's of methods, but if someone drop about 100.000 lines of almost undocumented sourcode at you (nicely mixed with some 8000 lines assembler), you better know if you better reject it. I have this request and I am very resistant. (Option: port and keep modula source or migrate to other language in 9 months!)
cheers
1) I am wondering if there are still active (experienced) Modula programmers around ?
There are plenty of them, but you have to do a bit of web search to find them. If you search for "Curriculum Vitae" (or "Resume") and "Modula-2" there should be plenty of hits. Also, anybody who has experience in Oberon, Pascal or Delphi will be able to handle Modula-2.
Also there are active Modula-2 projects, most notably:
GNU Modula-2 at http://www.nongnu.org/gm2
Modula-2 R10 at http://modula-2.net/m2r10
Modula2JCC at http://code.google.com/p/modula2jcc
Modulipse at http://modulipse.sourceforge.net
Schwarzer Kaffee http://sourceforge.net/projects/schwarzerkaffee
2) Anyone experience with porting Modula code to a new hardware generation ?
Ask on the GNU Modula-2 mailing list. Many GNU Modula-2 users have Modula-2 code from 16-bit DOS systems they like to port to modern platforms. The GNU Modula-2 website lists this as one important motivation for GM2. The GM2 mailing list is at:
http://lists.nongnu.org/mailman/listinfo/gm2
There is also the Modula-2 Usenet news group, you can reach it via the Google interface at
http://groups.google.com/group/comp.lang.modula2
Last but not least, there is a Modula-2 IRC channel at Freenode
irc://irc.freenode.net/#modula-2
3) How to assess 100.000 lines of Modula-2 source code
"if someone drop about 100.000 lines of almost undocumented sourcode at you (nicely mixed with some 8000 lines assembler), you better know if you better reject it. I have this request and I am very resistant. (Option: port and keep modula source or migrate to other language in 9 months!)"
You may want to contact Rick Sutcliffe, a well known Modula-2 scholar and book author who is also the maintainer of the Modula-2 FAQ in which he states that he does get hired to do consulting work for assessing Modula-2 source code in company take-over situations. It seems to me that your situation might be similar enough to justify hiring an expert to establish the value of the software that is offered to you.
The Modula-2 FAQ is at http://faq.modula2.net
1) I am wondering if there are still active (experienced) Modula programmers around ?
Yes, I'm one. But I already have a job :-)
2) Anyone experience with porting Modula code to a new hardware generation ?
Not clear if you meant porting code or porting a compiler. Porting Wirth's Modula-2 compiler (or Oberon compiler) should be easy. Ada and Modula-3 are another story.
3) Does anyone know about a tool that can re-engineer, means map Procedures and Mod-files in a graphical way. These tools are available for eg. C programs.
I don't understand the question. If you are looking to visualize the import graph of a Modula-2 program, you could easily write something to emit dot. Visualizing call graphs is another story.
Here's my bottom line on Modula-2 and Oberon:
Any C programmer worth his or her salt can quickly learn enough Modula-2 to maintain a large legacy application. Oberon's another story; its model of exported names and type extension is not like the object models found in other OO languages.
Wirth's genius as a language designer was to make things easy for the person writing the compiler. So if you need tools, any good compiler writer can produce them. Wirth's compiler should be available and easy to port.
Ada does not deserve to be mentioned in the same breath with Modula-2 and Oberon.
Ada is still an very active language. I use it in my own research since 1995 and in my lectures since last year at a university.
I myself don't know much of Modula, however I worked at a research center in Brazil that had a packet switching network project (Compac) that was entirely created in Modula-2. If I'm not mistaken they even developed the compiler/linker themselves. Since I don't feel at liberty to point you to specific persons, I would suggest you do a google search for "compac" and "cpqd" and I can pretty much guarantee you will find names of people involved in it. It should come as no surprise that references to it are quite old, from late 80's.
Modula-2 is architecturally not that dissimilar to C. A programmer familiar with C should have little trouble figuring out Modula-2. Given that your application has a significant body of assembler code then you will need someone with low-level skills anyway.
IIRC Modula-2's grammar is LL(1) or nearly so, so writing a parser to generate call graphs for a Modula-2 code base is not beyond the wit of man. Graphviz is your friend if you want a quick and easy way of visualising the call graphs. Again, this suggests that you're up for employing a 'real programmer' to do the porting work.
If you need a reasonably viable Modula-2 compiler, you could look at the Amsterdam Compiler Kit which does have a competent Modula-2 compiler that can target a wide variety of platforms, although it doesn't support Win32 IIRC.
I would suggest that documenting and porting the existing Modula-2 code base is probably easier than attempting to re-write it in C. However, if you need to move to a different processor architecture then you will have to re-write the assembly language bits anyway. This does rather change the value proposition of porting.
If it is you doing the porting then you might consider doing it in two steps.
Arrange with the customer to do a utility to generate the call graph and give them a feasibility study recommending what to do and some estimate of the scope.
Do the port, either porting the code base or re-writing it. Bear in mind that you may not need a low level language for the entire code base if you're running it on a modern computer. You may be able to do it in a mixture of (say) Python and C with less effort than would have been needed for a rewrite purely in C.
Yup.
I realise that you asked this question quite some time ago but I also know that projects that nobody like to handle get kind of delayed...
I built several large systems in Modula-2 over a span of ten years and have this insane habit of taking on impossible tasks.
I have not touched it for about ten years but am absolutely certain that I can port your system for you to almost any other platform. Why not get in touch with me if you are still interested?
Oh yeah - better still, we are both in Singapore :-)
ADW Modula-2 has now been released as freeware. http://www.modula2.org/adwm2/ Since it's free and supports 32 & 64-bit Windows applications (and I know Modula-2), I've picked it up and am using it for small utility work that I want to be a 64-bit Windows binary (most of my work is in Java and .Net, which are fine but sometimes a pure binary is best. I use MASM32 for 32-bit binary Windows apps already).
edit
There's also a project in the works (still very early on, not yet usable as of the date of this edit) now to compile Modula-2 on the JVM (with a transpile to Java option). https://github.com/m2sf/m2j