www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Breaking backwards compatiblity

reply Walter Bright <newshound2 digitalmars.com> writes:
This statement is from Linus Torvalds about breaking binary compatibility:

https://lkml.org/lkml/2012/3/8/495

While I don't think we need to worry so much at the moment about breaking
binary 
compatibility with new D releases, we do have a big problem with breaking
source 
code compatibility.

This is why we need to have a VERY high bar for breaking changes.
Mar 09 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/09/2012 11:32 PM, Walter Bright wrote:
 This statement is from Linus Torvalds about breaking binary compatibility:

 https://lkml.org/lkml/2012/3/8/495

 While I don't think we need to worry so much at the moment about
 breaking binary compatibility with new D releases, we do have a big
 problem with breaking source code compatibility.

 This is why we need to have a VERY high bar for breaking changes.
Most bug fixes are breaking changes. I don't think we are there yet.
Mar 09 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/9/2012 2:41 PM, Timon Gehr wrote:
 On 03/09/2012 11:32 PM, Walter Bright wrote:
 This statement is from Linus Torvalds about breaking binary compatibility:

 https://lkml.org/lkml/2012/3/8/495

 While I don't think we need to worry so much at the moment about
 breaking binary compatibility with new D releases, we do have a big
 problem with breaking source code compatibility.

 This is why we need to have a VERY high bar for breaking changes.
Most bug fixes are breaking changes. I don't think we are there yet.
There have been some gratuitous ones, in my not-so-humble opinion. Those need to stop.
Mar 09 2012
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, March 09, 2012 14:44:05 Walter Bright wrote:
 On 3/9/2012 2:41 PM, Timon Gehr wrote:
 On 03/09/2012 11:32 PM, Walter Bright wrote:
 This statement is from Linus Torvalds about breaking binary
 compatibility:
 
 https://lkml.org/lkml/2012/3/8/495
 
 While I don't think we need to worry so much at the moment about
 breaking binary compatibility with new D releases, we do have a big
 problem with breaking source code compatibility.
 
 This is why we need to have a VERY high bar for breaking changes.
Most bug fixes are breaking changes. I don't think we are there yet.
There have been some gratuitous ones, in my not-so-humble opinion. Those need to stop.
Do you have any specific ones in mind? There were a number of them to try and make it so that names were more consistent with regards to camelcasing and the like, but those changes have largely stopped (or at least are well into the deprecation process if they haven't been completed yet). The only stuff along those lines that I'm aware of at the moment is the discussion on making some changes to some of the function names in core.time and std.datetime, because some people don't like some of them. And no such changes have been made yet (though there are people are still looking to make some of them). - Jonathan M Davis
Mar 09 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/9/2012 2:56 PM, Jonathan M Davis wrote:
 Do you have any specific ones in mind? There were a number of them to try and
 make it so that names were more consistent with regards to camelcasing and the
 like, but those changes have largely stopped (or at least are well into the
 deprecation process if they haven't been completed yet).
I've voiced my objections to changing those names before. I know it's a done deal now.
Mar 09 2012
prev sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Friday, 9 March 2012 at 22:41:22 UTC, Timon Gehr wrote:
 Most bug fixes are breaking changes. I don't think we are there 
 yet.
In my opinion, this is a very interesting and important observation – due to the powerful meta-programming and reflection capabilities, most of the time the question is not whether a change is backward compatibile or not, but rather how _likely_ it is to break code. There isn't really a good way to avoid that, even more so if your language allow testing whether a given piece of code compiles or not. A related problem is that we still don't quite have an appropriate language spec, so you can never be sure if you code is really »correct« or if you are relying on DMD implementation details – I'm sure everybody who had their meta-programming heavy code break due to a seemingly unrelated DMD bugfix knows what I'm trying to say… David
Mar 11 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 11/03/2012 22:59, David Nadlinger a écrit :
 On Friday, 9 March 2012 at 22:41:22 UTC, Timon Gehr wrote:
 Most bug fixes are breaking changes. I don't think we are there yet.
In my opinion, this is a very interesting and important observation – due to the powerful meta-programming and reflection capabilities, most of the time the question is not whether a change is backward compatibile or not, but rather how _likely_ it is to break code. There isn't really a good way to avoid that, even more so if your language allow testing whether a given piece of code compiles or not. A related problem is that we still don't quite have an appropriate language spec, so you can never be sure if you code is really »correct« or if you are relying on DMD implementation details – I'm sure everybody who had their meta-programming heavy code break due to a seemingly unrelated DMD bugfix knows what I'm trying to say… David
D is very tied to DMD's implementation. This may be not good, but it is too soon to maintain several compilers.
Mar 11 2012
prev sibling next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 09-03-2012 23:32, Walter Bright wrote:
 This statement is from Linus Torvalds about breaking binary compatibility:

 https://lkml.org/lkml/2012/3/8/495

 While I don't think we need to worry so much at the moment about
 breaking binary compatibility with new D releases, we do have a big
 problem with breaking source code compatibility.

 This is why we need to have a VERY high bar for breaking changes.
If we want to start being able to avoid breaking changes, we *really* need to finally deprecate the stuff that's been slated for deprecation for ages... -- - Alex
Mar 09 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Mar 09, 2012 at 11:46:24PM +0100, Alex Rønne Petersen wrote:
 On 09-03-2012 23:32, Walter Bright wrote:
This statement is from Linus Torvalds about breaking binary compatibility:

https://lkml.org/lkml/2012/3/8/495

While I don't think we need to worry so much at the moment about
breaking binary compatibility with new D releases, we do have a big
problem with breaking source code compatibility.

This is why we need to have a VERY high bar for breaking changes.
If we want to start being able to avoid breaking changes, we *really* need to finally deprecate the stuff that's been slated for deprecation for ages...
[...] Does that include std.stdio and std.stream? When are we expecting std.io to be ready? IMHO, this is one major change that needs to happen sooner rather than later. The current lack of interoperability between std.stdio and std.stream is a big detraction from Phobos' overall quality. T -- Жил-был король когда-то, при нём блоха жила.
Mar 09 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 10-03-2012 00:14, H. S. Teoh wrote:
 On Fri, Mar 09, 2012 at 11:46:24PM +0100, Alex Rønne Petersen wrote:
 On 09-03-2012 23:32, Walter Bright wrote:
 This statement is from Linus Torvalds about breaking binary compatibility:

 https://lkml.org/lkml/2012/3/8/495

 While I don't think we need to worry so much at the moment about
 breaking binary compatibility with new D releases, we do have a big
 problem with breaking source code compatibility.

 This is why we need to have a VERY high bar for breaking changes.
If we want to start being able to avoid breaking changes, we *really* need to finally deprecate the stuff that's been slated for deprecation for ages...
[...] Does that include std.stdio and std.stream? When are we expecting std.io to be ready? IMHO, this is one major change that needs to happen sooner rather than later. The current lack of interoperability between std.stdio and std.stream is a big detraction from Phobos' overall quality. T
Well, I was mostly thinking language-wise. But yeah, those too. -- - Alex
Mar 09 2012
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 09 Mar 2012 18:14:39 -0500, H. S. Teoh <hsteoh quickfur.ath.cx> =
 =

wrote:

 On Fri, Mar 09, 2012 at 11:46:24PM +0100, Alex R=C3=B8nne Petersen wro=
te:
 On 09-03-2012 23:32, Walter Bright wrote:
This statement is from Linus Torvalds about breaking binary  =
 compatibility:
https://lkml.org/lkml/2012/3/8/495

While I don't think we need to worry so much at the moment about
breaking binary compatibility with new D releases, we do have a big
problem with breaking source code compatibility.

This is why we need to have a VERY high bar for breaking changes.
If we want to start being able to avoid breaking changes, we *really* need to finally deprecate the stuff that's been slated for deprecation for ages...
[...] Does that include std.stdio and std.stream? When are we expecting std.=
io
 to be ready?
Sadly, I have no guarantees for when it will be ready. The rewrite is = mostly in place, what I'm struggling with is how to make it backwards = compatible with std.stdio. Specifically, I think I need to rewrite = std.typecons.RefCounted to be more flexible.
 IMHO, this is one major change that needs to happen sooner rather than=
 later. The current lack of interoperability between std.stdio and
 std.stream is a big detraction from Phobos' overall quality.
I agree, as I watch other modules which would benefit from the rewrite g= et = more attention, I cringe hoping that it doesn't introduce something that= = would necessitate a complete rewrite with the new system (thereby making= = my case for rewriting std.stdio weaker). It's my number 1 priority for D. The problem is that D is not my number= 1 = priority right now :( If you want to take a look so far (I haven't compiled in a long time sin= ce = starting the migration to backwards compatibility): https://github.com/schveiguy/phobos/blob/new-io2/std/io.d I also have a trello card for it... -Steve
Mar 09 2012
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Linus would probably hate D just as much as he hates C++. :p
Mar 09 2012
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/9/2012 4:02 PM, Andrej Mitrovic wrote:
 Linus would probably hate D just as much as he hates C++. :p
It's clear to me from Linus' postings that he would not be interested in D. And that's ok. He's doing what works for him, and it's hard to argue with his success at it.
Mar 09 2012
prev sibling parent "so" <so so.so> writes:
On Saturday, 10 March 2012 at 00:02:44 UTC, Andrej Mitrovic wrote:
 Linus would probably hate D just as much as he hates C++. :p
Rather then using ones influence to make a better language (C) it is much easier to bitch about attempts made by others.
Mar 09 2012
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 01:02:35AM +0100, Andrej Mitrovic wrote:
 Linus would probably hate D just as much as he hates C++. :p
Yeah... I can just imagine his eye scanning the description of D and stopping right at the word "GC", and immediately writing a flaming vitriolic post to LKML about how a GC is the absolutely worst thing one could possibly conceive of putting inside a kernel, and that any kernel developer caught flirting with the idea of using D ought to have all kernel patches ignored from that point on. :-) T -- Amateurs built the Ark; professionals built the Titanic.
Mar 09 2012
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 10-03-2012 01:15, H. S. Teoh wrote:
 On Sat, Mar 10, 2012 at 01:02:35AM +0100, Andrej Mitrovic wrote:
 Linus would probably hate D just as much as he hates C++. :p
Yeah... I can just imagine his eye scanning the description of D and stopping right at the word "GC", and immediately writing a flaming vitriolic post to LKML about how a GC is the absolutely worst thing one could possibly conceive of putting inside a kernel, and that any kernel developer caught flirting with the idea of using D ought to have all kernel patches ignored from that point on. :-) T
In all fairness, a stop-the-world GC in a kernel probably *is* a horrible idea. -- - Alex
Mar 10 2012
next sibling parent reply "so" <so so.so> writes:
On Saturday, 10 March 2012 at 08:53:23 UTC, Alex Rønne Petersen 
wrote:

 In all fairness, a stop-the-world GC in a kernel probably *is* 
 a horrible idea.
For us (desktop users), it would not differ much would it now?
Mar 10 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 10-03-2012 10:09, so wrote:
 On Saturday, 10 March 2012 at 08:53:23 UTC, Alex Rønne Petersen wrote:

 In all fairness, a stop-the-world GC in a kernel probably *is* a
 horrible idea.
For us (desktop users), it would not differ much would it now?
Linux was never intended to be a pure desktop kernel. It's used widely in server and embedded machines. -- - Alex
Mar 10 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, March 10, 2012 10:12:44 Alex R=C3=B8nne Petersen wrote:
 On 10-03-2012 10:09, so wrote:
 On Saturday, 10 March 2012 at 08:53:23 UTC, Alex R=C3=B8nne Peterse=
n wrote:
 In all fairness, a stop-the-world GC in a kernel probably *is* a
 horrible idea.
=20 For us (desktop users), it would not differ much would it now?
=20 Linux was never intended to be a pure desktop kernel. It's used widel=
y
 in server and embedded machines.
And actually, when _responsiveness_ is one of the key features that a d= esktop=20 OS requires, a stop-the-world GC in a desktop would probably be _worse_= than=20 one in a server. - Jonathan M Davis
Mar 10 2012
parent reply "so" <so so.so> writes:
On Saturday, 10 March 2012 at 09:17:37 UTC, Jonathan M Davis 
wrote:

 And actually, when _responsiveness_ is one of the key features 
 that a desktop
 OS requires, a stop-the-world GC in a desktop would probably be 
 _worse_ than
 one in a server.
My point is, every operation, even a mouse movement is already a stop-the-world event for all the "modern" operating systems i have encountered and Linux manages to take this to ridiculous levels.
Mar 10 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 10:30:46AM +0100, so wrote:
 On Saturday, 10 March 2012 at 09:17:37 UTC, Jonathan M Davis wrote:
 
And actually, when _responsiveness_ is one of the key features that a
desktop OS requires, a stop-the-world GC in a desktop would probably
be _worse_ than one in a server.
My point is, every operation, even a mouse movement is already a stop-the-world event for all the "modern" operating systems i have encountered and Linux manages to take this to ridiculous levels.
[...] Huh??! Since when is mouse movement a stop-the-world event on Linux? I've been using Linux for the past 15 years and have never seen such a thing. T -- Some ideas are so stupid that only intellectuals could believe them. -- George Orwell
Mar 10 2012
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 10 March 2012 at 15:19:15 UTC, H. S. Teoh wrote:
 Since when is mouse movement a stop-the-world event on Linux?
It's a hardware interrupt. They all work that way. You have to give a lot of care to handling them very quickly and not letting them stack up (lest the whole system freeze).
Mar 10 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 04:23:43PM +0100, Adam D. Ruppe wrote:
 On Saturday, 10 March 2012 at 15:19:15 UTC, H. S. Teoh wrote:
Since when is mouse movement a stop-the-world event on Linux?
It's a hardware interrupt. They all work that way. You have to give a lot of care to handling them very quickly and not letting them stack up (lest the whole system freeze).
Sure, but I've never seen a problem with that. T -- This is a tpyo.
Mar 10 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 10-03-2012 16:28, H. S. Teoh wrote:
 On Sat, Mar 10, 2012 at 04:23:43PM +0100, Adam D. Ruppe wrote:
 On Saturday, 10 March 2012 at 15:19:15 UTC, H. S. Teoh wrote:
 Since when is mouse movement a stop-the-world event on Linux?
It's a hardware interrupt. They all work that way. You have to give a lot of care to handling them very quickly and not letting them stack up (lest the whole system freeze).
Sure, but I've never seen a problem with that. T
A GC world stop is much more severe than a simple interrupt... This comparison is completely insane. -- - Alex
Mar 10 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 10 March 2012 at 15:27:00 UTC, H. S. Teoh wrote:
 Sure, but I've never seen a problem with that.
I used to back on Windows 95. You could work that computer hard enough that the poor thing just couldn't keep up.
Mar 10 2012
prev sibling parent reply "so" <so so.so> writes:
On Saturday, 10 March 2012 at 15:27:00 UTC, H. S. Teoh wrote:
 On Sat, Mar 10, 2012 at 04:23:43PM +0100, Adam D. Ruppe wrote:
 On Saturday, 10 March 2012 at 15:19:15 UTC, H. S. Teoh wrote:
Since when is mouse movement a stop-the-world event on Linux?
It's a hardware interrupt. They all work that way. You have to give a lot of care to handling them very quickly and not letting them stack up (lest the whole system freeze).
Sure, but I've never seen a problem with that.
Neither the OS developers, especially when they are on 999kTB ram and 1billion core processors.
Mar 10 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 06:41:24PM +0100, so wrote:
 On Saturday, 10 March 2012 at 15:27:00 UTC, H. S. Teoh wrote:
On Sat, Mar 10, 2012 at 04:23:43PM +0100, Adam D. Ruppe wrote:
On Saturday, 10 March 2012 at 15:19:15 UTC, H. S. Teoh wrote:
Since when is mouse movement a stop-the-world event on Linux?
It's a hardware interrupt. They all work that way. You have to give a lot of care to handling them very quickly and not letting them stack up (lest the whole system freeze).
Sure, but I've never seen a problem with that.
Neither the OS developers, especially when they are on 999kTB ram and 1billion core processors.
[...] Um... before my recent upgrade (about a year ago), I had been using a 500MB (or was it 100MB?) RAM machine running a 10-year-old processor. And before *that*, it was a 64MB (or 32MB?) machine running a 15-year-old processor... Then again, I never believed in the desktop metaphor, and have never seriously used Gnome or KDE or any of that fluffy stuff. I was on VTWM until I decided ratpoison (a mouseless WM) better suited the way I worked. T -- Who told you to swim in Crocodile Lake without life insurance??
Mar 10 2012
parent reply "so" <so so.so> writes:
On Saturday, 10 March 2012 at 17:51:28 UTC, H. S. Teoh wrote:

 Um... before my recent upgrade (about a year ago), I had been 
 using a
 500MB (or was it 100MB?) RAM machine running a 10-year-old 
 processor.
 And before *that*, it was a 64MB (or 32MB?) machine running a
 15-year-old processor...

 Then again, I never believed in the desktop metaphor, and have 
 never
 seriously used Gnome or KDE or any of that fluffy stuff. I was 
 on VTWM
 until I decided ratpoison (a mouseless WM) better suited the 
 way I
 worked.
I am also using light window managers. Most of the time only tmux and gvim running. I tried many WMs but if you are using it frequently and don't like falling back to windows and such, you need a WM working seamlessly with GUIs. Gimp is one. (You might not believe in desktop but how would you use a program like Gimp?) Now most of the tiling WMs suck at handling that kind of thing. Using xmonad now, at least it has a little better support.
Mar 10 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 07:23:11PM +0100, so wrote:
 On Saturday, 10 March 2012 at 17:51:28 UTC, H. S. Teoh wrote:
[...]
Then again, I never believed in the desktop metaphor, and have never
seriously used Gnome or KDE or any of that fluffy stuff. I was on
VTWM until I decided ratpoison (a mouseless WM) better suited the way
I worked.
I am also using light window managers. Most of the time only tmux and gvim running. I tried many WMs but if you are using it frequently and don't like falling back to windows and such, you need a WM working seamlessly with GUIs. Gimp is one. (You might not believe in desktop but how would you use a program like Gimp?) Now most of the tiling WMs suck at handling that kind of thing. Using xmonad now, at least it has a little better support.
I don't use tiling WMs. And frankly, Gimp's multi-window interface (or OpenOffice, I mean, LibreOffice, for that matter) is very annoying. That's why I don't use gimp very much. I just use command-line imagemagick tools to do stuff. And when I need to generate complex images, I use povray. :-P (Or write my own image generating algos.) But I don't do much fancy stuff with images anyway, otherwise I would've figured out a way to make gimp work nicely. But on the point of WMs, the only *real* GUI app that I use regularly is the browser. (And Skype, only because the people I want to talk to are on the other side of the world and they only have Skype. But this is only once a week as opposed to every day.) I pull up OpenOffice / LibreOffice every now and then, under protest, when it's *absolutely* necessary. Pretty much everything else I do in the terminal. So I don't really use any "desktop" features at all anyway. That's why I like ratpoison: maximize everything, no overlapping/tiling windows, and keyboard controls for everything. T -- Real Programmers use "cat > a.out".
Mar 10 2012
prev sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Adam D. Ruppe wrote:
 On Saturday, 10 March 2012 at 15:19:15 UTC, H. S. Teoh wrote:
 Since when is mouse movement a stop-the-world event on Linux?
=20 It's a hardware interrupt. They all work that way. You have to give a lot of care to handling them very quickly and not letting them stack up (lest the whole system freeze).
So? It's not stop-the-world. While one core is handling the interrupt, the other(s) is(are) still running. A stop-the-world GC would need to block all threads on all cores while running. Jerome PS: This is nothing restricted to Linux. Windows, MacOS X and the *BSDs have the same behaviour. --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Mar 10 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 04:35:26PM +0100, "Jérôme M. Berger" wrote:
 Adam D. Ruppe wrote:
 On Saturday, 10 March 2012 at 15:19:15 UTC, H. S. Teoh wrote:
 Since when is mouse movement a stop-the-world event on Linux?
It's a hardware interrupt. They all work that way. You have to give a lot of care to handling them very quickly and not letting them stack up (lest the whole system freeze).
So? It's not stop-the-world. While one core is handling the interrupt, the other(s) is(are) still running. A stop-the-world GC would need to block all threads on all cores while running. Jerome PS: This is nothing restricted to Linux. Windows, MacOS X and the *BSDs have the same behaviour.
[...] OK, clearly I wasn't understanding what the OP was talking about. It *seemed* to imply that Linux had stop-the-world problems with mouse movement, but this isn't the case. A hardware interrupt is a hardware interrupt. Whatever OS you're using, it's got to stop to handle this somehow. I don't see how else you can do this. When the hardware needs to signal the OS about something, it's gotta do it somehow. And hardware often requires top-priority stop-the-world handling, because it may not be able to wait a few milliseconds before it's handled. It's not like software that generally can afford to wait for a period of time. As for Win95 being unable to keep up with mouse movement... well, to be honest I hated Win95 so much that 90% of the time I was in the DOS prompt anyway, so I didn't even notice this. If it were truly a problem, it's probably a sign of poor hardware interrupt handling (interrupt handler is taking too long to process events). But I haven't seen this myself either. T -- Lottery: tax on the stupid. -- Slashdotter
Mar 10 2012
parent reply "so" <so so.so> writes:
On Saturday, 10 March 2012 at 16:22:41 UTC, H. S. Teoh wrote:

 OK, clearly I wasn't understanding what the OP was talking 
 about. It
 *seemed* to imply that Linux had stop-the-world problems with 
 mouse
 movement, but this isn't the case.

 A hardware interrupt is a hardware interrupt. Whatever OS 
 you're using,
 it's got to stop to handle this somehow. I don't see how else 
 you can do
 this. When the hardware needs to signal the OS about something, 
 it's
 gotta do it somehow. And hardware often requires top-priority
 stop-the-world handling, because it may not be able to wait a 
 few
 milliseconds before it's handled. It's not like software that 
 generally
 can afford to wait for a period of time.

 As for Win95 being unable to keep up with mouse movement... 
 well, to be
 honest I hated Win95 so much that 90% of the time I was in the 
 DOS
 prompt anyway, so I didn't even notice this. If it were truly a 
 problem,
 it's probably a sign of poor hardware interrupt handling 
 (interrupt
 handler is taking too long to process events). But I haven't 
 seen this
 myself either.
Design of input handling, the theoretical part is irrelevant. I was solely talking about how they do it in practice. OSs are simply unresponsive and in linux it is more severe. If i am having this issue in practice it doesn't matter if it was the GC lock or an another failure to handle input.
Mar 10 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 06:49:02PM +0100, so wrote:
 On Saturday, 10 March 2012 at 16:22:41 UTC, H. S. Teoh wrote:
[...]
As for Win95 being unable to keep up with mouse movement... well, to
be honest I hated Win95 so much that 90% of the time I was in the DOS
prompt anyway, so I didn't even notice this. If it were truly a
problem, it's probably a sign of poor hardware interrupt handling
(interrupt handler is taking too long to process events). But I
haven't seen this myself either.
Design of input handling, the theoretical part is irrelevant. I was solely talking about how they do it in practice. OSs are simply unresponsive and in linux it is more severe. If i am having this issue in practice it doesn't matter if it was the GC lock or an another failure to handle input.
Then you must be running a very different Linux from the one I use. In my experience, it's Windows that's an order of magnitude less responsive due to constant HD thrashing (esp. on bootup, and then periodically thereafter) and too much eye-candy. (Then again, I don't use graphics-heavy UIs... on Linux you can turn most of it off, and I do, but on Windows you have no choice. So perhaps it's more a measure of how I configured my system than anything else. I tried doing this in Windows once, and let's just say that I'll never, ever, even _dream_ of attempting it again, it was that painful.) T -- I'm still trying to find a pun for "punishment"...
Mar 10 2012
next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 10-03-2012 18:58, H. S. Teoh wrote:
 On Sat, Mar 10, 2012 at 06:49:02PM +0100, so wrote:
 On Saturday, 10 March 2012 at 16:22:41 UTC, H. S. Teoh wrote:
[...]
 As for Win95 being unable to keep up with mouse movement... well, to
 be honest I hated Win95 so much that 90% of the time I was in the DOS
 prompt anyway, so I didn't even notice this. If it were truly a
 problem, it's probably a sign of poor hardware interrupt handling
 (interrupt handler is taking too long to process events). But I
 haven't seen this myself either.
Design of input handling, the theoretical part is irrelevant. I was solely talking about how they do it in practice. OSs are simply unresponsive and in linux it is more severe. If i am having this issue in practice it doesn't matter if it was the GC lock or an another failure to handle input.
Then you must be running a very different Linux from the one I use. In my experience, it's Windows that's an order of magnitude less responsive due to constant HD thrashing (esp. on bootup, and then periodically thereafter) and too much eye-candy.
This. On the other hand, OS X has all the eye candy and is still extremely responsive. ;)
 (Then again, I don't use graphics-heavy UIs... on Linux you can turn
 most of it off, and I do, but on Windows you have no choice. So perhaps
 it's more a measure of how I configured my system than anything else. I
 tried doing this in Windows once, and let's just say that I'll never,
 ever, even _dream_ of attempting it again, it was that painful.)


 T
-- - Alex
Mar 10 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 07:44:10PM +0100, Alex Rønne Petersen wrote:
 On 10-03-2012 18:58, H. S. Teoh wrote:
On Sat, Mar 10, 2012 at 06:49:02PM +0100, so wrote:
[...]
Design of input handling, the theoretical part is irrelevant. I was
solely talking about how they do it in practice. OSs are simply
unresponsive and in linux it is more severe. If i am having this
issue in practice it doesn't matter if it was the GC lock or an
another failure to handle input.
Then you must be running a very different Linux from the one I use. In my experience, it's Windows that's an order of magnitude less responsive due to constant HD thrashing (esp. on bootup, and then periodically thereafter) and too much eye-candy.
This. On the other hand, OS X has all the eye candy and is still extremely responsive. ;)
But if I wanted eye candy, I'd be using Windows in the first place. :-) T -- They pretend to pay us, and we pretend to work. -- Russian saying
Mar 10 2012
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 10-03-2012 19:54, H. S. Teoh wrote:
 On Sat, Mar 10, 2012 at 07:44:10PM +0100, Alex Rønne Petersen wrote:
 On 10-03-2012 18:58, H. S. Teoh wrote:
 On Sat, Mar 10, 2012 at 06:49:02PM +0100, so wrote:
