JavaScript so-called modules are the worst thing I've ever seen, because the resolution strategies are all really horribly bad ux, and because people continue to multiply the insanity seemingly every 6 months with some new slightly different approach to it all (systemjs vs. node vs. amd vs. etc.; webpack vs. babel vs. etc.) and then enough people seem to get on board with each insane little thing so that we end up with a nightmare of half-assed explanations about any given one, lots of hand waving, and me just getting nowhere. All I bloody wanted to do was spend 15 minutes actually writing code that freaking did something, but instead I am still dead in the water because of this utter insanity. Dust off and nuke the place from orbit, it's the only way to be sure!

Modules and namespaces and all that stuff in Typescript is a complete train wreck. I guess the JavaScript ecosystem is like 80% to blame for it, but Typescript does nothing that I can see to actually sanitize it so that there's any concise, good, rhyme or reason to it all. What a crock of junk the entire JavaScript ecosystem is. You can't put lipstick on a crock of poo and get anything other than poo wearing lipstick. I am hitting some weird compiler thing where adding imports breaks some code that was working fine. Looking in the Typescript issues shows at least a zillion things that are apparently wrong, or at least confusing, about the whole thing. Like: oh my freakin' g*d.

I guess I have never once used an online job (either as employer or employee) search site that wasn't a prime example of just about everything that is wrong with technology. (Probably Craigslist comes the closest to being minimally broken, but it suffers from not having as much posted on it?) It just seems all mind-bogglingly hilariously train-wreck-esque, in a comedic ouroboros technology-will-eat-itself kind of insanity. An insanity of technical emperor types with no actual clothing on. "I know! I'll start a startup to solve the problem of matching candidates with jobs!" Now you have, like, seven problems.

uh. yeah. Zelda? is good game design?! wtf? yeah, i really like still not knowing wtf i am supposed to do w/out looking it up online in a freaking walkthrough. i also like being stuck on a giant tall thing set up for me to keep falling off of so i die over and over. yeah. fun.

I know why we can't have nice things: Because "PC" architecture has led to small, slow, narrow buses, in theory compensated for by ever larger cached memories. What a crock of crap. Console architectures are so much more sane. Why should I have to fork out 2x the $$$ and waste 2x+ the electrons to shuffle things from main CPU RAM to GPU RAM (and sometimes back again)? It freaking kills me that drawing a freaking line is freaking rocket science now. Let alone if you want to draw a lot of them, and animate them.

you cannot escape from, or paper over, or gild, the crap. the crap is crap, and you are doomed. what a freaking nightmare.

The thing in google where I click on something to read the hit and then hit the back button because it didn't have what i wanted and then google decides to refresh the bloody page and insert 'related' stuff so that my next click isn't on the next item down that was originally there but ends up being a click on some 'related' thing to the thing i didn't like... yeah, that's obviously patentable. "Pissing Off Users With Really Stupid UI So-Called Features."

I understand that PLT (programming language theory) is hard, that syntax is hard, that making a programming language that doesn't suck is truly really hard.

but.

but, I find it depressing that so many languages seem to be designed to make things I think are important and wish were easy, really hard.

To wit, so far it looks to me like Typescript (a) doesn't have mixins or delegation, and (b) requires the use of 'this' all the time. So I end up with "this.hasa.field" type verbosity all over the place. I guess I could reduce it by making lots of property accessor wrappers on "this" to turn it into "this.hfield" or something, but all in all I shake my fist at the sky and at Hejlsberg.

(no, I am not smart enough to make a good language. just whiny enough to point out that everything kind of sucks.)

(The same sort of thing happens to me in Java whenever I try to do anything other than vanilla missionary position type Java class based OO inheritance crap. Maybe it has gotten somehow less stick-in-the-eye horrible over time, does Java have polymorphic 'this' now or something like that, so that even just trying to write Factories instead of using new() actually isn't a living hell?)

How to utterly destroy any interest I have in your, seemingly otherwise kinda cool, programming language: require 'this' everywhere.

It drives me nuts when programming languages have More Than One Way To Do It for things that should by now be kinda I wish I'd hope freaking standard, freaking figured out.

To wit, mixins in Typescript. I mean, ff'ss, a supposedly 'modern' language that utterly fails to have either mixins or has-a-delegation?

Oh my freakin' god and I really hate it when people are either just ignorant, or clueless, or just have no good taste what-so-ever, and run around claiming, "oh sure Typescript has had mixins since 2.2" which if you ask me is watery bull excrement.

(Or see just about anything in JavaScript. Or anything that uses a macro in Haxe. Or any language that doesn't have a 'newtype' equivalent. Or enums. Or first order lambdas. Or any number of things that should be bloody de rigeur by now. Yes, PLT is really hard, I know, I know.)

The fact that cars do not already always know what-all service has been done to them is kind of lame. In this "future".

Most programming is still ad-hoc. Even if somebody has an "architecture" for a project, chances are there's still a zillion things that aren't remotely statically checked.

What can/not be? depends on many things of course, but I wish there were a table, chart, venn diagram, whitepaper, or something that listed the ideas of what bugs can be statically checked. What if Maslov wrote about the hierarchy of needs of good computer systems? What if we start with non-turing completeness and see what we can assure, and then see what options we have if we start to 'fall back' into the turing mud pit.

Things I'd hope for; things that tend to be buggy:

+ order of operations.

+ type mismatches.

+ null.

+ over/under flow.

+ collection bounds checking.

+ concurrency: races, deadlock, livelock, determinacy.

+ performance.

+ security.

+ extensibility, eg algebraic compositional properties.

+ support for aspect oriented, cross-cutting concerns.

+ end-to-end data models.

+ versioning of any/everything.

+ cross-platform-ness.

+ reusability, or at least fuzzy logic copy-paste code detection.