Q: type ... is new String

Q: type ... is new String

[tmoran]

Any comments on the effectiveness of using multiple types for different
categories of strings, rather than "String" all the time?
  I have a TV program database with a base directory, containing a folder
for each show, which in turn has a folder for each season, which then
has a folder for each episode, which then contains the actual video, eg
  c:\TV\I Love Lucy\1975\The New Neighbor\video.mpg
Instead of wordy, and error prone, calls on Ada.Directories.Compose, or
  Episode & '\' & Video_File
Would it be useful to have
  type Show_Paths is new String;
  type Season_Paths is new String;
  type Episode_Paths is new String;
  ...
  function "+"(Show : Show_Paths; Season : String) return Season_Paths;
  function "+"(Show_Season : Season_Paths; Episode : String)
    return Episode_Paths;
  etc
so one could write
  This_Show : Show_Paths := ...
  First_Episode_Name : String := ...
  Episode_Path : Episode_Paths := This_Show + "1975" + First_Episode_Name;
but the compiler would object to
  Episode_Path : Episode_Paths := This_Show + First_Episode_Name;

Re: Q: type ... is new String

[Dmitry A. Kazakov]

On Wed, 30 May 2012 16:33:45 +0000 (UTC), tmoran@acm.org wrote:

> Any comments on the effectiveness of using multiple types for different
> categories of strings, rather than "String" all the time?

I used that once to separate paths and simple names of objects. Not that I
am overly satisfied with the result, but it is still better than
effectively untyped mess.

Ada.Directories should not have used String for everything.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Q: type ... is new String

[Maciej Sobczak]

On 30 Maj, 18:33, tmo...@acm.org wrote:
> Any comments on the effectiveness of using multiple types for different
> categories of strings, rather than "String" all the time?

Interestingly, this is a bit different from defining multiple number
types instead of using standard types all the time.
The difference is that number types carry bounds as additional
information and that can be comfortably used to later define arrays,
loop ranges, etc.
Strings don't have this capability (unless, of course, you define
constrained String (A .. B) types) and the only added value of
defining separate types is in (potentially) increased readability and
(potential) compile-time assistance in avoiding mixing apples with
oranges. I write "potentially" in braces, as the balance between costs
and gains is not always obvious here - in particular, a gain in
readability can be devastated by later need to instantiate tons of
generics or spraying type casts all over the shop just to get simple
things done (example: try to print a log message containing several of
such values).

It is a typical engineering tradeoff between being rock-solid and
lightweight.

As to performance (if that was your original question), you *can*
expect some performance degradation due to these tons of instantiated
generics increasing the executable working set and competing for cache
space. How much? I have no idea. :-) And it has to be judged in the
context of the target system.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Q: type ... is new String

[Yannick Duchêne (Hibou57)]

Le Thu, 31 May 2012 09:37:22 +0200, Maciej Sobczak  
<see.my.homepage@gmail.com> a écrit:

> On 30 Maj, 18:33, tmo...@acm.org wrote:
>> Any comments on the effectiveness of using multiple types for different
>> categories of strings, rather than "String" all the time?
>
> Interestingly, this is a bit different from defining multiple number
> types instead of using standard types all the time.
> The difference is that number types carry bounds as additional
> information and that can be comfortably used to later define arrays,
> loop ranges, etc.
> Strings don't have this capability (unless, of course, you define
> constrained String (A .. B) types)

There is nothing like a range with text type, but there is still provision  
for contracts (pre/post in Ada 2012). An invariant for a Path_Type would  
be as much useful as a range for a numeric type would be.

Talking about range and this particular case, prior to Ada 2012, there was  
no way to narrow the range for a derive type of an array type, without  
freezing its bounds. It's now possible with Ada 2012.


Prior to Ada 2012:

    Minimum_Length : constant := <platform dependent>;
    Maximum_Length : constant := <platform dependent>;

    subtype Index_Type is Natural range Minimum_Length .. Maximum_Length;

    type Path_Type is new String (Index_Type);
    -- Unfortunately, this freeze the lower and upper bound, and the
    -- declaration below fails.

    XYZ_Location : Path_Type := "..................."; -- Will fail.


Since Ada 2012:

    Minimum_Length : constant := <platform dependent>;
    Maximum_Length : constant := <platform dependent>;

    subtype Index_Type is Natural range Minimum_Length .. Maximum_Length;

    subtype Path_Type is String
       with Static_Predicate => Path_Type'Length in Index_Type;
       -- You may add additional contracts, specific to file paths,
       -- like conformance with a format.

    XYZ_Location : Path_Type := "..................."; -- OK.

-- 
“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

Re: Q: type ... is new String

[J-P. Rosen]

Le 04/06/2012 07:58, Yannick Duchêne (Hibou57) a écrit :
>    Minimum_Length : constant := <platform dependent>;
>    Maximum_Length : constant := <platform dependent>;
> 
>    subtype Index_Type is Natural range Minimum_Length .. Maximum_Length;
> 
>    type Path_Type is new String (Index_Type);
>    -- Unfortunately, this freeze the lower and upper bound, and the
>    -- declaration below fails.
> 
>    XYZ_Location : Path_Type := "..................."; -- Will fail.
Why not:
type Path_Type is array (Index_Type range <>) of Character;

?
Reminder: There is nothing special to type String, you'll still have
literals etc.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Q: type ... is new String

[Yannick Duchêne (Hibou57)]

Le Mon, 04 Jun 2012 08:30:14 +0200, J-P. Rosen <rosen@adalog.fr> a écrit:

> Le 04/06/2012 07:58, Yannick Duchêne (Hibou57) a écrit :
>>    Minimum_Length : constant := <platform dependent>;
>>    Maximum_Length : constant := <platform dependent>;
>>
>>    subtype Index_Type is Natural range Minimum_Length .. Maximum_Length;
>>
>>    type Path_Type is new String (Index_Type);
>>    -- Unfortunately, this freeze the lower and upper bound, and the
>>    -- declaration below fails.
>>
>>    XYZ_Location : Path_Type := "..................."; -- Will fail.
> Why not:
> type Path_Type is array (Index_Type range <>) of Character;
>
> ?
> Reminder: There is nothing special to type String, you'll still have
> literals etc.

Good idea. I did not consider this one, may be due to the natural tendency  
of deriving from an already existing type with similar meaning.

While I'm OK with this idea and feel it good, I would not apply it,  
because I would prefer to derive from String. Ada lacks a way to narrow  
the allowed range of a derived array type.

-- 
“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

