denisw

Pretty sure that they wanted to write "this", typed something different by accident, and auto-correct struck.

What you linked to is WASI-libc, which is a C standard library implementation on top of WASI - which itself is more low-level and less POSIX-like. https://github.com/WebAssembly/WASI

There is RFC 3339, which is essentially “ISO 8601: The Good Parts” and, like all IETF RFCs, freely available: https://www.rfc-editor.org/rfc/rfc3339

In the German-speaking world, LovelyBooks [1] is quite popular. It seems to be strongly focused on fiction, though.

[1] https://www.lovelybooks.de/

This point was recognized quite early. there is an influential article by Jack W. Reeves from 1992 [1] that looks at the manufacturing analogy and argues that "the code is the design" whereas the "manufacturing" is just the compilation and packaging (that is, super cheap and automated). I believe it‘s this line of thinking that inspired Agile practices, where software developers are seen as engineers rather than code monkeys.

[1] https://www.developerdotstar.com/mag/articles/reeves_design....

Telegram has this built-in. The chat list contains an entry called "Saved Messages" that is basically a one-to-one chat with yourself.

To be clear, the difference is that an URI generally only allows you to refer to a resource ("Identifier"), whereas an URL also tells you where to find and access it ("Locator").

For instance, `https://example.com/foo` tells you that the resource can be accessed via the HTTPS protocol, at the server with the hostname example.com (on port 443), by asking it for the path `/foo`. It is hence an URL. On the other hand, `isbn:123456789012` precisely identifies a specific book, but gives you no information about how to locate it. Thus, it is just an URI, not an URL. (Every URL is also an URI, though.)

denisw.de

I started this to share various learnings from my dev work, as well thoughts on software engineering and architecture. The current two posts are on Redux, but I plan to publish posts on other topics (Kafka Streams, architecture, etc.) soon.

Link: https://denisw.de/

I recommend „Capital in the 21st Century“ by Thomas Pikkety, an economist who has deeply studied wealth and income equality using historical data spanning three centuries. This book has all the evidence you need.

https://www.amazon.com/-/de/dp/0674979850

Spoiler alert: income from wealth is on its way of becoming close to being as concentrated as it was in the 19th century (especially in the US), and the share of income from work in total national income is decreasing almost anywhere. So yes, increasingly you can only accrue significant wealth by already having significant wealth.

I really enjoyed the comparison of dependency injection with dynamic scoping, and the explanation of how the latter can take over the uses cases of the former with less boilerplate.

But one benefit of dependency injection unacknowledged in this article is that dependency injection is the explicitness of dependencies: the need to pass them in forces the caller to be aware of which dependencies exist, and changes in dependencies cannot be ignored (they lead to compilation errors in statically typed languages, at least).

Managing dependencies with dynamic variables, on the other hand, is implicit. It's impossible to know which parts of the dynamic environment are used by a module without inspecting its source code. And changes to the module's dependencies are not noticed by callers, which may lead to cases where tests fail to stub out particular side effects without anyone noticing.

Given this drawback, dependency injection still seems like the better trade-off to me, despite of its higher amount of required boilerplate. Perhaps it is possible to bring some of the explicitness to the dynamic scoping approach, though.

Yes, that's what I meant. The use of the term "API" for a single public code element is something I have not come across in any other language community, hence the clarification for those who are not familiar.

The crazy high numbers are due to a fairly Microsoft-specific definition of "API" in this context. What they count here is class members; so they ported a class with 15 methods and 3 properties, they'd count this as "18 APIs" (or perhaps 19 - not sure if the class itself counts as an "API" as well).

That being said, I'm sure there was indeed an impressive amount of code that had to be ported.

If you install the VS Code's C# extension, you should be getting autocomplete and quick fixes such as adding impport statements automatically.

https://code.visualstudio.com/docs/languages/csharp

Why should I build a model specifically for this one context of usage and have the properties tightly-coupled to their mutators, when I can completely decouple these things and have the models operate with any arbitrary state mutators?

