Announcement

Collapse
No announcement yet.

Head Up

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

  • Head Up

    John S. is back. I posted a long reply in the Cafe. If any of you disagree with what I said there, let me know so I can adjust.

    Stan
    Do not go quiet into that good night,
    ... Rage, rage against the dark.

  • #2
    Well put.

    Rod
    Rod
    I want not 'not', not Knot, not Knott, not Nott, not knot, not naught, not nought, but aught.

    Comment


    • #3
      uCalc: final chapter

      Here's the PM I sent to Daniel Corbier today about uCalc. We won't be using uCalc.


      Hello Daniel,
      Sorry I didn't get back to you sooner.

      I shared the zip and the links with the rest of the team. We had a lively discussion considering how to use uCalc in the Converter Project. While the consensus is that uCalc is a good tool for this kind of work, I made the decision late Saturday that we will not be able to use uCalc at this time.

      There are two primary reasons for this decision. The learning curve is too steep for us to come up to speed fast enough to use it effectively, at least in the first development iteration.

      The second reason is that we have not yet developed a complete set of rules for how to translate VB6 to PB. Since uCalc LB is a rules based system, we are essentially in the same boat you were with the samples I sent: we don't know enough of the rules to write them down yet.

      There are some extremely complex issues involving the way VB uses objects instead of statements and functions. As an example we have identified 87 VB terms that can be treated as statements or functions. Everything else seems to be an object of one sort or another. Each built-in object has 50 or more attributes, which may be properties, events, or methods. VB also allows the programmer to create new objects in every program. On top of the object issue is the fact that VB is an extremely lenient system. Poor programming practices are tolerated in VB6 even more than we expected.

      I regret saying no to using uCalc, but as project coordinator I have to balance complexity against productivity in this case. In my opinion, it would add a level of complexity to the project without increasing the productivity of the volunteers. It may be possible to reconsider using uCalc when the project is more mature. Right now, though, I can't justify it.

      We do appreciate your interest in the project and your demonstration of the capabilities of uCalc Language Builder. Your product remains on our list of possible tools for future use.

      Stan
      Do not go quiet into that good night,
      ... Rage, rage against the dark.

      Comment

      Working...
      X