Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Tried? No, actually built (more than one) language convertor.</p> <p>Here's one I (and my coworkers) built for the <a href="http://www.semdesigns.com/Products/Services/NorthropGrummanB2.html" rel="nofollow noreferrer">B2 Spirit Stealth Bomber</a> to convert the mission software, coded in a legacy language, JOVIAL, into maintainable C code, with 100% automated conversion. One of the requirements was that we were NOT allowed to see the actual source code. No joke.</p> <p>You are right: if you get only a medium high conversion rate (e.g., 70-80%), the effort to finish the conversion is still very significant if indeed you can do it at all. We target 95%+ and do better when told to try harder as was the case for the B2. The only reason people accept medium high rate converters is because they can't find (or won't fund!) a better one, insist on starting <em>now</em>, and accept the fact that converting it this way may be painful (usually they don't know how much) but is in fact less painful than rebuilding it from scratch. (I happen to agree with this assessment: in general, projects that try to recode a large system from scratch usually fail and conversions using medium high conversion rate tools don't have as high a failure rate.)</p> <p>There are lots of bad conversion tools out there, something slapped together with a mountain of PERL code doing regexes on text strings, or some YACC-based parser with code generation essentially one-to-one for each statement in the compilation unit. The former are built by people who had a conversion dropped on them out of the sky. The latter are often built by well-intentioned engineers that don't have decent compiler background.</p> <p>For a singularly bad example, see my response to this SO question about COBOL migration: <a href="https://stackoverflow.com/questions/1029974/experience-migrating-legacy-cobol-pl1-to-java">Experience migrating legacy Cobol/PL1 to Java</a>, which is exactly a direct statement translator... producing the stuff that gave rise to the term "JOBOL".</p> <p>To get such high-accuracy conversion rates, you need high-quality parsers, and means to build high-quality translation rules that preserve semantics, and optimize for target-language properties and special cases. In essence, you need what amounts to configurable compiler technology. The reason we succeed, IMHO, is our <a href="http://www.semanticdesigns.com/Products/DMS/DMSToolkit.html" rel="nofollow noreferrer">DMS Software Reengineering Toolkit</a>, which was designed to do this job. (I'm the architect; check out my SO icon/bio).</p> <p>Lots of careful testing helps, too.</p> <p>DMS "knows" what the compiler knows about code, by virtue of having a compiler-like front end for the language of interest, and having the ability to build ASTs, symbol tables, control and data flows, call graphs. It uses much of the compiler technology that the compiler community spent the last half-century inventing, <em>because that stuff has been proven to be useful in translation!</em></p> <p>DMS knows <em>more</em> than most compilers know, because it can read/analyze/transform the entire application at once; most compilers stick to single compilation units. Thus one can code translation rules that depend on the entire application as opposed to just the current statement. We often add problem- or application-specific knowledge to improve the translation. This often shows up when converting special features of a language, or calls on libraries, where one must recognize the library calls as special idioms, and translate them to calls on compositions of target libraries and language constructs.</p> <p>This capability is used to build translators (e.g., the JOVIAL translator), or domain-specific code generators.</p> <p>More often we build complex automated software engineering tools that solve problems specific to customers, such as program analysis tools (dead code, duplicate code, style-broken code, metrics, architecture extraction, ...), and mass change tools (platform [not langauge] migrations, data layer insertion, API replacement, ...)</p>
    singulars
    1. This table or related slice is empty.
    1. POExperiences with "language converters"?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommunity
    1. USIra Baxter
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. CO"Tried? No, actually built (more than one) langauge convertor." How did you build them without trying them? :)
      singulars
      1. PO
      1. USnico
    2. COWhile this is really a rhetorical question, it deserves a bit of an answer. 1) You need good system functionality tests; these are extremely hard to get as most customers don't have any kind of tests! So, *somebody* gets to code them. 2) You can heavily unit test the translators by enumerating the sets of language constructs/special cases as units, and running translation/checking on them. That pays off big time, because if you can reliably translate the language constructs/library calls and their compositions, you can translate entire programs reliably. This is how you test compilers.
      singulars
      1. PO
      1. USIra Baxter
    3. CO"You need good system functionality tests; these are extremely hard to get as most customers don't have any kind of tests! So, somebody gets to code them. " Well you are to right about that, that is also the problem I'm facing but in my case it's Access and partly extremly poor paste+copy+error "code" ;-(
      singulars
      1. PO
      1. USFriedrich
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload