SomeCallMeTim

It's actually worse than you're saying.

NoSQL databases have been around since the 60s [1], and the term was created in 1998. Two decades ago. Is the author of this manifesto saying that they'll only work with tech from the 50s? Or is the 80s good enough? The 90s clearly isn't.

In fact, Ajax has _also_ been around for two decades; 1998 was a big year for the web, apparently. The Outlook Web App (a major milestone in SPAs) was created in 2000, 18 years ago.

This "manifesto" is nothing more than "I choose to bury my head in the sand and use outdated tech and ignore the state of the art!"

[1] https://en.wikipedia.org/wiki/NoSQL

Now I want to see something like Prettier (a code formatter that enforces _exact_ whitespace and specific optional syntax) that will parse C code and fill in the correct parameter names, in comments, based on the headers, for any boolean parameters (maybe excluding single boolean parameters?).

Only for versions of "now" that date back to 1975, since that's when the law was passed.

This is entirely a straw man, and doesn't even represent the reality (or age!) of the law.

What the law implies is that Apple needs to continue to warrant the REST of the iPad, even if someone else has done work on the iPad at some point, unless that work caused the damage being claimed under warranty. They are perfectly able to say that they won't cover damage caused by you (or, by extension, anyone you hire to work on your iPad).

If the screen came from another provider, then Apple no longer needs to cover the screen at all, in fact. That's perfectly legal under current law. But Apple can't cancel the warranty on the rest of the device if the screen replacement procedure didn't cause the damage.

If, for instance, the iPad (the one with a replaced screen above) stops holding any charge after six months due to a faulty battery, and there is no connection between that new problem and the screen replacement procedure, then Apple still needs to cover the repair or replacement of the battery.

The problem is that if a competent screen repair voids all warranties, then you are being forced to go to Apple for all repairs. And that's what is illegal.

If a car dealer requires that you get the oil changed at a dealer in order to maintain your warranty, but something completely unrelated fails, they can't then say "Sorry, your warranty is void because you didn't pay our high maintenance rates."

That's what the law is about, and it's been that way since 1975 (!!), so I don't think we're going to suddenly see a drop in all-inclusive warranties just because the FTC is cracking down on a half dozen companies that aren't in compliance.

Nothing can replace many, many years of experience.

Some skill in general optimization-thinking is key. The ability to visualize how the entire system works is key. Aptitude for API and general architectural design is key.

And even when you get it all right, _something will fail._ At which point profiling and having the right metrics in place so you can see what's failing is key.

I think you need senior _technology_ people from day one, if you want to build to scale, and you don't really want to pay to build everything twice _and_ pay for extreme server costs _and_ pay to migrate from the old to the new system.

Maybe this means something different than "Heavy Hitters". I've never run a huge company division; I prefer to work in a startup environment, and except for a short stint at Amazon, that's where I've stayed. But I have been able to step into small companies as an interim CTO and turn their technology from a mess that won't scale and that was written by junior developers into something that will scale cleanly from day one.

And I typically do this by throwing away most of what was there to begin with and rebuilding from the ground up. Most junior devs just don't have good architecture and design in their blood like a strong senior developer. Which means there's 2-3x extra work to prevent the current system from dying or failing during the transition process ("Changing the tires while driving at 60MPH").

If instead you have someone like me drive the project from the start, when the project is _finally_ seeing traction you can focus on adding features your customers are demanding and pivoting if necessary. And you don't end up hemorrhaging money by paying for 50x as many servers as you would need if you'd start with a strong architecture.

And the funny thing? Hiring a strong dev early on will likely get you to a working product much sooner than several junior devs, and you overall save money due to launching sooner. So it's a huge win. And a lot of the time, founders _are_ junior devs (I've been coding for 30 years; anyone with less than five years is junior, from where I sit, and a decade is bare minimum to be "senior").

But everyone wants to cut costs and hire the $10/hour developers, or the green developers fresh out of college. And now articles like this are being written that imply that you shouldn't even hire a "heavy hitter" until some vague criteria have occurred...

Well, good luck with that. You might be able to pivot and improve your technology in time. Or you might end up going the way of Friendster, pissing off your user base because your site keeps failing, and by the time you have it working reliably, they've all left. [1] Or maybe the fact that they left allowed it to work reliably? Hard to say.

[1] https://en.wikipedia.org/wiki/Friendster

Which would mean exponentially growing testing requirements on the part of the company delivering the updates.

"Should" in an ideal world doesn't equal "should" in a world with deadlines and limited resources. It's enough work to ensure that all the features work with ONE version of an app. If you had to also test every version of the app without this or that feature update installed, you just continually multiply the testing requirements by the number of optional features.

And don't say unit testing solves this problem. The problem is in INTEGRATION testing with the whole app, which 99% of the time can only adequately be done by making the build and having a human use it. Even automated integration tools won't find things like formatting errors and buttons too small for humans to click.

I'd like to continue to maintain ONE app, please, and not `n!` app permutations.

I have experienced short-term thinking, driven by stock market expectations, very directly.

Working on a game, we had a build ready two weeks before the end of a quarter, but we weren't quite done. We had just a few minor tweaks that needed just two more weeks to complete, and we in fact delivered a complete game two weeks later...that was ignored, because it was more important to make their quarterly goal than to release a better product.

Turns out there were several games being developed that quarter, and ours was the only one to make it even close to under the deadline. But because they were doing quarterly reports, they were under tremendous pressure to release something, and so an inferior product was released.

Oh, and this was the era of physical cartridges. No updates possible. We put in a ton of extra work to make it perfect and they didn't care.

The international versions were shipped later and included the improved changes. If anyone is interested in seeing the difference, you can probably find the ROMs and a Game Boy Advance emulator: Check out the US release of "Tetris Worlds" and any of the international releases (all include English, but the three different international releases each included other languages as well).

I haven't tried either, no. They do look nice, but they still only solve part of the problem.

I have only been tasked with fixing setups on Jenkins, and a friend of mine has spoken at length about how difficult things are to set up.

Some of that is based on the difficulty in getting a Jenkins configuration into source control. For CircleCI, I know, the CI configuration goes in a configuration file that gets checked in to the repo.

Another big part is making sure the development environment is sane, and replicating it. When we were dealing with Jenkins, Docker didn't exist yet. I assume that build slaves running inside Docker are a thing now? Because that's another thing that CircleCI gives us.

Honestly, though, this is just a thing that's easier to outsource if you can. Running a Jenkins server on your own is valuable if you have business reasons ("Code cannot go onto a third party server!") or if you're doing testing that involves connected devices (build and deploy to this Android device, then run tests...). But apart from that or a similar motivation, why bother maintaining a server when services are available for fee or cheap?

Honestly, I would guess you've nailed it: The delivery company is collecting a fee because they are only paid for per delivery, so making a driver (and truck) wait doesn't otherwise make them money.

But there's no guarantee that the fees are passed on to the driver. Just in case, I'll pass a question back through my wife to see if some truckers are actually paid for waiting. They talk to each other; I bet they all know if anyone is paid to wait.

Correct. But the idea is that WebRender uses the same (general) techniques that a game-engine like this would use to make web page renders happen faster.

Speaking of batching, I look at this demo [1] on my mobile phone, and I can get ~3500 sprites without dropping below 60FPS.

A web page may not be able to reuse as much image data, I know. But smart game engines frequently look for ways to better batch sprites.

And technically speaking, if you're using a Z-buffer, you don't need to sort opaque layers at all. You can draw the layers in back and then draw more layers in front. Yes, you get overdraw in that case, but if you're using Z values for layering, you could potentially get better batches by drawing in arbitrary order (i.e., relying on Z-depth to enforce opaque object order), and in my experience larger batches gives you a bigger advantage than reducing overdraw.

[1] http://www.goodboydigital.com/pixijs/bunnymark/

Yeah. My wife has a friend who's a long-haul trucker. He gets profoundly disrespected by the current system, including showing up at 8AM to an appointment and being made wait all day, and sometimes into the next day, for his truck to be unloaded/loaded and ready for him to take.

And he's paid nothing for that. There's no penalty at all for wasting the trucker's time. I cite this as evidence that the truckers have no effective lobbying body, and therefore will in fact lose most of long-haul jobs over the next 15 years.

Jenkins is also a bloody pain in the ass. Just saying.

It's pretty trivial to use with Node. You just need to have a source folder, set up your tsconfig.json file with your preferred options, and then run:

    tsc --watch

There's also an REPL for Node here:

    https://www.npmjs.com/package/ts-node

I find it a bit tricky to do anything complex in, though. Since TypeScript is mostly ES2015 anyway, when I want interactive anything I usually just use an ES2015 interpreter (like Node itself). The types usually make interactive stuff more challenging.

> I'd be just as fund of another language that would be functional, immutable, interactive and with smart abstractions.

You get all of the above with TypeScript except immutability. Pull in Lodash for extra functional sauce, or the functional variant of Lodash for increased composability. And the serialization format is the industry standard JSON.

