monfera (u/monfera) - Readit News

monfera commented on TS to JSDoc Conversion github.com/sveltejs/svelt... · Posted by u/ajhenrydev

_gruntled · 3 years ago

> It's also a really contrarian viewpoint about typescript which is really popular.

I really, really don't get the controversy here. JSDoc _is_ TypeScript, just with a syntax that's valid JavaScript (on account of it living in comments). This means it doesn't have to be built to run, but still gets all of the typing goodies regular TypeScript does. The end-user code authoring experience is the same or better.

> To completely switch over to js and then set types that way seems regressive.

"It's regressive to use a fully-JS TypeScript syntax instead of using dozens of tools on top of regular TypeScript to achieve the same outcome" is quite a spicy take.

monfera · 3 years ago

> JSDoc _is_ TypeScript

This is surprisingly true in a way. TypeScript is not a language(1), it's primarily a linter-assisting overlay atop of an actual language, JavaScript. Also, there's a linter that outputs and bundles JS, shedding the alien type annotations and also injecting its own, very partial runtime.

So, JSDoc is just a linter/documenter aid. And so is TypeScript.

(1) TS is not a language: it has no spec, no reference documentation. It defines no behaviors, in particular, no runtime behaviors. It sits atop of various JS versions, layering over them in unspecified ways. TS is a linting layer, and also is a hack.

monfera commented on Your Computer Isn't Yours sneak.berlin/20201112/you... · Posted by u/sneak

orestarod · 5 years ago

It was always a tiny minority of the general population that had real knowledge and capabilities of creating the actual technological equipment widely used by the said general population. In the same vein, there are no less people capable of low/OS level programming than before, and you can't expect every proficient user, even a power user or e.g. the now numerous web developers, to be at this level of ability.

monfera · 5 years ago

What changed is that the very things capable of eliciting interest in programming also offer overpowering content consumption functions with huge, never ending catalogs of games, movies, videos, short funny clips etc.

As computing and "content" proliferate, the uncompetitiveness of creation, esp. symbolic creation such as programming, is increasing. At some point, broadening of the access no longer offsets this effect, and the talent pool may start to shrink even if capability and permeation is a million times higher than it was.

monfera commented on Why Love Generative Art? artnome.com/news/2018/8/8... · Posted by u/Artnome

codingdave · 8 years ago

> The problem with generative art is not that it isn’t considered art by everyone.

Abstract Art in general isn't considered "Art" by everyone, especially in the days of Abstract Expressionism and Jackson Pollack. While I do appreciate the thoughts around generative art, these discussions are not new. But it is a new generation using new tools, re-discovering the arguments from the mid 20th century.

The question isn't whether it is art, or whether other people think it is art. The question is why do those questions matter to you (the generic you, not OP or any specific commenter) as an artist. Are you doing it to get validation from others? Are you doing it to sell the work to others? Or do you have your own reasons for your work, aside from the opinions of others?

For me, art is about self expression and self exploration. If other people call it "art", great. If they buy my work, even better. But I'll do my work, either way.

monfera · 8 years ago

Good points. A minor thing, generative art isn't necessarily abstract art, though currently almost exclusively is. (Oh and spelled Pollock.) Regarding validation, it might not matter for some, but might for others. I'm sure there were quite a few great artists who wouldn't have done their art at the same level had there not been validation as art. Something more mundane, recognition is likely a big factor in whether patrons seek out and are willing to pay for generative art. So it can matter even for those who aren't looking for the ego lifting part.

monfera commented on Intel Responds to Security Research Findings newsroom.intel.com/news/i... · Posted by u/runesoerensen

bjornedstrom · 8 years ago

This is probably one of the poorest and most defensive PR pieces I've read from a company in a long time, and it does not really make me sympathetic to them at all.

> Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operating as designed. Intel believes these exploits do not have the potential to corrupt, modify or delete data.

This is deceptive. It very quickly acknowledge the confidentiality aspect, but then claims that is "operating as designed" and then immediacy try to damage control by pointing out what the exploits cannot do (corrupt/modify/delete).

> Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.

This is deceptive. In the first sentence it combines two statements: 1) bug/flaw in Intel products and 2) that it is unique to Intel. In the rest of the paragraph it then claims that the previous statements are incorrect, but only addressing the second point.

> Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively. Intel has begun providing software and firmware updates to mitigate these exploits. Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time.

This is deceptive. It immediately mentions AMD to give the impression that AMD also suffer from the problem.

It then goes on with a straw man about performance impacts ("contrary to some reports").

And then mentions "average computer user" whereas the real problem is obviously not average computer users. Again, deceptive.

monfera · 8 years ago

In the case of asymmetric competition, a company with vastly more resources might curate a list of undisclosed problems with competitors' products, for when a major event like this strikes, they can drag along the underdogs. The optics are different if 1) the dominant player can pretend it's "working together" with the other vendors, 2) the dominant player condescendingly points out mildly related issues in competitors' product, and 3) the name of the alternatives keeps getting linked in a "we're in the same boat" way.

I'm not suggesting this is the case here at all, as it's unlikely that Intel identified this precise issue with AMD long ago and haven't checked their own vulnerability (though there's always a chance that an issue is found by company A when analyzing the strengths and weaknesses of company B's products, which then turns out to apply for their own products too). But I wouldn't be surprised if somehow there were some loosely related AMD issues that came to light now, and it's impossible to tell if those would be current finds or older ones.