[...]
 Design of input handling, the theoretical part is irrelevant. I was
 solely talking about how they do it in practice. OSs are simply
 unresponsive and in linux it is more severe. If i am having this
 issue in practice it doesn't matter if it was the GC lock or an
 another failure to handle input.
Then you must be running a very different Linux from the one I use. In my experience, it's Windows that's an order of magnitude less responsive due to constant HD thrashing (esp. on bootup, and then periodically thereafter) and too much eye-candy.
This. On the other hand, OS X has all the eye candy and is still extremely responsive. ;)
But if I wanted eye candy, I'd be using Windows in the first place. :-) T
Personally I'm all for OS X; it's a good UI on top of a Unix shell - what's not to love? But I don't intend to start an OS war or anything here... :P -- - Alex
Mar 10 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Alex Rønne Petersen" <xtzgzorex gmail.com> wrote in message 
news:jjg8e8$46e$1 digitalmars.com...
 Personally I'm all for OS X; it's a good UI
Compared to CDE, yes.
 on top of a Unix shell - what's not to love?

 But I don't intend to start an OS war or anything here... :P
Oh, it's ON! j/k ;)
Mar 10 2012
prev sibling parent "Tove" <tove fransson.se> writes:
On Saturday, 10 March 2012 at 19:01:29 UTC, Alex Rønne Petersen 
wrote:
 Personally I'm all for OS X; it's a good UI on top of a Unix 
 shell - what's not to love?

 But I don't intend to start an OS war or anything here... :P
On "paper"(based on features) OS X has been my first OS of choice since the day it was launched... yet I never once tried it, as there are no sane hardware options. :( Since I require a Discrete Graphics Card, "Mac Pro" is the only choice available, but it's a workstation class computer, however considering I don't have any mission critical requirements for my home computer... the 100% price premium is not justified.
Mar 10 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Alex Rønne Petersen" <xtzgzorex gmail.com> wrote in message 
news:jjg7dq$24q$1 digitalmars.com...
 On 10-03-2012 18:58, H. S. Teoh wrote:
 Then you must be running a very different Linux from the one I use. In
 my experience, it's Windows that's an order of magnitude less responsive
 due to constant HD thrashing (esp. on bootup, and then periodically
 thereafter) and too much eye-candy.
This. On the other hand, OS X has all the eye candy and is still extremely responsive. ;)
That's because they cram [their] hardware upgrades down your throat every couple years.
Mar 10 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 02:23:15PM -0500, Nick Sabalausky wrote:
 "Alex Rønne Petersen" <xtzgzorex gmail.com> wrote in message 
 news:jjg7dq$24q$1 digitalmars.com...
 On 10-03-2012 18:58, H. S. Teoh wrote:
 Then you must be running a very different Linux from the one I use.
 In my experience, it's Windows that's an order of magnitude less
 responsive due to constant HD thrashing (esp. on bootup, and then
 periodically thereafter) and too much eye-candy.
This. On the other hand, OS X has all the eye candy and is still extremely responsive. ;)
That's because they cram [their] hardware upgrades down your throat every couple years.
[...] Yikes. That would *not* sit well with me. Before my last upgrade, my PC was at least 10 years old. (And the upgrade before that was at least 5 years prior.) Last year I finally replaced my 10 y.o. PC with a brand new AMD hexacore system. The plan being to not upgrade for at least the next 10 years, preferably more. :-) (Maybe by then, Intel's currently-experimental 80-core system would be out in the consumer market, and I'll be a really happy geek sitting in the corner watching 1000 instances of povray cranking out images at lightning speed like there's no tomorrow.) T -- "Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next. -- (Stolen from the net)
Mar 10 2012
prev sibling next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 10-03-2012 20:23, Nick Sabalausky wrote:
 "Alex Rønne Petersen"<xtzgzorex gmail.com>  wrote in message
 news:jjg7dq$24q$1 digitalmars.com...
 On 10-03-2012 18:58, H. S. Teoh wrote:
 Then you must be running a very different Linux from the one I use. In
 my experience, it's Windows that's an order of magnitude less responsive
 due to constant HD thrashing (esp. on bootup, and then periodically
 thereafter) and too much eye-candy.
This. On the other hand, OS X has all the eye candy and is still extremely responsive. ;)
That's because they cram [their] hardware upgrades down your throat every couple years.
No one forces you to upgrade. -- - Alex
Mar 10 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, March 10, 2012 20:48:05 Alex R=C3=B8nne Petersen wrote:
 No one forces you to upgrade.
What, you've never had the Apple police come to your door and force a n= ew=20 computer on you at gunpoint? ;) - Jonathan M Davis
Mar 10 2012
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Alex Rønne Petersen" <xtzgzorex gmail.com> wrote in message 
news:jjgb5l$94f$1 digitalmars.com...
 On 10-03-2012 20:23, Nick Sabalausky wrote:
 "Alex Rønne Petersen"<xtzgzorex gmail.com>  wrote in message
 news:jjg7dq$24q$1 digitalmars.com...
 On 10-03-2012 18:58, H. S. Teoh wrote:
 Then you must be running a very different Linux from the one I use. In
 my experience, it's Windows that's an order of magnitude less 
 responsive
 due to constant HD thrashing (esp. on bootup, and then periodically
 thereafter) and too much eye-candy.
This. On the other hand, OS X has all the eye candy and is still extremely responsive. ;)
That's because they cram [their] hardware upgrades down your throat every couple years.
No one forces you to upgrade.
That's true. They just say "You *could* stick with your ancient two-year-old machine...You'll be shit out of luck when you need to install anything...but yea, we'll *cough* 'let' *cough* you do it...hee hee hee."
Mar 10 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, March 10, 2012 11:49:22 H. S. Teoh wrote:
 Yikes. That would *not* sit well with me. Before my last upgrade, my PC
 was at least 10 years old. (And the upgrade before that was at least 5
 years prior.) Last year I finally replaced my 10 y.o. PC with a brand
 new AMD hexacore system. The plan being to not upgrade for at least the
 next 10 years, preferably more. :-)
LOL. I'm the complete opposite. I seem to end up upgrading my computer every 2 or 3 years. I wouldn't be able to stand being on an older computer that long. I'm constantly annoyed by how slow my computer is no matter how new it is. Of course, I do tend to stress my machine quite a lot by having a ton of stuff open all the time and doing CPU-intensive stuff like transcoding video, and how you use your computer is a definite factor in how much value there is in upgrading. - Jonathan M Davis
Mar 10 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.428.1331409260.4860.digitalmars-d puremagic.com...
 On Saturday, March 10, 2012 11:49:22 H. S. Teoh wrote:
 Yikes. That would *not* sit well with me. Before my last upgrade, my PC
 was at least 10 years old. (And the upgrade before that was at least 5
 years prior.) Last year I finally replaced my 10 y.o. PC with a brand
 new AMD hexacore system. The plan being to not upgrade for at least the
 next 10 years, preferably more. :-)
LOL. I'm the complete opposite. I seem to end up upgrading my computer every 2 or 3 years. I wouldn't be able to stand being on an older computer that long. I'm constantly annoyed by how slow my computer is no matter how new it is. Of course, I do tend to stress my machine quite a lot by having a ton of stuff open all the time and doing CPU-intensive stuff like transcoding video, and how you use your computer is a definite factor in how much value there is in upgrading.
With the exception of notably-expensive things like video processing, ever since CPUs hit the GHz mark (and arguably for some time before that), there has been *no* reason to blame slowness on anything other than shitty software. My Apple IIc literally had more responsive text entry than at least half of the textarea boxes on the modern web. Slowness is *not* a hardware issue anymore, and hasn't been for a long time. You know what *really* happens when you upgrade to a computer that's, say, twice as fast with twice as much memory? About 90% of the so-called "programmers" out there decide "Hey, now I can get away with my software being twice as slow and eat up twice as much memory! And it's all on *my user's* dime!" You're literally paying for programmer laziness. I just stick with software that isn't bloated. I get just as much speed, but without all that cost. (Again, there are obviously exceptions, like video processing, DNA processing, etc.)
Mar 10 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, March 10, 2012 16:08:28 Nick Sabalausky wrote:
 With the exception of notably-expensive things like video processing, ever
 since CPUs hit the GHz mark (and arguably for some time before that), there
 has been *no* reason to blame slowness on anything other than shitty
 software.
 
 My Apple IIc literally had more responsive text entry than at least half of
 the textarea boxes on the modern web. Slowness is *not* a hardware issue
 anymore, and hasn't been for a long time.
 
 You know what *really* happens when you upgrade to a computer that's, say,
 twice as fast with twice as much memory? About 90% of the so-called
 "programmers" out there decide "Hey, now I can get away with my software
 being twice as slow and eat up twice as much memory! And it's all on *my
 user's* dime!" You're literally paying for programmer laziness.
 
 I just stick with software that isn't bloated. I get just as much speed, but
 without all that cost.
Yeah. CPU is not the issue. I/O and/or memory tends to be the bottleneck for most stuff - at least for me. Getting a faster CPU wouldn't make my computer any more responsive.
 (Again, there are obviously exceptions, like video processing, DNA
 processing, etc.)
I do plenty of that sort of thing though, so CPU really does matter quite a bit to me, even if it doesn't affect my normal computing much. When transcoding video, CPU speed makes a _huge_ difference. - Jonathan M Davis
Mar 10 2012
parent "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.438.1331414665.4860.digitalmars-d puremagic.com...
 On Saturday, March 10, 2012 16:08:28 Nick Sabalausky wrote:
 With the exception of notably-expensive things like video processing, 
 ever
 since CPUs hit the GHz mark (and arguably for some time before that), 
 there
 has been *no* reason to blame slowness on anything other than shitty
 software.

 My Apple IIc literally had more responsive text entry than at least half 
 of
 the textarea boxes on the modern web. Slowness is *not* a hardware issue
 anymore, and hasn't been for a long time.

 You know what *really* happens when you upgrade to a computer that's, 
 say,
 twice as fast with twice as much memory? About 90% of the so-called
 "programmers" out there decide "Hey, now I can get away with my software
 being twice as slow and eat up twice as much memory! And it's all on *my
 user's* dime!" You're literally paying for programmer laziness.

 I just stick with software that isn't bloated. I get just as much speed, 
 but
 without all that cost.
Yeah. CPU is not the issue. I/O and/or memory tends to be the bottleneck for most stuff - at least for me. Getting a faster CPU wouldn't make my computer any more responsive.
Well, all those busses, I/O devices, etc, are still a lot faster than they were back in, say, the 486 or Pentium 1 days, and things were plenty responsive then, too. But, I do agree, like you say, it *does* depend on what you're doing. If you're doing a lot of video as you say, then I completely understand.
Mar 10 2012
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 04:08:28PM -0500, Nick Sabalausky wrote:
[...]
 My Apple IIc literally had more responsive text entry than at least
 half of the textarea boxes on the modern web. Slowness is *not* a
 hardware issue anymore, and hasn't been for a long time.
Ugh. You remind me of the early releases of Mozilla, where loading the *UI* would slow my machine down to a crawl (if not to a literal stop). Needless to say actually browsing. I stuck with Netscape 4 for as long as I could get away with, and then switched to Opera because it could do everything Mozilla did at 10 times the speed. Sad to say, recent versions of Opera (and Firefox) have become massive memory and disk hogs. I still mainly use Opera because I like the interface better, but sometimes I have the misfortune of needing Firefox for some newfangled Javascript nonsense that the GUI team at my day job were arm-twisted to implement by the PTBs. Running *both* Firefox and Opera simultaneously, with some heavy-duty Javascript going on in Firefox, routinely soaks up all RAM, hogs the disk at 99% usage, and renders the PC essentially unusable. Exiting one (or preferably both) of them immediately solves the problem. And people keep talking about web apps and the browser as a "platform". Sigh.
 You know what *really* happens when you upgrade to a computer that's,
 say, twice as fast with twice as much memory? About 90% of the
 so-called "programmers" out there decide "Hey, now I can get away with
 my software being twice as slow and eat up twice as much memory! And
 it's all on *my user's* dime!" You're literally paying for programmer
 laziness.
Or worse, "Hey look! We can add goofy animations to every aspect of our UI to hog all CPU and memory, because users love eye-candy and will be induced to upgrade! We get a kickback from our hardware manufacturers and we sell more software without actually adding any new features! It's a win-win situation!"
 I just stick with software that isn't bloated. I get just as much
 speed, but without all that cost.
I'm constantly amazed by the amount of CPU and memory needed to run a *word processor*. I mean, really?! All of that just for pushing some characters around? And I thought word-processing has been solved since the days of CP/M. Silly me.
 (Again, there are obviously exceptions, like video processing, DNA 
 processing, etc.)
[...] And povray rendering. :-) Or computing the convex hull of high-dimensional polytopes. Or solving the travelling salesman problem. Or inverting very large matrices. Y'know, actual, *hard* problems. As opposed to fiddling with some pixels and pushing some characters around. T -- Tech-savvy: euphemism for nerdy.
Mar 10 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.439.1331415624.4860.digitalmars-d puremagic.com...
 On Sat, Mar 10, 2012 at 04:08:28PM -0500, Nick Sabalausky wrote:
 [...]
 My Apple IIc literally had more responsive text entry than at least
 half of the textarea boxes on the modern web. Slowness is *not* a
 hardware issue anymore, and hasn't been for a long time.
Ugh. You remind me of the early releases of Mozilla, where loading the *UI* would slow my machine down to a crawl (if not to a literal stop). Needless to say actually browsing. I stuck with Netscape 4 for as long as I could get away with, and then switched to Opera because it could do everything Mozilla did at 10 times the speed. Sad to say, recent versions of Opera (and Firefox) have become massive memory and disk hogs. I still mainly use Opera because I like the interface better,
I couldn't beleive that Opera actually *removed* the native "skin" (even what joke it was in the first place) in the latest versions. That's why my Opera installation is staying put at v10.62. Which reminds me, I still need to figure out what domain it contacts to check whether or not to incessently nag me about *cough* "upgrading" *cough*, so I can ban the damn thing via my hosts file.
 And people keep talking about web apps and the browser as a "platform".
 Sigh.
Yea. There's even an entire company dedicated to pushing that moronic agenda (*and* tracking you like Big Brother). They're called "Microsoft Mark 2"...erm...wait...I mean "Google".
 You know what *really* happens when you upgrade to a computer that's,
 say, twice as fast with twice as much memory? About 90% of the
 so-called "programmers" out there decide "Hey, now I can get away with
 my software being twice as slow and eat up twice as much memory! And
 it's all on *my user's* dime!" You're literally paying for programmer
 laziness.
Or worse, "Hey look! We can add goofy animations to every aspect of our UI to hog all CPU and memory, because users love eye-candy and will be induced to upgrade!
Yes, seriously! "And let's not bother to allow anyone to disable the moronic UI changes even though we (*cough* Mozilla) *claim* to care about being super-configurable."
 We get a kickback from our hardware manufacturers
 and we sell more software without actually adding any new features! It's
 a win-win situation!"
That's one of the reasons I despise the modern-day Epic and Valve: *Complete* graphics whores (not to mention Microsoft sluts, particularly in Epic's case), and I don't believe for a second that what you've described isn't the exact nature of...what does Epic call it? Some sort of "Alliance" with NVIDIA and ATI that Epic was so *publically* proud of. Fuck Cliffy, Sweeny, "Fat Fuck" Newell, et al. Shit, and Epic actually used to be pretty good back in their "Megagames" days. Portal's great (honestly I hate myself for how much I *like* it ;) ), but seriously, it would be *so* much better with Wii controls instead of that dual-analog bullshit. But unlike modern game devs I'm not a graphics whore, so I don't give two shits about the tradeoff in visual quality ('Course that's still no free ride for the lazy crapjobs that were done with the Wii ports of Splinter Cell 4 and FarCry - it may not be a 360/PS3, but it sure as hell is no N64 or even any sub-XBox1 machine, as the "modern" gamedevs would have me believe).
 I just stick with software that isn't bloated. I get just as much
 speed, but without all that cost.
I'm constantly amazed by the amount of CPU and memory needed to run a *word processor*. I mean, really?! All of that just for pushing some characters around? And I thought word-processing has been solved since the days of CP/M. Silly me.
Ditto.
 (Again, there are obviously exceptions, like video processing, DNA
 processing, etc.)
[...] And povray rendering. :-) Or computing the convex hull of high-dimensional polytopes. Or solving the travelling salesman problem. Or inverting very large matrices. Y'know, actual, *hard* problems. As opposed to fiddling with some pixels and pushing some characters around.
Yup. Although I like to count non-realtime 3D rendering under the "video processing" category even though the details are very, very different from transcoding or AfterEffects and such.
 Or solving the travelling salesman problem.
That's aready been solved. Haven't you heard of eCommerce? j/k ;)
Mar 10 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 05:16:15PM -0500, Nick Sabalausky wrote:
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.439.1331415624.4860.digitalmars-d puremagic.com...
[...]
 Sad to say, recent versions of Opera (and Firefox) have become
 massive memory and disk hogs. I still mainly use Opera because I
 like the interface better,
I couldn't beleive that Opera actually *removed* the native "skin" (even what joke it was in the first place) in the latest versions. That's why my Opera installation is staying put at v10.62.
While I noticed that Opera's UI seems to be undergoing all sorts of overhauls recently, I didn't bother to find out what changed/didn't change. My custom setup disables most of the toolbars anyway, so I don't really notice. :-)
 Which reminds me, I still need to figure out what domain it contacts
 to check whether or not to incessently nag me about *cough*
 "upgrading" *cough*, so I can ban the damn thing via my hosts file.
Umm... you *could* just point Opera at opera:config, then search for "Disable Opera Package AutoUpdate", y'know...
 And people keep talking about web apps and the browser as a
 "platform".  Sigh.
Yea. There's even an entire company dedicated to pushing that moronic agenda (*and* tracking you like Big Brother). They're called "Microsoft Mark 2"...erm...wait...I mean "Google".
lol... [...]
 We get a kickback from our hardware manufacturers and we sell more
 software without actually adding any new features! It's a win-win
 situation!"
