111–120 of 143 posts
It would be nice if some research institution would pay for the rehabilitation of some huge, bloated, ancient, but relatively unimportant app. Ideally by independent teams in parallel. Just to get some real data on what works, rather than anecdotes from veterans.
It would be nice if some research institution would pay for the rehabilitation of some huge, bloated, ancient, but relatively unimportant app. Ideally by independent teams in parallel. Just to get some real data on what works, rather than anecdotes from veterans.
I enjoy refactoring, I'd help with something like this.
The amount of code you have in a company is usually a function of the amount of engineers you have.
Earlier quoted context omitted.
The correct solution is to version the standard library separately from the language and allow for versioned dependencies, then a new language/VM update doesn't imply a new library that breaks everything, and vice versa. But python grew up in an enviroment where this sort of thing was not practical, and the batteries included is actually a good approach for what python tries to do - scripting. It just doesn't scale w…
Once you have the standard library split apart, you might as well split it up, though, and then you don't really have a standard library any more. You could go the Haskell Platform route... which isn't a wonderful idea.
It's a bad idea, on short timeframes. But it's a hell of an adaptability bonus that ensures the language will keep improving.
Just like Haskell's extension system, or its loose dependency on Prelude, or its multiparadigm emulation.
I keep hopping something better than Haskell appears and people move on - but it probably won't happen any time soon, as soon as something better gets traction, Haskell will simply devour it and keep growing.
Earlier quoted context omitted.
You can find these places everywhere. Look for jobs where the software department isn't the core business and you'll find small groups of devs bogged down trying to implement another customization among code that looks like switch(clientId){ case 42: //todo: Make sure database agrees ... } before each calling what are essentially copies of otherwise identical thousand line functions. Because the "risk" of actually ch…
Rewarding in which way? Getting to really improve the codebase? Compensation?
Earlier quoted context omitted.
I enjoy refactoring, I'd help with something like this.
I think the pain in refactoring is not the refactoring itself, it's the weeks spent creating a mental map of a foreign and architecturally broken codebase (but which sorta works). Even to write the non-reg tests before even considering the refactor, much time must be spent becoming an expert in something that will die soon.
Seriously, this sounds like exactly my kinda gig.
Earlier quoted context omitted.
I don't follow. What does it tell?
Have you heard of the term/phrase "bro science" with respect to weight lifting? I'd draw an analogy between them. Clarification: what I mean is there is a lot of ad-hoc stuff in these blogs that may be narrowly true or applicable to a given project or subset of a domain, but generally there is either significant evidence against some of these blogs' contents or the contents themselves have absolutely no formal, rigor…
Nice analogy btw.
Earlier quoted context omitted.
That's by far the best way to work. It's hard to explain to someone who hasn't experienced it how much easier it is to develop in a bug free code base.
I challenge that; I don't think a "bug free code base" actually exists. Joshua Bloch has a great article about this which I think may be of interest to other readers: https://research.googleblog.com/2006/06/extra-extra-read-all... . To paraphrase: We programmers need all the help we can get, and we should never assume otherwise. Careful design is great. Testing is great. Formal methods are great. Code reviews are gre…
At other places I've worked, I wouldn't raise an eyebrow if I found 3 bugs in a day, just trying to get other stuff done.