Re: Q: type ... is new String

[Dmitry A. Kazakov]

On Mon, 04 Jun 2012 09:48:07 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Mon, 04 Jun 2012 08:30:14 +0200, J-P. Rosen <rosen@adalog.fr> a �crit:
> 
>> Le 04/06/2012 07:58, Yannick Duch�ne (Hibou57) a �crit :
>>>    Minimum_Length : constant := <platform dependent>;
>>>    Maximum_Length : constant := <platform dependent>;
>>>
>>>    subtype Index_Type is Natural range Minimum_Length .. Maximum_Length;
>>>
>>>    type Path_Type is new String (Index_Type);
>>>    -- Unfortunately, this freeze the lower and upper bound, and the
>>>    -- declaration below fails.
>>>
>>>    XYZ_Location : Path_Type := "..................."; -- Will fail.
>> Why not:
>> type Path_Type is array (Index_Type range <>) of Character;
>>
>> ?
>> Reminder: There is nothing special to type String, you'll still have
>> literals etc.
> 
> Good idea. I did not consider this one, may be due to the natural tendency  
> of deriving from an already existing type with similar meaning.

It is not natural, it is sloppy. You (1) derive when the result type shall
be in the same class [with class-wide objects]. You (2) clone or use other
means to create an independent type when there shall be no class [no
class-wide objects]. It is a conscious design choice between 1 and 2.

> While I'm OK with this idea and feel it good, I would not apply it,  
> because I would prefer to derive from String. Ada lacks a way to narrow  
> the allowed range of a derived array type.

subtype Punch_Card is String (1..80); -- ?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Q: type ... is new String

[Yannick Duchêne (Hibou57)]

Le Mon, 04 Jun 2012 10:03:12 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Mon, 04 Jun 2012 09:48:07 +0200, Yannick Duchêne (Hibou57) wrote:
>
>> Le Mon, 04 Jun 2012 08:30:14 +0200, J-P. Rosen <rosen@adalog.fr> a  
>> écrit:
>>
>>> Le 04/06/2012 07:58, Yannick Duchêne (Hibou57) a écrit :
>>>>    Minimum_Length : constant := <platform dependent>;
>>>>    Maximum_Length : constant := <platform dependent>;
>>>>
>>>>    subtype Index_Type is Natural range Minimum_Length ..  
>>>> Maximum_Length;
>>>>
>>>>    type Path_Type is new String (Index_Type);
>>>>    -- Unfortunately, this freeze the lower and upper bound, and the
>>>>    -- declaration below fails.
>>>>
>>>>    XYZ_Location : Path_Type := "..................."; -- Will fail.
>>> Why not:
>>> type Path_Type is array (Index_Type range <>) of Character;
>>>
>>> ?
>>> Reminder: There is nothing special to type String, you'll still have
>>> literals etc.
>>
>> Good idea. I did not consider this one, may be due to the natural  
>> tendency
>> of deriving from an already existing type with similar meaning.
>
> It is not natural, it is sloppy. You (1) derive when the result type  
> shall
> be in the same class [with class-wide objects]. You (2) clone or use  
> other
> means to create an independent type when there shall be no class [no
> class-wide objects]. It is a conscious design choice between 1 and 2.
>
>> While I'm OK with this idea and feel it good, I would not apply it,
>> because I would prefer to derive from String. Ada lacks a way to narrow
>> the allowed range of a derived array type.
>
> subtype Punch_Card is String (1..80); -- ?

A path is intently a string is all platform I know, and that's not just a  
representation trick. A punch card is not the same, and that would indeed  
be an error to derive it from a string. You may find a file path in a text  
file, you may not find a punch card in a text file. A string and a file's  
path belongs to the same class.

-- 
“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

Re: Q: type ... is new String

[Dmitry A. Kazakov]

On Mon, 04 Jun 2012 10:14:55 +0200, Yannick Duch�ne (Hibou57) wrote:

> A path is intently a string is all platform I know,

RSX-11 had path of two letter device, two numbers of the directory,
RADIX-50 encoded file name, extension and numeric version. E.g.
DX:[1,54]HELLO.ADA;4. Neither part of this was ASCII string. And path
weren't stored anywhere if "internally" meant "kept on the magnetic
carrier."

> A string and a file's path belongs to the same class.

I prefer separate types for path, device, file name, for absolute and
relative paths.

A common class with strings may be present per conversions between strings
and paths. E.g. a path with non-Latin1 letters to String would raise
Constraint_Error.

However, if typed properly, you better have no implicit conversions to
strings at all. If you look into it, strings are actually used as a
middleman for rendering, I/O etc. A comprehensive design may need no such
thing. E.g. you would write paths directly to a text file and read them
from there back as you do with numbers.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Q: type ... is new String

[J-P. Rosen]

Le 04/06/2012 09:48, Yannick Duchêne (Hibou57) a écrit :
> Good idea. I did not consider this one, may be due to the natural
> tendency of deriving from an already existing type with similar meaning.
Which is very common, and to my taste, not a good idea.

One of the unique features of Ada is the ability to define your own
types that match your needs from scratch, without hooking them to some
predefined "magical" types with special properties, as happens in most
other languages.

Integer is an integer type like any other, String is an array type like
any other, etc. No reason to derive from them, but there are good
reasons not to. For example, if you define:
   type Int is new Integer range 1..10;

you inherit (by default) the representation of Integer, presumably 32
bits. And you can't define this way a type /wider/ than integer. If you
write:
   type Int is range 1..10;

the compiler chooses the most efficient implementation, and there is not
limit other than the capabilities of the machine.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Q: type ... is new String

[Yannick Duchêne (Hibou57)]

Le Wed, 30 May 2012 18:33:45 +0200, <tmoran@acm.org> a écrit:

> Any comments on the effectiveness of using multiple types for different
> categories of strings, rather than "String" all the time?
>   I have a TV program database with a base directory, containing a folder
> for each show, which in turn has a folder for each season, which then
> has a folder for each episode, which then contains the actual video, eg
>   c:\TV\I Love Lucy\1975\The New Neighbor\video.mpg
> Instead of wordy, and error prone, calls on Ada.Directories.Compose, or
>   Episode & '\' & Video_File
> Would it be useful to have
>   type Show_Paths is new String;
>   type Season_Paths is new String;
>   type Episode_Paths is new String;
>   ...

May be a single base Path_Type could be enough, and all others could be  
subtype of this base type.

-- 
“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

Re: Q: type ... is new String

[Brian Drummond]

