Nick Sabalausky wrote:
> And I'll see your "HTML/XML syntax is a horrid verbose mess", and raise you a "(X)HTML's shittiness extends far beyond the syntax."

What's odd about how pointlessly verbose it is, is it was designed in the era of modems. You'd think that tightening up the syntax would be a priority.

Am 07.08.2010 06:39, schrieb Nick Sabalausky:
(...)
>
> I use Programmer's Notepad 2 which does parenthesis-matching out-of-the-box.
>
>
Hey, you are the first person I heard of that also uses PN2 :) . It isn't a full-featured IDE but it's a great editor for programming, isn't  it.

On 08/07/2010 01:40 AM, Walter Bright wrote:
>
> What's odd about how pointlessly verbose it is, is it was designed in
> the era of modems. You'd think that tightening up the syntax would be a
> priority.

Do you really think those <p> tags and <a href> tags were choking the 14.4 modems of the time? When HTML was first designed, it was a simple markup language.

The real bandwidth killers were when people put pictures (*gasp*) in their HTML pages. It got really annoying when people decided to use image maps for navigation, which meant you couldn't browse with pictures turned off.

Ah, good times.

On 2010-08-06 19:23, Steven Schveighoffer wrote:
> On Fri, 06 Aug 2010 11:48:00 -0400, Jacob Carlborg <doob@me.com> wrote:
>
>> On 2010-08-06 17:41, Alexander Malakhov wrote:
>>> Steven Schveighoffer <schveiguy@yahoo.com> писал(а) в своём письме Fri,
>>> 06 Aug 2010 18:28:41 +0700:
>>>
>>>> 2. It seems like the documentation is HTML written as ddoc. I see $(P)
>>>> tags, $(LI) tags, etc. Can't we just write it as HTML?
>>>
>>> I have had exactly same thought when I've first seen DDoc a week ago
>>>
>>>
>>>> I think many would feel much more comfortable that way.
>>>
>>> I have virtually zero exp with HTML/XML, but DDocs syntax seems to be
>>> pretty
>>> straightforward
>>>
>>>> It's also more supported by editors. I forgot a closing parentheses on
>>>> one tag, and it screwed up the entire page. I had to find it by hand,
>>>> whereas an HTML editor could red-flag a tag without a closing tag, or
>>>> you could run it through an XML verifier (if it's xhtml).
>>>
>>> Good points. And XML is not going to disappear anytime soon, so there
>>> will
>>> always be a lot of people familiar with it, as wall as tool for it.
>>> So I think it would be reasonable to have <tag/> syntax and HTML tags
>>> like <B>, <I> etc.
>>>
>>> Also, for example, what if I want to put extra ')' paren into $(D text)?
>>> I think there is (simple) solution, but that is one more thing to learn.
>>> In the end it's just markup language and I don't see much use in
>>> learning
>>> more then one of them.
>
>>>
>>> One reason of it I can think of: parsing speed and ambiguities (same as
>>> with <templates>)
>>>
>>> Anyway, when D will take over the world, they will have to change HTML
>>> syntax to fit what everyone already knows )
>>
>> One reason is why HTML is not used directly is that you could output
>> the documentation in other formats than HTML, like PDF. A second
>> reason to use macros (i.e. $(B arg)) instead of HTML is that this
>> allows you to have the macro expand into something like this <span
>> class="bold">arg</span> instead of <b>arg<b>. Of course one could
>> define a language in XML to use instead of the macros.
>
> Does ddoc output in pdf? And besides, most of the tags *are* html tags,
> they're even the same tag name. I can't imagine there's no htmltopdf
> program that would do exactly that.
>
> Regarding the <span class="bold"> thing, can't you just do this in css:
>
> b {
> whatever;
> }

Many/some of the "style" tags have been deprecated in XHTML/HTML5. Now, apparently "b" wasn't one of them as I first thought.

