On 23 February 2012 19:28, F i L wrote:
> H. S. Teoh wrote:
>>
>> So for example, here's a function that computes the average of an array:
>>
>> }efas erup tsnoc a f~a+z!~ni z@# b! $
>> a c)0=
>> hcaerof~d=b! $c^)d=%
>> nruter c(b{htgnel=
>>
H. S. Teoh wrote:
So for example, here's a function that computes the average of
an array:
}efas erup tsnoc a f~a+z!~ni z@# b! $
a c)0=
hcaerof~d=b! $c^)d=%
nruter c(b{htgnel=
%
Here's an example of how to use it:
tropmi
On Wed, Feb 22, 2012 at 11:15:35PM +0100, F i L wrote:
> >It does not serve any purpose to insist on closely similar
> >notations.
>
> So let's make '+' be '$' and '-' be '+'?
Sounds like an esolang (http://esolangs.org/wiki/Main_Page) :)
Maybe I should invent one. I'll call it EsoD, for Esoteri
It does not serve any purpose to insist on closely similar
notations.
So let's make '+' be '$' and '-' be '+'? My point wasn't that
mathematical equations are identical to sequential code
statements, but that they should, as much as possible, attempt to
stay inline. It's all about how difficu
On Wed, Feb 22, 2012 at 08:35:21PM +0100, Kagamin wrote:
> On Wednesday, 22 February 2012 at 19:04:55 UTC, H. S. Teoh wrote:
> >Wait, which proposal? To replace && and || with 'and' and 'or'?
> >
> >Or my slightly extreme rant about replacing '==' with '=' and '='
> >with ':=', amongst other things
On Wednesday, 22 February 2012 at 19:04:55 UTC, H. S. Teoh wrote:
Wait, which proposal? To replace && and || with 'and' and 'or'?
Or my slightly extreme rant about replacing '==' with '=' and
'=' with
':=', amongst other things?
Well, it's hard to explain. Proposals like python's semantic
w
On Wed, Feb 22, 2012 at 07:57:31PM +0100, Kagamin wrote:
> On Friday, 17 February 2012 at 06:25:49 UTC, H. S. Teoh wrote:
> >But who am I to speak out against more than four decades of
> >historical accidents, right? I think I'll shut up now.
>
> Can you forgive me a little investigation? I heard
On Friday, 17 February 2012 at 06:25:49 UTC, H. S. Teoh wrote:
But who am I to speak out against more than four decades of
historical
accidents, right? I think I'll shut up now.
Can you forgive me a little investigation? I heard similar
proposals and wonder where they come from. What do you t
On Friday, 17 February 2012 at 16:43:54 UTC, F i L wrote:
I just don't see an argument for why we *shouldn't* make
mathematical operations in code match those we where taught as
children as close as possible.
There is a profound difference in that math is mostly about
making a series of
On 02/18/2012 06:13 PM, Nick Sabalausky wrote:
"bcs" wrote in message
news:jhonpv$neg$1...@digitalmars.com...
On 02/18/2012 09:10 AM, Nick Sabalausky wrote:
I've heard a lot of people say that about vi(m), but in my (admittedly
somewhat limited) experience, I've never come across a (Li|U)n[ui
On 02/19/2012 07:25 AM, Kevin Cox wrote:
Vb yes, python kinda. Vb is designed for people who don't want to
program. The idea is to create a quick application that gets two job
done. Python is slightly different. It has a ton of syntax and all the
libraries that it needs to be used in moderate
On 02/18/2012 11:21 AM, H. S. Teoh wrote:
On Sat, Feb 18, 2012 at 09:45:10AM -0800, bcs wrote:
On 02/16/2012 09:14 PM, H. S. Teoh wrote:
On Thu, Feb 16, 2012 at 09:00:39PM -0800, Walter Bright wrote:
On 2/16/2012 8:47 PM, H. S. Teoh wrote:
Well, in that case, we should replace 'in' with '∈'.
Kevin Cox:
> I think that python stretches
> close to the line but I doubt it was designed for beginners.
Python partially comes from ABC, a language that was designed to teach
programming. So originally Python was meant (unlike ABC) to be practically
useful, but also to avoid being unnecessari
Vb yes, python kinda. Vb is designed for people who don't want to
program. The idea is to create a quick application that gets two job
done. Python is slightly different. It has a ton of syntax and all the
libraries that it needs to be used in moderately sized project. Python
comes across as b
On 17/02/2012 06:09, bcs wrote:
Any language that is designed to be easy for amateurs to use will be used by
amateurs, and
only by amateurs.
Do you consider either VB or Python to fall under that category?
Stewart.
I think the difference between chording and non-chording styles of
input depends on the person. I have dyspraxia, which affects my fine
motor control, so remembering and performing complex key sequences
(such as emacs' keyboard shortcuts) is difficult for me, hell I have
difficulty correctly typing
On Sun, Feb 19, 2012 at 1:31 AM, Nick Sabalausky wrote:
> "H. S. Teoh" wrote in message
> news:mailman.527.1329589896.20196.digitalmar...@puremagic.com...
>> On Sat, Feb 18, 2012 at 12:10:48PM -0500, Nick Sabalausky wrote:
>>
>> [...]
>>> If I'm using a server that doesn't already have ssh set up
"H. S. Teoh" wrote in message
news:mailman.527.1329589896.20196.digitalmar...@puremagic.com...
> On Sat, Feb 18, 2012 at 12:10:48PM -0500, Nick Sabalausky wrote:
>
> [...]
>> If I'm using a server that doesn't already have ssh set up (for
>> instance, if I'm actually setting up ssh) *then* I'll e
"bcs" wrote in message
news:jhonpv$neg$1...@digitalmars.com...
> On 02/18/2012 09:10 AM, Nick Sabalausky wrote:
>>
>> I've heard a lot of people say that about vi(m), but in my (admittedly
>> somewhat limited) experience, I've never come across a (Li|U)n[ui]x
>> system
>> that didn't have nano o
Am 18.02.2012 18:10, schrieb Nick Sabalausky:
"James Miller" wrote in message
news:mailman.523.1329551034.20196.digitalmar...@puremagic.com...
I would like to add a few more points.
I exclusively use (g)vim text editing, why? Because it means I can jump on
a console, SSH into a server, and it w
On Sat, Feb 18, 2012 at 09:45:10AM -0800, bcs wrote:
> On 02/16/2012 09:14 PM, H. S. Teoh wrote:
> >On Thu, Feb 16, 2012 at 09:00:39PM -0800, Walter Bright wrote:
> >>On 2/16/2012 8:47 PM, H. S. Teoh wrote:
> >>>Well, in that case, we should replace 'in' with '∈'.
> >>
> >>I would, but that doesn't
On Sat, Feb 18, 2012 at 12:10:48PM -0500, Nick Sabalausky wrote:
[...]
> I've heard a lot of people say that about vi(m), but in my (admittedly
> somewhat limited) experience, I've never come across a (Li|U)n[ui]x
> system that didn't have nano or pico (neither of which are great, but
> they're goo
On 02/16/2012 09:14 PM, H. S. Teoh wrote:
On Thu, Feb 16, 2012 at 09:00:39PM -0800, Walter Bright wrote:
On 2/16/2012 8:47 PM, H. S. Teoh wrote:
Well, in that case, we should replace 'in' with '∈'.
I would, but that doesn't work because of keyboarding issues.
I wasn't being serious. I was
On 02/18/2012 09:10 AM, Nick Sabalausky wrote:
"James Miller" wrote in message
news:mailman.523.1329551034.20196.digitalmar...@puremagic.com...
I would like to add a few more points.
I exclusively use (g)vim text editing, why? Because it means I can jump on
a console, SSH into a server, and it
"James Miller" wrote in message
news:mailman.523.1329551034.20196.digitalmar...@puremagic.com...
>I would like to add a few more points.
> I exclusively use (g)vim text editing, why? Because it means I can jump on
> a console, SSH into a server, and it will probably have vim, or atleast
> vi.
I
I would like to add a few more points.
I exclusively use (g)vim text editing, why? Because it means I can jump on
a console, SSH into a server, and it will probably have vim, or atleast vi.
I also switch between languages frequently, I use PHP and JavaScript at
work; and D, bash and python in my sp
"Marco Leise" wrote in message
news:op.v9uav5gm9y6...@marco-leise.homedns.org...
> EN might be an alternative, but '+' with shift and '-' without? i don't
> know...
That does seem weird now that you mention it. I guess I just managed to get
used to it. *shrug*
"H. S. Teoh" wrote in message
news:mailman.492.1329503475.20196.digitalmar...@puremagic.com...
>
> That's not 100% true, though. Programming has always had close ties with
> math, even though, as you said, they aren't the same thing. In fact,
> computing came out of math, if you want to be histor
On Friday, 17 February 2012 at 20:52:56 UTC, F i L wrote:
H. S. Teoh wrote:
Are you referring to:
int x = 10;
vs.
x = 10;
?
In that case I would still prefer :=, since the first can be
thought of
as shorthand for "int x; x := 10".
I'm not sure what you're asking/saying h
H. S. Teoh wrote:
Are you referring to:
int x = 10;
vs.
x = 10;
?
In that case I would still prefer :=, since the first can be
thought of
as shorthand for "int x; x := 10".
I'm not sure what you're asking/saying here. What I mean is that
there needs to be some distinctio
Am 17.02.2012, 19:00 Uhr, schrieb H. S. Teoh :
I thought the US/English keyboard layout is already very well suited to
D.
Yes, but I am still using the German (DE) layout, which has all the keys (so
there was never a _need_ to switch) but almost every symbol I type requires the
shift key. EN
On Friday, 17 February 2012 at 17:49:53 UTC, H. S. Teoh wrote:
On Fri, Feb 17, 2012 at 08:56:58AM +0100, F i L wrote:
[...]
Thought to be honest I doubt we'll all still be designing
applications
in text (only) editors, even fancy ones, in the next 10-15
years.
I know I still will be. I have n
On Fri, Feb 17, 2012 at 09:58:06AM -0500, Nick Sabalausky wrote:
> "F i L" wrote in message
[...]
> > Seeing as how we're all educated around with mathematic symbols as
> > children, a language design which reflects what is most familiar
> > will be the easiest to initially understand. Less frict
On Fri, Feb 17, 2012 at 08:44:48AM +0100, F i L wrote:
> On Friday, 17 February 2012 at 06:25:49 UTC, H. S. Teoh wrote:
> >On Fri, Feb 17, 2012 at 06:47:20AM +0100, F i L wrote:
> >>I would use them over '||' and '&&' for the reasons bearophile
> >>gave.
> >>Highlighted as keywords, they're easily
Nick Sabalausky wrote:
I find:
case a == 0 && b !is null && c == "Bar" { ... }
much easier to read than:
case a == 0 and b !is null and c == "Bar" { ... }
Since the former uses a totally different character set for the
operators, my eyes can parse it at a glance. With the latter, I
ha
On Fri, Feb 17, 2012 at 06:30:09PM +0100, Marco Leise wrote:
[...]
> Why didn't I think of that before! The perceived ease of use depends -
> in parts - on the spoken language you use, because different keyboard
> layouts are used. To pick up your example, I don't mind := because I
> have to hold [
On Fri, Feb 17, 2012 at 08:56:58AM +0100, F i L wrote:
[...]
> Thought to be honest I doubt we'll all still be designing applications
> in text (only) editors, even fancy ones, in the next 10-15 years.
I know I still will be. I have never liked IDE's, and probably never
will.
> Software design i
Am 17.02.2012, 16:08 Uhr, schrieb Nick Sabalausky :
I've always agreed with the usual reasoning behind ":= and = instead of =
and ==", but in practice I don't like it becase assignment is so
*incredibly* common I don't want it to be a 2-handed 3-keypress
"Shift+Keypress and then another keypress
"F i L" wrote in message
news:iylkhrwcbscmfwsdx...@forum.dlang.org...
> Nick Sabalausky wrote:
>>
>> You're talking about very minor details that are trivial to learn (I was
>> only about 12 or 13 when I learned C). The prodictivity drop in these
>> cases is *purely* a *minor* upfront cost, and
Nick Sabalausky wrote:
"F i L" wrote in message
news:jzkatvnibtjkcafqs...@forum.dlang.org...
All of the syntaxes you're advocating are every bit as
arbitrary as the ones you're against.
Programming is logic largely based around math.
Yes, it's *based* around math, but it *isn't* math.
Engl
Am 17.02.2012, 15:02 Uhr, schrieb James Miller :
On 18 February 2012 02:35, David wrote:
Python also uses "&" for set intersection afaik.
Yes, but that's an overload of the &-Operator and it makes sense.
We should add "and" and "or" this makes the Code way more readable, imo.
But I spen
Timon Gehr wrote:
The contract syntax is wrong, because it conceptually has to
belong to the function declaration, not the function body.
I'm not so convinced. I just hate how in/out are shoved up
against the name of the function. I was thinking about using '.'
to reference the current functi
Am 17.02.2012 15:02, schrieb James Miller:
On 18 February 2012 02:35, David wrote:
Python also uses "&" for set intersection afaik.
Yes, but that's an overload of the&-Operator and it makes sense.
We should add "and" and "or" this makes the Code way more readable, imo.
But I spent years
"F i L" wrote in message
news:ycdqoufsbftcccpek...@forum.dlang.org...
> On Friday, 17 February 2012 at 06:25:49 UTC, H. S. Teoh wrote:
>> On Fri, Feb 17, 2012 at 06:47:20AM +0100, F i L wrote:
>>> I would use them over '||' and '&&' for the reasons bearophile gave.
>>> Highlighted as keywords, th
"F i L" wrote in message
news:jzkatvnibtjkcafqs...@forum.dlang.org...
>> All of the syntaxes you're advocating are every bit as arbitrary as the
>> ones you're against.
>
> Programming is logic largely based around math.
Yes, it's *based* around math, but it *isn't* math.
English is based larg
On 18 February 2012 02:35, David wrote:
>> Python also uses "&" for set intersection afaik.
>
>
> Yes, but that's an overload of the &-Operator and it makes sense.
>
>
> We should add "and" and "or" this makes the Code way more readable, imo.
But I spent years learning && and ||, when I read code
Le 17/02/2012 05:35, Jonathan M Davis a écrit :
On Thursday, February 16, 2012 22:31:18 Caligo wrote:
C++ has this and it makes code little more readable in certain cases:
if(something() or foo() and bar()){ ... }
instead of this in D:
if(something() || foo()&& bar()){ ... }
possible enha
Python also uses "&" for set intersection afaik.
Yes, but that's an overload of the &-Operator and it makes sense.
We should add "and" and "or" this makes the Code way more readable, imo.
On 02/17/2012 08:44 AM, F i L wrote:
Yep! Though, I like D's '~' as append operator for arrays. Though I i'm
not sure this wouldn't work better:
a, b: [1, 2, 3, 4, 5]
a += b[2] // appends b[0] to a
a[] += b[2] // adds b[0]'s value to all of a
'+' means addition! Concatenation is not even co
On 02/17/2012 06:47 AM, F i L wrote:
I would use them over '||' and '&&' for the reasons bearophile gave.
Highlighted as keywords, they're easily set appart, easier to type, and
more distinguished... then again if I had my way I'd remove the '('/')'
brackets, ending marks, and auto keyword; switc
On 17 February 2012 05:14, H. S. Teoh wrote:
> On Thu, Feb 16, 2012 at 09:00:39PM -0800, Walter Bright wrote:
>> On 2/16/2012 8:47 PM, H. S. Teoh wrote:
>> >Well, in that case, we should replace 'in' with '∈'.
>>
>> I would, but that doesn't work because of keyboarding issues.
>
> I wasn't being s
On 2/17/12, Jonathan M Davis wrote:
> Well, canFind gives you any functionality-wise.
Good point! I tend to forget about canFind.
On Friday, February 17, 2012 09:47:50 Andrej Mitrovic wrote:
> The better question is why is there no 'any' and 'all' template in Phobos!
You mean as in a function which returns whether any element in a range matches
a predicate and a function which returns whether all elements in a range match
The better question is why is there no 'any' and 'all' template in Phobos!
On Friday, 17 February 2012 at 07:21:32 UTC, Nick Sabalausky
wrote:
"F i L" wrote in message
news:simejelbyihexcsbk...@forum.dlang.org...
I would use them over '||' and '&&' for the reasons bearophile
gave. Highlighted as keywords, they're easily set appart,
easier to type, and more distinguis
All of the syntaxes you're advocating are every bit as
arbitrary as the ones you're against.
Programming is logic largely based around math. Seeing as how
we're all educated around with mathematic symbols as children, a
language design which reflects what is most familiar will be the
easiest
On Friday, 17 February 2012 at 06:25:49 UTC, H. S. Teoh wrote:
On Fri, Feb 17, 2012 at 06:47:20AM +0100, F i L wrote:
I would use them over '||' and '&&' for the reasons bearophile
gave.
Highlighted as keywords, they're easily set appart, easier to
type,
and more distinguished... then again if
"H. S. Teoh" wrote in message
news:mailman.460.1329459948.20196.digitalmar...@puremagic.com...
> On Fri, Feb 17, 2012 at 06:47:20AM +0100, F i L wrote:
>> I would use them over '||' and '&&' for the reasons bearophile gave.
>> Highlighted as keywords, they're easily set appart, easier to type,
>>
"F i L" wrote in message
news:simejelbyihexcsbk...@forum.dlang.org...
>I would use them over '||' and '&&' for the reasons bearophile gave.
>Highlighted as keywords, they're easily set appart, easier to type, and
>more distinguished... then again if I had my way I'd remove the '('/')'
>bracket
Andrei Alexandrescu wrote:
I figured I won't be able to unread the rest, so I stopped here
:o).
Well... my syntax must require a finer taste ;-p
Jonathan M Davis wrote:
On Friday, February 17, 2012 06:57:48 F i L wrote:
I knew someone was going to say that >:{
Well, you _were_ asking for
On Fri, Feb 17, 2012 at 06:47:20AM +0100, F i L wrote:
> I would use them over '||' and '&&' for the reasons bearophile gave.
> Highlighted as keywords, they're easily set appart, easier to type,
> and more distinguished... then again if I had my way I'd remove the
> '('/')' brackets, ending marks,
On 02/16/2012 09:16 PM, Nick Sabalausky wrote:
"Jonathan M Davis" wrote in message
news:mailman.450.1329455016.20196.digitalmar...@puremagic.com...
Seriously?&& and || are _way_ more readible, because they're obviously
not
functions or variables. It's immediately obvious what the operators ar
On 02/16/2012 08:53 PM, bearophile wrote:
Caligo:
possible enhancement request? or is there a good reason it is not in
the language?
I have asked for them, but Walter doesn't want, he thinks C/C++ programmers
will not use them... :-( Despite D != C/C++.
Jonathan M Davis:
On Friday, February 17, 2012 06:57:48 F i L wrote:
> I knew someone was going to say that >:{
Well, you _were_ asking for it. :)
But I do honestly think that it's ugly. Obviously, different people have
different ideas of what a language's syntax should look like - frequently
strongly influenced
On 2/16/12 11:47 PM, F i L wrote:
I would use them over '||' and '&&' for the reasons bearophile gave.
Highlighted as keywords, they're easily set appart, easier to type, and
more distinguished... then again if I had my way I'd remove the '('/')'
brackets, ending marks, and auto keyword;
I figu
On Friday, 17 February 2012 at 05:53:08 UTC, Jonathan M Davis
wrote:
On Friday, February 17, 2012 06:47:20 F i L wrote:
I would use them over '||' and '&&' for the reasons bearophile
gave. Highlighted as keywords, they're easily set appart,
easier
to type, and more distinguished... then again i
On Friday, February 17, 2012 06:47:20 F i L wrote:
> I would use them over '||' and '&&' for the reasons bearophile
> gave. Highlighted as keywords, they're easily set appart, easier
> to type, and more distinguished... then again if I had my way I'd
> remove the '('/')' brackets, ending marks, and
I would use them over '||' and '&&' for the reasons bearophile
gave. Highlighted as keywords, they're easily set appart, easier
to type, and more distinguished... then again if I had my way I'd
remove the '('/')' brackets, ending marks, and auto keyword;
switched the definition name-type placem
On Thu, Feb 16, 2012 at 11:16 PM, Nick Sabalausky wrote:
>
> This is why I think people are nuts when they claim that english-like
> VB-style syntax is more readable than C-style.
>
> (Yea, to a grandmother with zero programming experience english-like
> languages are more readable. For a programm
"Jonathan M Davis" wrote in message
news:mailman.450.1329455016.20196.digitalmar...@puremagic.com...
>
> Seriously? && and || are _way_ more readible, because they're obviously
> not
> functions or variables. It's immediately obvious what the operators are
> when
> scanning code. That's not the
On 02/17/2012 06:02 AM, Jonathan M Davis wrote:
On Thursday, February 16, 2012 23:53:34 bearophile wrote:
And I'm actually mildly shocked that anyone (at least any programmer)
would
think that "or" and "and" were more readable. The fact that operators
aren't words is a _major_ boon to code readi
On 02/17/2012 05:53 AM, bearophile wrote:
Caligo:
possible enhancement request? or is there a good reason it is not in
the language?
I have asked for them, but Walter doesn't want, he thinks C/C++ programmers
will not use them... :-( Despite D != C/C++.
Jonathan M Davis:
On Thu, Feb 16, 2012 at 09:00:39PM -0800, Walter Bright wrote:
> On 2/16/2012 8:47 PM, H. S. Teoh wrote:
> >Well, in that case, we should replace 'in' with '∈'.
>
> I would, but that doesn't work because of keyboarding issues.
I wasn't being serious. I was going to suggest to those who complain
On 2/16/2012 8:54 PM, Jonathan M Davis wrote:
Yuck. That's horrible to hear. I should certainly hope that no one uses them.
Having two operators for the same thing is horrific, and words are definitely
worse than symbols as far as readibility goes.
Well, it sounded like a good idea at the time
On 2/16/2012 8:47 PM, H. S. Teoh wrote:
Well, in that case, we should replace 'in' with '∈'.
I would, but that doesn't work because of keyboarding issues.
On Thursday, February 16, 2012 23:53:34 bearophile wrote:
> > And I'm actually mildly shocked that anyone (at least any programmer)
> > would
> > think that "or" and "and" were more readable. The fact that operators
> > aren't words is a _major_ boon to code readibility.
>
> This is very very wron
On 2/16/2012 8:35 PM, Jonathan M Davis wrote:
Since when does C++ have "or" and "and"?
Since C++98!
(Amazing but true.)
Caligo:
> possible enhancement request? or is there a good reason it is not in
> the language?
I have asked for them, but Walter doesn't want, he thinks C/C++ programmers
will not use them... :-( Despite D != C/C++.
Jonathan M Davis:
> And I'm actually mildly shocked that an
On Thursday, February 16, 2012 21:52:35 Brad Anderson wrote:
> On Thu, Feb 16, 2012 at 9:35 PM, Jonathan M Davis
> They are in the 1998 standard (section 2.5, right below trigraphs, if you
> are curious). Nobody actually uses them.
Yuck. That's horrible to hear. I should certainly hope that no on
On Thu, Feb 16, 2012 at 9:35 PM, Jonathan M Davis wrote:
> On Thursday, February 16, 2012 22:31:18 Caligo wrote:
> > C++ has this and it makes code little more readable in certain cases:
> >
> > if(something() or foo() and bar()){ ... }
> >
> > instead of this in D:
> >
> > if(something() || foo(
http://en.cppreference.com/w/cpp/language/operator_alternative
On Thu, Feb 16, 2012 at 10:35 PM, Jonathan M Davis wrote:
> On Thursday, February 16, 2012 22:31:18 Caligo wrote:
>> C++ has this and it makes code little more readable in certain cases:
>>
>> if(something() or foo() and bar()){ ... }
>>
>> instead of this in D:
>>
>> if(something() || foo() && b
On Thu, Feb 16, 2012 at 08:35:38PM -0800, Jonathan M Davis wrote:
> On Thursday, February 16, 2012 22:31:18 Caligo wrote:
> > C++ has this and it makes code little more readable in certain cases:
> >
> > if(something() or foo() and bar()){ ... }
> >
> > instead of this in D:
> >
> > if(somethin
On Thursday, February 16, 2012 22:31:18 Caligo wrote:
> C++ has this and it makes code little more readable in certain cases:
>
> if(something() or foo() and bar()){ ... }
>
> instead of this in D:
>
> if(something() || foo() && bar()){ ... }
>
>
> possible enhancement request? or is there a
C++ has this and it makes code little more readable in certain cases:
if(something() or foo() and bar()){ ... }
instead of this in D:
if(something() || foo() && bar()){ ... }
possible enhancement request? or is there a good reason it is not in
the language?
85 matches
Mail list logo