On Wed, 30 May 2012 16:33:45 +0000, tmoran wrote:

> Any comments on the effectiveness of using multiple types for different
> categories of strings, rather than "String" all the time?

A comment from a different angle...

Some time ago, http://www.joelonsoftware.com/ was recommended to me as a 
good "inside voice" on (specifically C and C++) programming practice. And 
I started to enjoy these articles and agree with some of his points...

Until I read
http://www.joelonsoftware.com/articles/Wrong.html

specifically this quote from a section oddly titled "The Real Solution"...

"All strings that come from the user must be stored in variables (or 
database columns) with a name starting with the prefix "us" (for Unsafe 
String). All strings that have been HTML encoded or which came from a 
known-safe location must be stored in variables with a name starting with 
the prefix "s" (for Safe string)."

Now it seems to me that he would be better off saying
"type UnsafeString is new String;" 
and bypassing the rest of that (rather long) article entirely. And let 
the compiler catch the problems instead of uglifying the entire codebase  
so that he can tell programmers (I kid you not, it's a direct quote from 
the article!) "I know, it’s a little bit hard to see the wrong code at 
first, but do this for three weeks, and your eyes will adapt ..."

Three weeks? Jeez. And you know that's just the tip of the iceberg. 
What's wrong with just letting the compiler find the wrong code?

Now, we can debate the relative merits of "is new String" versus "is new 
Array <> of Character" but how do we get the message out there that 
recognized industry experts (and I'm not quoting "expert" because I 
believe he is, in his field) are recommending "Real Solutions" that 
impose weeks of painful and unnecessary work on unsuspecting programmers 
for ... what purpose? what gain?

Or am I missing something in that article?

- Brian

Re: Q: type ... is new String

[Maciej Sobczak]

On 4 Cze, 13:39, Brian Drummond <br...@shapes.demon.co.uk> wrote:

> Now it seems to me that he would be better off saying
> "type UnsafeString is new String;"
> and bypassing the rest of that (rather long) article entirely.

Except that it would not work in the language that he used for
presentation (which is VBScript, I guess).

> Or am I missing something in that article?

Yes, this:

"Let’s pretend that you’re building some kind of a web-based
application [...]"

The author describes a problem in a well-defined domain (web-based
apps written in some dynamically-typed language similar in nature to
VBScript) and presents a possible solution. Given the constraints, the
solution he proposed is probably the best he could do.

Like it or not, for many people switching to Ada is not a viable
solution.

Having said that, I agree that most of the security problems that
plague the web-development ecosystem could be solved with a proper
type system and static type-safety.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Q: type ... is new String

[Georg Bauhaus]

On 04.06.12 15:36, Maciej Sobczak wrote:

> I agree that most of the security problems that
> plague the web-development ecosystem could be solved with a proper
> type system and static type-safety.

To illustrate a problem, web programming is almost always confronting
I/O of untyped "text": of implicit, ambiguous, indeterminable,
inconsistent, wrong encoding. There is no perfect way to prevent
exception raising effects, remember that most systems are layered,
and disconnected. Basic AI is needed to make educated guesses about
to the meaning of octet sequences.

Any complaint about malformed output at the other end is likely
justified, but useless: "We *must* have the data. Do your best!"

The best one can do is classify I/O, then read input from sources
marked safe/unsafe, and finally use these data in typed structures.

Any countermeasure must be one of the masses: how can one make the
notion of type checking of web data so popular that it is considered
a must-have?

Re: Q: type ... is new String

[Dmitry A. Kazakov]

On Mon, 04 Jun 2012 16:58:38 +0200, Georg Bauhaus wrote:

> On 04.06.12 15:36, Maciej Sobczak wrote:
> 
>> I agree that most of the security problems that
>> plague the web-development ecosystem could be solved with a proper
>> type system and static type-safety.
> 
> To illustrate a problem, web programming is almost always confronting
> I/O of untyped "text": of implicit, ambiguous, indeterminable,
> inconsistent, wrong encoding. There is no perfect way to prevent
> exception raising effects, remember that most systems are layered,
> and disconnected. Basic AI is needed to make educated guesses about
> to the meaning of octet sequences.
> 
> Any complaint about malformed output at the other end is likely
> justified, but useless: "We *must* have the data. Do your best!"

malformed /= untyped.

Typing is about a way to describe behavior. Anything you can do in an
untyped way you can do typed and conversely, since both is Turing complete.
Malformed, but legal input must be parsed and mapped onto a set of properly
typed objects. Where is a problem?

Miserable state of internet standards is not directly related to the
pitiful methods of programming usual to internet applications. Though both
may be consequences of same attitude to software design.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Q: type ... is new String

[Georg Bauhaus]

On 04.06.12 17:14, Dmitry A. Kazakov wrote:

> malformed /= untyped.
> 
> Typing is about a way to describe behavior.

Well, yes, though in the web word, "type" may de facto mean "element type"
at best. The problem with strings is not that one could speak
about operations PUT, GET, DELETE, HEAD, and so on, and consider
these the behavior of something. The problem is data that cannot
reliably parsed and mapped to a set of properly typed objects. But
we still must have that information!

Everything in practice is implicit, ambiguous, indeterminable,
inconsistent. This may be a consequence of the attitude in the web,
which does not normally use "type" at all. Not at the level of
system integration, where it matters. The AI job, then, is to look
at the forms and try to make sense, even when things are malformed.
REJECT is not an option.

> Miserable state of internet standards is not directly related to the
> pitiful methods of programming usual to internet applications. Though both
> may be consequences of same attitude to software design.

Re: Q: type ... is new String

[Dmitry A. Kazakov]

On Mon, 04 Jun 2012 18:06:36 +0200, Georg Bauhaus wrote:

> On 04.06.12 17:14, Dmitry A. Kazakov wrote:
> 
>> malformed /= untyped.
>> 
>> Typing is about a way to describe behavior.
> 
> Well, yes, though in the web word, "type" may de facto mean "element type"
> at best. The problem with strings is not that one could speak
> about operations PUT, GET, DELETE, HEAD, and so on, and consider
> these the behavior of something. The problem is data that cannot
> reliably parsed and mapped to a set of properly typed objects. But
> we still must have that information!

You are mangling OSI layers. String in this case is merely a transport, or
a container. Operations defined on the container type are not the
operations of the things it may contain, nor the operations of the things
the contained things may describe. The string may contain an Ada program
and operations on the Ada source object could be something like ASIS, but
that should have no effect on the implementation of String.

> Everything in practice is implicit, ambiguous, indeterminable,
> inconsistent.

