On 10/9/2014 5:36 PM, deadalnix wrote:
> Is this the politically correct wy to say "we don't care about
> simplicity anymore!" ?

If simplicity was the overriding goal, we'd settle for the simplest possible language that was Turing complete.

The problem, however, is that what makes a language simple to comprehend also tends to make writing programs with it complicated!

For an analogy, when I was younger I had a set of hand tools to do everything with. I couldn't afford a more complete set. Not having the right tool for each job meant approximating it with some other tool. I'd get the jobs done, but at the cost of much extra time invested, and crummy results.

Such as I could never get a square cut on a piece of wood. Now, I have a sweet miter saw that quickly and accurately cuts wood every time. Of course it is a far more complex tool than a handsaw, but much simpler to actually get work done with.

So it's not that we don't care about simplicity anymore. We care about what is simple for the programmer to get complex work done quickly and accurately. I like to think of D as a fully equipped machine shop, where the programmer doesn't have to make do with inadequate (but simple) tools. As professional programmers, isn't that what we really care about?

On 10/9/2014 1:34 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> 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.

I agree that 'alias this' syntax is a bit hackish, and I've never been happy with that, but the semantics are pretty darned good.

On Friday, 10 October 2014 at 22:25:10 UTC, Walter Bright wrote:
> So it's not that we don't care about simplicity anymore. We care about what is simple for the programmer to get complex work done quickly and accurately. I like to think of D as a fully equipped machine shop, where the programmer doesn't have to make do with inadequate (but simple) tools. As professional programmers, isn't that what we really care about?

Agreed. Overall, I'd say that there's a third way beyond "better" or "worse", which is "non-whollistic better".

I always start any new task not by designing the whole application nor by start to hack together parts as I need them. Instead, I identify "tools" - parts of the application that I know will exist, but could be used in any variety of applications - and build nicely designed, generic libraries for those. With a set of "better" libraries the remaining code that links them together is fairly small, so it's easy to shuffle things around or build out new functionality.

On 10/10/2014 06:25 PM, Walter Bright wrote:
> On 10/9/2014 5:36 PM, deadalnix wrote:
>> Is this the politically correct wy to say "we don't care about
>> simplicity anymore!" ?
>
> If simplicity was the overriding goal, we'd settle for the simplest
> possible language that was Turing complete.
>

In other words, Brainfuck: http://en.wikipedia.org/wiki/Brainfuck

It only has 8 commmands and *nothing* else, SOOO SIMPLE!!!

I've been incredibly productive ever since I switched to BF! It's so amazingly simple and orthogonal that it only takes *just* a day or so to write a "hello world"! Brilliant!

Today "hello world", next millennium "pong", and then some glorious day...*real useful software*! Mwahahahahah!!!!!

/sarcastic_bastard turns back to his complicated language and resumes getting real work done...

On Friday, 10 October 2014 at 22:27:04 UTC, Walter Bright wrote:
> I agree that 'alias this' syntax is a bit hackish, and I've never been happy with that, but the semantics are pretty darned good.

I think that such features often are the result of special casing that could have been handled by more generic solutions. Then they become superfluous later when more generic constructs are added and you end up with many ways of doing the same thing (complexity with no gain).

In this case some kind of inheritance, some variation of static interface, or some kind of deductive system/rewrite system probably would have been more powerful and covered the same use case.

On Mon, 13 Oct 2014 10:41:02 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> In this case some kind of inheritance, some variation of static interface, or some kind of deductive system/rewrite system probably would have been more powerful and covered the same use case.
AST macros! AST macros can do almost anything! ;-)

On Friday, 10 October 2014 at 21:54:32 UTC, Peter Alexander wrote:
> 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.

Ok, beliefs are good, but one should not limit visions by them.

> 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).

I don't think there is anything that prevents a language from:

1. Allow the user to specify the constraints and let the system fill in the details.

2. Let the user guide the search down to the low level details for efficiency.

So, from a theoretical point of view I'd say it should be possible to go from high to low level with a reasonable simple language at the cost of an advanced compiler.

If you can specify how a program should work and let a human being construct a program from it that works from the specification alone, then a "competent" compiler/expert system should be able to do the same thing.

> 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).

I think the compiler should handle memory management and let the user configure the compiler.

It is rather obvious that the compiler sometimes should to instantiate two different versions of the same function based on usage on the call site, so if you don't let the compiler handle this then achieving the optimization potential becomes difficult.

Another point: compiling code to run on allocated activation records is not the same as having it compile for a call-stack. If you want lots of fibers you have to give up the concept of a stack and stick to activation records. It is also a more generic concept (Simula used it to represent both objects and memory function blocks, they had the same internal representation).

> 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).

Probably. So if you are going to support low level programming then it is better to focus on the low level and be a bit more reluctant to add high level features.

From a system level language I don't really need:
- templates
- exceptions
- fibers
- garbage collection

I'd rather have basic building blocks and some kind of well designed deductive capability. Type systems are deductive in nature, so I think deductive compile time evaluation makes sense.

On Monday, 13 October 2014 at 11:07:39 UTC, Ola Fosheim Grøstad wrote:
> ...
> From a system level language I don't really need:
> - templates
> - exceptions
> - fibers
> - garbage collection


Ada, Modula-3 ? :)

On Monday, 13 October 2014 at 10:51:54 UTC, ketmar via Digitalmars-d wrote:
> AST macros! AST macros can do almost anything! ;-)

Including making it impossible to add new features to the language... :)

On Monday, 13 October 2014 at 11:39:26 UTC, Paulo  Pinto wrote:
> On Monday, 13 October 2014 at 11:07:39 UTC, Ola Fosheim Grøstad wrote:
>> ...
>> From a system level language I don't really need:
>> - templates
>> - exceptions
>> - fibers
>> - garbage collection
>
>
> Ada, Modula-3 ? :)

Ada would actually be a nice starting point. :)