On 01/21/13 04:12, deadalnix wrote:
On Saturday, 19 January 2013 at 13:19:36 UTC, Artur Skawina wrote:
If you wonder where the loss comes from, others have mentioned some sources
Nobody demonstrated anything remotely close to that.
Ignoring an argument does not invalidate it. The fact that
On Saturday, 19 January 2013 at 13:19:36 UTC, Artur Skawina wrote:
(No (or small enough) gain) - (real (tangible) loss) 0.
If you wonder where the loss comes from, others have mentioned
some sources
in this thread already. I'm just pointing out the lack of gain
and additional
loss
On 01/18/13 11:28, deadalnix wrote:
On Friday, 18 January 2013 at 09:10:38 UTC, Artur Skawina wrote:
On 01/18/13 09:48, Walter Bright wrote:
On 1/17/2013 11:58 PM, Artur Skawina wrote:
Sane, but badly formatted code is much preferable to bad, but pretty code.
Offhand, I can't remember ever
On Friday, 18 January 2013 at 07:21:48 UTC, simendsjo wrote:
On Friday, 18 January 2013 at 06:45:37 UTC, Mehrdad wrote:
On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina
wrote:
This is one of the reasons why automatic code formatting is
such a bad idea.
artur
In what language? In
On Friday, 18 January 2013 at 07:19:16 UTC, Jonathan M Davis
wrote:
On Friday, January 18, 2013 07:45:34 Mehrdad wrote:
On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina
wrote:
This is one of the reasons why automatic code formatting is
such a bad idea.
artur
In what language?
On Friday, 18 January 2013 at 07:58:57 UTC, Artur Skawina wrote:
On 01/18/13 07:45, Mehrdad wrote:
On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina
wrote:
This is one of the reasons why automatic code formatting is
such a bad idea.
In what language? In C# it's actually a fantastic
On Friday, 18 January 2013 at 07:58:57 UTC, Artur Skawina wrote:
On 01/18/13 07:45, Mehrdad wrote:
On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina
wrote:
This is one of the reasons why automatic code formatting is
such a bad idea.
In what language? In C# it's actually a fantastic
On Friday, January 18, 2013 09:12:26 Mehrdad wrote:
Have you /actually/ tried this in Visual C#?
Visual C# doesn't use heuristics to do format your code... it's
not like C++ where everything is ambiguous.
I suggest you give it a try and let the auto-formatter format
your code to see what
Maybe I should invent a programming language in which color has semantic
value. And fonts. :-P
Sort of :-)
http://www.colorforth.com/primer.htm
-=mike=-
On 1/17/2013 5:59 PM, Walter Bright wrote:
But in practice, I find over and over again that carefully formatted code tends
to go hand in hand with well designed code.
I might add that trying to find the right way to format code is a non-trivial
exercise I go through all the time. It matters
On 1/17/2013 11:58 PM, Artur Skawina wrote:
Sane, but badly formatted code is much preferable to bad, but pretty code.
Offhand, I can't remember ever running across bad but pretty code.
On 2013-01-18 08:18, Jonathan M Davis wrote:
In _any_ language. Inevitably, the formatter ends up totally mangling at least
some of the lines. In my experience, any attempt to be super strict with the
formatting rules (as an automatic code formatter must be) results in ugly
code. A basic set of
On Friday, 18 January 2013 at 08:13:48 UTC, deadalnix wrote:
Believing that one code formatting will inherently be better
than what a formatted can do is very similar to the assertion
often heard that code generated by the compiler is worse than
hand written assembly or many other recurring
On 01/18/2013 09:48 AM, Walter Bright wrote:
On 1/17/2013 11:58 PM, Artur Skawina wrote:
Sane, but badly formatted code is much preferable to bad, but pretty
code.
Offhand, I can't remember ever running across bad but pretty code.
Some of the worst code I have seen has been consistently
On Friday, January 18, 2013 09:47:31 Jacob Carlborg wrote:
On 2013-01-18 08:18, Jonathan M Davis wrote:
In _any_ language. Inevitably, the formatter ends up totally mangling at
least some of the lines. In my experience, any attempt to be super strict
with the formatting rules (as an
On 01/18/13 09:48, Walter Bright wrote:
On 1/17/2013 11:58 PM, Artur Skawina wrote:
Sane, but badly formatted code is much preferable to bad, but pretty code.
Offhand, I can't remember ever running across bad but pretty code.
Which is my point. An autoformatter makes the bad code look good,
On 01/18/13 09:58, Timon Gehr wrote:
On 01/18/2013 09:48 AM, Walter Bright wrote:
On 1/17/2013 11:58 PM, Artur Skawina wrote:
Sane, but badly formatted code is much preferable to bad, but pretty
code.
Offhand, I can't remember ever running across bad but pretty code.
Some of the worst
Am 18.01.2013 10:10, schrieb Artur Skawina:
Which is my point. An autoformatter makes the bad code look good, but does
not change its quality. Hence use of such a tool as part of the std dev
process should be strongly discouraged, not encouraged.
bad code can't look good by pretty-printing -
Am 18.01.2013 10:20, schrieb dennis luehring:
so you can concentrate your analysis completely on the semantic if an a
fulltime 100% working autoformatter would be always active
another nice effect of an autoformatter would be the newcomer-style -
only the semantic is normaly total shit in the
On Friday, January 18, 2013 10:20:58 dennis luehring wrote:
Am 18.01.2013 10:10, schrieb Artur Skawina:
Which is my point. An autoformatter makes the bad code look good, but does
not change its quality. Hence use of such a tool as part of the std dev
process should be strongly discouraged,
Am 18.01.2013 10:29, schrieb Jonathan M Davis:
Formatting can have a huge effect on code legibility. There are plenty of cases
where slight formatting changes don't make that big a difference, but some
really can (e.g. where the braces go), and many small differences can add up.
For instance,
On Friday, January 18, 2013 10:45:46 dennis luehring wrote:
Am 18.01.2013 10:29, schrieb Jonathan M Davis:
Formatting can have a huge effect on code legibility. There are plenty of
cases where slight formatting changes don't make that big a difference,
but some really can (e.g. where the
On Friday, 18 January 2013 at 09:10:38 UTC, Artur Skawina wrote:
On 01/18/13 09:48, Walter Bright wrote:
On 1/17/2013 11:58 PM, Artur Skawina wrote:
Sane, but badly formatted code is much preferable to bad, but
pretty code.
Offhand, I can't remember ever running across bad but pretty
code.
On Friday, 18 January 2013 at 09:30:51 UTC, Jonathan M Davis
wrote:
On Friday, January 18, 2013 10:20:58 dennis luehring wrote:
Am 18.01.2013 10:10, schrieb Artur Skawina:
Which is my point. An autoformatter makes the bad code look
good, but does
not change its quality. Hence use of such a
On Friday, 18 January 2013 at 10:40:50 UTC, Mehrdad wrote:
On Friday, 18 January 2013 at 10:30:33 UTC, deadalnix wrote:
If you believe you know operator precedence, you are probably
wrong. And even if you are right, most other programmer don't.
They're not /that/ bad...
+ - * / % are like
On Friday, 18 January 2013 at 10:30:33 UTC, deadalnix wrote:
If you believe you know operator precedence, you are probably
wrong. And even if you are right, most other programmer don't.
They're not /that/ bad...
+ - * / % are like in math
are harder, but all you need is to recall
On Friday, January 18, 2013 11:30:32 deadalnix wrote:
If you believe you know operator precedence, you are probably
wrong. And even if you are right, most other programmer don't.
You really should know the precedence of at least the common operators. For
instance, I don't think that there's
On Thu, 2013-01-17 at 17:59 -0800, Walter Bright wrote:
[…]
But in practice, I find over and over again that carefully formatted code
tends
to go hand in hand with well designed code.
Having an obsessive–compulsive side to your nature is good in these
case.
--
Russel.
On 1/18/2013 12:58 AM, Timon Gehr wrote:
On 01/18/2013 09:48 AM, Walter Bright wrote:
On 1/17/2013 11:58 PM, Artur Skawina wrote:
Sane, but badly formatted code is much preferable to bad, but pretty
code.
Offhand, I can't remember ever running across bad but pretty code.
Some of the worst
On Friday, 18 January 2013 at 10:49:52 UTC, Jonathan M Davis
wrote:
On Friday, January 18, 2013 11:30:32 deadalnix wrote:
If you believe you know operator precedence, you are probably
wrong. And even if you are right, most other programmer don't.
You really should know the precedence of at
On Friday, 18 January 2013 at 10:49:52 UTC, Jonathan M Davis
wrote:
You really should know the precedence of at least the common
operators. For instance, I don't think that there's much excuse
for code like
if((a == b) (c != d))
Unfortunately I've come across a few cases (and in dmd too)
On 01/18/2013 01:13 PM, monarch_dodra wrote:
...
*Personally*, I prefer
if ((a == b) (c != d))
over
if (a == b c != d)
I *know* the precedence here, but I still find it clearer with grouping.
HOWEVER, I 100% agree that in such code, the format chosen is very very
important. Place
monarch_dodra:
As a side note, I've taken to ALWAYS placing parenthesis with
ternary operators. That thing has some nasty precedence rules...
Then please vote :-)
http://d.puremagic.com/issues/show_bug.cgi?id=8757
Bye,
bearophile
On Tuesday, 15 January 2013 at 14:07:11 UTC, monarch_dodra wrote:
On Tuesday, 15 January 2013 at 13:55:53 UTC, Timon Gehr wrote:
On 01/15/2013 11:57 AM, mist wrote:
Well, probably I am playing good vision nazi here, as 12
font size
seems HUGE to me, far beyond the comfort zone.
It's just
On Fri, 2013-01-18 at 17:52 +0100, Graham Fawcett wrote:
[…]
FWIW, Emacs doesn't out of the box. But this makes it work:
(global-set-key [M-mouse-4] 'text-scale-increase)
(global-set-key [M-mouse-5] 'text-scale-decrease)
(M- for Alt, or C- for Control.)
Graham,
I am going to count the
On 01/18/2013 08:52 AM, Graham Fawcett wrote:
I do not know of any editor that does not support ctrl + scroll to
change the font sizes on the fly.
FWIW, Emacs doesn't out of the box. But this makes it work:
(global-set-key [M-mouse-4] 'text-scale-increase)
(global-set-key [M-mouse-5]
On 1/18/2013 3:09 AM, Russel Winder wrote:
On Thu, 2013-01-17 at 17:59 -0800, Walter Bright wrote:
[…]
But in practice, I find over and over again that carefully formatted code tends
to go hand in hand with well designed code.
Having an obsessive–compulsive side to your nature is good in
On Fri, Jan 18, 2013 at 11:03:12AM -0800, Walter Bright wrote:
On 1/18/2013 3:09 AM, Russel Winder wrote:
On Thu, 2013-01-17 at 17:59 -0800, Walter Bright wrote:
[…]
But in practice, I find over and over again that carefully formatted
code tends to go hand in hand with well designed code.
Well, initially it was just a harmless joke about some unique D
features. It is digitalmars.D newsgroup after all, no idea why
you have taken this so seriously.
But well, if you want to take this seriously, then I need to
state that I can't agree with Only if the increase in ugliness
is
On 17.01.2013 14:10, Mehrdad wrote:
Uh, you sort of missed the point...
The point was that you align similar-looking lines when /writing/ the
code, so that it's in the right form when you need to modify it later,
and all you need to do is Alt-Click-Drag to create 20 cursors, and type
away.
Or
On 01/15/2013 08:29 PM, H. S. Teoh wrote:
It's paradoxical that a 1D (i.e. linear) representation is more useful
for capturing the complexity of programming as opposed to, say, a 2D
graphical representation
Typical code is 2d because of line-oriented statements and indented
block structure.
On 2013-01-17 05:00, Era Scarecrow wrote:
Not going to happen, everyone's brain stores and processes things in
different locations (Not that there aren't enough dumb people around).
However the transmitter would likely be DRM laden and/or hacked (or
programmed intentionally) so it would send
Maybe I should invent a programming language in which color has semantic
value. And fonts. :-P
Why stop here? Go paint your programs in Piet. ;)
Fixing const issues in Phobos would be as simple as
selecting the entire source code and changing the font to italics. :-P
I suggest a special
On Thu, Jan 17, 2013 at 08:26:16AM +0100, Era Scarecrow wrote:
On Thursday, 17 January 2013 at 06:52:39 UTC, H. S. Teoh wrote:
On Thu, Jan 17, 2013 at 06:28:30AM +0100, deadalnix wrote:
We are using writing to communicate between people for thousands
of year now. This is clearly the most
On Thu, Jan 17, 2013 at 08:26:16AM +0100, Era Scarecrow wrote:
Somehow what seems like would work good is a card-file system.
Assuming the order of functions/declarations don't matter and
you let the editor deal with where it places things (say,
alphabetically or by attributes like private,
On Thursday, 17 January 2013 at 16:25:11 UTC, Era Scarecrow wrote:
On Thu, Jan 17, 2013 at 08:26:16AM +0100, Era Scarecrow wrote:
Somehow what seems like would work good is a card-file
system. Assuming the order of functions/declarations don't
matter and you let the editor deal with where it
On 17/01/2013 12:30, Jeff Nowakowski wrote:
On 01/15/2013 08:29 PM, H. S. Teoh wrote:
It's paradoxical that a 1D (i.e. linear) representation is more useful
for capturing the complexity of programming as opposed to, say, a 2D
graphical representation
Typical code is 2d because of
On Thursday, 17 January 2013 at 20:17:06 UTC, Stewart Gordon
wrote:
And in most languages, a program/module is essentially just a
sequence of tokens, and as such is one-dimensional. We might
look at it in a two-dimensional form, but this two-dimensional
layout means nothing as far as the
On Thursday, 17 January 2013 at 20:17:06 UTC, Stewart Gordon
wrote:
OTOH, because we tend to view code in a two-dimensional form,
and even rely on line breaks and block indentation to make code
readable, I can understand people thinking of code as 2D.
And there are languages in which the code
On Thu, Jan 17, 2013 at 11:43:33PM +0100, Rob T wrote:
On Thursday, 17 January 2013 at 20:17:06 UTC, Stewart Gordon wrote:
OTOH, because we tend to view code in a two-dimensional form, and
even rely on line breaks and block indentation to make code
readable, I can understand people thinking of
On Thursday, 17 January 2013 at 23:35:37 UTC, H. S. Teoh wrote:
It's easy to represent in 2D or 3D a *simulation* of program
execution (I.e., a particular instance of execution), but how
do you represent concurrent program *logic*?
For example, consider this: you have a program in which up
On 1/14/2013 3:19 PM, Timon Gehr wrote:
It is funny how statements about beauty of code tend to overemphasize the
importance of trivial formatting rules. This is completely irrational.
Formatting is a part of the process that could be trivially automated. It is not
what the substance is.
On Friday, 18 January 2013 at 01:59:18 UTC, Walter Bright wrote:
On 1/14/2013 3:19 PM, Timon Gehr wrote:
It is funny how statements about beauty of code tend to
overemphasize the
importance of trivial formatting rules. This is completely
irrational.
Formatting is a part of the process that
On 01/18/13 02:59, Walter Bright wrote:
On 1/14/2013 3:19 PM, Timon Gehr wrote:
It is funny how statements about beauty of code tend to overemphasize the
importance of trivial formatting rules. This is completely irrational.
Formatting is a part of the process that could be trivially
On Thu, Jan 17, 2013 at 05:59:13PM -0800, Walter Bright wrote:
[...]
But in practice, I find over and over again that carefully formatted
code tends to go hand in hand with well designed code.
It's like internet postings. If you see a posting in ALL CAPS, or
all lower case, or sloppy
On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina wrote:
This is one of the reasons why automatic code formatting is
such a bad idea.
artur
In what language? In C# it's actually a fantastic idea.
On Friday, January 18, 2013 07:45:34 Mehrdad wrote:
On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina wrote:
This is one of the reasons why automatic code formatting is
such a bad idea.
artur
In what language? In C# it's actually a fantastic idea.
In _any_ language.
On Friday, 18 January 2013 at 06:45:37 UTC, Mehrdad wrote:
On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina wrote:
This is one of the reasons why automatic code formatting is
such a bad idea.
artur
In what language? In C# it's actually a fantastic idea.
Well.. :)
enum E
{
S
On 2013-01-18 08:21, simendsjo wrote:
Well.. :)
enum E
{
S = 0x01,
Longer = 0x10,
}
After:
enum E
{
S = 0x01,
Longer = 0x10,
}
Any manual formatting like lining up arguments is always lost. Following
the recommended style guide for a language by hand isn't that big a
feat,
On 01/18/13 07:45, Mehrdad wrote:
On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina wrote:
This is one of the reasons why automatic code formatting is such a bad idea.
In what language? In C# it's actually a fantastic idea.
Every language. Not only does it mean that the heuristics
H. S. Teoh wrote:
Maybe I should invent a programming language in which color has semantic
value. And fonts. :-P
ColorForth by Chuck Moore
http://www.colorforth.com/cf.htm
Peter
On Wed, 2013-01-16 at 00:57 +0100, Rob T wrote:
[…]
The sad part is that after all these decades, we're still
_writing_ code, and we're doing it in essentially the exact same
way as was done 30 years ago using a text editor.
In the early to mid 1980s there was a move to not using text files
Of course now programmers rely on Git and Mercurial, there is likely no
chance of people giving up on hierarchies of text files as the way of
storing code.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip:
On Wed, 2013-01-16 at 03:54 +0100, Rob T wrote:
[…]
I was just a while ago thinking that a reason why text based
programming has been so predominant may be that the ability to
transmit and discuss programming problems are much easier to do
when the program is represented in written form.
On 1/15/2013 2:58 AM, Russel Winder wrote:
The issue is that having a single global style standard for a
programming language makes it easier to read code in that language.
Yup, it's better even if there are parts of it one doesn't like.
On Wednesday, 16 January 2013 at 01:29:24 UTC, Rob T wrote:
On Wednesday, 16 January 2013 at 01:03:36 UTC, Peter Alexander
wrote:
There's nothing stopping a more superior method from still
using the keyboard.
What amazes me is how much language complexity is added just
to make text editing
On 1/15/2013 9:32 AM, F i L wrote:
sorry if this has already been posted, but Phoronix did an article on John
Carmack's words as well, and the forum discussion has a bit of talk about D in
it (specifically how it compares to C++).
When you have a ton of similar lines of code which need to be
edited in parallel, lining them up lets you edit all of them in
one keystroke. Saves me quite a lot of annoying editing in the
long run, actually.
When you have a ton of similar lines of code, you'd better start
thinking about
On Wednesday, 16 January 2013 at 11:00:48 UTC, mist wrote:
When you have a ton of similar lines of code which need to be
edited in parallel, lining them up lets you edit all of them
in one keystroke. Saves me quite a lot of annoying editing in
the long run, actually.
When you have a ton of
On Wednesday, 16 January 2013 at 18:38:21 UTC, Mehrdad wrote:
On Wednesday, 16 January 2013 at 11:00:48 UTC, mist wrote:
When you have a ton of similar lines of code which need to be
edited in parallel, lining them up lets you edit all of them
in one keystroke. Saves me quite a lot of annoying
On Wednesday, 16 January 2013 at 18:42:38 UTC, Mehrdad wrote:
On Wednesday, 16 January 2013 at 18:38:21 UTC, Mehrdad wrote:
On Wednesday, 16 January 2013 at 11:00:48 UTC, mist wrote:
When you have a ton of similar lines of code which need to
be edited in parallel, lining them up lets you edit
On Wednesday, 16 January 2013 at 18:57:06 UTC, mist wrote:
This is a single template operator in D so it kind of solves
the problem. First is tricky, but is exactly the reason
sometimes types from external libs are used only via
alias/typedef. I'd prefer something like
On Wednesday, 16 January 2013 at 19:06:47 UTC, Mehrdad wrote:
On Wednesday, 16 January 2013 at 18:57:06 UTC, mist wrote:
This is a single template operator in D so it kind of solves
the problem. First is tricky, but is exactly the reason
sometimes types from external libs are used only via
On Wednesday, 16 January 2013 at 19:06:47 UTC, Mehrdad wrote:
On Wednesday, 16 January 2013 at 18:57:06 UTC, mist wrote:
This is a single template operator in D so it kind of solves
the problem. First is tricky, but is exactly the reason
sometimes types from external libs are used only via
On Wednesday, 16 January 2013 at 19:29:59 UTC, mist wrote:
Mixins and templates are tools to avoid copy-paste, there is no
point to using them just for the sake of that. I have already
mentioned that first example is not related to copy-paste and
thus not fixable with that, it is more related
On Wednesday, 16 January 2013 at 21:45:49 UTC, Mehrdad wrote:
The problem with the idea of a mixin is that it's just ___too
much abstraction___.
Clarification: I meant the problem with the idea of using a mixin
to solve THIS kind of editing problem.
Obviously there's appropriate situations
On 16.01.2013 20:07, Mehrdad wrote:
When you have a ton of similar lines of code which need to be edited in
parallel, lining them up lets you edit all of them in one keystroke.
Saves me quite a lot of annoying editing in the long run, actually.
With Sublime Text you don't even have to align
On 1/15/2013 5:39 PM, H. S. Teoh wrote:
Maybe I should invent a programming language in which color has semantic
value.
That works until your first color blind user.
On Wed, Jan 16, 2013 at 04:40:07PM -0800, Walter Bright wrote:
On 1/15/2013 5:39 PM, H. S. Teoh wrote:
Maybe I should invent a programming language in which color has semantic
value.
That works until your first color blind user.
I wasn't being serious. :)
T
--
Food and laptops don't
On Thursday, 17 January 2013 at 00:40:06 UTC, Walter Bright wrote:
On 1/15/2013 5:39 PM, H. S. Teoh wrote:
Maybe I should invent a programming language in which color
has semantic value.
That works until your first color blind user.
I have a perfect solution! Have a special monitor that
On Wednesday, 16 January 2013 at 22:29:10 UTC, Marco Nembrini
wrote:
On 16.01.2013 20:07, Mehrdad wrote:
When you have a ton of similar lines of code which need to be
edited in
parallel, lining them up lets you edit all of them in one
keystroke.
Saves me quite a lot of annoying editing in
On Thursday, January 17, 2013 03:09:35 Era Scarecrow wrote:
I have a perfect solution! Have a special monitor that can
transmit the images directly into your brain! No more sense
dependence issues!
And then you get to worry about people hacking your brain with bad soure code!
:)
- Jonathan
On Thursday, 17 January 2013 at 03:29:46 UTC, Jonathan M Davis
wrote:
On Thursday, January 17, 2013 03:09:35 Era Scarecrow wrote:
I have a perfect solution! Have a special monitor that can
transmit the images directly into your brain! No more sense
dependence issues!
And then you get to
On 01/17/2013 04:10 AM, Mehrdad wrote:
On Wednesday, 16 January 2013 at 22:29:10 UTC, Marco Nembrini wrote:
On 16.01.2013 20:07, Mehrdad wrote:
When you have a ton of similar lines of code which need to be edited in
parallel, lining them up lets you edit all of them in one keystroke.
Saves
On Tuesday, 15 January 2013 at 23:57:44 UTC, Rob T wrote:
On Monday, 14 January 2013 at 19:24:25 UTC, Walter Bright wrote:
Quite a nice read on the coding style used in Doom.
http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550
The sad part is that after all
On Thu, Jan 17, 2013 at 06:28:30AM +0100, deadalnix wrote:
On Tuesday, 15 January 2013 at 23:57:44 UTC, Rob T wrote:
On Monday, 14 January 2013 at 19:24:25 UTC, Walter Bright wrote:
Quite a nice read on the coding style used in Doom.
On Thursday, 17 January 2013 at 05:13:51 UTC, Timon Gehr wrote:
That cannot be true. Drag alone is O(n). (eg. emacs does not
require drag!)
Er... depends on what you're talking about.
I'm talking about clicks/keypresses, not drags. 1 drag == 1
operation.
On Thursday, 17 January 2013 at 06:52:39 UTC, H. S. Teoh wrote:
On Thu, Jan 17, 2013 at 06:28:30AM +0100, deadalnix wrote:
We are using writing to communicate between people for
thousands of year now. This is clearly the most efficient way
to express idea, including to a computer.
Not to
On Tuesday, 15 January 2013 at 07:38:01 UTC, Jacob Carlborg wrote:
On 2013-01-14 22:40, H. S. Teoh wrote:
Stream operators are teh eviil. Overloading and for I/O
was a
horrible design decision. Operator overloading should be
reserved for
numeric types. But then again, Stroustrup didn't have
On 01/14/2013 06:13 PM, H. S. Teoh wrote:
On Tue, Jan 15, 2013 at 12:57:17AM +0100, Timon Gehr wrote:
On 01/15/2013 12:26 AM, mist wrote:
[...]
- I generally can understand less at once than can possibly fit with
9th font size on 24 inch screen.
In my experience, the screen is always too
On Tuesday, 15 January 2013 at 08:29:59 UTC, monarch_dodra wrote:
Just because there is something better today doesn't mean they
were a mistake.
I'm not sure if they /were/ but they certainly /are/...
no?
Okay, how many of these streambuf methods are you familiar with?
For me that's
On 2013-01-15 08:24, Tavi Cacina wrote:
Am 15.01.2013 01:55, schrieb Stewart Gordon:
vec.erase(std::remove(vec.begin(), vec.end(), val), vec.end());
That piece of code is correct.
http://en.wikipedia.org/wiki/Erase-remove_idiom
All thanks to a terrible naming decision...
It's not remove but
On 2013-01-15 09:29, monarch_dodra wrote:
I still prefer writeln over writefln. While writefln issafe, you
can still botch the amount of args, and or flag types, in which case
writefln will throw. Writeln never throws (due to a code error).
What about the argument that a format string makes
On Monday, 14 January 2013 at 23:48:14 UTC, bearophile wrote:
And extra vertical spaces are like semantic formatting tools
for plain text - can group related blocks perfectly and speed
up reading.
The idea of not wasting lines doesn't go against the idea of
adding blank lines to create code
On Mon, 2013-01-14 at 11:24 -0800, Walter Bright wrote:
Quite a nice read on the coding style used in Doom.
http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550
On the other hand I don't like some parts of the style he is putting
forward as good.
Go has an
On Monday, 14 January 2013 at 23:57:18 UTC, Timon Gehr wrote:
This generally comes up as an argument in these discussions,
but I don't buy it. Not all development is done on a desktop
with a huge screen. And even then, there is always something to
put on it. What window manager are you using?
Well, probably I am playing good vision nazi here, as 12 font
size seems HUGE to me, far beyond the comfort zone.
On Tuesday, 15 January 2013 at 10:47:19 UTC, mist wrote:
On Monday, 14 January 2013 at 23:48:14 UTC, bearophile wrote:
And extra vertical spaces are like semantic formatting tools
for plain text - can group related blocks perfectly and speed
up reading.
The idea of not wasting lines doesn't
On 01/15/13 00:37, bearophile wrote:
Walter Bright:
http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550
From the article:
[Side note: John Carmack has stated that static analysis tools
revealed that their common bug was incorrect parameter matching
in
On 2013-58-15 11:01, Russel Winder rus...@winder.org.uk wrote:
On Mon, 2013-01-14 at 11:24 -0800, Walter Bright wrote:
Quite a nice read on the coding style used in Doom.
http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550
On the other hand I don't like
1 - 100 of 182 matches
Mail list logo
