Hi Everybody,Seeing some opinions expressed in the forum concerning principles for the evolution of SMath, I feel opportune to add some comments of my own.
Culturally, I’m not afraid of sometimes being wrong or to face contradictorily reasonable exchanges.
Here, I’ll go out of the forum routine to deal with some particular cases and needs.
I expect some other’s opinions and feelings targeting common progress.
I’m abundantly using SMath, since 2012.
I insist on saying that I’m very happy with the SMath as it is now, despite all its lacks, and that I profit to express here all my deep gratitude and my congratulations to Andrey and to all the developers for their work during the time that becomes so history.
For the comprehension of my sayings, I mention that I’m a senior civil structural engineer, with an engineering attitude, practice and mentality. Mainly, my concerns and my options are about the usefulness of things and actions. For me, as well mathematics as programming are important tools but not objectives.
I use SMath in my works—didactic, scientific and engineering. I published papers and books using SMath. I contribute to the evolution of the Second Generation of the European Standards, called Eurocodes, also by using SMath.
A. Based on my experience, as SMath user, I sometimes expressed some of my evaluations and proposals, not always echoed… Some of my proposals are more on the “cosmetic” side, but others touch the fundamentals. So, for instance:
i) Assenting an important virtue of SMath – that of allowing the creation of good-looking applications, I consider that it would be comfortable in use to mark graphically the limits of cells in a matrix. The subject is in a long status quo, despite my repeated demands also shared by some others.
I also proposed to provide all SMath objects with the option of being or not surrounded in a box like all the SMath native regions.
ii) SMath does not manage (as the main programming languages do) the variable scope—the accessibility mode, inside and outside the segment of variable creation.
As it is now, in a SMath function, it can be used (read) and even modified (write) a variable defined in the main segment. Any variable with the same name in the main segment and in a routine is considered as public and hence exposed to read/write operations. Of course, this feature gives the advantage of avoiding variable declaration in the entire application and of simple access.
In engineering there is used a large quantity of variables; the variables names often have précised signification (essential for a “natural” design, comprehension and communication) and therefore they can appear in many functions as local names.
The protection against unwanted interferences by the local modification of names is leading to the high loudness of the file’s design. During my entire practice with SMath, I interpreted this feature as a major (“boring”) deficiency. I understood that for certain applications this feature is a big virtue. I mention again that the major programming languages handle explicitly the scope of variables.
IMHO, the major part of engineering applications is algorithmic, including significative use of names. My main reason for using SMath is exactly based on its capability to write formulas as in literature and also to handle units.
iii) For the comfortable use of a certain category of applications, as those in engineering, I find useful the creation of a special kind of user’s defined function model, sealed, having all variables as local, the only way for external communication being read-only, at the entrance and to the output, as, for instance, those in the embedded trigonometrical functions
.
B. I hope to contribute to the idea that modern engineering could have big profits to include tools like that produced by using SMath or MathCad. I find SMath as a fitted solution for many engineering calculations.
I repeatedly mention that I do not pretend to be more reasonable than others, on the side of the actual situation assessments.
I sometimes identified a sort of simplism in some people’s comprehension of the programming design, namely by expecting the same exigences of an application during its creation as during its use. A good programming tool must facilitate both hypostases.
That’s why I point out from the start that, IMHO, the main expectation of an informatics product is the freedom of multiple choices (avoiding “dictatorial” and “monopolistic” choices, frozenly embedded by the creator).
1. During the creation of a computer application, destined for others than its creator, the “cleanness” expectance is different for the application’s creator during his work process and that of the final user. So, the final (external user) expects:
• That the informatics product to be conformed to the basics and with the recognized principles and norms concerning the subject (also called as “referential”), so that the user can adopt the soft for making his decisions and assuming responsibilities.
Here I mention that most commercial soft are built as non-transparent boxes, letting the user with the full and exclusive responsibility without access to the full transformation of input data into the output result. This situation is at least paradoxical, abnormal and even unacceptable for funding the user’s responsibilities.
• Ergonomic construction is important for productivity.
• The WYSIWYN (what you see is what you need) behavior during the soft design is a profitable tendency.
• The total transparence and accessibility of the process are the main features and advantages of SMath, constitutive for the user’s confidence.
2. The creator (designer) of an application has a very different situation and a different expectation from the tool that he uses for the fabrication of the final application.
• It can be said that the software creation is mostly an initial “dirty work.” It is iterative, a long way from trial and errors to the final production. The start priority is not oriented for the beauty side and for the apparent cleanness, but it is more oriented for the facility to catch “bugs” and to inspect the right flaw. At the same time, I do not deny that a good-looking arrangement can facilitate the work.
• In SMath, the use of “ugly colors” and borders is useful (almost indispensable) to group families of information; they contribute to the clear understanding and control of various segments in a complex application during the inception phase.
• In engineering, during the creation of an application, there is a large amount of information to be operated. Handling names without confusion is often a truly hard task. This task is very complicated by the specificity of SMath to make public the names and not to provide the encapsulation of functions.
• Some users could be interested in building their own applications by using available bricks of code.
3. I hope that my assessments are not received as offenses by anyone. For avoiding any incomprehension, I insist on saying that “my game is exclusive to the ball - as they say in football - without targeting any players’ legs”.
I beg your pardon for the length of my sayings but, as somebody said, “I did not have enough time…”.
Finally, I use Mr. Kenny Lemens’s wise adage: “May this be of Good Help”.
Best regards,
Ioan 
