On 2014-02-27 21:43, Walter Bright wrote:
This comes up now and then. The problem with it is it makes function
overloading a near impossibility to untangle.
We could quite easy add support for named parameters but still require
using the same position of the arguments. I don't know if those
Jacob Carlborg:
We could quite easy add support for named parameters but still
require using the same position of the arguments. I don't know
if those wanting named parameters would be satisfied with this
though.
I think requiring the same position of the arguments goes against
one of the
On 2014-03-01 15:19:29 +, Jacob Carlborg d...@me.com said:
On 2014-02-27 21:43, Walter Bright wrote:
This comes up now and then. The problem with it is it makes function
overloading a near impossibility to untangle.
We could quite easy add support for named parameters but still require
On Friday, 28 February 2014 at 12:12:38 UTC, bearophile wrote:
Chris:
Every time I write something in JS, I feel like a complete
programming novice,
Probably that's part of the problem. More experience in a
language helps.
I suggest to use TypeScript (http://www.typescriptlang.org/ ),
On 2014-03-01 17:19, Michel Fortin wrote:
I did implement something like that in DMD a while ago as an experiment.
See the comments below that commit:
https://github.com/michelf/dmd/commit/673bae4982ff18a3d216bc1578f50d40f4d26d7a
I based the quite easy on the few changes needed in your
On Saturday, 1 March 2014 at 16:37:36 UTC, Asman01 wrote:
On Friday, 28 February 2014 at 12:12:38 UTC, bearophile wrote:
Chris:
Every time I write something in JS, I feel like a complete
programming novice,
Probably that's part of the problem. More experience in a
language helps.
I
On Saturday, 1 March 2014 at 18:57:03 UTC, Craig Dillabaugh wrote:
On Saturday, 1 March 2014 at 16:37:36 UTC, Asman01 wrote:
On Friday, 28 February 2014 at 12:12:38 UTC, bearophile wrote:
Chris:
Every time I write something in JS, I feel like a complete
programming novice,
Probably that's
On Thursday, 27 February 2014 at 19:54:04 UTC, w0rp wrote:
On Thursday, 27 February 2014 at 18:37:51 UTC, Craig Dillabaugh
wrote:
On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto
wrote:
clip
Like it or not, JavaScript is good enough.
Really? I've been stuck for the past week or
On Friday, 28 February 2014 at 11:21:51 UTC, Chris wrote:
On Thursday, 27 February 2014 at 19:54:04 UTC, w0rp wrote:
On Thursday, 27 February 2014 at 18:37:51 UTC, Craig
Dillabaugh wrote:
On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto
wrote:
clip
Like it or not, JavaScript is
On Thursday, 27 February 2014 at 17:16:54 UTC, Paulo Pinto wrote:
Yep, that is how for example .NET, Eiffel, Smalltalk, Lisp and
many other languages work.
An object in Smalltalk is not a primitive type. Even ints,
floats, chars, etc. in Smalltalk are no primitive types but
objects. Not
Chris:
Every time I write something in JS, I feel like a complete
programming novice,
Probably that's part of the problem. More experience in a
language helps.
I suggest to use TypeScript (http://www.typescriptlang.org/ ), it
has static types, more Java-style classes, better modules,
On Friday, 28 February 2014 at 12:12:38 UTC, bearophile wrote:
Chris:
Every time I write something in JS, I feel like a complete
programming novice,
Probably that's part of the problem. More experience in a
language helps.
Unfortunately, you cannot get experienced in JS, there's always
On Friday, 28 February 2014 at 12:12:38 UTC, bearophile wrote:
Chris:
Every time I write something in JS, I feel like a complete
programming novice,
Probably that's part of the problem. More experience in a
language helps.
I suggest to use TypeScript (http://www.typescriptlang.org/ ),
Am 28.02.2014 13:15, schrieb Bienlein:
On Thursday, 27 February 2014 at 17:16:54 UTC, Paulo Pinto wrote:
Yep, that is how for example .NET, Eiffel, Smalltalk, Lisp and many
other languages work.
An object in Smalltalk is not a primitive type. Even ints, floats,
chars, etc. in Smalltalk are no
A1)
Google's Dart (https://www.dartlang.org) looks like a very promising
replacement for javascript. It can compile to javascript to ensure
portability (but chromium runs it natively) but the language itself reminds
more of D to a surprising extent. Dart language has features such as:
static
What needed to create language that can be run everywhere? I mean
would it be hard to add support of running D code in web-browser?
it's better to write all logic at one language, that on 2 or 3.
Timothee Cour:
* better way to define default constructors:
class Point {
num x;
num y;
num z;
// Syntactic sugar for setting z and x before the constructor
body runs.
Point(this.z, this.x){...}
}
This is more explicit and flexible than D's way for default
struct
constructors,
I don't like any of the syntax changes mentioned. I do like the
suggestions for better IDEs and similar tools. We can always do
more to improve these.
On Thursday, 27 February 2014 at 10:27:41 UTC, Timothee Cour
wrote:
A1)
Google's Dart (https://www.dartlang.org) looks like a very
promising
replacement for javascript. It can compile to javascript to
ensure
portability (but chromium runs it natively) but the language
itself reminds
more of D
On 2/27/14, 7:19 AM, Timothee Cour wrote:
And then some design decisions which wouldn't work for D: everything is
an object, no struct (just class), VM, etc.
In a programming language you can make everything look like an object
but implement it as a primitive type. So that could work in D
Am 27.02.2014 17:48, schrieb Ary Borenszweig:
On 2/27/14, 7:19 AM, Timothee Cour wrote:
And then some design decisions which wouldn't work for D: everything is
an object, no struct (just class), VM, etc.
In a programming language you can make everything look like an object
but implement it as
On Thursday, 27 February 2014 at 10:27:41 UTC, Timothee Cour
wrote:
A1)
Google's Dart (https://www.dartlang.org) looks like a very
promising
replacement for javascript. It can compile to javascript to
ensure
portability (but chromium runs it natively)
No, neither Chromium nor even Chrome
Am 27.02.2014 18:29, schrieb thedeemon:
On Thursday, 27 February 2014 at 10:27:41 UTC, Timothee Cour wrote:
A1)
Google's Dart (https://www.dartlang.org) looks like a very promising
replacement for javascript. It can compile to javascript to ensure
portability (but chromium runs it natively)
On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto wrote:
clip
Like it or not, JavaScript is good enough.
Really? I've been stuck for the past week or so trying to put
together a browser based UI using JavaScript + HTML for a work
related project. It has been a painful experience.
On Thursday, 27 February 2014 at 18:37:51 UTC, Craig Dillabaugh
wrote:
On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto
wrote:
clip
Like it or not, JavaScript is good enough.
Really? I've been stuck for the past week or so trying to put
together a browser based UI using
On Thursday, 27 February 2014 at 19:54:04 UTC, w0rp wrote:
On Thursday, 27 February 2014 at 18:37:51 UTC, Craig Dillabaugh
wrote:
On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto
wrote:
clip
Like it or not, JavaScript is good enough.
Really? I've been stuck for the past week or
On 27.2.2014 20:54, w0rp wrote:
I developed 99% of the JavaScript part of an application for a year, and
I have extensive JavaScript knowledge. After all that, I wrote this.
https://w0rp.com/blog/post/javascript-sucks/
I think it was someone on Slashdot who posted this wonderful comment:
Am 27.02.2014 19:37, schrieb Craig Dillabaugh:
On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto wrote:
clip
Like it or not, JavaScript is good enough.
Really? I've been stuck for the past week or so trying to put together a
browser based UI using JavaScript + HTML for a work
On 2/27/2014 2:19 AM, Timothee Cour wrote:
* optional named parameters arguments (with simplest possible syntax)
This comes up now and then. The problem with it is it makes function overloading
a near impossibility to untangle.
On 2/27/2014 2:19 AM, Timothee Cour wrote:
* import all except specified symbols:
import 'package:lib2/lib2.dart' hide foo; // Import all names EXCEPT foo.
As a general rule, negation features are frequently misunderstood, our brains
tend to just not see the negation. One should positively
On 2/27/2014 2:19 AM, Timothee Cour wrote:
* cascade operations: they perform a series of operations on the members of a
single object:
foo.bar(1)..baz(3)
equivalent to:
foo.bar(1)
foo.baz(3)
D has ranges and algorithms to conveniently chain operations.
* better way to define default
Walter Bright:
* optional named parameters arguments (with simplest possible
syntax)
This comes up now and then. The problem with it is it makes
function overloading a near impossibility to untangle.
Do you have an example of the problem?
* better way to define default constructors:
class
On Thu, Feb 27, 2014 at 12:56 PM, Walter Bright
newshou...@digitalmars.comwrote:
On 2/27/2014 2:19 AM, Timothee Cour wrote:
* cascade operations: they perform a series of operations on the members
of a
single object:
foo.bar(1)..baz(3)
equivalent to:
foo.bar(1)
foo.baz(3)
D has ranges
* better syntax for optional positional arguments:
void fun(int x, [int y, int z=3]){...}
Thinking of which, this would actually solve a long standing problem in
D, that
of specifying optional parameters AFTER a variadic template:
void fun(T...)(T args, [string file=__FILE__,int
On Thu, Feb 27, 2014 at 2:40 PM, bearophile bearophileh...@lycos.comwrote:
Walter Bright:
* optional named parameters arguments (with simplest possible syntax)
This comes up now and then. The problem with it is it makes function
overloading a near impossibility to untangle.
Do you have
We could kinda do named parameters today like this:
ParameterTypeTuple!foo args;
args.named_param = 3;
foo(args);
It would be nice if we could declare a variable inside a
with(auto x = foo) like we can in if() too.
* better way to define default constructors:
class Point {
num x;
num y;
num z;
// Syntactic sugar for setting z and x before the constructor body
runs.
Point(this.z, this.x){...}
}
This is more explicit and flexible than D's way for default struct
constructors,
On Thu, 2014-02-27 at 19:20 +0100, Paulo Pinto wrote:
[…]
From what I understood on Dart talks last Google IO, work was planned
to have V8 and Dart VM play together inside Chrome.
Dartium is a build of Chromium with both, so this is very much the
direction that is possible.
Personally, I
On 14/08/12 05:03, TJB wrote:
On Monday, 13 August 2012 at 10:11:06 UTC, Don Clugston wrote:
... I have come to believe that there are very few algorithms
originally designed for integers, which also work correctly for
floating point.
Integer code nearly always assumes things like, x + 1 !=
On Saturday, 11 August 2012 at 05:41:23 UTC, Walter Bright wrote:
On 8/10/2012 9:55 PM, F i L wrote:
On the first condition, without an 'else z = ...', or if the
condition was removed at a later time, then you'll get a
compiler error and be forced to explicitly assign 'z'
somewhere above
On Tuesday, 14 August 2012 at 10:31:30 UTC, Mehrdad wrote:
Note to Walter:
You're obviously correct that you can make an arbitrarily
complex program to make it too difficult for the compiler to
enforce initialization, the way C# does (and gives up in some
cases).
What you seem to be
On 14/08/12 12:31, Mehrdad wrote:
On Saturday, 11 August 2012 at 05:41:23 UTC, Walter Bright wrote:
On 8/10/2012 9:55 PM, F i L wrote:
On the first condition, without an 'else z = ...', or if the
condition was removed at a later time, then you'll get a compiler
error and be forced to
Mehrdad wrote:
Note to Walter:
You're obviously correct that you can make an arbitrarily
complex program to make it too difficult for the compiler to
enforce initialization, the way C# does (and gives up in some
cases).
[ ... ]
I think some here are mis-interpreting Walters position
On Tue, 14 Aug 2012 16:32:25 +0200, F i L witte2...@gmail.com wrote:
class Foo
{
float x; // I think this should be 0.0f
// Walter thinks it should be NaN
}
In this situation static analysis can't help catch issues, and we're
forced to rely on a default value
On Tuesday, 14 August 2012 at 14:46:30 UTC, Simen Kjaeraas wrote:
On Tue, 14 Aug 2012 16:32:25 +0200, F i L witte2...@gmail.com
wrote:
class Foo
{
float x; // I think this should be 0.0f
// Walter thinks it should be NaN
}
In this situation static analysis can't
On Tuesday, 14 August 2012 at 15:24:30 UTC, F i L wrote:
Really? We can catch (or, should be able to) missing
initialization of stuff with @disable this(), but not floats?
Classes have constructors, which lend themselves perfectly to
doing exactly this (just pretend the member is a local
On Tuesday, 14 August 2012 at 15:24:30 UTC, F i L wrote:
On Tuesday, 14 August 2012 at 14:46:30 UTC, Simen Kjaeraas
wrote:
On Tue, 14 Aug 2012 16:32:25 +0200, F i L
witte2...@gmail.com wrote:
class Foo
{
float x; // I think this should be 0.0f
// Walter thinks it should
On Tuesday, 14 August 2012 at 14:32:26 UTC, F i L wrote:
Mehrdad wrote:
Note to Walter:
You're obviously correct that you can make an arbitrarily
complex program to make it too difficult for the compiler to
enforce initialization, the way C# does (and gives up in some
cases).
[ ... ]
I
On 8/14/2012 3:31 AM, Mehrdad wrote:
Then you get the best of both worlds:
1. You force the programmer to manually initialize the variable in most cases,
forcing him to think about the default value. It's almost no trouble for
2. In the cases where it's not possible, the language helps the
On Tuesday, 14 August 2012 at 21:22:14 UTC, Mehrdad wrote:
C# and Java don't.
Typo, scratch Java, it's N/A for Java.
On Tuesday, 14 August 2012 at 21:13:01 UTC, Walter Bright wrote:
On 8/14/2012 3:31 AM, Mehrdad wrote:
Then you get the best of both worlds:
1. You force the programmer to manually initialize the
variable in most cases,
forcing him to think about the default value. It's almost no
trouble for
On 8/14/2012 2:22 PM, Mehrdad wrote:
I was talking about definite assignment, i.e. the _lack_ of automatic
initialization.
I know. How does that fit in with default construction?
On Tuesday, 14 August 2012 at 21:58:20 UTC, Walter Bright wrote:
On 8/14/2012 2:22 PM, Mehrdad wrote:
I was talking about definite assignment, i.e. the _lack_ of
automatic initialization.
I know. How does that fit in with default construction?
They aren't called unless the user calls them.
On Tuesday, 14 August 2012 at 22:57:26 UTC, Mehrdad wrote:
Bar(initialized); // error
Bar(uninitialized); // OK
Er, other way around I mean...
On 8/14/2012 3:57 PM, Mehrdad wrote:
I know. How does that fit in with default construction?
They aren't called unless the user calls them.
I guess they aren't really default constructors, then g.
So what happens when you allocate an array of them?
D could take a similar approach.
It
On Wednesday, 15 August 2012 at 00:32:43 UTC, Walter Bright wrote:
On 8/14/2012 3:57 PM, Mehrdad wrote:
I guess they aren't really default constructors, then g.
I say potayto, you say potahto... :P
So what happens when you allocate an array of them?
For arrays, they're called
On 12/08/12 01:31, Walter Bright wrote:
On 8/11/2012 3:01 PM, F i L wrote:
Walter Bright wrote:
I'd rather have a 100 easy to find bugs than 1 unnoticed one that
went out in
the field.
That's just the thing, bugs are arguably easier to hunt down when
things default
to a consistent, usable
On 13/08/12 11:11, Don Clugston wrote:
Exactly. I have come to believe that there are very few algorithms originally
designed for integers, which also work correctly for floating point.
import std.stdio;
void main()
{
real x = 1.0/9.0;
Don Clugston:
I have come to believe that there are very few algorithms
originally designed for integers, which also work correctly for
floating point.
And JavaScript programs that use integers?
Bye,
bearophile
On 8/13/2012 5:38 AM, Joseph Rushton Wakeling wrote:
Looks like some sort of cheat in place to
make sure that the successive division and multiplication will revert to the
original number.
That's called rounding. But rounding always implies some, small, error that
can accumulate into being a
On 8/12/2012 6:38 PM, F i L wrote:
Also, and I'm not sure this isn't just me, but I ran a DMD (v2.057 T think)
vector test (no simd) against Mono C# a few moths back where DMD got only ~10 ms
improvement over C# (~79ms vs ~88ms). Now a similar test compiled with DMD 2.060
runs at ~22ms vs C#'s
On 13/08/12 20:04, Walter Bright wrote:
That's called rounding. But rounding always implies some, small, error that
can accumulate into being a very large error.
Well, yes. I was just remarking on the choice of rounding and the motivation
behind it.
After all, you _could_ round it instead
On Monday, 13 August 2012 at 10:11:06 UTC, Don Clugston wrote:
... I have come to believe that there are very few algorithms
originally designed for integers, which also work correctly for
floating point.
Integer code nearly always assumes things like, x + 1 != x, x
== x,
(x + y) - y ==
Am 12.08.2012 02:43, schrieb F i L:
Yes, and this is an excellent argument for using NaN as a
debugging practice in general, but I don't see anything in favor
of defaulting to NaN. If you don't do some kind of check against
code, especially with such large data sets, bugs of various kinds
are
On 8/11/2012 7:30 AM, Jakob Ovrum wrote:
On Saturday, 11 August 2012 at 09:40:39 UTC, Walter Bright wrote:
Of course it is doing what the language requires, but it is an incorrect
diagnostic because a dead assignment is required.
And being a dead assignment, it can lead to errors when the code
On Sun, 12 Aug 2012 12:38:47 +0200, Walter Bright
newshou...@digitalmars.com wrote:
On 8/11/2012 7:30 AM, Jakob Ovrum wrote:
On Saturday, 11 August 2012 at 09:40:39 UTC, Walter Bright wrote:
Consider `pure` member functions - turns out most of them are actually
pure
because the implicit
Am 12.08.2012 12:38, schrieb Walter Bright:
On 8/11/2012 7:30 AM, Jakob Ovrum wrote:
Consider `pure` member functions - turns out most of them are actually pure
because the implicit `this` parameter is allowed to be mutated and it's rare for
a member function to mutate global state, yet we all
On Sunday, 12 August 2012 at 11:34:20 UTC, dennis luehring wrote:
Am 12.08.2012 12:38, schrieb Walter Bright:
A better design would be to have pure be the default and
impure would require annotation. The same for const/immutable.
Unfortunately, it's too late for that now. My fault.
its never
On 8/12/12 12:52 AM, TJB wrote:
Thanks for bringing this back to the original topic and for your thoughts.
Indeed, a lot of econometricians are using MATLAB, R, Guass, Ox and the
like. But there are a number of econometricians who need the raw power
of a natively compiled language (especially
On Sunday, 12 August 2012 at 10:39:01 UTC, Walter Bright wrote:
No, it is not easier to understand, because there's no way to
determine if the intent is to:
1. initialize to a valid value -or-
2. initialize to get the compiler to stop complaining
If there is an explicit initializer, it
Andrei Alexandrescu:
(I recall hearing complaints about large overheads in Matlab
caused by eager copy semantics, is that true?)
In Matlab there is COW:
http://www.matlabtips.com/copy-on-write-in-subfunctions/
Bye,
bearophile
On Sunday, 12 August 2012 at 03:30:24 UTC, bearophile wrote:
Andrei Alexandrescu:
- The language's superior modeling power and level of control
comes at an increase in complexity compared to languages such
as e.g. Python. So the statistician would need a larger
upfront investment in order to
On Sunday, 12 August 2012 at 17:22:21 UTC, dsimcha wrote:
... I find Matlab and R incredibly frustrating to use for
anything but very standard matrix/statistics computations on
data that's already structured the way I like it.
This is exactly how I feel, and why I am turning to D. My data
On Sun, 12 Aug 2012 03:38:47 -0700, Walter Bright
newshou...@digitalmars.com wrote:
On 8/11/2012 7:30 AM, Jakob Ovrum wrote:
On Saturday, 11 August 2012 at 09:40:39 UTC, Walter Bright wrote:
Of course it is doing what the language requires, but it is an
incorrect
diagnostic because a dead
Andrei Alexandrescu wrote:
* Efficiency - D generates native code for floating point
operations and has control over data layout and allocation.
Speed of generated code is dependent on the compiler, and the
reference compiler (dmd) does a poorer job at it than the
gnu-based compiler (gdc)
On 12/08/12 18:22, dsimcha wrote:
For people with more advanced CS/programming knowledge, though, this is an
advantage of D. I find Matlab and R incredibly frustrating to use for anything
but very standard matrix/statistics computations on data that's already
structured the way I like it. This
On Monday, 13 August 2012 at 01:52:28 UTC, Joseph Rushton
Wakeling wrote:
The main use-case and advantage of both R and MATLAB/Octave
seems to me to be the plotting functionality -- I've seen some
exceptionally beautiful stuff done with R in particular,
although I've not personally explored
On 8/10/2012 9:55 PM, F i L wrote:
On the first condition, without an 'else z = ...', or if the condition was
removed at a later time, then you'll get a compiler error and be forced to
explicitly assign 'z' somewhere above using it. So C# and D work in similar
ways in this respect except that C#
Walter Bright wrote:
That is a good solution, but in my experience programmers just
throw in an =0, as it is simple and fast, and they don't
normally think about NaN's.
See! Programmers just want usable default values :-P
It's too bad that ints don't have a NaN value, but
interestingly
On Saturday, 11 August 2012 at 04:33:38 UTC, Walter Bright wrote:
It's too bad that ints don't have a NaN value, but
interestingly enough, valgrind does default initialize them to
some internal NaN, making it a most excellent bug detector.
The compiler could always have flags specifying if
On 8/11/2012 1:30 AM, Era Scarecrow wrote:
On Saturday, 11 August 2012 at 04:33:38 UTC, Walter Bright wrote:
It's too bad that ints don't have a NaN value, but interestingly enough,
valgrind does default initialize them to some internal NaN, making it a most
excellent bug detector.
The
On 8/11/2012 1:57 AM, Jakob Ovrum wrote:
The compiler in languages like C# doesn't try to prove that the variable is NOT
set and then emits an error. It tries to prove that the variable IS set, and if
it can't prove that, it's an error.
It's not an incorrect diagnostic, it does exactly what
On Saturday, 11 August 2012 at 09:40:39 UTC, Walter Bright wrote:
On 8/11/2012 1:57 AM, Jakob Ovrum wrote:
Because experience shows that even the yellers tend to do the
short, convenient one rather than the longer, correct one.
Bruce Eckel wrote an article about this years ago in reference
to
On Saturday, 11 August 2012 at 09:26:42 UTC, Walter Bright wrote:
On 8/11/2012 1:30 AM, Era Scarecrow wrote:
The compiler could always have flags specifying if variables
were used, and if they are false they are as good as NaN. Only
downside is a performance hit unless you Mark it as a
On Friday, 10 August 2012 at 22:01:46 UTC, Walter Bright wrote:
It catches only a subset of these at compile time. I can craft
any number of ways of getting it to miss diagnosing it.
Consider this one:
float z;
if (condition1)
z = 5;
... lotsa code ...
if (condition2)
On Saturday, 11 August 2012 at 09:40:39 UTC, Walter Bright wrote:
Of course it is doing what the language requires, but it is an
incorrect diagnostic because a dead assignment is required.
And being a dead assignment, it can lead to errors when the
code is later modified, as I explained. I
Andrei Alexandrescu wrote:
[ ... ]
Although this case is not about default values but about the
result of a computation (in this case 0.0/0.0), I think it
still reveals the usefulness of having a singular value in the
floating point realm.
My argument was never against the usefulness of
On 8/11/2012 12:33 PM, F i L wrote:
In D we have a bit of a conceptual double standard within the
number community. I have to remember these rules when I'm creating something,
not just when I'm debugging it. As often as D may have caught a construction
mistake specifically related to floats in
F i L:
Walter Bright wrote:
3. Floating point values are default initialized to NaN.
This isn't a good feature, IMO. C# handles this much more
conveniently
An alternative possibility is to:
1) Default initialize variables just as currently done in D, with
0s, NaNs, etc;
2) Where the
Walter Bright wrote:
I'd rather have a 100 easy to find bugs than 1 unnoticed one
that went out in the field.
That's just the thing, bugs are arguably easier to hunt down when
things default to a consistent, usable value. When variables are
defaulted to Zero, I have a guarantee that any
On 8/11/2012 2:41 PM, bearophile wrote:
2) Where the compiler is certain a variable is read before any possible
initialization, it generates a compile-time error;
This has been suggested repeatedly, but it is in utter conflict with the whole
notion of default initialization, which nobody
On 8/11/2012 3:01 PM, F i L wrote:
Walter Bright wrote:
I'd rather have a 100 easy to find bugs than 1 unnoticed one that went out in
the field.
That's just the thing, bugs are arguably easier to hunt down when things default
to a consistent, usable value.
Many, many programming bugs trace
On 08/10/2012 06:01 PM, Walter Bright wrote:
On 8/10/2012 1:38 AM, F i L wrote:
Walter Bright wrote:
3. Floating point values are default initialized to NaN.
This isn't a good feature, IMO. C# handles this much more conveniently
with just
as much optimization/debugging benefit (arguably more
On Saturday, 11 August 2012 at 23:49:18 UTC, Chad J wrote:
On 08/10/2012 06:01 PM, Walter Bright wrote:
It catches only a subset of these at compile time. I can craft
any number of ways of getting it to miss diagnosing it.
Consider this one:
float z;
if (condition1)
z = 5;
... lotsa code ...
Walter Bright wrote:
That's just the thing, bugs are arguably easier to hunt down
when things default
to a consistent, usable value.
Many, many programming bugs trace back to assumptions that
floating point numbers act like ints. There's just no way to
avoid knowing and understanding the
On 8/11/12 7:33 PM, Walter Bright wrote:
[snip]
Allow me to insert an opinion here. This post illustrates quite well how
opinionated our community is (for better or worse).
The OP has asked a topical question in a matter that is interesting and
also may influence the impact of the language
Andrei Alexandrescu:
- The language's superior modeling power and level of control
comes at an increase in complexity compared to languages such
as e.g. Python. So the statistician would need a larger upfront
investment in order to reap the associated benefits.
Statistician often use the R
On Sunday, 12 August 2012 at 02:28:44 UTC, Andrei Alexandrescu
wrote:
On 8/11/12 7:33 PM, Walter Bright wrote:
[snip]
Allow me to insert an opinion here. This post illustrates quite
well how opinionated our community is (for better or worse).
The OP has asked a topical question in a matter
Walter Bright wrote:
3. Floating point values are default initialized to NaN.
This isn't a good feature, IMO. C# handles this much more
conveniently with just as much optimization/debugging benefit
(arguably more so, because it catches NaN issues at
compile-time). In C#:
class Foo
1) I think compile-time function execution is a very big plus for
people doing calculations.
For example:
ulong fibonacci(ulong n) { }
static x = fibonacci(50); // calculated at compile time! runtime
cost = 0 !!!
2) It has support for a BigInt structure in its standard library
(which
1 - 100 of 133 matches
Mail list logo
