Similar story here. C64 was amazing, even to load a game, you had to learn some commands. (Unless the game was in a cartridge.)

Then I got a PC, and learned structured programming with Borland Pascal and later Turbo C. These were great IDEs for the time.

What'd I tell to Bjarne:

- In the future, you'll carry in your pocket a computer more powerful than the sum of all computers currently present at the university

- The unchecked flat memory model of C will cause numerous security issues with sometimes grave consequences in the "real world"

- Follow the design of Standard ML (SML) and adapt it to systems programming (yeah, it appeared in 1983, but surely papers have been published before that)

- Do not even think about using unsigned types for sizes and get rid of implicit numeric conversions: if (v.size() - 1 < 0) fails on empty vector in today's C++

- Deterministic resource management is still important and is _the_ feature that C++ gets praised for.

- Lack of standard ABI will cause a lot of headaches and lost time.

- I would tell him about LLVM IR, .NET assemblies, metadata and encourage him to first standardize an intermediate format which the compiler could read and write. That'd ensure seamless interoperability between compilers and even other languages.

- Related to the above point: the header/source split will become a burden.

C++ created disasters on maintenance. The best could happen to C++ it's to be killed for once et all with Go as a systems' language and Rust maybe for the rest.

Go could have learnt a few lessons from the languages that predated it, instead like the authors originally did with C, it was more fun to create their own thing, and leave a few warts that will never be fixed as Go will never leave beyond 1.<increment counter>.

At least it is much safer than C will ever be.

Rust still needs to get rid of its C++ dependency on LLVM, and eventually GCC.

Go learnt everything from plan9 C and Limbo which are pretty much the refined versions of Unix, C and something being the core of Inferno.

It's pretty much good enough maybe not for operating systems, but ideal for network-waiting daemons. It uses far more RAM than a core written in C, but for something built for the future, in 2030 it won't be that bloated. Specially when were are seeing Electron bound aberrations and even JS ridden crap under Gnome and Windows 11 for trivial tasks.

Yes Go is an improvement over C, with Alef and Limbo learnings, and some Oberon-2 in the mix, pity that they forgot about everyone else in the programming language community.

Proper enumerations instead of iota/const, generators as language feature instead of callback gimmicks, generics still have a few sharp corners, the new Do approach, plugins half done, verbose error handling,....

Because with POST you have a RPC (remote procedure call) with arbitrary semantics and HTTPS is just a convenient transport.

That's also why I only use a couple of status codes: Ok, Created, NoContent, BadRequest, Forbidden, Unauthorized an InternalServerError (the latter two generated automatically by the framework).

GET, PUT, DELTE, etc. seem to be tailored towards entities, but as soon as the endpoint is not an "entity", the semantics get vague and break down.

It just works without any tweaks. Also, Visual Studio, One Drive, One Note, (office apps in general).

Nuclear has the highest energy density (kWh produced per km2). "Renewables" need much larger areas to produce equivalent power. This means that habitats for many species are negatively affected or destroyed.

This is an ongoing debate in Norway where local people are strongly against wind turbines because they want to preserve the nature as it is.

EDIT: Relevant poster in the picture. I once was approached by Greenpeace activist on the street who was collecting money. While I would gladly donate to WWF, I said sharp "NO" to him and explained that it was because Greenpeace opposes nuclear.

I obviously don't know about Norway, but in most developed countries, the number one reason for habitat destruction or disruption is going to be animal agriculture, or highspeed road infrastructure. While I can't prove it, it seems too convenient that people suddenly care about "nature" right after they've fucked it up for so many other reasons.

> suddenly care about "nature"

Obviously its extremely arbitrary and selective.

https://www.wwf.no/dyr-og-natur/truede-arter/ulv-i-norge/ret...

Moral posturing and virtue signalling is a huge part of Scandinavian culture in general.

> the number one reason for habitat destruction or disruption is going to be animal agriculture, or highspeed road infrastructure

The surface of both of these things hasn't changed much in the last 30 years.

> The surface of both of these things hasn't changed much in the last 30 years.

Source?

It was also my understanding that large amounts of habitat (e.g. Amazon rainforest) are lost for agriculture in general, and that cows are a particularly large part of that

Road surfaces I don't specifically know in terms of habitat area loss, but they split up habitat areas, and surely we'll have gotten more road surface as we went from ~6 to ~8 billion people on the planet in the last 30 years? How could that have stayed roughly the same?!

I wish more people would think along these lines: https://www.theguardian.com/environment/2009/may/10/windpowe...

There’s a wind farm being built in your backyard? Demand one of them for free to power your village.

> This is an ongoing debate in Norway where local people are strongly against wind turbines because they want to preserve the nature as it is.

Really ? They don't mind being one of the top oil exporter in the world though

Oil and gas extraction is "invisible", platforms far, far away on the sea. Nothing to complain about. :)

