Non-text format for source code

I am seeing the tide go out from those approaches. Peaked about 2007ish. YMMV. And I'll exclude "Matlab to 'C'" - that still happens.

--
Les Cargill
Reply to
Les Cargill
Loading thread data ...

Yep. All the CASE tool vendors go out of business otherwise.

--
Les Cargill
Reply to
Les Cargill

Don't get me wrong. I'm totally for tools that validate the crap I code, and if there were a domain-specific language to make that job easier, I would use it. For one of our earlier products, I even wrote a program that decompiled statemachines written in C into a model and verified its consistency (our statemachine implementer had a very regular way of formatting his source :-)

However, what I'm seeing now from the modelers is huge spaghetti state machines nobody understands. The only advantage of those is that the modelers can see that the device actually opens the MENU_SCREEN when the "Menu" button is pressed in the OPENING_SCREEN by simulating the state machine on a PC.

And then I'm seeing people who do not use language constructs that are appropriate for solving a problem (like outlined above) because the modeler won't let them. For another example, we have about a hundred files like "VectorOfInt.hpp" that just contain a single typedef "typedef std::vector VectorOfInt;", because the modeling tool cannot handle templates (but can be told "hey, there's a class 'VectorOfInt' in ).

And all that makes code harder to understand and larger. In other words: worse.

It may not be a problem when you're developing for a huge Java application server. Code is too big? Add a few gigs of RAM. Code crashes? Well, the user get's a HTTP 500 error and an exception dump, but nothing dangerous. In embedded, I normally want to do better than that.

Stefan

Reply to
Stefan Reuther

Well, since you asked---there's the Literate Programming method, started by the Great Don Knuth. There was a gaggle of Tangle/Weave systems for original Pascal and then for Fortran, C, C++ and even some modular tools that supported a wide variety. It was neat to be able to have one master document that processed into LaTex and then PDF as well as into HTML, and which generated all computer files as well: compilable source, Makefiles, test harness and data. The tools understood the syntax, so they indexed and hyperlinked the source.

My favorite feature, however, was the decoupling from the compiler requirements. The master document defined chunks of code which were subsequently reassembled for compilable source. Usually one defined logically atomic chunks much shorter than a typical compilation unit; such chunks could contain all related material in one place, including source code, explanation with fancy TeX math, test data and harness, all variable declarations and definitions, all in one logical place.

Needless to say it was too structured and never took the world by storm. Doxygen is a pale shadow of the Literate Programming.

Reply to
Przemek Klosowski

or even better, documentation should BE the source code, as in Literate programming (see my previous posting answering Vladimir's original query)

Reply to
Przemek Klosowski

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.