When to Use TypeScript – A Detailed Guide Through Common Scenarios - <AUTHOR> https://khalilstemmler.com/articles/when-to-use-typescript-guide/ <comment><USER2> I agree with this article. Good stuff. One minor gripe:

> if you care about the code, you need to have unit tests for it.

That's not really true. You can test at a differently granularity and still have the same confidence in your code. Scores of brittle unit tests crowding your productivity is not what you do to code you care about. I wish people would just stop propagating this detrimental rumor that is backed by zero evidence. I prefer to keep my unit test suite lite and sweet (try to test what is very sensitive at the unit level - easy to miss or algorithmic things) and then try to get the most out of my acceptance test suite. Sorry, but I just worked on too many systems where the unit tests suite breaks no matter what you touch and you spend more time updating the tests than actually getting shit done.

<comment><USER3> If you write a library, or expose a public interface, I do expect a lot of unit tests. Unit tests can run offline, fast, during build time. I don't mind integ-unit tests that perhaps simulate a database in memory to avoid mocking the entire storage layer. I rather have tests that are technically integration tests as they include more than, well, a unit, as long as they are idempotent, test mainly one thing, and can run fast and offline. Not sure if there is a term for it but I call these integunit tests... (probably the worst name possible)

But unit / unit++ tests are not just for you, they are for me, they give me confidence I can touch your code without inadvertently breaking something critical that you may have missed in your acceptance tests. It gives you peace of mind to be able to refactor. An acceptance test may tell you they something broke, but a good unit test will show you exactly where.

<comment><USER2> > breaking something critical that you may have missed in your acceptance > tests.

So you can miss things in your acceptance tests but can't miss them in your unit tests? Why do you feel more confident with unit tests than with acceptance tests? Maybe because unit tests break more often so they are providing you with a false sense of security? Do you know that when a test fails for a reason other than the specified assertion its a called a false negative and the failure is meaningless? Do you know if your tests fail and no functional or non-functional requirements of the program has changed the failure is also meaningless (you are testing implementation)? Ask yourself how often does your group give you time to do these hypothetical large refactoring that give merit to large unit test suites? How many times, even, do you do small refactorings and find all the test have to go away or significantly change anyway because they made some implementation assumption that is no longer true? How many times have you gone into a test suite and have seen that its been patched up so many times that you can swear its testing something but you just don't know what? I know that Uncle Bob tells us about test for refactoring and this and that, but I just don't buy it any more. The emperor is naked god dammit. Uncle Bob and the like are very famous because people swallow their anecdote without due scrutiny.

<comment><USER4> One thing I can't find much evidence of is Uncle Bob's experience in delivering commercial software. I get the feeling he works mainly on toy examples which might explain some of the things he advocates that, like you, don't match my experience at all.

</comment></comment></comment></comment><comment><USER5> > will most often write vanilla React.js apps when: the codebase is small

This one never ceases to amaze me. Any codebase is small, until it gets big. And once it's big, the effort to rewrite is hard to justify.

You don't build a house and add the foundation later.

<comment><USER6> I see so many HN comments endorsing "build the product to exact specification using the minimum reasonable tool set." When you then ask "what happens when the specification changes?" you get hilarious answers like "just say no to the user", or "just extend the app!"

This is why I always over engineer a bit, especially on new projects. I'll happily, for instance, add a framework before it's strictly necessary. I've _never_ regretted that decision in the end.

If people here want to use a 5 gallon bucket on an initial 5 gallon job, go for it. Best of luck to you. I'll be over here starting with a 10 gallon bucket and not sweating when the customer needs to add another gallon...

<comment><USER7> It's rare that I find a comment which validates my own practices like this. I personally love creating systems and abstractions, and admittedly I will sometimes create one when a simpler solution would suffice. However those "over-engineered" solutions have frequently saved me lots of time much later when business requirements change.

<comment><USER8> Your stance sounds different to the grandparent's.

There's a world of difference between adding a framework and over-engineering something that could have used a simpler solution.

My experience has been the exact opposite of yours, whenever I added something complicated, it either never got used and unnecessarily complicated the code, or when the time came to use the fandangled cleverness I lovingly wrought, it never quite met the need I actually ended up having.

So I stopped doing that years ago and now always write the simplest code. Never regretted it. I will add frameworks early though.

</comment></comment></comment></comment><comment><USER9> This doesn't seem like a common occurrence, judging from all the praise of TypeScript sung on this thread and elsewhere, but I've had an overall negative experience working with TypeScript so far.

Here's some thoughts on what has contributed to that so far:

1\. TypeScript pushes you towards its own build pipeline (based on tsc) that doesn't play nicely all the time with mainstream JS build pipelines (usually based on babel).

With babel 7 came @babel/preset-typescript, which I hoped would narrow the gap, but so far it's very clearly a second class citizen in the TypeScript ecosystem, with new features built only with tsc-based pipelines in mind (Project References is the one that stands out because we sorely need it for our monorepo codebase, but can't use because we chose to adopt @babel/preset- typescript), and having personally ran into several issues stemming from what seems to be fundamental incompatibilities between tsc and babel that have no real workarounds (here's one that I can remember off the top of my head: [https://github.com/babel/babel/issues/8361](https://github.com/babel/babel/issues/8361)).

The reason this is so frustrating is TypeScript could have been just a type checker, like Flow. But instead, it had to introduce it's own compilation tooling which is still vastly inferior to babel in terms of overall flexibility and extensibility. All of this seems to be due to what I believe are a few fundamentally poorly thought-out decisions at the beginning of the project to allow TypeScript to specify its own language features that have runtime semantics (things like Enums and class visibility modifiers, neither of which are anywhere close to becoming standardized in JS-proper, by the way, and both of which are completely orthogonal to TypeScript's main responsibility of type checking), and implementing them using a separate build pipeline instead of as extensions to babel & its own type checker.

If I were to use a JS type system for a new project today, I'd personally choose Flow over TypeScript in a heartbeat because of this.

(this is getting a bit long so will continue in a reply)

<comment><USER9> 2\. TypeScript's type checker, at least in its current state, has been downright painful to work with for functional programming with functional composition and higher order functions in general, with errors that are incredibly opaque and unhelpful, and its poor inference introduces so much seemingly avoidable type-related verbosity that it completely distorts the signal to noise ratio in our code.

A prime example for this is ramda's pipe function: [https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/ramda/index.d.ts#L2148)

A simple function that composes functions together in reverse order requires:

1) The definition to be an exhaustive list of all the variations of input functions that pipe can accept (which of course would technically require an infinite number of declarations to fully specify, so ramda had to call it quits at 10).

2) The user of pipe to specify output types for every single function being composed at every step, even though that should be possible to infer using the return type of each function in the pipeline.

These kinds of limitations plague our codebase everywhere we try to define higher order functions in our own code as well, because it means we have to ask users of the function to specify the result of the function argument as a generic parameter even though it should be perfectly inferrable from the function argument itself, and the noise buildup becomes exponential as you start composing higher order functions together due to pipe suffering the same limitation. The issue also rears its head when using higher order components with recompose, which we make heavy use of as well.

I'd love to hear how other teams working with functional programming in TypeScript work with these limitations. Perhaps we're missing something fundamental that could vastly improve our experience?

