Jump to page: 1 25  
Page
Thread overview
Worse is better?
Oct 08, 2014
Joakim
Oct 08, 2014
John Carter
Oct 09, 2014
Peter Alexander
Oct 10, 2014
deadalnix
Oct 10, 2014
Peter Alexander
Oct 10, 2014
Peter Alexander
Oct 10, 2014
Chris Williams
Oct 13, 2014
Paulo Pinto
Oct 13, 2014
Alex Ogheri
Oct 13, 2014
Paulo Pinto
Oct 13, 2014
eles
Oct 13, 2014
eles
Oct 13, 2014
Paulo Pinto
Oct 13, 2014
Paulo Pinto
Oct 13, 2014
Paulo Pinto
Oct 14, 2014
Dicebot
Oct 14, 2014
Dicebot
Oct 14, 2014
Walter Bright
Oct 14, 2014
ketmar
Oct 14, 2014
Paulo Pinto
Oct 14, 2014
ketmar
Oct 14, 2014
ketmar
Oct 14, 2014
Sag Academy
Oct 14, 2014
ketmar
Oct 14, 2014
eles
Oct 14, 2014
Paulo Pinto
Oct 14, 2014
Paulo Pinto
Oct 14, 2014
ketmar
Oct 10, 2014
Walter Bright
Oct 10, 2014
Chris Williams
Oct 11, 2014
Nick Sabalausky
Oct 10, 2014
Walter Bright
Oct 13, 2014
ketmar
Oct 13, 2014
ketmar
Oct 10, 2014
Walter Bright
October 08, 2014
This is a somewhat famous phrase from a late '80s essay that's mentioned sometimes, but I hadn't read it till this week.  It's a fascinating one-page read, he predicted that lisp would lose out to C++ when he delivered this speech in 1990, well worth reading:

https://www.dreamsongs.com/RiseOfWorseIsBetter.html

Since "worse" and "better" are subjective terms, I interpret it as "simpler spreads faster and wider than complex."  He thinks simpler is worse and complex is often better, hence the title.  Perhaps it's not as true anymore because that was the wild west of computing back then, whereas billions of people use the software built using these languages these days, so maybe we cannot afford to be so fast and loose.

What does this have to D?  Well, the phenomenon he describes probably has a big effect on D's adoption even today, as he was talking about the spread of programming languages, ones we use to this day.  Certainly worth thinking about, as we move forward with building D.
October 08, 2014
On Wednesday, 8 October 2014 at 19:44:04 UTC, Joakim wrote:
> This is a somewhat famous phrase from a late '80s essay that's mentioned sometimes, but I hadn't read it till this week.

Keep reading, he is still pretty ambivalent about the whole concept still...

http://dreamsongs.com/WorseIsBetter.html
October 09, 2014
On Wednesday, 8 October 2014 at 19:44:04 UTC, Joakim wrote:
> What does this have to D?  Well, the phenomenon he describes probably has a big effect on D's adoption even today, as he was talking about the spread of programming languages, ones we use to this day.  Certainly worth thinking about, as we move forward with building D.

That ship has sailed for D. It is no longer a simple language. It now tries to do The Right Thing.

I found the turning point:

https://github.com/D-Programming-Language/dlang.org/commit/67e5f0d8b59aa0ce26b2be9bd79c93d1127b2db6#diff-b6ac8bc22fdbb33f7266c9422db97c2bL212

:-)
October 09, 2014
> a fascinating one-page read, he predicted that lisp would lose out to C++ when he delivered this speech in 1990, well worth

Lisp has never been in the same class of languages as C++. Lisp gained traction in a time period when there were few alternatives, and it was easy to implement an interpreter for it. It was cool among the academic-geeks that hung at universities, so it gained traction among the young who looked up to them. That prolonged the lifespan of Lisp, but Lisp as a language has never been great from a usability perspective.

Worse is not better, but things tend to get worse when you add features to a core where the new parts does not fit and you insist on backwards compatibility.

The dynamics of evolving around an "installed base"…

You see this in X11, windows and the X86 instruction set too.

D should be able to a lot better, with a small installed base, but you probably need to delay that to D3.

And even then you have a problem when so many D users think that "alias this" is a good idea… It is a hack and a "worse is better" design. In order to avoid such constructs you need to think about the semantics of the language in a more "axiomatic" manner.
October 10, 2014
On Thursday, 9 October 2014 at 08:17:09 UTC, Peter Alexander
wrote:
> On Wednesday, 8 October 2014 at 19:44:04 UTC, Joakim wrote:
>> What does this have to D?  Well, the phenomenon he describes probably has a big effect on D's adoption even today, as he was talking about the spread of programming languages, ones we use to this day.  Certainly worth thinking about, as we move forward with building D.
>
> That ship has sailed for D. It is no longer a simple language. It now tries to do The Right Thing.
>
> I found the turning point:
>
> https://github.com/D-Programming-Language/dlang.org/commit/67e5f0d8b59aa0ce26b2be9bd79c93d1127b2db6#diff-b6ac8bc22fdbb33f7266c9422db97c2bL212
>
> :-)