That's one of the reasons I despise the modern-day Epic and Valve: *Complete* graphics whores (not to mention Microsoft sluts, particularly in Epic's case), and I don't believe for a second that what you've described isn't the exact nature of...what does Epic call it? Some sort of "Alliance" with NVIDIA and ATI that Epic was so *publically* proud of. Fuck Cliffy, Sweeny, "Fat Fuck" Newell, et al. Shit, and Epic actually used to be pretty good back in their "Megagames" days.
[...] I root for indie games. That's where the real creativity's at. Creativity has died in big-budget games years ago.
 Or solving the travelling salesman problem.
That's aready been solved. Haven't you heard of eCommerce? j/k ;)
[...] lol! T -- Public parking: euphemism for paid parking. -- Flora
Mar 10 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.446.1331424217.4860.digitalmars-d puremagic.com...
 On Sat, Mar 10, 2012 at 05:16:15PM -0500, Nick Sabalausky wrote:
 Which reminds me, I still need to figure out what domain it contacts
 to check whether or not to incessently nag me about *cough*
 "upgrading" *cough*, so I can ban the damn thing via my hosts file.
Umm... you *could* just point Opera at opera:config, then search for "Disable Opera Package AutoUpdate", y'know...
Ugh. If the authors of a GUI program can't be bothered to put an option in their own options menus, then that option may as well not exist. Why can't they learn that? I searched every inch of Opera's options screens and never found *any* mention or reference to any "Disable AutoUpdate" or "opera:config". What the fuck did they expect? Clairvoyance? Omniscience? Thanks for the tip, though.
 And people keep talking about web apps and the browser as a
 "platform".  Sigh.
Yea. There's even an entire company dedicated to pushing that moronic agenda (*and* tracking you like Big Brother). They're called "Microsoft Mark 2"...erm...wait...I mean "Google".
lol...
Heh :) I really do see modern Google as "the new microsoft" though, but just with less respect for personal privacy. (Heck, aren't half their employees former MS employees anyway?) I don't care how much they chant "Don't be evil", it's actions that count, not mantras. Hell, that's what happened to MS and Apple, too. *They* used to be the "Google" to IBM's "evil", and then they themselves became the new IBMs. That famous Apple II commercial is so depressingly ironic these days. Success changes corporations.
 [...]
 We get a kickback from our hardware manufacturers and we sell more
 software without actually adding any new features! It's a win-win
 situation!"
That's one of the reasons I despise the modern-day Epic and Valve: *Complete* graphics whores (not to mention Microsoft sluts, particularly in Epic's case), and I don't believe for a second that what you've described isn't the exact nature of...what does Epic call it? Some sort of "Alliance" with NVIDIA and ATI that Epic was so *publically* proud of. Fuck Cliffy, Sweeny, "Fat Fuck" Newell, et al. Shit, and Epic actually used to be pretty good back in their "Megagames" days.
[...] I root for indie games. That's where the real creativity's at. Creativity has died in big-budget games years ago.
Absolutely. And it's not just from the gamer's side, but from the developer's side too. I grew up wanting to join an id or an Apogee, Sierra, Sega, etc., but when I got to college twelve years ago, I looked at the state of the industry and decided "If I'm going to do games, it's going to be as an indie." I hate the web dev I do, yet I still vastly prefer it to joining an EA or "yet another group of 'developers' who are really just trying to get into Pixar" or any of the smaller houses that Bobby Kodick and Activision are holding by the balls.
Mar 10 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jjgtjn$1aqm$1 digitalmars.com...
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.446.1331424217.4860.digitalmars-d puremagic.com...
 I root for indie games. That's where the real creativity's at.
 Creativity has died in big-budget games years ago.
Absolutely. [...]
There are some rare but notable exceptions, though: The first three Splinter Cells are among my favorite games ever. As much as I hate Valve, I have to admit, both Portal games are phenomenal (although Portal itself is ultimately rooted in indie-land via Narbacular Drop). And Japan can still be relied on as much as ever to produce some very good games: MegaMan 9, Kororinpa, No More Heroes, Resident Wiivil 4, probably half the games Atlus publishes like 3D Dot Game Heroes, etc. (Although I guess many of those aren't really "big-budget". But they're not strictly indie either.)
Mar 10 2012
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 08:01:11PM -0500, Nick Sabalausky wrote:
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.446.1331424217.4860.digitalmars-d puremagic.com...
 On Sat, Mar 10, 2012 at 05:16:15PM -0500, Nick Sabalausky wrote:
 Which reminds me, I still need to figure out what domain it
 contacts to check whether or not to incessently nag me about
 *cough* "upgrading" *cough*, so I can ban the damn thing via my
 hosts file.
Umm... you *could* just point Opera at opera:config, then search for "Disable Opera Package AutoUpdate", y'know...
Ugh. If the authors of a GUI program can't be bothered to put an option in their own options menus, then that option may as well not exist. Why can't they learn that? I searched every inch of Opera's options screens and never found *any* mention or reference to any "Disable AutoUpdate" or "opera:config". What the fuck did they expect? Clairvoyance? Omniscience?
Yay! I'm clairvoyant! :-P Seriously though, I suspect the reason for opera:config is to hide "dangerous" options for the "end users", but keep it available to geeks like you & me who like to tweak stuff most people don't even know exists. I can just imagine somebody filing an Opera bug that auto update stopped working, when they were the ones who turned it off themselves. Can't say I agree with this approach, but that's the way things are, sad to say. [...]
 Heh :) I really do see modern Google as "the new microsoft" though,
 but just with less respect for personal privacy. (Heck, aren't half
 their employees former MS employees anyway?) I don't care how much
 they chant "Don't be evil", it's actions that count, not mantras.
 
 Hell, that's what happened to MS and Apple, too. *They* used to be the
 "Google" to IBM's "evil", and then they themselves became the new
 IBMs. That famous Apple II commercial is so depressingly ironic these
 days. Success changes corporations.
[...] Here's a quote for you: "Perhaps the most widespread illusion is that if we were in power we would behave very differently from those who now hold it---when, in truth, in order to get power we would have to become very much like them." -- Unknown T -- Recently, our IT department hired a bug-fix engineer. He used to work for Volkswagen.
Mar 10 2012
next sibling parent reply Derek <ddparnell bigpond.com> writes:
 Ugh. If the authors of a GUI program can't be bothered to put an
 option in their own options menus, then that option may as well not
 exist. Why can't they learn that? I searched every inch of Opera's
 options screens and never found *any* mention or reference to any
 "Disable AutoUpdate" or "opera:config". What the fuck did they expect?
 Clairvoyance? Omniscience?
I found it in a minute. First I tried opera help and it directed me to details about auto-update, which showed how to disable it. It is in the normal UI place for such stuff. Tools -> Preferences -> Advanced -> Security -> Auto-Update. -- Derek Parnell Melbourne, Australia
Mar 10 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Derek" <ddparnell bigpond.com> wrote in message 
news:op.wazmllu534mv3i red-beast...
 Ugh. If the authors of a GUI program can't be bothered to put an
 option in their own options menus, then that option may as well not
 exist. Why can't they learn that? I searched every inch of Opera's
 options screens and never found *any* mention or reference to any
 "Disable AutoUpdate" or "opera:config". What the fuck did they expect?
 Clairvoyance? Omniscience?
I found it in a minute. First I tried opera help and it directed me to details about auto-update, which showed how to disable it. It is in the normal UI place for such stuff. Tools -> Preferences -> Advanced -> Security -> Auto-Update.
They stuck it under "Security"? No wonder I couldn't find it. That's like putting "blue" under "shapes". :/
Mar 10 2012
parent reply Marco Leise <Marco.Leise gmx.de> writes:
 I searched every inch of Opera's options screens and never 
 found *any* mention or reference to any "Disable AutoUpdate"
"Derek" <ddparnell bigpond.com> wrote in message news:op.wazmllu534mv3i red-beast...
 I found it in a minute. First I tried opera help and it directed me to 
 details about auto-update, which showed how to disable it. It is in the 
 normal UI place for such stuff.

   Tools -> Preferences -> Advanced -> Security -> Auto-Update.
Am Sat, 10 Mar 2012 23:44:20 -0500 schrieb "Nick Sabalausky" <a a.a>:
 They stuck it under "Security"? No wonder I couldn't find it. That's like 
 putting "blue" under "shapes". :/
So much for every inch ...and false accusations. You made my day! ;) -- Marco
Mar 12 2012
parent "Nick Sabalausky" <a a.a> writes:
"Marco Leise" <Marco.Leise gmx.de> wrote in message 
news:20120312124959.2ef8eb86 marco-leise.homedns.org...
 I searched every inch of Opera's options screens and never
 found *any* mention or reference to any "Disable AutoUpdate"
"Derek" <ddparnell bigpond.com> wrote in message news:op.wazmllu534mv3i red-beast...
 I found it in a minute. First I tried opera help and it directed me to
 details about auto-update, which showed how to disable it. It is in the
 normal UI place for such stuff.

   Tools -> Preferences -> Advanced -> Security -> Auto-Update.
Am Sat, 10 Mar 2012 23:44:20 -0500 schrieb "Nick Sabalausky" <a a.a>:
 They stuck it under "Security"? No wonder I couldn't find it. That's like
 putting "blue" under "shapes". :/
So much for every inch ...and false accusations. You made my day! ;)
Yup. You've got me there! (I had thought that I had, but I'm not sure if that works for or against me ;) )
Mar 12 2012
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.449.1331429962.4860.digitalmars-d puremagic.com...
 Seriously though, I suspect the reason for opera:config is to hide
 "dangerous" options for the "end users", but keep it available to geeks
 like you & me who like to tweak stuff most people don't even know
 exists.
Yea, that's what buttons labeled "Advanced Options" are for. :/
Mar 10 2012
prev sibling parent reply "so" <so so.so> writes:
On Saturday, 10 March 2012 at 19:54:13 UTC, Jonathan M Davis 
wrote:

 LOL. I'm the complete opposite. I seem to end up upgrading my 
 computer every 2
 or 3 years. I wouldn't be able to stand being on an older 
 computer that long.
 I'm constantly annoyed by how slow my computer is no matter how 
 new it is.
No matter how much hardware you throw at it, somehow it gets slower and slower. New hardware can't keep up with (ever increasing) writing bad software. http://www.agner.org/optimize/blog/read.php?i=9
Mar 10 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"so" <so so.so> wrote in message 
news:pzghdzojddybajuguxwa forum.dlang.org...
 On Saturday, 10 March 2012 at 19:54:13 UTC, Jonathan M Davis wrote:

 LOL. I'm the complete opposite. I seem to end up upgrading my computer 
 every 2
 or 3 years. I wouldn't be able to stand being on an older computer that 
 long.
 I'm constantly annoyed by how slow my computer is no matter how new it 
 is.
No matter how much hardware you throw at it, somehow it gets slower and slower. New hardware can't keep up with (ever increasing) writing bad software. http://www.agner.org/optimize/blog/read.php?i=9
That is a *FANTASTIC* article. Completely agree, and it's very well-written. That's actually one of reasons I like to *not* use higher-end hardware. Every programmer in the world, no exceptions, has a natural tendancy to target the hardware they're developing on. If you're developing on high-end hardware, your software is likely to end up requiring high-end hardware even without your noticing. If you're developing on lower-end hardware, your software is going to run well on fucking *everything*. Similar thing for server software. If your developing on a low-end local machine, it's going to run that much better under heavier loads. I think it's a shame that companies hand out high-end hardware to their developers like it was candy. There's no doubt in my mind that's significantly contributed to the amount of bloatware out there.
Mar 11 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Mar 11, 2012 at 04:12:12AM -0400, Nick Sabalausky wrote:
 "so" <so so.so> wrote in message 
 news:pzghdzojddybajuguxwa forum.dlang.org...
[...]
 No matter how much hardware you throw at it, somehow it gets slower
 and slower.  New hardware can't keep up with (ever increasing)
 writing bad software.

 http://www.agner.org/optimize/blog/read.php?i=9
That is a *FANTASTIC* article. Completely agree, and it's very well-written.
I really liked the point about GUIs. Many resources are used for graphical elements that only have aesthetic value AND tends to distract the user from actual work. IOW, you're wasting CPU, RAM, and disk time (which comes from spending lots of hard-earned cash for that expensive hardware upgrade) just for some silly eye-candy that has no value whatsoever except to distract from the task at hand, that is, to accomplish what you set out to do in the first place. That's why I use ratpoison as my WM. Who needs title bars with fancy colored icons, gradient shading, and *shadows*?! I mean, c'mon. You're trying to get work done, not admire how clever the UI designers were and how cool a color gradient is. If I wanted to admire eye-candy, I'd be playing computer games, not working. (That said, though, I did at one point have a Compiz installation for the sole purpose of showing off Linux to clueless people. :-P) Then the points about background processes, auto-updates, and boot-up times. These are things about Windows that consistently drive me up the wall. Background processes are all nice and good as long as they are (1) necessary, and (2) don't do stupid things like hog your CPU or thrash your disk every 12 seconds. But the way Windows works, every time you install something, it insists on starting up at boot-time, incessantly checking for auto-updates every 12 seconds, downloading crap from online without your knowledge, and THEN pop up those intrusive, distracting, and utterly annoying "Plz Update Meeee!" dialogs. Ugh. Everytime I see one of those dialogs I have this urge to delete the app and expunge all traces of it from the system with extreme prejudice. At least on Linux you can turn off this crap and/or otherwise prevent it from doing stupid things. But on Windows you have no choice. Attempting to disable stuff usually breaks said apps, or affects system usability in some way.
 That's actually one of reasons I like to *not* use higher-end
 hardware.  Every programmer in the world, no exceptions, has a natural
 tendancy to target the hardware they're developing on. If you're
 developing on high-end hardware, your software is likely to end up
 requiring high-end hardware even without your noticing. If you're
 developing on lower-end hardware, your software is going to run well
 on fucking *everything*.
True. I suppose it's a good thing at my day job that we don't get free upgrades. Whatever was current when we first got the job is whatever we have today. It does have a certain value to it, in that we notice how idiotically long it takes to compile the software we're working on, and how much CPU and RAM a particular ludicrously-long linker command-line eats up at a certain point in the build (which, not too surprisingly, is the linking of the GUI component). It does provide a disincentive against doing more stupid things to make this worse. Now if only everyone (particular the people working on the GUI component :-P) had 5-year old development machines, perhaps that ludicrously-long linker command would never have existed in the first place. Well, I can dream. :-) T -- Ignorance is bliss... but only until you suffer the consequences!
Mar 11 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.478.1331478431.4860.digitalmars-d puremagic.com...
 On Sun, Mar 11, 2012 at 04:12:12AM -0400, Nick Sabalausky wrote:
 "so" <so so.so> wrote in message
 news:pzghdzojddybajuguxwa forum.dlang.org...
[...]
 No matter how much hardware you throw at it, somehow it gets slower
 and slower.  New hardware can't keep up with (ever increasing)
 writing bad software.

 http://www.agner.org/optimize/blog/read.php?i=9
That is a *FANTASTIC* article. Completely agree, and it's very well-written.
I really liked the point about GUIs. Many resources are used for graphical elements that only have aesthetic value AND tends to distract the user from actual work. IOW, you're wasting CPU, RAM, and disk time (which comes from spending lots of hard-earned cash for that expensive hardware upgrade) just for some silly eye-candy that has no value whatsoever except to distract from the task at hand, that is, to accomplish what you set out to do in the first place. That's why I use ratpoison as my WM. Who needs title bars with fancy colored icons, gradient shading, and *shadows*?! I mean, c'mon.
Actually, I rather like my black windows with "dark-blue to light-purple" gradient title bars. I've been using that scheme for years and I don't think I'll ever change it: http://www.semitwist.com/download/img/shots/myColorScheme.png
 You're
 trying to get work done, not admire how clever the UI designers were and
 how cool a color gradient is. If I wanted to admire eye-candy, I'd be
 playing computer games, not working. (That said, though, I did at one
 point have a Compiz installation for the sole purpose of showing off
 Linux to clueless people. :-P)
Before I upgraded my Linux box to Kubuntu 10.04, it was Ubuntu...umm...something before 10.04, and although I'm not normally a UI-eye-candy guy, I fell in love with the window physics effect whle draggng windows. And it was properly hardware accellerated, so it worked very fast even being on an old 32-bit single-core. My brother, who had recently gotten a Mac laptop (although he's now become the third member of my family who's gotten fed up with Apple) saw it and exclaimed "I want jelly windows!" But then in Kubuntu 10.04, the effect no longer works (or maybe it just doesn't work with hardware accelleration, I don't remember now), so I had to give it up :( 'Course, I'm more than ready to give up KDE itself now. Move to something like Trinity or LXDE or XFCE. And Debian 6. Canonincal just keeps getting crazier and crazier. I don't want their new Linux-based iOS of an operating system. OTOH, Debian's "versioning" system is irritationly moroninc. Squeeze, wheeze, wtf? They don't even have any natural ordering for god's sake! At least Ubuntu's moronic names have *that* much going for them! I don't care what Pixar character my OS is pretending to be, and I don't *want* to care.
 Then the points about background processes, auto-updates, and boot-up
 times. These are things about Windows that consistently drive me up the
 wall. Background processes are all nice and good as long as they are (1)
 necessary, and (2) don't do stupid things like hog your CPU or thrash
 your disk every 12 seconds. But the way Windows works, every time you
 install something, it insists on starting up at boot-time, incessantly
 checking for auto-updates every 12 seconds, downloading crap from online
 without your knowledge, and THEN pop up those intrusive, distracting,
 and utterly annoying "Plz Update Meeee!" dialogs. Ugh. Everytime I see
 one of those dialogs I have this urge to delete the app and expunge all
 traces of it from the system with extreme prejudice.

 At least on Linux you can turn off this crap and/or otherwise prevent it
 from doing stupid things. But on Windows you have no choice. Attempting
 to disable stuff usually breaks said apps, or affects system usability
 in some way.
I just avoid those programs (and immediately disable the upgrade nag screens). For example, I will *not* allow Safari or Chrome to even *touch* my computer. (When I want to test a page in Chrome, I use SRWare Iron instead. If SRWare Iron ever goes away, then Chrome users will be on their own when viewing my pages.)
 -- 
 Ignorance is bliss... but only until you suffer the consequences!
So very true :)
Mar 11 2012
next sibling parent "so" <so so.so> writes:
On Sunday, 11 March 2012 at 19:22:04 UTC, Nick Sabalausky wrote:

 I just avoid those programs (and immediately disable the 
 upgrade nag
 screens). For example, I will *not* allow Safari or Chrome to 
 even *touch*
 my computer. (When I want to test a page in Chrome, I use 
 SRWare Iron
 instead. If SRWare Iron ever goes away, then Chrome users will 
 be on their
 own when viewing my pages.)
http://code.google.com/p/smoothgestures-chromium/issues/detail?id=498
Mar 11 2012
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Mar 11, 2012 at 03:20:34PM -0400, Nick Sabalausky wrote:
[...]
 'Course, I'm more than ready to give up KDE itself now. Move to
 something like Trinity or LXDE or XFCE.
Way ahead of you there. ;-) I'm already using a mouseless WM, and thinking of replacing ratpoison with something even more radical. Something that not only doesn't need the mouse, but *eradicates* all need for the mouse on virtually all applications. Something that maps keystrokes to geometry, so that you point using your keyboard. The screen would divide into regions mapped to certain keys, and certain key sequences would subdivide regions, so you can virtually point at anything just by hitting 3-4 keys. Furthermore, due to X11's root window allowing the WM to scan pixels, the region subdivisions can auto-snap to high-contrast boundaries, so you're actually subdividing based on visually distinct regions like text lines or buttons, etc., rather than just a blind coordinates subdivision (which will require unreasonable amounts of keystrokes to point accurately). (Though at the rate I'm going, I don't know when I'm ever going to have the time to actually sit down and write a WM. So maybe this is just a really wild impractical pipe dream. :-P) The mouse still has its place, of course, for when you *actually* need it, like drawing free-hand curves and stuff like that.
 And Debian 6. Canonincal just keeps getting crazier and crazier. I
 don't want their new Linux-based iOS of an operating system. OTOH,
 Debian's "versioning" system is irritationly moroninc.  Squeeze,
 wheeze, wtf? They don't even have any natural ordering for god's sake!
 At least Ubuntu's moronic names have *that* much going for them! I
 don't care what Pixar character my OS is pretending to be, and I don't
 *want* to care.
I'm a Debian developer, actually. Though I've been so busy with other stuff that I haven't really done anything worth mentioning for the last long while. To me, Debian only ever has 3 versions, oldstable, stable, and unstable. Every Debian "release" is really just a rollover of unstable into stable, and stable into oldstable. I don't even remember those silly Pixar names or their correlation with actual version numbers (actually, I find the version numbers quite meaningless). "Unstable" is really a misnomer... it's generally a lot more stable than, say, your typical Windows XP installation. (But YMMV... remember I don't use a real desktop environment or any of the stuff that "common people" use.) I see it more as "current release" than "unstable", actually. The *real* unstable is "experimental", which only fools who like crashing their system every other month would run. Stable is for those freaks who run mission-critical servers, whose life depends on the servers being almost impossible to crash. So really, for PCs, most people just run "unstable". So in my mind, I never even think about "Debian 6" or "Debian 5" or whatever arbitrary number they want to call it. I run "unstable" at home and "stable" on a remote server, and it's as simple as that. T -- If it tastes good, it's probably bad for you.
Mar 11 2012
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 12 March 2012 at 01:28:39 UTC, H. S. Teoh wrote:
 Something that not only doesn't need the mouse, but 
 *eradicates* all
 need for the mouse on virtually all applications.
It isn't what you described, but in X11, if you hit shift+numlock, it toggles a mode that lets you move the cursor and click by using the numpad keys.
Mar 11 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Mar 12, 2012 at 02:31:44AM +0100, Adam D. Ruppe wrote:
 On Monday, 12 March 2012 at 01:28:39 UTC, H. S. Teoh wrote:
Something that not only doesn't need the mouse, but *eradicates* all
need for the mouse on virtually all applications.
It isn't what you described, but in X11, if you hit shift+numlock, it toggles a mode that lets you move the cursor and click by using the numpad keys.
There is that, but that's still just a mouse in disguise. In fact, it's worse than a mouse, 'cos now you're pushing the mouse with buttons instead of just sweeping it across the mouse pad with your hand. I'm talking about a sort of quadtree-type spatial navigation where you zero in on the target position in logarithmic leaps, rather than a "linear" cursor displacement. T -- INTEL = Only half of "intelligence".
Mar 11 2012
prev sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Sun, 11 Mar 2012 04:12:12 -0400
schrieb "Nick Sabalausky" <a a.a>:

 I think it's a shame that companies hand out high-end hardware to their 
 developers like it was candy. There's no doubt in my mind that's 
 significantly contributed to the amount of bloatware out there.
