>    Today this might be more obsolete than it was 20 years ago, but there
> are still benefits to that. The standard is quite well-established and
> has been around forever, so almost every system in existence supports it.

It sounds a bit like Unix itself: It's not actually a very good idea, 
but everything in Creation supports it, and so it will remain around 
forever.

Actually, I found a rather interesting description of the history of 
Unix the other day. I'll have to see if I can find it again. As you read 
it, you discover that many design decisions that look stupid are in fact 
merely obsolete. They served a purpose 60 years ago, it's just that they 
aren't the best choice any more.

> Also, being text-based (and low-bandwidth) you can create or port terminal
> emulators to almost any system with a screen and a keyboard, even very
> exotic ones. For instance, it's pretty common for unix-savvy people to
> have a terminal emulator on their cellphones so that they can contact
> their computer or whatever remotely. A remote GUI would simply not do.

These days, the fashion seems to be for everything from print servers to 
network hubs to be controlled by HTML over HTTP. Which is equally 
stupid, but looks more pretty...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Actually, I found a rather interesting description of the history of 
> Unix the other day. I'll have to see if I can find it again. As you read 
> it, you discover that many design decisions that look stupid are in fact 
> merely obsolete. They served a purpose 60 years ago, it's just that they 
> aren't the best choice any more.

  That would be quite strange, given that Unix was originally developed
41 years ago.

> > Also, being text-based (and low-bandwidth) you can create or port terminal
> > emulators to almost any system with a screen and a keyboard, even very
> > exotic ones. For instance, it's pretty common for unix-savvy people to
> > have a terminal emulator on their cellphones so that they can contact
> > their computer or whatever remotely. A remote GUI would simply not do.

> These days, the fashion seems to be for everything from print servers to 
> network hubs to be controlled by HTML over HTTP. Which is equally 
> stupid, but looks more pretty...

  Well, it has the advantage that it's still relatively low-bandwidth and
usable with any web browser in any system, and you can do things with the
mouse.

  Of course the downside is that you need something that can run a web
browser.

-- 
                                                          - Warp

Post a reply to this message

Invisible escreveu:
>>> Um, *yes*. Why, do you think it doesn't have worth?
>>
>> it's far more verbose and, thus, hurts readability?
> 
> Far more verbose, and as a consequence it's almost self-explanatory what 
> it does. (Unlike a collection of symbols that have no widely-accepted 
> meaning outside of regex languages...)

symbols like $ or >>=?

yeah, every language has them and you *learn* to live with them.  or you 
just endlessly refuse to learn and whine all day long about them...

you are correct though in that the Lisp way of spelling out names is 
more self-explanatory than the Haskell abuse of perlisms.  At least for 
outsiders.  For insiders, you know by personal experience that a concise 
DSL made out of single chars is much more practical... which is why you 
can do it in Lisp with macros too!

>> then try this in your little language:
>>
>> // A phone number with or without hyphens:
>> [2-9]\d{2}-?\d{3}-?\d{4}
>>
>> It looks pretty much like a template for a phone number. I'm sure yours
>> will look like a little backwards forth script and will be much harder
>> to figure out.
> 
> I actually can't figure out what that does, so I can't implement it.

BS.

>> I also wonder if it's the postfix nature of regexes that bothers you...
> 
> No, mostly it comes down to these:
> 1. Commands have cryptic names like "*" or "+".

more than frakkin' $ or >>= ??!

you quite throw away reason completely when you try to invent reasons 
for why you dislike something, don't you?

> 2. Literal characters aren't quoted, so it's hard to tell what's literal 
> and what's a command.

there's only .*+?^$\ for commands and the rest are grouping chars ()[]{} 
and literal chars.  what's to be confused?

> (And 3. since spaces are literal characters, you can't even use spacing 
> to make the structure of the expression clearer.)

you can in perl regex extensions.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

On 11/11/2010 03:52 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> Actually, I found a rather interesting description of the history of
>> Unix the other day. I'll have to see if I can find it again. As you read
>> it, you discover that many design decisions that look stupid are in fact
>> merely obsolete. They served a purpose 60 years ago, it's just that they
>> aren't the best choice any more.
>
>    That would be quite strange, given that Unix was originally developed
> 41 years ago.

How do you know all these things?

