Re: S-expression I/O in Ada

[Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org>]

On 08/07/2010 12:23 AM, Natacha Kerensikova wrote:
>
> I heard people claiming that the first language shapes the mind of
> coders (and they continue saying a whole generation of programmers has
> been mind-crippled by BASIC). My first language happened to be 386
> assembly, that might explain things. Anyway, I genuinely tried OOP
> with C++ (which I dropped because it's way too complex for me (and I'm
> tempted to say way too complex for the average coder, it should be
> reserved to the few geniuses actually able to fully master it)), but I
> never felt the need of anything beyond what can be done with a C
> struct containing function pointers.

Capers Jones, the function-point person, collected statistics on function points 
in various languages. One statistic was the average number of LOC to implement a 
function point. Function points may or may not be a good metric, but the values 
fell into 3 groups, which he labeled low-level languages (assembler and C), 
mid-level (FORTRAN, Pascal), and high-level (Ada).

Thus, there is a big difference in abstraction between C and Ada. C is about 
translating the problem into the capabilities of the solution language; Ada is 
(or should be) about modeling the problem in the software. C is about coding: 
mapping everything onto a small set of predefined representations. Ada is about 
SW engineering: creating useful abstractions that represent important aspects of 
the problem.

Effectively using Ada requires a different way of thinking from using C or 
assembler. You'll more quickly gain that mindset by asking how to approach 
specific problems in Ada, rather than how to do something you did in C.

I think there may be an analogy between languages and data representation 
formats: everything can be implemented in machine code, but that doesn't mean 
it's a good language for development. Similarly, everything may be represented 
as a sequence of bytes, but that doesn't mean it's an appropriate representation 
for an application.

An S-expression library might be a useful thing at a low-level, but few 
applications should call it directly. Instead, there should probably be at least 
one layer of abstraction on top of the low-level storage representation, so that 
the application only deals with appropriate application-level representations of 
the data.

Here, your problem seems to be how to have a human-readable storage format for 
your applications. While there is merit to discussing the pros and cons of the 
many existing formats to use, the Ada approach is to use an application-specific 
abstraction, hiding the implementation detail of which such format is eventually 
chosen.

-- 
Jeff Carter
"I blow my nose on you."
Monty Python & the Holy Grail
03

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---