I just got my compiler set up the way I want it and I am ready for my
first ada project.
I have spent sometime with lua. Lua's library support is terrible but
lots of people love the language. Many people just build a rough
skeleton application in C and call it from lua.
Lua handles all the type checking and much of the logic in this
arrangement and C is mostly just library code.
Would this same approach seem logical for ada? -Patrick
> I just got my compiler set up the way I want it and I am ready for my
> first ada project.
> I have spent sometime with lua. Lua's library support is terrible but
> lots of people love the language. Many people just build a rough
> skeleton application in C and call it from lua.
> Lua handles all the type checking and much of the logic in this
> arrangement and C is mostly just library code.
> Would this same approach seem logical for ada? -Patrick
This might make sense, if you're claiming that Ada's "library support is terrible"; else, why would you make this comparison? It sounds like you want to use Ada, but not use the Ada libraries.
If you instead want to use Ada with a library for which you don't have an Ada interface, you can build (or look for) a binding to that library. This is done in Ada, not in another language. See the Ada packages Interfaces.*. Typically, you don't need to program in anything except Ada - that way, you get Ada's protection (to the extent possible) in with binding, just not within the library itself.
Typically a script language (for instance Lua) needs a compiled one
(here, C) to speak to the broader world. The interpreter, the run-
time, the library components, and so on are built with the compiled
language in order to have products in machine code (.exe, .dll in
Windows for instance).
Ada is a general-purpose, compiled language, so the relationship would
be different. You can make a whole standalone application fully in Ada
(with GUI, databases, number crunching, compression,...).
There is a broad standard Ada library that is very useful, it would be
silly to ignore it a priori just because of your experience with Lua!
Additionally, Ada can access numerous components written in classical
languages like Fortran or C via the Import pragma.
There are actually some very very useful ada librarys out there for
doing some amazing stuff. From the booch components to fuzzy logic all
written totally in ada.
I use em so I can stand on the extra wide shoulders of some of the
tremendous ada programmers out there.
Patrick <patr...@spellingbeewinnars.org> writes:
> I just got my compiler set up the way I want it and I am ready for my
> first ada project.
> I have spent sometime with lua. Lua's library support is terrible but
> lots of people love the language. Many people just build a rough
> skeleton application in C and call it from lua.
> Lua handles all the type checking and much of the logic in this
> arrangement and C is mostly just library code.
> Would this same approach seem logical for ada? -Patrick
It doesn't really seem logical for C! Perhaps I've misunderstood you.
I don't know Lua, but I do know Tcl, and the approach I've adopted is to
write the application engine, if you will, in Ada and the controls in
Tcl. The application engine can be very complicated, but the controls
are usually simple.
An example: this proc runs every 100 ms to see whether each of 4 lamps
should be lit or not. The Ada part of the app presents the function
getLampState which takes a string (the name of the lamp) and returns a
boolean (0 or 1, I expect) saying whether it should be lit. The GUI is
written in Tcl[/Tk], which it's good at, and the complex timing logic
about when the lamps should be lit is left to the Ada.
proc checkLampProc {} {
foreach l {a b c d} {
set s [getLampState $l]
if {$s} {
.c itemconfigure $l -fill yellow
} else {
.c itemconfigure $l -fill gray
}
}
after 100 checkLampProc
}
Patrick <patr...@spellingbeewinnars.org> writes:
> Hi Everyone
> I just got my compiler set up the way I want it and I am ready for my
> first ada project.
> I have spent sometime with lua. Lua's library support is terrible but
> lots of people love the language. Many people just build a rough
> skeleton application in C and call it from lua.
> Lua handles all the type checking and much of the logic in this
> arrangement and C is mostly just library code.
> Would this same approach seem logical for ada? -Patrick
Yes; "Anything C can do, Ada can do Better"
Lua should be used for user scripting, not large-scale programming.
Hi Brian, Just to clarify, I was not bashing ada in any way. I am just
getting started and don't really know much of anything, I am not
criticizing libraries I have never used.
I was thinking of intertwining C and ada via import and export pragmas
and the fdump-ada-spec feature. I am just a little mixed up about
whether to write a little C beforehand or to do everything in ada.
Hi Gautier!
Your right, I should give the ada libraries a go first
Hi tonyg, good point, not being a giant ada programmer myself, this
makes sense :)
Hi Simon I definitely want to write everything I can in ada, not C,
thanks
Hi Stephan
"Anything C can do, Ada can do Better" , yep sure seems like it,
that's why I'm here :)
Hi Dmitry
I never really thought about ada scripting C but yes, through the
import/export pragmas I guess it really is, thanks
On Feb 8, 3:10 pm, Patrick <patr...@spellingbeewinnars.org> wrote:
> Thanks Guys!
> I was thinking of intertwining C and ada via import and export pragmas
> and the fdump-ada-spec feature. I am just a little mixed up about
> whether to write a little C beforehand or to do everything in ada.
That makes some sense. Were I you I'd go with the REALLY-THICK-BINDING
approach, where you put the C importing (and executing) into a package
Body with only nice (read Ada) interfacing in the Spec... using it
your
user should have no clue C is ever involved.
> --
> Jeff Carter
> "I'm a lumberjack and I'm OK."
> Monty Python's Flying Circus
> 54
> --- Posted via news://freenews.netfront.net/ - Complaints to n...@netfront.net ---
I see.
But there's also something to be said about doing something yourself
(I.E. a "Learning Project")
and, in addition to that, I'm interested in interpreters/compilers --
though to be perfectly honest,
I don't consider myself to be particularly GOOD at them as they
usually stop before they're up and
working. (Life getting in the way or losing interest for a while or
hitting a problem that I've no
clue on how to address or somesuch.)
On Wed, 8 Feb 2012 18:08:21 -0800 (PST), Shark8 wrote:
> On Feb 8, 7:07 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Wed, 08 Feb 2012 07:02:12 -0500, Stephen Leake wrote:
>>> Patrick <patr...@spellingbeewinnars.org> writes:
>>>> Would this same approach seem logical for ada? -Patrick
>>> Yes; "Anything C can do, Ada can do Better"
>>> Lua should be used for user scripting, not large-scale programming.
>> There is no scripting which should not be done in Ada. Even if it does not
>> appear so at first glance, it is.
> HM -- That reminds me, I should re-try implementing a LISP interpreter
> in Ada.
No, the point is not to re-implement LISP, bash, perl, you name it, in Ada.
The point is to throw it away. The advantage of using Ada is Ada itself.
Le Thu, 09 Feb 2012 09:34:45 +0100, Dmitry A. Kazakov
<mail...@dmitry-kazakov.de> a écrit:
> No, the point is not to re-implement LISP, bash, perl, you name it, in
> Ada.
> The point is to throw it away. The advantage of using Ada is Ada itself.
Such an assertion seems silly to me (with apologize). No language at all,
not even Ada, could be an universal model for everything. There are place
for numerous DSL (read Domain Specific Language), and some scripting
languages, like LISP or derivatives, or logic programming languages, are a
kind of.
However, as Ada is good at procedural stuff, type and interface safety and
implementation, this make sense to implement DSL interpreters with Ada (a
compiler or interpreter for a language X, need not be implemented with X
itself).
Or else, can you reasonably demonstrate your assertion ?
-- “Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University
On Thu, 09 Feb 2012 10:55:08 +0100, Yannick Duchêne (Hibou57) wrote:
> Le Thu, 09 Feb 2012 09:34:45 +0100, Dmitry A. Kazakov
> <mail...@dmitry-kazakov.de> a écrit:
>> No, the point is not to re-implement LISP, bash, perl, you name it, in
>> Ada. The point is to throw it away. The advantage of using Ada is Ada itself.
> Such an assertion seems silly to me (with apologize).
Did you program something substantial in bash? (:-))
Again, the point is, that even if you believe that something is throw-away
and run-once enough to be written in something as disgusting as any popular
scripting language is, it would be an error to follow your belief.
You are not alone. I myself keep on repeating this kind of error being too
lazy to create a *.gpr file, to write the main procedure, to add Glib stuff
for spawning child processes, etc, resorting to bash and losing far more
than wining in the end.
> No language at all,
> not even Ada, could be an universal model for everything.
Since when a language became a model?
> There are place
> for numerous DSL (read Domain Specific Language),
I don't know how many such languages you know. My job is in particular to
deal with them and sometimes to design them. I know lots of them, far more
I wished to. The world would be a much better place without any of them.
If you want to be serious in pushing your argument, you have to show how
and why the domain's specific fails to fit into a strongly typed,
imperative, OO framework.
The only debatable position here is actually declarative vs. imperative.
But it won't fly with scripting languages anyway.
> and some scripting
> languages, like LISP or derivatives, or logic programming languages, are a
> kind of.
Interesting debate: theoretically, I would support fully Yannick.
But when looking at my practice the strange fact is that the only DSL
I'm using is command-line interpreter scripts.
I can do everything else straight in Ada, even:
1) on-purpose data conversions, sorting, aggregation (in one case,
replacing a R script; the Ada version ran hundred times faster and
solved a data modelling bottleneck for several people)
2) 3D models (instead of VRML or MAXScript)
3) random language generators (Ada is used there in a purely
functional way)
4) recompression of Zip archives by calling different Zippers and
taking the best compression ratio
In cases 2) and 4) I can definitely do a lot more than using a
corresponding DSL
_________________________
Gautier's Ada programming
http://sf.net/users/gdemont
Le Thu, 09 Feb 2012 11:45:31 +0100, Dmitry A. Kazakov
<mail...@dmitry-kazakov.de> a écrit:
>> No language at all,
>> not even Ada, could be an universal model for everything.
> Since when a language became a model?
Always been for me. I see Ada as a language providing a set of low level
models. All languages comes with their own model, even natural language
(people are just not aware of that fact).
> If you want to be serious in pushing your argument, you have to show how
> and why the domain's specific fails to fit into a strongly typed,
> imperative, OO framework.
First is readability. A DSL provide a specific set of vocabulary and a
syntax which, if well designed, emphase things where needed. Using Ada for
some things, would be like using assembly instead of Ada. With Ada you
don't have to care about setting‑up stack frame and cleaning it on return
nor you have to care about register vs memory allocation. The same way,
some domain don't have to care about private/public, limited/non‑limited,
local/library‑level. You could provide some package holding the
functionnalities of a DSL, a attempt to right what a DSL do in a simple
Ada program, but you will miss conciness and specifically designed context
which come with a DSL and help to focus on the DSL domain only.
> The only debatable position here is actually declarative vs. imperative.
> But it won't fly with scripting languages anyway.
It precisely do.
>> and some scripting
>> languages, like LISP or derivatives, or logic programming languages,
>> are a
>> kind of.
> ... mess.
Either you use it badly, or it is just not well suited to you in
particular. Does not imply this cannot suite well someones else.
What would be a real mess, would be an attempt to express Prolog clauses
with Ada arrays (arrays with anonymous types, of course; don't even think
about named array sub‑types). Would be bloated with no added value for
what matters to Prolog users. You would nearly have to create a new
derived type for each clauses if you wanted it to be real Ada.
Similar comments could apply with others, including some as common as SQL
is.
This does not mean all are good or perfect (SQL syntax is not good to me),
I just mean trying to replace all with Ada would make things worst.
-- “Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University
Le Thu, 09 Feb 2012 11:45:31 +0100, Dmitry A. Kazakov
<mail...@dmitry-kazakov.de> a écrit:
> Did you program something substantial in bash? (:-))
Sorry, I forgot: Bash is not a good example (:-))
-- “Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University
> Interesting debate: theoretically, I would support fully Yannick.
> But when looking at my practice the strange fact is that the only DSL
> I'm using is command-line interpreter scripts.
> I can do everything else straight in Ada, even:
> 1) on-purpose data conversions, sorting, aggregation (in one case,
> replacing a R script; the Ada version ran hundred times faster and
> solved a data modelling bottleneck for several people)
> 2) 3D models (instead of VRML or MAXScript)
> 3) random language generators (Ada is used there in a purely
> functional way)
> 4) recompression of Zip archives by calling different Zippers and
> taking the best compression ratio
> In cases 2) and 4) I can definitely do a lot more than using a
> corresponding DSL
I'd view this from a different angle, too. It isn't decisive,
I'm sure. The difference is not in the vocabulary, or in
convenience. Rather, there are things that one can do at the
language level (whatever the problem domain is) that is not
easily done using another language.
Suppose that some programming language has both data types
and associated sets of operations that are fundamental to handling
objects of this data type. Like one would expect addition to be
available with objects of numeric types. Such operations could
be somewhat like Ada's intrinsics, or like type attributes. Or they
could be somewhat like the schematic patterns of operations on
containers, etc. In any case, they, too, follow the conventional
scheme of (values, operations). But, what makes them different
is the kinds of values on the one hand and their "initial functions"
(from which to built more operations) on the other.
Suppose that data from some problem domain have a physical
structure that is very much comparable to the structure of the
above mentioned data types (data types as-is, not composed).
Likewise, the typical ways of using the data in the
domain are comparable to (language-based) operations on objects
of that data type (the "initial functions").
Then, "operational modes", the ways of doing things in the domain
will actually suggest such a "matching" programming language.
For example, "search" à la Prolog, or "generators" à la Icon
have influenced the types of built-in data structures and operations,
and have also influenced the interpretation of expressions.
The result is a different language, but a suitably different
language that is still a general purpose programming language.
The choice of a domain specific programming language in this sense
will be influenced by the domain: the data structures of the
domain might match the data structures in the language better.
The operations in the domain might match the ones of the language
better.
The difference between the languages when seen from this angle
is this: no need to produce yet another DSL to get language features
that are valuable in some domain.
Le Thu, 09 Feb 2012 12:08:37 +0100, Gautier write-only
<gautier_niou...@hotmail.com> a écrit:
> Interesting debate: theoretically, I would support fully Yannick.
> But when looking at my practice the strange fact is that the only DSL
> I'm using is command-line interpreter scripts.
On my own side, I sometime play with a Prolog interpreter of mine
(designed in SML), more often with SML, commonly with SQL and XSLT and I
was an M2T (Model To Text, which is an OMG language used in conjunction
with UML) user, and I am seasoned with RenderMan shader language (*). Just
that to be honest, I believe M2T and XSLT was an error, and Prolog program
would have been a better choice (I am placing all of Ada, Prolog and SML
at the same level, so for many things, to me, Prolog is the language of
choice just like Ada is for some other things).
(*) Just to cite languages with execution phase. There are also many DSL
in data representation area, what ever what data can means, but these are
not relevant to mention here, as Ada has nothing to do with it. Oh well,
may be there is finally one worth to note here, which is the one
AdaControl use :-P
> I can do everything else straight in Ada, even:
> 1) on-purpose data conversions, sorting, aggregation (in one case,
> replacing a R script; the Ada version ran hundred times faster and
> solved a data modelling bottleneck for several people)
No need for a DSL here, and Ada is indeed the best choice.
> 2) 3D models (instead of VRML or MAXScript)
Depend what you do (3D means nothing alone).
> 3) random language generators (Ada is used there in a purely
> functional way)
I don't understand.
> 4) recompression of Zip archives by calling different Zippers and
> taking the best compression ratio
No need for a DSL, so Ada is OK here too.
Avoid confusion: a DSL is not the first
lossy‑unsafe‑unreadable‑unmaintainable language with no added value you
encounter. A DSL is not a toy language launched by who‑know‑who in a
search of celebrity, so don't think about these when you read the word
“DSL” somewhere. Some are good, some are bad. The multiple so
called‑scripting languages everywhere are not DSL, they are just
symptomatic of unfinished software which every user is supposed to
fix/finish him/herself or symptomatic of some bad experience with
compilation process or symptomatic of “every thing must be free as bear
and what's free as bear here must run everywhere to get it free as bear
everywhere”. Except for some case, most DSL are confidential and do not
take part of the “hip” (although the concept of DSL is a bit buzzy since
some years, but tha's DSL as a whole, not one or another in particular).
Well, all of that to say if one expect to use Ada for extremely
everything, he/she gonna encounter some disillusions.
-- “Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University
Le Thu, 09 Feb 2012 14:48:50 +0100, Georg Bauhaus
<rm.dash-bauh...@futureapps.de> a écrit:
> The difference between the languages when seen from this angle
> is this: no need to produce yet another DSL to get language features
> that are valuable in some domain.
I agree with that (that's why I said elsewhere, XSLT and M2T should have
never been). Except when particular requirements of a user interface
states it differently.
-- “Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University
On Thu, 09 Feb 2012 14:42:02 +0100, Yannick Duchêne (Hibou57) wrote:
> Le Thu, 09 Feb 2012 11:45:31 +0100, Dmitry A. Kazakov
> <mail...@dmitry-kazakov.de> a écrit:
>>> No language at all,
>>> not even Ada, could be an universal model for everything.
>> Since when a language became a model?
> Always been for me. I see Ada as a language providing a set of low level
> models. All languages comes with their own model, even natural language
> (people are just not aware of that fact).
Maybe, but why this model must be "an universal model of everything" in
order to be able to program finite state automata (which modern computers
are)?
>> If you want to be serious in pushing your argument, you have to show how
>> and why the domain's specific fails to fit into a strongly typed,
>> imperative, OO framework.
> First is readability.
Huh, I remember a description of a 8-channel input device in such a
language. The text file containing it was 40 Kb long.
These languages are absolutely, ultimately unreadable, fully of useless
syntactic garbage and thousands of keywords of which nobody cared to define
what they are supposed to mean.
I don't claim that they could not be designed readable, but the fact that
they are usually developed by groups of engineers strikes any chance for
that. Language design is a very difficult task. There is no more than a
dozen of people in the world who could do that.
> Using Ada for
> some things, would be like using assembly instead of Ada.
Nope. Ada provides abstraction means based on ADTs, OO and packages. On
this measure DSLs are assemblers, as they provide practically no means for
encapsulation, abstraction, refactoring, reuse. For an outsider they might
look so easy to use, but they are not. In my area all these languages end
up as programs generated automatically from other languages, and nobody
reads that mess.
> You could provide some package holding the
> functionnalities of a DSL, a attempt to right what a DSL do in a simple
> Ada program, but you will miss conciness and specifically designed context
> which come with a DSL and help to focus on the DSL domain only.
This requires a proof. If you don't claim a need in a very special syntax
(e.g. MatLab/SIMULINK), you cannot make an argument here.
>> The only debatable position here is actually declarative vs. imperative.
>> But it won't fly with scripting languages anyway.
> It precisely do.
Really? How many *declarative* scripting languages are in use?
>>> and some scripting
>>> languages, like LISP or derivatives, or logic programming languages,
>>> are a
>>> kind of.
>> ... mess.
> Either you use it badly, or it is just not well suited to you in
> particular.
Rather they use me badly (:-)) I must touch them because in my realm
(automotive, energy) a lot of stuff is described in DSL languages.
> What would be a real mess, would be an attempt to express Prolog clauses
> with Ada arrays (arrays with anonymous types, of course; don't even think
> about named array sub‑types).
I see no problem to have a decent way do describe inference rules in Ada by
overriding "and", "or", "=" etc. Look at GNAT Spitbol package. There is no
big difference in describing patterns and rules of inference. This is
basically the same stuff.
> Similar comments could apply with others, including some as common as SQL is.
But SQL miserably fails as a language of relation algebra. I think that an
Ada implementation based on aggregates to describe tuples would be much
better. If ARG concentrated on improving the Ada's type system rather than
on hacking limited returns and exception throwing comments, Ada could
certainly be perfect for that.
Apart from the fact that a relational DB is not the brightest idea in the
world, when it comes to the objects just a bit more complex than integer or
string.
Here is where your fine idea of DSL collapses. There is no insulated
domains. Any specific language is turns unsuitable when faces the real
world. Program power set in SQL or path finding in SIMULINK...
> On Thu, 09 Feb 2012 14:42:02 +0100, Yannick Duchêne (Hibou57) wrote:
>> Le Thu, 09 Feb 2012 11:45:31 +0100, Dmitry A. Kazakov
>> <mail...@dmitry-kazakov.de> a écrit:
>>>> No language at all,
>>>> not even Ada, could be an universal model for everything.
>>> Since when a language became a model?
>> Always been for me. I see Ada as a language providing a set of low level
>> models. All languages comes with their own model, even natural language
>> (people are just not aware of that fact).
> Maybe, but why this model must be "an universal model of everything" in
> order to be able to program finite state automata (which modern computers
> are)?
When you created a specific model, you can hide implementation part. Ada
do this, and DSL do the same. Specific syntactic construct goes one step
above that, as it disallow to go outside of the domain, just like Ada
disallow (except with that specific generic subprogram) to bypass the type
system. DSL is when you need an hight level model and only that. I
understood what you mean, and believe me I already though about using
plain Ada (or Ada‑like) language with a package or set of package acting
as a specific engine. At best you always end with syntax limitation which
make the whole not expressive, or with the need to go with a whole
compiler where a single application could be enough.
>>> If you want to be serious in pushing your argument, you have to show
>>> how
>>> and why the domain's specific fails to fit into a strongly typed,
>>> imperative, OO framework.
>> First is readability.
> Huh, I remember a description of a 8-channel input device in such a
> language. The text file containing it was 40 Kb long.
> These languages are absolutely, ultimately unreadable, fully of useless
> syntactic garbage and thousands of keywords of which nobody cared to
> define
> what they are supposed to mean.
May be too big language (PL/I syndrom?). I don't know this “description of
a 8‑channel input device”. By the way, the way you talk about it, seems to
suggest this was a description language; not the same purpose as Ada.
Persisting in a bad choice is not a problem bring by DSL, that's a human
problem.
>> Using Ada for
>> some things, would be like using assembly instead of Ada.
> Nope. Ada provides abstraction means based on ADTs, OO and packages. On
> this measure DSLs are assemblers, as they provide practically no means
> for
> encapsulation, abstraction, refactoring, reuse.
Some domain simply don't need this. The only thing they may need in this
area, is typically package‑like structure, to organize and manage large
source. And this is not even a requirement, as the need come at some scale
only.
> This requires a proof. If you don't claim a need in a very special syntax
> (e.g. MatLab/SIMULINK), you cannot make an argument here.
One of the purpose of a DSL is to provide a special syntax.
> Really? How many *declarative* scripting languages are in use?
I said elsewhere (just my personal feeling), those scripting languages all
over the place, are not DSL. They are just I don't know what which is
supposed to avoid compilation even for long time running application and
run on any platform, kind of virtual machine, and often virtual
environment, as they typically come with their own set of libraries, own
installation system, own UI, etc. All of these scripting languages are
just a failure to either solve or simply accept the fact there exist
multiple environments which are all different enough (scripting language
is for viral software?). Or else, failure to accept what the nature of a
software is, something quickly becoming complex and requiring some
learning stage ahead. That's not the DSL topic, that's another topic. A
DSL may be compiled or interpreted, and will typically be a tiny language
(not required, as mathematics shows).
>> What would be a real mess, would be an attempt to express Prolog clauses
>> with Ada arrays (arrays with anonymous types, of course; don't even
>> think
>> about named array sub‑types).
> I see no problem to have a decent way do describe inference rules in Ada
> by
> overriding "and", "or", "=" etc. Look at GNAT Spitbol package. There is
> no
> big difference in describing patterns and rules of inference. This is
> basically the same stuff.
For what added value? And you will have to distribute an Ada compiler and
make people use it every time? Distribute with a wrapper? When just a
dedicated engine or interpreter is required, what a whole Ada compiler
have to afford?
> But SQL miserably fails as a language of relation algebra. I think that
> an
> Ada implementation based on aggregates to describe tuples would be much
> better. If ARG concentrated on improving the Ada's type system rather
> than
> on hacking limited returns and exception throwing comments, Ada could
> certainly be perfect for that.
> Apart from the fact that a relational DB is not the brightest idea in the
> world, when it comes to the objects just a bit more complex than integer
> or
> string.
> Here is where your fine idea of DSL collapses. There is no insulated
> domains. Any specific language is turns unsuitable when faces the real
> world. Program power set in SQL or path finding in SIMULINK...
Yes, I agree.
-- “Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University