Wrong. In practice there are abstraction layers each of which is
well-defined, except for the last one presented to the reader. There is
nothing ambiguous in character encoding, network frames, states of gates.
For a CPU, network adapter, graphic card etc to work, there is no need to
know anything about the incomputable semantics of the web page rendered
before the user. Similarly the parser of the page content containing "to be
or not to be?" need not to answer such questions. For each possible input
there is a defined output the parser should spill. Where is a problem?

> This may be a consequence of the attitude in the web,
> which does not normally use "type" at all. Not at the level of
> system integration, where it matters. The AI job, then, is to look
> at the forms and try to make sense, even when things are malformed.
> REJECT is not an option.

Yes, this is a consequence of a misconception. Note that *exactly* same
misconception is behind dynamic preconditions of Eiffel now unfortunately
introduced in Ada 2012. There is NO reject. There cannot be any reject. You
have to handle every possible input state. You have no option to put a
precondition on anybody except for very rare cases of which you can safely
forget. That does not work in REAL world. Have courage to face it!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Q: type ... is new String

[Yannick Duchêne (Hibou57)]

Le Mon, 04 Jun 2012 19:05:18 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>> This may be a consequence of the attitude in the web,
>> which does not normally use "type" at all. Not at the level of
>> system integration, where it matters. The AI job, then, is to look
>> at the forms and try to make sense, even when things are malformed.
>> REJECT is not an option.
>
> Yes, this is a consequence of a misconception.

At least HTML5 addresses this, as it specifies malformed input handling.

> Note that *exactly* same
> misconception is behind dynamic preconditions of Eiffel now unfortunately
> introduced in Ada 2012.

There's nothing wrong with it, and it does not betray Ada's spirit, as it  
helps to catch errors as much soon as possible. When an error is not (or  
cannot be) caught at compile time, that's still better to catch it the  
sooner at runtime, rather than after a long chain of consequences which  
hides the error origination. That's what dynamic check of contracts is  
for. After all, we have runtime range‑check, since Ada's birth, which is  
similar.

I don't understand your frequent griefs against runtime check of  
contracts. Anyway, this does not prevent anyone to statically prove a  
program with SPARK (or may be Coq) if one is able to. If you can't, you  
just still have the option of runtime checking contracts, which is better  
than nothing.

-- 
“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

Re: Q: type ... is new String

[Georg Bauhaus]

On 04.06.12 19:05, Dmitry A. Kazakov wrote:
> On Mon, 04 Jun 2012 18:06:36 +0200, Georg Bauhaus wrote:
>
>> On 04.06.12 17:14, Dmitry A. Kazakov wrote:
>>
>>> malformed /= untyped.
>>>
>>> Typing is about a way to describe behavior.
>>
>> Well, yes, though in the web word, "type" may de facto mean "element type"
>> at best. The problem with strings is not that one could speak
>> about operations PUT, GET, DELETE, HEAD, and so on, and consider
>> these the behavior of something. The problem is data that cannot
>> reliably parsed and mapped to a set of properly typed objects. But
>> we still must have that information!
>
> You are mangling OSI layers.

Yes, deliberately changing layers for illustration of the layers that
may yield a type.  At my layer, every attempt at mapping
the contents of a "string" to objects of a type is doomed to failure
in case it should be general. This doesn't work without creating
a slew of types that is as vague as its input. Sometimes input is
undecidable without human intervention, so Turing completeness does
not really help. Types would have to be ever changing, and complex,
and flexible, and be developed in O(∞) of program writing time,
all since they must adapt to changing input.

> There is nothing ambiguous in character encoding,

In processing data from any source that speaks HTTP, you don't really know
the character encoding: you may be told the encoding is X but actually it
is Y. Or, you get a mix of characters encoded as X here and Y there
in the same document. Sometimes human intervention can help finding
a correct interpretation, sometimes it can't. The problem is conceptually
similar to that of determination of a calendar date, given 5/6/7 of
a document written in English, issued by a French organization, written
by a Swiss employee, processed by the usual software.


> For each possible input
> there is a defined output the parser should spill. Where is a problem?

Here is the problem: There is no complete description of the set of
possible inputs.


It's the web. Changing. Data are not quite as lucid as a set of ways
to designate a file. Is the latter set changing so frequently that the
Ada standard would not be able to follow?

Re: Q: type ... is new String

[Dmitry A. Kazakov]

On Mon, 04 Jun 2012 22:56:01 +0200, Georg Bauhaus wrote:

> On 04.06.12 19:05, Dmitry A. Kazakov wrote:

>> There is nothing ambiguous in character encoding,
> 
> In processing data from any source that speaks HTTP, you don't really know
> the character encoding: you may be told the encoding is X but actually it
> is Y.

<=> I do know the encoding.

You are trying to pursue some absolute truth, e.g. "true encoding" of a
broken page, which simply does not exist and is irrelevant. You should
define an encoding and that is all the corresponding component need to know
about it.

Note again a connection to error checks: the program shall not check
itself. A consequence of this: if you use an input it is not your
responsibility to make guesses. You do as you told. If you want to add some
encoding guessing layer, do it just elsewhere. Just basics of good software
design where each component shall have a well defined narrow functionality.

>> For each possible input
>> there is a defined output the parser should spill. Where is a problem?
> 
> Here is the problem: There is no complete description of the set of
> possible inputs.

See, that is the problem. People didn't do their job.

> It's the web. Changing. Data are not quite as lucid as a set of ways
> to designate a file. Is the latter set changing so frequently that the
> Ada standard would not be able to follow?

Nope, things changing are as irrelevant as the computer's relative position
to Proxima Centauri.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Q: type ... is new String

[Georg Bauhaus]

On 05.06.12 09:32, Dmitry A. Kazakov wrote:
> On Mon, 04 Jun 2012 22:56:01 +0200, Georg Bauhaus wrote:
>
>> On 04.06.12 19:05, Dmitry A. Kazakov wrote:
>
>>> There is nothing ambiguous in character encoding,
>>
>> In processing data from any source that speaks HTTP, you don't really know
>> the character encoding: you may be told the encoding is X but actually it
>> is Y.
>
> <=>  I do know the encoding.

You snipped the part that explained how this "knowledge" isn't
knowledge. It is in a state of flux and occasionally crystallizes
to yield Heisentypes. ;-)

(All I see is subsequences of 2#bbbb_bbbb#. For the AI part,
I am told to produce the most likely information that the
originator might have intended to send.)