While that's strictly true, there are a lot of people who wouldnt mind living across the fence from a solar farm. Not so many want to live next to a nuclear power plant. Irrationaly perhaps but still.

Energy density is unimportant. What matters is cost. A source that has higher energy density but also higher cost is a loser.

The whole energy density meme was propagated by Vaclav Smil. He observed in the past that energy sources had become more energy dense, and then took the irrational leap to proclaim this was some sort of iron law of energy development.

> because they want to preserve the nature as it is.

In Norway? Or by nature as it is you mean managed nature "parks" or reindeer herding areas?

Don't Scandinavians generally vehemently support the eradication of native species like wolves (despite much bigger number of them doing just fine in much denser areas like Italy or Poland).

By "nature" i mean e.g., mountains. Not necessarily managed park. IIRC, the people have also protested against high-voltage lines because... dunno, they "ruin the view" across the fjord I guess.

> reindeer herding areas

There was recently a case in the highest court, Sami people vs state where they wanted newly built wind park in Finnmark to be torn down because... reindeer, native land and rights. They (Sami) won. Funnily, some researchers have shown that reindeer got used to the windmills quickly with seemingly no adverse effects. (Truth to be told, Sami are also internally divided on many issues. There's also a bitter (relatively recent) history between Sami and the state where the state had suppressed Sami culture over decades.)

After the verdict, some lower-ranked politicians said that Finnmark is about to become a museum, no development will now be possible there. I jokingly once thought: give the whole area to Russia so Sami can demonstrate in front of Kremlj.

I don't think the windmills will get torn down, and what happens next, I have no idea.

(For reference: the area is about 48000 km2 and population is around 75000 people. Which gives about 1.5 person per square kilometer.)

> eradication of native species like wolves

Not eradication but controlled number reduction. I'm personally opposed to it, but farmers somehow have a strong-hold on the government there. ATTACKS ON THE LIVE-STOCK! I don't know how much financial damage they suffer yearly, but that's the official explanation.

> ATTACKS ON THE LIVE-STOCK!

It's rather interesting how Italy or Poland can fit several times more livestock, people and wolves into significantly less area.

https://ec.europa.eu/eurostat/databrowser/view/APRO_MT_LSCAT...

Italy is more densely populated than Denmark for example (and Sweden is an empty wasteland in comparison), yet also somehow has enough space both for wolves and cows/sheep/etc.

"Don't Scandinavians generally vehemently support the eradication of native species like wolves" - Don't know where you got this idea from. Yes, Sweden has started allowing licensed (very regulated) hunting of wolf, but only because the population has increased a lot. There is already tension between livestock farmers and wolfs in places, and I believe allowing wolfes to become much more than what we currently would eventuallt results in _fewer_ wolfs because they would start getting hated.

The greens have long been staunch supportes of wolfs in Sweden, and its the right which is not. Atm we do have a right leaning government so... Im sure it will sway the other way eventually.

> but only because the population has increased a lot

Swedish wolf population is extremely small relative to its geographical size.

There are less than 400 wolves in Sweden. For example there are 1500 wolves in Poland, possibly twice that in Italy. How many times more farmers livestock those countries have? Let alone people. The Baltic states have more than twice as many wolves as Sweden and Norway put together...

Sweden is 50% larger than Italy and six times less people, yet somehow several times less area available for wildlife?

Talking about farmers..

https://en.wikipedia.org/wiki/Land_use_statistics_by_country

Sweden has only slightly more cultivated land than Lithuania (and Norway several times less than that), let alone Poland or Italy...

There are 6000 to 7500 gray wolves in the US lower 48 states (and nearly 10000 in Alaska.)

The Eastern Coyote is larger than the western variety and has some wolf DNA. It seems to be evolving to fill the niche the wolf occupied in the eastern US. There may be as many as 4.7 million coyotes in the US. There's a pair in Central Park in New York City; Chicago has ~2000.

> Allows me to move directories around, without having to depend on an IDE to keep namespaces in sync.

So... without and IDE, you'd move code around, let the NS be changed due to being placed in a different directory structure, and then fix namespaces on use-sites manually?

> I want all of C#, with terseness and not forcing OOP.

C# does not force OOP on you. You can have a single namespace, single static partial class and spread its members across as many files as you want. So the "ceremony" consists of the following snippet _per file_

    namespace NS;
    static partial class C {
        // Your methods here
    }

> Pushing these into an IDE is the Windows way of doing things.

s/Windows/modern/

> To win in Unix land, C# needs to be editable in a plain text editor.

I guess hard-core unix users still use sticks and stones to make fire.

I just want to focus on writing functions. Here's a trivial example.

I would like:

  // math/adder.cs
  public static add(int x, int y) : int {
    return x + y;
  }

Instead of:

  // math/adder.cs
  namespace math {
    class adder {
      public static add(int x, int y) : int {
        return x + y;
      }
    }
  }

Both are callable as:

  math.adder.add(10, 20);

C# allows file-level namespaces so you can write

    namespace Math;

    static class Adder {
      public static int Add(...) { ... }
    }

(one nesting level less). Next, elsewhere you can write

    namespace Whatever;
    using static Math.Adder;

    class CC {
      void M() {
        var z = Add(10, 20); // no NS qualification needed due to using static above
      }
    }

Java enforces directory structure to reflect package names, and this feature is not universally popular.

I agree with the first example. I wish C# could do “free” floating functions which just lives in the namespace itself. Your second example could do with the extra namespace indentation by doing

namespace math;

But why?

Having to use class/struct instead of free floating funcs tries to force some hierarchy, architecture, etc

Which eventually makes the code better *globally*

I was arguing that the hierarchy is already in your path. The explicit namespace (and even the class name) is redundant if what you want are mostly functions.

Currently, you're forced to define the hierarchy in the directory structure, and then again with namespaces. There should be a way to opt out of this.

Ok, I see

As of now you can opt out of physical hierarchy (file patches)

I think logical hierarchy is better because you avoid stupid things like moving file to other folder causing compilation errors.

I've witnessed too much of such issues in C++/cmake world to want it.

Just Linux (not counting other *nix) has a ~63% server market share. [1]

That's a lot of sticks and stones.

[1] https://en.m.wikipedia.org/wiki/Usage_share_of_operating_sys...

Plenty of those servers run Java, which is where C# kind of comes from due to J++ lawsuit.

> [...] how do you find the code that will run when they do fail? You would have to traverse [...]

I work in a .NET world and there many developers have this bad habit of "interface everything", even if it has just 1 concrete implementation; some even do it for DTOs. "Go to implementation" of a method, and you end up in the interface's declaration so you have to jump through additional hoops to get to it. And you're out of luck when the implementation is in another assembly. The IDE _could_ decompile it if it were a direct reference, but it can't find it for you. When you're out of luck, you have to debug and step into it.

But this brings me to dependency injection containers. More powerful ones (e.g., Autofac) can establish hierarchical scopes, where new scopes can (re)define registrations; similar to LISP's dynamically scoped variables. What a service resolves to at run-time depends on the current DI scope hierarchy.

Which brings me to the point: I've realized that effects can be simulated to some degree by injecting an instance of `ISomeEffectHandler` into a class/method and invoking methods on it to cause the effect. How the effect is handled is determined by the current DI registration of `ISomeEffectHandler`, which can be varied dynamically throughout the program.

So instead of writing

    void DoSomething(...) {
        throw SomeException(...);
    }

you establish an error protocol through interface `IErrorConditions` and write

    void DoSomething(IErrorConditions ec, ...) {
        ec.Report(...);
    }

(Alternately, inject it as a class member.) Now, the currently installed implementation of `IErrorConditions` can throw, log, or whatever. I haven't fully pursued this line of though with stuff like `yield`.

The annoyance is that the .NET standard library already does this precise thing, but haphazardly and in far fewer places than ideal.

ILogger and IProgress<T> comes to mind immediately, but IMemoryCache too if you squint at it. It literally just "sets" and "gets" a dictionary of values, which makes it a "state" effect. TimeProvider might be considered an algebraic effect also.

> I work in a .NET world and there many developers have this bad habit of "interface everything", even if it has just 1 concrete implementation

I work on a Java backend that is similar to what you're describing, but Intellij IDEA is smart enough to notice there is exactly one non-test implementation and bring me to its source code.

not that familiar with java, but in .net when you do this, it is very common for the implementation to be in a separate assembly, part of a different project

Doesn’t that imply an interface is necessary though, so you can compile (and potentially release) the components separately? I don’t use .net but this sounds quite similar to pulling things into separate crates in Rust or different compilation units in C, which is frequently good practice.

Definitely that could imply the necessity of an interface, but often it's simply done, because everyone working in a project blindly follows an already established poor convention.

by "it's common in the .Net world" I mean that it seems to be an antipattern that's blindly followed. If there's only ever one implementation, it is the interface, imo

> you end up in the interface's declaration so you have to jump through additional hoops to get to it

Bit of a tangent, but this really annoys me when I work on TypeScript (which isn't all that often, so maybe there's some trick I'm missing)—clicking through to check out the definition of a library function very often just takes me to a .d.ts file full of type definitions, even if the library is written in TypeScript to begin with.

In an ideal world I probably shouldn't really need to care how a library function is implemented, but the world is far from ideal.

Check out work by Microsoft research. Examples: Z3 solver, project Orleans.

Recently I wished for "VB for Web". Something that'd make it easy for a tech-competent, but a non-programmer, person to prototype a functional web application.