But what if the developers themselves use bloated software, like Eclipse or slow compilation processes, like big C++ programs. It is a net productivity increase. But yeah, I sometimes think about keeping some old notebook around to test on it - not to use it for development. Actually, sometimes you may want to debug your code with a very large data set. So you end up on the other side of the extreme: Your computer has too little RAM to run some real world application of your software. As for the article: The situation with automatic updates was worse than now - Adobe, Apple and the others have learned and added the option to disable most of the background processing. The developments in the web sector are interesting under that aspect. High quality videos and several scripting/VM languages make most older computers useless for tabbed browsing :D -- Marco
Mar 12 2012
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 11:52:47AM -0800, Jonathan M Davis wrote:
 On Saturday, March 10, 2012 11:49:22 H. S. Teoh wrote:
 Yikes. That would *not* sit well with me. Before my last upgrade, my
 PC was at least 10 years old. (And the upgrade before that was at
 least 5 years prior.) Last year I finally replaced my 10 y.o. PC
 with a brand new AMD hexacore system. The plan being to not upgrade
 for at least the next 10 years, preferably more. :-)
LOL. I'm the complete opposite. I seem to end up upgrading my computer every 2 or 3 years. I wouldn't be able to stand being on an older computer that long. I'm constantly annoyed by how slow my computer is no matter how new it is. Of course, I do tend to stress my machine quite a lot by having a ton of stuff open all the time and doing CPU-intensive stuff like transcoding video, and how you use your computer is a definite factor in how much value there is in upgrading.
[...] True. But I found Linux far more superior in terms of being usable on very old hardware. I can't imagine the pain of trying to run Windows 7 on, say, a 5 y.o. PC (if it will even let you install it on something that old!). I used to run CPU-intensive stuff too, by using 'at' to schedule it to run overnight. :-) Although, I have to admit the reason for my last upgrade was because I was doing lots of povray rendering, and it was getting a bit too slow for my tastes. It's no fun at all if you had to wait 2 hours just to find out you screwed up some parameters in your test render. Imagine if you had to wait 2 hours to know the result of every 1 line code change. T -- Lottery: tax on the stupid. -- Slashdotter
Mar 10 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.437.1331414346.4860.digitalmars-d puremagic.com...
 True. But I found Linux far more superior in terms of being usable on
 very old hardware.
There have been exceptions to that: About 10-12 years ago, GNOME (or at least Nautlus) and KDE were *insanely* bloated to the pount of making Win2k/XP seem ultra-lean.
Mar 10 2012
next sibling parent Sean Cavanaugh <WorksOnMyMachine gmail.com> writes:
On 3/10/2012 4:22 PM, Nick Sabalausky wrote:
 "H. S. Teoh"<hsteoh quickfur.ath.cx>  wrote in message
 news:mailman.437.1331414346.4860.digitalmars-d puremagic.com...
 True. But I found Linux far more superior in terms of being usable on
 very old hardware.
There have been exceptions to that: About 10-12 years ago, GNOME (or at least Nautlus) and KDE were *insanely* bloated to the pount of making Win2k/XP seem ultra-lean.
Both KDE and Gnome UIs and apps using these Uis still feel very sluggish to me on a modern machine. I don't get this feeling at all on Win7, even on a much slower machine (my laptop for instance).
Mar 10 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 05:22:07PM -0500, Nick Sabalausky wrote:
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.437.1331414346.4860.digitalmars-d puremagic.com...
 True. But I found Linux far more superior in terms of being usable
 on very old hardware.
There have been exceptions to that: About 10-12 years ago, GNOME (or at least Nautlus) and KDE were *insanely* bloated to the pount of making Win2k/XP seem ultra-lean.
[...] Good thing I didn't use them then. :-) But if I was installing Linux on ancient hardware, I wouldn't even dream of install KDE or GNOME. I mean, X11 itself is already a resource hog, nevermind something built on top of it. I only installed X11 'cos I had to use a GUI browser. (I would've stuck with Lynx if it had been able to render tables the way elinks can today.) T -- "I'm not childish; I'm just in touch with the child within!" - RL
Mar 10 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/10/2012 1:20 PM, H. S. Teoh wrote:
 It's no fun at all if you had to wait 2 hours just to
 find out you screwed up some parameters in your test render. Imagine if
 you had to wait 2 hours to know the result of every 1 line code change.
2 hours? Man, you got good service. When I submitted my punched card decks, I'd be lucky to get a result the next day! (Yes, I did learn to program using punch cards. And to be fair, the programs were trivial compared with the behemoths we write today.)
Mar 10 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 10:41:48PM -0800, Walter Bright wrote:
 On 3/10/2012 1:20 PM, H. S. Teoh wrote:
It's no fun at all if you had to wait 2 hours just to find out you
screwed up some parameters in your test render. Imagine if you had to
wait 2 hours to know the result of every 1 line code change.
2 hours? Man, you got good service. When I submitted my punched card decks, I'd be lucky to get a result the next day! (Yes, I did learn to program using punch cards. And to be fair, the programs were trivial compared with the behemoths we write today.)
And also today, the complexity of the compile/link process can lead to dainbramaged makefiles that sometimes fail to recompile a changed source, and the linker picks up leftover junk .o's from who knows how many weeks ago, causing heisenbugs that don't exist in the source code but persistently show up in the binary until you rm -rf the entire source tree, checkout a fresh copy from the repos, reapply your changes, and rebuild the whole thing from scratch. (And that's assuming that in the meantime somebody didn't check in something that doesn't compile, or that introduces new and ingenious ways of breaking the system.) So perhaps the turnaround time has improved, but the frustration level has also increased. :-) T -- The best way to destroy a cause is to defend it poorly.
Mar 10 2012
parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.456.1331450402.4860.digitalmars-d puremagic.com...
 On Sat, Mar 10, 2012 at 10:41:48PM -0800, Walter Bright wrote:
 On 3/10/2012 1:20 PM, H. S. Teoh wrote:
It's no fun at all if you had to wait 2 hours just to find out you
screwed up some parameters in your test render. Imagine if you had to
wait 2 hours to know the result of every 1 line code change.
2 hours? Man, you got good service. When I submitted my punched card decks, I'd be lucky to get a result the next day! (Yes, I did learn to program using punch cards. And to be fair, the programs were trivial compared with the behemoths we write today.)
And also today, the complexity of the compile/link process can lead to dainbramaged makefiles that sometimes fail to recompile a changed source, and the linker picks up leftover junk .o's from who knows how many weeks ago, causing heisenbugs that don't exist in the source code but persistently show up in the binary until you rm -rf the entire source tree, checkout a fresh copy from the repos, reapply your changes, and rebuild the whole thing from scratch. (And that's assuming that in the meantime somebody didn't check in something that doesn't compile, or that introduces new and ingenious ways of breaking the system.)
*cough*DMD*cough*
Mar 11 2012
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
H. S. Teoh:

 (Then again, I don't use graphics-heavy UIs... on Linux you can turn
 most of it off, and I do, but on Windows you have no choice.
In Windows there is a very very easy way to disable all eye candy and most UI sugar, to produce a snappy graphics interface even on low powered laptops, that looks like Windows95 :-) Bye, bearophile
Mar 10 2012
prev sibling parent "Kagamin" <spam here.lot> writes:
On Saturday, 10 March 2012 at 08:53:23 UTC, Alex Rønne Petersen 
wrote:
 In all fairness, a stop-the-world GC in a kernel probably *is* 
 a horrible idea.
Doesn't kernel always work in a stop-the-world mode?
Apr 03 2012
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, March 09, 2012 15:14:39 H. S. Teoh wrote:
 On Fri, Mar 09, 2012 at 11:46:24PM +0100, Alex Rønne Petersen wrote:
 On 09-03-2012 23:32, Walter Bright wrote:
This statement is from Linus Torvalds about breaking binary
compatibility:

https://lkml.org/lkml/2012/3/8/495

While I don't think we need to worry so much at the moment about
breaking binary compatibility with new D releases, we do have a big
problem with breaking source code compatibility.

This is why we need to have a VERY high bar for breaking changes.
If we want to start being able to avoid breaking changes, we *really* need to finally deprecate the stuff that's been slated for deprecation for ages...
[...] Does that include std.stdio and std.stream? When are we expecting std.io to be ready? IMHO, this is one major change that needs to happen sooner rather than later. The current lack of interoperability between std.stdio and std.stream is a big detraction from Phobos' overall quality.
Note that he didn't say that we should _never_ make breaking changes but rather that we need to have a very high bar for making such changes. In particular, it's stuff like renaming functions without changing functionality that he's against. If a module really needs a rewrite, then it'll get a rewrite, but we also need to do our best to avoid the need. And in the long run, it will hopefully be incredibly rare that we'll consider replacing modules. But there _are_ a few modules which are going to be replaced or rewritten. It's just that those are the modules that really need it and therefore meet the high bar required to make such changes. - Jonathan M Davis
Mar 09 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 10/03/2012 00:24, Jonathan M Davis a écrit :
 On Friday, March 09, 2012 15:14:39 H. S. Teoh wrote:
 On Fri, Mar 09, 2012 at 11:46:24PM +0100, Alex Rønne Petersen wrote:
 On 09-03-2012 23:32, Walter Bright wrote:
 This statement is from Linus Torvalds about breaking binary
 compatibility:

 https://lkml.org/lkml/2012/3/8/495

 While I don't think we need to worry so much at the moment about
 breaking binary compatibility with new D releases, we do have a big
 problem with breaking source code compatibility.

 This is why we need to have a VERY high bar for breaking changes.
If we want to start being able to avoid breaking changes, we *really* need to finally deprecate the stuff that's been slated for deprecation for ages...
[...] Does that include std.stdio and std.stream? When are we expecting std.io to be ready? IMHO, this is one major change that needs to happen sooner rather than later. The current lack of interoperability between std.stdio and std.stream is a big detraction from Phobos' overall quality.
Note that he didn't say that we should _never_ make breaking changes but rather that we need to have a very high bar for making such changes. In particular, it's stuff like renaming functions without changing functionality that he's against.
Just about that, having a consistent naming convention is an issue of first importance. In the given topic, I did argue for some convention, but, let's look at the larger picture and how it relate to this topic. Whatever the naming convention is, it mandatory to have one. So at some point, renaming stuff are going to happen, or phobos will become completely opaque when growing. Renaming just one function isn't important enough to justify to break compatibility. Having a consistent naming convention is.
Mar 11 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:jje0er$24mb$1 digitalmars.com...
 This statement is from Linus Torvalds about breaking binary compatibility:

 https://lkml.org/lkml/2012/3/8/495

 While I don't think we need to worry so much at the moment about breaking 
 binary compatibility with new D releases, we do have a big problem with 
 breaking source code compatibility.

 This is why we need to have a VERY high bar for breaking changes.
Freezing things against breaking changes is all fine and good, but NOT before they're reached a point where they're good enough to be frozen. Premature freezing is how you create cruft and other such shit. Let's not go jumping any guns here.
Mar 09 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jje2cg$27tg$1 digitalmars.com...
 "Walter Bright" <newshound2 digitalmars.com> wrote in message 
 news:jje0er$24mb$1 digitalmars.com...
 This statement is from Linus Torvalds about breaking binary 
 compatibility:

 https://lkml.org/lkml/2012/3/8/495

 While I don't think we need to worry so much at the moment about breaking 
 binary compatibility with new D releases, we do have a big problem with 
 breaking source code compatibility.

 This is why we need to have a VERY high bar for breaking changes.
Freezing things against breaking changes is all fine and good, but NOT before they're reached a point where they're good enough to be frozen. Premature freezing is how you create cruft and other such shit. Let's not go jumping any guns here.
Keep in mind, too, that Linux has decades of legacy and millions of users. That's a *very* different situation from Phobos. Apples and oranges.
Mar 09 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/10/2012 12:09 AM, Nick Sabalausky wrote:
 "Nick Sabalausky"<a a.a>  wrote in message
 news:jje2cg$27tg$1 digitalmars.com...
 "Walter Bright"<newshound2 digitalmars.com>  wrote in message
 news:jje0er$24mb$1 digitalmars.com...
 This statement is from Linus Torvalds about breaking binary
 compatibility:

 https://lkml.org/lkml/2012/3/8/495

 While I don't think we need to worry so much at the moment about breaking
 binary compatibility with new D releases, we do have a big problem with
 breaking source code compatibility.

 This is why we need to have a VERY high bar for breaking changes.
Freezing things against breaking changes is all fine and good, but NOT before they're reached a point where they're good enough to be frozen. Premature freezing is how you create cruft and other such shit. Let's not go jumping any guns here.
+1.
 Keep in mind, too, that Linux has decades of legacy and millions of users.
 That's a *very* different situation from Phobos. Apples and oranges.
+1.
Mar 09 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/9/2012 3:09 PM, Nick Sabalausky wrote:
 Keep in mind, too, that Linux has decades of legacy and millions of users.
 That's a *very* different situation from Phobos. Apples and oranges.
Linux has had a habit of not breaking existing code from decades ago. I think that is one reason why it has millions of users. Remember, every time you break existing code you reset your user base back to zero. I'm *still* regularly annoyed by the writefln => writeln change in D1 to D2, and I agreed to that change. Grrrr.
Mar 09 2012
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 10 March 2012 at 04:34:15 UTC, Walter Bright wrote:
 Linux has had a habit of not breaking existing code from 
 decades ago. I think that is one reason why it has millions of 
 users.
If you want to see someone who takes compatibility seriously (and all the way to the bank), take a look at Microsoft Windows. I don't like developing Linux apps much, nor to a lot of professionals, because it's binary compatibility is a joke. Yeah, the kernel is decent about it, but the rest of the system sure as hell isn't. You're lucky if you can take a Linux binary and use it next month, and certainly not ten years from now. (For example, take dmd out of the box on CentOS. Won't work.) On Windows though, even if you relied on bugs twenty years ago, they bend over backward to keep your app functioning. It is really an amazing feat they've accomplished, both from technical and business perspectives, in doing this while still moving forward.
Mar 09 2012
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 10 March 2012 at 04:40:11 UTC, Adam D. Ruppe wrote:
 Yeah, the kernel is decent about it, but the rest of the
 system sure as hell isn't.
Let me tie this into D. A couple weeks ago, I revived one of my work D projects - about 30,000 lines of code - that was dormant for about a year. The language worked fine. The library was a bit more of a pain. std.date's deprecation still makes me mad. And the move of std.string.replace over to std.array meant not one of the modules compiled without a change. (Really easy change: "import std.string : replace;" why that works and "import std.string;" doesn't I'm not sure. I'm probably relying on a bug here!) But still, the D language manages to move forward without much breakage. dmd pretty much gets better each release. Phobos has some breakage though. Not really bad; updating this code went quickly. I think I spent half an hour on it. But, there was some minor changes needed. We might have a stable language, but if the library doesn't do the same, we'll never be Windows.
Mar 09 2012
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/9/12 8:46 PM, Adam D. Ruppe wrote:
 We might have a stable language, but if the library doesn't
 do the same, we'll never be Windows.
I hear ya. Andrei
Mar 09 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:wirsowklisbhbkbujewr forum.dlang.org...
 On Saturday, 10 March 2012 at 04:40:11 UTC, Adam D. Ruppe wrote:
 Yeah, the kernel is decent about it, but the rest of the
 system sure as hell isn't.
Let me tie this into D. A couple weeks ago, I revived one of my work D projects - about 30,000 lines of code - that was dormant for about a year. The language worked fine. The library was a bit more of a pain. std.date's deprecation still makes me mad. And the move of std.string.replace over to std.array meant not one of the modules compiled without a change. (Really easy change: "import std.string : replace;" why that works and "import std.string;" doesn't I'm not sure. I'm probably relying on a bug here!) But still, the D language manages to move forward without much breakage. dmd pretty much gets better each release. Phobos has some breakage though. Not really bad; updating this code went quickly. I think I spent half an hour on it. But, there was some minor changes needed. We might have a stable language, but if the library doesn't do the same, we'll never be Windows.
If we start freezing things now, we're going to be Windows 9x.
Mar 09 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 01:44:59AM -0500, Nick Sabalausky wrote:
 "Adam D. Ruppe" <destructionator gmail.com> wrote in message 
 news:wirsowklisbhbkbujewr forum.dlang.org...
[...]
 We might have a stable language, but if the library doesn't do the
 same, we'll never be Windows.
Really? D is a stable language as of this moment? Interesting.
 If we start freezing things now, we're going to be Windows 9x.
You mean Windows 3.1. T -- Without outlines, life would be pointless.
Mar 09 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.398.1331362435.4860.digitalmars-d puremagic.com...
 On Sat, Mar 10, 2012 at 01:44:59AM -0500, Nick Sabalausky wrote:
 "Adam D. Ruppe" <destructionator gmail.com> wrote in message
 news:wirsowklisbhbkbujewr forum.dlang.org...
[...]
 We might have a stable language, but if the library doesn't do the
 same, we'll never be Windows.
Really? D is a stable language as of this moment? Interesting.
 If we start freezing things now, we're going to be Windows 9x.
You mean Windows 3.1.
I was pretty happy with 3.1. It's terrible in retrospect, but viewed in the context of the early 90's, I don't think it was bad at all. Maybe not as stable as the Unix of the time (I wouldn't know), but it was usable by mere mortals and was still a lot more robust than WinMe. But then around the time of 98SE and Me, the 9x line just wasn't up to even the current expectations of the time. (And maybe my memory's foggy, but I seem to remember having more troubles with 98 than I did with 3.1. And Me was definitely much worse.)
Mar 09 2012
parent reply sclytrack <sclytrack hotmail.com> writes:
On 03/10/2012 08:31 AM, Nick Sabalausky wrote:
 I was pretty happy with 3.1. It's terrible in retrospect, but viewed in the
 context of the early 90's, I don't think it was bad at all. Maybe not as
 stable as the Unix of the time (I wouldn't know), but it was usable by mere
 mortals and was still a lot more robust than WinMe.

 But then around the time of 98SE and Me, the 9x line just wasn't up to even
 the current expectations of the time. (And maybe my memory's foggy, but I
 seem to remember having more troubles with 98 than I did with 3.1. And Me
 was definitely much worse.)
My grandfather still uses 3.11 I gave him my old computer (Athlon) with Windows 7. But no after a week he wanted his old system back.
Mar 10 2012
parent "so" <so so.so> writes:
 My grandfather still uses 3.11

 I gave him my old computer (Athlon) with Windows 7. But no 
 after a week he wanted his old system back.
"my old Windows 7" Which was the newest/bestest thing a few days/weeks/months/years ago. It must be hard to keep up, they release OSs faster than the time it takes to install or possibly booting a system! :)
Mar 10 2012
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 10 March 2012 at 06:53:49 UTC, H. S. Teoh wrote:
 Really? D is a stable language as of this moment? Interesting.
Yeah, it is. It removes restrictions or sometimes adds stuff, but over this last year, not much of the language has actually broke. I have a lot of D code, some of it rather fancy, and I can't actually think of a place where a *language* change broke it. Library changes break it almost every other release, but language changes tend to be ok. There's regressions every so often, but they aren't bad.
 You mean Windows 3.1.
You're insane! D rox my sox right off my cox and has for a long time, and it has been getting pretty consistently better.
Mar 10 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 03:34:48PM +0100, Adam D. Ruppe wrote:
 On Saturday, 10 March 2012 at 06:53:49 UTC, H. S. Teoh wrote:
Really? D is a stable language as of this moment? Interesting.
Yeah, it is. It removes restrictions or sometimes adds stuff, but over this last year, not much of the language has actually broke. I have a lot of D code, some of it rather fancy, and I can't actually think of a place where a *language* change broke it.
Well, the slated property enforcement *will* break a lot of stuff...
 Library changes break it almost every other release, but language
 changes tend to be ok. There's regressions every so often, but they
 aren't bad.
OK.
You mean Windows 3.1.
You're insane! D rox my sox right off my cox and has for a long time, and it has been getting pretty consistently better.
You're right, D *does* rock in spite of its current shortcomings. It's easy to see only the flaws when you're just focused on fixing problems, but it's true that when I take a step back and compare it with, say, C/C++, there's simply no comparison. Even with all its warts, D is unquestionably superior in pretty much every way. T -- "The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again."
Mar 10 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/9/2012 10:44 PM, Nick Sabalausky wrote:
 If we start freezing things now, we're going to be Windows 9x.
Win9x was incredibly successful (!) We can only hope to be so successful.
Mar 10 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 10:47:54AM -0800, Walter Bright wrote:
 On 3/9/2012 10:44 PM, Nick Sabalausky wrote:
If we start freezing things now, we're going to be Windows 9x.
Win9x was incredibly successful (!) We can only hope to be so successful.
Win9x's success is mainly attributable to Microsoft's superior marketing strategies. It can hardly be called a success technology-wise. T -- I am not young enough to know everything. -- Oscar Wilde
Mar 10 2012
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 10 March 2012 at 18:57:10 UTC, H. S. Teoh wrote:
 It can hardly be called a success technology-wise.
It is significantly ahead of its competition at the time.
Mar 10 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:tfdzpwcijnavdalmnzit forum.dlang.org...
 On Saturday, 10 March 2012 at 18:57:10 UTC, H. S. Teoh wrote:
 It can hardly be called a success technology-wise.
It is significantly ahead of its competition at the time.
And it was a big advancement over 3.1. Pre-emptive multitasking anyone?
Mar 10 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 02:27:20PM -0500, Nick Sabalausky wrote:
 "Adam D. Ruppe" <destructionator gmail.com> wrote in message 
 news:tfdzpwcijnavdalmnzit forum.dlang.org...
 On Saturday, 10 March 2012 at 18:57:10 UTC, H. S. Teoh wrote:
 It can hardly be called a success technology-wise.