> You are trying to pursue some absolute truth, e.g. "true encoding" of a
> broken page, which simply does not exist and is irrelevant.

I am the one to create the truth, the valuable information. Like I am
the one to guess the correct interpretation of calendar date 5/6/7.

> Note again a connection to error checks: the program shall not check
> itself. A consequence of this: if you use an input it is not your
> responsibility to make guesses.

Yes, it is, making guesses is precisely what I'm told to do.

> If you want to add some encoding guessing layer, do it just elsewhere.

Too late. Too many additional decisions that create a large set
of types in layers that isn't lightweight enough to handle
within the constraints of the job. And the process of type
creation will need backtracking triggered by unexpected events.

>>> For each possible input
>>> there is a defined output the parser should spill. Where is a problem?
>>
>> Here is the problem: There is no complete description of the set of
>> possible inputs.
>
> See, that is the problem. People didn't do their job.

No, they did their job. What they did might not be like
what I wish they had done. But a doctor cannot sit back
and accuse the patients of having ruined their own health.
*That* is irrelevant.


> Nope, things changing are as irrelevant as the computer's relative position
> to Proxima Centauri.

So what is the outline of a type that describes a file naming
scheme that has changed?

Re: Q: type ... is new String

[Dmitry A. Kazakov]

On Tue, 05 Jun 2012 10:40:36 +0200, Georg Bauhaus wrote:

> On 05.06.12 09:32, Dmitry A. Kazakov wrote:
>> On Mon, 04 Jun 2012 22:56:01 +0200, Georg Bauhaus wrote:
>>
>>> On 04.06.12 19:05, Dmitry A. Kazakov wrote:
>>
>>>> There is nothing ambiguous in character encoding,
>>>
>>> In processing data from any source that speaks HTTP, you don't really know
>>> the character encoding: you may be told the encoding is X but actually it
>>> is Y.
>>
>> <=>  I do know the encoding.
> 
> You snipped the part that explained how this "knowledge" isn't
> knowledge. It is in a state of flux and occasionally crystallizes
> to yield Heisentypes. ;-)
> 
> (All I see is subsequences of 2#bbbb_bbbb#. For the AI part,
> I am told to produce the most likely information that the
> originator might have intended to send.)

Bad design. Don't do that.

>> You are trying to pursue some absolute truth, e.g. "true encoding" of a
>> broken page, which simply does not exist and is irrelevant.
> 
> I am the one to create the truth, the valuable information. Like I am
> the one to guess the correct interpretation of calendar date 5/6/7.

Maybe, but that imposes no problem on software design. The mail program
successfully transmitted "5/6/7" without making guesses. Do not conflate
well-defined functionality, e.g. "send over socket", "render calendar page
on the screen" with ill-defined stuff, like what is going on in someone's
head.

>> If you want to add some encoding guessing layer, do it just elsewhere.
> 
> Too late.

For broken design it is always too late. Fix the design.

>>>> For each possible input
>>>> there is a defined output the parser should spill. Where is a problem?
>>>
>>> Here is the problem: There is no complete description of the set of
>>> possible inputs.
>>
>> See, that is the problem. People didn't do their job.
> 
> No, they did their job.

How an incomplete definition is job done?

Now feel free to tell me that working without specifications, is the right
way to develop software...

>> Nope, things changing are as irrelevant as the computer's relative position
>> to Proxima Centauri.
> 
> So what is the outline of a type that describes a file naming
> scheme that has changed?

Why should I care about description of naming schemes? I need a set of
types describing file name valid in some specified environment. It is not
rocket science. Before you start confusing things again, this has nothing
to do with parsing file names.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Q: type ... is new String

[Georg Bauhaus]

On 05.06.12 11:06, Dmitry A. Kazakov wrote:

>> (All I see is subsequences of 2#bbbb_bbbb#. For the AI part,
>> I am told to produce the most likely information that the
>> originator might have intended to send.)
> 
> Bad design. Don't do that.

How is producing the most likely information from a piece
of data bad design? And who am I to say "I don't do that"?


> Do not conflate
> well-defined functionality, e.g. "send over socket", "render calendar page
> on the screen" with ill-defined stuff, like what is going on in someone's
> head.

What is going on in someone's head is precisely the information
I am looking for. It so happens that this includes resource
identifiers, and here, too, I need to guess the right one, because
the transport layer conveys mistakes, omissions, and
quadruped-on-the-keyboard-effects correctly.

And, again, I must rely on guesses in order to construct objects
from input, and will reconstruct them again, and again.

Is this about a trivially correct ADT again, to be fleshed out?

I can make a sufficiently simple type for URIs, signifying nothing,
and I can map any of those resource identifiers to objects of the type.
I do not even need a behavioral description of the type; it is
exactly that of strings (including a hashing function in the
language used).
So all the separate type does is that it forms a subset of strings.
Good.

That seems pretty close to Spolsky's safe/unsafe naming convention,
but better, if refactoring is needed, because a type is better
than an Emacs macro (to which he is referring somewhere).

> For broken design it is always too late. Fix the design.

The design as a whole is not in our hands, I should think. The design
is as is, dictated by a combination of current input and time available.

> How an incomplete definition is job done?

If
- foreign company's management says "Job done!" and
- foreign company works profitably,
= then an incomplete definition means job done.

The resulting "designed system" is not ideal, from my technical
point of view. But they need not care.


> Why should I care about description of naming schemes? I need a set of
> types describing file name valid in some specified environment.

Whenever there is a sufficient specification of an environment, fine.

Just saying that web documents are an example of when a specification
might be insufficient, if it exists at all.

Re: Q: type ... is new String

[Dmitry A. Kazakov]

On Tue, 05 Jun 2012 14:20:14 +0200, Georg Bauhaus wrote:

> On 05.06.12 11:06, Dmitry A. Kazakov wrote:
> 
>>> (All I see is subsequences of 2#bbbb_bbbb#. For the AI part,
>>> I am told to produce the most likely information that the
>>> originator might have intended to send.)
>> 
>> Bad design. Don't do that.
> 
> How is producing the most likely information from a piece
> of data bad design?

Good design is not based on likelihood... and information is not
"produced."

> And who am I to say "I don't do that"?

And who are you to say "I do that"?

You, as a programmer, are someone to make decisions. You cannot refrain
from choosing.

>> Do not conflate
>> well-defined functionality, e.g. "send over socket", "render calendar page
>> on the screen" with ill-defined stuff, like what is going on in someone's
>> head.
> 
> What is going on in someone's head is precisely the information
> I am looking for. It so happens that this includes resource
> identifiers, and here, too, I need to guess the right one, because
> the transport layer conveys mistakes, omissions, and
> quadruped-on-the-keyboard-effects correctly.

