krilnon's comments

Glad to see this showing up every few years. After its initial launch, I think I helped the creator add the localization and lightspeed features: https://joshworth.com/updates-to-the-solar-system-map/

...and we eventually met up and had lunch.

Awesome! It's surreal to see a familiar name making such a neat app. I saw this earlier today and had a small moment of triumph since I'm terrible at solving sudokus myself. A few people visit kF every once and a while; feel free to stop by!

Are you the same yeldarb as the one from kirupaForum?

It's documented. I used to be very fluent in the AS3LR, and I found it in a minute or two here: http://help.adobe.com/en_US/FlashPlatform/reference/actionsc...

The formal language specification came fairly late in AS3's useful life, but it also describes the syntax: http://help.adobe.com/livedocs/specs/actionscript/3/as3_spec...

VoiceOver: yes, as reported in this article: http://mashable.com/2016/07/10/apple-innovation-blind-engine...

> [Jordyn Castor] was a driving force behind accessibility on Apple's soon-to-be released Swift Playgrounds, an intro-to-coding program geared toward children. She's been working to make the program accessible to blind children, who have been waiting a long time for the tool, she says.

I'm excited to see that Alex Warth is involved with this. In my late undergrad days, I was really excited by his OMeta language. It turned out that I'm actually really bad at writing PEGs (or even ANTLR grammars), so I wasn't the best candidate for advancing OMeta into common use, but the idea is really compelling.

There was a funny discussion on an MIT mailing list this summer when an (apparently) tone-deaf email was sent out by MIT Professional Education entitled "4 Ways You May Be Enabling Hackers"... which warned about the dangers of cybersecurity-style hackers.

RMS's response was:

> These MIT professors ought to know better than to smear us hackers by using the word "hacker" as synonymous with "security breaker".

Writing valid XHTML was good practice for writing valid XSLT. Browsers would definitely choke on invalid XSL. I remember spending a fair amount of time looking at that pale yellow Firefox error screen that would point out invalid XML documents during my XSL days.

It's been a while, so I'm not completely sure this is true, but I think any XHTML within an XSL document also had to be valid XML (that would also validate against the XHTML schema), so you couldn't get away with as much as you could with rendering a plain XHTML page.

There's an official specification for what and how a program that claims to be a JVM implementation should operate given Java bytecode. So someone writing a language that compiles to Java bytecode would typically either target the specification (and test on as many implementations as they felt necessary), or target a specific implementation like HotSpot and ignore the rest.

From the article:

> I have a working prototype of a JavaScript VM that is highly optimized for NGINX’s unique requirements and we’ve begun the task of embedding it within NGINX Open Source.

> I wrote the sorting algorithm in as3isolib

Oh neat. I don't recognize your username, but I submitted the first entry in the logo contest for that library in 2008, which ended up being fairly close to the final logo.

> Flash is certainly alive and well.

There's plenty of developer activity, but I'm pretty sure Adobe only has a life support team maintaining most things now.

AS4 was cancelled, so Falcon was the last notable language change. Most of the AoT iOS/Android targeting stuff was completed years ago, so now AFAICT it's just being kept compatible with new releases.

FP12 was supposed to be a huge jump, but now 12-17 (and the accompanying AIR APIs) have come and gone without pushing things forward meaningfully.

You're right about Fireworks. Some people do like to use the Flash authoring environment for general web graphic work, even though that's not its primary intent. A friend of mine still uses it for all of his web tutorials and book diagrams. (Flash has tools for exporting single frames in a variety of image/vector formats.)

You're right to point out the cultural divide w.r.t. tooling. It just seems to me that when two different people come up with pretty identical names for something and focus an essay/paper on that name, then there's likely an opportunity for some sort of cross-pollination of ideas.

Ah, great; thanks for pointing out that it has changed. The last time I looked at Rust in detail was mid-April, so I hadn't seen that.

The author's term "anti-sloppy programming" immediately brought to mind a former colleague's paper, aptly-titled "Sloppy Programming" [1]. Interestingly, Rust is a programming language, while this paper describes an editor/IDE enhancement to turn natural language style input into ASTs.

This suggests to me that the most anti-sloppy languages like Rust would benefit the most from sloppy input inference techniques. Has anyone been working on developer tools to make writing Rust code easier? (Lifetime management is the obvious new language feature to target.)

[1] http://groups.csail.mit.edu/uid/other-pubs/sloppy-programmin... (pdf), or less-detailed: http://groups.csail.mit.edu/uid/projects/keyword-commands/in...

> You'd expect the artist(s) of the record to get my $12 minus a service fee, but what I'm sure happens is the artist(s) only get the price per play x 3 and Spotify pocket the rest.

I think companies like Spotify end up spending 60-70% of that $12 on paying license fees, which include per-play amounts that eventually end up with the artists. And the structure of those deals is such that the groups with the biggest licensing deals get most of your $12, even if you didn't listen to music from that particular artist.

I agree that it's not what you (or I) want, but it does make sense from the perspective of the largest parties involved in these negotiations.

Might you go back when ES6 is widely supported by browsers / Node? I don't mind either way, but since the parent comment mentioned that arrow functions were coming to JS, it was interesting that you specifically said 'never', rather than 'until ES6'.

> you begin to learn it is all just posturing

Yeah, I think that's probably the most common motivation behind the interaction spotlighted in the article.

> Here's a sample interaction between an experienced programmer and a beginner who is just learning programming

I think the interaction happens between programmers of all levels of experience, but it might be most harmful when it's an experienced programmer talking to a beginner.

> It does get discouraging as a noobie when you hear people in forums throwing around the latest tech jargon and some esoteric C library just to show-off how much they know more than you.

If that's really their intent and if you (the noobie) are the one they're talking to, then sure. If I'm a noob walking deep into a HN thread on an esoteric C library, I'm probably not going to be discouraged that people are using jargon, unless I've identified myself as a beginner and the comments are replies to mine.

> They also made the mistake of showing a link that includes the word "Typography"

Including some aesthetics-stretching cases seems like a fairly honest/transparent thing to do for an open-source project that someone is blogging about.

> It breaks the semantics of what the underline means — any bit that's underlined is supposed to be the link, and if it's not underlined it's not a link.

That's a reasonable way to look at it, but humans like us can be pretty flexible with semantics, thanks to pragmatics. If I see a link that covers most of a set of letters stuck together without a space, I tend to assume that the whole thing is a click target. Even if my assumption is wrong, my clicking error rate probably won't be too high, since I think that people tend not to hit the edges of pointing task targets.

Nah, it's real. Adobe had a WebGL competitor, Stage3D, at the time, but I didn't work on that at all. As an intern, I would run a few useful benchmarks per day, but it was more reliable to run things I knew would heat up a laptop instantly, so I used WebGL demos.

Brownie-wise, I would wait a while because lunch would fill me up. But at 3 or 4 pm, I'd be hungry again and something the size of a brownie would really hit the spot.