On 15/03/2015 05:06, Walter Bright wrote:
>> In D we have some implicit casts also because the "cast(int)x" syntax is
>> dangerous. But now we can write safe casts with the "int(x)" syntax,
>> so there's
>> less need of naked implicit casts.
>
> Again, too many casts can cause bugs.

You can have safe wrappers for casts. If you don't want to change the type, use something like std.conv.signed. Isn't that safe?

On 03/14/2015 08:49 PM, Xavier Bigand wrote:
>
> Take a look to the new Qt web site :
> http://www.qt.io/
>

While I personally think the latest D homepage redesign looks stylistically inconsistent and a bit cluttered and messy (I don't mean that to insult, merely an opinion/critique), I'm REALLY glad we haven't jumped on that hideous bandwagon above.

Even ignoring all subjective and objective specifics of the style, the mere concept of designing a site "mobile-first (and desktop if we ever feel like it, as it usually turns out)" is entirely inappropriate for websites relating to software development - a field which even today still takes place almost entirely on desktop/laptop, not phone or tablet.

On Tue, 2015-03-17 at 02:31 -0400, Nick Sabalausky via Digitalmars-d wrote:
> On 03/14/2015 08:49 PM, Xavier Bigand wrote:
> >
> > Take a look to the new Qt web site :
> > http://www.qt.io/
> >
> 
> While I personally think the latest D homepage redesign looks stylistically inconsistent and a bit cluttered and messy (I don't mean that to insult, merely an opinion/critique), I'm REALLY glad we haven't jumped on that hideous bandwagon above.

I think the main issue is that a huge majority of webpage designers have got lazy and just use the same design as everyone else. I have had this debate about "all websites looking the same, and so there is no branding" with a couple of new website owners, but to no avail. It seems the fashion has been encoded into the rules of webpage design. The fact that it leads to bad UX appears not to be an issue for them.

For me the biggest problem with the D website, is that it is dark on light surrounded by light on dark. I prefer light on dark across the whole page. As you say these things are personal. In the end having a nicely branded page is actually more important that any personal taste.

> Even ignoring all subjective and objective specifics of the style, the mere concept of designing a site "mobile-first (and desktop if we ever feel like it, as it usually turns out)" is entirely inappropriate for websites relating to software development - a field which even today still takes place almost entirely on desktop/laptop, not phone or tablet.

You mean you don't do all your documentation lookup on your phablet? How can this be, it is 2015. ;-)

Me, I'm a technology dinosaur, I use my phone for making phone calls.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 3/16/2015 4:29 AM, ninja wrote:
> This. Figuring out the return types in the examples was a daily struggle in the
> first few weeks.

When Voldemort types are returned, they must be by auto. The user isn't supposed to know what the return type is, just how to use it.

On Sat, 2015-03-14 at 12:54 -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> On 3/14/15 11:24 AM, Russel Winder via Digitalmars-d wrote:
> > But yes, it certainly shows you can create shared-memory "multi-threading" this way,
> 
> So your affirmation has been refuted.

It appears so, I grovel at the feet of logic and proof.

The core issue here is the ability to ship memory addresses around instead of having to ship values. I still believe dataflow to be the superior architecture for concurrent and parallel systems. Actian Datarush and GPars are on the JVM and avoid Unsafe, and whilst you can set up sharing of mutable data structures, it is a lot harder than as in Go. Likewise with Python-CSP and PyCSP sending values that are not references to shared mutable state is the norm. It is quite hard to do otherwise with Python as a consequence of the GIL and the necessity to use multiprocessing (i.e. each process is a separate PVM and hence separate OS process, and hence different address space).

> > but anyone actually doing it would be being
> > very silly.
> 
> That's "design by prayer". Aren't most bugs created by people doing very silly things?

And prayer achieves nothing.

I think you can probably remove the "very" there and it still be right.

> > Sending addresses down multiple channels
> 
> One is enough.

Actually no, you need two. I believe you are thinking that the sender retains the reference and sends the reference so one send is enough. True per se. But what Rust is trying to enforce, which C++ (and D?) do not, is ownership of the reference, so that you can send a reference the originator cannot then use.  Clearly std::unique_ptr is trying to provide this for C++ but it isn't enforced as has to be to avoid the situation you coded up in Go.
> 
> > is obvious here and
> > definitely not the right thing to do unless the datum contains an
> > embedded lock which is then used. cf.
> > https://talks.golang.org/2012/10things.slide#3
> 
> Yes, of course it's not the right thing to do. Your point being...?

A language has to enforce not manipulating shared mutable memory or the programs will likely be broken. Functional programming's obsession with copying rather than sharing, helps with this.

> > It would be better if channels could only accept value types, and not reference types.
> 
> Probably not as that would further hamstrung the language.

I am not sure that is true. I find it somewhat strange that Go allows sharing of references to mutable state in this way, it certainly doesn't fit with the way I was brought up to use dataflow.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sat, 2015-03-14 at 22:18 +0000, deadalnix via Digitalmars-d wrote: […]
> So now we are going from Go is safe, to well, it is obviously not safe (then, why were you so eager to have a proof ?) but nobody in their right mind would do something like this.

It is usually Andrei that catches me out overstating the case in general…

My model of dataflow is of processes (separate address spaces) passing
messages which are values not address. This is the way I use GPars,
Python-CSP and Go. As Andrei proved with an existence proof, Go makes it
easy to break this model by sending address around because goroutines
are not processes: goroutines are tasks on a thread pool in a single
address space.

> But this is only a short snippet. This can happen the same way in a million line codebase, and good luck finding it.
> 
> Also, the "no good programmer would do this" is an immediate red flag. Not only programmer will do this, but the one that claim they won't will do it even sooner as they evidently lack self awareness.

Indeed. Which is why goroutines really should be enforced processes, i.e. no access to state outside the goroutine code should be allowed. As far as I am aware Erlang is the premier example of doing this right. We try hard with GPars, but there are still ways of circumventing. Python-CSP has the "problem" that every process is a separate PVM so they really are processes, no mutable state sharing is possible unless you actively construct it. You can, but it is quite hard to do by accident.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tuesday, 17 March 2015 at 06:31:32 UTC, Nick Sabalausky wrote:
> On 03/14/2015 08:49 PM, Xavier Bigand wrote:
>>
>> Take a look to the new Qt web site :
>> http://www.qt.io/
>>
>
> While I personally think the latest D homepage redesign looks stylistically inconsistent and a bit cluttered and messy (I don't mean that to insult, merely an opinion/critique), I'm REALLY glad we haven't jumped on that hideous bandwagon above.

Yes, the scroll-scroll-scroll-scroll-where-did-they-hide-the-info-design is annoying and probably the result of using generic templates. Looks cheap.

> Even ignoring all subjective and objective specifics of the style, the mere concept of designing a site "mobile-first (and desktop if we ever feel like it, as it usually turns out)" is entirely inappropriate for websites relating to software development - a field which even today still takes place almost entirely on desktop/laptop, not phone or tablet.

The site is the epitome of inappropriate:

«This site is optimized with the Yoast WordPress SEO plugin»

On 03/17/2015 02:51 AM, Russel Winder via Digitalmars-d wrote:
> I have had this
> debate about "all websites looking the same, and so there is no
> branding" with a couple of new website owners, but to no avail. It seems
> the fashion has been encoded into the rules of webpage design. The fact
> that it leads to bad UX appears not to be an issue for them.
>

It's been my observation for quite some time that the majority of people in the tech sector seem to have come here primarily as a "follow the leader" reaction to computers being "the big, hot new thing". Consequently, we've become completely overrun by folk with a predominantly trend/fashion-based mentality.

IMO, this explains a LOT of things, such as why (ex.) Node.js and Go (among many, many, many others) have been big despite questionable merit, and why anything like D (or pretty much ANY attempt at persuasion by logical reasoning, such as your UX experiences above) which has strong merit but requires a greater attention span and IQ than that of a gnat, usually faces an uphill battle at best.

I think the "by comparison Go -> condo in hip, trendy area" from the OP is even more appropriate and accurate than the author may have even realized. And a good argument for what makes D better.

Lately I've been thinking we're just chasing our tails with the whole "D marketing" thing. Obviously a larger audience and improved (ie, more accurate) public image would be very good for us, of course. But the way I figure: D already appeals, and will continue to attract more of, *exactly* the audience that it's most suited to - intelligent professionals. The other 90% of field will continue darting around sniffing each others rears no matter WHAT we do, even if we DO manage to catch their attention for the day or two it inevitably takes before the next shiny random object trots across their path.

On Sun, 2015-03-15 at 14:13 +0000, Laeeth Isharc via Digitalmars-d
wrote:
[…]
> [I am by no means expert in Python, but python 3 does not seem to be an improvement if you want to be able to accomplish tasks involving simple processing of ASCII files]

Not entirely true, this is a "belief" being put about by those who wish to stay with Python 2 and not move to Python 3 for reasons other than practical ones.

There are some cases, cf. Mercurial, where the code has been founded on the equivalence of byte and character, which means they have to use Python 2 or undertake a very serious rewrite of everything so as to use Python 3 – which to date they are saying will never happen.

For most people though the fact that strings are sequences of Unicode
codepoints in Python 3 is not a problem processing files as long as they
remember that a file has an encoding. I can see that many like to slide
back to everything is ASCII encoded ergo bytes are strings of length 1
(there are no characters in Python). However once you get over the
barrier of "there are byte sequences and there are strings and they are
different", life becomes very much easier. Certainly I find I have no
problem doing networking with Python 3 having made the mental jump to
"remember about encodings".

[…]
> I think it would be a positive to have some user stories from people who have moved from Python+Cython or Python+C to D and seen significant benefits.  I am sure there are plenty - most users don't seem to be active in the forum.  And we should collect user stories, pretty them up, and have them reachable from the front page very easily.  People make decisions based upon feelings (indeed without feelings there can be no decision), and so stories - based in reality - can be more persuasive than dry facts in persuading people.

This would be a good addition to the website. Along with any C++ → D stories.

It might be worth collecting D → … stories as well, not perhaps to publish but to ascertain what the issues were.
> 
> We should try to identify what the biggest sticking points are for people considering making the switch, both real (like documentation) and perception (like 'D has no web/server framework'.

I am fairly confident that the major issue is "presence in the market". D is not a language that is known about, or talked about, in the same sentences as Java, Python, C++, Fortran, Go, Scala, Groovy, etc. All too often when I mention D in a conversation about language choice, the reaction is "I've not heard of that one.". Nim, Ceylon, Kotlin are in the same boat. Raising the presence of D in the minds of programmers and their bosses so it get used in the same sentences as the other languages is the task at hand.

[…]
> 
> I was thinking about this just recently.  There used to be a D scripting language (now rebranded as something else - I forget the name), but this fell into disuse post rdmd.  Rdmd is great, a real simple win, but doesn't substitute for a scripting language in all uses.

Unless a REPL is needed (see previous rant of mine on REPLs, but you possibly have a genuine need for one), editor+fast compilation is almost certainly a better solution that a single line REPL. So rdmd almost certainly its most people needs for "scripting with D".

The question is how to deal with evolving a persistent data set that takes a long time to construct. I wonder if, rather than writing an interpreter/REPL à la Scala, it might be better to build a small framework for managing a persistent dataset. On Posix at least wrapping something around mmap should do the job. This would then allow snapshotting.

> In particular, I do agree with Russell about the value of an ipython/Jupyter notebook for scientific computing (which means also parts of finance) - especially for playing with data.  Excel won't cut the mustard any more for many modern data sets, which means new tools like ipython notebooks come into focus.

s/Russell/Russel/ ?

Excel is still the most used tool in quant work in many financial institutions :-( Some banks are even going to the extent of incorporating its use into their Python/C#/C++ workflows.

> For the time being it's not the lack of a notebook, but the lack of dataframes and pandas style functionality that prevent using D easily in this domain.  But dataframes are not that complicated or difficult, and it is just a bit of work, and Vlad Levenfeld has made a good start on some of this.
> 
> I wonder whether it would be feasible to integrate the D REPL with Jupyter.  Russell?

Jupyter's aim is to be as language agnostic as possible. Hence it's separation from IPython: having a separate identity makes it easier for people to acknowledge the UI can be used with R, Julia, Markdown, LaTeX as well as Python.

[…]

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 03/17/2015 03:45 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>
> Yes, the scroll-scroll-scroll-scroll-where-did-they-hide-the-info-design
> is annoying and probably the result of using generic templates. Looks
> cheap.
>

Funny thing is, I've seen a LOT of generic-template sites that look & feel WAY better than the "mobile first"-style ones.

I'm still a little bit irked that Linode ditched their formerly fantastic homepage for yet-another-useless-PITA-mobile-first-style homepage.

>> Even ignoring all subjective and objective specifics of the style, the
>> mere concept of designing a site "mobile-first (and desktop if we ever
>> feel like it, as it usually turns out)" is entirely inappropriate for
>> websites relating to software development - a field which even today
>> still takes place almost entirely on desktop/laptop, not phone or tablet.
>
> The site is the epitome of inappropriate:
>
> «This site is optimized with the Yoast WordPress SEO plugin»

Sometimes I'm truly amazed by the lengths people will go JUST to contort WordPress into whatever not-remotely-related purpose they have in mind.

It's like being the only carpenter in the world who uses a hammer instead of stringing up a frozen pizza to the end of a rubber squeeze toy.