Re: Top Five World’s Most Underrated Programming Languages

2019-01-17 Thread Brian via Digitalmars-d-announce
On Monday, 14 January 2019 at 20:21:25 UTC, Andrei Alexandrescu 
wrote:

Of possible interest:

https://www.technotification.com/2019/01/most-underrated-programming-languages.html


Because no software can use it.

examples:
1. Docker use golang.
2. Middleware system use java.
3. Shell use python.
4. AI use python and R.
5. Desktop application use QT / C#.
6. Web framework & database use php's laravel and java's 
sprint-boot.

7. Web use Javascript / typescript.




Re: Top Five World’s Most Underrated Programming Languages

2019-01-17 Thread Meta via Digitalmars-d-announce

On Friday, 18 January 2019 at 01:15:06 UTC, Bill Baxter wrote:

Gotta laugh at Ruby being listed as "Underrated", though.

--bb

On Mon, Jan 14, 2019 at 12:25 PM Andrei Alexandrescu via 
Digitalmars-d-announce  
wrote:



Of possible interest:


https://www.technotification.com/2019/01/most-underrated-programming-languages.html


I get the feeling that Ruby's popularity is waning with the rise 
of Node.js and the broad ecosystem of Javascript-based web 
application frameworks. At one time it probably came close to 
rivaling Python in popularity and sheer volume of new 
development, but I think that's firmly in the past now (not that 
it is dead, by any means).


Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)

2019-01-17 Thread Walter Bright via Digitalmars-d-announce

On 1/17/2019 11:31 AM, H. S. Teoh wrote:

[...]


Thanks for the thoughtful and well-written piece.

But there is a counterpoint: symmetry in mathematics is one thing, but symmetry 
in human intuition is not. Anytime one is dealing in human interfaces, one runs 
into this. I certainly did with the way imports worked in D. The lookups worked 
exactly the same for any sort of symbol lookup. I thought it was great.


But I was unable to explain it to others. Nobody could understand it when I said 
imported symbol lookup worked exactly like any lookup in a name space. They 
universally said it was "unintuitive", filed bug reports, etc. Eventually, I had 
to give it up. Now import lookup follows special different rules, people are 
happy, and I learned (again) that symmetry doesn't always produce the best outcomes.


User interfaces (and programming languages certainly are user interfaces) are 
hard and (ironically) are anything but intuitive to design.


Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)

2019-01-17 Thread Walter Bright via Digitalmars-d-announce

On 1/17/2019 8:06 AM, bpr wrote:

Was that a pre C++11 version of C++, or a more modern one?


pre C++11


Re: Top Five World’s Most Underrated Programming Languages

2019-01-17 Thread Bill Baxter via Digitalmars-d-announce
Gotta laugh at Ruby being listed as "Underrated", though.

--bb

On Mon, Jan 14, 2019 at 12:25 PM Andrei Alexandrescu via
Digitalmars-d-announce  wrote:

> Of possible interest:
>
>
> https://www.technotification.com/2019/01/most-underrated-programming-languages.html
>


Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)

2019-01-17 Thread Stefan Koch via Digitalmars-d-announce

On Thursday, 17 January 2019 at 22:44:08 UTC, H. S. Teoh wrote:
On Thu, Jan 17, 2019 at 10:20:24PM +, Stefan Koch via 
Digitalmars-d-announce wrote:
P.S. There is one caveat: because of how type-functions work 
they cannot, you cannot create a non-anonymous symbol inside a 
type-function, because there is no way to infer a mangle.


You can however create an anonymous symbol and alias it inside 
a template body, which gives it a mangle and it can behave 
like a regular symbol.


Interesting.  Is it possible to assign a "fake" mangle to type 
functions that never actually gets emitted into the object 
code, but just enough to make various internal compiler stuff 
that needs to know the mangle work properly?


No this is not possible, a symbol which is only used at 
compile-time is actually really rare. Actually If the symbol is 
constrained to a compile-time only context (e.g. inside is() or 
taking the .sizeof) this problem does not arise, and it could be 
allowed.


Imagine you want to return a struct type  which has all the 
fields of a given base struct but adds a member.