It is significantly ahead of its competition at the time.
And it was a big advancement over 3.1. Pre-emptive multitasking anyone?
[...] I thought the Unix world has had that years before Windows. But not in the consumer PC market, I suppose. But 3.1 was such a sad mess that just about *anything* would be an improvement on it. T -- ASCII stupid question, getty stupid ANSI.
Mar 10 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.427.1331409078.4860.digitalmars-d puremagic.com...
 On Sat, Mar 10, 2012 at 02:27:20PM -0500, Nick Sabalausky wrote:
 "Adam D. Ruppe" <destructionator gmail.com> wrote in message
 news:tfdzpwcijnavdalmnzit forum.dlang.org...
 On Saturday, 10 March 2012 at 18:57:10 UTC, H. S. Teoh wrote:
 It can hardly be called a success technology-wise.
It is significantly ahead of its competition at the time.
And it was a big advancement over 3.1. Pre-emptive multitasking anyone?
[...] I thought the Unix world has had that years before Windows.
I just meant versus 3.1. I wouldn't know about Unix.
 But not in the consumer PC market, I suppose.
I'm not sure I'd say there was a consumer-level Unix at all back then.
Mar 10 2012
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 10.03.2012 20:52, schrieb H. S. Teoh:
 On Sat, Mar 10, 2012 at 02:27:20PM -0500, Nick Sabalausky wrote:
 "Adam D. Ruppe"<destructionator gmail.com>  wrote in message
 news:tfdzpwcijnavdalmnzit forum.dlang.org...
 On Saturday, 10 March 2012 at 18:57:10 UTC, H. S. Teoh wrote:
 It can hardly be called a success technology-wise.
It is significantly ahead of its competition at the time.
And it was a big advancement over 3.1. Pre-emptive multitasking anyone?
[...] I thought the Unix world has had that years before Windows. But not in the consumer PC market, I suppose. But 3.1 was such a sad mess that just about *anything* would be an improvement on it. T
Sure it had pre-emptive multitasking. On the other hand, on those days, UNIX had very nice guis called Motif, NEWS and NeXTSTEP. Personally I think the only nice one was from NeXTSTEP. Each version costed a few dollars more that what most house holds would be willing to pay. And lets not forget that long before gcc became famous, you would have to pay extra for the developer tools. Which in some cases did cost as much as the OS itself. And most importantly, there were almost no games, compared with what the home markets had access to. Yes I am aware of the dirty tricks Microsoft played on IBM, but actually taking into consideration the way IBM managed OS/2, those tricks weren't actually needed. So in the end, for the people using PC compatibles, the only game in town was Windows 9x. -- Paulo
Mar 10 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/10/2012 10:58 AM, H. S. Teoh wrote:
 Win9x's success is mainly attributable to Microsoft's superior marketing
 strategies. It can hardly be called a success technology-wise.
Oh, I disagree with that. Certainly, Win9x was a compromise, but it nailed being a transition operating system from 16 to 32 bit, and it nailed making Windows an attractive target for game developers.
Mar 10 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 10/03/2012 20:37, Walter Bright a écrit :
 On 3/10/2012 10:58 AM, H. S. Teoh wrote:
 Win9x's success is mainly attributable to Microsoft's superior marketing
 strategies. It can hardly be called a success technology-wise.
Oh, I disagree with that. Certainly, Win9x was a compromise, but it nailed being a transition operating system from 16 to 32 bit, and it nailed making Windows an attractive target for game developers.
Windows 3.1 had patches provided by microsoft to handle 32bits. But this is quite offtopic. Win9x was good back then. Now it is crap. When doing something new (like D) you don't only need to provide something as good as what existed before. Actually, providing better isn't enough either. You need to provide enough to compensate the cost of the change, and additionally communication/marketing must convince user to switch.
Mar 11 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/11/2012 8:29 AM, deadalnix wrote:
 Win9x was good back then. Now it is crap.
Sure, but it's only fair to assess it in the context of its times, not current times.
 When doing something new (like D) you don't only need to provide something as
 good as what existed before. Actually, providing better isn't enough either.
You
 need to provide enough to compensate the cost of the change, and additionally
 communication/marketing must convince user to switch.
Yup.
Mar 11 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/9/12 8:40 PM, Adam D. Ruppe wrote:
 (For example, take dmd out of the box on CentOS. Won't
 work.)
Why? I have CentOS at work and it seems to work. Andrei
Mar 09 2012
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 10 March 2012 at 05:15:32 UTC, Andrei Alexandrescu 
wrote:
 Why? I have CentOS at work and it seems to work.
My work server is CentOS 5.6 (32 bit), maybe it is this specific version, but the fresh dmd always gives: 1) a libc version mismatch. I fix this by recompiling from source. 2) a linker error on warn-mismatch or something like that not being a valid option. Editing dmd.conf takes care of this one.
Mar 09 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/9/2012 8:40 PM, Adam D. Ruppe wrote:
 On Windows though, even if you relied on bugs twenty
 years ago, they bend over backward to keep your app
 functioning. It is really an amazing feat they've
 accomplished, both from technical and business
 perspectives, in doing this while still moving
 forward.
I agree that Windows does a better job of it than Linux. MS really does pour enormous effort into backwards compatibility. You could legitimately call it heroic - and it has paid off for MS.
Mar 09 2012
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 10.03.2012 06:47, schrieb Walter Bright:
 On 3/9/2012 8:40 PM, Adam D. Ruppe wrote:
 On Windows though, even if you relied on bugs twenty
 years ago, they bend over backward to keep your app
 functioning. It is really an amazing feat they've
 accomplished, both from technical and business
 perspectives, in doing this while still moving
 forward.
I agree that Windows does a better job of it than Linux. MS really does pour enormous effort into backwards compatibility. You could legitimately call it heroic - and it has paid off for MS.
For those that don't know it, this is a great blog about how Microsoft efforts in backwards compatibility. http://blogs.msdn.com/b/oldnewthing/ I must say I used to be a bit anti-Microsoft while I was at university and discovered UNIX. But later on, I got to work for a couple of Fortune 500 companies and got to understand why companies the size of Microsoft are as they are. -- Paulo
Mar 10 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
Le 10/03/2012 06:47, Walter Bright a écrit :
 On 3/9/2012 8:40 PM, Adam D. Ruppe wrote:
 On Windows though, even if you relied on bugs twenty
 years ago, they bend over backward to keep your app
 functioning. It is really an amazing feat they've
 accomplished, both from technical and business
 perspectives, in doing this while still moving
 forward.
I agree that Windows does a better job of it than Linux. MS really does pour enormous effort into backwards compatibility. You could legitimately call it heroic - and it has paid off for MS.
Micsrosoft being incompatible with mostly everything, they sure can't afford to not be compatible with themselves. This is of strategic importance for microsoft. I don't think this is as important for us as it is for microsoft (even if it is).
Mar 11 2012
prev sibling parent Jeff Nowakowski <jeff dilacero.org> writes:
On 03/09/2012 11:40 PM, Adam D. Ruppe wrote:
 On Windows though, even if you relied on bugs twenty
 years ago, they bend over backward to keep your app
 functioning.
They stopped doing that a long time ago. There's a well-known blog article about this: http://www.joelonsoftware.com/articles/APIWar.html Some apps and hardware had trouble running on XP, and Vista took this to all new levels -- one of the reasons it got so much bad press.
Mar 10 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:jjelk7$7fm$1 digitalmars.com...
 On 3/9/2012 3:09 PM, Nick Sabalausky wrote:
 Keep in mind, too, that Linux has decades of legacy and millions of 
 users.
 That's a *very* different situation from Phobos. Apples and oranges.
Linux has had a habit of not breaking existing code from decades ago. I think that is one reason why it has millions of users. Remember, every time you break existing code you reset your user base back to zero. I'm *still* regularly annoyed by the writefln => writeln change in D1 to D2, and I agreed to that change. Grrrr.
Are you kidding me? I'm *thrilled* with how much of an improvement writeln is *every time I use it*. Seriously how the hell did writeln ever hurst *anyone*? We're bitching about trivialities here.
Mar 09 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/9/2012 10:43 PM, Nick Sabalausky wrote:
 "Walter Bright"<newshound2 digitalmars.com>  wrote in message
 I'm *still* regularly annoyed by the writefln =>  writeln change in D1 to
 D2, and I agreed to that change. Grrrr.
Are you kidding me? I'm *thrilled* with how much of an improvement writeln is *every time I use it*. Seriously how the hell did writeln ever hurst *anyone*? We're bitching about trivialities here.
I'm not complaining about the functionality improvement - I think that's great. I'm talking about the name change. It's far and away the most common thing I have to edit when moving code from D1 <=> D2.
Mar 10 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:jjg7s4$24p$2 digitalmars.com...
 On 3/9/2012 10:43 PM, Nick Sabalausky wrote:
 "Walter Bright"<newshound2 digitalmars.com>  wrote in message
 I'm *still* regularly annoyed by the writefln =>  writeln change in D1 
 to
 D2, and I agreed to that change. Grrrr.
Are you kidding me? I'm *thrilled* with how much of an improvement writeln is *every time I use it*. Seriously how the hell did writeln ever hurst *anyone*? We're bitching about trivialities here.
I'm not complaining about the functionality improvement - I think that's great. I'm talking about the name change. It's far and away the most common thing I have to edit when moving code from D1 <=> D2.
I still like the name better. Do we really need an alphabet soup appended to "write" just to spit out one string? It's really not a name change at all though: It's a new function. writefln is still there with the same old functionality (which is good, it *is* a good function). It's just that writeln has been added and just happens to be better in every way for the majority of use-cases.
Mar 10 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/10/2012 11:31 AM, Nick Sabalausky wrote:
 I still like the name better. Do we really need an alphabet soup appended to
 "write" just to spit out one string?
It's not about whether it was a better name. It was about having to constantly edit code.
Mar 10 2012
next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
On 10/03/12 20:38, Walter Bright wrote:
 On 3/10/2012 11:31 AM, Nick Sabalausky wrote:
 I still like the name better. Do we really need an alphabet soup
 appended to
 "write" just to spit out one string?
It's not about whether it was a better name. It was about having to constantly edit code.
But... writefln is still there. Is it incompatible with the D1 one in some way? -Lars
Mar 10 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/10/2012 2:44 PM, Lars T. Kyllingstad wrote:
 But... writefln is still there. Is it incompatible with the D1 one in some way?
Try writefln(3);
Mar 11 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:jjho0a$2qdu$1 digitalmars.com...
 On 3/10/2012 2:44 PM, Lars T. Kyllingstad wrote:
 But... writefln is still there. Is it incompatible with the D1 one in 
 some way?
Try writefln(3);
Having been accustomed to C's printf, I don't think it would have ever even occurred to me to try that. (FWIW/YMMV)
Mar 11 2012
next sibling parent reply Matej Nanut <matejnanut gmail.com> writes:
I find the point on developing on a slower computer very interesting,
and here's my story.

I've been using an EeePC for everything for the past 2.5 years and
until now, I could cope. I'm getting a new laptop this week because I
direly need it at the faculty (some robotics/image processing/computer
vision =E2=80=94 no way to run these on an EeePC realtime).

However, I could notice an interesting trend between my colleagues'
programs and mine. For example, solving the 15-game with heuristics
took ~0.01 secs on the Eee, and comparing to others' programs theirs
took several seconds and found worse solutions (not all of them of
course, but most). When doing some local search optimisation, the
difference was seconds-to-HOURS. I guess someone was really sloppy,
but still.

This has also been one of the reasons I became interested in languages
like C and D. Believe it or not, in our university, you don't ever get
to see C officially if you don't learn it yourself. I consider this
pathetic. The official and only taught language is Java. Which I grant
them is at least cross-platform, but I believe that every
university-educated programmer must know C.

I am convinced that my university produces bad programmers and as such
don't find it surprising that new written programs are terribly slow,
if they even work at all.

Matej
Mar 11 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Matej Nanut" <matejnanut gmail.com> wrote in message 
news:mailman.471.1331466712.4860.digitalmars-d puremagic.com...
I'm getting a new laptop this week because I
direly need it at the faculty (some robotics/image processing/computer
vision
Neat stuff!!
However, I could notice an interesting trend between my colleagues'
programs and mine. For example, solving the 15-game with heuristics
took ~0.01 secs on the Eee, and comparing to others' programs theirs
took several seconds and found worse solutions (not all of them of
course, but most). When doing some local search optimisation, the
difference was seconds-to-HOURS. I guess someone was really sloppy,
but still.
Yup. Not surprised.
This has also been one of the reasons I became interested in languages
like C and D. Believe it or not, in our university, you don't ever get
to see C officially if you don't learn it yourself. I consider this
pathetic. The official and only taught language is Java. Which I grant
them is at least cross-platform, but I believe that every
university-educated programmer must know C.
Yea, Java has been pretty much the de facto standard College Computer Science language since I left college (close to 10 years ago now...god, that just seems so *wrong* that's it's been that long...)
I am convinced that my university produces bad programmers and as such
don't find it surprising that new written programs are terribly slow,
if they even work at all.
I'm convinced that colleges in general produce very bad programmers. The good programmers who have degrees, for the most part (I'm sure there are rare exceptions), are the ones who learned on their own, not in a classroom. It's sad that society brainwashes people into believing the opposite.
Mar 11 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/11/2012 12:32 PM, Nick Sabalausky wrote:
 I'm convinced that colleges in general produce very bad programmers. The
 good programmers who have degrees, for the most part (I'm sure there are
 rare exceptions), are the ones who learned on their own, not in a classroom.
Often the best programmers seem to have physics degrees!
Mar 11 2012
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 11/03/2012 21:07, Walter Bright a écrit :
 On 3/11/2012 12:32 PM, Nick Sabalausky wrote:
 I'm convinced that colleges in general produce very bad programmers. The
 good programmers who have degrees, for the most part (I'm sure there are
 rare exceptions), are the ones who learned on their own, not in a
 classroom.
Often the best programmers seem to have physics degrees!
I saw you coming ^^.
Mar 11 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/11/2012 3:36 PM, deadalnix wrote:
 Le 11/03/2012 21:07, Walter Bright a écrit :
 On 3/11/2012 12:32 PM, Nick Sabalausky wrote:
 I'm convinced that colleges in general produce very bad programmers. The
 good programmers who have degrees, for the most part (I'm sure there are
 rare exceptions), are the ones who learned on their own, not in a
 classroom.
Often the best programmers seem to have physics degrees!
I saw you coming ^^.
Whether or not anyone considers me a good programmer, I don't have a degree in physics. Frankly, I wasn't good enough to consider it.
Mar 11 2012
prev sibling parent reply =?utf-8?Q?Simen_Kj=C3=A6r=C3=A5s?= <simen.kjaras gmail.com> writes:
On Sun, 11 Mar 2012 21:07:06 +0100, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 3/11/2012 12:32 PM, Nick Sabalausky wrote:
 I'm convinced that colleges in general produce very bad programmers. The
 good programmers who have degrees, for the most part (I'm sure there are
 rare exceptions), are the ones who learned on their own, not in a  
 classroom.
Often the best programmers seem to have physics degrees!
Eugh. Physicist programmers tend to use one-letter variable names in my experience. Makes for... interesting reading of their code.
Mar 12 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Simen Kjærås" <simen.kjaras gmail.com> wrote in message 
news:op.wa28iobk0gpyof biotronic.lan...
 On Sun, 11 Mar 2012 21:07:06 +0100, Walter Bright 
 <newshound2 digitalmars.com> wrote:

 On 3/11/2012 12:32 PM, Nick Sabalausky wrote:
 I'm convinced that colleges in general produce very bad programmers. The
 good programmers who have degrees, for the most part (I'm sure there are
 rare exceptions), are the ones who learned on their own, not in a 
 classroom.
Often the best programmers seem to have physics degrees!
Eugh. Physicist programmers tend to use one-letter variable names in my experience. Makes for... interesting reading of their code.
D is great for physics programming. Now you can have much, much more than 26 variables :)
Mar 12 2012
parent reply =?utf-8?Q?Simen_Kj=C3=A6r=C3=A5s?= <simen.kjaras gmail.com> writes:
On Tue, 13 Mar 2012 03:50:49 +0100, Nick Sabalausky <a a.a> wrote:

 "Simen Kj=C3=A6r=C3=A5s" <simen.kjaras gmail.com> wrote in message
 news:op.wa28iobk0gpyof biotronic.lan...
 On Sun, 11 Mar 2012 21:07:06 +0100, Walter Bright
 <newshound2 digitalmars.com> wrote:

 On 3/11/2012 12:32 PM, Nick Sabalausky wrote:
 I'm convinced that colleges in general produce very bad programmers=
. =
 The
 good programmers who have degrees, for the most part (I'm sure ther=
e =
 are
 rare exceptions), are the ones who learned on their own, not in a
 classroom.
Often the best programmers seem to have physics degrees!
Eugh. Physicist programmers tend to use one-letter variable names in =
my
 experience. Makes for... interesting reading of their code.
D is great for physics programming. Now you can have much, much more =
 than 26
 variables :)
True, though mostly, you'd just change to using greek letters, right? Finally we can use =CE=B8 for angles, alias ulong =E2=84=95...
Mar 12 2012
next sibling parent James Miller <james aatch.net> writes:
On 13 March 2012 16:10, Simen Kj=C3=A6r=C3=A5s <simen.kjaras gmail.com> wro=
te:
 On Tue, 13 Mar 2012 03:50:49 +0100, Nick Sabalausky <a a.a> wrote:

 "Simen Kj=C3=A6r=C3=A5s" <simen.kjaras gmail.com> wrote in message
 news:op.wa28iobk0gpyof biotronic.lan...
 On Sun, 11 Mar 2012 21:07:06 +0100, Walter Bright
 <newshound2 digitalmars.com> wrote:

 On 3/11/2012 12:32 PM, Nick Sabalausky wrote:
 I'm convinced that colleges in general produce very bad programmers.
 The
 good programmers who have degrees, for the most part (I'm sure there
 are
 rare exceptions), are the ones who learned on their own, not in a
 classroom.
Often the best programmers seem to have physics degrees!
Eugh. Physicist programmers tend to use one-letter variable names in my experience. Makes for... interesting reading of their code.
D is great for physics programming. Now you can have much, much more tha=
n
 26
 variables :)
True, though mostly, you'd just change to using greek letters, right? Finally we can use =CE=B8 for angles, alias ulong =E2=84=95...
That might actually make it /more/ readable in some cases. -- James Miller
Mar 12 2012
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 13, 2012 at 04:10:20AM +0100, Simen Kjærås wrote:
 On Tue, 13 Mar 2012 03:50:49 +0100, Nick Sabalausky <a a.a> wrote:
[...]
D is great for physics programming. Now you can have much, much more
than 26 variables :)
True, though mostly, you'd just change to using greek letters, right?
And Russian. And extended Latin. And Chinese (try exhausting that one!). And a whole bunch of other stuff that you may not have known even existed.
 Finally we can use θ for angles, alias ulong ℕ...
+1. Come to think of it, I wonder if it's possible to write a large D program using only 1-letter identifiers. After all, Unicode has enough alphabetic characters that you could go for a long, long time before you exhausted them all. (The CJK block will be especially resilient to exhaustion.) :-) Worse yet, if you don't have fonts installed for some of the Unicode blocks, you'd just end up with functions and variables that have invisible names (or they all look like a black splotch). So it'll be a bunch of code that reads like black splotch = black splotch ( black splotch ) + black splotch. Ah, the hilarity that will ensue... T -- It's bad luck to be superstitious. -- YHL
Mar 12 2012
parent =?utf-8?Q?Simen_Kj=C3=A6r=C3=A5s?= <simen.kjaras gmail.com> writes:
On Tue, 13 Mar 2012 06:45:12 +0100, H. S. Teoh <hsteoh quickfur.ath.cx> =
 =

wrote:

 On Tue, Mar 13, 2012 at 04:10:20AM +0100, Simen Kj=C3=A6r=C3=A5s wrote=
:
 On Tue, 13 Mar 2012 03:50:49 +0100, Nick Sabalausky <a a.a> wrote:
[...]
D is great for physics programming. Now you can have much, much more=
than 26 variables :)
True, though mostly, you'd just change to using Greek letters, right?=
 And Russian. And extended Latin. And Chinese (try exhausting that one!=
).
 And a whole bunch of other stuff that you may not have known even
 existed.
I know Unicode covers a lot more than just Greek. I didn't know the usag= e of Chinese was very common among physicists, though. :p
 Finally we can use =CE=B8 for angles, alias ulong =E2=84=95...
+1. Come to think of it, I wonder if it's possible to write a large D program using only 1-letter identifiers. After all, Unicode has enough=
 alphabetic characters that you could go for a long, long time before y=
ou
 exhausted them all. (The CJK block will be especially resilient to
 exhaustion.) :-)
63,207[1] designated characters thus far[2]. Add in module names and oth= er 'namespaces', and I'd say that should be no problem at all. As long as your head doesn't explode, that is. [1] http://unicode.org/alloc/CurrentAllocation.html [2] Yeah, not all of those are valid identifiers.
Mar 13 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Mar 11, 2012 at 03:32:39PM -0400, Nick Sabalausky wrote:
[...]
 I'm convinced that colleges in general produce very bad programmers.
 The good programmers who have degrees, for the most part (I'm sure
 there are rare exceptions), are the ones who learned on their own, not
 in a classroom.  It's sad that society brainwashes people into
 believing the opposite.
[...] I have a master's degree in computer science. About 90% (perhaps 95%) of what I do at my day job is stuff I learned on my own outside the classroom. That is not to say the classroom is completely worthless, mind you; courses like discrete maths and programming logic did train me to think logically and rigorously, an indispensible requirement in the field. However, I also found that most big-name colleges are geared toward producing researchers rather than programmers in the industry. Now I don't know if this applies in general, but the curriculum I was in was so geared towards CS research rather than doing real industry work (i.e., write actual programs!) that we spent more time studying uncomputable problems than computable ones. OK, so knowing what isn't computable is important so that you don't waste time trying to solve the halting problem, for example. But when *most* (all?) of your time is spent contemplating the uncomputable, wouldn't you say that you're a bit too high up in that ivory tower? I mean, this is *computer science*, not *uncomputable science* we're talking about. Case in point. One of the courses I took as a grad student was taught by none less than Professor Cook himself (y'know the guy behind Cook's Theorem). He was a pretty cool guy, and I respect him for what he does. But the course material was... I don't remember what the official course title was, but we spent the entire term proving stuff about proofs. Let me say that again. I'm not just talking about spending the entire semester proving math theorems (which is already questionable enough in a course that's listed as a *computer science* course). I'm talking about spending the entire semester proving things *about* math proofs. IOW, we were dealing with *meta-proofs*. And most of the "proofs" we proved things about involved *proofs of infinite length*. Yeah. I spent the entire course repeatedly wondering if I had misread the course calendar and gone to the wrong class, and, when I had ruled that out, what any of this meta-proof stuff had to do with programming. T -- Recently, our IT department hired a bug-fix engineer. He used to work for Volkswagen.
Mar 11 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.510.1331520028.4860.digitalmars-d puremagic.com...
 That is not to say the classroom is completely worthless,
 mind you;