Really? When last time you saw web page errors caused by the transport?

> And, again, I must rely on guesses in order to construct objects
> from input, and will reconstruct them again, and again.

No, you must not and shall not. This attitude is the core problem: guesses
that buffer does not overflow etc. I see this as the problem. Not buffer
overflows, but guesses that it would not!

> I can make a sufficiently simple type for URIs, signifying nothing,

Programming is about locally trivial things...

>> For broken design it is always too late. Fix the design.
> 
> The design as a whole is not in our hands, I should think. The design
> is as is, dictated by a combination of current input and time available.

Usual excuses...

>> How an incomplete definition is job done?
> 
> If
> - foreign company's management says "Job done!" and
> - foreign company works profitably,
> = then an incomplete definition means job done.

No, it does not mean that. Business job might be done, the job of putting
down specifications is not. You could also argue that the programming job
is done because there is no man-power available, somebody stolen the
computers or a meteorite extinguished all life on the earth. It is not
done, is a commentary why it was not.

Anyway, do I understand correctly that you changed your point from lack of
AI to blame, to laziness and ill will of some evil foreigners? (:-))

>> Why should I care about description of naming schemes? I need a set of
>> types describing file name valid in some specified environment.
> 
> Whenever there is a sufficient specification of an environment, fine.
> 
> Just saying that web documents are an example of when a specification
> might be insufficient, if it exists at all.

Specification [in]sufficient for what?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Q: type ... is new String

[Shark8]

On Tuesday, June 5, 2012 7:20:14 AM UTC-5, Georg Bauhaus wrote:
> On 05.06.12 11:06, Dmitry A. Kazakov wrote:
> 
> >> (All I see is subsequences of 2#bbbb_bbbb#. For the AI part,
> >> I am told to produce the most likely information that the
> >> originator might have intended to send.)
> > 
> > Bad design. Don't do that.
> 
> How is producing the most likely information from a piece
> of data bad design? And who am I to say "I don't do that"?

PHP gives a good answer [by illustrating the wrong way to do it].

"*PHP is built to keep chugging along at all costs. __When faced with either doing something nonsensical or aborting with an error, it will do something nonsensical.__ Anything is better than nothing.
*Weak typing (i.e., silent automatic conversion between strings/numbers/et al) is so complex that __whatever minor programmer effort is saved is by no means worth it__."
From: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

"And if you are in the business of creating or using magic then make it very clear what it expects where and when and why and where. Be as upfront as you possibly can and give proper warnings when something goes awry."
From: http://www.pelshoff.com/2012/04/in-favour-of-typing

What you're asking with the "producing the most likely information" question is exactly summed up in the emphasized portions of the first quote. The second quote {being more about the internal codebase, but still applicable} could easily be rephrased "give a warning about behavior based on questionable assumptions".

Re: Q: type ... is new String

[Georg Bauhaus]

On 06.06.12 06:09, Shark8 wrote:
> On Tuesday, June 5, 2012 7:20:14 AM UTC-5, Georg Bauhaus wrote:
>> On 05.06.12 11:06, Dmitry A. Kazakov wrote:
>>
>>>> (All I see is subsequences of 2#bbbb_bbbb#. For the AI part,
>>>> I am told to produce the most likely information that the
>>>> originator might have intended to send.)
>>>
>>> Bad design. Don't do that.
>>
>> How is producing the most likely information from a piece
>> of data bad design? And who am I to say "I don't do that"?
>
> PHP gives a good answer [by illustrating the wrong way to do it].

So then, what is the right way to do it, taking us back to the
original question? Given that sometimes the ivory tower has
poky offices; given scarce resources, lack of coffee included;
given specifications that have incomplete definitions, are
contradictory, but do exist like gravity, can we still hope for
a set of types that

- can be developed within finite time
- cover all that is needed, now and in the near future
- are computationally efficient
- don't cram a lot into exceptions
- can be changed within finite time (backwards compatibly)

If we can, and if it isn't rocket science, that is, if it
is relatively easy to do, where is the proof of concept?

Or is it more promising to ask programmers to sort things
out so that the usual String based I/O parameter naming
scheme stays?

   type Locally_Abstract_Name is tagged private;
   ...
   -- add any operations the project likes, e.g. "+"

   type Platform is tagged private;

   function Transform
     (Target   : Platform;
      Filename : Locally_Abstract_Name'Class)
   return String;

Re: Q: type ... is new String

[Randy Brukardt]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:4fcdf97f$0$9521$9b4e6d93@newsspool1.arcor-online.net...
> On 05.06.12 11:06, Dmitry A. Kazakov wrote:
>
>>> (All I see is subsequences of 2#bbbb_bbbb#. For the AI part,
>>> I am told to produce the most likely information that the
>>> originator might have intended to send.)
>>
>> Bad design. Don't do that.
>
> How is producing the most likely information from a piece
> of data bad design? And who am I to say "I don't do that"?

It's bad design. Malformed input should always be rejected, period. Any 
other situation leads to zillions of security holes. And if you're not 
willing to say "don't do that", let me do so for you. :-)

I'm well aware that pragmatic requirements might force you into a bad design 
(as I had to in order to not block my own mail because of malformed Outlook 
messages). But that doesn't magically make the design good, it's still 
garbage.

                                Randy. 

Re: Q: type ... is new String

[Georg Bauhaus]

On 07.06.12 01:56, Randy Brukardt wrote:
> "Georg Bauhaus"<rm.dash-bauhaus@futureapps.de>  wrote in message
> news:4fcdf97f$0$9521$9b4e6d93@newsspool1.arcor-online.net...
>> On 05.06.12 11:06, Dmitry A. Kazakov wrote:
>>
>>>> (All I see is subsequences of 2#bbbb_bbbb#. For the AI part,
>>>> I am told to produce the most likely information that the
>>>> originator might have intended to send.)
>>>
>>> Bad design. Don't do that.
>>
>> How is producing the most likely information from a piece
>> of data bad design? And who am I to say "I don't do that"?
>
> It's bad design. Malformed input should always be rejected, period. Any
> other situation leads to zillions of security holes. And if you're not
> willing to say "don't do that", let me do so for you. :-)

Thanks. However, technical considerations are only one of the inputs
to the utility function that maps from the multidimensional space of
business factors into money. If to reject means values further away
from its maximum, I can't reject. A better internet is not the
immediate business model, as usual. Nor would the garbage care
if one of its copies was rejected by our programs. ;-)