module ct_helper;

alias f(alias baseT, alias newMemberType, string newMember_name)
{
   struct Extended
   {
   baseT base;
   mixin("newMemberType " ~ newMemberName);
   }
   return typeof(Extended.init);
}

--

module user

struct S1 { int x; }
alias S2 = f!(S1, float, "y") // looks like a 
template-instantiation but it's not!, I am just reusing it, to 
not confuse the parser to much.


which mangle should this get?
S2 ?  - doesn't work there is no mangle for an alias.
 ct_helper.f.Extended? doesn't work if we call the type-function 
again with diffrent arguments
make it an anonymous type ? - If we do that than this means that 
the type-function is no longer pure as two anonymous types can 
never Equal each other


include the arguments to the type-function and it's parameters in 
the mangle? - that's possible but type-functions are not meant to 
leave any sign of their existence in order to not introduce ABI 
issues.


In short for now I'd rather side-step the problem by not allowing 
freshly minted types to escape into a runtime context without 
going through a template wrapper (which also handles caching and 
has proper behavior in is-expressions).




Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)

2019-01-17 Thread Johannes Loher via Digitalmars-d-announce
Am 17.01.19 um 23:20 schrieb Stefan Koch:
> For 2 years I have pondered this problem, and I did come up with a
> solution.
> It's actually not that hard to have CTFE interact with type-tuples.
> You can pass them as function parameters, or return them if you wish.
> Of course a type-tuple returning ctfe function, is compile-time only.
> This solved one more problem that ctfe has:
> helper functions required for ctfe can only be omitted from the binary,
> if you use the trick of putting them into a module which is the import
> path but never explicitly given on the command line.
> newCTFE has the facility to be extended for this, and implementing
> type-functions is at least on my personal roadmap.
> 
> At Dconf 2018 Andrei and Walter said, a DIP which is substantiated
> enough might make it.
> However due to lack of time, (and productivity-reducing internal
> changes) it will take some time until I can get started on this.
> 
> Also I plan for newCTFE to be in shape before I add type-manipulation
> abilities.
> 
> Cheers,
> 
> Stefan
> 
> P.S. There is one caveat: because of how type-functions work they
> cannot, you cannot create a non-anonymous symbol inside a type-function,
> because there is no way to infer a mangle.
> You can however create an anonymous symbol and alias it inside a
> template body, which gives it a mangle and it can behave like a regular
> symbol.
> 
> 
This is one of the most exciting things i have read in recent times!



Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)

2019-01-17 Thread H. S. Teoh via Digitalmars-d-announce
On Thu, Jan 17, 2019 at 10:20:24PM +, Stefan Koch via 
Digitalmars-d-announce wrote:
> On Thursday, 17 January 2019 at 19:31:24 UTC, H. S. Teoh wrote:
[...]
> > Coming back to the D example at the end, I totally agree with the
> > sentiment that D templates, in spite of their significant
> > improvements over C++ syntax, ultimately still follow the same
> > recursive model. Yes, you can use CTFE to achieve the same thing at
> > runtime, but it's not the same thing, and CTFE cannot manipulate
> > template argument lists (aka AliasSeq aka whatever it is you call
> > them).  This lack of symmetry percolates down the entire template
> > system, leading to the necessity of the hack that Bartosz refers to.
> > 
> > Had template argument lists / AliasSeq been symmetric w.r.t. runtime
> > list manipulation, we would've been able to write a foreach loop
> > that manipulates the AliasSeq in the most readable way without
> > needing to resort to hacks or recursive templates.
> > 
> For 2 years I have pondered this problem, and I did come up with a
> solution.  It's actually not that hard to have CTFE interact with
> type-tuples.  You can pass them as function parameters, or return them
> if you wish.  Of course a type-tuple returning ctfe function, is
> compile-time only.

YES!  This is the way it should be.  Type-tuples become first class
citizens, and you can pass them around to functions and return them from
functions, the only stipulation being that they can only exist at
compile-time, so it's an error to use them at runtime.

