On Tuesday, 18 December 2018 at 11:25:17 UTC, Jonathan M Davis wrote:
> Of course, even if we _did_ have a solution for reversing attributes, slapping an attribute on the top of the module would still potentially be a maintenance problem, because it's then really easy to miss that an attribute is in effect (it's a problem that we've had on several occasions with druntime and Phobos in the few cases where attributes are mass-applied). So, there is no silver bullet here (though regardless of whether mass-applying attributes is something that should ever be considered good practice, we really should add a way to be able to reverse them).

Thanks Jonathan for your elaborate explanation. I personally have no problem with the attributes which - in practice - means I don't use them much unless I want to make sure something is nogc, for example. For library designers it makes sense to be explicit. I guess that is where the trade-off kicks in. Maybe it is just a feature. We argue against specifying them because other languages are not as explicit. It does add a little noise.

On Tue, 2018-12-18 at 12:20 +0000, Kagamin via Digitalmars-d-announce wrote:
> On Tuesday, 18 December 2018 at 10:19:14 UTC, Russel Winder wrote:
> > Clojure is but you have to work hard for that, the initial language is effectively pure.
> 
> https://ideone.com/y8KWja clearly it isn't, its site only claims that most code happens to be pure, but it looks like it's not checked in any way and not sure if purity can be even checked there.

Can we all agree that Haskell is a pure functional language. I think we must because: a) it says it is, and b) it is.

   f2 = print "Hello World."
   f1 = f2
   main = do
     f1

result of running this:

   GHCi, version 8.0.1
   >
   "Hello World."
   >

OK so Haskell uses monads and Clojure just uses the JVM I/O. Haskell is pure, Clojure is impure. But I stand by my original statement: Clojure is best used as a pure language.

Even if I/O is impure, you can make it pure with monads if you really have to.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On 12/17/18 4:42 AM, Dukc wrote:
> On Monday, 17 December 2018 at 09:41:01 UTC, Dukc wrote:
>> On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote:
>>
>>> @safe and pure though...
>>
>> Why @safe? Can't you just write "@safe:" on top and switch to @system/@trusted as needed?
> 
> Argh, I forgot that you are not supposed to @safe templates away.

You can apply @safe to anything. It's @trusted you have to be careful with.

Of course, it probably won't work for many templates.

-Steve

On Monday, 17 December 2018 at 11:04:13 UTC, Atila Neves wrote:
>> Why @safe? Can't you just write "@safe:" on top and switch to @system/@trusted as needed?
>
> Not quite. It doesn't work the way most people expect for member functions and causes problems for templates.

Don't templates infer attributes? @safe didn't work well for trusted aggregates (including inference), not sure if dip1000 fixes that.

On Tue, Dec 18, 2018 at 08:17:28AM +0000, Russel Winder via Digitalmars-d-announce wrote:
> On Mon, 2018-12-17 at 12:16 -0800, Walter Bright via Digitalmars-d-announce wrote:
> > […]
> > 
> > Going pure, however, is much harder (at least for me) because I'm not used to programming that way. Making a function pure often requires reorganization of how a task is broken up into data structures and functions.

Component-based programming helps a lot in this regard. It breaks the problem down in a way that, when done correctly, captures the essence of the algorithm in a way that's easily translated to pure code (esp. D's expanded definition of purity).


[...]
> I can recommend a short period of working only with Haskell. And then a short period working only with Prolog. Experience with Java and Python people trying to get them to internalise the more declarative approach to software, shows that leaving their programming languages of choice behind for a while is important in improving their use of their languages of choice.
[...]

It's all about the mindset. Being forced to think about the problem from a purely functional perspective gives you a radically different perspective from the usual imperative paradigm, and IME often yields insight into the essential structure of your programming problem that is otherwise easily obscured by the imperative structure imposed upon it.


T

-- 
Klein bottle for rent ... inquire within. -- Stephen Mulraney

On Tue, 18 Dec 2018 08:17:28 +0000, Russel Winder wrote:
> I did a lightning talk at the GStreamer conference in Edinburgh a couple of months ago, concluding that I think D (which about half the audience knew of) is overall better than Rust for GTK+ and GStreamer applications, but recognising that Rust is actually the replacement for C and C++ for GTK+ and GStreamer applications. (Obviously Python has an ongoing role in all this as well.)

Is there a video link for that talk? I'd be interested in hearing it.

On Tue, 2018-12-18 at 16:50 +0000, Neia Neutuladh via Digitalmars-d-announce wrote:
> On Tue, 18 Dec 2018 08:17:28 +0000, Russel Winder wrote:
> > I did a lightning talk at the GStreamer conference in Edinburgh a couple of months ago, concluding that I think D (which about half the audience knew of) is overall better than Rust for GTK+ and GStreamer applications, but recognising that Rust is actually the replacement for C and C++ for GTK+ and GStreamer applications. (Obviously Python has an ongoing role in all this as well.)
> 
> Is there a video link for that talk? I'd be interested in hearing it.

The videos are here:

https://gstconf.ubicast.tv/channels/#gstreamer-conference-2018

I think they recorded the lightning talks as a single video, so you'll have to fast forward to my little bit.

I see from:

https://pengutronix.de/de/2018-10-29-gstconf-2018.html

That it has been described "an entertaining lightning talk about the history of MeTV, a live TV viewing application, up to the latest rewrite in Rust using GStreamer"

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On 18-12-2018 19:52, Russel Winder wrote:
> On Tue, 2018-12-18 at 16:50 +0000, Neia Neutuladh via Digitalmars-d-announce
> wrote:
>> Is there a video link for that talk? I'd be interested in hearing it.
> 
> The videos are here:
> 
> https://gstconf.ubicast.tv/channels/#gstreamer-conference-2018
> 
> I think they recorded the lightning talks as a single video, so you'll have to
> fast forward to my little bit.

If you are only interested in the MeTV part, this is the start of that lighting talk:

https://gstconf.ubicast.tv/permalink/v125ac3127116gnuo89h/#start=2561

-- 
Mike Wey

On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote:
> Not the case in Rust, not the case in how I write D. TBH it's not such a big deal because something has to be typed, I just default to const now anyway instead of auto. @safe and pure though...

I'd be interested in seeing some of that Rust code. My impression from Clojure is that an all-immutable style requires leaning heavily on the garbage collector and as far as I know Rust has none.

On Wed, 19 Dec 2018 01:04:24 +0000, Nathan S. wrote:
> On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote:
>> Not the case in Rust, not the case in how I write D. TBH it's not such a big deal because something has to be typed, I just default to const now anyway instead of auto. @safe and pure though...
> 
> I'd be interested in seeing some of that Rust code. My impression from Clojure is that an all-immutable style requires leaning heavily on the garbage collector and as far as I know Rust has none.

It is greatly simplified by automatic memory management. Rust doesn't have a GC, but it has a complex ownership system instead, and that's the basis of its memory management. When that's insufficient, you use reference counting.

Besides which, this is about defaults. In cases where your data is actually mutable and it would be awkward to switch to a more Haskell-like way of coding, you can still use that.