> and override what <b> does? There are probably macros which do other
> things that xhtml/css cannot do, but I don't think we should use macros
> for every html element. For example, the $(V1) and $(V2) tags. We need a
> good solution for that, and I think having dmd work those out is fine. I
> also don't mind using the macros for more dynamic stuff. I just think
> the formatting stuff can remain html, and all the macros should be
> defined/documented somewhere.
>
> I like this explanation from Alexander:
>
> In the end it's just markup language and I don't see much use in
> learning more then one of them.
>
> It's just a thought, it might be blowing out of proportion a bit.
> Granted I think I would have felt more comfortable using html directly,
> but it wasn't that hard to learn, and I was able to work through the
> issues. I just wish I had some editor help...
>
> -Steve

Would it be better to write in XML that then converts it to the output format?

-- 
/Jacob Carlborg

On 2010-08-07 00:54, Walter Bright wrote:
> Don wrote:
>> The reason they're the same is that the docs were originally written
>> in html. The original conversion to ddoc was done via search and replace.
>> One of the HUGE benefits of ddoc is that it does highlighting of the D
>> code. That instantly saved Walter a lot of time.
>> Seriously, converting it to ddoc did improve productivity.
>
> Here's what it has done, and this is real live experience because they
> were originally 100% html:
>
> 1. Yes, Don is right. It has improved ENORMOUSLY the productivity in
> those documents. I'm talking doubling or even tripling it.
>
> 2. I can comment out sections with $(COMMENT blah blah) and have them
> elided from the output. HTML comments remain in the output.
>
> 3. It has enabled the site to be written in correct, conforming HTML.
> Previously, it was a mess, and I didn't know what was wrong with it
> because it rendered ok anyway.
>
> 4. HTML has zero provision for conditional compilation. Want two HTML
> pages from the same source? Write two HTML pages. Note that the D1 and
> D2 docs are generated from the same source, this makes it easy to
> determine what's different between them.
>
> 5. It enabled me to produce a common look & feel for the whole site,
> which is hundreds of pages. This was just impossible before.
>
> 6. Even better, I can *change* the look and feel of the site with just
> editting a handful of macros.
>
> 7. I can update URLs across the site trivially, such as if bugzilla
> changes its URL.
>
> 8. As Don mentioned, it will automagically syntax highlight D code.
>
> 9. Grep doesn't work well with HTML tags. You really need an HTML-aware
> editor. Ddoc works with any editor (all you really need is a parentheses
> matcher).
>
> 10. HTML is a visually butt-ugly format that makes my eyes bleed pus.
> Very hard to read.

I think for any serious HTML work you need a server side language to help you.

-- 
/Jacob Carlborg

Hello Alexander,

> Steven Schveighoffer <schveiguy@yahoo.com> писал(а) в своём письме
> Fri, 06  Aug 2010 18:28:41 +0700:
> 
>> 2. It seems like the documentation is HTML written as ddoc.  I see
>> $(P)  tags, $(LI) tags, etc.   Can't we just write it as HTML?
>> 
> I have had exactly same thought when I've first seen DDoc a week ago
> 

There are a few pieces that I'd like to see stay as customizable markup, the BNF rules for one because it would allow the rules to be run with a different set of macros and, for example, generate input to a parser generator. Once such a system is set up it would make it trivially easy to keep the docs and parser in sync.

If people really don't like the current system and if an appropriate XSLT library could be found, then converting the current system to generate XML tags and run it through some XSLT pass should be just as powerful as what we have now but better supported by existing tools.

-- 
... <IXOYE><

Hello Walter,

> BCS wrote:
> 
>> While you fix that, could you also add support for another linker to
>> the win32 version?
>> 
> Which one are you thinking about?
> 

I'm not. I was just assuming the solution would be to add support for an existing 64bit capable windows linker. And I'm guess that most of that would would be shared with adding support for a 32 bit one as well (assuming a pair of linkers that support the same file format can be found).

-- 
... <IXOYE><

Hello Walter,