In other words, they become symmetric to other built-in language types,
and can be manipulated by conventional means, instead of being an
oddball exception with special-case behaviour that requires special-case
syntax dedicated to manipulating them.  Again, the root of the problem
is asymmetry, and the solution is to make it symmetric.


> This solved one more problem that ctfe has:
> helper functions required for ctfe can only be omitted from the
> binary, if you use the trick of putting them into a module which is
> the import path but never explicitly given on the command line.

Exactly.  Yet another problem caused by the asymmetry of type-tuples
w.r.t. other built-in types, and naturally solved by making them
symmetric.


> newCTFE has the facility to be extended for this, and implementing
> type-functions is at least on my personal roadmap.

Awesome.


> At Dconf 2018 Andrei and Walter said, a DIP which is substantiated
> enough might make it.
> However due to lack of time, (and productivity-reducing internal
> changes) it will take some time until I can get started on this.
> 
> Also I plan for newCTFE to be in shape before I add type-manipulation
> abilities.

Yes, let's please get the Minimum Viable Product of newCTFE merged into
master first, before we expand the scope (and delay the schedule :-P)
yet again!


[...]
> P.S. There is one caveat: because of how type-functions work they
> cannot, you cannot create a non-anonymous symbol inside a
> type-function, because there is no way to infer a mangle.
>
> You can however create an anonymous symbol and alias it inside a
> template body, which gives it a mangle and it can behave like a
> regular symbol.

Interesting.  Is it possible to assign a "fake" mangle to type functions
that never actually gets emitted into the object code, but just enough
to make various internal compiler stuff that needs to know the mangle
work properly?


T

-- 
Why do conspiracy theories always come from the same people??


Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)

2019-01-17 Thread Stefan Koch via Digitalmars-d-announce

On Thursday, 17 January 2019 at 19:31:24 UTC, H. S. Teoh wrote:
On Thu, Jan 17, 2019 at 06:03:07PM +, Paul Backus via 
Digitalmars-d-announce wrote: [...]
[2] 
https://bartoszmilewski.com/2009/10/21/what-does-haskell-have-to-do-with-c/

[...]

Coming back to the D example at the end, I totally agree with 
the sentiment that D templates, in spite of their significant 
improvements over C++ syntax, ultimately still follow the same 
recursive model. Yes, you can use CTFE to achieve the same 
thing at runtime, but it's not the same thing, and CTFE cannot 
manipulate template argument lists (aka AliasSeq aka whatever 
it is you call them).  This lack of symmetry percolates down 
the entire template system, leading to the necessity of the 
hack that Bartosz refers to.


Had template argument lists / AliasSeq been symmetric w.r.t. 
runtime list manipulation, we would've been able to write a 
foreach loop that manipulates the AliasSeq in the most readable 
way without needing to resort to hacks or recursive templates.


For 2 years I have pondered this problem, and I did come up with 
a solution.
It's actually not that hard to have CTFE interact with 
type-tuples.
You can pass them as function parameters, or return them if you 
wish.
Of course a type-tuple returning ctfe function, is compile-time 
only.

This solved one more problem that ctfe has:
helper functions required for ctfe can only be omitted from the 
binary, if you use the trick of putting them into a module which 
is the import path but never explicitly given on the command line.
newCTFE has the facility to be extended for this, and 
implementing type-functions is at least on my personal roadmap.


At Dconf 2018 Andrei and Walter said, a DIP which is 
substantiated enough might make it.
However due to lack of time, (and productivity-reducing internal 
changes) it will take some time until I can get started on this.


Also I plan for newCTFE to be in shape before I add 
type-manipulation abilities.


Cheers,

Stefan

P.S. There is one caveat: because of how type-functions work they 
cannot, you cannot create a non-anonymous symbol inside a 
type-function, because there is no way to infer a mangle.
You can however create an anonymous symbol and alias it inside a 
template body, which gives it a mangle and it can behave like a 
regular symbol.





Re: Top Five World’s Most Underrated Programming Languages

2019-01-17 Thread Carl Sturtivant via Digitalmars-d-announce
On Monday, 14 January 2019 at 20:21:25 UTC, Andrei Alexandrescu 
wrote:

Of possible interest:

https://www.technotification.com/2019/01/most-underrated-programming-languages.html


What's interesting here is the language nim, which perhaps has 
some lessons for D.

https://nim-lang.org/




Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)

2019-01-17 Thread Steven Schveighoffer via Digitalmars-d-announce

On 1/17/19 2:31 PM, H. S. Teoh wrote:

On Thu, Jan 17, 2019 at 06:03:07PM +, Paul Backus via 
Digitalmars-d-announce wrote:
[...]

[2]
https://bartoszmilewski.com/2009/10/21/what-does-haskell-have-to-do-with-c/

[...]

Haha, seems D did better than C++ in this respect, but not quite at the
level of Haskell.

The C++ example of a template that takes templates and arguments and
declares another template is a perfect example of why C++ template
syntax is utterly horrible for doing these sorts of things.

Coming back to the D example at the end, I totally agree with the
sentiment that D templates, in spite of their significant improvements
over C++ syntax, ultimately still follow the same recursive model. Yes,
you can use CTFE to achieve the same thing at runtime, but it's not the
same thing, and CTFE cannot manipulate template argument lists (aka
AliasSeq aka whatever it is you call them).  This lack of symmetry
percolates down the entire template system, leading to the necessity of
the hack that Bartosz refers to.

Had template argument lists / AliasSeq been symmetric w.r.t. runtime
list manipulation, we would've been able to write a foreach loop that
manipulates the AliasSeq in the most readable way without needing to
resort to hacks or recursive templates.


well, there was no static foreach for that article (which I admit I 
didn't read, but I know what you mean).


But it's DEFINITELY not as easy as it could be:

import std.conv;

alias AliasSeq(P...) = P;

template staticMap(alias Transform, Params...)
{
alias seq0 = Transform!(Params[0]);
static foreach(i; 1 .. Params.length)
{
   mixin("alias seq" ~ i.to!string ~ " = AliasSeq!(seq" ~ 
(i-1).to!string ~ ", Transform!(Params[" ~ i.to!string ~ "]));");

}
mixin("alias staticMap = seq" ~ (Params.length-1).to!string ~ ";");
}

alias Constify(T) = const(T);
void main()
{
alias someTypes = AliasSeq!(int, char, bool);
pragma(msg, staticMap!(Constify, someTypes)); // (const(int), 
const(char), const(bool))

}

Note, that this would be a LOT easier with string interpolation...

mixin("alias seq${i} = AliasSeq!(seq${i-1}, 
Transform!(Params[${i}]));".text);


-Steve


Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)

2019-01-17 Thread H. S. Teoh via Digitalmars-d-announce
On Thu, Jan 17, 2019 at 06:03:07PM +, Paul Backus via 
Digitalmars-d-announce wrote:
[...]
> [2]
> https://bartoszmilewski.com/2009/10/21/what-does-haskell-have-to-do-with-c/
[...]

Haha, seems D did better than C++ in this respect, but not quite at the
level of Haskell.

The C++ example of a template that takes templates and arguments and
declares another template is a perfect example of why C++ template
syntax is utterly horrible for doing these sorts of things.

Coming back to the D example at the end, I totally agree with the
sentiment that D templates, in spite of their significant improvements
over C++ syntax, ultimately still follow the same recursive model. Yes,
you can use CTFE to achieve the same thing at runtime, but it's not the
same thing, and CTFE cannot manipulate template argument lists (aka
AliasSeq aka whatever it is you call them).  This lack of symmetry
percolates down the entire template system, leading to the necessity of
the hack that Bartosz refers to.

Had template argument lists / AliasSeq been symmetric w.r.t. runtime
list manipulation, we would've been able to write a foreach loop that
manipulates the AliasSeq in the most readable way without needing to
resort to hacks or recursive templates.

//

Lately, as I've been pondering over these fundamental language design
issues, I've become more and more convinced that symmetry is the way to
go.  And by symmetry, I mean the mathematical sense of being "the same
under some given mapping (i.e., transformation or substitution)".