In my case, the programs have to operate like a very small Google:
They shall find interesting information in all the garbage precisely
because combinations of bits of information in there may turn out to be
worth the effort (i.e., the money). Pragmatic requirements, yes,
and they influence the "design". So strings it is, for the most part.

Re: Q: type ... is new String

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1tr1nuc1xy9mp$.d5s1fz9vuczz.dlg@40tude.net...
> On Mon, 04 Jun 2012 22:56:01 +0200, Georg Bauhaus wrote:
>
>> On 04.06.12 19:05, Dmitry A. Kazakov wrote:
>
>>> There is nothing ambiguous in character encoding,
>>
>> In processing data from any source that speaks HTTP, you don't really 
>> know
>> the character encoding: you may be told the encoding is X but actually it
>> is Y.
>
> <=> I do know the encoding.
>
> You are trying to pursue some absolute truth, e.g. "true encoding" of a
> broken page, which simply does not exist and is irrelevant. You should
> define an encoding and that is all the corresponding component need to 
> know
> about it.

I agree with Dmitry here. It is idiotic for web tools to do anything with 
malformed input (pages, whatever) other than to reject them. If they did 
that, we'd have far fewer ways to attack web programs (like browsers), and 
far fewer malformed inputs as well (because hardly anyone would want to 
write pages that couldn't be rendered -- they'd fix them in a hurry).

The sloppiness in handling input is the bane of the Internet; software that 
doesn't do that is garbage. Unfortuately, garbage is all we have (thus the 
popularity of apps).

Note that for my spam filter, I block or quarantine almost everything 
malformed. I had to allow some holes in that, because some very common tools 
and sites send out only malformed mail; which is aggrevating and allows ways 
for spammers and other criminals to make successful attacks. Grumble.

                                       Randy.

Re: Q: type ... is new String

[Yannick Duchêne (Hibou57)]

Le Mon, 04 Jun 2012 17:14:49 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> Miserable state of internet standards

JavaScript is not representative of Internet standards ;-) . There are not  
all so miserable as JavaScript is.


-- 
“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

Re: Q: type ... is new String

[Georg Bauhaus]

On 04.06.12 22:33, Yannick Duchêne (Hibou57) wrote:
> Le Mon, 04 Jun 2012 17:14:49 +0200, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> a écrit:
>> Miserable state of internet standards
>
> JavaScript is not representative of Internet standards ;-) . There are not all so miserable as JavaScript is.

The internet is largely operated without following standards.

__
When there was a chance to introduce well structured data
to the WWW at large (early 1990s), the effort was spoiled by
preferring <font> and permissive parsers, thus destroying
the idea that a little structuring work prior to publication
is good.

Re: Q: type ... is new String

[Georg Bauhaus]

On 05.06.12 02:25, Dennis Lee Bieber wrote:
> On Mon, 04 Jun 2012 23:27:30 +0200, Georg Bauhaus
> <rm.dash-bauhaus@futureapps.de>  declaimed the following in
> comp.lang.ada:
>
>>
>> The internet is largely operated without following standards.
>>
> 	I would consider that the "web" tends to operate without following
> standards...

Yes, I meant services offered via internet (WWW, Twitter, ..., or less
public ones), not the internet, thanks for the correction. I shall
think about a way of maintaining conceptual integrity in the face of
everyone speaking about "the internet".

Re: Q: type ... is new String

[Yannick Duchêne (Hibou57)]

Le Tue, 05 Jun 2012 08:15:04 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:

> On 05.06.12 02:25, Dennis Lee Bieber wrote:
>> On Mon, 04 Jun 2012 23:27:30 +0200, Georg Bauhaus
>> <rm.dash-bauhaus@futureapps.de>  declaimed the following in
>> comp.lang.ada:
>>
>>>
>>> The internet is largely operated without following standards.
>>>
>> 	I would consider that the "web" tends to operate without following
>> standards...
>
> Yes, I meant services offered via internet (WWW, Twitter, ..., or less
> public ones), not the internet, thanks for the correction. I shall
> think about a way of maintaining conceptual integrity in the face of
> everyone speaking about "the internet".

OK! Now I can agree with you.

-- 
“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

Re: Q: type ... is new String

[Shark8]

On Monday, June 4, 2012 7:25:41 PM UTC-5, Dennis Lee Bieber wrote:
> 
> 	But stuffing HTML into email, and ActiveX into web pages, along with
> perverting HTML into a /layout/ language rather than just a structurally
> mark-up -- yes; that is no following standards.

Indeed, in my experience much of web-development difficulty is precisely due to people trying to use HTML as a layout-language instead of a structural [mark-up] language. I sometimes wonder what would have happened if PostScript/PDF had been used to address the layout-craze instead.

Re: Q: type ... is new String

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:4fcd283e$0$9502$9b4e6d93@newsspool1.arcor-online.net...
> On 04.06.12 22:33, Yannick Duch�ne (Hibou57) wrote:
>> Le Mon, 04 Jun 2012 17:14:49 +0200, Dmitry A. Kazakov 
>> <mailbox@dmitry-kazakov.de> a �crit:
>>> Miserable state of internet standards
>>
>> JavaScript is not representative of Internet standards ;-) . There are 
>> not all so miserable as JavaScript is.
>
> The internet is largely operated without following standards.

Which is why the Internet is a warren of attacks and vulrabilities. If at 
all possible, reject malformed stuff, and there will be less of it over 
time. (Things would be so much better if Google's crawler rejected many 
sorts of malformed pages, because SEO effects alone would eliminate those 
sorts of pages from most sites.)

                                         Randy.

Re: Q: type ... is new String

[Adam Beneschan]

On Wednesday, June 6, 2012 5:01:44 PM UTC-7, Randy Brukardt wrote:
> "Georg Bauhaus"  wrote in message 
> news:4fcd283e$0$9502$9b4e6d93 at newsspool1.arcor-online.net...
> > On 04.06.12 22:33, Yannick Duchêne (Hibou57) wrote:
> >> Le Mon, 04 Jun 2012 17:14:49 +0200, Dmitry A. Kazakov 
> >> a écrit:
> >>> Miserable state of internet standards
> >>
> >> JavaScript is not representative of Internet standards ;-) . There are 
> >> not all so miserable as JavaScript is.
> >
> > The internet is largely operated without following standards.
> 
> Which is why the Internet is a warren of attacks and vulrabilities.