I'd say that, and I often have ;) And I forever will.
 courses like discrete maths
Personally, I found discrete math to be the easiest class I took since kindergarten (*Both* of the times they made me take discrete math. Ugh. God that got boring.) It was almost entirely the sorts of things that any average coder already understands intuitively. Like DeMorgan's: I hadn't known the name "DeMorgan", but just from growing up writing "if" statements I had already grokked how it worked and how to use it. No doubt in my mind that *all* of us here have grokked it (even any of us who might not know it by name) *and* many of the coworkers I've had who I'd normally classify as "incompetent VB-loving imbiciles". Then there was Pidgeonhole principle, which was basically just obvious corollaries to preschool-level spacial relations. Etc. All pretty much BASIC-level stuff.
 and programming logic did train me
 to think logically and rigorously, an indispensible requirement in the
 field.

 However, I also found that most big-name colleges are geared toward
 producing researchers rather than programmers in the industry.
The colleges I've seen seemed to have an identity crisis in that regard: Sometimes they acted like their role was teaching theory, sometimes they acted like their role was job training/placement, and all the time they were incompetent at both.
 Case in point. One of the courses I took as a grad student was taught by
 none less than Professor Cook himself (y'know the guy behind Cook's
 Theorem). He was a pretty cool guy, and I respect him for what he does.
 But the course material was... I don't remember what the official course
 title was, but we spent the entire term proving stuff about proofs.  Let
 me say that again.  I'm not just talking about spending the entire
 semester proving math theorems (which is already questionable enough in
 a course that's listed as a *computer science* course). I'm talking
 about spending the entire semester proving things *about* math proofs.
 IOW, we were dealing with *meta-proofs*.  And most of the "proofs" we
 proved things about involved *proofs of infinite length*.

 Yeah.

 I spent the entire course repeatedly wondering if I had misread the
 course calendar and gone to the wrong class, and, when I had ruled that
 out, what any of this meta-proof stuff had to do with programming.
I once made the mistake of signing up for a class that claimed to be part of the CS department and was titled "Optimization Techniques". I thought it was obvious what it was and that it would be a great class for me to take. Turned out to be a class that, realistically, belonged in the Math dept and had nothing to do with efficient software, even in theory. Wasn't even in the ballpark of Big-O, etc. It was linear algebra with large numbers of variables. I'm sure it would be great material for the right person, but it wasn't remotely what I expected given the name and department of the course. (Actually, similar thing with my High School class of "Business Law" - Turned out to have *nothing* to do with business whatsoever. Never understood why they didn't just call the class "Law" or "Civic Law".) Kinda felt "baited and switched" both times.
Mar 11 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Mar 12, 2012 at 01:36:06AM -0400, Nick Sabalausky wrote:
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.510.1331520028.4860.digitalmars-d puremagic.com...
[...]
 Personally, I found discrete math to be the easiest class I took since
 kindergarten (*Both* of the times they made me take discrete math.
 Ugh. God that got boring.) It was almost entirely the sorts of things
 that any average coder already understands intuitively. Like
 DeMorgan's: I hadn't known the name "DeMorgan", but just from growing
 up writing "if" statements I had already grokked how it worked and how
 to use it. No doubt in my mind that *all* of us here have grokked it
 (even any of us who might not know it by name) *and* many of the
 coworkers I've had who I'd normally classify as "incompetent VB-loving
 imbiciles".
It's not that I didn't already know most of the stuff intuitively, I found that, in retrospect, having to learn it formally helped to solidify my mental grasp of it, and to be able to analyse it abstractly without being tied to intuition. This later developed into the ability to reason about other stuff in the same way, so you could *derive* new stuff yourself in similar ways.
 Then there was Pidgeonhole principle, which was basically just obvious
 corollaries to preschool-level spacial relations. Etc.  All pretty
 much BASIC-level stuff.
Oh reeeeaally?! Just wait till you learn how the pigeonhole principle allows you to do arithmetic with infinite quantities... ;-) (And before you shoot me down with "infinite quantities are not practical in programming", I'd like to say that certain non-finite arithmetic systems actually have real-life consequences in finite computations. Look up "Hydra game" sometime. Or "Goldstein sequences" if you're into that sorta thing.) [...]
 However, I also found that most big-name colleges are geared toward
 producing researchers rather than programmers in the industry.
The colleges I've seen seemed to have an identity crisis in that regard: Sometimes they acted like their role was teaching theory, sometimes they acted like their role was job training/placement, and all the time they were incompetent at both.
In my experience, I found that the quality of a course depends a LOT on the attitude and teaching ability of the professor. I've had courses which were like mind-openers every other class, where you just go "wow, *that* is one heck of a cool algorithm!". Unfortunately, (1) most professors can't teach; (2) they're not *paid* to teach (they're paid to do research), so they regard it as a tedious chore imposed upon them that takes away their time for research. This makes them hate teaching, and so most courses suck. [...]
 I once made the mistake of signing up for a class that claimed to be
 part of the CS department and was titled "Optimization Techniques". I
 thought it was obvious what it was and that it would be a great class
 for me to take.  Turned out to be a class that, realistically,
 belonged in the Math dept and had nothing to do with efficient
 software, even in theory. Wasn't even in the ballpark of Big-O, etc.
 It was linear algebra with large numbers of variables.
Ahhhhahahahahaha... must've been high-dimensional polytope optimization stuff, I'll bet. That stuff *does* have its uses... but yeah, that was a really dumb course title. Another dumb course title that I've encountered was along the lines of "computational theory" where 95% of the course talks about *uncomputable* problems. You'd think they would've named it "*un*computational theory". :-P
 I'm sure it would be great material for the right person, but it
 wasn't remotely what I expected given the name and department of the
 course.  (Actually, similar thing with my High School class of
 "Business Law" - Turned out to have *nothing* to do with business
 whatsoever. Never understood why they didn't just call the class "Law"
 or "Civic Law".) Kinda felt "baited and switched" both times.
[...] That's why I always took the effort read course descriptions VERY carefully before I sign up. It's like the fine print in contracts. You skip over it at your own peril. (Though, that didn't stop me from taking "Number Theory". Or "Set Theory". Both of which went wayyyyyy over my head for the most part.) T -- 2+2=4. 2*2=4. 2^2=4. Therefore, +, *, and ^ are the same operation.
Mar 11 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.531.1331533449.4860.digitalmars-d puremagic.com...
 On Mon, Mar 12, 2012 at 01:36:06AM -0400, Nick Sabalausky wrote:
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message
 news:mailman.510.1331520028.4860.digitalmars-d puremagic.com...
[...]
 Personally, I found discrete math to be the easiest class I took since
 kindergarten (*Both* of the times they made me take discrete math.
 Ugh. God that got boring.) It was almost entirely the sorts of things
 that any average coder already understands intuitively. Like
 DeMorgan's: I hadn't known the name "DeMorgan", but just from growing
 up writing "if" statements I had already grokked how it worked and how
 to use it. No doubt in my mind that *all* of us here have grokked it
 (even any of us who might not know it by name) *and* many of the
 coworkers I've had who I'd normally classify as "incompetent VB-loving
 imbiciles".
It's not that I didn't already know most of the stuff intuitively,
Didn't mean to imply that you didn't, of course.
 Then there was Pidgeonhole principle, which was basically just obvious
 corollaries to preschool-level spacial relations. Etc.  All pretty
 much BASIC-level stuff.
Oh reeeeaally?! Just wait till you learn how the pigeonhole principle allows you to do arithmetic with infinite quantities... ;-)
Well, the discrete math courses offered at the places I went to didn't take things that far. Just explained the principle itself.
 (And before you shoot me down with "infinite quantities are not
 practical in programming", I'd like to say that certain non-finite
 arithmetic systems actually have real-life consequences in finite
 computations. Look up "Hydra game" sometime. Or "Goldstein sequences" if
 you're into that sorta thing.)
Yea, I don't doubt that. While no game programmer, for example, would be caught dead having their code crunching calculus computations, there are some computations done in games that are obtained in the first place by doing some calculus (mostly physics, IIRC). Not exactly the same thing, but I get that applicablity of theory isn't limited to what the computer is actually calculating.
 [...]
 However, I also found that most big-name colleges are geared toward
 producing researchers rather than programmers in the industry.
The colleges I've seen seemed to have an identity crisis in that regard: Sometimes they acted like their role was teaching theory, sometimes they acted like their role was job training/placement, and all the time they were incompetent at both.
In my experience, I found that the quality of a course depends a LOT on the attitude and teaching ability of the professor. I've had courses which were like mind-openers every other class, where you just go "wow, *that* is one heck of a cool algorithm!".
Yea, I *have* had some good instructors. Not many. But some.
 Unfortunately, (1) most professors can't teach; (2) they're not *paid*
 to teach (they're paid to do research), so they regard it as a tedious
 chore imposed upon them that takes away their time for research. This
 makes them hate teaching, and so most courses suck.
although I'm uncertain how applicable it is to public party schools like BGSU. There didn't seem to be much research going on there as far as I could tell, but I could be wrong though.
 [...]
 I once made the mistake of signing up for a class that claimed to be
 part of the CS department and was titled "Optimization Techniques". I
 thought it was obvious what it was and that it would be a great class
 for me to take.  Turned out to be a class that, realistically,
 belonged in the Math dept and had nothing to do with efficient
 software, even in theory. Wasn't even in the ballpark of Big-O, etc.
 It was linear algebra with large numbers of variables.
Ahhhhahahahahaha... must've been high-dimensional polytope optimization stuff, I'll bet.
Sounds about right. I think the term "linear programming" was tossed around a bit, which I do remember from high school to be an application of linear algebra rather than software.
 That stuff *does* have its uses...
Yea, I never doubted that. Just not what I was expected. Really caught me offguard.
 but yeah, that was a
 really dumb course title.

 Another dumb course title that I've encountered was along the lines of
 "computational theory" where 95% of the course talks about
 *uncomputable* problems. You'd think they would've named it
 "*un*computational theory". :-P
Yea that is kinda funny.
 I'm sure it would be great material for the right person, but it
 wasn't remotely what I expected given the name and department of the
 course.  (Actually, similar thing with my High School class of
 "Business Law" - Turned out to have *nothing* to do with business
 whatsoever. Never understood why they didn't just call the class "Law"
 or "Civic Law".) Kinda felt "baited and switched" both times.
[...] That's why I always took the effort read course descriptions VERY carefully before I sign up. It's like the fine print in contracts. You skip over it at your own peril.
Our course descriptions didn't have much fine print. Just one short vaguely-worded paragraph. I probably could have asked around and gotten a syllubus from previous semesters, but I didn't learn advanced student tricks like that until a few years into college. ;) Plus, that's other concerns, like scheduling and requirements. I found that a lot of my course selections had to be dictated more by scheduling and availability than much anything else.
Mar 12 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Mar 12, 2012 at 03:15:32PM -0400, Nick Sabalausky wrote:
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.531.1331533449.4860.digitalmars-d puremagic.com...
[...]
 (And before you shoot me down with "infinite quantities are not
 practical in programming", I'd like to say that certain non-finite
 arithmetic systems actually have real-life consequences in finite
 computations. Look up "Hydra game" sometime. Or "Goldstein
 sequences" if you're into that sorta thing.)
Argh. Epic fail on my part, it's *Goodstein* sequence, not Goldstein.
 Yea, I don't doubt that. While no game programmer, for example, would
 be caught dead having their code crunching calculus computations,
 there are some computations done in games that are obtained in the
 first place by doing some calculus (mostly physics, IIRC). Not exactly
 the same thing, but I get that applicablity of theory isn't limited to
 what the computer is actually calculating.
I think the bottom line is that a lot of this stuff needs someone who can explain and teach it in an engaging, interesting way. It's not that the subject matter itself is boring or stupid, but that the teacher failed at his job and so his students find the subject boring and stupid. [...]
 Our course descriptions didn't have much fine print. Just one short
 vaguely-worded paragraph. I probably could have asked around and
 gotten a syllubus from previous semesters, but I didn't learn advanced
 student tricks like that until a few years into college. ;) Plus,
 that's other concerns, like scheduling and requirements. I found that
 a lot of my course selections had to be dictated more by scheduling
 and availability than much anything else.
I guess I was lucky then. There were a couple o' useless mandatory courses I had to take, but for the most part, I got to choose what I wanted. (And then my geeky side took over and I filled up most of my electives with math courses... sigh...) T -- Some days you win; most days you lose.
Mar 12 2012
prev sibling parent James Miller <james aatch.net> writes:
On 12 March 2012 15:42, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 On Sun, Mar 11, 2012 at 03:32:39PM -0400, Nick Sabalausky wrote:
 [...]
 I'm convinced that colleges in general produce very bad programmers.
 The good programmers who have degrees, for the most part (I'm sure
 there are rare exceptions), are the ones who learned on their own, not
 in a classroom. =C2=A0It's sad that society brainwashes people into
 believing the opposite.
[...] I have a master's degree in computer science. About 90% (perhaps 95%) of what I do at my day job is stuff I learned on my own outside the classroom. That is not to say the classroom is completely worthless, mind you; courses like discrete maths and programming logic did train me to think logically and rigorously, an indispensible requirement in the field. However, I also found that most big-name colleges are geared toward producing researchers rather than programmers in the industry. Now I don't know if this applies in general, but the curriculum I was in was so geared towards CS research rather than doing real industry work (i.e., write actual programs!) that we spent more time studying uncomputable problems than computable ones. OK, so knowing what isn't computable is important so that you don't waste time trying to solve the halting problem, for example. But when *most* (all?) of your time is spent contemplating the uncomputable, wouldn't you say that you're a bit too high up in that ivory tower? I mean, this is *computer science*, not *uncomputable science* we're talking about. Case in point. One of the courses I took as a grad student was taught by none less than Professor Cook himself (y'know the guy behind Cook's Theorem). He was a pretty cool guy, and I respect him for what he does. But the course material was... I don't remember what the official course title was, but we spent the entire term proving stuff about proofs. =C2=
=A0Let
 me say that again. =C2=A0I'm not just talking about spending the entire
 semester proving math theorems (which is already questionable enough in
 a course that's listed as a *computer science* course). I'm talking
 about spending the entire semester proving things *about* math proofs.
 IOW, we were dealing with *meta-proofs*. =C2=A0And most of the "proofs" w=
e
 proved things about involved *proofs of infinite length*.

 Yeah.

 I spent the entire course repeatedly wondering if I had misread the
 course calendar and gone to the wrong class, and, when I had ruled that
 out, what any of this meta-proof stuff had to do with programming.


 T

 --
 Recently, our IT department hired a bug-fix engineer. He used to work
 for Volkswagen.
I'm entirely self-taught, and currently taking a break from university (too much debt, not enough time, too much stress). I rarely use stuff that I haven't taught myself. I realize now that trying to teach people how to program is very, very hard however, since I always think about how to teach stuff I know. Ideally you'd learn everything at once and spend the next 2 years re-arranging it in your brain, but unfortunately people don't work like that... -- James Miller
Mar 11 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/11/2012 4:20 AM, Matej Nanut wrote:
 I've been using an EeePC for everything for the past 2.5 years and
 until now, I could cope.
You're right that there's a downside to providing your developers the hottest machines available - their code tends to be a dog on the machines your customer has. I have an EeePC, but I find I could not cope with the tiny screen and tiny keyboard :-)
Mar 11 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:jjj0je$2bse$2 digitalmars.com...
 On 3/11/2012 4:20 AM, Matej Nanut wrote:
 I've been using an EeePC for everything for the past 2.5 years and
 until now, I could cope.
You're right that there's a downside to providing your developers the hottest machines available - their code tends to be a dog on the machines your customer has. I have an EeePC, but I find I could not cope with the tiny screen and tiny keyboard :-)
I've often found the keys on a normal sized keyboard to be a bit small. (I have somewhat large hands - I think the original XBox1 "Duke" controller is the only good-sized game controller.) I spent some time trying to find a keyboard with slightly larger than normal keys, but couldn't come up with anything. OTOH, I may have just been being sloppy with my keypresses: I'm not hitting multiple keys anymore like I had been for awhile.
Mar 11 2012
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 11/03/2012 21:06, Walter Bright a écrit :
 On 3/11/2012 4:20 AM, Matej Nanut wrote:
 I've been using an EeePC for everything for the past 2.5 years and
 until now, I could cope.
You're right that there's a downside to providing your developers the hottest machines available - their code tends to be a dog on the machines your customer has.
I think a better solution is including expected performances in the user stories and add them in the testing suite. Dev can enjoy a powerful machine without risking to get a resource monster as a final executable.
Mar 11 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Mar 11, 2012 at 11:38:12PM +0100, deadalnix wrote:
 Le 11/03/2012 21:06, Walter Bright a écrit :
On 3/11/2012 4:20 AM, Matej Nanut wrote:
I've been using an EeePC for everything for the past 2.5 years and
until now, I could cope.
You're right that there's a downside to providing your developers the hottest machines available - their code tends to be a dog on the machines your customer has.
I think a better solution is including expected performances in the user stories and add them in the testing suite. Dev can enjoy a powerful machine without risking to get a resource monster as a final executable.
Even better, have some way of running your program with artificially reduced speed & resources, so that you can (sortof) see how your program degrades with lower-powered systems. Perhaps run the program inside a VM or emulator? T -- It's bad luck to be superstitious. -- YHL
Mar 11 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.517.1331521772.4860.digitalmars-d puremagic.com...
 On Sun, Mar 11, 2012 at 11:38:12PM +0100, deadalnix wrote:
 I think a better solution is including expected performances in the
 user stories and add them in the testing suite. Dev can enjoy a
 powerful machine without risking to get a resource monster as a final
 executable.
Even better, have some way of running your program with artificially reduced speed & resources, so that you can (sortof) see how your program degrades with lower-powered systems. Perhaps run the program inside a VM or emulator?
I don't think such things would ever truly work, except maybe in isolated cases. It's an issue of dogfooding. But then these "eat your cake and then still have it" strategies ultimately mean that you're *not* actually doing the dogfooding, just kinda pretending to. Instead, you'd be eating steak seven days a week, occasionally do a half-bite of dogfooding, and immediately wash it down with...I dunno, name some fancy expensive drink, I don't know my wines ;)
Mar 11 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Mar 12, 2012 at 01:48:46AM -0400, Nick Sabalausky wrote:
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.517.1331521772.4860.digitalmars-d puremagic.com...
 On Sun, Mar 11, 2012 at 11:38:12PM +0100, deadalnix wrote:
 I think a better solution is including expected performances in the
 user stories and add them in the testing suite. Dev can enjoy a
 powerful machine without risking to get a resource monster as a
 final executable.
Even better, have some way of running your program with artificially reduced speed & resources, so that you can (sortof) see how your program degrades with lower-powered systems. Perhaps run the program inside a VM or emulator?
I don't think such things would ever truly work, except maybe in isolated cases. It's an issue of dogfooding. But then these "eat your cake and then still have it" strategies ultimately mean that you're *not* actually doing the dogfooding, just kinda pretending to. Instead, you'd be eating steak seven days a week, occasionally do a half-bite of dogfooding, and immediately wash it down with...I dunno, name some fancy expensive drink, I don't know my wines ;)
[...] Nah, it's like ordering extra large triple steak burger with double-extra cheese, extra bacon, sausage on the side, extra large french fries swimming in grease, and _diet_ coke to go with it. T -- Blunt statements really don't have a point.
Mar 11 2012
prev sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Sun, 11 Mar 2012 12:20:43 +0100, Matej Nanut <matejnanut gmail.com>  =

wrote:

 I find the point on developing on a slower computer very interesting,
 and here's my story.

 I've been using an EeePC for everything for the past 2.5 years and
 until now, I could cope. I'm getting a new laptop this week because I
 direly need it at the faculty (some robotics/image processing/computer=
 vision =E2=80=94 no way to run these on an EeePC realtime).
I recently switch from an Atom N330 to a Core i5-2400S. While being about 10x faster at compilation it lead to more trial and error compilation. Turnaround times with dmd are a little too short.
Mar 11 2012
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Mar 11, 2012 at 12:20:43PM +0100, Matej Nanut wrote:
[...]
 This has also been one of the reasons I became interested in languages
 like C and D. Believe it or not, in our university, you don't ever get
 to see C officially if you don't learn it yourself. I consider this
 pathetic. The official and only taught language is Java.
Ugh.
 Which I grant them is at least cross-platform, but I believe that
 every university-educated programmer must know C.
+1. Java is a not-bad language. In fact, as a language it has quite a few good points. However, one thing I could never stand about Java culture is what I call the bandwagon-jumping attitude. It's this obsessive belief that Java is the best thing invented since coffee (har har) and that it's the panacea to solve all programming problems, cure world hunger, and solve world peace, and that whoever doesn't use Java must therefore be some inferior antiquated dinosaur from the last ice age. Every new trend that comes out must be blindly adopted without any question, because obviously new == good, and therefore whatever diseased fancy some self-appointed genius dreamed up one night must be adopted without regard for whether it actually adds value. C is therefore a fossilized relic from bygone times and nobody uses it anymore, and we've never heard of what on earth an assembler is, neither do we care, since the JVM is obviously superior anyway. As the saying goes, if you don't know history, you'll end up repeating it.
 I am convinced that my university produces bad programmers and as such
 don't find it surprising that new written programs are terribly slow,
 if they even work at all.
[...] Obligatory quote: If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell :-) T -- Question authority. Don't ask why, just do it.
Mar 11 2012
parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.479.1331479176.4860.digitalmars-d puremagic.com...
 Java is a not-bad language. In fact, as a language it has quite a few
 good points.
