1,937 karma · joined July 11, 2010
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.
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.
Then I got a PC, and learned structured programming with Borland Pascal and later Turbo C. These were great IDEs for the time.
- 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.
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.
> 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.
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.
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
} 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.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 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`.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.
- 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.
It provides the opposite: a mutable CoW data structure that is extremely cheap to "fork" so that all subsequent updates occur only on the new "fork" and are invisible to the old "fork".
So it's like an elementary particle?
So, I don't judge, but sympathize with people who just "delete the repo and start from scratch". Unintuitive, user-hostile tools call for heavy-handed solutions.
IME, most people are willing to learn something when they're shown the value for invested effort. That "delete the repo" is standard answer for fixing f*up, tells more about the tool than the people using it. (I.e. it requires disproportionately big investment of time for little value.)
Until threads and async enter the scene.