Why is C++ template syntax such a mess to work with?  Because it's a
separate set of syntax and idioms grafted onto the original core
language with little or no symmetry between them.  Where the core
language uses < and > as comparison operators, template syntax uses <
and > as delimiters. This asymmetry leads to all kinds of nastiness,
like earlier versions of C++ being unable to parse
`templateA>` properly (the >> gets wrongly lexed as a
bitshift operator). An intervening space is required to work around this
asymmetry.  This is just one trivial example.

A more fundamental example, which also afflicts D, is that the template
instantiation mechanism is inherently recursive rather than iterative,
so when you need to write a loop, you have to paraphrase it as a
recursive template. This is asymmetric with the runtime part of the
language, where constructs like `foreach` are readily available to
express the desired semantics.

On a different note, the same principle of symmetry applies to built-in
types vs. user-defined types. In TDPL Andrei alludes to programmers
disliking built-in types having "magic" behaviour that's different from
user-defined types.  Why the dislike? Because of asymmetry. Built-in
types have special behaviour that cannot be duplicated by user-defined
types, so when you want the special behaviour but built-in types don't
quite meet your needs, you find yourself without any recourse. It is
frustrating because the reasoning goes "if built-in type X can have
magic behaviour B, why can't user-defined type Y have behaviour B too?"
The desire for behaviour B to be possible both for built-in types and
user-defined types stems from the desire for symmetry.

Why is alias this so powerful?  Because it lets a new type Y behave as
if it were an existing type X -- it's symmetry.  Similarly, the Liskov
Substitution Principle is essentially a statement of symmetry in the
universe of OO polymorphism.

Why is the Unix "everything is a file" abstraction so useful? Because of
symmetry: whether it's a physical file, a network socket, or pipe, it
exposes the same API. Code that works with the data don't have to care
about what kind of object it is; it can simply use the API that is
symmetric across different types of objects.

Similarly, why are D ranges so powerful? Because they make containers,
data sources, data generators, etc., symmetric under the range API
operations.  It allows code to be decoupled from the details of the
concrete types, and focus directly on the problem domain.

Why does the GC simplify many programming tasks so much? Because it
makes every memory-allocated object symmetric w.r.t. memory management:
you stop worrying about whether something is stack-allocated or
heap-allocated, whether it has cycles, or whether somebody else still
holds a reference to it -- you focus on the problem domain and let the
GC do its job.

At a higher level: in the old days, programming languages used to
distinguish between functions and procedures (and maybe some languages
still do, but they seem rare these days). But eventually this
distinction was ditched in favor of things like returning `void` (C,
C++, Java, D), or some other equivalent construct. Why? So that instead
of having two similar but asymmetric units of code encapsulation,
everything is just a "function" (it just so happens some functions don't
return a meaningful value). IOW, introduce symmetry, get rid of the
asymmetry.


On the flip side, 

Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)

2019-01-17 Thread Paul Backus via Digitalmars-d-announce

On Thursday, 17 January 2019 at 16:06:39 UTC, bpr wrote:
On Thursday, 17 January 2019 at 01:59:29 UTC, Walter Bright 
wrote:
Bartosz Milewski is a C++ programmer and a Haskell fan. He 
once gave a presentation at NWCPP where he wrote a few lines 
of Haskell code. Then, he showed the same code written using 
C++ template metaprogramming.


The Haskell bits in the C++ code were highlighted in red. It 
was like a sea of grass with a shrubbery here and there. 
Interestingly, by comparing the red dots in the C++ code with 
the Haskell code, you could understand what the C++ was doing. 
Without the red highlighting, it was a hopeless wall of < > :-)


Was that a pre C++11 version of C++, or a more modern one?

It would be instructive to see that example with C++17 or even 
20 and D

next to each other.


The presentation was given at BoostCon 2011, and is (at least 
partially) available on youtube [1]. There is also a blog post 
from 2009, "What Does Haskell Have to Do with C++?" [2] that uses 
the same format, and presumably covers the same material. The 
examples in the blog post were tested with "the GNU C++ compiler 
v. 4.4.1 with the special switch -std=c++0x", which according to 
the GCC documentation [3] includes many (but not all) features 
from C++11.