Because otherwise, your domain model is not able to express which states are valid. A core idea behind encapsulation is that by controlling state mutations, it is possible to enforce invariants, thereby making invalid states impossible to construct. This idea is not unique to object orientation; for instance, in the static functional programming community, this is known as "making illegal state unrepresentable" [1].

By creating a "dumb" domain model and allowing business rule modules to do arbitrary mutations, each model is required to know about and enforce the domain model’s invariants itself, which dramatically increases the amount of code that potentially can break these invariants, and thus needs to be debugged if something goes wrong.

Taking this a step further, you can have a business model project (class library/Nuget) that is shared across multiple projects within an organization.

This can work in some situations, but there are good reasons not to do this. Different teams may have differing and sometimes conflicting meanings for some of the terms of the domain (especially for generic concepts such as "user") as well as different data needs depending on the use case. This is why for instance Eric Evans’ "Domain-Driven Design" [2] argues for limiting domain model unification to "bounded contexts" [3] of which there may be multiple in the organization, and have explicit translation ("anti-corruption“) layers between the boundaries of these contexts.

[1] https://fsharpforfunandprofit.com/posts/designing-with-types...

[2] https://www.goodreads.com/book/show/179133.Domain_Driven_Des...

[3] https://www.martinfowler.com/bliki/BoundedContext.html

I'd say many people actually reboot their phones frequently - every time they cannot or forget to charge in time and the phone goes black. :)

Consider the Mozilla Public License (MPL) [1]. It is copyleft in the sense that modifications to the library must be MPL-licensed as well, but doesn't impose any restrictions on apps merely using the library. This avoids the LGPL’s complicated re-linking requirements which are very hard to fulfill for iOS apps (as mentioned elsewhere in this thread).

[1] https://www.mozilla.org/en-US/MPL/

Variables alone are not a reason to use Sass anymore. There are CSS Custom Properties [1] now, which are even more powerful in that you can dynamically override them in specific sub-sections of the DOM. The only downside is that Internet Explorer 11 doesn't support them (if that's important for your target audience).

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/--*

Author of Redux Preboiled here.

This is an interesting idea! However, it's currently a bit difficult to define a value as completely readonly in TypeScript. See this GitHub issue:

https://github.com/Microsoft/TypeScript/issues/13923

Looking only at the commit numbers of the `atom/atom` repo is a bit misleading as the Atom source code as the core plugin packages (e.g., the language modes, but also fundamental features like the tree and the fuzzer) are each in their own repo. For instance, the fuzzy-finder repo alone had 15+ commits in the last three weeks.

From what I learned from digging into Pika/Pack a bit, I think you misrepresented it a bit.

- The standard typescript builder can only generate ES2018

That's true, but only because the compilation to previous ES versions is meant to be handled by other plugins. For instance, the "web" plugin [1] uses babel-preset-env, which in turn will take your package.json's "browserslist" [2] into account.

- The web bundler can only generate ES modules

The Pika project seems to be all about promoting ES modules, so it's no wonder that put this option to the forefront. However, there is also an UMD plugin [3] and a "node" (presumably Common.js) one [4].

[1] https://github.com/pikapkg/builders/tree/master/packages/plu... [2]: https://github.com/browserslist/browserslist [3]: https://github.com/pikapkg/builders/tree/master/packages/plu... [4]: https://github.com/pikapkg/builders/tree/master/packages/plu...

One important thing to note here is that this goes much further than `private` in TypeScript. The latter is purely a compile-time illusion. If you write `private x`, your objects' x property is still publically accessible and modifiable as far as the JS runtime is concerned. any other. It‘s just the TypeScript compiler that gives you an error if you access x, and only if it happens to have the type information it needs to do so (if the object ends up in an `any` variable, all bets are off).

This means TypeScript's "private" properties also shows up in the return value of Object.keys() etc. So it‘s a pretty leaky abstraction.

