On Tuesday, 3 July 2018 at 03:27:06 UTC, Ali wrote:
Well, D is not exactly known for contract oriented programming
or DbC (Design by Contract)
we have to thank Bertrand Meyer and his language Eiffel, for
that
Thanks for pointing this out !
His book "Object-Oriented Software Construction" is
On Thursday, 19 July 2018 at 09:44:16 UTC, Steven Schveighoffer
wrote:
On 7/18/18 1:58 AM, John Carter wrote:
With web services, most of the time the shared state you want
elsewhere anyway (to make it persistent), so it's a better fit
for processes than most program domains.
Sharing a
On 7/18/18 1:58 AM, John Carter wrote:
On Friday, 13 July 2018 at 13:15:39 UTC, Steven Schveighoffer wrote:
But it doesn't scale if you use OS processes, it's too heavyweight. Of
course, it depends on the application. If you only need 100 concurrent
connections, processes might be OK.
I
On Friday, 13 July 2018 at 13:15:39 UTC, Steven Schveighoffer
wrote:
But it doesn't scale if you use OS processes, it's too
heavyweight. Of course, it depends on the application. If you
only need 100 concurrent connections, processes might be OK.
I think you may have fallen for Microsoft
On Friday, 13 July 2018 at 12:55:33 UTC, Adam D. Ruppe wrote:
You use process isolation so it is easy to restart part of it
without disrupting others. Then it can crash without bringing
the system down. This is doable with segfaults and range
errors, same as with exceptions.
This is one of
On Wednesday, 11 July 2018 at 22:35:06 UTC, crimaniak wrote:
The people who developed Erlang definitely have a lot of
experience developing services.
Yes, it was created for telephone-centrals. You don't want a
phone central to go completely dead just because there is a bug
in the code. That
On 7/13/18 4:47 PM, Patrick Schluter wrote:
On Friday, 13 July 2018 at 20:12:36 UTC, Steven Schveighoffer wrote:
On 7/13/18 3:53 PM, Paolo Invernizzi wrote:
On Friday, 13 July 2018 at 13:15:39 UTC, Steven Schveighoffer wrote:
On 7/13/18 8:55 AM, Adam D. Ruppe wrote:
[...]
But it doesn't
On Friday, 13 July 2018 at 20:12:36 UTC, Steven Schveighoffer
wrote:
On 7/13/18 3:53 PM, Paolo Invernizzi wrote:
On Friday, 13 July 2018 at 13:15:39 UTC, Steven Schveighoffer
wrote:
On 7/13/18 8:55 AM, Adam D. Ruppe wrote:
[...]
But it doesn't scale if you use OS processes, it's too
On 7/13/18 3:53 PM, Paolo Invernizzi wrote:
On Friday, 13 July 2018 at 13:15:39 UTC, Steven Schveighoffer wrote:
On 7/13/18 8:55 AM, Adam D. Ruppe wrote:
On Wednesday, 11 July 2018 at 12:45:40 UTC, crimaniak wrote:
This error handling policy makes D not applicable for creating WEB
On Friday, 13 July 2018 at 13:15:39 UTC, Steven Schveighoffer
wrote:
On 7/13/18 8:55 AM, Adam D. Ruppe wrote:
On Wednesday, 11 July 2018 at 12:45:40 UTC, crimaniak wrote:
This error handling policy makes D not applicable for
creating WEB applications and generally long-running services.
You
On 7/13/18 8:55 AM, Adam D. Ruppe wrote:
On Wednesday, 11 July 2018 at 12:45:40 UTC, crimaniak wrote:
This error handling policy makes D not applicable for creating WEB
applications and generally long-running services.
You use process isolation so it is easy to restart part of it without
On Wednesday, 11 July 2018 at 12:45:40 UTC, crimaniak wrote:
This error handling policy makes D not applicable for creating
WEB applications and generally long-running services.
You use process isolation so it is easy to restart part of it
without disrupting others. Then it can crash without
On 7/10/18 6:59 PM, Jonathan M Davis wrote:
On Tuesday, 10 July 2018 16:48:41 MDT Steven Schveighoffer via Digitalmars-d
wrote:
On 7/10/18 6:26 PM, Jonathan M Davis wrote:
On Tuesday, 10 July 2018 13:21:28 MDT Timon Gehr via Digitalmars-d
wrote:
On 03.07.2018 06:54, Walter Bright wrote:
...
On Wednesday, 11 July 2018 23:39:49 MDT Walter Bright via Digitalmars-d
wrote:
> On 7/11/2018 6:54 PM, Brad Roberts wrote:
> > Anyway, this is one of the areas where people clearly have different
> > philosophies and changing minds is unlikely to happen.
>
> True, but that doesn't mean each
On 7/11/2018 4:56 PM, John Carter wrote:
I disagree with Bjarne Stroustrup on many things but in this article he is
absolutely spot on. https://www.artima.com/intv/goldilocks3.html
It's a great article, and a quick read.
On 7/11/2018 11:27 AM, Brad Roberts wrote:
When you're afraid of your software and afraid to make changes to it, you make
bad choices. Embrace every strategy you can find to help you find problems as
quickly as possible.
It's good to hear my opinions on the subject backed by major
On 7/11/2018 6:54 PM, Brad Roberts wrote:
Anyway, this is one of the areas where people clearly have different
philosophies and changing minds is unlikely to happen.
True, but that doesn't mean each philosophy is equally valid. Some ideas are
better than others :-)
BTW, the "fail fast with
On 7/11/2018 3:24 PM, crimaniak via Digitalmars-d wrote:
On Wednesday, 11 July 2018 at 18:27:33 UTC, Brad Roberts wrote:
... application exiting asserts in production. Yes, you kill the
app. You exit as fast and often as the errors occur. You know what
happens? You find the bugs faster,
On Wednesday, 11 July 2018 at 12:45:40 UTC, crimaniak wrote:
The error should be maximally localized, and the programmer
should be able to respond to any type of errors. The very
nature of the work of WEB applications contributes to this. As
a rule, queries are handled by short-lived tasks
On Wednesday, 11 July 2018 at 13:19:01 UTC, Joakim wrote:
...
Sounds like you're describing the "Let it crash" philosophy of
Erlang:
https://ferd.ca/the-zen-of-erlang.html
I never program Erlang, but I think yes, something like this.
The people who developed Erlang definitely have a lot of
On Wednesday, 11 July 2018 at 18:27:33 UTC, Brad Roberts wrote:
... application exiting asserts in production. Yes, you kill
the app. You exit as fast and often as the errors occur. You
know what happens? You find the bugs faster, you fix them even
faster, and the result is solid
On 7/11/2018 5:45 AM, crimaniak via Digitalmars-d wrote:
On Tuesday, 10 July 2018 at 22:59:08 UTC, Jonathan M Davis wrote:
Or aside from that strawman that RangeError shouldn't be an Error
even...
I suspect that we're going to have to agree to disagree on that one. ...
...
continuing to
On Wednesday, 11 July 2018 at 16:17:30 UTC, Jacob Carlborg wrote:
The boot time of my computer was reduced from several minutes
to around 30 seconds when I switch to SSD disks.
My NVMe ssd is very fast.
On 2018-07-11 03:50, Walter Bright wrote:
On 7/10/2018 8:39 AM, H. S. Teoh wrote:
The saving grace to real mode DOS was that rebooting was so fast.
I beg to differ. Boot time has been about the same for the last 40 years
:-)
The boot time of my computer was reduced from several minutes to
On Wednesday, 11 July 2018 at 12:45:40 UTC, crimaniak wrote:
On Tuesday, 10 July 2018 at 22:59:08 UTC, Jonathan M Davis
wrote:
Or aside from that strawman that RangeError shouldn't be an
Error even...
I suspect that we're going to have to agree to disagree on
that one. ...
...
continuing
On Tuesday, 10 July 2018 at 22:59:08 UTC, Jonathan M Davis wrote:
Or aside from that strawman that RangeError shouldn't be an
Error even...
I suspect that we're going to have to agree to disagree on that
one. ...
...
continuing to execute the program is risky by definition. ...
This error
On 7/10/2018 12:21 PM, Timon Gehr wrote:
Which threads are those?
Here's one:
https://digitalmars.com/d/archives/digitalmars/D/Program_logic_bugs_vs_input_environmental_errors_244143.html
Have fun, it may take upwards of a week to read that one!
On 7/10/2018 8:39 AM, H. S. Teoh wrote:
The saving grace to real mode DOS was that rebooting was so fast.
I beg to differ. Boot time has been about the same for the last 40 years :-)
On 7/10/2018 12:21 PM, Timon Gehr wrote:
On 03.07.2018 06:54, Walter Bright wrote:
(I'm referring to the repeated and endless threads here where people argue
that yes, they can recover from programming bugs!)
Which threads are those?
I'd have to google for them. Maybe try searching for
On Tuesday, 10 July 2018 16:48:41 MDT Steven Schveighoffer via Digitalmars-d
wrote:
> On 7/10/18 6:26 PM, Jonathan M Davis wrote:
> > On Tuesday, 10 July 2018 13:21:28 MDT Timon Gehr via Digitalmars-d
wrote:
> >> On 03.07.2018 06:54, Walter Bright wrote:
> >>> ...
> >>>
> >>> (I'm referring to
On 7/10/18 6:26 PM, Jonathan M Davis wrote:
On Tuesday, 10 July 2018 13:21:28 MDT Timon Gehr via Digitalmars-d wrote:
On 03.07.2018 06:54, Walter Bright wrote:
...
(I'm referring to the repeated and endless threads here where people
argue that yes, they can recover from programming bugs!)
On Tuesday, 10 July 2018 13:21:28 MDT Timon Gehr via Digitalmars-d wrote:
> On 03.07.2018 06:54, Walter Bright wrote:
> > ...
> >
> > (I'm referring to the repeated and endless threads here where people
> > argue that yes, they can recover from programming bugs!)
>
> Which threads are those?
On 03.07.2018 06:54, Walter Bright wrote:
...
(I'm referring to the repeated and endless threads here where people
argue that yes, they can recover from programming bugs!)
Which threads are those?
On Mon, Jul 09, 2018 at 11:37:59PM -0700, Walter Bright via Digitalmars-d wrote:
> On 7/9/2018 6:50 PM, John Carter wrote:
> > Nothing creates flaky and unreliable systems more than allowing them
> > to wobble on past the first point where you already know that things
> > are wrong.
>
> Things
On Sunday, 8 July 2018 at 20:55:15 UTC, John Carter wrote:
On Saturday, 7 July 2018 at 01:18:21 UTC, wjoe wrote:
But that's not how D works. It throws an Error which can be
caught.
If people are allowed to do something they assume it's
legitimate.
It should be a compile time error to catch
On 7/9/2018 6:50 PM, John Carter wrote:
Nothing creates flaky and unreliable systems more than allowing them to wobble
on past the first point where you already know that things are wrong.
Things got so bad with real mode DOS development that I rebooted the system
every time my program
On Monday, 9 July 2018 at 22:50:07 UTC, Mr.Bingo wrote:
On Tuesday, 3 July 2018 at 04:54:46 UTC, Walter Bright wrote:
On 7/2/2018 7:53 PM, John Carter wrote:
Step 2 is to (gradually) migrate std:: standard library
precondition violations in particular from exceptions (or
error codes) to
On Tuesday, 3 July 2018 at 04:54:46 UTC, Walter Bright wrote:
On 7/2/2018 7:53 PM, John Carter wrote:
Step 2 is to (gradually) migrate std:: standard library
precondition violations in particular from exceptions (or
error codes) to contracts. The programming world now broadly
recognizes that
On 2018-07-08 22:55, John Carter wrote:
On Saturday, 7 July 2018 at 01:18:21 UTC, wjoe wrote:
But that's not how D works. It throws an Error which can be caught.
If people are allowed to do something they assume it's legitimate.
It should be a compile time error to catch an Error, but it
On Sunday, 8 July 2018 14:55:15 MDT John Carter via Digitalmars-d wrote:
> On Saturday, 7 July 2018 at 01:18:21 UTC, wjoe wrote:
> > But that's not how D works. It throws an Error which can be
> > caught.
> >
> > If people are allowed to do something they assume it's
> > legitimate.
> >
> > It
On Saturday, 7 July 2018 at 01:18:21 UTC, wjoe wrote:
But that's not how D works. It throws an Error which can be
caught.
If people are allowed to do something they assume it's
legitimate.
It should be a compile time error to catch an Error, but it
doesn't even emit a warning and it seems
On Tuesday, 3 July 2018 at 04:54:46 UTC, Walter Bright wrote:
On 7/2/2018 7:53 PM, John Carter wrote:
Step 2 is to (gradually) migrate std:: standard library
precondition violations in particular from exceptions (or
error codes) to contracts. The programming world now broadly
recognizes that
On 7/6/18 4:21 AM, Walter Bright wrote:
On 7/5/2018 3:26 PM, H. S. Teoh wrote:
people keep tripping over the terminology
Some people do. However, the long threads of debate on this topic was
with people who were clear on what the terminology meant.
My question has never been the difference
On 7/5/2018 3:26 PM, H. S. Teoh wrote:
people keep tripping over the terminology
Some people do. However, the long threads of debate on this topic was with
people who were clear on what the terminology meant.
On Thu, Jul 05, 2018 at 10:05:44PM +, John Carter via Digitalmars-d wrote:
[...]
> At work here I have emerged from a long, dark, debate on the subject
> within the team.
>
> The ultimately solution was to realize there are actually TWO
> facilities with TWO entirely different purposes that
On Tuesday, 3 July 2018 at 04:54:46 UTC, Walter Bright wrote:
On 7/2/2018 7:53 PM, John Carter wrote:
In general all pre/post/assert-condition violations) cause a
corrupted state that cannot be recovered from
programmatically, and so they should never be reported to the
calling code as
On Tuesday, 3 July 2018 at 04:54:46 UTC, Walter Bright wrote:
So, I have finally convinced the C++ world about that! Now if I
can only convince the D world :-)
(I'm referring to the repeated and endless threads here where
people argue that yes, they can recover from programming bugs!)
It
On 7/2/2018 7:53 PM, John Carter wrote:
Step 2 is to (gradually) migrate std:: standard library precondition
violations in particular from exceptions (or error codes) to contracts. The
programming world now broadly recognizes that programming bugs (e.g.,
out-of-bounds access, null dereference,
On Tuesday, 3 July 2018 at 03:27:06 UTC, Ali wrote:
we have to thank Bertrand Meyer and his language Eiffel, for
that
True.
I was referring to the ideas in Walter's proposal
https://forum.dlang.org/thread/lrbpvj$mih$1...@digitalmars.com
Well, D is not exactly known for contract oriented programming or
DbC (Design by Contract)
we have to thank Bertrand Meyer and his language Eiffel, for that
https://herbsutter.com/2018/07/02/trip-report-summer-iso-c-standards-meeting-rapperswil/
This looks to me like a huge step forward for C++
* You get to install your own violation handler and ship a
release build with the option of turning on enforcement at run
time.
* You get to express
51 matches
Mail list logo
