Re: "Constructor" was a Very Bad name choice we have never recovered from (Was Re: D is dead)

[FeepingCreature via Digitalmars-d]

On Monday, 27 August 2018 at 11:02:14 UTC, Guillaume Piolat wrote:

C++ binds the two in the same operation.

D does not, T.init must be a valid object. This is a major 
cultural change, though I believe the D way is superior on the 
efficiency stand-point (you can create large arrays of valid 
objects quite fast).


I mean, then again, @disable this() ...

Re: "Constructor" was a Very Bad name choice we have never recovered from (Was Re: D is dead)

[Guillaume Piolat via Digitalmars-d]

On Monday, 27 August 2018 at 03:06:17 UTC, John Carter wrote:


The last few years I have told myself (and anyone who doesn't 
back away fast enough) that "Constructors" do _not_ construct 
objects, they are "Name Binders." (Sort of like lisp's "let" 
macro)


They bind instance variable names to pre-existing sub-objects.


One could say there is "storage" and "instantiation" of an object.
C++ binds the two in the same operation.

D does not, T.init must be a valid object. This is a major 
cultural change, though I believe the D way is superior on the 
efficiency stand-point (you can create large arrays of valid 
objects quite fast).

Re: "Constructor" was a Very Bad name choice we have never recovered from (Was Re: D is dead)

[John Carter via Digitalmars-d]

Or to put it another way

RAII should be

"Taking Ownership of a Resource is Initialization, and 
relinquishing ownership is automatic at the object life time end, 
but Failure to Acquire a Resource Is Not An Exceptional 
Circumstance"


Not as catchy, but far less problematic.

"Constructor" was a Very Bad name choice we have never recovered from (Was Re: D is dead)

[John Carter via Digitalmars-d]

On Friday, 24 August 2018 at 02:33:31 UTC, Jonathan M Davis wrote:

Walter Bright wrote:
My personal opinion is that constructors that throw are an 
execrable programming practice, and I've wanted to ban them. 
(Andrei, while sympathetic to the idea, felt that too many 
people relied on it.) I won't allow throwing constructors in 
dmd or any software I have authority over.


Wow. I'm surprised by this.

I expect that you'd have a riot on your hands though if you 
actually tried to push for getting rid of throwing constructors.


A generation of programmers have been mislead down a deep rabbit 
hole thinking that "Constructors" are things that "Construct" 
objects.


This has to led to a generation of vaguely smelly code that "does 
too much work in the constructor" (of which throwing exceptions 
is evidence).


The last few years I have told myself (and anyone who doesn't 
back away fast enough) that "Constructors" do _not_ construct 
objects, they are "Name Binders." (Sort of like lisp's "let" 
macro)


They bind instance variable names to pre-existing sub-objects.

This attitude coupled with an a rule of thumb, "make it immutable 
unless I prove to myself that I _need_ it to be mutable" has led 
to a major improvement in my code.

[Issue 11810] std.stdio.byLine/readln performance is very bad

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=11810

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 11810] std.stdio.byLine/readln performance is very bad

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=11810

--- Comment #11 from Andrei Alexandrescu and...@erdani.com ---
http://forum.dlang.org/thread/melpfi$2scc$1...@digitalmars.com

--

[Issue 11810] std.stdio.byLine/readln performance is very bad

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=11810

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #10 from Andrei Alexandrescu and...@erdani.com ---
https://github.com/D-Programming-Language/phobos/pull/3089

--

[Issue 11810] std.stdio.byLine/readln performance is very bad

[d-bugmail]

https://issues.dlang.org/show_bug.cgi?id=11810

--- Comment #8 from Nick Treleaven ntrel-pub...@yahoo.co.uk ---
Here's as far as I got:
https://github.com/ntrel/phobos/commits/byLine-fast

This is faster than standard byLine on my Windows box iff std.utf.validate is
not called for each line. To be honest, I'm not sure whether std.stdio.readln
is doing UTF validation or not. readln has different implementations so
performance of standard byLine varies by platform.

I'm not sure whether this would be accepted as a PR. One issue is that when
using stdin you couldn't input just one line at a time anymore.

--

[Issue 11810] std.stdio.byLine/readln performance is very bad

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=11810


