Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I am a graduate student majoring in Computer Science. My department teaches the majority of its courses using Java (though I did take one course on system architecture that used C to demonstrate processor scheduling, memory management, etc....but I digress).
I want to learn more about COBOL, but I don't have access to a mainframe system. Can anyone please recommend a free COBOL compiler for Windows that would enable me to get through some basic COBOL tutorials?
Disclaimer: yes, I've Googled this already, so hoping for some experienced individuals to give some further info.
Thanks!
Other posters have suggested Tiny COBOL, but have a look at OpenCOBOL too. OpenCOBOL
is a cross compiler to C and has a fairly active development community.
COBOL is not a difficult language to learn. Unless you are tying to work your way into a mainframe shop,
spending a lot of time studying COBOL may not have much career payback.
As belisarius pointed out, it is not the language as much as the environment that needs to be learned.
By analogy, there isn't very much to learn about the C language either. However,
just knowing C will not get you very far - you need to work with the
huge standard library that comes with it. COBOL is similar in that
respect. The difference is that COBOL does not come with a huge standard library, it is part of a package
that often includes: CICS, DB/2, MQ-Series and an array of other library services (LE Services in an IBM environment).
COBOL can be found outside of a mainframe environment but the mainframe
is its "real home". As a generalization, "mainframe" implies an IBM mainframe running Z/OS
(many may take exception to this statement). This publication: Introduction to the Mainframe - z/OS
is a good place to get a feel for what an IBM mainframe environment is like.
The things I find characterize COBOL are:
COBOL is a procedural language. Some vendors have added OO extensions
and new COBOL language standards include OO extensions, but this is largely window dressing.
COBOL is fundamentally a procedural language.
Data declaration. The PICTURE/USAGE thing is a bit of a mind bender. Data declaration combines
internal data representation (binary, packed decimal, floating point, character, etc.) with presentation
(number of digits, leading zeros, sign, etc.) into a single declaration.
REDEFINES used to provide different views of the same underlying memory.
Hierarchical data declarations. Data hierarchy is defined using level numbers. Level 1 defines the top of the
hierarchy and increasing numbers define lower levels. Levels 66 (in conjunction with RENAMES), 77, 88 have special meanings.
Flow of control. Many programmers (even some veteran COBOL programmers) view SECTION/PARAGRAPH
in a manner similar to a procedure call. They are completely different. SECTION/PARAGRAPH do
not follow normal stack oriented call/return semantics. COBOL uses a unique mechanism to manage
return from PERFORMed sections/paragraphs.
Monolithic programs with tons of global variables. It is not uncommon to find COBOL source files
running into thousands of lines with several hundred global variables.
COBOL doesn't have to be written this way - I believe this is a legacy dating back to a time when
procedure calls were considered costly but PERFORMing a SECTION/PARAGRAPH was very efficient. The habit
seems to have stuck and newer COBOL programs tend to be written as monolithic monsters too.
String handling nightmare. COBOL does financial calculations very well. It does not do
string handling very well at all. The string handling verbs INSPECT, STRING and UNSTRING can do
a number of interesting things, but manage to be quite aggravating too.
COPY/REPLACING and REPLACE compiler directives need to be understood. They behave somewhat
differently than file inclusion in most other languages. Most shops use COPY only for common record or
data declaration, others use them for common procedural code too (with REPLACING and or REPLACE).
Given a working knowledge of C, you should be able to pick up on COBOL without much difficulty.
I'll not address your specific question, since it was many years ago that I stopped working as a mainframe systems programmer (and with mainframes in general ... and that includes COBOL). Nevertheless, there are two points that I want to emphasize:
COBOL is an easy to learn language. You'll feel at first that the syntax is daunting. A lot of "divisions", "sections" , "paragraphs" ... just try to understand why they exist. Nobody writes those labels. The way COBOL uses and redefines data structures is perhaps the most interesting concept, try to understand it well.
This is the key point. I said "COBOL is easy". Now the bad news: being a fair mainframe COBOL programmer is NOT easy. But that has nothing to do with COBOL, it's the environment. The mainframe is big, and there are a lot of "ecosystems" in there. You have DB2, CICS, some JCL, and VSAM as a bare minimum, and perhaps a dozen more, depending on your installation. Printers, tapes and other specialized and hard to manage hardware too. Each one of them requires several years to tame, and that's the real value of a good mainframe programmer. Microfocus had an expensive compiler/environment product that was able to emulate a few of these features, but I think it's out of market now.
Anyway, dexterity with those features are usually acquired "on the shop" and very difficult (believe me) to get from a book or courseware.
That said, don't expect to get a mainframe job (other than a super-junior one) after learning and taming COBOL. That is just a first little step.
HTH!
There used to be a Cobol-to-C compiler and Eclipse IDE from a company called "The Kompany". The product was called "Kobol". It would let you write Cobol using an eclipse based environment that would be similar to what you would use for a mainframe (Rational Developer for Z). They have a free demo version and a cheap student version IIRC.
You will find that Cobol is easy to learn, easy to write and hard to shoot yourself in the foot with. That is one of the reasons it is so very popular with financial institutions.
I think it is great that you are adding Cobol to your toolbox.
Have you tried TinyCobol? I think I used it once and it wasn't bad.
A while back, MicroFocus had a free version of their IDE+Compiler (Net Express), but they no longer offer it. I'm pretty sure I have a copy of the installer somewhere around here, though I'm not sure that it would still be legal to install if they no longer offer the product. I can take a look later tonight (it would be on my other computer, which is currently headless and inactive) and see what I come up with.
Try OpenCOBOL http://www.opencobol.org/, it's free, it runs on Windows and Linux and is being actively developed.
Micro focus now offer their Personal Edition of Visual COBOL free for non-commercial use. This COBOL works with either Microsoft Visual Studio as a .Net language or Eclipse. It even comes with a lite version of Visual Studio so you don't have to buy that. You can download it from https://www.microfocus.com/product-downloads/vcpe/vcpe22/index.aspx
The open source OpenCOBOL at www.opencobol.org/ has now changed its name and location. Now called GNU Cobol it may be found at sourceforge.net/projects/open-cobol/. This is an excellent COBOL that implements a substantial part of the ANS 85 and ISO 2002 COBOL standards.
The GNU COBOL site also has a link to Gary Cutler's Programmers Guide to OpenCOBOL 1.1 which is an excellent language reference. If you are looking for learning materials you can try my COBOL tutorial at www.csis.ul.ie/cobol/course
There is also a very useful online version of COBOL that uses the OpenCOBOL compiler. It may be found at http://www.compileonline.com/compile_cobol_online.php
Check out their overly long "Hello world" program. In ISO 2002 COBOL the IDENTIFICATION DIVISION is not required and since the program stops when the end of the text is reached, the STOP RUN is not required either. Only the three lines shown below are actually required. Try it yourself.
PROGRAM-ID. HELLO-WORLD.
PROCEDURE DIVISION.
DISPLAY 'Hello, world'.
Related
I'm a fairly advanced hobby programmer. I consider myself capable at Objective-C, Java, some straight C, Python, and general MVC design.
I've written quite a few programs but they have all been relatively self-contained, using external libraries occasionally.
When reading about larger projects, and/or more complicated programs, I hear a lot of language thrown around about "Writing one part in X, and writing this part in Y."
Since I have a lack of experience with this, I was wondering if someone could point me in the right direction. What general designs/mechanisms are employed for applications or projects written in more than one language? What is involved in a "scriptable" design?
Thanks for any guidance on the topic!
-Chase
There is no single "right way". A multitude of approaches exist, including the .NET-way, where all the languages are hosted inside a common runtime environment with well-specified interoperability constraints, and a good old Unix-way, where all the components are supposed to communicate via pipes or sockets, using simple text-based protocols.
For the latter you can read a classic book: http://en.wikipedia.org/wiki/The_Unix_Programming_Environment
Depends on what you need to do. For example if you want to build a poker game online then, most probably you would use java for the application and flash/flex for the interface. Java has the power of the libraries and the flash/flex are quite generally available and offer a rich interface.
If you have a software that receives input from an online application and offers output on a specific output (label printer for example) then your online-ready software (Java/PHP/Python) would best communicate with a specially designed program on the target computer. A program for which I'd use C++ for it's technical power, rigurosity and speed compared to java.
The idea is to identify the languages that suit your purpose best. In my opinion it is ideal that you use one language to do all the stuff, that is why I like java as it seems to fit everything although it has a more or less bad renown for slowness.
I see things in a kind of this way:
1. Engineered, machine oriented stuff then it is C++ (and languages of it's kind)
2. Mobile multifunctional stuff (middle-ware mainly) Java
3. Online , browser based stuff PHP especially for B2C(people oriented) applications
4. Python,Ruby etc are from my point of view somewhere between java and PHP but I never really worked with them so I can not give an exact opinion
You can link them together depending on your needs.
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 6 years ago.
Improve this question
The language site: http://processing.org/
What are people using Processing for? I have the opportunity to learn this in a classroom setting and am wondering if it will be a good use of my time.
Yes, it is useful and not a waste of time. I'm using Processing mainly for building proof-of-concepts for visualisations and graphic experiments. The time between an idea in my head and working code on my laptop is small, mainly because Processing does not throw too many obstacles in that course.
The ease of experimenting with things in Processing is an advantage in learning to program. Processing is actually a front-end to Java programs. At run-time the Processing code is translated to Java code.
Processing comes with a small but capable development environment (IDE), excellent documentation, a large library of extensions and a significant set of examples and demos.
Finally, I strongly recommend the book Processing: A Programming Handbook for Visual Designers and Artists by Casey Reas and Ben Fry, the authors of Processing. It's a beautiful book, carefully edited and full of sources for inspiration.
Processing has been used for hundreds of high-end projects in a wide range of fields, from multimedia installations to information visualization. It is not a toy or an educational exercise, despite its roots as a teaching tool.
The core application framework simplifies most common multimedia needs (OpenGL, Quicktime, PDF export, camera capture), removing project overhead involved in the boring task of setting up basic applications.It uses an extensible code structure that has allowed the creation of dozens of useful libraries for everything from 3D import / export to complex geometry synthesis.
So no, it is not a waste of time.
A references from my own work:
Stockspace
Anything that beautiful could never be a waste of time. :) It's probably the leading tool in its space, which would be something like, "Declarative languages for visualizing data". (Though I'm told it can do more than that.) Its got a O'Reilly book - that's always a great sign.
'Useful' and 'Beautiful' do not describe the library (processing is not a language), but the programs written in it. They are usually beautiful, but can be useful, too. Perhaps browsing it's showcase can give you a hint about some useful programs. Processing is very well suited for visualization apps, so it can indeed be useful for that.
Now, that's for the usefulness of the applications. For the usefulness of programming them, I think it's a pretty cool way to show more visually how some fundamental concepts of programs work, which you may find enjoyable. Processing is being used a lot nowadays to teach fundamentals of programming; it'd be cool to learn recursion by making fractals.
I have used processing for many interactive installations and found it really useful, because you get real fast results. Programming visual effects is really easy and elegant.
Some examples to watch:
http://www.youtube.com/watch?v=Ziv8Q5N7mSU
http://www.youtube.com/watch?v=zrT5uJox0J0
http://www.youtube.com/watch?v=Y58wBAp7mac
http://www.youtube.com/watch?v=EZp5HsFKxCs
http://www.youtube.com/watch?v=d4LcfsHQnYw
If you are dealing with a lot of data (many bitmaps, videos and sound) you might consider its limitations. I was happy to use it and will continue using it for certain projects.
So as a conclusion: processing is no waste of time. It's a really useful language for real world applications (in its own domain of course).
I agree with what the other posters have said, but I would add that every development tool has advantages and disadvantages. While it is easy to jump right in and visualize stuff with processing, the drawback is that it is hard to incorporate processing code into another project. Tools are in development to make this easier, but if you want a graphical environment that works in your application, all the time that processing saves you when prototyping is mostly lost in the re-adaptation of the code or getting it to work.
Processing is definitely useful for many purposes.
I think the post on "Processing for Programmers" by Eliot Lash answers your question very well, and in much detail. I'll give some highlights based on my experience below, but I recommend you have a look at the post, which also covers practicalities.
Your question has to do with the perception of Processing as a simple programming language and environment that doesn't require much experience to use. However, Processing is also a neat tool that makes life easier for more experienced developers, and the skills you develop with Processing can be definitely useful outside the "classroom" or prototyping contexts.
First off, as a programming language, Processing acts merely as a "layer" on top of Java that simplifies things. All Processing code is translated to Java code first. This means you can write Java code and import Java libraries in your Processing code, within (or outside) the Processing IDE. Pedagogically, this helps Processing serve as a "gateway" programming language into Java and other fully-featured languages. You can start coding with Processing, slowly make way into Java in a familiar environment, and then progress to more advanced tools.
You can also import Processing functionality into your Java projects (see here and here). This lets you exploit the speed and simplicity of Processing for multimedia etc., in the context of complex applications that require a more fully-featured programming language.
On top of these innate features, over the years, people have developed tools, libraries, etc. that can make your Processing skills useful in many contexts. Some examples:
Web/browser: Processing.js is a JavaScript library that lets you run Processing code verbatim in the browser. p5.js is a library for writing JavaScript based on Processing principles and functionality.
Mobile: You can develop Android apps using Processing by using the IDE in "Android mode".
Electronics, IoT...: The Arduino programming language and environment are very, very similar to Processing.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I'm part of a group that starts a new development project from scratch.
Currently it is on hobby-basis but we aim to make it our living
in the time frame of 1-2 years.
We are senior developers coming from a multitude of languages and techniques
with much of the focus on Java for the last few years.
Now, we're thinking of choice of toolsets and languages (the future is
bright when starting from scratch).
We want to be able to use modern architectures efficiently and have
good experience in Java and other JRE-based techniques.
The project is in short a lot of I/O, databases and a decent UI that probably
needs to be web-based and feel quite efficient.
One route to go is classic Java and build UI using GWT (or layers on top of GWT),
another is Scala + lift.
Then there are other techniques based on Ruby, Groovy and so on.
My question is then: What would you select as tools for a new long-term
project given the above. Is Scala here to stay for instance or is one
of those with only temporary hype?
What other techniques do you consider for larger projects from scratch?
Possibly your biggest binary choice is whether you decide to stay on the Java Virtual Machine (JVM) via either Java or one of the other languages which compile into bytecode, or to move onto some other platform, possibly Ruby or Python (with the complications of working with different architectures/operating systems that this may entail). Personally, I decided that I very much wanted to stick with the JVM and hence your language choices would be...
Scala
All I can give is my own experiences coming from a Java background: migrating to scala was made easy by its natural integration into the Java ecosystem and the ability to continue to use pretty much the same toolset in the same way.
By this last point I mean that the statically-typed nature of scala means that all the refactoring and code-navigation opportunities are still available to the developer but scala's type inference means that this comes without the unnecessary verbosity of type declarations littered throughout your code.
I can still use my favourite stuff like Spring, ant, IDEA and I can still use all the libraries I've ever written in Java (this is an argument for picking a language which integrates with Java over a completely new one like Ruby, Smalltalk or Python).
From the perspective of whether scala is here to stay as a JVM language, this is what concerned me most. But consider how many questions on SO have been tagged Jython (161), JRuby (176), clojure (388) and Groovy (661), assuming you wish to stay on the JVM. Not only is scala now well ahead of these (815) but it is growing at quite a rate.
Lastly, although I have not used Lift, a colleague has been extremely impressed with it (and I would probably look at it if I were writing a web application). The fat-client alternative (scala swing) I have found to be more than useable (better than raw swing at any rate!).
Groovy
It's worth noting that the creator of Groovy recently said that had he known of the existence of Scala, he would never have bothered to create Groovy!
JRuby / Jython
I have lumped these two languages together because they both represent an attempt to port the syntax of a dynamic language onto the JVM. Unless that syntax is already familiar to you, why would you bother to go down this route? I must say, the SO stats (above) do not indicate that these have the momentum at the moment.
I would also opine that moving from a statically-compiled to a dynamic language is a big step and you might be surprised by what you miss (in terms of refactoring and development aides etc.) - you may also care about the fact that the interpreted nature of these languages makes them over an order of magnitude slower than Scala.
Clojure
I have no real opinions on clojure other than to say that with an imperative background, its syntax is scary and its flow extremely unfamiliar. I am becoming more impressed by the functional paradigm but I felt that clojure was a step too far for me; I would be a fish out of water in the language, having no previous experience of LISP/Scheme.
The choice of language implies a lot of other choices, which collectively can be more important than the language choice itself. More specifically, when you choose a language, you're also choosing that language's web framework, ORM, IDE, build tool, etc.
For example, if you choose Groovy, you're implicitly also choosing the Grails web framework, if you choose Scala you're choosing Lift, etc. Although you can use Eclipse/Netbeans/IntelliJ for almost any JVM language, the experience varies quite a bit depending on which language you're using. Eclipse is a great IDE for Java development, but a pretty crappy one for Groovy/Grails development.
The problem with this kind of question is that if you ask a guy who uses language X, he'll tell you to choose X, then list all the reasons why X is so great and a few shallow reasons not to use the other languages. Examples of such shallow criticisms include:
Scala
poor tool support
functional programming is esoteric to typical OO developers
Groovy
dynamic languages are unsuitable for large projects
dynamic languages perform poorly
Jython
whitespace indendation as code block delimiters sucks
dynamic langages (see above)
JRuby
reputation for bad performance
funky syntax (from the POV of a Java developer, at least)
Clojure
very funky syntax (from the POV of almost everyone)
very immature
I should emphasise that I don't necessarily believe any of the statements above to be true,
the point I'm trying to make is that it's very easy to dismiss languages without any real experience of them (I only really know one of the languages above). So I wouldn't put too much faith in what people say against a particular language, unless you're sure they've really used it.
If I was faced with your choice I would use Groovy/Grails, because I find it to be an extremely productive and enjoyable technology to work with for building web apps, with good tool support. Are there other choices that might be even better? Sure, but Groovy/Grails is good enough for me (for now).
If you all have strong Java background and no functional and/or dynamic languages background, then you are likely to do well by keeping to Java or migrating to Scala.
I don't mean to disparage any of the other languages here, but Scala will be more familiar to you, and you can put your Java familiarity to good use. Whether you should jump to Scala or not -- that's another question. If you do, however, take notice that you need not be stuck with Lift. Not only there are other web frameworks in Scala, but people have had success combining Scala with traditional Java frameworks such as Wicket.
I worked a lot with Scala, Groovy and JRuby and I can share my experience
Scala
This language was designed in a very in a professional way. You can see it in every aspect of it.
No performance issues because it is a static typed language.
Interesting to learn and play with because of its functional nature.
BUT:
It is very complicated. You can't spend an evening to write a hello world program. You should spend at least a weekend)) Dmitry Jemerov (one of the creators of IntelliJ) said that Scala is much more complex than C++.
Lack of a good tool support. I believe that IDEs for Groovy and Ruby is much superior.
Not well integrated into java ecosystem. Of course you can use java libraries but you will dance a lot of all conversions from one collection to another e.t.c.
Lack of pure Scala libs. You always have to write a small wrapper over a java lib.
Groovy
Has shortcuts for most java boilerplate code.
Great IDE integration.
Interactions with Java are so natural and easy. It is not important whether you use a java class or a groovy class, it just works.
Great for writing DSLs
BUT:
It is a slow language (But I think that it is not an issue in most cases)
As the integration with java is the main goal of Groovy there are some unnatural aspects of the language.
JRuby
One of the best designed languages I've ever seen.
There are a lot of cool libs that can be used.
The best language for writing internal DSLs
Easy to learn.
BUT:
The integration with java sucks.
In my opinion it is too early to use Scala in production systems. It is just too hard because of the lack of tools and libraries. I used Groovy in many big projects quite successfully so it may be the best tool from these 3 languages.
With the information given you can choose any language proposed. They will all still be here in 5 years.
If you cannot decide which tool to pick for your requirements we can't help you. The information given is just to vague to decide. Start building some prototypes for all language/framework and see what fits best. Maybe the requirements are more clear afterwards.
Have you tried Jython -- Python working on JVM? I use it quite often to do various database tasks and it works quite well with such databases as Oracle, PostgreSQL and Informix. I do not create classic UI apps, but I have read that well known Python Web frameworks like web2py or django work with Jython.
If you have experience using dynamic languages, and are able to write the unit tests to support them, go that way. The development speed should be greater than what you can achieve from a static language. However, as the project will get bigger, it may become harder & harder to mantain ( it may only be me, but compile time checks help you a great deal ).
If however, you have Scala experience, I'd choose that instead. I find Scala to be a nice mix between Java and Ruby.
Good luck!
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 3 years ago.
Improve this question
I would like some practical guidance on when I should use a Domain Specific Language. I have found resources about advantages and disadvantages, but what kind of project would warrant its use?
It seems like there is a big investment in time to create and maintain a DSL, so in what application space would I get a productivity return on my time investment?
Edit: It seems the most common use of DSL is for file formats for persisting data state, what about using a DSL for program logic and structure(perhaps code generation)? When is this feasible?
Edit #2 I am mainly asking about when is creating a specific DSL worthwhile. Of course we should use existing DSLs as much as possible to save time.
There are very few good reasons for creating yet another DSL. The world is fat with special-purpose languages.
Think along with these lines.
Solve the problem with a general-purpose language such as Python, Java, C++.. whatever.
Optimize that solution to factor out the common features and build a really nice, really elegant, really extensible class library.
Optimize that class library to emphasize "orthogonality". Make sure all features work well together, without any problems.
If you need simplification of the syntax only, create a scripting wrapper around your nice class library. This is your DSL. For Python, this is easy -- it's already a dynamic language. For Java, there are things you can leverage. For C++ it can be a bit of work to build this flexible scripting environment.
If you still need further optimization, consider writing a compiler for your DSL.
The ACM Computing Surveys article When and How to Develop Domain-Specific Languages provides advice on just this topic, as does Martin Fowler's 2010 book Domain-Specific Languages.
Firstly, I would use a DSL when the problem domain your developing against is a widely well known domain, and some business experts of that domain have already went through great lengths to build such a DSL so that you wouldn't have to go through the lengths yourself to solve all the problems they have already figured out.
If you're thinking of creating a DSL, I would consider doing so if your business is done in a very particular area, and you spend the majority of your time focusing in a specific problem domain. If you bounce around doing applications for multiple problem domains, then I wouldn't advise taking that approach.
For example, if your business is soley in building tax applications, it might be a good idea to build a tax system DSL. This would allow your language not only to be useable by you in your various tax applications, but it would also be marketeable (useable) by other businesses in your industry that want to do similar things that you're accomplishing.
Of course, you have to weight the costs/benefits of building a DSL vs a framework on top of an already existing language.
One situation that comes to mind is when the requirements requires a very high or improbable level of customization/configuration. So you would provide a kind of scripting model against a DSL instead.
Takes a car assembly "arm" for example, providing a configuration model to support various factory configurations would be impossible. (detect this, don't detect that, when this happens do this ... etc.)
But compiling a new application with specialized logic for each customer is probably not a good way to go. So in this case, you create a little framework that would becomes a kind of DSL, and then for each robotic arm you sells, you write a little app in your DSL and save it along with the core software that would compiles and runs your DSL scripts instead. Or better yet, tools to program the DSL are included along with the robotic arm so your customer can "program" the arm themselves in the DSL you created.
One real world examples that comes to mind is Yahoo Pipes (you could think of it as a DSL) or the robots.txt directive for automated web crawler for example. They may not be a full-blown DSL but they demonstrate where DSL might be useful.
Well, someone has to say it, so here goes:
Lisp is regarded by some as the domain specific language for any domain. A well-supported and very extensible DSL at that.
In some cases, fashioning a DSL from Lisp (or a similar language such as Haskell) could actually provide a lot of power with minimal effort, and thus would be quite worthwhile. DSLs do not always need to be big maintenance burdens.
The most obvious is you should definitely use them when the language already exists and is well-supported. The prime examples of this are UIL for Motif-based GUI development and make for software builds.
If you have to make your own, I'd say to look for domains a large amount of effort is in just specifying things properly, and where your compiler can't really find most errors, but a domain-specific compiler could. GUIs are a great example, as most of the work is in setting up the layout, and there are generally lots of ways to make syntacticly valid C++ calls that make no sense whatsoever to your underlying GUI system (EG: trying to embed an entire dialog widget inside a button).
I find UIL particularly a huge gain for GUI development because a UIL compiler can find errors in a GUI specification that just look like nice normal compilable code to a C++ compilter. The fact that it is well-supported means that the code is easy to port between platforms, and even GUI builders.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
What successful conversion/rewrite have you done of software you were involved with? What where the languages and framework involved in the process? How large was the software in question? Finally what is the top one or two thing you learned from being involved with the process.
This is related to this question
I'm going for "most abstruse" here:
Ported an 8080 simulator written in
FORTRAN 77 from a DECSystem-10 running TOPS-10 to an
IBM 4381 mainframe running VM/CMS.
I rewrote 20,000 lines of Perl to use "use strict" in every file. I had to add "my" everywhere it was needed and I had to fix the bugs that were uncovered during the process.
The biggest thing I learned from doing this is, "It always takes longer than you think."
I had to get it done all at once overnight so that the other coders would not be writing new, unfixed code at the same time. I thought it would go quickly, but it didn't, and I was still hacking on it at 6 AM the next morning.
I did get it complete and checked in before everyone else started work though!
I rewrote a large java web application to an ASP.Net application for a realty company for various reasons.
The biggest thing I learned is that, no matter how trivial the feature the original system had, if it's not in the second system, the client thinks the rewrite is a failure. Expectation management is everything when writing the new system.
This is the biggest reason rewrites are so hard: it seems so easy to the client ("Just re-do what I already have and add a few things.").
The coolest one for me, I think, was the port of MAME to the iPod. It was a great learning experience with embedded hardware, and I got to work with a lot of great people. Official site.
I am doing a rewrite of an Inhouse Project managment system to a more standard MVC model. Its in the LAMP stack (PHP) and i am close to the 1st milestone.
The things i have learned from that currently is how simple the program feels at the beginning and i tried to not add complexity until i have to.
Example is that i programmed all the functionality first (like i was an admin user) and then when that is sorted out, add the complexity of having restrictions (user levels etc)
I ported/redesigned/rewrote a 30,000-line MS-DOS C++ program into a similar-length but much more fully-featured and usable Java Swing program.
I learned never to take another job involving C++ or Java.
I ported a client server Powerbuilder app, a couple of hundred screens worth, into an ASP.NET app (C#).
Due to performance and maintainability issues, I had over the previous year moved a ton of embedded SQL out of Powerbuilder scripts and into stored procedures.
Although this would make a lot of you wince, having a lot of business logic in the database, it mean the Powerbuilder app was relatively "light" and when we built the .Net front end, it could take advantage of the SQL codebase and have a lot of functionality already built and tested.
Not saying I'd recommend building apps that way, but it certainly worked to our advantage in this instance.
We had a code generation tool in our application framework that was used to read in text-based data files, About 20 other applications made use of it.
We wanted to make use of XML data files instead of structured text-based files. The original code was quite outdated and difficult to maintain. We replaced this tool by a combination of XSLT scripts and a utility library. For the utility library we could make use of some code in the old tool.
The result was that all 20 applications could now make use of either the obsolete text based file format or the new XML based format. We also delivered a conversion-generation tool that converted old data files to new XML data files.
After bringing out one or two release we have now decided that we will no longer support the old text based format and everybody is able to convert their data to XML.
We did hardly have to do manual conversions,
Converted the main company app from pre-standard C++ to standard C++. We had a multimillion dollar sale contingent on making it work on AIX, and after looking at it we decided that converting to standard C++ was going to be just as easy as converting to IBM's traditional C++.
I don't know the line count, but the source code ran to hundreds of megabytes.
We used standard Unix tools to do this, including vi and the assorted compilers.
It took a few months. Most of the fixes were simple ones, caught by the compiler and almost mechanically fixed. Some of them were much more complicated.
I think my main takeaway was: Don't get too awfully clever with code in a language that hasn't been standardized yet, or is likely to have things change in unexpected ways. We had to do a lot of digging in some of the ingenious adaptations/abuses of C++ streams.
Ten years ago I managed a team that converted a CAD system from DOS into Windows. The DOS version used home-brew libraries for graphics drawing, the Windows version used MFC. The software was about 70.000 lines of C code at the time of the conversion. The most important thing we learned in the process is the power of abstraction. All device-specific non-portable routines were isolated in a few files. It was therefore relatively easy to substitute the calls to the DOS-based library that would draw by directly accessing the frame buffer with Windows API calls. Similarly, for input we just substituted the event loop that checked for keyboard and mouse events, with the corresponding Windows event loop. We continued our policy of isolating the non-portable (this time Windows) code from the rest of the system, but we have not yet found this particularly useful. Perhaps one day we will port the system to Mac OS X and be thankful again.
Several. But I mention one.
It was a performance modeling tool. Part delphi 1, part turbo pascal. It needed a rewrite else it was not going to survive. So we started as a team of 2, but only me survived to the end. And I was ready before the deadline ;-).
Several things we did:
Make it multimodel. The original had lots of globals. I removed them all and multi model was easy to adapt.
Extended error messages. Click on a message and get the help.
Lots of graphs and diagrams. All clickable to drill down.
Simulation. Change parameters over time and see how long the current configuration was enough.
We really made this one clean and it paid back heavily in the end. Such a big learning experience.
Re-wrote a system for a company that processes legal invoices - the original system was a VB monstrosity that had no idea of good OO principles - everything was mixed together. The HTML did SQL, and the SQL wrote HTML. A large part of it was a custom rules engine that used something like XML for the rules.
Two teams did the re-write, which took about 9 months. One team did the web front end and the backend workflow, while the other team (that I was on) re-wrote the rules engine. The new system was written in C#, and was done test-first. Adding new rules to the system when we were done was dirt simple, and it was all testable. Along the way we did things like convert the company from VSS to SVN, implement continuous integration, automate the deployment, and teach the other developers how to do TDD and other Scrum/XP practices.
Managing expectations was crucial through the project. Having a customer that was savvy about software was very helpful.
Having a mix of large scale (end-to-end) tests along with comprehensive unit and integration tests helped tons.
Converted vBulletin which is written in PHP into C#/Asp.NET. I'm pretty familiar with both languages, but PHP is the hands down the winner for building that software. The biggest pain in the rear was needing to do a C# equivalent of PHP's eval() for calling the templates.
It was my first challenge in trying to do a conversion. I learned that I need more experience with C# and that writing it from scratch is just the easier route sometimes.
I converted a dynamical build-process completely written in Perl to a C#/.Net solution using a workflow-engine a co-worker had developed (which was still in beta - so I had to do some refinements). That gave me the oppertunity to add fail-safe and fail-over functionality to the build process.
Before you ask - no - the microsoft workflow-foundation could not be used since you cannot dynamically change a process during its runtime.
What I learned:
to hate the Perl-developer
process-optimization using a wf-engine
fail-safe and fail-over strategies
some C# tweaks ;)
In the end it covered about 5k - 6k (including the wf-engine) LoC origin from 3 200 LoC Perl-files. But it was fun - and far better in the end ;)
Converting theoretically portable C code into theoretically portable C code across architectures to support a hardware change that saves the company X dollars per unit.
The size varies - this is a common need, and I've done small and large projects.
I learned to write more portable C code. Elegance is great, but when it comes right down to it the compiler takes care of performance, and the code should be as simple and portable as possible.
Ported a simulation written in Fortran 77 (despite being written in the 90s) to C/Java because the original only worked on small data sets. I learned to love big O notation after several times of explaining why just moving the entire data table into memory at the start of the program was not going to scale.
Migrating the B-2 Stealth Bomber mission software from JOVIAL to C. 100% fully automated conversion. Seriously!
Main lesson: using configurable automated conversion tools is a huge win.
See DMS Software Reengineering Toolkit.