sharpercoder

A display with >10ms response times for writing does not cut it for me. I love the product, but this is something I can't compromise on. I really hope this problem on e-ink screens gets solved!

So where can I buy a ticket to ride?

The promise of Rust is safe and fast low-level development. What is the primary selling point of using rust for webdev? Speed? I can mainly see disadvantages when using rust for this scenario.

Can we somehow start to use the ascii 30 character aka the Record Separator (SP)? This would solve a lot of the problems!

One, two, three, four, five, six, seven, eight, nine, ten, eleven, twelve... they're unique names. Then comes thirten, fourten.

Ten, eleven and twelve are unique names and probably have their entymology derived from a base-12 numbering system once primarily used in Anglo-speaking countries.

Try the hard server. Games end in 10 years on average. You end bu getting 50M, which makes it a lot of fun to play. To play competitively, you have to manage your economy the first 5 years really tight.

This is a more scalable solution then the Spectacle solution (record both hori- and vertical). I wonder if filmmakers will adapt their filming to cater to this algo - i.e. having a bigger margin to the edge in order to have AutoFlip give even better results.

It means your taxes will go up and thw city has lost oportunity cost. That seems to me as a bad thing. You'd want the right amount of infra.

I have done extensive testing and review reading. You have two options: sony xm3 or bose 700.

My experience is that using Argan oil right after climbing solves this for the next day. The combination of a nights rest and Argan oil almost always does the trick. The times it did not work was when I had a more serious skin injury.

As a developer and systems architect, I really like this. As uset, I hate this so much. On slower connections, I like to load a page, swap tabs, come back later and expect the page to be loaded. This mechanism will now break (and is already brokrn by the usr of these lazy loading libs).

You seem to assume that the passed-in object should also be used as the resulting object. This is false, as they can be decoupled.

In other words, it's still possible to pass in a separate js object instance containing the configuration.

Yet I'm not sure about the whole of your arguments, so I can't tell if it would actually make sense to wrap the default js builder pattern implementation (the javascript object initializer syntax aaaaaaaaaaab refers to).

However, I do method builders often overused in API's where a simple singular builder method combined with builder classes suffice and simplify.

But is the increasing complexity (an interpreter added to the codebase) not introducing also another - new - attack vector?

From a usability perspective, "sketchy" or "cartoony" charts actually serve a purpose. To me, they communicate "the trend is important here, not the precise numbers". This can more acurately convey communication intent as opposed to a precise rendered graph.

Your page is not only awesome in creating my Catan clone, but also very useful when communicating on it with others. You have set the gold standard or the defacto standard.

If you're interested in my implementation: https://github.com/generateui/jsettlers-web/blob/master/src/... https://github.com/generateui/jsettlers-web/blob/master/src/... https://github.com/generateui/jsettlers-web/blob/master/src/... https://github.com/generateui/jsettlers-web/blob/master/src/...

A hex has a coord. A coord has 6 nodes and 6 edges. An Edge can be created from 2 coords or 2 nodes. A node can be created from 3 edges or 3 coords. The implementation is immutable and memoized.

The same is so true for programming, in particular OOP. In my experience, code is much easier to change when a loosely coupled set of interfaces is built as opposed to an hierarchy of classes.

True, but the current state of tooling does not allow for these kind of changes in most published public API's. Even now where e.g. the .NET Roslyn API allows for this, I don;t see it happen often.

These language features build using the type system are useful, except when you're using them in your API. In that case, they break down as changing the API becomes problematic. A simple example is to change a `void derp(Nullable<SomeType> parameter)` into `void derp(SomeType parameter)`. This is a breaking change, while on the consumer side it is not a breaking change.

In my experience, this discussion gets convoluted by confusing modularity with monorepo. They are orthogonal to each other; you can have a very modular codebase in a monorepo but also a very coupled (non-modular) codebase with polyrepo.

Though it's true that monorepos without proper discipline can tend towards coupling. Yet, when discussing mono vs poly, we should keep this in mind.

I have installed doxygen on a handful of projects. In hindsight, it was a waste of time. No one reads generated codedoc, yet everyone just read the code.

Doxygen should be replaced with rendered comments in IDEs/code editors. That's the real solution.

I suspect there's actually quite a market to develop such UI for. Given a service that standardizes UI over a wide array of applications (web apps, mobile apps, desktop apps), I bet there's a large enough market for it.

Implementation would be interesting and most likely quite hard to achieve, though.

If you need lexicographically sortable uuids, you have a very different problem.

Since I presume these asm-compiled .NET BCL binaries are largely immutable, I think they can be cached aggressively. This means that the initial cost of downloading them may be high, but it browsers would support some kind of hashed asm library caching, this cost would be mostly one-off actions.

I'm very fond of small, specific and simple languages without sacrificing inherent complexity. For me, that includes IP adresses, UUIDs, timestamps, URIs, println formatting, et cetera.

It's a shame though that we don't represent them as such in the current state of affairs but choose to implement them separately in every language. Can we have a fast, universal, feature complete parser generator that is natively supported in our mainstream languages?

For instance, think adding an ANTLR grammar into a .NET project and then be able to just do `var ipAddress = ip"127.0.0.1";` and get full editor support with that.

Yet `Maybe<T> | Option<T> | ...` is not an option (pun intended), as Rich Hickey explains here: https://www.youtube.com/watch?v=YR5WdGrpoug.

In effect, his argument is: 1) You have `public X Do(Y y)` changed into `public X Do(Option<Y> y)`. This will break your API. 2) You have `public X Do(Y y)` changed into `Option<X> Do(Y y)`. This will break your API.

Thus, do not use Option<T> or equivalent in your API's. Only use a language-supported construct such as C#8's upcoming `string?` and `string`.

Human languages are also forgiving on the receiving side which is not true for computer languages. 1 wrong character and yiu get an error. This is an important difference when discovering and even using it,l.

With a language, it is far more important. In a gui I can just click around and see. With tuis, I need to enter a command and hope it is the right syntax.

But most commandline languages are inconsistent, have inconsistent abbreviations, have inconsistent command parameter naming/defaults, contain acronyms of incomprehensible words, have plain weird names, contain inconsistent or outright incorrect documentation...

A language to do stuff is actually a great thiing, especially if it can produce readable and reproducable objects (programs). However, I get really scared looking to most commandline scripts. It's an incomprehensible mess people only can start to grok after years of experience with the particualr commandline tool.

I hate non-discoverable UI's. The first thing I do with any software, is click through all possible menu's, windows, ribbons, whatever. After some time, I usually get quite a grasp on what the software is capable of. The two notable exceptions are textbased UI's (terminals, dsls, ...) and softwar requiring domain specific knowledge (e.g. geomodeling software, specific 3D modeling software, ...).

I never understood the appeal for terminals. Often (Microsoft's Powershell is a notable exception) the syntax is full of incomprehensible abbreviations, the syntax is wildly inconsistent, the syntax contains hard to remember acronyms...

No, for me, terminals and most textbased interfaces will never be as usable as GUIs.

Fun story. I bought a very fuel efficient diesel car (build: 2001) 3 years ago. It does 94 mpg or 1L per 30KM. Since then, many cities in my country decided to introduce "pollution zones", banning diesels of 2000 and older. My old home city decided to go one step further and ban diesels of 2004 and older. When I visit family and friends, I actually have to actively route around it. Which is ironic, since my car is more fuel efficient then most cars currently produced. But I guess the NOx exhaust also matters (which is much higher with diesels).

To be frank, it surprises me that I can go around in my car still at all. Burning diesel to move people should be banned by now, especially with the market flooding with EVs.