> Isn't plain JSON even worse? At least the design you're criticising has a dynamic schema definition separate from code.
The point is that "dynamism" isn't needed in this case. It's used to define fixed parameter sets for different components, so those components could just as well define a class and use json to (de)serialize it.
IOW: Defining new fields, classes and values is worthless unless the underlying component can interpret them. So code changes are needed anyway, and then class is way better and safer to use.
I've seen a set of SQL tables designed to mimic "flexible classes". There's a table for the "class", another table defining its "fields", and two other tables defining class instances and related field values (all as varchar).
Flexible, yes. You can store anything. The downside is, that I've also found "anything". Stuff attached to the wrong "class", wrong datatypes, missing "obligatory" fields, etc, etc.
It's a PITA to work with. If I could design it from scratch, it'd be a single table with JSON payload.
- 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.
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.
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.
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.
> 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
}
> [...] 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.
(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`.
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.
I've been a co-founder of a Norwegian startup, Quine AS, that attempted to automate workflows in media productions (as in movies, series, commercials). Ultimately, we've failed; the company was dissolved in July 2024. I've used a couple of weeks of vacation to clean up and document the reusable parts of the code, and to write about (parts of) our history.
For those wondering: we (the co-founders) bought the IP back from the liquidation assets and agreed to open-source it.
I've been a co-founder of a Norwegian startup, Quine AS, that attempted to automate workflows in media productions (as in movies, series, commercials). Ultimately, we've failed; the company was dissolved in July 2024. I've used a couple of weeks of vacation to clean up and document the reusable parts of the code, and to write about (parts of) our history.
Depends on how you define "persistent data structure". In most definitions that I've encountered, a new version is made after each update. This code makes a new version only when you explicitly request it with Fork(). This allows you to
- Use the data structure as a "standard" tree, sharing one instance across threads and use locking for thread-safety
- Use it as a fully-persistent structure by calling "Fork" before every modification
- Or anything in between
I needed the 3rd case: a cache manager gives out a forked view of the actual cache contents to its clients. Thus the cache is always in control of the "master" copy, and if a client modifies its own fork, the cache and other clients are not affected.