sharpercoder

This boils down to code removeability. A few larger classes wit large methods is in general easier to remove/refactor then a large amount of small cohesive classes with an obtuse design concept behind it. Of all the codebases I refactored, I take the "large methods and large classes" hands down. Pulling a few classes here and there is easy, compared to first understanding a clusterf*ck of overengineered abstractions.

The quality of (any) mutable e-paper tablet will boil down to:

1. writing movement-to-pixel latency (should be around 5ms)

2. writing experience (tilting support, pressure levels, anti-aliasing, ...)

3. speed of apps on the device

4. shareability of annotations

5. "stroke-recognition" of diagrams, text, math formula's, etc

6. mashing of touch & pencil gestures

7. apps on the platform

I'd argue that only the Surface 4 solves (1) & (2) completely, with the competition between 75% and 90%. Speed (3) is a solved problem for mobile CPU/GPU/LED/OLED hardware, but e-paper is not close to 50%. (4) is also still quite young, since the "write on digital paper" thing is not even being used by enthusiasts (only some rarae niches show consistent use). (5) is mostly solved for handwriting recognition, and good progress is made on diagrams and math formula's. But it's young, and certainly not yet a commodity. (6) seems quite solved, as most algorithms to distinct between pencils and hand/finger touches work quite well. (7) is not yet solved, there are no good apps. Some exist, but they have "handwriting" as a feature, but not as a core feature.

Color may come in as 8th, but is for most digital authoring not that important. It would certainly increase the potential market for a good e-paper device, but would come last on above list.

In the past 15 years, progress on e-paper display technology has been slow but steady. Is the latency problem solved yet? Or are we still around 100ms?

I imagine autonomous bicycles using gyroscopes to stay stable, highly integrated camera's with environment comprehension (Waymo off-the-shelf chips) to redistribute them over the city at night.

Please just let me pay for not seeing ads.

One thing with reputation systems which is not accounted for I feel in many websites, is that higher reputation must translate to higher responsibility. It's nothing other then the good ol' "With power comes responsibility" adagium, also known reversed as "Power always corrupts".

In my humble opinion, there should be also a system that ensures increased power is applied correctly. SO does not have this, and that's a major problem.

They should be included, as it simply is a valid use-case which most likely will actually be used. However, there should be many more examples or good real-world use-cases. Lack of those concerns me.

The market should be able to handle this. Thus, the government should create the curcumstances this can occur, which means in practice that timeslot-based tarifs should be enabled.

"Headlines are still set by hand."

I now understand where the word "typesetting" comes from.

When discussing hydrogen cars, I particularly like the blog of Mux about this topic.

Part 1: https://ssj3gohan.tweakblogs.net/blog/11470/why-fuel-cell-ca...

Part 2: https://ssj3gohan.tweakblogs.net/blog/11493/why-fuel-cell-ca...

Part 3: https://ssj3gohan.tweakblogs.net/blog/11556/why-fuel-cell-ca...

Part 4: https://ssj3gohan.tweakblogs.net/blog/11572/why-fuel-cell-ca...

I'd like to be able to specify restrictions on type usage in Javascript. For instance, in some cases I know that my array will always be 6 items larges - no smaller, no larger, never sparse. But I can't specify this, yet it allows for certain optimizations (e.g. loop unrolling).

Lately I was memory profiling an application in Javascript using Chrome. The fact that it used ES6 classes really helped, as some anonymous classes where hard to find memory leaks with, but the typed classes was a simple text query.

I can imagine ES6 classes with decorators may enable specialized optimizations too.

I hope to see a pluggable markdown editor sometime. Pluggable in the sense that the syntax (lexer & parser) are highly configurable and can cater to the needs of the domain. Because in effect most websites, documents, et cetera 1) use a certain flavor of markdown and 2) have extensions.

It would be nice to be able to configure a certain syntax and then have the editor be aware of that syntax. Most editors out there currently only work with a fixed syntax or a fixed set of syntaxes.

A cent is a minor currency unit; think procent, aka hundred in latin, or used in common international form one-hundreth.

We don't need both. 10 toasters is more then enough to fulfill our needs.

I guess the culture around a language matters significantly. For instance, there is quite a specific culture around the Rust community/language. The focus on the language ergonomics is also reflected in many packages. Same goes for the mutability/immutability aspect of code.

A second example of this culture is the go language. I read a few repo's, and the same style of programming is seemingly applied throughout.

For the Java case, I can actually see operator overloading going haywaire over many codebases. The same as overengineering is a typical trait associated with Java.

