On Monday, 12 August 2013 at 16:45:52 UTC, Chris wrote:
> unless it's a very specific thing  like web development
> where PHP etc are handier.

D rox for webdev too :) Only downside is it isn't pre-installed like php tends to be, but it still rox.

On Monday, 12 August 2013 at 16:58:22 UTC, Adam D. Ruppe wrote:
> On Monday, 12 August 2013 at 16:45:52 UTC, Chris wrote:
>> unless it's a very specific thing  like web development
>> where PHP etc are handier.
>
> D rox for webdev too :) Only downside is it isn't pre-installed like php tends to be, but it still rox.

Yes, but it's still a bit of a gamble to use D. You'd need a (virtual) server.

On Monday, 12 August 2013 at 16:58:22 UTC, Adam D. Ruppe wrote:
> On Monday, 12 August 2013 at 16:45:52 UTC, Chris wrote:
>> unless it's a very specific thing  like web development
>> where PHP etc are handier.
>
> D rox for webdev too :) Only downside is it isn't pre-installed like php tends to be, but it still rox.

Hehe, sometimes I have the feeling that PHP is only language that does _not_ rock for webdev :) Well, probably with the exception of Brainfuck. No sure about latter though.

On Monday, 12 August 2013 at 17:23:39 UTC, Dicebot wrote:
> On Monday, 12 August 2013 at 16:58:22 UTC, Adam D. Ruppe wrote:
>> On Monday, 12 August 2013 at 16:45:52 UTC, Chris wrote:
>>> unless it's a very specific thing  like web development
>>> where PHP etc are handier.
>>
>> D rox for webdev too :) Only downside is it isn't pre-installed like php tends to be, but it still rox.
>
> Hehe, sometimes I have the feeling that PHP is only language that does _not_ rock for webdev :) Well, probably with the exception of Brainfuck. No sure about latter though.

PHP is terrible. The fact that you have to mark variables with $ is simply ridiculous. PHP is not very exciting. But it does the job.  Alas, why do the mediocre solutions always find acceptance?

On Monday, 12 August 2013 at 16:58:22 UTC, Adam D. Ruppe wrote:
> On Monday, 12 August 2013 at 16:45:52 UTC, Chris wrote:
>> unless it's a very specific thing  like web development
>> where PHP etc are handier.
>
> D rox for webdev too :) Only downside is it isn't pre-installed like php tends to be, but it still rox.

Yea, but how is that related to column width in PDF articles? Please stay on-topic...

On Mon, Aug 12, 2013 at 08:57:10PM +0200, Chris wrote:
> On Monday, 12 August 2013 at 17:23:39 UTC, Dicebot wrote:
> >On Monday, 12 August 2013 at 16:58:22 UTC, Adam D. Ruppe wrote:
> >>On Monday, 12 August 2013 at 16:45:52 UTC, Chris wrote:
> >>>unless it's a very specific thing  like web development where PHP etc are handier.
> >>
> >>D rox for webdev too :) Only downside is it isn't pre-installed like php tends to be, but it still rox.
> >
> >Hehe, sometimes I have the feeling that PHP is only language that does _not_ rock for webdev :) Well, probably with the exception of Brainfuck. No sure about latter though.
> 
> PHP is terrible. The fact that you have to mark variables with $ is simply ridiculous. PHP is not very exciting. But it does the job. Alas, why do the mediocre solutions always find acceptance?

Marking variables with $ is actually not a bad thing; it helps set variables apart from, say, type identifiers, functions, etc.. But in the context of PHP, it's kinda pointless.

But this is only the least of PHP's problems. I'm not going to repeat what people have said about PHP's flaws, but you can read all about it here:

	http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

As for why mediocre solutions always find acceptance, I really don't know either. I've come to adopt the rule of thumb that if something is popular, then assume it sucks by default, until it's proven otherwise. It has worked pretty well for me so far.


T

-- 
WINDOWS = Will Install Needless Data On Whole System -- CompuMan

On Mon, 12 Aug 2013 13:45:02 +0200
Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:

