[erlang-questions] erlang-questions Digest, Vol 24, Issue 15

[John Haugeland]

>
> Even getting colors is something that is totally dependant on what kind of
> terminal (yes, *terminal*) you have.


Yes, that's exactly what I said.  That's why doing it in the language is the
superior strategy - it allows you to have per-console (no, not terminal)
output.

Why is it a console?  Because they're not all interactive.  Terminals are
two-way.  Consoles aren't, necessarily.






> Using a window on a windowing system (such as Microsoft Windows or
> X-windows, or whatever) means that you have a terminal program running,
> which do the actual visualization.


Yes.  And they don't all use windows.  Windows erl.exe, for example, uses
the DOS console.  That isn't the same as using a window - windows erl.exe
will work in Windows 7's pure console mode, for example.

The germane observation is that the language does not make any guarantees
about the user interface, and that as such anything which is meant to be
portable must be done in common ground.







> *Erlang is in no way involved with this.*
>

What?  Erlang is the only common factor in a group of undefined user
interfaces.  To suggest that erlang isn't involved in its own input/output
is silly.





However, almost all terminal programs have some way of controlling them, and
> thus cause visual effects.


Not all of them.  And each are different.  Even so, you seem to be making my
point for me.






> The exact way you get the terminal program to present the visual effects
> you want is possibly unique for that terminal program. And it is still
> totally outside of Erlang.


Uh huh.  Which is precisely why any formatting must be done in Erlang, to
ensure that nobody attempts to ape a set of visual effects specific to one
platform.






> All that being said, there is an ANSI standard, which many terminal
> programs implement,


Neither the modern Windows console nor the default Linux BASH environment
honor ANSI codes.  The VT standard, which is not the same as ANSI codes,
would be a marginally better choice, but the reason that's actually a bad
choice was already discussed.






> which means that if your terminal program follows this standard,


What terminal program do you believe is involved for Windows users?  Answers
which aren't suitable outside Unix aren't suitable period.






> the way to get the wanted effects are well known, and can probably be
> answered by a whole bunch of people reading this list.


Yes.  Including me.  But it's a bad strategy, so nobody will.  There's a
reason HIPE tools don't get used much in production code.  Things that are
tied to one platform are fundamentally broken.





But even so, we don't even know what kind of terminal the original posted is
> using, so we can't even make a proper answer based on that standard, because
> it might very well not be something that will work for him.


Yes, that's exactly what I said.






> Sorry, but you uninformed reply really pissed me off.


So much that you agreed with it, it seems.  You haven't actually said
anything that disagrees with me.






> Uninformed people are not a problem. We all have to learn somehow, someway,
> at some point.


Yes.  We all do.






> But making totally bogus claims


Such as?





> and trying to shoot down someone who gives a correct answer is just plain
> wrong.


I haven't shot down someone who gives a correct answer.  I've shot down
someone who gave a unix-specific answer when there are better available
approaches which are well known to people who are willing to do the small
amount of extra work it takes to keep a portable language portable.

I haven't actually seen you point out anything I said which was wrong.  All
you seem to want to do is repeat the things I said, come to the conclusion I
came to when saying "here's what you would do if you were willing to limit
yourself to Unix", then get all nasty in public.







> *First* you learn the topic, *then* you answer. Not the other way around.


Yeah.





> And for some totally unkown reason (to me), you think that it is Erlang
> that should have the answer. Geez.


Probably because of the things I've already explained several times: it's
the only common factor among a set of undefined terminals, and I'm not
willing to accept a naive, unix-only solution from naive, unix-only people.






> Maybe I should direct all the people on NetBSD-current here as well, when
> they pop this question.
>

That's okay: I'm on that mailing list too.  Being on an operating system
specific mailing list doesn't actually teach you much about how to handle
things in an operating-system portable fashion, as a general rule of thumb.






> And, as a friendly gnome,


You seem to be confused about the nature of the word "friendly."






> I'll provide the answer for when he really is using a terminal that is ANSI
> compliant:
>

Wow, a repetition of the answer other people already gave, including the
person you're yelling at for not giving answers. Bravo.  By the way, those
are actually VT codes, not ANSI.  ANSI requires escape bracket; CSI is only
supported by the VT terminal series.





> I could go on for quite a while about this, but maybe you should read a
> manual instead?
>

Yes, I'll get right on reading a manual about the thing I already
suggested.  Because clearly I didn't know about it, which is why I knew its
correct name when you didn't.  And the fact that I've already panned it for
important reasons, and provided a portable alternative?

Really, dude, you shouldn't get that high up on your horse.  It hurts worse
when you fall.






> And this is still totally not related to Erlang, and you'd send the same
> control sequence if your program was written in C, Perl, Haskell, Lisp,
> Prolog, Assembler, Basic, Pascal, FORTRAN, Cobol, Snobol, Algol, Dibol,
> Focal, Python, Java, or God knows what else, if your *terminal* was ANSI
> compliant.


Wow, you really don't understand the idea that requiring terminal code
scanning breaks three out of the four existing consoles, do you?

This is the Unix specific part that isn't acceptable.  Your strategy would
require people to log in over SSH or Telnet for their stuff to work
correctly.  The windows shell wouldn't work.  The Dos shell wouldn't work.
The stream Unix shell wouldn't work.

We get it: you really like the idea the rest of us already discussed before
you spoke up.  No need to get all "omg i'm so right and you need to read a
book" about it. Turns out you aren't as far out ahead as you think you are.
At least read enough of the manual you're talking about to know the name of
the coding scheme you're trying to discuss.






> If that shouldn't make it obvious to you that it is not related to the
> language, but to the terminal, then I don't know what would.
>

Yes, the scheme you have which is unacceptably tied to a unix environment
isn't about the language.  Wow.  Bravo.  By killing all but one terminal,
you've made it a terminal issue.

Any *acceptable portable solution* cannot be required to support the things
you expect to gain from a telnet/ssh connection.  That's why your solution
is unacceptable.  Any solution which requires the support of an intermediary
communications application is fundamentally broken.  You've broken anything
that doesn't work through a Unix terminal, then used that to justify calling
it a terminal problem.

But, for those of us who don't use Erlang through ssh/telnet, your solution
is not only broken, but introduces a ton of unnecessary noise into the
console which damages the language's fundamental usability.

That's why *a correct, console portable solution* cannot rely on third party
intermediary tools which aren't even usually there.

Your solution is a terminal solution, yes.  But that doesn't mean the
problem is a terminal problem, and the fact that it isn't shows more mature
engineers who know what portability is why the solution you're so bent out
of shape about isn't adequate.

The funniest part is that a portable, language level solution would probably
rely on the strategy you're discussing for the Unix interactive shell
implementation.

No solution which cuts away 75% of the existing consoles is acceptable.
Emitting VT protocol noise because you're assuming a VT connection might
maybe be there, ignorant of how it affects (and potentially damages)
existing systems, is the hallmark of poor design.

If you choose to reply, please mediate your tone.  I don't like being talked
down to by someone who doesn't understand that they're playing catch-up.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090504/f72dfbee/attachment.htm>