Events are really a necessary tool. You're the first person I know of to complain of "event hell;" event-based programming is a key feature of modern operating systems and browsers and applications. I haven't used a CSP (it looks like a Lisp thing?), but it doesn't look like a full replacement for events, but rather streams? And there are functional stream libraries in JavaScript/TypeScript. [0]

I don't deny that having macros as a "sometimes feature" would be a good thing. I just can't stand the Lisp zillions of nested parenthesis. (Thankfully JavaScript callback-hell is also a thing of the past with async/await and Promises...I don't like zillions of levels of callbacks either).

I think once you have static types, immutability isn't as critical, but if you're set on it, there's always Immutable.js [1]

> On static vs dynamic type systems, I still don't know. I like types, they feel good to have, but I just don't feel they really help, I think they're a false sense of safety, and they just slow you down. That said, maybe they pay back in the long term maintainance, I'm still unsure though.

Technical debt earns compound interest over time. Static type systems let you zero out technical debt for almost no effort.

The only "slow you down" I get from TypeScript is defining declarations for libraries that are missing them. That's about 5 minutes to 15 minutes per library. That's an extremely low up front cost to pay, and everything else about TypeScript is faster (auto complete on object members) and better (refactoring is fast and easy enough that it's easy to "just do it" and not put it off until later).

[0] http://reactivex.io/ or https://github.com/cujojs/most/ are good examples.

[1] http://facebook.github.io/immutable-js/

>I don't know, sounds like it's just not as awesome for you, but probably is that awesome to all those famous people saying it is.

Like our pg? Who loves Lisp to death, and made his first major app (a web page store generator, if I recall) in Lisp? But then after selling it to Yahoo -- ported it to another language (Python?) so that other developers could actually modify it?

It's not "lowest common denominator" to expect a language to stay within certain bounds of flexibility. If every single project has so many macros that it's effectively a DSL that no other programmer anywhere understands, then you've created a software package that becomes instantly unmaintainable if the wrong people get hit by a bus.

In college, by the time I picked up Lisp, I had already used:

* Assembly Language * Basic * Pascal * Forth * C++ * Recursion

And I'd already worked on video games professionally (in 1987, in a project for Lucasfilm Games, before they became LucasArts).

Java and C# had yet to be invented. At the time, there weren't libraries and documentation to speak of in any Lisp, so that's something. It was Common Lisp (as well as "elisp" on the Atari ST, which of course was completely incompatible...).

Since then, I've used tail calls (in Lua, and soon coming to JavaScript), collection mappings, pure functions, higher order functions, and all that, in many other languages. I just still hate Lisp, and while I have no problem understanding how to use Lisp, I don't see the advantage of using it over using other languages, and in particular I am finding static types to be critical in large system architecture, which are completely lacking in Clojure and other Lisps.

>Yes, but I bet the first one's you've learned were already algol-like.

BZZZZT! Wrong answer!

I started with BASIC and transitioned from there to assembly language. Wrote several games and device drivers in assembly language (BASIC was too slow) and then learned Forth. Tried really hard to like Forth, and played with it for a while; loved some aspects of the language, but couldn't wrap my head around how to write a game with it, so I gave up and kept writing games in assembly language.

Pascal was my next language, and that wasn't until later. Much later than that I finally got to C.

You might think of BASIC as Algol-like, though I'd say it's more Fortran-like. Assembly language, though, is about un-Algol as a language can be, as is Forth.

I spent months working on a Lisp project in college. I pretty much hated it.

Some people (myself included) don't like the aesthetics of Lisp as a language, nor do we like the enforced functional program structure, nor do we like the lack of infix operators. Maybe I "didn't have good enough teachers," but for every other language I've ever learned I didn't need those "good teachers" to achieve a strong level of mastery, and I've learned more than a dozen to a high level of mastery.

After a while you have to stop blaming the people and instead just admit that Lisp isn't as awesome-for-all-purposes as some famous people seem to think it is.

I have been using TypeScript. The TypeScript compiler gives me roughly 1-2 second builds, even on a large project that (it can watch code and build incrementally).

So I get the benefits of static types, plus the benefits of fast iteration, PLUS the benefits of a fully dynamic language for when I want to accomplish something quickly.

It's a full win-win-win. Throw in linting to avoid the legacy JavaScript crap and it's pretty awesome.

8000' is high enough for people to have problems (I live near the mountains in Colorado, and whenever I'm at a vacation destination that's at 8000' or more, they always have oxygen canisters for sale).

But people hike/climb to the top of 14ers (14k+ feet) here in Colorado all the time without additional gear/oxygen. 4000 meters is only 13k' and change.

Ears would pop going up or down if they didn't pressurize it, but it would be livable -- especially if you pumped in extra oxygen on the higher floors.

But if you're building it that big anyway, you could certainly pressurize it too, though that would make the HVAC tricky, though you'd probably need to have zones of no more than 100 floors that were sealed from each other, or the weight of the air on the higher floors would raise the pressure on the lower floors.

If you're spending a trillion dollars to build a building, might as well make it comfortable, right? :)

You're right. I should have said there's no reason to worry about competently designed UI control performance.

Swing was, in fact, an absolute disaster.

Linux has Electron compatibility already. On desktop there is no good reason to worry about "native" control performance.

And considering that React Native can barely seem to keep the controls in sync on iOS and Android [0], trying to throw in a tiny minority platform like Gnome makes no sense at all. Better to build controls for raw X or even an OpenGL UI implementation. It's not like it's impossible to do the latter. [1]

In fact, VS Code already runs mostly everywhere, has gotten a huge amount of community mindshare in an amazingly short period of time, and at this point I couldn't imagine ever using gedit for...well, anything, really. Why would I?

P.S. Not a downvoter.

[0] A friend is working on a project that's run into a number of "bug on Android, not on iOS" that, once patched, became a "bug on iOS and not on Android" issue. Rinse and repeat.

[1] https://kivy.org/#home http://www.fltk.org/index.php

> Frankly I'd be surprised if she had never been harassed in some way.

1. She grew up in Denmark 2. She works in the UK

From what I've heard, both are far more progressive and egalitarian than the US. If the people you know are based in the US, that could be the distinction.

I think the problems here are far worse.

No, you're missing the part where women leave tech in droves because of the treatment they experience.

Sure, we need to get more women into the pipeline. But we also need to not be pushing them out of the industry because they don't want to be groped, ignored, or otherwise disrespected.

In my experience, every woman I've worked with in tech has been above average or excellent. It's the men I've worked with who are much more variable in skill.

I heard a woman on this phenomenon in a podcast, saying that we'll know we actually reach gender parity when there are women working in tech who are below average in skill. And we're not there yet; women in tech tend to the exceptional. Women who stay are the ones who couldn't imagine doing something else because they're so good at tech.

A few minutes ago it looked like the content had been deleted. Right now I tried twice; first time I got a Tumblr error page, the second time I got a redirect to an "Enter Password" field on a Tumblr blog page.

I'm going to suggest that the owner is migrating the domain to point at a Tumblr page. Right Now. Maybe his servers were having trouble with the increased interest?

> Are these tools really the main source maintenance pain for web developers?

I consider TypeScript (or Elm) support a best practice for "JavaScript" development, so something that brags about not having a development workflow is a non-starter. It's not only not a pain for me, it's a significant missing feature.

Hey neighbor! I'm in Lafayette as well, over by the library. 20 minutes to Boulder, Longmont, or 30 minutes to Denver. It's a great location.

Agreed, it's awesome here, though the prices are going up pretty quickly. That said, so are the restaurants down Public! Great new options. :)

Did SparkFun re-open its retail business then? When I was there last summer on a tour, the retail storefront wasn't open. The facility is great, though.

Also: Don't forget TinkerMill in Longmont, a great hackerspace that doubles as an incubator. I just met someone today who is bootstrapping an educational toy company out of TinkerMill. The local start-up community is really quite vibrant.

It's listing what technologies are used by developers. I would wager very few use Macs to develop for Windows.

The vast majority of developers out there are using Windows. I would believe the majority of start-up engineers are using Macs, but the world of software development is probably 100x that of "start-up engineers."

> it's a solution that can't be fully cross platform.

I call B.S. on that. There's nothing stopping Apple from creating an API that anyone can register with, or even providing an XMPP gateway to allow completely non-Apple platforms to connect.

Apple is choosing to keep their walled garden isolated. It's absolutely a choice.

> Large companies can afford to spend the resources on a custom, more cross platform-y solution.

On scale: Cross platform is cheaper than coding twice. Small companies "dedicated to iOS" are Doing It Wrong. In 2017 it should be considered a best practice to use cross platform development environments for any app development. Between React Native, NativeScript, Xamarin, and yes, even Ionic/Cordova, there are a ton of great options, and there's no compelling reason for 95% of apps to go completely platform-native. And it's worse: Environments like React Native make it cheaper to create for a single platform, much less two platforms. And additional features and ongoing maintenance are also half as costly. It's a win-win-win situation.