Ask HN: What made you change your mind about a programming language/paradigm?

Same, except I realized this after starting my first (and current) job as a C developer.

I now get way more annoyed by the in-house build system than the huge C codebase.

I the early Nineties, I had a good idea of what an ideal programming language would be. Then I encountered Perl, which was diametrically opposite to everything I thought I wanted. Perl enabled me to do in a morning what would have taken a week in C. I was blown away. I was converted. I became a Perl evangelist. I used Perl everywhere I could.

20-odd years later, writing Perl for fun and C++ for money, I had a Perl program which, over ten years, had gradually grown to about 5,000 lines and 25 classes. It needed more testing than anything else I maintained. I missed the help I would have got from a C++ compiler -- what some Perl people disparagingly call BDSM. In C++, if I need to add a Widget argument to a leaf method, the compiler will find all the call sites that need updating. If they in turn need updating to accept a Widget, the compiler will find their call sites, and so on. By the time the program compiles again, it's much of the way towards working. But Perl doesn't do that for me. I can't even specify the number of arguments a method should take, let alone their types.

I eventually rewrote the whole thing in D. It came out at almost exactly the same length, which was a surprise, but I got native speed, much-reduced memory consumption, and proper type-safety. My hunch is that a translation to modern C++ would have been longer and taken more work than doing it in D, but not that much more, and the performance would have been better still.

This is not so much a story about Perl, C, C++ and D as about weakly- and strongly-typed languages. (Perl 6, in particular, remedies some of the deficiencies in Perl 5's type system, and some of the bolt-on object systems for Perl 5 take steps in that direction as well. These are heroic and ingenious efforts to give users the best of all possible worlds, to the extent that that's possible, and I wish them well.) Languages that are too weakly typed, too dynamic, too flexible, are fine for short programs that are maintained over a short period of time, but they just don't scale -- maintenance becomes too difficult, too time-consuming and too error-prone. At some point, it's best to rewrite in a well-chosen language that imposes more structure and provides more type-safety, and work with that structure (not against it) to make your program rigid enough to stand up under its own weight.

As a result of that experience, I no longer use Perl, or any other very dynamic language, for anything but the smallest throwaway programs. For everything else, I anticipate the need to grow by using C++ or D, and the next language I learn is more likely to be Rust than, say, Python.

A more general point: if you only know one composer, one band or one style of music and you think the rest aren't worth knowing, you don't know music. Even though I don't use dynamic languages much nowadays, I'm a stronger engineer for having done so. Do take the time to learn several different languages that differ widely from each other and from what you already know -- preferably including some assembler -- and don't assume that the language of the month is best suited to your unique temperament or to the job in front of you. Having an abundance of tools and choosing between them wisely is better than having one and using it for everything. It doesn't matter how dexterously you can use a soldering iron when what you need is a chainsaw.

> What's the correct way to use typescript...

You write TypeScript the same way you write JavaScript. It just enforces a lot of the proper discipline and practices that JavaScript doesn't, and it doesn't let you incorrectly use APIs.

> you're explicitly asking for things you know you have in your document, but it reports an error

I'm not 100% sure what you're talking about, but I bet you'd get a great answer on StackOverflow by posting example code and the error message.

First of all, TypeScript doesn't know what's in your document unless you built the document with TypeScript objects. If it's HTML, TypeScript can't read or understand it.

My guess is that you're using something like "getElementBy..." and then TypeScript complains that you're using a value that might be null. You just need to check if the value is null and (for example) throw an error. Once you do that, any line after the null check will assume there's a value.

There are other workarounds when you're 100% sure you don't need TypeScript's error checks (like // @ts-ignore flags), but I strongly recommend against using them.

> using minimal jQuery

Why are you using jQuery at all? It's a solution for a problem that doesn't exist anymore. Just use vanilla JS.

As someone who appreciated C and C-style languages I hated on python for a long time.

I disliked python because of syntactical annoyances,mistakes I would notmally iron out at compile time now happen at run time and version fragmentation with no backward compatibility at times. On that last point,new java versions for example would deprecate features over time allowing the programmer the option of enabling these features. I still think the simple things like mixing tabs and spaces shouldn't have caused a hard failure,warnings or ability to override the deprecation would have been nice. Not only that,I hated how I would ship a python program having tested it in one python version and five years from now the default python version on linux distros (or default installer for windows) would install an incompatible version,I hated how users of my program would have to figure out the correct version.

But I no longer hate python mostly as a result of having seen how easily it has helped me solve different types problems that are otherwise difficult or time consuming to solve. At the end of the day,it gets the job done well,is easy to learn,harder to screw up in and has saved me a ton of time.