Thoughts about "Compile-time types" talk

[Alex]

On Friday, 17 May 2019 at 09:15:14 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 17 May 2019 at 00:25:36 UTC, Alex wrote:
>> My point was that this is where languages are ultimately 
>> headed.  Knowing where we are going helps us get there.
>
> It would be interesting to use a language like that, for sure.

You'll have to wait a few millennia ;/ And it will require people 
to create it. After all, a thousand years ago the Greeks were 
contemplating such things in their own limited way wishing there 
was a better way to do something... Socrates would be amazing at 
what we have just as you will be amazing at what the future 
brings(if humans don't destroy themselves in the process).

But there is a clear evolutionary goal of computation, a 
direction to where things are moving that is beyond humans 
control. 100 years ago the computer scientists had no clue about 
the complexities of programming yet everything did was a stepping 
stone in the natural logical evolution of computation. 
Mathematics was the first computer, physic then was created which 
helped speed up things tremendously, who knows what is next.

With quantum computing, if it is in the right direction, a new 
programming paradigm and languages will need to be laid to make 
it practical. Imagine when you first learned programming and how 
primitive you thought compared to now. That is a microcosm of 
what is happening on the large scale. Compilers are still in the 
primitive stage on the higher level just as your programming 
knowledge is primitive on a higher level(and very advanced on a 
lower level).


The thing is, abstraction is the key to being able to deal with 
complexity. That is the only way humans can do what they do. 
Compilers that make it hard to do abstraction become very 
difficult to use for complexity. The only languages I see that 
handle complexity on any meaningful level are functional 
programming languages. Procedural languages actually seem to 
create an upper limit where it becomes exponentially harder to do 
anything past a certain amount of complexity.

The problem with functional programming languages is they are 
difficult to use for simple stuff and since all programs start 
out as simple, it becomes very hard to find a happy medium. It's 
as if one needs a D+Haskell combo that work seamlessly together 
where Haskell can build the abstraction and D can handle the 
nitty gritty details but that there would be a perfect blend 
between the procedural to the functional and one can work at any 
level at any time without getting stuck(hence one chooses the 
right amount for the particular task(which might be coding a 
graphics function or designing a oop like hierarchy)).

Most languages are hammers, you are stuck with using them to 
solve all the problems and if they don't solve a particular 
problem well then you are screwed, you just have to hammer away 
until you get somewhere.

Unfortunately D+Haskell would be an entirely new language.

One way to see this is the wave/particle duality. Humans are 
notorious in choosing one view or the other in things... reality 
is that there is no distinction... there is just one thing. Same 
goes for programming. Procedural and functional are just two 
different extremes and making the distinction is actually 
limiting in the long run. The goal with such things is choosing 
the right view for the right problem at the right time and then 
one can generate the solution very easily. Difficulty is 
basically using the wrong tool for the job. [And you'll notice 
that most D users use D in a specific job that it excels at and 
then believes that it is a great language because it does their 
job well... they just chose the right tool(relatively speaking) 
for their job. They generally fail to realize there are many 
tools and many jobs. The same goes for most Haskell users and 
most python users, etc.]