Am 13.10.2014 um 23:56 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>":
> On Monday, 13 October 2014 at 19:00:37 UTC, Paulo Pinto wrote:
>> But no better than Algol or PL/... variants.
>>
>> There were other alternatives.
>
> Algol compilers required a lot more RAM than BCPL (~120k vs ~20k)
>
> :)
>

If you wish, I can enumerate other alternatives with compatible memory requirements. :)

It was a matter of luck being tied to UNIX, just like JavaScript is tied to the browser, having a few of the key developers spread into American universities outside AT&T, and creating workstation startups that succeed in the market.

Outside of the workstation market based on UNIX systems and a few universities, barely anyone was using C in Europe.

If those startups that paved the way to likes of Sun, SGI among others, had failed to capture the market, C would just be another footnote in the history of programming languages.

--
Paulo

On Monday, 13 October 2014 at 14:58:08 UTC, Ola Fosheim Grøstad wrote:
> Nice to have, but not critical to success IMO.

Templates are absolutely critical for any new system level programming language for me to even consider it. I had my share of pain emulating those in plain C and don't want to ever do it again.

On Tuesday, 14 October 2014 at 01:36:08 UTC, Dicebot wrote:
> Templates are absolutely critical for any new system level programming language for me to even consider it. I had my share of pain emulating those in plain C and don't want to ever do it again.

But maybe you don't really do low level programming then? In which areas of low level programming are templates critical? I have trouble finding examples where I have used it or seen it used for anything non-trivial in performant code.

In theory it is nice to write double/float/fixed-point functions once, but in reality you often need to change the algorithms or the implementation when moving from double to float if you care about performance.

Similarily for datastructures. You can often reduce the number of data structure collections needed to implement an algorithm by creating a special one that targets the dominant access patterns and operations of the algorithm. Or significantly improve memory handling. Or significantly improve cache performance.

In fact, when I think about it, you loose a lot when going from machine language to a programming language in the first place. When coding on a CISC like 68000 (that allows "high level assembly") you would structure the data, lookup tables and memory address space in a way to fit the problem and the instruction set to get performance and tight code.

On Tuesday, 14 October 2014 at 07:25:59 UTC, Ola Fosheim Grøstad wrote:
> But maybe you don't really do low level programming then? In which areas of low level programming are templates critical? I have trouble finding examples where I have used it or seen it used for anything non-trivial in performant code.

I don't do it right now but I definitely did (assuming barebone MIPS sounds low-level enough). And I can't say anything good about this experience from pure programming technology point of view.

Templates are not about low level or high level of domain. It is a tool to reduce code redundancy and simplify maintenance of large code base. I am not even speaking about algorithms in STL or std.algorithm sense but much more routine things - common small snippets that either get copy-pasted or hidden behind C macros.

Probably when you say "low level" you imagine something like embedded microcontrollers. But there quite many huge scale systems out there too, sometimes reaching millions lines of C code. And those struggle from minimal C abstraction capabilities.

On 10/14/2014 1:00 AM, Dicebot wrote:
> Templates are not about low level or high level of domain. It is a tool to
> reduce code redundancy and simplify maintenance of large code base. I am not
> even speaking about algorithms in STL or std.algorithm sense but much more
> routine things - common small snippets that either get copy-pasted or hidden
> behind C macros.

I discovered something very interesting about templates when writing Warp. Templates make it easy for unittests to test a function, by accepting dummy input that is conveniently of another type (such as using an array of data instead of an input range).

I'm sure I've heard of this before, type mocking and all, but it didn't sink in until I wrote Warp.

On Tuesday, 14 October 2014 at 08:00:21 UTC, Dicebot wrote:
> large code base. I am not even speaking about algorithms in STL or std.algorithm sense but much more routine things - common small snippets that either get copy-pasted or hidden behind C macros.

C has macros to compensate for deficiencies in the language.

What kind of routine things are you thinking about that cannot be covered either by better features or by explicit inlining?

> Probably when you say "low level" you imagine something like embedded microcontrollers. But there quite many huge scale

I am thinking about the stuff where it makes sense to drop down to C/C++ due to the nature of the problem.

For most applications it makes more sense to write the high level stuff in a high level language such as Objective-C/Swift and drop down to C/C++ for engine level stuff.

People often write everything in C/C++ for portability, but that is really a compiler/platform issue, not a language-design issue.

> systems out there too, sometimes reaching millions lines of C code. And those struggle from minimal C abstraction capabilities.

Or they struggle with C not having the right feature set. Sure, with templates you can implement more convenient ref-counting and unique-pointers, and you can get a little bit more type safety. But C suffers from the simple design of BCPL which was a bare bones version of CPL.

On Tue, 14 Oct 2014 07:25:56 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> But maybe you don't really do low level programming then? In which areas of low level programming are templates critical?
in the same areas as other things, like conditional branches, for example.

templates is a very cool macro system, with type checks and so. i haven't seen low-level programmers that doesn't use macros.

the only other required thing is good optimizing compiler with good inliner, so small templates will be really inserted in-place, like C macros.

there is also attribute inference for template functions, it's nice. ;-)

On Tue, 14 Oct 2014 09:36:33 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> C has macros
KILL! KILL! KILL! HULK SMASH!

On Tuesday, 14 October 2014 at 09:36:34 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 14 October 2014 at 08:00:21 UTC, Dicebot wrote:
>> large code base. I am not even speaking about algorithms in STL or std.algorithm sense but much more routine things - common small snippets that either get copy-pasted or hidden behind C macros.
>
> C has macros to compensate for deficiencies in the language.
>
> What kind of routine things are you thinking about that cannot be covered either by better features or by explicit inlining?
>
>> Probably when you say "low level" you imagine something like embedded microcontrollers. But there quite many huge scale
>
> I am thinking about the stuff where it makes sense to drop down to C/C++ due to the nature of the problem.
>
> For most applications it makes more sense to write the high level stuff in a high level language such as Objective-C/Swift and drop down to C/C++ for engine level stuff.

Why drop down to C/C++?

It would be like saying you need to drop down to them from D.

>
> People often write everything in C/C++ for portability, but that is really a compiler/platform issue, not a language-design issue.

This is what made me move away from Turbo Pascal back in the day.

If UNIX variants had a Turbo Pascal 7 or Modula-2 compatible compilers,
I would have stayed in that world for a lot longer.

>
>> systems out there too, sometimes reaching millions lines of C code. And those struggle from minimal C abstraction capabilities.
>
> Or they struggle with C not having the right feature set. Sure, with templates you can implement more convenient ref-counting and unique-pointers, and you can get a little bit more type safety. But C suffers from the simple design of BCPL which was a bare bones version of CPL.


C suffers from its designers not wanting to acknowledge what other systems programmers were doing, not from BCPL design.

--
Paulo

On Tue, 14 Oct 2014 11:04:01 +0000
Paulo  Pinto via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> This is what made me move away from Turbo Pascal back in the day.
> 
> If UNIX variants had a Turbo Pascal 7 or Modula-2 compatible
> compilers,
> I would have stayed in that world for a lot longer.

*nix is very hostile to non-c languages. i dropped FreePascal due to lack of headers for libraries. automatic converters still can't do the good things, and converting/fixing headers manually is *very* tedious.

this was a hard move, as i had to drop all my fpc libraries and start writing new ones for C.