Is this the politically correct wy to say "we don't care about
simplicity anymore!" ?
October 10, 2014
On Friday, 10 October 2014 at 00:36:45 UTC, deadalnix wrote:
> Is this the politically correct wy to say "we don't care about
> simplicity anymore!" ?

Heh. I don't think so. We've just rebalanced our priorities.

You can't have simple, expressive, and low level control. D1 was simple but lacking in expressiveness and control. D2 had traded some simplicity in to improve the situation. I think it has been worthwhile (modulo the inevitable hiccups and warts).
October 10, 2014
On Friday, 10 October 2014 at 09:00:17 UTC, Peter Alexander wrote:
> You can't have simple, expressive, and low level control.

Why not?
October 10, 2014
On Friday, 10 October 2014 at 21:11:20 UTC, Ola Fosheim Grostad wrote:
> On Friday, 10 October 2014 at 09:00:17 UTC, Peter Alexander wrote:
>> You can't have simple, expressive, and low level control.
>
> Why not?

It's just something I believe from experience.

The gist of my reasoning is that to get low level control you need to specify things. When those things are local and isolated, all is good, but often the things you specify bleed across interfaces and affect either all the implementations (making things more complex) or all the users (making things less expressive).

For example, consider the current memory allocation/management debate. I cannot think of a possible way to handle this that simultaneously:

(a) gives users full control over how every function allocates/manages memory (control).
(b) makes the implementation of those functions easy (simple).
(c) makes it easy to compose functions with different management policies (expressive).

There are trade-offs on every axis. I'm sure we'll be able to find something reasonable, that maybe does a good job on each axis, but I don't think it's possible to get 10/10 on all of them.

Maybe there's a way to do it, but if there is I imagine that language and programming experience is going to be vastly different from what we have now (in any language).
October 10, 2014
On 10/8/2014 12:44 PM, Joakim wrote:
> This is a somewhat famous phrase from a late '80s essay that's mentioned
> sometimes, but I hadn't read it till this week.  It's a fascinating one-page
> read, he predicted that lisp would lose out to C++ when he delivered this speech
> in 1990, well worth reading:
>
> https://www.dreamsongs.com/RiseOfWorseIsBetter.html
>
> Since "worse" and "better" are subjective terms, I interpret it as "simpler
> spreads faster and wider than complex."  He thinks simpler is worse and complex
> is often better, hence the title. Perhaps it's not as true anymore because that
> was the wild west of computing back then, whereas billions of people use the
> software built using these languages these days, so maybe we cannot afford to be
> so fast and loose.


I can't help but think that this is nothing more than different people have different ideas on what "better" is.

It reminds me of the Beta vs VHS debate. Rarely mentioned is a movie could fit on one VHS tape, rather than 2 Beta tapes. (VHS was cheaper, too.) That made VHS "better" for an awful lot of people.

"What Sony did not take into account was what consumers wanted. While Betamax was believed to be the superior format in the minds of the public and press (due to excellent marketing by Sony), consumers wanted an affordable VCR (a VHS often cost hundreds of dollars less than a Betamax);[9] Sony believed that having better quality recordings was the key to success, and that consumers would be willing to pay a higher retail price for this, whereas it soon became clear that consumer desire was focused more intently on recording time, lower retail price, compatibility with other machines for sharing (as VHS was becoming the format in the majority of homes), brand loyalty to companies who licensed VHS (RCA, Magnavox, Zenith, Quasar, Mitsubishi, Panasonic, even JVC itself, et al.), and compatibility for easy transfer of information.[10] In addition, Sony, being the first producer to offer their technology, also thought it would establish Betamax as the leading format. This kind of lock-in and path dependence failed for Sony, but succeeded for JVC. For thirty years JVC dominated the home market with their VHS, Super VHS and VHS-Compact formats, and collected billions in royalty payments."

 -- http://en.wikipedia.org/wiki/Videotape_format_war#End_of_Beta

It's a cautionary tale for us.
October 10, 2014
On Friday, 10 October 2014 at 21:54:32 UTC, Peter Alexander wrote:
> (a) gives users full control over how every function allocates/manages memory (control).
> (b) makes the implementation of those functions easy (simple).
> (c) makes it easy to compose functions with different management policies (expressive).

Probably the method would be to make garbage management an aspect of the language itself, like how Go handles parallel processing at the compiler level. Developers write everything like it's all magically garbage collected, with maybe a few metatags/keywords sprinkled around, and then tells the compiler what the default garbage collection should be, and the garbage collector goes in and rewrites code according to different strategies, including an option for static-analysis based collection like Mercury.

D could potentially be moved that direction, but I would imagine that adding reference versions of structs would be necessary first, so that pointers became less prevalent, and pointers only allowed in blocks marked dangerous where the programmer has to perform any management himself.
« First   ‹ Prev
1 2 3 4 5