Well, that's one reason.  But it's not the only reason.  Some of the standards themselves weren't appropriate for an Internet accessible to the general public.  In particular, SMTP was designed for a research community where people could mostly trust each other, and then it was used without modification when "the Internet" came into being, making it easy for criminals to send unverifiable e-mail with spam and viruses and not get tracked down.  At least that's how I see it.  If it could be done over again, I'd hope the gurus would replace SMTP with something more secure before the whole system was unleashed on the public.  I think that's the biggest single thing that should have been done.

But... sigh... hindsight is 20/20.  So maybe we should hope that by 2020 we can start doing all the things that should have been done earlier...  <grin>

                        -- Adam

Re: Q: type ... is new String

[Brian Drummond]

On Mon, 04 Jun 2012 06:36:31 -0700, Maciej Sobczak wrote:

> On 4 Cze, 13:39, Brian Drummond <br...@shapes.demon.co.uk> wrote:
> 
>> Now it seems to me that he would be better off saying "type
>> UnsafeString is new String;"
>> and bypassing the rest of that (rather long) article entirely.
> 
> Except that it would not work in the language that he used for
> presentation (which is VBScript, I guess).

"pseudocode" he called it, having started the article using C. And in 
pseudocode, anything the author wants will work...

>> Or am I missing something in that article?
> 
> Yes, this:
> 
> "Let’s pretend that you’re building some kind of a web-based application
> [...]"
> 
> The author describes a problem in a well-defined domain (web-based apps
> written in some dynamically-typed language similar in nature to
> VBScript) and presents a possible solution. Given the constraints, the
> solution he proposed is probably the best he could do.

Joel Spolsky did indeed define it as a web-based application, though the 
nature of the language is not discussed. Since there are some tools like 
AWS for building Web apps using Ada, I believe the _stated_ constraints 
don't prohibit strong typing. (I can't rule out unstated constraints 
along the lines you suggest)

Dynamic typing and scripting do not necessarily imply weak typing, though 
they are usually used that way. There is even an Ada-based scripting 
language as one counterexample.

> Like it or not, for many people switching to Ada is not a viable
> solution.

While I have to agree with that, I suspect that for many more, it might 
be viable, but is automatically dismissed without consideration; this 
article being just one example. 

The article works AGAINST reliable software by dismissing not just Ada, 
but strong typing in general. The fact that it does so by omission rather 
than by discussion and disagreement helps foster ignorance; at least if 
it said "the Ada approach is stupid because ... (see ref #) " at least it 
would raise awareness and let the reader think, read further, and agree 
or disagree as she saw fit.

Or the article could add "a strongly typed language would allow a better 
solution using ... but this is all you get in C (VBScript, whatever), 
so ..."

I do not know whether the author is to blame, or if he is genuinely 
unaware of the power of a good type system. My point in this post is 
simply that if people are unaware of a good thing, then there will be no 
demand for it.

> Having said that, I agree that most of the security problems that plague
> the web-development ecosystem could be solved with a proper type system
> and static type-safety.

Or at least some type safety. Even in a well designed dynamic language, 
type safety is possible. In the context of the example, let all the input 
methods return UnsafeString (i.e. the base String class has no input 
methods), the encode methods return String, then you simply (explicitly) 
make the write methods reject UnsafeString. 

It is of course possible that not all dynamic languages are well-designed.

- Brian

Re: Q: type ... is new String

[Yannick Duchêne (Hibou57)]

Le Tue, 05 Jun 2012 14:05:10 +0200, Brian Drummond  
<brian@shapes.demon.co.uk> a écrit:
> Dynamic typing and scripting do not necessarily imply weak typing, though
> they are usually used that way. There is even an Ada-based scripting
> language as one counterexample.

You must be talking about BUSH (all uppercase):

* http://www.pegasoft.ca/bush.html
* http://www.pegasoft.ca/docs/bushintro.html

(link posted for readers who don't already know it).

-- 
“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

Re: Q: type ... is new String

[Shark8]

On Monday, June 4, 2012 6:39:56 AM UTC-5, Brian Drummond wrote:
> Now, we can debate the relative merits of "is new String" versus "is new 
> Array <> of Character" but how do we get the message out there that 
> recognized industry experts (and I'm not quoting "expert" because I 
> believe he is, in his field) are recommending "Real Solutions" that 
> impose weeks of painful and unnecessary work on unsuspecting programmers 
> for ... what purpose? what gain?


Well, if we assume that programmers have an inherent zero-sum masochistic sense then this makes perfect sense. A programmer will then choose the language which "hurts" in the ways most acceptable to him: B&D language vs. B&D lifestyle.

We of the former must obviously have low tolerance for pain-duration (we want the compiler to catch the most errors and berate us at compile-time) whereas the others enjoy long drawn-out pains (especially when some intermittent error somewhere absolutely needs fixed and you have to spend days debugging the program to find out what's going on).

I think more people are attracted to the latter because "debugging isn't fun", "isn't fun" -> "work" therefore debugging is work. (And thus the more debugging they do the more sense of accomplishment for their work they feel.)

Re: Q: type ... is new String

[Jeffrey Carter]

On 06/04/2012 08:54 AM, Shark8 wrote:
>
> I think more people are attracted to the latter because "debugging isn't
> fun", "isn't fun" ->  "work" therefore debugging is work. (And thus the more
> debugging they do the more sense of accomplishment for their work they
> feel.)

I agree. When you've spend hours/days/weeks fighting the language to get 
something that [sort of] does [most of] what you want, you get a sense of 
accomplishment. It was hard, so clearly you've achieved something significant. 
If you fix a couple of compiler errors and it works, it must not have been very 
difficult.

-- 
Jeff Carter
"Hold your temper. Count ten.... Now let 'er go.
You got a good aim."
Never Give a Sucker an Even Break
105

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: Q: type ... is new String

[Brian Drummond]

On Mon, 04 Jun 2012 15:01:06 -0700, Jeffrey Carter wrote:

> On 06/04/2012 08:54 AM, Shark8 wrote:
>>
>> I think more people are attracted to the latter because "debugging
>> isn't fun", "isn't fun" ->  "work" therefore debugging is work. (And
>> thus the more debugging they do the more sense of accomplishment for
>> their work they feel.)
> 
> I agree. When you've spend hours/days/weeks fighting the language to get
> something that [sort of] does [most of] what you want, you get a sense
> of accomplishment. It was hard, so clearly you've achieved something
> significant. If you fix a couple of compiler errors and it works, it
> must not have been very difficult.

Ah, that must be it!

- Brian