>> These days, the fashion seems to be for everything from print servers to
>> network hubs to be controlled by HTML over HTTP. Which is equally
>> stupid, but looks more pretty...
>
>    Well, it has the advantage that it's still relatively low-bandwidth and
> usable with any web browser in any system, and you can do things with the
> mouse.
>
>    Of course the downside is that you need something that can run a web
> browser.

You need something that supports HTTP, HTML, JavaScript, the DOM, and 
[typically] supports these things with all the same glitches and bugs as 
Internet Explorer 4.5 >_<

What's that? You wanted to reconfigure all your print servers from a 
script? Good luck with that...

Post a reply to this message

Invisible escreveu:
> On 11/11/2010 03:52 PM, Warp wrote:
>> Invisible<voi### [at] devnull>  wrote:
>>> Actually, I found a rather interesting description of the history of
>>> Unix the other day. I'll have to see if I can find it again. As you read
>>> it, you discover that many design decisions that look stupid are in fact
>>> merely obsolete. They served a purpose 60 years ago, it's just that they
>>> aren't the best choice any more.
>>
>>    That would be quite strange, given that Unix was originally developed
>> 41 years ago.
> 
> How do you know all these things?

he is omniscient.  You are just a puny ignorant human.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> 1. Commands have cryptic names like "*" or "+".

  You might as well argue that math is cryptic because it uses notation
like "1+2=3".

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >    That would be quite strange, given that Unix was originally developed
> > 41 years ago.

> How do you know all these things?

  There are two friends of everybody. The name of the first one starts
with a G and the name of the second one starts with a W.

-- 
                                                          - Warp

Post a reply to this message

Invisible wrote:
>>>> (That is, optional sign, one or more digits, optional decimal point
>>>> followed by one or more digits, optional E followed by optional sign
>>>> followed by one to three digits.)
>>>
>>> If I've understood the spec correctly, it's
>>>
>>> do
>>> option (char '+' <|> char '-')
>>> many1 digit
>>> option (char '.')
>>> many1 digit
>>> option (do char 'E'; option (char '+' <|> char '-'); many1 digit)
>>
>> Bzzzt. Sorry. That requires at least a 2-digit number.
> 
> I don't follow. Where do you think by definition deviates from your spec?

Your parser won't parse "+3" as a valid number.

> I've never seen a system that can do that, but I guess that doesn't 
> prove a lot.

Basically, if you wanted the sign, you could do something like

string sign = "(+|-)?";

and then construct your regexp out of parts. Basically, just like you did. 
It's not because "your parser is in a real language". It's because you're 
using whatever language the parser is in to construct the match expression 
and I didn't.

>>> You can also factor the task into smaller pieces:
>>
>> Yeah, that's just a text substitution in the regexp expression.
> 
> Sure. Except without any guarantee of syntactic correctness.

Again, until the first time you run it. So?

Clearly you have no guarantee of semantic correctness, so this really isn't 
a problem, given that with your syntactic correctness you still got the 
expression wrong. :-)

>>> With a regex, on the other hand, you cannot even statically guarantee
>>> that a given string is even a syntactically valid regex.
>>
>> Nonsense. How'd you get that?
> 
> Not every string is a valid regex. You have to follow the syntax rules. 
> But this is not checked at compile-time (and usually /cannot/ be checked 
> at compile-time). So if you make a typo in your regex, you won't find 
> out until runtime.

It can be checked at compile time if your language cares to. That's not an 
aspect of the regexp, but an aspect of you using Haskell.

And if you wrote the code and never ran it, then guess what, you have worse 
problems than syntax errors in your regexps.

> If you start constructing regexs programmatically, your problems just 
> multiplied.
> 
> On the other hand, with a /real/ parser library, both of these grave 
> problems immediately vanish into thin air.

How do you construct your parser programatically in Haskell? That looks like 
code to me.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Warp wrote:
> nemesis <nam### [at] gmailcom> wrote:
>> do you really believe spelling out "option (char '+' <|> char '-')" is 
>> any worth as opposed to "(\+|-)"?
> 
>   Btw, "(\+|-)" is unnecessarily complex. Just use "[+-]". That's exactly
> what the [] syntax is for.

Good point. That was my bad.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Invisible wrote:
> If there are more than three digits, the above parser fails, and no 
> other alternatives are tried (i.e., no backtracking).

Then you aren't doing what regular expressions can do.

In order to *get* the power of regexp, *your* parser has to backtrack. So if 
you turn backtracking off, there are trivial regular expressions you can't 
match. If you turn backtracking on, you're using more time and space than a 
regular expression engine.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message