> Jonathan M Davis wrote:
> 
>> Unfortunately, in order to be able to use D where I work, I'd have to
>> be able to link the D code with C/C++ code which has been built with
>> Visual Studio and its compiler and linker. And, if I understand
>> correctly, that means that the D code has to be linked with
>> Microsoft's linker. If that's a misunderstanding on my part, then
>> linking D with Microsoft's linker would be unnecessary, and dmc
>> should do the job just fine (though only needing the one C/C++ linker
>> over two would still be an improvement). But as I understand it, any
>> C or C++ code which is going to be used with D code in Windows has to
>> have been built with dmc.
>> 
> This actually used to be possible with dmc, but Microsoft has
> repeatedly changed formats (some of them are secret, too) and I gave
> up endlessly chasing those changes.
> 

Would you be open to allowing semi official builds of DMD? That would be have builds of DMD that use the official DMD code base except for an object file generator mainland by someone else. It seems that would be a clean separation point that shouldn't break to often and you already have, what, 4 different versions now?

A good build system should make this an almost no effort proposition on your part: you develop as normal and whenever you do a release, the other versions would get built, tested and if they pass, posted to the site, if not, the owners (not you) get contacted.

-- 
... <IXOYE><

"Walter Bright" <newshound2@digitalmars.com> wrote in message news:i3aofk$242d$1@digitalmars.com...
> Adam Ruppe wrote:
>> The Digital Mars EMCAScript implementation is insanely fast too. It comes in at about 80x faster than IE6 - its contemporary competition. Now, the new browsers beat it out by several times, but it took them a lot of years to catch up.
>
> Yeah, at the time (10 years ago) I shopped it around to the various browser vendors, and nobody believed the speed increase. Sigh.

Out of curiosity, what sorts of people did you speak to? The actual developers or, well, people who aren't primarily developers? The latter tend to be complete morons ( "I don't know anything about programming, but I'm very good at identifying people who are good at it.": http://www.semitwist.com/articles/article/view/human-resources-the-expert-novices )

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:i3a5d6$pig$1@digitalmars.com...
> On 08/03/2010 04:31 PM, bearophile wrote:
>> BCS:
>>
>>> The video is up: http://www.youtube.com/watch?v=RlVpPstLPEc
>>
>> Thank you for the link and thank you to Andrei for the very nice talk. I think the link can be put on Reddit too, if not already present. When Andrei talks he seems a little different from the Andrei that writes in this newsgroup. The talk was quite interactive, and the idea of giving away books for good questions was a good one. The people in the room seem to know how to program.
>
> Thanks. I hope the difference is in the "good" direction. Somehow I find it difficult to grok the right tone on the Usenet.
>
> Regarding this talk, I was so nervous during it that I was (and am after watching the recording) unable to assess the talk's quality. I was mostly on autopilot throughout; for example I seem to vaguely recall at some point there were some people standing in the back, but I have no idea when they appeared.
>

I thought the talk was great. :)


>> 27.50, "transactional file copy": this example was script-like, and as short as possible to fit into one single slide, so in this case I think using enforce() is OK. But in true programs I suggest all D programmers to use DesignByContract with assert() more and to use enforce() less. Among other things enforce() kills inlining possibilities and inflates code. In D.learn I have seen people use enforce() in a situation where DbC is designed for. I think the D community needs to learn a bit more DbC, and in my opinion to do this the leaders have to lead the way.
>
> I agree with Walter that enforce() is the only right choice there.
>

For a slide-presentation I agree. But if I were writing it for myself, I would just use "if()" and "return 1;". (I do like enforce() for other uses though.)


>> 42.00: I don't know what Big-O() encapsulation is. I think later you explain it a bit more, but I have lost the meaning.
>
> Sorry. By that I mean an abstraction that uses information hiding to make complexity an implementation detail, instead of an interface requirement. Consider e.g. at(int) for a sequence container which makes no claim about complexity.
>

I used to disagree with that, but I think I've been sufficiently convinced.