Nick Treleaven ntrel-pub...@yahoo.co.uk changed:

   What|Removed |Added

 CC||ntrel-pub...@yahoo.co.uk


--- Comment #7 from Nick Treleaven ntrel-pub...@yahoo.co.uk 2014-02-28 
08:55:17 PST ---
(In reply to comment #5)
 Created an attachment (id=1305) [details]
 byLineFast with small changes

BTW I'm working on porting this to std.stdio.byLine, I'll submit a PR when
finished.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 11810] std.stdio.byLine/readln performance is very bad

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=11810



--- Comment #6 from hst...@quickfur.ath.cx 2013-12-26 14:23:27 PST ---
The whole point of byLine is to be a convenient API for user code to read lines
from a file. It should not be constrained to using fgetc() just because we
can't predict line length in advance. It should be built on top of a buffering
mechanism (maybe byChunk) so that it offers good performance to a very
commonly-used user operation. I highly recommend Peter Alexander to submit the
improved byLine implementation to Phobos.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 11810] New: std.stdio.byLine/readln performance is very bad

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=11810

   Summary: std.stdio.byLine/readln performance is very bad
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: peter.alexander...@gmail.com


--- Comment #0 from Peter Alexander peter.alexander...@gmail.com 2013-12-24 
04:34:29 PST ---
std.stdio.readln (and hence byLine) use repeated calls to fgetc() to find the
new line characters. This is a very inefficient way to read files (lots of
per-byte overhead).

I have a version of byLine that reads the files in 4kb chunks and then does the
new line search. It is 6 times faster than byLine on my machine on a 10MB file
(OSX 10.8.5, x64 2GHz MacBook).

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 11810] std.stdio.byLine/readln performance is very bad

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=11810


Dejan Lekic dejan.le...@gmail.com changed:

   What|Removed |Added

 CC||dejan.le...@gmail.com


--- Comment #1 from Dejan Lekic dejan.le...@gmail.com 2013-12-24 04:42:03 PST 
---
It has been discussed on IRC hundreds of times and we all agreed that if
developer wants performance (s)he would read page-size chunks. That is why we
have byChunk(size_t) in std.stdio, I believe. :)

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 11810] std.stdio.byLine/readln performance is very bad

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=11810



--- Comment #2 from Peter Alexander peter.alexander...@gmail.com 2013-12-24 
05:27:14 PST ---
(In reply to comment #1)
 It has been discussed on IRC hundreds of times and we all agreed that if
 developer wants performance (s)he would read page-size chunks. That is why we
 have byChunk(size_t) in std.stdio, I believe. :)

OK, but:

1. It's non-trivial to implement byLine on top of byChunk.

2. Why would you want byLine to be slow? I'm not seeing the advantage of
keeping byLine as it is. Fixing it doesn't change the API and has no downsides
other than requiring a bit extra memory for the buffer.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 11810] std.stdio.byLine/readln performance is very bad

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=11810


bearophile_h...@eml.cc changed:

   What|Removed |Added

 CC||bearophile_h...@eml.cc


--- Comment #3 from bearophile_h...@eml.cc 2013-12-24 10:08:13 PST ---
(In reply to comment #1)
 It has been discussed on IRC hundreds of times and we all agreed that if
 developer wants performance (s)he would read page-size chunks. That is why we
 have byChunk(size_t) in std.stdio, I believe. :)

This is not acceptable. byLine is a very commonly used function (far more than
byChunk in script-like D programs) and it should be sufficiently fast.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 11810] std.stdio.byLine/readln performance is very bad

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=11810


Artem Tarasov lomerei...@gmail.com changed:

   What|Removed |Added

 CC||lomerei...@gmail.com


--- Comment #4 from Artem Tarasov lomerei...@gmail.com 2013-12-24 10:47:16 
PST ---
+1

There's also this implementation:
http://permalink.gmane.org/gmane.comp.lang.d.general/117750

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 11810] std.stdio.byLine/readln performance is very bad

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=11810



--- Comment #5 from bearophile_h...@eml.cc 2013-12-24 13:11:31 PST ---
Created an attachment (id=1305)
byLineFast with small changes

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

this is very bad

[JimB]

I am very bad because.. I'm not and I don't. It's very bad to be me. I 
haven't lived a day without someone I love very much... isn't that 
selfish.