[1] https://www.youtube.com/watch?v=GjhsSzRtTGY
[2] 
https://bartoszmilewski.com/2009/10/21/what-does-haskell-have-to-do-with-c/

[3] https://gcc.gnu.org/gcc-4.4/cxx0x_status.html


Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)

2019-01-17 Thread bpr via Digitalmars-d-announce

On Thursday, 17 January 2019 at 01:59:29 UTC, Walter Bright wrote:

On 1/16/2019 4:19 PM, H. S. Teoh wrote:
On Wed, Jan 16, 2019 at 11:43:19PM +, John Carter via 
Digitalmars-d-announce wrote:

[...]


Yes, that's one of the outstanding qualities of D, and one 
that I was
immensely impressed with when I perused the Phobos source code 
for the

first time.
Bartosz Milewski is a C++ programmer and a Haskell fan. He once 
gave a presentation at NWCPP where he wrote a few lines of 
Haskell code. Then, he showed the same code written using C++ 
template metaprogramming.


The Haskell bits in the C++ code were highlighted in red. It 
was like a sea of grass with a shrubbery here and there. 
Interestingly, by comparing the red dots in the C++ code with 
the Haskell code, you could understand what the C++ was doing. 
Without the red highlighting, it was a hopeless wall of < > :-)


Was that a pre C++11 version of C++, or a more modern one?

It would be instructive to see that example with C++17 or even 20 
and D

next to each other.


Re: My Meeting C++ Keynote video is now available

2019-01-17 Thread H. S. Teoh via Digitalmars-d-announce
On Thu, Jan 17, 2019 at 11:17:18AM +, Tony via Digitalmars-d-announce wrote:
> On Sunday, 13 January 2019 at 04:04:14 UTC, Walter Bright wrote:
> 
> > One major takeaway is that the bugs/line are the same regardless of
> > the language used. This means that languages that enable more
> > expression in fewer lines of code result in fewer bugs for the same
> > functionality.
> > 
> Is the data to support this conclusion freely available on the web
> somewhere?
> 
> My impression is that Python is considered the easiest language to
> use. If it has no more bugs per line than a statically typed program
> that seems to suggest that non-speed-critical work should be done in
> Python.

No, if the number of bugs is truly proportional to the number of lines,
then we should all ditch D and write APL instead.  :-P


T

-- 
Leather is waterproof.  Ever see a cow with an umbrella?


Re: My Meeting C++ Keynote video is now available

2019-01-17 Thread Tony via Digitalmars-d-announce

On Sunday, 13 January 2019 at 04:04:14 UTC, Walter Bright wrote:

One major takeaway is that the bugs/line are the same 
regardless of the language used. This means that languages that 
enable more expression in fewer lines of code result in fewer 
bugs for the same functionality.


Is the data to support this conclusion freely available on the 
web somewhere?


My impression is that Python is considered the easiest language 
to use. If it has no more bugs per line than a statically typed 
program that seems to suggest that non-speed-critical work should 
be done in Python.


Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)

2019-01-17 Thread H. S. Teoh via Digitalmars-d-announce
On Wed, Jan 16, 2019 at 05:59:29PM -0800, Walter Bright via 
Digitalmars-d-announce wrote:
[...]
> Bartosz Milewski is a C++ programmer and a Haskell fan. He once gave a
> presentation at NWCPP where he wrote a few lines of Haskell code.
> Then, he showed the same code written using C++ template
> metaprogramming.
> 
> The Haskell bits in the C++ code were highlighted in red. It was like
> a sea of grass with a shrubbery here and there. Interestingly, by
> comparing the red dots in the C++ code with the Haskell code, you
> could understand what the C++ was doing. Without the red highlighting,
> it was a hopeless wall of < > :-)
[...]

I don't know Haskell, but I've worked with Scheme (another Lisp dialect
/ derivative) a little, and sometimes I feel like the core of my logic
is little bits of shrubbery lost in an ocean of parentheses. :-P


T

-- 
I don't trust computers, I've spent too long programming to think that they can 
get anything right. -- James Miller