<comment><USER9> 3\. TypeScript only supports positional generic parameters (i.e. you can't give them names).

It's well known that positional semantics don't scale when it comes to argument lists, because when changing the API of something with a positional argument list, adding an argument in an arbitrary position becomes a breaking change that requires all usages to be updated.

Unfortunately, part of the fallout from point 2 means we often need to define higher order functions that require a decent number of generic parameters, all of which have to be positional due to this limitation.

There's a hack that we discovered that allows you to have poor-man's named generics by using a single generic argument with named properties, inspired by this comment: [https://github.com/Microsoft/TypeScript/pull/23696#issuecomm...](https://github.com/Microsoft/TypeScript/pull/23696#issuecomment-408717985)

But it's incredibly verbose, and doesn't support optional generic arguments or defaults as far as I can tell. We still use it despite this, because we believe the verbosity and having to specify every generic argument is the lesser of two evils compared to offering APIs that requires breaking changes for every addition. But that we have to make this choice points to a glaring omission in the design of the type system.

<comment><USER10> You can kind of give generics names by declaring them in an interface and passing T extends Interface as the generic parameter

</comment></comment></comment></comment><comment><USER11> The article mentions object-oriented programming several times as a helpful paradigm (especially for domain-constrained problems where DDD is helpful).

I'd also like to point out that functional programming is tremendously helpful for solving these types of problems, especially when combined with use of modules. TypeScript is absolutely capable of modeling, checking, and otherwise handling types in a functional programming context. — this is one of its best strengths in my opinion, and one reason I now prefer TypeScript over C#.

<comment><USER12> > TypeScript over C#

TypeScript is a transpiler for JS. C# is a server side language. Can you please clarify how former is the replacement for latter?

<comment><USER13> I don't want to speak for the OP here, but when I refer to Typescript in comparison to other languages I tend to mean Javascript + the type system provided by the Typescript.

Typescript is not even necessarily the transpiler nowadays. I use Babel for that and use Typescript exclusively for static type analysis in CI and during development.

</comment></comment></comment><comment><USER14> It's a default for me now, on every new project. It doesn't slow down development because TypeScript allows you to easily "step down" type constraints as desired, and writing nontrivial code without any kind of type hints is just unimaginable to me now.

<comment><USER15> > unimaginable

I imagine adding types gradually as a design solidifies, rather than slow velocity early on. Best not to be dogmatic on these things.

<comment><USER16> I have never understood why typed languages make you slower at any point in time (early, late etc.).

Because you have to hit more keystrokes to write your program?

That doesn't compute. typing is the thing you do the least amount of when programming. In all best practices we are taught to not save keystrokes. Name your variables expressively. write small functions. document code. Write tests. All ""excess"" keystrokes nobody questions. But when you have to type " ... : number" it's slow velocity?

In my opinion people vastly over-estimate productivity boosts of saving keystrokes. It's the tedious, boring part of the work that you would like to skip entirely, hence excess keystrokes feel way more "slowing you down" than they acutally are.

Although it doesn't matter, you actualy save keystrokes: autocomplete, auto- refactors and less low level unit-tests compensate the couple of type annotations easily.

<comment><USER17> Though you have a point, writing down type annotations can seriously slow you down when you are doing exploratory (prototyping) programming. It can also make your code less readable as the annotations can get in the way of the logic you really care about (easily fixed in an IDE, but people want to still use notepad to edit/read code). Then there is figuring out what the annotation should be in the first place, again easily enough automated in an IDE but the notepad problem remains.

<comment><USER18> What usually slows me down about dynamically typed code is you have some variable returned by a function only denoted by var myVariable = myFunction(); and I'm sitting there staring at thinking... "what are the contents of that variable? what properties do I have access to on that object? what can I do with it?"

And figuring that out becomes a massive time suck when that's a constant across an entire code base. Statically typed stuff means I can very quickly find that out even if it's the first time i'm exploring that particular area of the code.

<comment><USER17> I agree, in a type inferred language or a language where annotations can be supressed, this is just another matter of IDE affordable.

Some dynamically typed languages support type annotations that are only enforced dynamically; Julia is the primary example of such a language ATM.

</comment></comment></comment></comment></comment></comment><comment><USER19> The amount of fanboyism in these comments is astounding.

TypeScript is a great tool.

At the same time, people have written apps with vanilla JavaScript for a very long time now, and it works just fine. If types are really that big a deal that you have a hard time writing an application without a compiler checking your types, you should reevaluate what you're doing. It's not "dangerous" to use plain ol' JavaScript, and implying that others are foolish for not using it reeks of _software snobbery_.

 _Whoa, you mean people really still use plain JavaScript, bruh? I mean, don 't you need like punchcards for that? That's how grandpas program, bruh. You can't even, like, scale an app without type-checking. An app written without TypeScript is like a house of cards, dude._

<comment><USER20> >If types are really that big a deal that you have a hard time writing an application without a compiler checking your types, you should reevaluate what you're doing.

Implying that everyone has exceptional short term memory, and reading old code has virtually no cost.

<comment><USER19> I never said that TypeScript wasn't helpful. The picture painted by some people that frontend applications without compile-time type-checking are ready to fall apart at the seams and have knobs and springs go flying everywhere, like something from a Looney Tunes cartoon, is patently absurd.

<comment><USER20> Given what I said, Even for fairly simple examples, it would still be more bug prone, simply due to humans not having perfect cognition. At scale that can add up.

Also keep in mind that this both enables, and follows a trajectory of increasingly complex frontend applications, previously a lot of interactive stuff was done server side.

Patently absurd, if you take it as a strawman, sure. You ended up using that to paint the complete opposite picture, which was essentially that Typescript doesn't actually add any real value, only "perceived" value. Which is true, if all you value is the execution environment. Keep in mind that Typescript was not the first attempt at trying to "tame" Javascript. One example that comes to mind is Coffeescript.

The natural reducto ad absurdum is thus, well why aren't we just writing in ASM, it all boils down to that anyway, right? People were doing fine then too... Could it also be said that accusing people of needing "crutches" is also snobbery?

</comment></comment></comment></comment><comment><USER21> Typescript is wonderful, especially as someone used to writing a lot of java/groovy. Typescript is like pouring cement around your javascript house of cards. It makes writing front end code painless and predictable.

It also has amazing tooling in intelli-j. Code completion, linting, package recognition, all the good stuff.

<comment><USER22> > It also has amazing tooling in intelli-j. Code completion, linting, package > recognition, all the good stuff.

... and in the free Visual Studio Code, also crossplatform like IntelliJ.

(Nothing against IntelliJ, JetBrains is a cool company with amazing products IMO, I just prefer VSCode myself.)

<comment><USER23> I think VS Code is almost like a little brother of IntelliJ now but better at a few places. (Especially rendering.)

</comment></comment></comment><comment><USER24> Regarding TypeScript, the benefit of catching way more errors at compile time greatly outweighs the amount of extra work for adding types. If you're starting a new JavaScript project, you should definitely think long and hard if you pledge not to use TypeScript.

<comment><USER6> And the best part is that TypeScript is just a superset of JS. If you're new to TS, you can use it like you've been using JS. Just by giving your variables the `any` type, or disabling null checking, and so on, you can write JS like you always have. No pressure.

And, eventually, you'll be lulled into properly typing your variables, because damn it those type annotations are super handy! Oh, and you start defining your own interfaces because it makes your code more readable and easier to reason about. Oh, and...etc etc etc.

If you start by gradually adopting the extra features that TS provides, you'll never want to go back.

</comment></comment><comment><USER25> Why does everyone treat TypeScript like a full language? Besides some features like generics 98% of it is just javascript with type annotations (sorta similar, including in syntax, to py3 with annotations). And in that view its probably foolish not to use it as the cost of these annotations is so low relative to the refactoring/safety/easy-of-use/code-completion/etc it offers. These type annotations are so easy to add!

I can't even imagine writing JS without these annotations esp given all the odd behaviors of the language.

<comment><USER6> TypeScript is such an unbelievably powerful add-on that I simply refuse to use vanillaJS unless absolutely necessary. It eliminates entire classes of bugs, encourages me to write better code by thinking in JS about contracts (interfaces), and vastly improves my productivity with the aforementioned annotations. ("What was the signature for method X of class Y in library Z? Ah, that's it. Thanks, TS/VSCode!")

</comment></comment><comment><USER26> Some people love js for it's functional approach. Mainly because they hated the whole OOP paradigms and the design pattern baggage that came with it.

But now js is adding classes and there's typescript , now it's like Java all over again.

Welcome to programming, where the fads go back and forth in cycles.

I also read a commment here saying people love React because now they can add code all over their view file.

Well adding code in view file is ugly and there's a reason why we tried to get away from doing that.

Sounds to me people want to just go back to the 90s-00s!

</comment><comment><USER27> > it's actually dangerous for your project to NOT be written using TypeScript > today.

Wow! Bye bye Javascript! Such arrogance! In a way it always feels like Typescript developers are way beyond all those poor suckers still coding in Python, Javascript, Ruby, Coffeescript, etc.. Dynamically typed languages are DANGEROUS!!! just as C is DANGEROUS!!! I'm so happy C is still being used and not abandoned in favor of C# or so.

I know I can be way more popular preaching Typescript nowadays, it would make me really cool, smart and up to date. Not going for Typescript proves I'm mediocre at best. This is not cynic, this is real when I talk to fellow web developers.

I believe static type checking should ideally be done by the IDE, we shouldn't need an entire new language for that with all its shortcomings, issues and whatsoever. And we'll see what's left when the hype is over and the next big thing in the Javascript world comes around. At least heaps of Typescript code bases that need to be rewritten.

<comment><USER28> > static type checking should ideally be done by the IDE, we shouldn't need an > entire new language

I am not sure what you are trying to say here. Javascript is barely typed, so presumably you do need a new language to perform type checking.

Unless you mean that your IDE should be able to infer types, which is unlikely because typing defines intent, and we've all read plenty of code where we can't figure out what the code author intended.

</comment></comment><comment><USER29> One challenge I have with TS is that when writing interfaces for untyped libs it's easy to make a mistake. I've had issues where VScode was telling me something was the incorrect type because someone else on the team had written an incorrect type in. Instead of debugging it like I would in normal JS I banged my head against the wall because I was convinced that is TypeScript was telling me something was a certain type, it HAD to be true.

</comment><comment><USER30> Coming from C# background, Using Typescript for front-end programming was a breeze for me. This helped me in picking up newer frameworks and saved countless hours during debugging and build time errors. I liked strict validation of props using interfaces while working with restful APIs.

</comment><comment><USER31> Such a guide can be reduced to:

If you only have a single file that has a limited set of responsibilities (e.g., just a small tool) and is not shared / distributed then JS may still be okay, otherwise always go for TypeScript.

Honestly, TypeScript never slows me down. The enhanced completion / IDE knowledge, compile-time type checking, and transpilation supporting newer ES features + React is a huge boost.

</comment><comment> a-saleh I wonder if some of the people here, that like Typescript just fine, would consider less main-stream typed-js solution.

I.e. Elm, ReasonML/ocaml/bucklescript, Purescript, Haskell with ghcjs, Rust with web-assembly compilation, or even wasm from Go?

I am somebody who really likes to dabble, but is not a fronted person, so I am thinking, what would make you consider switching?

<comment><USER32> What I mainly liked about TS is that it's basically plain js with some typeinfo sprinkled on top. So no barrier of entry for existing js developers.

Now I work on a project with Elm for the frontend. It's not as easy to just jump into, so wouldn't use it for a project where lots of developers sometimes have to make additions. But once up to speed, Elm is great.

</comment></comment><comment><USER33> Always, unless it's a very short script that uses packages that have no type definitions.

<comment><USER34> the issue I run into (and maybe there is a quick solution) but when I work on a TS React project and want to add a library that does not have Typings definitions, i get in a world of hurt. trying to quickly add my own typings or fix TS errors w/out disabling major compiler functions.. usually spend an hour or two and give up on the library.. is there a good way to deal with this scenario?

<comment><USER35> That is a pain point, but I think of it as spending a few hours to save a few weeks down the road.

</comment></comment></comment><comment><USER36> Honestly, the only downside to me of typescript is occasional grief from @type libraries or some build complications when you're first getting setup. But having working code completion and non-surprising return values/argument parameters is so much worth the initial minor pain points.

<comment><USER37> The other issue is dealing with module compilation... this part still always screws me over.

Once it's up and running TS is freaking amazing

</comment></comment><comment><USER38> i recently learned you can actually have typescript annotations without [imo] polluting the syntax or requiring the TS compiler:

[http://seg.phault.net/blog/2017/10/typescript-without- transp...](http://seg.phault.net/blog/2017/10/typescript-without-transpiling/)

does anyone know if there are limitations to this style?

<comment><USER39> Cool, thanks. I generally love TS, but I have one project which I converted to TypeScript, and then reverted back to ES7, because the project is quite complex and the overhead of TS was not worth it. I wonder if by using this Jsdoc/ts strategy in critical sections I can get 80% of the benefit.

<comment><USER40> > the overhead of TS

Do you have any concrete examples? I would argue that a complex project that is already in TS benefits more from remaining in TS, so I'm curious what your reasoning was.

<comment><USER39> 1) Import/export syntax hell. This project is 148 Javascript files, 12k LOC. Everything runs in both Node and Browser environments. Without TypeScript I just use CommonJS syntax and rewrite the scripts on the fly via a server-side pass through for a browser environment. But because of the module hell (import/export/script modules/relative vs absolute paths/defaults) I couldn't find a good formula for write once, run everywhere for this large project. I needed to be outputting 2 different builds to 2 different places which led to all kinds of path problems. This is very much unique to this project though, which has unique runtime require requirements.

2) Compile time overhead when iterating. For many visual development tasks it just takes too long to change something, compile and see results in the browser. Without TS it's 0 latency. With TS it was a few seconds. Without TS I could make 10 changes with 2 seconds latency, and perhaps I make 1 type mistake costing me 20 seconds of debug time, for a total of 40 seconds. With TS I make 10 changes with 5 seconds latency and zero mistakes but now total overhead if 50 seconds. I want to be able to get the documentation and static type checking benefits without giving up that instant feedback.

</comment></comment></comment></comment><comment><USER41> My day to day value from typescript is that when you're on a make things happen team that's burdened by type pendants or grouchy C#/java/r/whatever "devs" who find themselves career "transitioning" to JavaScript/web-apps throw them typescript as a Turing Tarpit & then everyone shuts up and then makes a thing. Dumb arguments get relegated/channeled into PR/issues on the tsconfig.

I say that half in jest but one of the dumbest & most destructive things in software engineering is tribalism or militant belief systems. Having a "neutral" way to deal with them (or something like "data" seeming like it's neutral) once and for all does wonders for productivity

People who don't like or trust typescript, what's your good-faith case against it. Personal productivity or ugly/confusing syntax are valid reasons I think

</comment><comment><USER42> > I certainly didn't see the benefit... up until I started experiencing some > really annoying stuff. Things like builds not failing when they should, > buggy code and typos finding their way into production code somehow started > to get to me

It's hard for me to understand how anyone can't see the benefit of types at compile time. I mean if you write more than 100 LOC you are bound to make a mistake that a typing system would catch and think "I wonder if there is a way the my build process could catch such as silly error". I can only imagine that such programmers are "write only" in that they add lots of features but rarely need to come back and maintain their code. With an ide with autocomplete it may mitigate some mistakes and give a false sense of security about non-static typing.

</comment><comment><USER43> On the other hand. If your code base has become so big that you need something like TypeScript to make your life bearable, you're probably doing it wrong.

Having strongly typed languages has much more to do with those developers who can't live without the autocomplete feature in their IDE. Especially the army of ASP.NET developers who are used to working with Visual Studio.

We'll probably be seeing more of those code generator patterns with TypeScript soon.

Not saying TypeScript is a bad thing. But strongly typed languages do come with their pitfalls. Massive amounts of code providing a simple CRUD interface. An entire team working on their complex microservice solution which is just wrapping some already existing API. Things that can easily be achieved with a couple of lines of _cough_ PHP _cough_.

</comment><comment><USER44> I'm writing a DDD helper library in Typescript ([https://www.npmjs.com/package/@node- ts/ddd](https://www.npmjs.com/package/@node-ts/ddd)), but found it more difficult doing something similar in Javascript. The richness and safety that static typings bring to a project compounds as time goes by.

I've also found it easier for new developers to become productive sooner when the language and framework guides them in the direction they want to go. I'm all for anything that supports a positive developer experience, and it's more concise to express my design in terms of static types than it is through mounds of documentation or exploring the code.

</comment><comment><USER45> Seems like you should just learn javascript instead. Though I can see how Typescript might be easier, depending on your background.

</comment><comment><USER46> Just use it. I found with auto import and other stuff actually writing TypeScript is almost always faster than JavaScript.

The type system is a little bit more advanced than those languages with nominal type systems like Java. Sometimes typing old code is tricky. But the good news is you can escape by using any anytime.

</comment><comment><USER47> > For example, it's almost always expected that your app is going to still > work offline in some capacity; and when users ARE online, it's also usually > expected that they're going to get real-time notifications without having to > refresh the page.

I never expect something to work while I'm offline, or do they mean the cached contents like a page would work if it were just cached HTML and CSS? As for real-time notifications, I don't know anybody who uses those, the other day someone was telling me how pissed off they were that they always get them from some news site, and they didn't mean to enable them, now they can't find where to turn them off!

</comment><comment><USER48> Yup- Typescript is mostly used in large-scale enterprise software development where rigorous unit tests are not in place.

I still suspect that a large part of Typescript adoption comes from developers who are used to working in an IDE (Visual Studio, Eclipse, etc), and are uncomfortable with javascript's natural "textfile->compiler->test" workflow.

Its also worth noting that support for typescript (that isn't Microsoft marketing) tends to come from outwith established tech environments. Using Typescript outwith MS environments can be challenging.

</comment><comment><USER49> Isn't anyone worried that TypeScript will go the way of CoffeeScript?

<comment><USER50> I am not. CoffeeScript was never as popular as Typescript already is. TypeScript is a tool which solves a problem, CoffeScript is a language (IMHO) no one needed.

<comment><USER51> To be fair to CoffeeScript, it introduced and popularized features that eventually made it to the EcmaScript standard. You could make a case for it being the kick that started the wave of improvements to JS that we've seen in the past decade.

As for GP's post, I can only hope that Typescript leaves a similar legacy, even if the language itself ceases to exist.

<comment><USER52> That kind of historical retrospective is an article I would definitely read. As much as Coffeescript seems like a dying language when compared to where JS is today, its appeal was very strong for it to have become a default include in Rails 3.1, and to have been the primary choice for teams like Dropbox and Github [0].

0: [https://en.wikipedia.org/wiki/CoffeeScript#Adoption](https://en.wikipedia.org/wiki/CoffeeScript#Adoption)

<comment><USER51> I'm pretty sure Jeremy Ashkenas has commented before on how he's satisfied with the role CoffeeScript ended up playing. Don't know if there are full- fledged articles on the topic, and I can't tag him here, but if you're really curious you can always reach out at [https://twitter.com/jashkenas](https://twitter.com/jashkenas)!

</comment></comment></comment></comment></comment><comment><USER53> FYI, the link to "concrete classes" is incorrectly linking to [https://khalilstemmler.com/articles/when-to-use- typescript-g...](https://khalilstemmler.com/articles/when-to-use-typescript- guide/wiki/concrete-class/).

I assume the correct link should be pointing to [https://khalilstemmler.com/wiki/concrete- class/](https://khalilstemmler.com/wiki/concrete-class/)

<comment><AUTHOR> I appreciate that. Thank you!

</comment></comment><comment><USER54> At the risk of being downvoted into Hades, I feel that if your project is complex enough to warrant using Typescript, its complex enough to warrant using a more robust and comprehensive language. After using Typescript extensively working on a back-end application in a complex problem domain I feel that while it is definitely a fantastic improvement to the core language, it doesn't really escape Javascript's worst issues. Issues like Promise- fatigue, poor ecosystem, terrible native types are still there under the hood. For the extra tax you pay in terms of build pipeline, tooling and dealing with the ecosystem, you may as well upgrade to a language more suitable for this kind of development for little extra cost. I just feel this debate is somewhat of a false dichotomy. People in this thread are debating Typescript vs Javascript as if these are the only two possible options for web development.

<comment><USER55> > Promise-fatigue

JavaScript actually handles async IO nicely, and I've never heard this term before (callback hell, yes). So promises and async/await sugar actually make it pretty nice.

> poor ecosystem

Ecosystem is fine, just don't jump on everything new. The well-known problem is standard library, it is indeed a problem, usually addressed with a mix of additional packages.

> For the extra tax you pay in terms of build pipeline

This pipeline is norm in the frontend development, so in case you have people proficient in tooling, it is not that high (of course, it is hard if you have Java developers).

> Typescript vs Javascript as if these are the only two possible options for > web development

They are not, but the nice thing about it is that you can have almost the same tooling as on your frontend, if you have some sort of complex application. So that increases speed of development, and TypeScript gives you some sense of scalability.

Last part is that TypeScript can be adopted incrementally, while another languages will require complete rewrite (and different deployment, etc).

<comment><USER54> I actually just made the term up myself just then to describe my feelings about the fact that all of the methods in our service layer are just `await this(); await that(); await another(); //...` and so on. Please be aware that this post is describing my own experiences in _back-end_ web-app development using Node. I feel I'm courting more controversy here, but if you're using `async/await` ad-nauseum your app might not actually be as async as you think it is. Of course this is a godsend compared to the callback hell that it replaced, but I can't help feeling that this is the right solution to the wrong problem. In my experience, most of the server-side applications I've seen written in Node are only practically asynchronous at the router level. Once you get into the controllers they tend to become entirely procedural and effectively completely synchronous. With the exception of the rare `Promise.all(...).then(...)`.... If you're using `await` on every single function call, it stops being syntactic sugar and just becomes more syntactic salt.

<comment><USER56> I completely disagree. Or rather I'd say if you're making a bunch of remote calls, and you need the results before taking the next step, then you're going to need to be doing something like this in any case. FWIW I feel a backend controller in Node is much easier to write, and to understand, with async/await than the equivalent patterns in Java.

As you put it, "Once you get into the controllers they tend to become entirely procedural and effectively completely synchronous" but that's because for most people it's far easier to think about a problem as a series of individual steps. Even then, if you have a bunch of serial awaits it's usually pretty trivial to go back and then await on a Promise.all() if you realize things can be run concurrently.

<comment><USER54> I think I might not have explained myself too well up there. I was referring to entirely sequential async calls. Like: ``` Thing thing = await loadThing(); Thing other = await thing.doSomething(); thing = await saveThing(); // repeat x1000... ```

I see this over and over.

<comment><USER57> And what exactly is the problem with that?

"Thing thing = await loadThing(); ": Start loading thing, then await so the main thread can continue doing other stuff while thing is loaded.

"Thing other = await thing.doSomething();": Invoke some other function that does some stuff in the background, then await so the main thread can continue doing other stuff while thing does something.

"thing = await saveThing();": Saving can often be done in parallel so no need to block the App while something is saved. Invoke the save function, then await so the main thread can continue doing other stuff while thing is saved.

This gets you the advantages of async programming while still maintaining a legible coding style that looks similar to common synchronous code.

</comment></comment></comment></comment></comment></comment><comment><USER58> Your DDD link is dead (so technically it's a DDDD link :)

<comment><AUTHOR> Haha. Yeah, that's the next article for me to write. I just started this blog recently. My approach has been to track which dead links have been clicked the most and then write about that topic next. DDD is far in the lead. Expect it soon.

Thanks for reading!

</comment></comment><comment><USER59> This sounded more like an OOP pitch than a TS one.

</comment><comment><USER23> People don't seem to point out but you need a decent editor to benefit from using TS. If your editor doesn't support live checking, then it probably feels like boring additional work by going back and forth between code and compilation error logs.

</comment><comment><USER60> Recent Typescript convert here: I find Typescript a GREAT tool for those experimental projects. They are the ones that need constant refactoring as you build, which is where Typescript shines.

</comment><comment><USER61> By the way, fun fact: the _script_ utility for recording a TTY session saves a file whose default name is "typescript".

</comment><comment><USER62> The link to domain driven development wasn't useful. The post should explain more about that and SOLID.

</comment><comment><USER63> 4 of the most popular language creators here [https://www.youtube.com/watch?v=csL8DLXGNlU](https://www.youtube.com/watch?v=csL8DLXGNlU) agree that type systems are useful.

I would suggest definitely not using Vanilla JS. There are excellent type systems over JS, TypeScript, Scala.JS, BuckleScript to name a few each with their pros and cons (I don't know what cons BuckleScript has though, maybe relatively smaller lib-ecosystem)

<comment><USER64> Larry Wall is endorsing strong types? I'll have to watch that now. I guess you can use Perl 6 in a way that approximates it, but it's very optional.

<comment><USER65> I believe the idea is 'gradual typing', where you add types as you firm up an interface.

Lots of the perl6 code I've seen types most stuff at least at interface boundaries.</comment></comment></comment>


Instagram's suicide note - <AUTHOR> http://claytoncubitt.tumblr.com/post/38164739490

<comment><USER2> Just a matter of time until the fb-style "Joe likes FoxNews" rage starts. Maybe it'll be a lot more hipster: "Azul likes GorillaNutz Gum". Actually, I think I'd start using it if it was that good...</comment>


User Culture Versus Programmer Culture - <AUTHOR> http://pgbovine.net/two-cultures-of-computing.htm?dsffs <comment><USER2> I find a decent amount of fault with this article, but it's not all bad. It starts off with a really cool premise and then goes on to equate "programmer culture" with using the command line. I think the author is spot on when he describes how user's think about software/apps, but obviously the command line is not the be all and end all of how programmers think about software, it's just (a very important) one of many tools.

One group of people have no idea what programming is, the other group do. It's not that complicated. There is no user/programmer culture divide, it's simply a matter of understanding a complex topic or not.

I think a lot of "programmers" use apps and other software like "users", but when something goes wrong we like to hunt down the solution and fix it, and I think that explains why it is not uncommon to hear programmers complaining about how stupid the people who wrote the software they use everyday must be; because it can be frustrating and annoying when it ends up being something really obscure.

Programmers have a better understanding of how software works, but just like everyone else we get frustrated and annoyed when our app's crash. We can complain in more elaborate and accurate ways than the average person is all.

<comment><USER3> The command line is just an example of the division you may see between university academic departments and business areas in a large company.

What the writer calls "programmer culture" may well involve running Linux. Then using OpenOffice or Google Docs or LaTeX instead of Word and Excel leading to messed up formatting any time documents are passed back and forth. Maybe sending presentations around as PDFs - which Windows users can't edit. Can I, a Linux-using programmer, understand why you'd want to connect a spreadsheet to a database? It boggles the mind. No, don't bother to send it to me, I can't open excel files. And in the opposite direction, us Linux users will happily recommend software that works great for us, and which is notionally cross-platform, but on other platforms the user experience is much worse. And that's just for technology which has barely changed since Office 95. God forbid if you want to embed a video into a presentation and have it play on several platforms.

</comment></comment><comment><USER4> I've seen a similar schism within the programming community. Web culture is of course closely related to Unix culture. The web is really an outgrowth of Unix.

At places like Google, and other web companies, the Unix shell and emacs/vim reign supreme. Most people on HN work at web companies.

I used to work in the game industry, and have referred several coworkers to Google. Invariably they are shocked that people still use emacs and vim, and find / xargs. They are visual people and prefer IDEs. The command line just seems primitive and unproductive. A lot of people with a Java background have a similar reaction. And no, it's not related to the quality of programmer, since James Gosling (who wrote the original emacs I think) had the same reaction to google's tool chain.

I think programmers can roughly be divided into "language people" or "visual people". That is probably true of non-programmers as well. I have taught programming using the terminal and vim at Google, a web company, but I realize that in a different setting, this would be the wrong toolset.

Interestingly, I would expect Unix / verbal culture to be most relevant to librarians. If you were teaching a bunch of technical artists programming, Unix would be inappropriate and almost certainly a disaster.

</comment><comment><USER5> While the cultural observations are all true, the class he's using as an example just seems really poorly planned.

It's not hard at all to motivate why programming is different from all those alternatives. The instructors just picked really terrible examples.

You can keep a room of nonprogrammers at rapt attention for an hour with 30 lines of Processing. Do something _cool_.

<comment><USER6> sorry i should've provided context: these classes are meant especially for working professionals -- mostly in academia: librarians, research staff, scientists -- to learn skills to make themselves more productive at work. 30 lines of Processing is _cool_ , but won't make them more productive in grepping through gigabytes of ill-formed archival data files, organizing and visualizing them, and making reports for their bosses.

</comment></comment><comment><USER7> This article confuses teaching Unix with teaching programming. They are separate subjects. It used to be a prerequisite to teach Unix first because most programming tools were command line, but I'm not sure whether this is still true. I spend far less time in the shell than I did 15 years ago because the GUI tools are now so good. To use the example from the article, back then I would have used the find command because it was the best way, but now like his users I would just use Spotlight. I think memorising command parameters and key sequences has become a badge of honor because it is difficult but the command line is no longer the most efficient way of doing everything.

<comment><USER8> > This article confuses teaching Unix with teaching programming

I don't think thats true, he references programming in python in there, but he uses the _tools_ programmers generally use (on unix based systems) to program to more sharply contrast it with what the user might expect based on software that _they_ use

> but the command line is no longer the most efficient way of doing everything

I agree with you, but the fact that most of the most gifted programmers I know usually gravitate towards some truly esoteric tools because of the complete control it affords them, negatively (sadly) impacts the rest of the programmers that look up to them

<comment><USER9> >> but the command line is no longer the most efficient way of doing everything

> I agree with you, but the fact that most of the most gifted programmers I > know usually gravitate towards some truly esoteric tools because of the > complete control it affords them, negatively (sadly) impacts the rest of the > programmers that look up to them

I spent years programming with Visual Studio and other IDEs that preceded it. I now work exclusively with "command line" tools because I can't physically use a mouse as my primary input device. I also use Linux now since it isn't possible to navigate OSX as efficiently as I can navigate using xmonad, tmux, and Vim on Linux.

It isn't an exaggeration to say that I owe my career, and my business, to the gifted programmers who maintained and improved the tools that I depend on now over the last several decades.

Is it possible the command line is the most efficient way of doing things and you just haven't discovered that yet?

</comment></comment></comment><comment><USER10> I think the author misses the point. Most users I interact with do not want to learn anything slightly challenging. They either want a magic button to do everything or they want you to do their job. God forbid they read any documentation, watch a quick video or even listen to a simple explanation. They don't need to learn how to program or use the command line, they need to give a shit and do their jobs, which might involve a little initiative and effort.

</comment><comment><USER11> I often teach programming in a community capacity, and I hate _hate_ HATE the "User Culture" that this article points out.

That said, it's absolutely correct, and it gets things done. It makes the users happy, and after a certain point they can pay for better tools or get minions to do the repetitive tasks (scale by hiring more minions, be flexible by hiring smarter minions, etc.)

When teaching you really do need to be careful to take it slow--it's really really easy to jump off into jargon and lose your audience, and people will generally play along to avoid looking stupid. And then they'll never come back.

Communication is the art of projecting your ideas onto someone else's experience, and many first-time programmers don't have anything other than everyday metaphors to rely on. We've gotta be careful with the noobies. :)

</comment><comment><USER12> I think non-programmers have this vision of The Matrix, Swordfish and all non realistic vision of programming. Swarms of text floating down the screen, whilst you're supposed to be pounding the keyboard and writing lots of numbers and equations.

Whilst it's true, we do look at a block of text, it's not always moving and boring. There is a lot of testing and visual feedback for us. Perhaps they get overwhelmed by the Terminal because they think "Oh god, The Matrix. My eyes." but it's not always like that.

<comment><USER6> have you seen the output of make? or pdflatex? if anyone walks by your screen while you're compiling anything, it's going to look like The Matrix, especially if you use a dark terminal color scheme :)

<comment><USER12> > have you seen the output of make?

Yes. That's a good point. Make is awful to read through quickly.

</comment></comment></comment><comment><USER13> Hey, Philip - thanks for posting this and also the previous write-up of your experiences as a helper in the 'boot camp' ([http://pgbovine.net/teaching- librarians-programming.htm](http://pgbovine.net/teaching-librarians- programming.htm)). It is very valuable, including the photos. Very nice, multi-generational group - must have been quite a challenge!

But I agree with calhoun137 when he says there is no fundamental user/programmer culture divide. Programmers are users with a deeper understanding and wider toolset. We all want to get stuff done quickly and move on with our lives rather than drown in computer-driven drudge work. So it seems like a course for beginners should start from that common point, and really be focused on (a) uncovering the problems they're already solving by hacking together the tools they know (e.g. getting data into Excel charts, or whatever) and (b) using the inefficiencies in their solutions to motivate learning or building tools with more leverage, etc.

I can't help but think from your description, the student "regular users" are the ones with a pragmatic/hacker approach, using the limited tools they know -- while the instructor "programmers" are the users stuck in religious attachment to their arcane tools. Maybe the course would go better adopting some of that "regular user culture", AKA hacking ;)

I'm sure it was more complicated than that and for one thing I can really empathize with having to deal with massive variety of platforms etc. Might be worth setting up a common VirtualBox image that everyone (students and instructors) use from day 1, to avoid some of that headache?

Anyway, thanks again for the write-up.

Eric

</comment><comment><USER14> He makes a good point about the difference between users and programmers and how they see software in general. But it seems like the teachers were hopelessly prepared and the subject content poorly put together. I think he also makes some points that are likely incorrect regarding that nature of programmers and their affinity with Unix, probably born out of his bias based on what is popular in Academia.

</comment><comment><USER15> Please, please, please do not teach programming in a 1960s-era style text editor with one font color. Syntax highlighting exists for a reason- it breaks down code into units that we can easily see and understand. If your code is all one color, new programmers will see it as a bunch of foreign gobbledegook, and it will be harder to single out the differences between functions, variables, includes, etc.

<comment><USER16> Would you say the same about another field? Please, when you're teaching literature, don't make all of Shakespeare the same color. The students will think it's all a bunch of foreign gobbledegook. It will be harder to sort the nouns from the verbs and it will be total chaos.

I think you underestimate people.

<comment><USER17> You could publish a book without the use of bold, italics, underlining, indentation... hell, even spaces ([http://en.wikipedia.org/wiki/Scriptio_continua](http://en.wikipedia.org/wiki/Scriptio_continua))!

But why would you? _Emphasis_ is useful. Syntax coloring is emphasis.

Or as HN user 'trevvvor sarcasticly put it: _" Traffic lights should be monotone and drivers should just know what position means what."_ \-- [https://news.ycombinator.com/item?id=6750761](https://news.ycombinator.com/item?id=6750761)

<comment><USER16> OK, so let's consider a spectrum:

* Text being unreadable due to its color.

* Text (in this sense, literature) being unreadable because there are no bold, italics, underlining, indentation.

* Text being unreadable due to no spaces at all.

Would you at least agree that two of these sound a bit like whining in comparison to the third?

Perhaps I'm biased due to my own color blindness, but to me a piece of code without color is pretty much the same, or perhaps even better than the alternative, as I've found the colors and bold can actually make things harder to read. (In particular I've often glossed over comments because some "helpful" text editor made them colorful and less legible.) I thought it was also a clear-cut analogy, though apparently not universal around these parts, that most prose usually tends to read just fine without that _emphasis_ you speak of.

Most of all I was bothered by this careless disparagement of anyone who would dream of seeing text in one color as "1960s" \-- as if that means anything.

<comment><USER17> Few points here:

> Text being unreadable due to no spaces at all."

Text without spaces is readable. Text with spaces is _more_ readable. Readability is a continuum. Literature is _certainly_ readable without bold, italics, underlining, and indentation.

Colored text, for people with normal vision, remains clear. Clarity is not lost, another channel for transmitting information to the user is added.

We don't use _color_ highlighting in books, but perhaps we should. I haven't tried it, so I cannot say it would not be better. I have heard it suggested that coloring lines of dialog would make literature easier to read. I think it is very plausible that Shakespeare in particular could be made more accessible with the use of color. With the rise of ebooks, this sort of experimentation is now feasible and I think that it is likely that we _will_ see people experimenting with this sort of thing as the new capabilities that ebook devices provide give us an opportunity to revisit some traditions that were originally set in place by material constraint.

And lastly, code is not read as literature typically is. Most literature is written with linearity in mind. Most code is written under the assumption that the reader will jump up and down it repetitively, frequently jumping to random locations in the file. Coloring code therefore becomes useful in much the same way that coloring road atlases are useful. You don't need to trace a road back to the nearest label to find out that it is an interstate; you can tell right away because it is blue. That big area inside of that squiggly line? It's a state park, you can tell because it is slightly green, so you don't need to look around on either side for the dotted line surrounding it. That green area in the middle? That's a comment, you can tell without scanning your eyes to either side looking for comment characters...

<comment><USER18> Rubrication used to be a normal thing. It was just harder to do economically for a very long time; there's no reason why we shouldn't do it now for general publications (at least in hardcover and electronic editions).

</comment></comment></comment></comment></comment></comment><comment><USER19> I think that the base premise is faulty here. I use shell (fish, specifically), git and sublime text every day. However, I use them for specific purposes.

If you want to show people what's so good about git, put them in situation where renaming files won't cut it. If the task they have at hand can be effectively solved with renaming files and emailing them, then they don't really need git. Another example: excel. It's an excellent tool for data analysis, especially on the first stage; on my bioinformatics course, it was the first, and by far, the most useful tool I've been taught.

<comment><USER6> _put them in situation where renaming files won 't cut it_

completely agreed, but often the _first_ example you show people needs to be simple enough to grok, not to mention to type. even showing a simple git example takes about an hour to account for typos, environmental mismatches, etc. showing a forking-diff-diffing-fork-merging-rebase-rebasing-merge- pulling-clone-while-solving-two-generals-problem-without-paxos will make people's heads explode. and first impressions often matter, for better or worse.

</comment></comment><comment><USER20> I say this as humbly as possible. I've taught a few classes to newbies for work, and yes, I'm frustrated with how fast the powers that be expect classes to be taught. But one also has to accept how slowly you have to go to teach new material to newbies. I've gotten unsolicited feedback from students thanking me, and one even sent me an email saying I inspired him to learn more, which was really touching. I've also received the "my god, you do it so fast!" comment. So with all due respect reading that post, that's not a symptom of "two cultures" per se, its a symptom of bad teaching, and a complete miss-match of material/audience.

In what possible universe is presenting to a bunch of librarians unix/grep/git/latex/python considered sane? Were the presenters really that mind-blind?

Half of those things are debate-ably not even programming, and all of them should be separate subjects. There is little/no reason to teach UNIX/regular- expressions/git/latex to someone who is learning to program in python, assuming the course is made up of non-programmers and the goal is to introduce programming. Its going to take them months/years before they're even at a stage where they vaguely have a reason to use those tools rather than the tools at hand, and I'm sorry but most of them are not going to stick with it that long. Do you know how long it takes to get assignment/arrays/loops/functions/variables/types/logic all working together? We're talking YEARS! We all forget about it the same way we forget about how hard it is to speak our native tongues, but you might as well fly into a room of native Japanese people reading shakespeare for the lecture. Non-programmers do not understand "AND" or "OR". And you're worried about unix/collaboration tools when they're going to struggle to write a 10 line program by themselves if they're the gifted ones?

If you want to inspire someone to learn to program (and I'm on the fence as to whether its really possible to do so if someone isn't inclined to hack things themselves anyway), then present them a real world task from their work/life they couldn't solve with their current tools. Then you need to show them how to solve it with programming, and only with the amount of programming learn- able (that's how much they can learn, not how much you can present) in the length of the course, so they could do it themselves without you present.

If you cannot do this, either the kind of people who program are likely going to discover such things by themselves, or you're probably wasting your time, because you can bet that they're just going through the motions at their keyboards and their eyes glazed over from the moment you said "statement/expression/function/assignment/Boolean/variable". All your words do not mean anything to normal people!!!

/end rant.

<comment><USER17> > _" In what possible universe is presenting to a bunch of librarians > unix/grep/git/latex/python considered sane?"_

I could see a case for teaching them latex, if only so that they were familiar with bibtex citations.

I learned recently that my alma mater combined their CS department and their library science department into some sort of conglomerate department. I can't say _I_ agree with that decision _(particularly in that case, I perceive it as a continuation of a negative trend in advertising, presentation, and prioritization at that university... but that is a separate topic)_ but the notion that librarians need computer skills above and beyond what the standard modern professional needs is not unheard of.

<comment><USER20> I was actually going to say, i can understand a LaTeX course maybe for librarians :P But i do think it should be a separate course, and you need to be able to explain to them why this is a great thing, and in addition to whatever they're doing at the moment. Plus, it needs to be great enough to overcome any network/lock in effects of "but everyone else does it this way"...(and good luck with that...because that's often the reason we do sub- optimal things in programming culture). You've got to do that and replace what they're doing right now, or helps them solve a problem in and of itself that was previously unsolvable.

Its not that I'm against teaching them such things, its just that it has to be in an environment of suitable context, and at a level expected of not only a beginner, but of a beginner who has never done any programming.

And far be it from me to say so, but maybe...just maybe...there's a reason librarians aren't programmers and are using the tools they have available to them. Maybe its the programmers who are in the wrong. I was shocked when i got into the workforce and discovered that everyone was doing all sorts of IT/admin stuff manually, and thought "if only everyone could program, think of all the efficiency gains!". Now, I'm realizing its a bit more complicated than that...

</comment></comment></comment><comment><USER21> I have always been a GUI person since the Amiga 500 days.

Yes the CLI might be good for certain tasks, specially automation, but that can also be achieved with scripts in languages like Python/Ruby.

The programmers that insist in a term/vi/emacs world are trapped in a 1970's world, loosing the progress that happend in between.

</comment><comment><USER22> An answer that I have given to a friend asking the same question is: Imagine you want to build a big building and you are given as many square boxes as you want, how do you build the building? Easy, you stack a bunch of boxes one on another until you get the shape and size you want. But what if you want to have a triangular roof? You're stuck; theres nothing you can do. Therefore, imagine now, that instead of being given square boxes you are given rectangular boxes. Now in order to build the same house that you built before you need to take a bunch of rectangles and put them together to make squares and then do what you did before. Thats soooo much more work. However, now you can build triangles.

This entire situation is like the programming problem that the author describes: specific tools designed for a specific problem will be easier to use to solve that problem. The moment, however, you want to use that tool to solve a problem that it wasnt meant to, you're stuck.

<comment><USER23> Serious question: Did that metaphor/analogy/whatever actually help your friend? Because I don't get it at all.

<comment><USER24> I think if you replace "rectangle" with "right-angle triangles", it would help immensely.

<comment><USER17> I'm still not sure I get it. Maybe 'triangles are more complex, but allow more complex results, like programming languages are more complex than other input languages humans use (like shortcut/mouse-action languages used in GUI programs like Photoshop), but programming languages allow more complex results'? In other words, triangle building block languages are the building- block equivalent of Turing equivalence?

<comment><USER24> I think the basic premise is:

Programming languages are the building blocks for all tools. When faced with a broken/useless tool, knowing how to build a new one is useful.

</comment></comment></comment></comment></comment><comment><USER25> So this is like complaining if you do a car maintenance course at your local college you have to _GASP_ use spanners and OMG might get some of that nasty dirty oil stuff on your hands.

<comment><USER6> interesting analogy, but i think the difference is that we intuitively understand what spanners and nasty dirty oil is, since they're physical objects that we see in daily life. so if i take a car maintenance course, i expect to get dirty. all of this magic inside of the computer is invisible. but you do make a good point, and one that i'll try to address in a future revision!

</comment></comment><comment><USER26> I don't know what kind of masochist would use find as an example of how the command line works.

</comment><comment><USER27> Please don't pipe the output of find into xargs. Use the -exec flag instead.

<comment><USER28> Why?

<comment><USER29> It is slightly more efficient. It also avoids some potential error cases when/if you have files with unexpected characters (for example spaces) in their names.

</comment></comment></comment><comment><USER30> This guy didn't even bother to name his computer!</comment>


Web Based Desktop - Very Impressive - <AUTHOR> http://extjs.com/deploy/ext-2.0-alpha1/examples/window/desktop.html

<comment><USER2> We are using extjs in our next UI version...the widgets are awesome. The docs are sometimes a bit terse. The examples are usually contrived in ways that completely avoid real world requirements...which often turn out to be quite complex to get working. Stuff like setting the selected item in a combo box that is generated via a JSON object takes several steps, and pre-loading a TreeMenu is laughably complex. It often feels like the goal was to make as much as possible load on-demand, with no possibility to use those widgets without the lazy-loading features...which makes it much slower to use in every use case I can imagine...we wrote our own tree menu that loads all items in one go instead of fighting with it anymore. Also, sometimes things change pretty dramatically between versions.

But it's the best thing we've found for our needs. It looks great, runs fast, and the developers offer reasonable commercial support.

</comment><comment><USER3> That is very responsive... impressive, indeed. There was even transparency while moving windows around. Right-clicking on the taskbar brought up a context menu. Overall it's a nice proof of concept.

</comment><comment><USER4> Their AIR application is quite impressive too: [http://extjs.com/blog/2007/06/29/building-a-desktop- applicat...](http://extjs.com/blog/2007/06/29/building-a-desktop-application- with-ext-air-aptana-and-red-bull/)

</comment><comment><USER5> Quite slick.

</comment><comment><USER6> there's a bug for the scrollbars, it overlaps other windows.</comment>


The ultimate weapon against GamerGate time-wasters: a 1960s chat bot - <AUTHOR> http://www.newstatesman.com/future-proof/2014/10/ultimate-weapon-against-gamergate-time-wasters-1960s-chat-bot-wastes-their-time

<comment><USER2> Amusing, yes... but otherwise dickish (it's still spam from a bot) and unimpressive. Even fairly brain-dead responses will emit a reply from _somebody_ , just like sending 419 scam.

</comment><comment><USER3> Anyone interested in learning more about GamerGate is well-advised to visit [http://www.reddit.com/r/KotakuInAction](http://www.reddit.com/r/KotakuInAction) (KiA). The sub is highly active and the wiki is reasonably well-curated. Polite, rational skeptics are welcome.

<comment><USER4> [http://rationalwiki.org/wiki/Gamergate](http://rationalwiki.org/wiki/Gamergate) is extensively referenced. Don't just believe the text - check the references.

<comment><USER3> > Don't just believe the text - check the references.

I've already read almost all of those references. The story told by the wiki article is downright comical in its misrepresentation of those references.</comment></comment></comment>


What to do if the Space Shuttle payload bay doors won't shut properly - <AUTHOR> https://waynehale.wordpress.com/2019/09/25/oops/ <comment><USER2> I visited the mentioned Air and Space Museum Annex this past weekend. It's well worth the effort if you're in the area, and IMO a better destination than the location on the National Mall.</comment>


Are Co-Founders in the Same City Really an Advantage to a Start-Up? - <AUTHOR>

Most founders will tell you (and it's the stance that Y Combinator takes) that being in the same physical location as your co-founders is critical to success.
My co-founder and I seem to work very well at a distance. Frankly, I don't see the advantage to being in the same place.
Sure, very occasionally there are things that would go faster if I could draw them on an actual whiteboard instead of a virtual one. But these moments are rare.
Basically, I think virtual communication is something you learn how to do. Since we're not in the same location, we're very used to using tools and communication styles that provide the same advantage as being in a room together.
And there are many, many advantages for us to start an entirely virtual company. Primarily, when we do have to grow our company we're going to be able to hire the best people in the world (as long as they have a good Internet connection.) This seems like a huge advantage over Google, who can only hire the best people within an hour's drive of Mountain View. It opens up an entire new pool of talent for us.
Other advantages:
1. No rent for office space and no commute.
2. We can hone our communications techniques so that we're ready to scale when we inevitably need to have people in multiple cities working together. 3. People get to work in an environment where they're most productive.
4. We cover more of the world so one of us is usually close to an investor or customer that wants to have an in-person meeting with.
5. Since we cover more of the world the company as a whole has more perspective.
As to arguments on the other side, the only one I can think of is:
1. It's easier to communicate, and thus easier to get things done. (But with modern communications devices, e.g. a screen recorder to capture exactly what's going on my system so that the programmer can how I produce the bug, I remain unconvinced that in-person speed of communication is anything more than a slight advantage that is greatly outweighed by the disadvantages of not being an entirely virtual company.)
Are there other advantages to in-person interactions that I'm not thinking of? <comment><USER2> YES THIS IS HUGE TRY TO BE IN THE SAME CITY.

Context: I started my company in 2005 from Ann Arbor (which quickly became Chicago) with 2 partners in NYC. Here's what we learned:

* It is very hard to get funded if you're not all in one place. Also, my previous startup, from '99-'01, relocated everyone as soon as the A round closed.

* All-hands company meetings are very hard to do, because they take the form of interminable phone calls instead of lively back-and-forths.

* Software design debates rapidly turn into a game of telephone.

* It's much harder to guage the mood of the team; we lost 2 people because they were unhappy about stuff that might have been resolved had we caught it earlier.

* Solo founders in far-flung branch offices quickly feel out of the loop, which sets up a bunch of vicious cycles involving security, assertiveness, style, and communication.

We've made it work by growing through it, painfully; we now have so many people in just two offices that there's a cameraderie and common purpose (I'm dignifying it, yes). It's still more painful than it would be if we were all in one place. I haven't said this anywhere but here, but we'd have shipped 9 months ago (as opposed to weeks ago) if we were all together.

The company I worked for between startups --- Arbor Networks (a startup, but I didn't start it, and I was employee #40something) --- has a business office in Boston and engineering in A2. This, too, was a debacle. Engineering and management are "us vs. them" in the best of circumstances.

More points:

* No rent for office space is not necessarily a win. We could all work from home in Chicago. But having an office is great, partly for the same reason some people _like_ wearing suits in NYC --- act the part, be the part, etc.

* People are often wrong about where they're most productive. If people are unproductive in an office culture, you may just have the wrong office culture. In Peopleware, Tom DeMarco lays out a great strategy for a skunkworks-style office to house a product team. Peopleware is excellent, read it!

* You're also missing out on the social aspect. How often can you all go out for dinners? When you have a shitty day and you're all pissed at each other, can you go out for a beer? (A teammate I yelled at once brought in a six pack at 2 in the afternoon, killing the work day and resolving the problem). Yesterday was my block party; everyone in my office showed up. How much cooler would it have been if the NYC crew was there too?

* Some really excellent players simply get lonely working from their home or in a tiny branch office. Some of them know it already and won't consider you. Some of them find out after they join and quit in the middle of a cycle. Obviously lots don't, but why cut your chances at all?

<comment><USER3> For the last few months I've been part of a distributed team of 4-5 members. First time for me--all my client work has been remote, but It's usually just me and at most one other person.

I haven't had much trouble working with one other person, like the first poster modern communication tech does it fine for me. People complain that physically meeting only scales to as many people as can fit comfortably in a small conference room, but I'd say meeting electronically doesn't really scale past 2 or 3.

Even with just a 4-5 member team, all hands meetings are indeed phone calls that drag on (we're getting a bit better at keeping them brief).

And "software design debates rapidly turn into a game of telephone"--oh yes. I may be wrong, but I fancy I have an excellent memory for the points and outcomes of such discussions, and it's endlessly frustrating to me to recap over and over when the same thing comes up next week, and the week after, etc.. Actually I don't know if that would be improved by being closer--besides this, the largest software team I've been on was 3 in person, years ago.

On the other hand, the other four or so members of the team all are on the west coast and have met--I'm the only one on the east coast. That's a problem for scheduling meetings sometimes, but I don't feel out of the loop or insecure. Part of that, no doubt, is that I'm not a founder--just a contractor. I care about the product as something I've put substantial work into, but it's not my baby and I'm not worried about someone stealing my baby away. There are four of us contractors building the product for the two not- very-technical founders. I guess that's another hot topic.

</comment></comment><comment><USER4> FWIW, David and I worked together 7 time zones apart for 4 years or so before he finally came to Chicago in 2006.

David wrote the code for Basecamp in Copenhagen and I designed the interface in Chicago.

The distance was a big advantage to us. It helped us each focus on what we were good at without too much meddling. When you're close it's real easy to spend time worrying about stuff that doesn't matter. When you're further apart you tend to actually focus on the work since that's the only thing you can do.

Your mileage may vary, of course, but that was our experience.

<comment><USER5> I would echo these sentiments. Sachin and I worked on Posterous.com remotely (I was in Mountain View and he was in NYC) for the months before we applied and were accepted to YC Summer 2008. We could work independently for long stretches and get large pieces of functionality done fast just over IM.

In fact, we've found this summer in Cambridge that the times we've been really able to crank out code are the weekends when one of us is traveling and one of us hangs back at the ranch. Complete control over distractions = gigantic productivity boost.

</comment></comment><comment><USER6> As the company grows, the extra friction on communications between the two locations becomes more of a problem. My company, Kongregate, has 10 people in San Francisco and 5 in Portland, Oregon. We make it work through all the methods you describe, but the couple of weeks a year when we all gather in the same place are definitely easier.

<comment><USER7> I love you guys. Thanks for finding a business model that helps support independent game developers like whoever wrote that Desktop Tower Defense game.

</comment></comment><comment><USER8> You make a good case, but what I fear is that you have not really experienced working in the same location to really know the "advantages". Its one thing to hear or read the advantages, but its a whole another thing to actually experience it.

My co-founder and I tried working remotely, and although productive it is nothing compare to being in the same room. I finally decided to move to where he is for 3 months.

(Your Point #1): I sub-leased an apartment and setup shop in the living room of a 1 bedroom apartment. It's closer to his house so the commute isn't that bad, since I live here I only pay rent and not a lease on an office.

(#2): Communication techniques for remote work won't come in handy once you get funding and are asked by the VCs to move to one city. Knowing how well you work with your co-founder(s) in the same space before funding is very valuable.

(#3): Working in a productive environment is definitely key, but you have to make it productive no matter where you are since you are a startup. It could be a coffee shop if it HAS to be.

(#4): Investors want to meet the entire team, they will be concerned if you mention "we work remotely."

(#5): No one starts a global company, they start a company that goes global.

It is a strain on finances but its good to do it for 3 months at a time, specially in summer time because in big cities you can get sub-leases for short period (furnished).

Good luck!

</comment><comment><USER9> _1\. It's easier to communicate, and thus easier to get things done. (But with modern communications devices, e.g. a screen recorder to capture exactly what's going on my system so that the programmer can how I produce the bug, I remain unconvinced that in-person speed of communication is anything more than a slight advantage that is greatly outweighed by the disadvantages of not being an entirely virtual company.)_

That's easy to under-estimate. The best way I've seen this explained is the following: imagine that each time you have a question, there's a ten minute delay to getting an answer. In a start-up, things are constantly shifting, and the product design will need to shift with them, so chances are you'll have a lot of questions. If you have, say, 15 (serial) questions a day, that's 2.5 hours of extra waiting time a day, so more than 25% extra time added to the critical path, roughly. That could make the difference between delivering within your tight budget and failing to do so.

Even worse is the questions you choose not to ask because it's too much overhead. Those can cost you abortive work, or cause you to miss out on a cool idea because you didn't discuss it with your cofounders.

I started my first start-up with a friend in Leicester while I was in London, and while it's definitely possible, that friend is basically my best friend that I've known for ten years, and I took trips up to Leicester regularly, and still we struggled somewhat. Obviously it can be done, but it is an extra hurdle, and you should be aware of it and spend extra effort to make up for the downsides.

For my current start-up, I work from home, and we have one developer in Kansas, but our CEO/product guy is in London too, and I spend a day a week with him, and that's working alright. We don't have offices, but at least we have strong communications between the business and tech sides.

Overall, I support the idea of a completely virtual company, and that's the direction we're trying to take this company in - but you should be fully aware of the challenges of it. It seems you are, so go for it! Good luck! :-)

</comment><comment><USER10> There are always exceptions, if it works for you, more power to ya. Just make sure it really is best, and not just you making the excuses to yourself to justify it

</comment><comment><USER11> You're going to have to be together at some point, and if you aren't 100% sure that will work EARLY, you could be doomed. You need the brainstorming back- and-forth for new ideas and to see new market challenges. You also aren't considering the time when you need to hire more employees, all of which you want corresponding with you and giving you new ideas.

It's also easier if you all are together when times gets tough and motivation wains.

</comment><comment><USER12> fundraising is easier if everyone's in the same spot, because raising money has to do with building relationships and that's best done (perhaps?) with people local to the team. investors get to know the team, etc, then invest in them. in the least, this is an obstacle we've faced.

</comment><comment><USER13> for someone who is thinking of what tools available. Here is small list of webapps for collaboration <http://blog.proto.in/2008/05/28/the-startup-kit- part-i/></comment>


This could be the Apple iCloud flaw that led to celebrity photos being leaked - <AUTHOR> http://thenextweb.com/apple/2014/09/01/this-could-be-the-apple-icloud-flaw-that-led-to-celebrity-photos-being-leaked/

<comment><AUTHOR> Bigger discussion: [https://news.ycombinator.com/item?id=8251945](https://news.ycombinator.com/item?id=8251945)</comment>


Impact of memory allocators on MySQL performance - <AUTHOR> http://www.percona.com/blog/2012/07/05/impact-of-memory-allocators-on-mysql-performance/ <comment><USER2> I'd re-run the test to sweep out best tcmalloc cache size parameter. People often misunderstand the effect of TCMALLOC_MAX_TOTAL_THREAD_CACHE_BYTES ... this environment variable controls the total size of all thread caches in the program, not the size of the cache in each thread. It defaults to 16MB which is probably about right if you're running your database on a 486. If you're using 1536 threads on a 50GB database you may enjoy significant benefit from increasing this parameter. Increasing it a lot.

<comment><USER2> Searching for TCMALLOC_MAX_TOTAL_THREAD_CACHE_BYTES on Google shows that pretty much nobody knows about this or if they do they aren't talking about it.</comment></comment>


Archaeologists use radar to find a Viking ship buried on an island - <AUTHOR> https://www.washingtonpost.com/history/2019/12/04/archaeologists-use-radar-find-massive-viking-ship-buried-an-island-millennium/ <comment><USER2> [https://arstechnica.com/science/2019/12/archaeologists- find-...](https://arstechnica.com/science/2019/12/archaeologists-find-a- viking-ship-buried-in-a-norwegian-field/)

</comment><comment><USER3> It's paywalled. Buried like a Viking ship.

<comment><USER4> Google: Viking ship radar

And you'll find a dozen stories written about it.</comment></comment>