4 ms·

No, I'm getting sick of my code being broken. My C code from 15 years ago works fine, but code in other languages can end up breaking within a year. I've moved

No, I'm getting sick of my code being broken. My C code from 15 years ago works fine, but code in other languages can end up breaking within a year. I've moved much of my development back to C++ just so I can have reasonable confidence my code will work when I come back to it in a couple of years. I don't care if Python 2.7 never gains another feature, as long as my code will still work in Windows 13 and Mac OS X 10.17.

afarrell 10y ago
How many dependencies maintained by others does your Python 2.7 code rely on?
ieverdream 10y ago
right tool for right job :). You use python for specific purpose, if the Python won't be maintained anymore, you can keep the current compiler, so it doesn't matter.
Svenstaro 10y ago
Your C code might still work but are you not relying on any libraries which might have been updated in 15 years in a non-backwards compatible way and thus broken your build?
- CJefferson 10y ago
  It's not perfect, I'll admit. I'm probably in a special area -- algorithms research. I tend not to use many libraries, and I'm often taking code written 10-20 years ago and wanting to get it working. The code is often VERY complicated, and I don't really want to reimplement it. Finally (and probably most importantly) I don't care about security holes, I'm not going to run this code on malicious input.
StavrosK 10y ago
My python code from 2000 will be supported until 2020, so I'm not sure which language you refer to when you say it'll "break within a year".
ben_jones 10y ago
There's something to be said about "small" languages. Whenever Golang does a point release I update all my production code without a fear in the world, not because I have to, but because their may be a performance improvement here or there that I get for "free". I think I skipped 1.5 and 1.5.1 because of a slight regression when they switched to a go-based compiler/runtime but other then that yeah, awesome. Conversely I'm always behind on Node as it's realllly annoying when a third-party lib breaks from an update. Larger packages will be fine but when you're dealing with say a Meteor package derived from an NPM package it's pretty shitty.
fallenshell 10y ago
It's called "moving forward". The technology sector moves fast, and you need to keep up. Nothing is ever going to get better with that sedentary mindset.
- shawkinaw 10y ago
  Well, if you ask me, backward compatibility should only be broken with extreme reluctance, because it's a huge waste of time to be rewriting things that already work. See also Angular 2.
  - fallenshell 10y ago
    This was a major release. 2 to 3.
dalke 10y ago
How is a language supposed to make backwards incompatible changes, when it's eventually found that the original style contains substantial flaws? Would you want the world to still be using K&R C? Because I remember the transition from that to ANSI C, and the special macros to make function prototypes work across both languages. The Python transition is little different.

afarrell 10y ago

How many dependencies maintained by others does your Python 2.7 code rely on?

ieverdream 10y ago

right tool for right job :). You use python for specific purpose, if the Python won't be maintained anymore, you can keep the current compiler, so it doesn't matter.

Svenstaro 10y ago

Your C code might still work but are you not relying on any libraries which might have been updated in 15 years in a non-backwards compatible way and thus broken your build?

CJefferson 10y ago
It's not perfect, I'll admit. I'm probably in a special area -- algorithms research. I tend not to use many libraries, and I'm often taking code written 10-20 years ago and wanting to get it working. The code is often VERY complicated, and I don't really want to reimplement it. Finally (and probably most importantly) I don't care about security holes, I'm not going to run this code on malicious input.

StavrosK 10y ago

My python code from 2000 will be supported until 2020, so I'm not sure which language you refer to when you say it'll "break within a year".

ben_jones 10y ago

There's something to be said about "small" languages. Whenever Golang does a point release I update all my production code without a fear in the world, not because I have to, but because their may be a performance improvement here or there that I get for "free". I think I skipped 1.5 and 1.5.1 because of a slight regression when they switched to a go-based compiler/runtime but other then that yeah, awesome. Conversely I'm always behind on Node as it's realllly annoying when a third-party lib breaks from an update. Larger packages will be fine but when you're dealing with say a Meteor package derived from an NPM package it's pretty shitty.

fallenshell 10y ago

It's called "moving forward". The technology sector moves fast, and you need to keep up. Nothing is ever going to get better with that sedentary mindset.

shawkinaw 10y ago
Well, if you ask me, backward compatibility should only be broken with extreme reluctance, because it's a huge waste of time to be rewriting things that already work. See also Angular 2.
- fallenshell 10y ago
  This was a major release. 2 to 3.

dalke 10y ago

How is a language supposed to make backwards incompatible changes, when it's eventually found that the original style contains substantial flaws? Would you want the world to still be using K&R C? Because I remember the transition from that to ANSI C, and the special macros to make function prototypes work across both languages. The Python transition is little different.