compile-time regex redux

[kris]

Andrei Alexandrescu (See Website For Email) wrote:
> kris wrote:
> 
>> Andrei Alexandrescu (See Website For Email) wrote:
>>
>>> kris wrote:
>> You're saying that a 'normal' D program is not sufficiently powerful 
>> to write other programs?  Au contraire!  There's nothing wrong with 
>> doing that at runtime, rather than turning the compiler itself into an 
>> abstract virtual machine?
> 
> 
> You don't understand. Code generation is only interesting when the 
> generated code works together with handwritten code and lives within the 
> same symbolic ecosystem.

Okay, I do understand that. My overall point is that such things are of 
  interest to only a tiny fragment of the commercial market.


> I tried to provide solid argumentation and/or evidence for my 
> statements. The post I replied to originally, and the post I am replying 
> to now, use rhetoric and bare statements somehow implying they are drawn 
> from common knowledge. I will not simply agree with a bare statement 
> claiming that this is not needed or that is not necessary.

I thought I added some evidence myself, in the paragraph below, but you 
seems to have missed that?

> 
>> We might as well be discussing whether the compiler should embed a GUI 
>> generator. So it can be used at compile-time. There are better ways of 
>> doing that. Ways that are more accessible, more maintainable, and have 
>> a much easier learning curve. The OSX GUI builder is one fine example.
>>
>>
>>> To survive, D must compensate for its relative lack of clout and 
>>> publicity by offering above and beyond what more mainstream languages 
>>> offer.
>>
>>
>> To survive, D needs to get serious about being taken seriously.
> 
> 
> Exactly what is anyone to make of this? 

Andrei, it's really no different to your claim that D must somehow 
"compensate for its relative lack of clout" by adding compile-time regex 
to the language (the topic at hand). Wouldn't you agree? D would 
arguably have more clout if a number of items were resolved, rather than 
adding more features.

Sure, I can imagine there's a lot more behind this than just Regex - but 
the point made elsewhere is a good one: if the DSL facilities are going 
to be totally awesome, one should be able to implement regex in it; 
efficiently.

You can do that today using templates. It's just not terribly efficient, 
as Walter pointed out.


 > Reminds me of Jerome K. Jerome:
 > "Never do something shameful, my son," the mother said, "and then
 > you'll never be ashamed of what you did."


How about: "Just because you can, doesn't mean you should" ?


> 
>> Concentrating on what /might/ become a niche ideal doesn't strike me 
>> as the best approach. Compare and constrast with, say, targeting D for 
>> cell-phone devices? It's the biggest market on the planet, just 
>> sitting there /waiting/ for D to come along with the right set of 
>> features.
> 
> 
> Sure if there are abstractions of interest to embedded programs they are 
> worth discussing. But again, leaving it at the level of Zen statements 
> is only empty rhetoric.

Hrm ... I won't go there :)


> 
>>>> What is wrong with runtime execution anyway? It sure is easier to 
>>>> write and maintain clean D code than (for many ppl) complex concepts 
>>>> that are, what amount to, nothing more than runtime optimizations. 
>>>> Isn't that true?
>>>
>>>
>>>
>>> No. Accommodating DSLs and generating code has more to do with 
>>> correctness and avoiding duplication of source code, than anything else.

Okay. That comes back to my original point about whether this is 
something that is gonna attract mainstream developers, en masse. Forgive 
me, but I just don't see that it does.


>> Yes and no. I will defer, of course, to your experience in the matter; 
>> but will note that there's /always/ a point of diminishing return.
> 
> 
> To this I'll insert the obligatory answer that that's a truism.
> 
>>> a "white hole" class is an implementation of A that implements all 
>>> methods to throw, and a "black hole" class is an implementation of A 
>>> that implements all methods to return the default value of the return 
>>> type.
>>>
>>> This pattern is very useful for either quick starting points for 
>>> writing true classes implementing A, or as standalone degenerate 
>>> implementations.
>>>
>>> To some programmers, black and white holes might not even raise a 
>>> "duplicated code" flag. They sit down and write:
>>
>>
>> That could reasonably be argued as a point of diminishing return? If 
>> it takes more effort or knowledge of how to abstract the pattern from 
>> two or more concepts, and to implement it using something unfamiliar, 
>> then 99% of developers will ignore it completely.
> 
> 
> I think any developer can write an alias statement. The point of the 
> example was to illustrate how an advanced feature can be used by an 
> expert to democratize efficient development.

I agree. But then how many everyday /useful/ patterns really exist in 
that form? Ones that ppl would actually use? Gui patterns are one of the 
few areas that come to mind. Componentization of software dev has long 
been a dream (akin to how hardware components are assembled). But the 
software world has never operated that way. It gets further and further 
away every year, as code becomes more and more throwaway.

More often than not, a 'reusable' component (perhaps written by an 
expert) simply does not offer what the user needs. The time it takes to 
understand how to 'adapt' that component is often longer than it takes 
to implement the required functionality directly. I don't agree with the 
approach, but it's what I see in both commerce and research.

It doesn't matter whether the component is hand-written or machine 
generated; the end result appears to be the same (IMO).


> 
> Abstraction is hard, no question about that. (Another truism. :o)) The 
> problem is that often, even when the abstraction is understood, 
> reflecting it in code is a complete mess.

Yes.

> 
> Walter gave another good case study: Ruby on Rails. The success of Ruby 
> on Rails has a lot to do with its ability to express abstractions that 
> were a complete mess to deal with in concreteland.
> 

Let look at that case study, then. The /real/ power in RoR comes from 
being able to dynamically bind via rich reflection. What we're talking 
about here does not add full reflection to D. Neither does it assist in 
getting D modules dynamically loaded at runtime.

As it turns out, some of us are actively looking /specifically/ at the 
killer RoR for D; far beyond what RoR does. Oddly enough, our working 
name for it is - DeRailed -

We have solid notions of what's needed; and several of us have build 
related platforms in the past. But this topic, at face value, doesn't 
appear to help us in any notable fashion. Perhaps you can expain this 
further?



>> And I can't see how this could possibly help D get notable traction, 
>> since it can also be done using the tools already available in D: 
>> contracts via interfaces or abstract base-classes.
> 
> 
> This reflects misunderstanding of the stakes. Interfaces and abstract 
> base classes are a recipe for _handwritten_ code. black_hole and 
> white_hole are tools that generate code _mechanically_.

Okay. But the fundamental approach to patterns is rather similar. You 
were discussing facilities provided as a template-of-functionality (in a 
lib or somewhere). At that level it doesn't matter, to the user, whether 
  they were originally hand written or not. That's what drove my point, 
rather than a misunderstanding.

- Kris