• 1 Post
  • 200 Comments
Joined 2 years ago
cake
Cake day: June 12th, 2023

help-circle


  • I’ve almost completely stopped using them, unless I’m stuck at a dead end. In the end all they have done is slow me down and make me unable to think properly anymore. They usually write way too much code, especially with tab complete stuff, resulting in me needing to delete code after hitting tab (what’s the point even, intellisense has always been really good and now it’s somehow worse). They’re usually wrong unless prompted multiple times. People say you can use them to generate boilerplate, but just use a language with less or no boilerplate like Kotlin. There’s usually very subtle bugs they introduce or they’re solving a problem that is simply documented on stack overflow, while I wouldn’t be using an LLM if I could just kagi it, so they solve the wrong thing.

    One thing it’s decent for, if you don’t care about code quality, is converting code to a language you do not know. You’re not going to end up with good idiomatic code at the end, but it will probably function.

    None of this is to say that the LLMs aren’t amazing, but if you start to depend on them you very very quickly realize that your ability to solve more complex problems will atrophy. And then when you get to a difficult problem you now waste much more time trying to solve a problem that might have been simpler for past you.














  • Article written like it’s someone that just discovered types even though a majority of the programming world said to use types for decades…

    Also I completely disagree with the assertion that you should write everything including backend in typescript in order to share types. You should be using a schema and generating your types if you are writing large systems. That way any service that uses your APIs can generate the types as well and isn’t locked in to your language.

    And please dear lord stop writing backend code in JavaScript or typescript or any scripting language.

    Other than that, yes, use types. They literally do exactly what every proponent of types has said they do for years. Turns out it’s a huge benefit!




  • Ruby and Python are both scripting languages and have been since being invented. Static type annotations are a dumb thing to add to a language like Python and Ruby, they’re not static languages. If you want static typing you should be using a different language. The syntax is most definitely not worse, and that’s not an opinion, Python’s for comprehensions are nightmares of readability, and hardly make sense 5 minutes after you write them. Ruby prioritizes readability over everything else.

    Speed is almost exactly the same, with Ruby winning on many benchmarks. The only people saying Python wins are Python programmers. There was a post on the clojure community the other day comparing specific instances and while clojure was winning them all, Ruby was in second on most of them.

    Python only looks better from the outside. I spent years coding in both at the exact same time at the same company. The only two things Python wins on is number of packages, and even that is a dumb metric (looking at you npm), and Click, which is an absolutely fantastic CLI framework.


  • I haven’t heard that in 15 years. The main reason to use Ruby is that it’s a better Python. The tooling is 10x better, it has all the same language features and more, it has easily enough packages to handle any situation you want, and it doesn’t have all the bike shedding that Python has.

    You shouldn’t be writing applications in a scripting language anyway. They’re for scripting, it’s in the name.