This proposal, on the other hand, tries to solve the much harder problem of of bringing true private instance variables to JS. This means making it impossible to access these variables from outside the project. To do this, they had to introduce a complete new "private namespace" that is different from the `this.<name>` one, because the latter is already reserved for the visible-to-everyone properties (messing with that would have serious compatibility implications). Hence the `#foo` syntax.

Taxonomies seem to be just as problematic in biology as in object-oriented programming. :)

It can be read as both an acronym for “Identity and Access Management” and as the phrase “I am”, which also happens to fit the topic of identity.

Object-Oriented Programming (OOP) is a programming paradigm where different components of a computer program are modeled after real-world objects.

This is a common, but dangerous way to introduce the object-oriented paradigm. While it is true that many object-oriented systems end up having a few classes that represent entities of its problem domain (such as, perhaps, bus stations in a public transport app), most of them do not. These other classes are abstract entities like data repositories, factories, controllers etc. that are meant to split software into understandable pieces with clear responsibilities that work together to make things happen.

The point is that this collaboration happens solely by these pieces sending each other messages (calling methods) that describe their intent, without needing to know how exactly the message is being processed. This style of communication is the key characteristic of object orientation, and even an introduction should probably put their focus on this aspect rather than „modeling the real world“, which isn‘t really something that is done this way in practice.

All this being said, I do see the appeal of the real-world rhetoric in that it seems much more approachable than ralking about little communicating abstract things. I wonder how to balance this.

That entirely depends on how “popular” is defined. If you mean “preferred choice for greenfield consumer and B2B apps”, then yes, C/C++ would be ranked way lower. But as far as I understand this statistic is based in search results, so it takes into account the huge body of existing software that needs maintenance (after all, you need to stay up-to-date and also look things up again from time to time), as well as domains in which C and C++ are a good still dominating, such as programming embedded devices.

Active Expressions seem to essentially be a more seamless and implicit form of Reactive Streams, such as those from the ReactiveX family of libraries [1]. For instance, the first example given by the paper is:

    var a = 5, b = 6;
    signal c = a + b; // c = 11
    
    a = 10; // c = 16

    var a = BehaviorSubject.createDefault(5);
    var b = BehaviorSubject.createDefault(6);
    var c = Observable.combineLatest(a, b, (x, y) -> x + y);

    // Read the last value emitted by stream `c`
    System.out.println(c.blockingFirst()); // 11
    
    // Save and emit 10 from stream `a`
    a.onNext(10);

    System.out.println(c.blockingFirst()); // 16

Also, when combined with shared-state concurrency, it might be hard to define and reason about which active expression runs in which thread. Reactive stream implementations have already tackled this issue with concepts such as schedulers [2].

[1] http://reactivex.io [2]: http://reactivex.io/RxJava/2.x/javadoc/

Stimulus is not bound to Rails in any way. It‘s just an NPM package which can be used whereever you have a JavaScript bundler setup (e.g., Webpack). I‘m not sure whether there is a build that can be embedded directly with a <script> tag.

To summarize, Flutter provides no automated or easy means to save/restore state when Android auto-kills the app (e.g. because of low memory). The main problem here is that the `onSaveInstanceState` and `onRestoreInstanceState` lifecycle callbacks require a synchronous response (return value) but the IPC system between Dart and native code is inherently asynchronous.

React Native currently has the very same problem. This is the reason why some very useful native components that require synchronous delegate callbacks (such as UITableView and UICollectionView from iOS) are not available from RN. However, the core team at Facebook is working on a "large re-architecture" that will allow synchronous calls into JS, fixing these issues:

https://facebook.github.io/react-native/blog/2018/06/14/stat...

I wrote that the Google Chrome engine was forked, and that Electron is using (not forking) it.

VS Code and Atom are based on Electron, which is a platform by GitHub using the Google Chrome browser engine, which was forked off Apple‘s WebKit engine, which was forked off KHTML from the KDE project.