> [...] A good programmer builds a working vocabulary. A good programmer does language design, [...]

You see this more and more in "test languages" like cucumber. These languages more explicitly allow programmers to specify domain items and behavior, much more so then general programming languages like Jav, C#, js, etc. I'm currently experimenting with a piece of software that actually does have a specific domain language defined using ANTLR. I'm totally unsure of this will make any sense, but at least it is fun to do. One benefit I can see already is that I now have fully typed & typechecked logging :). Another aspect I'm experimenting with is using it as a replacement for sais "test languages".

You can find my grammar here: https://github.com/generateui/jsettlers-web/blob/master/jset...

All items are equal to the second sequence. Which means, no items in "items". I could have picked a better example :P

With many languages adopting LINQ object querying, I find it more and more suitable to start using math's set operators for them. Many languages have almost identical behavioral sequence operators (.find in js, .Where in C#, etc) but math sort-of standardizes them all with a sound theoretical background. I'm not entirely sure if they all map 1-to-1, but at least most will.

    const items = ∅; // empty set
    if (myItem ∈ items) { ... } // is element of
    const union = items ∪ otherSet;
    assert items ≌ ∅; // items are all equal

Seems entirely reasonable; using a nuclear reactor to pump vast amounts of air into the water. While you can have high volume, it is restricted to a relatively small area only. To have noticeable impact on agricultural runoff, we need similar devices in river delta's. They can probably be less powerful; simple windmills probably could have a local measurable impact already.

NYT seems remote friendly, but is NYT remote non-US friendly? Front-end/Full-stack engineer from The Netherlands here.

Typically, I would agree. Yet, I'm fairly certain Google has good reason for doing so.

You assume that you need to tag manually. You assume that you are forced to do so. Currently, it's perfectly possible to put all files in a single folder. Your OS will be happy about that (except maybe some technical limitation of max filecount of a folder).

& , & . 🡒 & = & < ️.

HN apparently does not support unicode: https://imgur.com/a/Px2z5

Google Desktop was indeed a great solution partially solving the tag problem in Windows. A good tagging system trumps search as you can make the results much better determinate. The ability to create your own namespace and then organize every file into that namespace ensures encapsulation. In a search result, you almost always have to filter out irrelevant items.

Good working search solves the problem pragmatically though :)

A way to see folders & tags is to treat folders as tags but with the property that items may only be of one folder. The same happens in biology where scientists try to classify animals into one folder; a cat is put into the mammals folder (which has multiple hierarchies of subfolders). Instead, this classification system may be much more effective if it is classified as tags instead, where items may belong to multiple folders (or categories). This solves problems like the platypus, which belongs to multiple "biological folders".

It seems that humans have a hard time reasoning with the tag concept. I'm not sure where this comes from; is it decades of working with the folder/subfolder idiom in Windows, where most people are grown up with? Is it the resemblance of the physical world where we also put documents into one folder and one folder only? Or is it our intuition to simplify matters, and therefore seemingly make things simpler to uniquely have items belong to one container? I don't know; most likely, it's all the reasons above plus a few that I didn't mention.

This is strange, considering the competition going on in this industry.

This would be a useful feature for any programming font. I can totally imagine writing exploits through zero-width characters; smart insertion into interpreted strings (scanners/parsers) can potentially insert a security leak by an attacker. Though input can come from many places off course, this would at least make one vector visible.

In America, I predict society to realize they need much less roads. It's much better to have less but much better quality roads.

I'm unsure of how this change will get traction. I suspect states will eventually explain their infra budget cuts.

Societies (and therefore roadsystems) will adapt, because speed and safety. Roads will be changed to cater to the needs of self-driving cars; smart traffic lights, clear lining, clear signage, less leveled intersections, dedicated lanes, I can think of dozens more changes which make it easier and safer and more deterministic for computers to drive cars.

Development of these changes will be spurred once self-driving cars can make more efficient use of the road; the immense pressure of society to get rid of traffic jams will make sure of that.

Maybe some nations won't implement these things nationwide with 100% coverage, but they certainly will implement changes for certain roads. Highway roads first, then collector roads, and lastly neighborhood roads.

Google translate: https://translate.google.nl/translate?sl=auto&tl=en&js=y&pre...

Like MineCraft, this is a great world-building game. I'd like to see OpenTTD as the 2D variant of MineCraft - or vice versa.

Anyone who wants to conquer the VR world should build a world-building game and build a lasting community around it.