+1 Java's actually the reason I got fed up with C++'s *cough*module system*cough* and header files. The lack of "->" was nice too.
 However, one thing I could never stand about Java culture
 is what I call the bandwagon-jumping attitude. [...]
+1, or two, or three
 Obligatory quote:

 If Java had true garbage collection, most programs would delete
 themselves upon execution. -- Robert Sewell

 :-)
Hah! Fantastic.
 -- 
 Question authority. Don't ask why, just do it.
Fantastic, too. :)
Mar 11 2012
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 10/03/2012 20:38, Walter Bright a écrit :
 On 3/10/2012 11:31 AM, Nick Sabalausky wrote:
 I still like the name better. Do we really need an alphabet soup
 appended to
 "write" just to spit out one string?
It's not about whether it was a better name. It was about having to constantly edit code.
I do think better name isn't the problem. The problem is about consistency, and will persist as long as we don't agree on a guideline on that in phobos. Changing a name just for changing it doesn't worth the cost, unless the original name is horribly misleading - rare case. But getting the naming convention consistent is of much greater importance, and justify breaking code.
Mar 11 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/11/2012 8:34 AM, deadalnix wrote:
 I do think better name isn't the problem. The problem is about consistency, and
 will persist as long as we don't agree on a guideline on that in phobos.

 Changing a name just for changing it doesn't worth the cost, unless the
original
 name is horribly misleading - rare case. But getting the naming convention
 consistent is of much greater importance, and justify breaking code.
Frankly, I think naming conventions are overrated. The problem is that, as the sec vs seconds debate shows, there is not a correct answer. It becomes a bikeshed issue. There are a lot of considerations for a name, usually conflicting with each other. To set rules in concrete and follow them no matter what is a formula for silly results. I'm not suggesting no naming convention. Naming conventions are good. But they don't trump everything else in importance, not even close. And sometimes, a name change can be a huge win - the invariant=>immutable one is an example. But I think that's an exceptional case, not a rule.
Mar 11 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, March 11, 2012 13:16:44 Walter Bright wrote:
 On 3/11/2012 8:34 AM, deadalnix wrote:
 I do think better name isn't the problem. The problem is about
 consistency, and will persist as long as we don't agree on a guideline on
 that in phobos.
 
 Changing a name just for changing it doesn't worth the cost, unless the
 original name is horribly misleading - rare case. But getting the naming
 convention consistent is of much greater importance, and justify breaking
 code.
Frankly, I think naming conventions are overrated. The problem is that, as the sec vs seconds debate shows, there is not a correct answer. It becomes a bikeshed issue. There are a lot of considerations for a name, usually conflicting with each other. To set rules in concrete and follow them no matter what is a formula for silly results. I'm not suggesting no naming convention. Naming conventions are good. But they don't trump everything else in importance, not even close. And sometimes, a name change can be a huge win - the invariant=>immutable one is an example. But I think that's an exceptional case, not a rule.
Another issue is the question of what you consider consitency to be. On the whole, I really don't see much inconsistent about Phobos' naming at this point. The main problem that it's had is that it hasn't always used camelcasing historically, and a number of functions weren't camelcased like the rest and like we'd decide we wanted our function names and enum values to generally be. That's mostly been fixed. And yet there are still some people complaining about consistency. And to boot, other than the issue of secs vs seconds, I don't know what they even think is inconsistent. Some very basic conventions (such as the normal casing rules for various types of symbols) are certainly helpful, but you _are_ going to have corner cases, and if we tried to have strict and complicated rules on naming, it would just be frustrating all around. Not to mention, there's always _someone_ who comes up with a reason why they think that a particular name is bad or doesn't fit with the rest. So, I think that Phobos is mostly consistent with its naming at this point, and aside from some people not liking the name of a function or two, I really don't see what there is to complain about. - Jonathan M Davis
Mar 11 2012
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

 And sometimes, a name change can be a huge win - the invariant=>immutable one
is 
 an example. But I think that's an exceptional case, not a rule.
I was among the ones that have asked for that name change. But "immutable" is a quite long word. Now I think the "val" used by Scala is better, it uses less space for something I use often enough. "imm" is another option, but it looks less nice :-) Bye, bearophile
Mar 11 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/11/2012 2:51 PM, bearophile wrote:
 And sometimes, a name change can be a huge win - the invariant=>immutable
 one is an example. But I think that's an exceptional case, not a rule.
I was among the ones that have asked for that name change. But "immutable" is a quite long word. Now I think the "val" used by Scala is better, it uses less space for something I use often enough. "imm" is another option, but it looks less nice :-)
The reason we went with "immutable" is for any other name, I'd be constantly explaining: "xyzzy" means immutable And I did just that for "invariant". Over and over and over. People immediately get what "immutable" means, like for no other name. So consider "immutable" a labor saving device for me.
Mar 11 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 11/03/2012 23:12, Walter Bright a écrit :
 On 3/11/2012 2:51 PM, bearophile wrote:
 And sometimes, a name change can be a huge win - the
 invariant=>immutable
 one is an example. But I think that's an exceptional case, not a rule.
I was among the ones that have asked for that name change. But "immutable" is a quite long word. Now I think the "val" used by Scala is better, it uses less space for something I use often enough. "imm" is another option, but it looks less nice :-)
The reason we went with "immutable" is for any other name, I'd be constantly explaining: "xyzzy" means immutable And I did just that for "invariant". Over and over and over. People immediately get what "immutable" means, like for no other name. So consider "immutable" a labor saving device for me.
We have the same phenomena with dur and return type type qualifier (ie: why does const int* fun() isn't compiling ? Because const is qualifying the function, not the return type). Both are recurring questions and so should be as important as immutable. But both are major breaking change.
Mar 11 2012
parent "Nick Sabalausky" <a a.a> writes:
"deadalnix" <deadalnix gmail.com> wrote in message 
news:jjj907$2t00$1 digitalmars.com...
 Le 11/03/2012 23:12, Walter Bright a écrit :
 And I did just that for "invariant". Over and over and over. People
 immediately get what "immutable" means, like for no other name. So
 consider "immutable" a labor saving device for me.
We have the same phenomena with dur and return type type qualifier (ie: why does const int* fun() isn't compiling ? Because const is qualifying the function, not the return type). Both are recurring questions and so should be as important as immutable. But both are major breaking change.
I wouldn't call dur->duration a *major* breaking change. First of all, you get a clear compile-time error, not silently changed semantics. Secondly, it's a simple search/replace: s/dur!/duration!/ (Not that I normally do search/replaces *completely* blind and unattended, but it's still trivial.)
Mar 11 2012
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 11/03/2012 21:16, Walter Bright a écrit :
 On 3/11/2012 8:34 AM, deadalnix wrote:
 I do think better name isn't the problem. The problem is about
 consistency, and
 will persist as long as we don't agree on a guideline on that in phobos.

 Changing a name just for changing it doesn't worth the cost, unless
 the original
 name is horribly misleading - rare case. But getting the naming
 convention
 consistent is of much greater importance, and justify breaking code.
Frankly, I think naming conventions are overrated. The problem is that, as the sec vs seconds debate shows, there is not a correct answer. It becomes a bikeshed issue. There are a lot of considerations for a name, usually conflicting with each other. To set rules in concrete and follow them no matter what is a formula for silly results.
I think this example is very good. The seconds/secs show us the importance of getting consistent. Here the problem come from the fact that some stuff has been abbreviated (msecs, usecs, . . .) and some other hasn't (minutes, hours). Now we ends up with the tricky case of seconds, because it is in between theses 2 worlds and 2 naming conventions. And as we have seen, it confuses people, and have no good solution now (either duplication of the value, which is never good, either arbitrary choice of one naming convention). This typically show us what problems bad naming convention occurs, and how difficult it is solve afterward, because it breaks compatibility.
 I'm not suggesting no naming convention. Naming conventions are good.
 But they don't trump everything else in importance, not even close.
I have to disagree. They are really important on a large codebase (let say > 100,000 lines of code). Otherwise people tend not to find modules they can reuse expect by nowing the whole codebase. This have indirect effect to cause needless duplication - with all known drawbacks - and make the project more dependent on documentation - more documentation have to be produced, which means an overhead in workload and more trouble when documentation lacks, is outdated, or is bugguy.
 And sometimes, a name change can be a huge win - the
 invariant=>immutable one is an example. But I think that's an
 exceptional case, not a rule.
IMO, the name in itself isn't that important. The important thing is that thing get named in a predictable and simple way.
Mar 11 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Mar 11, 2012 at 11:31:33PM +0100, deadalnix wrote:
 Le 11/03/2012 21:16, Walter Bright a écrit :
[...]
I'm not suggesting no naming convention. Naming conventions are good.
But they don't trump everything else in importance, not even close.
I have to disagree. They are really important on a large codebase (let say > 100,000 lines of code). Otherwise people tend not to find modules they can reuse expect by nowing the whole codebase. This have indirect effect to cause needless duplication - with all known drawbacks - and make the project more dependent on documentation - more documentation have to be produced, which means an overhead in workload and more trouble when documentation lacks, is outdated, or is bugguy.
I used to be very much against verbose naming conventions. Almost all naming conventions are verbose, and I hate verbosity with a passion (I still do). But after having been forced to use naming conventions in some code at work, I'm starting to see some value to them, especially in very large projects where there's so much code that without some sort of convention, it quickly becomes impossible to find what you want. Due to lack of convention, one team tries writing code with what they feel is a consistent naming, then another team comes along and do the same, and they run into naming conflicts, so they rename stuff haphazardly. Repeat this over a few iterations of the product, and you end up with 50 modules all with inconsistent naming due to historical conflicts. Code readability thus drops dramatically, and people coming on board later on can't understand what the code was supposed to do because it's all so obtuse (and they don't have the time/energy to wade through 5 million lines of code to understand every little nuance). This, plus the time pressure of impending deadlines, cause them to resort to copy-n-pasting, second-guessing what a piece of code does without bothering to check their assumptions (since it's so obtuse that looking up *one* thing would cost them hours just to even begin to understand it), and all sorts of bad code enters the system. Compare this with a project that has naming conventions from the get go. Name clashes are essentially non-existent if the naming convention is consistent, and if you're looking for a function in module X to do Y, the naming convention almost already spells out the name for you. Makes things very easy to find, and once you understand the convention, makes code very easy to read (most guesses at what the code means are actually correct -- in a large project, you *know* people are just going to write what they think is right rather than spend time reading code to understand what it actually does). So people are more likely to actually write correct code, which means people who come on board after them are more likely to understand the code and not do stupid things. [...]
 IMO, the name in itself isn't that important. The important thing is
 that thing get named in a predictable and simple way.
+1. T -- First Rule of History: History doesn't repeat itself -- historians merely repeat each other.
Mar 11 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 02:31:53PM -0500, Nick Sabalausky wrote:
[...]
 writefln is still there with the same old functionality (which is
 good, it *is* a good function). It's just that writeln has been added
 and just happens to be better in every way for the majority of
 use-cases.
[...] Strange, I still find myself using writef/writefln very frequently. When you want formatting in your output, printf specs are just sooo convenient. But perhaps it's just a symptom of my having just emerged from the C/C++ world. :-) T -- First Rule of History: History doesn't repeat itself -- historians merely repeat each other.
Mar 10 2012
parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.429.1331409266.4860.digitalmars-d puremagic.com...
 On Sat, Mar 10, 2012 at 02:31:53PM -0500, Nick Sabalausky wrote:
 [...]
 writefln is still there with the same old functionality (which is
 good, it *is* a good function). It's just that writeln has been added
 and just happens to be better in every way for the majority of
 use-cases.
[...] Strange, I still find myself using writef/writefln very frequently. When you want formatting in your output, printf specs are just sooo convenient. But perhaps it's just a symptom of my having just emerged from the C/C++ world. :-)
They are nice, but I've found that in most of my cases, the non-formatted version is all I usually need. It's great though that the formatted ones are there for the cases where I do need them.
Mar 10 2012
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, March 10, 2012 11:56:03 H. S. Teoh wrote:
 On Sat, Mar 10, 2012 at 02:31:53PM -0500, Nick Sabalausky wrote:
 [...]
 
 writefln is still there with the same old functionality (which is
 good, it *is* a good function). It's just that writeln has been added
 and just happens to be better in every way for the majority of
 use-cases.
[...] Strange, I still find myself using writef/writefln very frequently. When you want formatting in your output, printf specs are just sooo convenient. But perhaps it's just a symptom of my having just emerged from the C/C++ world. :-)
It's a question of what you're printing out. Is it more typical to write a string out without needing to construct it from some set of arguments, or is it more common to have to print a string that you've constructed from a set of arguments? It all depends on your code. There's no question that writef and writefln are useful. It's just a matter of what _your_ use cases are which determines whether you use writeln or writefln more. - Jonathan M Davis
Mar 10 2012
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

 I'm talking about the name change. It's far and away the most common thing I 
 have to edit when moving code from D1 <=> D2.
We need good/better ways to manage Change and make it faster and less painful, instead of refusing almost all change right now. Things like more fine-graded deprecation abilities, smarter error messages in libraries that suggest how to fix the code, tools that update the code (py2to3 or the Go language tool to update the programs), things like the strange "future" built-in Python package, and so on. Bye, bearophile
Mar 10 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:jjgi8v$p1s$1 digitalmars.com...
 Walter:

 I'm talking about the name change. It's far and away the most common 
 thing I
 have to edit when moving code from D1 <=> D2.
We need good/better ways to manage Change and make it faster and less painful, instead of refusing almost all change right now. Things like more fine-graded deprecation abilities, smarter error messages in libraries that suggest how to fix the code, tools that update the code (py2to3 or the Go language tool to update the programs), things like the strange "future" built-in Python package, and so on.
+1
Mar 10 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jjgkb8$s1f$1 digitalmars.com...
 "bearophile" <bearophileHUGS lycos.com> wrote in message 
 news:jjgi8v$p1s$1 digitalmars.com...
 Walter:

 I'm talking about the name change. It's far and away the most common 
 thing I
 have to edit when moving code from D1 <=> D2.
We need good/better ways to manage Change and make it faster and less painful, instead of refusing almost all change right now. Things like more fine-graded deprecation abilities, smarter error messages in libraries that suggest how to fix the code, tools that update the code (py2to3 or the Go language tool to update the programs), things like the strange "future" built-in Python package, and so on.
+1
To elaborate on that, stagnation with thinks that should have been *just fixed* is one of the reasons I got fed up with C++ and went looking for an alternative (and found D). I hate to see D starting to jump into the same boat so soon.
Mar 10 2012
parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jjgkf6$s6h$1 digitalmars.com...
 "Nick Sabalausky" <a a.a> wrote in message 
 news:jjgkb8$s1f$1 digitalmars.com...
 "bearophile" <bearophileHUGS lycos.com> wrote in message 
 news:jjgi8v$p1s$1 digitalmars.com...
 Walter:

 I'm talking about the name change. It's far and away the most common 
 thing I
 have to edit when moving code from D1 <=> D2.
We need good/better ways to manage Change and make it faster and less painful, instead of refusing almost all change right now. Things like more fine-graded deprecation abilities, smarter error messages in libraries that suggest how to fix the code, tools that update the code (py2to3 or the Go language tool to update the programs), things like the strange "future" built-in Python package, and so on.
+1
To elaborate on that, stagnation with thinks that should have been *just fixed* is one of the reasons I got fed up with C++ and went looking for an alternative (and found D). I hate to see D starting to jump into the same boat so soon.
And seriously, name changes are one hell of a *trivial* breaking change. Some people here makes it sound like name changes are akin to...I dunno...banning templates or something. I happily switched from C++ to D. *That's* a "breaking change".
Mar 10 2012
prev sibling parent Sean Cavanaugh <WorksOnMyMachine gmail.com> writes:
On 3/10/2012 3:49 PM, bearophile wrote:
 Walter:

 I'm talking about the name change. It's far and away the most common thing I
 have to edit when moving code from D1<=>  D2.
We need good/better ways to manage Change and make it faster and less painful, instead of refusing almost all change right now. Things like more fine-graded deprecation abilities, smarter error messages in libraries that suggest how to fix the code, tools that update the code (py2to3 or the Go language tool to update the programs), things like the strange "future" built-in Python package, and so on. Bye, bearophile
I would think if a language designed in a migration path that worked it would allow things to be more fluid (on the library and language side). This is one thing I believe has really hurt C++, since the 'good words' like null couldn't be used they had to settle for dumber names like nullptr_t. From what I gather D's way 'out' is abuse of I would much rather the language be able to expand its turf at the expense of the existing codebases, as long as there was a way to _migrate the code cleanly_. I envision something like this would work: In addition to the 'module mypackage.mymodule' statement at the top of each file, should be a version number of D of some sort that the code was last built against. A very high level language revision like D1 or D2. Newer compilers would maintain the previous front-ends ability to parse these older files, purely for the sake of outputing TODO-like messages for how to upgrade the codebase to a newer version. A simple example right now from D1 to D2 would be the way floating point literals are parsed is no longer compatible. The UFCS changes could silently break existing code in theory and probably should be pointed out in some way before upgrading code from D1 to D2.
Mar 10 2012
prev sibling parent Boris Wang <kona.ming gmail.com> writes:
the ABI of linux is good enough,  it's based on a mature os : UNIX.

forget the name of D, name is not important.

There is no need for a replacement for c in OS area, because c is the best
high level language match current CPU architecture
Why c++ is so complexity? because the cpu architecture is not object
oriented.

energy save, high performance, develop effective, in the area focus on
these, is the market for D : "Half" system program language.
and the big point for growth, can call c/c++ binary from D source.

sorry about digressing from the subject.


2012/3/10 Walter Bright <newshound2 digitalmars.com>

 On 3/9/2012 3:09 PM, Nick Sabalausky wrote:

 Keep in mind, too, that Linux has decades of legacy and millions of users.
 That's a *very* different situation from Phobos. Apples and oranges.
Linux has had a habit of not breaking existing code from decades ago. I think that is one reason why it has millions of users. Remember, every time you break existing code you reset your user base back to zero. I'm *still* regularly annoyed by the writefln => writeln change in D1 to D2, and I agreed to that change. Grrrr.
Apr 01 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-03-10 00:04, Nick Sabalausky wrote:
 Freezing things against breaking changes is all fine and good, but NOT
 before they're reached a point where they're good enough to be frozen.
 Premature freezing is how you create cruft and other such shit. Let's not go
 jumping any guns here.
I completely aggree. -- /Jacob Carlborg
Mar 10 2012
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

 While I don't think we need to worry so much at the moment about breaking
binary 
 compatibility with new D releases, we do have a big problem with breaking
source 
 code compatibility.
 
 This is why we need to have a VERY high bar for breaking changes.
D will naturally progressively slow down the rhythm of its new breaking changes, but even very old languages introduce some breaking changes (see some of the changes in C++11), and D is not yet mature enough to slow them sharply down now. In D there are some unfinished parts still. Finishing them will probably break something. Bug fixing are now breaking things in every release, and I don't want to see an arbitrary stop to those improvements now. If you stop breaking changes, we'll not be able to fix a nasty situation like ("Some untidy attributes"): http://d.puremagic.com/issues/show_bug.cgi?id=3934 In bug 3934 there is a lot of stuff that I'd love to break in the code of the silly programmers that have used it. Another small breaking change, that I have argued about for years: http://d.puremagic.com/issues/show_bug.cgi?id=7444 Or this one "Default arguments of out and ref arguments": http://d.puremagic.com/issues/show_bug.cgi?id=5850 If today people write code with default arguments at ref/out arguments, forbidding those default arguments will break their code. "A bug-prone situation with AAs": http://d.puremagic.com/issues/show_bug.cgi?id=3825 Currently string literals concatenation is accepted like this: auto s = "foo" "bar"; But you have accepted to disallow this statically (and require a ~), after a request of mine. If today people write such code, this will be a breaking change for their code. Do you want me to list some more bugs now that are small breaking changes? I am willing to discuss each one of them. Stopping all those improvements right now at once is exceptionally unwise. Bye, bearophile
Mar 09 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/9/2012 3:14 PM, bearophile wrote:
 D will naturally progressively slow down the rhythm of its new breaking
 changes, but even very old languages introduce some breaking changes (see
 some of the changes in C++11),
What breaking changes are there in C++11, other than dumping export?
Mar 09 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/9/12 8:35 PM, Walter Bright wrote:
 On 3/9/2012 3:14 PM, bearophile wrote:
 D will naturally progressively slow down the rhythm of its new breaking
 changes, but even very old languages introduce some breaking changes (see
 some of the changes in C++11),
What breaking changes are there in C++11, other than dumping export?
Deprecating exception specifications :o). Andrei
Mar 09 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/9/2012 9:14 PM, Andrei Alexandrescu wrote:
 On 3/9/12 8:35 PM, Walter Bright wrote:
 On 3/9/2012 3:14 PM, bearophile wrote:
 D will naturally progressively slow down the rhythm of its new breaking
 changes, but even very old languages introduce some breaking changes (see
 some of the changes in C++11),
What breaking changes are there in C++11, other than dumping export?
Deprecating exception specifications :o).
I don't think that broke any existing code, because there wasn't any :-) Consider that I and some others agitated for dumping trigraphs. A couple of people voiciferously claimed that their entire code base depended on it, so it stayed in. Never mind that that codebase could be easily accommodated by writing a literally trivial filter. But now, to support raw string literals, C++11 has mucked up trigraphs. It's no longer possible to deprecate them without writing a filter that is pretty much a full blown C++ compiler itself.
Mar 09 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, March 09, 2012 21:54:28 Walter Bright wrote:
 Deprecating exception specifications :o).
I don't think that broke any existing code, because there wasn't any :-)
Sadly, there's code that will break because of that where _I_ work. For a while, they were recommended/required, because some of the people dictating coding standards didn't understand them properly. Fortunately, much of the newer code doesn't use them, but there's still plenty that does. I think that it stems primarily from Java programmers expecting them to work as checked exceptions and not realizing how they really work. The only thing that will likely stop code from breaking where I work due to the deprecation of exception specifications is the fact that it'll be years before we use C++11, and it'll probably only be newer projects that get compiled that way when it _does_ finally happen. - Jonathan M Davis
Mar 09 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:jjeqak$f3i$1 digitalmars.com...
 On 3/9/2012 9:14 PM, Andrei Alexandrescu wrote:
 On 3/9/12 8:35 PM, Walter Bright wrote:
 On 3/9/2012 3:14 PM, bearophile wrote:
 D will naturally progressively slow down the rhythm of its new breaking
 changes, but even very old languages introduce some breaking changes 
 (see
 some of the changes in C++11),