> On 08/12/2013 05:57 AM, Andrei Alexandrescu wrote:
> > On 8/11/13 4:45 PM, Joseph Rushton Wakeling wrote:
> >> On Sunday, 11 August 2013 at 23:37:28 UTC, Andrei Alexandrescu wrote:
> >>> That's an odd thing to say seeing as a lot of CS academic research is ten years ahead of the industry.
> >>
> >> I would personally venture to say that the publication practises of academia in general and CS in particular have many destructive and damaging aspects, and that industry-academia gap might be narrowed quite a bit if these were addressed.
> > 
> > Could be improved, sure. Destructive and damaging - I'd be curious for some substantiation.
> 
> In the case of CS in particular, the publication system is different from much of academia because it's so strongly based around conferences and conference proceedings.  I'd say that's damaging in several ways.
> 
> First, it means people write to the submission deadline rather than to their work having reached a satisfactory point of readiness.  All other activities grind to a halt in the run-up to major conference deadlines -- you see students and postdocs in particular pulling all-nighters in order to make sure that everything gets done in time.
> 
> Besides the health implications of that, such a last-minute rush has plenty of scope for making mistakes or introducing errors, errors that will be in the permanent academic record with little scope for correction (conference proceedings generally don't carry errata). There are also more direct sources of bias -- e.g. if the work is based on user surveys, the chances are all the people in the lab _not_ working towards a paper deadline will be shanghaied into completing those surveys, disrupting their own work and also ensuring that the results are based on a very skewed selection of the population.
> 
> This pressure to deliver on deadline something that will be accepted by the conference can also lead to quite a superficial approach to the existing literature, with references skimmed quickly in order to find any random phrase that may support the current piece of work (even though on closer reading it may actually indicate the opposite).
> 
> The second source of damage comes via the conference review process. Because conferences are all-or-nothing affairs -- you get accepted or you don't -- there's a strong tendency to submit multiple papers presenting different facets of essentially the same work to multiple different conferences, just to ensure that _something_ gets accepted.  That means overwork both for the authors (who have to write all those extra papers) and also for conference referees, who have to deal with the resulting excess of papers.
> 
> Reviewers are also working to deadlines, and with a lot of papers to assess in a short space of time (which is very disruptive to their other work), that can lead to snap and very superficial judgements. If there's a discrepancy in the amount of work that has to be done -- e.g. a "yes" means just a "yes", but a "no" means having to write a detailed report explaining why -- that can lead to accepting papers simply to lessen the workload.
> 
> There are also financial aspects -- because most conferences (understandably) won't accept papers unless at least one author comes to present, it means that authors' ability to publish their work can be constrained by their labs' ability to fund travel, accommodation and conference fees rather than by the quality of what they've done.
> 
> And finally, when all is done and dusted, the proceedings of conferences are almost invariably then locked up behind a publisher paywall, despite the fact that almost all the document preparation work is done by authors and conference volunteers.  How many tech businesses can afford the annual subscriptions to digital libraries? (I'm thinking small startups here.)
> 
> I suppose you could say that many of these issues are personal/professional failings of individual researchers or labs, but in my experience these failings are driven by the pressure to publish conference papers, and young researchers are pretty much trained to follow these working practices in order to succeed.
> 
> What particularly frustrates me about this particular situation is that the justification for the current system -- that computer science is too fast-moving for journal publication to keep up with the latest results -- simply doesn't hold water in an age of electronic publication.  It's habit and professional career structures, rather than the interests of research communication, that maintain the current system.
> 
> I could go on, but I think these examples will serve as substantiation. :-)

You really should post that somewhere as a "blog" article.

On 8/12/13 4:45 AM, Joseph Rushton Wakeling wrote:
> On 08/12/2013 05:57 AM, Andrei Alexandrescu wrote:
>> On 8/11/13 4:45 PM, Joseph Rushton Wakeling wrote:
>>> On Sunday, 11 August 2013 at 23:37:28 UTC, Andrei Alexandrescu wrote:
>>>> That's an odd thing to say seeing as a lot of CS academic research is
>>>> ten years ahead of the industry.
>>>
>>> I would personally venture to say that the publication practises of
>>> academia in general and CS in particular have many destructive and
>>> damaging aspects, and that industry-academia gap might be narrowed quite
>>> a bit if these were addressed.
>>
>> Could be improved, sure. Destructive and damaging - I'd be curious for some
>> substantiation.
>
> In the case of CS in particular, the publication system is different from much
> of academia because it's so strongly based around conferences and conference
> proceedings.  I'd say that's damaging in several ways.

I'd agree a lot more with what follows if it weren't for workshops, symposia, and journals, which together complete quite a large spectrum of publication and debate venues, all with different tradeoffs.

> First, it means people write to the submission deadline rather than to their
> work having reached a satisfactory point of readiness.  All other activities
> grind to a halt in the run-up to major conference deadlines -- you see students
> and postdocs in particular pulling all-nighters in order to make sure that
> everything gets done in time.

But that's a matter common to all deadline-oriented work. The tradeoffs are well known. Also, Journals and trade magazines don't have such.

> Besides the health implications of that, such a last-minute rush has plenty of
> scope for making mistakes or introducing errors, errors that will be in the
> permanent academic record with little scope for correction (conference
> proceedings generally don't carry errata).

On the upside that's incentive for producing good-quality work. Indeed, conference proceedings are predictably better than workshops or non-peer-reviewed publications.

> There are also more direct sources
> of bias -- e.g. if the work is based on user surveys, the chances are all the
> people in the lab _not_ working towards a paper deadline will be shanghaied into
> completing those surveys, disrupting their own work and also ensuring that the
> results are based on a very skewed selection of the population.

I haven't seen anyone really complaining about it. Not sure what surveys you mention. Students who don't submit this time around have more time focusing on research.

> This pressure to deliver on deadline something that will be accepted by the
> conference can also lead to quite a superficial approach to the existing
> literature, with references skimmed quickly in order to find any random phrase
> that may support the current piece of work (even though on closer reading it may
> actually indicate the opposite).

We're all guilty of that to a small extent. Generally people are good at picking relevant literature, and my advisers were very careful in reviewing quotations.

> The second source of damage comes via the conference review process.  Because
> conferences are all-or-nothing affairs -- you get accepted or you don't --
> there's a strong tendency to submit multiple papers presenting different facets
> of essentially the same work to multiple different conferences, just to ensure
> that _something_ gets accepted.  That means overwork both for the authors (who
> have to write all those extra papers) and also for conference referees, who have
> to deal with the resulting excess of papers.

That may happen at second and third tier venues. Good conferences accept good research, which means a submitter won't risk a rejection by chopping work in multiple pieces and submitting it separately. Never really heard of a labmate doing this.

> Reviewers are also working to deadlines, and with a lot of papers to assess in a
> short space of time (which is very disruptive to their other work), that can
> lead to snap and very superficial judgements.  If there's a discrepancy in the
> amount of work that has to be done -- e.g. a "yes" means just a "yes", but a
> "no" means having to write a detailed report explaining why -- that can lead to
> accepting papers simply to lessen the workload.

Agreed.

> There are also financial aspects -- because most conferences (understandably)
> won't accept papers unless at least one author comes to present, it means that
> authors' ability to publish their work can be constrained by their labs' ability
> to fund travel, accommodation and conference fees rather than by the quality of
> what they've done.

Journal papers.

> And finally, when all is done and dusted, the proceedings of conferences are
> almost invariably then locked up behind a publisher paywall, despite the fact
> that almost all the document preparation work is done by authors and conference
> volunteers.  How many tech businesses can afford the annual subscriptions to
> digital libraries?  (I'm thinking small startups here.)

Many academists defend the likes of IEEE etc., which use the funds gathered that way for good purposes. I know most conferences don't prevent their authors from putting their work online. In CS it is very rarely the case that a paper cannot be found without having to pay for it, and in those rare cases a little social engineering gets you the paper (I wrote the author and got it once).

> I suppose you could say that many of these issues are personal/professional
> failings of individual researchers or labs, but in my experience these failings
> are driven by the pressure to publish conference papers, and young researchers
> are pretty much trained to follow these working practices in order to succeed.
>
> What particularly frustrates me about this particular situation is that the
> justification for the current system -- that computer science is too fast-moving
> for journal publication to keep up with the latest results -- simply doesn't
> hold water in an age of electronic publication.  It's habit and professional
> career structures, rather than the interests of research communication, that
> maintain the current system.
>
> I could go on, but I think these examples will serve as substantiation. :-)

Well I'm unconvinced but this seems to be one of those potayto-potahto kind of things. I do agree the situation can improve.



Andrei

On Mon, 12 Aug 2013 12:34:22 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> 
> But this is only the least of PHP's problems. I'm not going to repeat what people have said about PHP's flaws, but you can read all about it here:
> 
> 	http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
> 

Ever since I first came across that, it's been my all-time favorite article on the web. He absolutely hits the nail on the head.

> As for why mediocre solutions always find acceptance, I really don't know either.

I think it has a lot to due with most people equating "good" and "popular". Popularity, by its very nature, is driven primarily by a self-feedback loop, so the "core" of popularity-based selections tends to be highly influenced by statistical noise, and is therefore fairly random. Since "90% of everything is crap", most of these somewhat-random popularity-based selections tend to be crap.

Hence, PHP being on every freaking server in existence (including
mine, embarrassingly enough).

Plus, most people (or really, humans in general) just aren't well suited to making merit-based choices anyway. Too easily influenced by less meritful factors like emotion, mental association, mistaken assumptions, impulse, popularity, etc.


> I've come to adopt the rule of thumb that if something is
> popular, then assume it sucks by default, until it's proven otherwise.
> It has worked pretty well for me so far.
> 

I wound up doing the same, somewhat unconsciously. A Pavlovian response I guess. And I agree, while it *has* occasionally led me astray, it usually serves me well. Of course, I'm a guy to usually tends to fall outside the bell curves anyway, so YMMV I suppose.

On Mon, 12 Aug 2013 21:23:17 +0200
"Idan Arye" <GenericNPC@gmail.com> wrote:

> On Monday, 12 August 2013 at 16:58:22 UTC, Adam D. Ruppe wrote:
> > On Monday, 12 August 2013 at 16:45:52 UTC, Chris wrote:
> >> unless it's a very specific thing  like web development where PHP etc are handier.
> >
> > D rox for webdev too :) Only downside is it isn't pre-installed like php tends to be, but it still rox.
> 
> Yea, but how is that related to column width in PDF articles? Please stay on-topic...

*ahem* How is column width in PDF articles related to whether or not D is the answer to the One vs. Two Language High Performance Computing Dilemma? ;)