Given Intel's dominant position, they may come out ahead in P&L or gross margin terms even if it turns out to be a clearly Intel issue, as the perceived or real loss of performance may trigger an upgrade spree, sold unit counts inevitably dominated by Intel purchases.

AMD has just started to catch up in overall performance, and in the worst case bug impact to Intel, they may even get competitive single-threaded performance. Also, there has been speculation that Apple has been evaluating ARM processors for some future laptops, and a sudden drop of the baseline is an interesting turn of events.

While this in theory benefits the underdogs, financially Intel may well come out ahead due to their market hegemony.

monfera commented on The web at maximum FPS: How WebRender gets rid of jank hacks.mozilla.org/2017/10... · Posted by u/bpierre

pcwalton · 8 years ago

If only it were as simple as just using Loop-Blinn. :) The technique described there will produce unacceptably bad antialiasing for body text. Loop-Blinn is fine if you want fast rendering with medium quality antialiasing, though. (Incidentally, it's better to just use supersampling or MLAA-style antialiasing with Loop-Blinn and not try to do the fancy shader-based AA described in that article.)

Additionally, the original Loop-Blinn technique uses a constrained Delaunay triangulation to produce the mesh, which is too expensive (O(n^3) IIRC) to compute in real time. You need a faster technique, which is really tricky because it has to preserve curves (splitting when convex hulls intersect) and deal with self-intersection. Most of the work in Pathfinder 2 has gone into optimizing this step. In practice people usually use the stencil buffer to compute the fill rule, which hurts performance as it effectively computes the winding number from scratch for each pixel.

The good news is that it's quite possible to render glyphs quickly and with excellent antialiasing on the GPU using other techniques. There's lots of miscellaneous engineering work to do, but I'm pretty confident in Pathfinder's approach these days.

monfera · 8 years ago

> Loop-Blinn is fine if you want fast rendering with medium quality antialiasing

For example, when using SVG shape-rendering: optimizeSpeed ? I truly hope that SVG is going to be part of this new magic, and that the shape-rendering presentation attribute is utilized. I don't think current SVG implementations get much of a speed boost by optimizeSpeed.

Speaking of which, to what extent will SVG benefit from this massive rewrite?

monfera commented on The Zen of Just Writing CSS svelte.technology/blog/th... · Posted by u/rich_harris

NathanCH · 9 years ago

Anyone who dismisses BEM because of the syntax is missing the point of BEM entirely.

monfera · 9 years ago

I think there are other reasons for dismissing BEM, it's quite an opinionated and shallow structuring, good for some stuff and not for others. Very HTML tag oriented, for which we have, well, HTML tags already. Its claims are simply not true (eg. "Reduces style conflicts by keeping CSS specificity to a minimum level."). Even in syntax, it saves on silly things (".btn"?) and wastes much more on, in effect, introducing Hungarian notation to CSS. I could go on but no time rn

monfera commented on The Zen of Just Writing CSS svelte.technology/blog/th... · Posted by u/rich_harris

inglor · 9 years ago

Worth mentioning that CSS-in-JS _and_ CSS-in-CSS hot reload in any modern build system anyway. So using workspaces used to be super useful but it's not a big selling point any more.

monfera · 9 years ago

I'd agree with it were it not for the huge difference between the view refresh latencies. Within the browser, it's near-intantaneous. Hot module reloading (which is still experimental) is relatively fast, yet there's a couple of seconds of a trip; also depends on what and how changes. Full page reload can take even longer, there's compilation time, bundling and the unavoidable cost of reloading stuff in the browser. Sure a couple of seconds doesn't sound bad but it's still a couple of seconds longer than what it should be (immediate) and it breaks my (work)flow.

monfera commented on The Zen of Just Writing CSS svelte.technology/blog/th... · Posted by u/rich_harris

monfera · 9 years ago

Just adding it here as well: if one likes editing CSS files in Chrome Dev Tools, then activating Workspaces will save such changes into the source file. This Dev Tools integration with the Svelte approach is so useful that it might actually tilt the choice in favor of CSS files over the more abstract, thus Chrome-uneditable CSS-in-JS (Workspaces are doable with SASS too as per https://www.amazeelabs.com/en/How-to-write-Sass-within-Chrom...).

monfera commented on The Zen of Just Writing CSS svelte.technology/blog/th... · Posted by u/rich_harris

dlbucci · 9 years ago

I like the simplicity provided by scoped CSS, and I tend to name classes in a way that essentially accomplishes scoping. However, there's this nagging feeling at the back of my mind that if every component in your app has its own stylesheet, your style is maybe not consistent? It just seems like the ideal website with a consistent and good UI design should be able to have a single stylesheet (probably written in Stylus/SASS). I don't know if this ever happens in practice, but it's just something I think about.

Less on-topic, I feel like the title of this article is wrong: you're not "Just Writing CSS" if you're writing scoped CSS, which requires some sort of build system.

monfera · 9 years ago

An example may be, graphic designer shop gets a contract to update the company 'style guide'. It gets done and there are a lot changes that are cross-cutting w.r.t. components, starting with fonts, borders, margins, border styling etc.

Also, what's not fully clear to me, what if - as usually is the case - the components are nested? Changing eg. font in the outer component would leave inner components fully intact?

A side note, I'm wondering how the Svelte approach relates to `isolation` in cycle.js https://github.com/cyclejs/cyclejs/issues/259 -