What breaking changes are there in C++11, other than dumping export?
Deprecating exception specifications :o).
I don't think that broke any existing code, because there wasn't any :-) Consider that I and some others agitated for dumping trigraphs. A couple of people voiciferously claimed that their entire code base depended on it, so it stayed in. Never mind that that codebase could be easily accommodated by writing a literally trivial filter. But now, to support raw string literals, C++11 has mucked up trigraphs. It's no longer possible to deprecate them without writing a filter that is pretty much a full blown C++ compiler itself.
So making improvements that involve trivially-handled breaking changes is good for C++ but bad for D?
Mar 09 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/9/2012 10:48 PM, Nick Sabalausky wrote:
 So making improvements that involve trivially-handled breaking changes is
 good for C++ but bad for D?
It's always a judgment call.
Mar 10 2012
prev sibling next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 10-03-2012 05:35, Walter Bright wrote:
 On 3/9/2012 3:14 PM, bearophile wrote:
 D will naturally progressively slow down the rhythm of its new breaking
 changes, but even very old languages introduce some breaking changes (see
 some of the changes in C++11),
What breaking changes are there in C++11, other than dumping export?
auto as a storage specifier. auto_ptr. Exception specifications. std::unary/binary_function. -- - Alex
Mar 10 2012
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter:

 What breaking changes are there in C++11, other than dumping export?
The end of the talk (just before the questions) about Clang of GoingNative2012 has shown one breaking change of C++: #include <iostream> struct S { int n; }; struct X { X(int) {} }; void f(void*) { std::cerr << "Pointer!\n"; } void f(X) { std::cerr << "X!\n"; } int main() { f(S().n); } % clang++ -std=c++11 -g -o cxx11-4 cxx11-4.cpp % ./cxx11-4 Pointer! % clang++ -std=c++98 -g -o cxx11-4 cxx11-4.cpp % ./cxx11-4 X! But in the end I don't care for C++11 here, my post here was about D and several bug reports that are able to break user code once fixed or improved. If you raise the bar too much for breaking changes now, most of those things will never be fixed or done. And this is _not_ acceptable for me. Bye, bearophile
Mar 10 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/10/2012 05:35 AM, Walter Bright wrote:
 On 3/9/2012 3:14 PM, bearophile wrote:
 D will naturally progressively slow down the rhythm of its new breaking
 changes, but even very old languages introduce some breaking changes (see
 some of the changes in C++11),
What breaking changes are there in C++11, other than dumping export?
I am only aware of those, but I don't use C++ a lot. So there might be more: - introduction of constexpr messed with the overload resolution rules. - '>>' can no longer be used inside a template argument expression.
Mar 10 2012
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:
 This is why we need to have a VERY high bar for breaking 
 changes.
Please remember this if someone proposes enforcing property by default. The -property switch is a big mistake that breaks a lot of code.
Mar 09 2012
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Saturday, March 10, 2012 01:12:34 Adam D. Ruppe wrote:
 On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:
 This is why we need to have a VERY high bar for breaking
 changes.
Please remember this if someone proposes enforcing property by default. The -property switch is a big mistake that breaks a lot of code.
As I understand it, it's like override, it's being phased in, and it _will_ become the normal behavior. There are also a number of things in the language that are supposed to be deprecated but have been sitting around for ages without actually being deprecated (e.g. delete). Walter's sentiments may be good, but there are a number of things which are still in a transitional phase and _will_ end up breaking code. Of course, I'd argue that stuff like deprecating/removing delete and fully enabling override and property _do_ pass the very high bar. I think that his biggest complaint is minor changes (such as changing function names) rather than the large changes that are still being made. - Jonathan M Davis
Mar 09 2012
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 10 March 2012 at 00:25:23 UTC, Jonathan M Davis 
wrote:
 As I understand it, it's like override, it's being phased in, 
 and it _will_ become the normal behavior.
A planned or inevitable big mistake that will break piles of code in a painful way is still a big mistake that will break piles of code in a painful way.
 and  property _do_ pass the very high bar.
If the height of the bar is based on how much code it breaks, sure. If it based on the benefit it actually brings us, no, absolutely not. property is the biggest name bikeshed of them all.
Mar 09 2012
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 09 Mar 2012 19:12:34 -0500, Adam D. Ruppe  
<destructionator gmail.com> wrote:

 On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:
 This is why we need to have a VERY high bar for breaking changes.
Please remember this if someone proposes enforcing property by default.
Clears the bar with room to spare IMO. Not to mention it's not just a proposal, but in print in TDPL . (dons flame war proof suit) -STeve
Mar 09 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Mar 09, 2012 at 07:26:48PM -0500, Steven Schveighoffer wrote:
 On Fri, 09 Mar 2012 19:12:34 -0500, Adam D. Ruppe
 <destructionator gmail.com> wrote:
 
On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:
This is why we need to have a VERY high bar for breaking changes.
Please remember this if someone proposes enforcing property by default.
I propose enabling property by default.
 Clears the bar with room to spare IMO.
 
 Not to mention it's not just a proposal, but in print in TDPL .
 
 (dons flame war proof suit)
[...] I don't see what's there to flamewar about. AFAIK property enforcement is going to happen sooner or later. T -- There is no gravity. The earth sucks.
Mar 09 2012
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 09 Mar 2012 19:40:37 -0500, H. S. Teoh <hsteoh quickfur.ath.cx>  
wrote:

 On Fri, Mar 09, 2012 at 07:26:48PM -0500, Steven Schveighoffer wrote:
 (dons flame war proof suit)
[...] I don't see what's there to flamewar about.
You're new... :) -Steve
Mar 09 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Mar 09, 2012 at 07:51:12PM -0500, Steven Schveighoffer wrote:
 On Fri, 09 Mar 2012 19:40:37 -0500, H. S. Teoh
 <hsteoh quickfur.ath.cx> wrote:
 
On Fri, Mar 09, 2012 at 07:26:48PM -0500, Steven Schveighoffer wrote:
(dons flame war proof suit)
[...] I don't see what's there to flamewar about.
You're new... :)
[...] Not nearly new enough to not be partially responsible for that huge gigantic thread about exceptions. :-) (Which I had no trouble following, btw, even though it's clear that a lot of people were totally lost after the first 100 posts or so. Mutt is just *that* cool. OTOH, when the thread nesting depth exceeded even mutt's ability to display the thread lines (because it was overflowing my terminal width), the thread started to fizzle out. I'm guessing that's when the rest of us mutt users bailed out. :-P) T -- "Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next. -- (Stolen from the net)
Mar 09 2012
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 09 Mar 2012 20:04:49 -0500, H. S. Teoh <hsteoh quickfur.ath.cx>  
wrote:

 On Fri, Mar 09, 2012 at 07:51:12PM -0500, Steven Schveighoffer wrote:
 On Fri, 09 Mar 2012 19:40:37 -0500, H. S. Teoh
 <hsteoh quickfur.ath.cx> wrote:

On Fri, Mar 09, 2012 at 07:26:48PM -0500, Steven Schveighoffer wrote:
(dons flame war proof suit)
[...] I don't see what's there to flamewar about.
You're new... :)
[...] Not nearly new enough to not be partially responsible for that huge gigantic thread about exceptions. :-) (Which I had no trouble following, btw, even though it's clear that a lot of people were totally lost after the first 100 posts or so. Mutt is just *that* cool. OTOH, when the thread nesting depth exceeded even mutt's ability to display the thread lines (because it was overflowing my terminal width), the thread started to fizzle out. I'm guessing that's when the rest of us mutt users bailed out. :-P)
No, what I meant is that property is a sore subject that invariable starts a time-consuming never-winning flame war any time someone mentions how it should or shouldn't be mandatory. -Steve
Mar 09 2012
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, March 09, 2012 16:40:37 H. S. Teoh wrote:
 On Fri, Mar 09, 2012 at 07:26:48PM -0500, Steven Schveighoffer wrote:
 On Fri, 09 Mar 2012 19:12:34 -0500, Adam D. Ruppe
 
 <destructionator gmail.com> wrote:
On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:
This is why we need to have a VERY high bar for breaking changes.
Please remember this if someone proposes enforcing property by default.
I propose enabling property by default.
 Clears the bar with room to spare IMO.
 
 Not to mention it's not just a proposal, but in print in TDPL .
 
 (dons flame war proof suit)
[...] I don't see what's there to flamewar about. AFAIK property enforcement is going to happen sooner or later.
Yes. The problem is that some people don't like property and don't want it enforced, whereas others think it's a big improvement. From the sounds of it, Adam thinks that it's bad, whereas Steven thinks that it's good. Personally, I'm _definitely_ in favor of property enforcement. Regardless, it's in TDPL, and the current plan is to enforce it. It just hasn't reached that point yet, since we're still in the transition stage from not having property at all to having property and having it enforced. - Jonathan M Davis
Mar 09 2012
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 10 March 2012 at 00:48:56 UTC, Jonathan M Davis 
wrote:
 From the  sounds of it, Adam thinks that it's bad
Indeed. I have an advantage here though: it is an objective fact that -property breaks a lot of existing D code. We can (and have) argue(d) all day about what, if any, improvements strict enforcement actually brings.
Mar 09 2012
parent reply Mantis <mail.mantis.88 gmail.com> writes:
10.03.2012 3:01, Adam D. Ruppe пишет:
 On Saturday, 10 March 2012 at 00:48:56 UTC, Jonathan M Davis wrote:
 From the  sounds of it, Adam thinks that it's bad
Indeed. I have an advantage here though: it is an objective fact that -property breaks a lot of existing D code. We can (and have) argue(d) all day about what, if any, improvements strict enforcement actually brings.
Arguments are same as before, I believe: // alias int delegate() dg_t; property dg_t foo() { return { return 42; }; } int main() { auto a = foo(); return 0; } // What should be the type of a?
Mar 09 2012
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 10 March 2012 at 03:33:42 UTC, Mantis wrote:
 What should be the type of a?
int. I'm for using property to disambiguate in any case. That's a clear benefit. I'm against the strict enforcement where it forces you to choose parens or no parens at the declaration site (what -property does). That's just pointless bikeshedding that breaks perfectly good code.
Mar 09 2012
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/9/2012 4:12 PM, Adam D. Ruppe wrote:
 The -property switch is a big mistake that breaks a
 lot of code.
It was done as a switch to see how much it would break and if that was worth it.
Mar 09 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:
 This is why we need to have a VERY high bar for breaking 
 changes.
Oh, and how do you intend to accomplish that with things like bug 314 still being open (and code relying on the buggy behavior), and not even the language being finalized (think: shared)? David
Mar 09 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, March 09, 2012 16:15:13 H. S. Teoh wrote:
 On Sat, Mar 10, 2012 at 01:02:35AM +0100, Andrej Mitrovic wrote:
 Linus would probably hate D just as much as he hates C++. :p
Yeah... I can just imagine his eye scanning the description of D and stopping right at the word "GC", and immediately writing a flaming vitriolic post to LKML about how a GC is the absolutely worst thing one could possibly conceive of putting inside a kernel, and that any kernel developer caught flirting with the idea of using D ought to have all kernel patches ignored from that point on.
He hates function overloading! I question that he'd ever be happy with anything other than C. And he's so specialized in what he works on that I think that a number of his opinions are completely inapplicable to the majority of programmers. Some of what he says is very valuable, but he's a very opinionated person whose opinions often don't line up with the rest of the programming world. If you'll notice, Walter sometimes has similar issues simply due to the kind of stuff he works on (e.g. thinking that the fact that you could run your program in a debugger to see a segfault was enough (rather than getting some sort of stacktrace with a segfault), which works great for compilers, but works horribly for programs that run for weeks at a time). We all have our biases based on what we've worked on. Linus just so happens to be very famous and _very_ specialized in the type of stuff that he works on. - Jonathan M Davis
Mar 09 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Fri, 09 Mar 2012 23:32:58 +0100, Walter Bright  
<newshound2 digitalmars.com> wrote:

 This statement is from Linus Torvalds about breaking binary  
 compatibility:

 https://lkml.org/lkml/2012/3/8/495

 While I don't think we need to worry so much at the moment about  
 breaking binary compatibility with new D releases, we do have a big  
 problem with breaking source code compatibility.

 This is why we need to have a VERY high bar for breaking changes.
Definitely. I think we should gather bugs that require breaking changes and prioritize them. IMHO it's also the main reason to continue fixing imports and protection. By now people mostly still appreciate those fixes but the pain they cause will only ever grow. ABI http://d.puremagic.com/issues/show_bug.cgi?id=7469
Mar 09 2012
prev sibling next sibling parent "ludi" <my email.com> writes:
On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:
 This statement is from Linus Torvalds about breaking binary 
 compatibility:

 https://lkml.org/lkml/2012/3/8/495

 While I don't think we need to worry so much at the moment 
 about breaking binary compatibility with new D releases, we do 
 have a big problem with breaking source code compatibility.

 This is why we need to have a VERY high bar for breaking 
 changes.
I don't think it is that straightforward to conclude anything about source compatibility in a programming language from this argument about binary compatibility in a kernel.
Mar 09 2012
prev sibling next sibling parent reply Gour <gour atmarama.net> writes:
On Fri, 09 Mar 2012 14:32:58 -0800
Walter Bright <newshound2 digitalmars.com> wrote:

Dear Walter,

 This is why we need to have a VERY high bar for breaking changes.
I agree with your statement above, but, personally, not having legacy D code to take care about I'm leaving it to more expertt users here to discuss, but I'm more concerned with another thing and that is roadmap. It would be nice if D would have some kind of roadmap with several milestones so that users can have some rough (it's not required that milestones are carved in stone) idea when to expect that some things will be fixed and/or new features added/implemented. Sincerely, Gour` --=20 As the embodied soul continuously passes, in this body,=20 from boyhood to youth to old age, the soul similarly passes=20 into another body at death. A sober person is not bewildered=20 by such a change. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Mar 10 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/10/2012 12:06 AM, Gour wrote:
 It would be nice if D would have some kind of roadmap with several
 milestones so that users can have some rough (it's not required that
 milestones are carved in stone) idea when to expect that some things
 will be fixed and/or new features added/implemented.
Right now the priority is eliminating high priority bugs from bugzilla, not implementing new features.
Mar 10 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 10:53:22AM -0800, Walter Bright wrote:
 On 3/10/2012 12:06 AM, Gour wrote:
It would be nice if D would have some kind of roadmap with several
milestones so that users can have some rough (it's not required that
milestones are carved in stone) idea when to expect that some things
will be fixed and/or new features added/implemented.
Right now the priority is eliminating high priority bugs from bugzilla, not implementing new features.
Speaking of which, how's our progress on that front? What are the major roadblocks still facing us? T -- He who does not appreciate the beauty of language is not worthy to bemoan its flaws.
Mar 10 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/10/2012 11:02 AM, H. S. Teoh wrote:
 Speaking of which, how's our progress on that front? What are the major
 roadblocks still facing us?
http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
Mar 10 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 11:39:54AM -0800, Walter Bright wrote:
 On 3/10/2012 11:02 AM, H. S. Teoh wrote:
Speaking of which, how's our progress on that front? What are the
major roadblocks still facing us?
http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
Looks quite promising to me. Can we expect dmd 2.060 Real Soon Now(tm)? :-) T -- "Uhh, I'm still not here." -- KD, while "away" on ICQ.
Mar 10 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.431.1331409456.4860.digitalmars-d puremagic.com...
 On Sat, Mar 10, 2012 at 11:39:54AM -0800, Walter Bright wrote:
 On 3/10/2012 11:02 AM, H. S. Teoh wrote:
Speaking of which, how's our progress on that front? What are the
major roadblocks still facing us?
http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
Looks quite promising to me. Can we expect dmd 2.060 Real Soon Now(tm)? :-)
No. Unfortnately, 2.059 will have to come first. ;)
Mar 10 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 10, 2012 at 02:59:28PM -0500, Nick Sabalausky wrote:
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.431.1331409456.4860.digitalmars-d puremagic.com...
 On Sat, Mar 10, 2012 at 11:39:54AM -0800, Walter Bright wrote:
 On 3/10/2012 11:02 AM, H. S. Teoh wrote:
Speaking of which, how's our progress on that front? What are the
major roadblocks still facing us?
http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
Looks quite promising to me. Can we expect dmd 2.060 Real Soon Now(tm)? :-)
No. Unfortnately, 2.059 will have to come first. ;)
[...] Argh! I didn't realize dmd bumped its version in git immediately after a release, rather than before. At my day job, we do it the other way round (make a bunch of changes, test it, then bump the version once we decide it's ready to ship). T -- Always remember that you are unique. Just like everybody else. -- despair.com
Mar 10 2012
parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.435.1331411268.4860.digitalmars-d puremagic.com...
 On Sat, Mar 10, 2012 at 02:59:28PM -0500, Nick Sabalausky wrote:
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message
 news:mailman.431.1331409456.4860.digitalmars-d puremagic.com...
 On Sat, Mar 10, 2012 at 11:39:54AM -0800, Walter Bright wrote:
 On 3/10/2012 11:02 AM, H. S. Teoh wrote:
Speaking of which, how's our progress on that front? What are the
major roadblocks still facing us?
http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
Looks quite promising to me. Can we expect dmd 2.060 Real Soon Now(tm)? :-)
No. Unfortnately, 2.059 will have to come first. ;)
[...] Argh! I didn't realize dmd bumped its version in git immediately after a release, rather than before. At my day job, we do it the other way round (make a bunch of changes, test it, then bump the version once we decide it's ready to ship).
I honestly don't like it either way. For my stuff, I bump it just before *and* just after a release. If you see something of mine with a version like "vX.Y", then it's a release version. If it's "vX.Y.1" than it's a development snapshot that could be anywhere between the next and previous "vX.Y". For instance, v0.5.1 would be a dev snapshot that could be anywhere between the v0.5 and v0.6 releases. Once I reach v1.0, then whenever I need to do a "vX.Y.Z" release, the 'Z' part will always been an even number for releases and odd for dev snapshots (unless I decide to just add an extra fourth number instead). (Prior to a v1.0, I don't think there's much point in bothering with a full "vX.Y.Z": just bump the Y since, by definition, you can always expect breaking changes prior to v1.0) I think it's terrible for dev and release versions to share the same version number.
Mar 10 2012
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 09/03/2012 23:32, Walter Bright a écrit :
 This statement is from Linus Torvalds about breaking binary compatibility:

 https://lkml.org/lkml/2012/3/8/495

 While I don't think we need to worry so much at the moment about
 breaking binary compatibility with new D releases, we do have a big
 problem with breaking source code compatibility.

 This is why we need to have a VERY high bar for breaking changes.
I think Linus is mostly right. But I don't think this is a reason not put the bar very high. Especially with the current state of D. This is more about providing a nice, and long, transition process. The way property evolve is a good example of what we should do. An example of management the change (even breaking change) is PHP. PHP has so much improved if you consider what have changed between v4 and v5, and then v5 and v5.3, that it is a factual proof that breaking change can be done to great benefit.
Mar 11 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"deadalnix" <deadalnix gmail.com> wrote in message 
news:jjif2l$1cdi$1 digitalmars.com...
 Le 09/03/2012 23:32, Walter Bright a écrit :
 This statement is from Linus Torvalds about breaking binary 
 compatibility:

 https://lkml.org/lkml/2012/3/8/495

 While I don't think we need to worry so much at the moment about
 breaking binary compatibility with new D releases, we do have a big
 problem with breaking source code compatibility.

 This is why we need to have a VERY high bar for breaking changes.
I think Linus is mostly right. But I don't think this is a reason not put the bar very high. Especially with the current state of D. This is more about providing a nice, and long, transition process. The way property evolve is a good example of what we should do. An example of management the change (even breaking change) is PHP. PHP has so much improved if you consider what have changed between v4 and v5, and then v5 and v5.3, that it is a factual proof that breaking change can be done to great benefit.
PHP could have handled the changes MUCH better than it did, though.
Mar 11 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jjiv40$2aba$1 digitalmars.com...
 "deadalnix" <deadalnix gmail.com> wrote in message 
 news:jjif2l$1cdi$1 digitalmars.com...
 An example of management the change (even breaking change) is PHP. PHP 
 has so much improved if you consider what have changed between v4 and v5, 
 and then v5 and v5.3, that it is a factual proof that breaking change can 
 be done to great benefit.
PHP could have handled the changes MUCH better than it did, though.
Ermm, the transition, I mean.
Mar 11 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 11/03/2012 20:39, Nick Sabalausky a écrit :
 "Nick Sabalausky"<a a.a>  wrote in message
 news:jjiv40$2aba$1 digitalmars.com...
 "deadalnix"<deadalnix gmail.com>  wrote in message
 news:jjif2l$1cdi$1 digitalmars.com...
 An example of management the change (even breaking change) is PHP. PHP
 has so much improved if you consider what have changed between v4 and v5,
 and then v5 and v5.3, that it is a factual proof that breaking change can
 be done to great benefit.
PHP could have handled the changes MUCH better than it did, though.
Ermm, the transition, I mean.
The point wasn't to say that what PHP did is perfect. But that they lead change and are successful at it. This clearly show that this is possible, they DID it.
Mar 11 2012
parent "Nick Sabalausky" <a a.a> writes:
"deadalnix" <deadalnix gmail.com> wrote in message 
news:jjj9bm$2t00$4 digitalmars.com...
 Le 11/03/2012 20:39, Nick Sabalausky a écrit :
 "Nick Sabalausky"<a a.a>  wrote in message
 news:jjiv40$2aba$1 digitalmars.com...
 "deadalnix"<deadalnix gmail.com>  wrote in message
 news:jjif2l$1cdi$1 digitalmars.com...
 An example of management the change (even breaking change) is PHP. PHP
 has so much improved if you consider what have changed between v4 and 
 v5,
 and then v5 and v5.3, that it is a factual proof that breaking change 
 can
 be done to great benefit.
PHP could have handled the changes MUCH better than it did, though.
Ermm, the transition, I mean.
The point wasn't to say that what PHP did is perfect. But that they lead change and are successful at it. This clearly show that this is possible, they DID it.
Right, I agree.
Mar 11 2012