> given the abysmal quality of this thing, nobody will ever insist that they release the sources
I am interested in seeing the source :)
Project from Hell (2008)
101–110 of 157 posts
Re: Project from Hell (2008)
#102Earlier quoted context omitted.
C++ is only "fast" because people who care about performance use it and a lot of people who are good at compilers work on gcc/intel/llvm. If the LLVM team decided to spend 5 years making python "fast", I bet they could make it benchmark just as well as C++.
No, It’s not possible to optimise Python like c++ because of the characteristics of the language. Plenty of very good people are working on Python optimisation and it’s still painfully slow and will always be.
> Plenty of very good people are working on Python optimisation and it’s still painfully slow and will always be.
Pypy etc never had the resources to build a truly amazing Python implementation. With Oracle throwing their weight behind Graal there's now ZipPy: http://thezhangwei.com/documents/oopsla113-zhang.pdf
Backwards compatibility with native extensions is the single biggest problem preventing optimising both Python and Ruby. If we could completely throw out C API compatibility like LuaJIT did, then we could make huge improvements to Python and Ruby performance and memory usage.
Re: Project from Hell (2008)
#103Earlier quoted context omitted.
C++ is only "fast" because people who care about performance use it and a lot of people who are good at compilers work on gcc/intel/llvm. If the LLVM team decided to spend 5 years making python "fast", I bet they could make it benchmark just as well as C++.
There's more to it than that. C++ is designed for implementations to produce fast code. "Leave no room between C++ and Assembly" has been a guiding principle of C++. This is not true of Python, and thus the engineering effort required for an implementation to reach the same level of performance is huge, if at all possible.
LuaJIT can do it and ZipPy + Graal + JVM should be able to get close enough to make a massive difference to Python performance in the near future.
Re: Project from Hell (2008)
#104Earlier quoted context omitted.
No, It’s not possible to optimise Python like c++ because of the characteristics of the language. Plenty of very good people are working on Python optimisation and it’s still painfully slow and will always be.
Perhaps you should consider this a different way. Consider the end to end performance of a system - from inputs in (say, timesheets and HR data) to outputs out (bank payment APIs called, emails sent). Would you bet the end to end performance of a system built by mediocre C++ programmers would be better than that of a system built by mediocre Python programmers? I certainly wouldn't.
To elaborate a bit: what I mean is, it is easier to build an acceptably performant system in Python than in C++.
Yes, an arbitrary algorithm will probably perform significantly faster in C++.
But that probably won't matter in a real-world system built from multiple integrated components, when the performance is more likely to be determined by the abstractions chosen and the system architecture in use. And IMO Python and its surrounding ecosystem makes it easier to make good choices in those areas.
Re: Project from Hell (2008)
#105Earlier quoted context omitted.
A startup I once worked at a decade ago decided to hire a sales executive in the UK. They initially hired him as a contractor and only made him a full-time employee a few months later because in the UK you can easily fire a contractor but not an employee, and they really wanted to make sure the guy they hired was the right person for the job. (To answer the inevitable "was he the right person?": Yes, he was. EMEA was…
You can actually fire without cause in the UK within the first 2 years of employment. Until that period elapses they have no recourse unless they can show discrimination on a protected ground (e.g race, pregnancy). However, most UK employers would use a probation period or initial fixed term contract (true employee with a fixed end date), rather than a non employee contractor. It is unlikely your company hired the gu…
Eh, I don't know the exact details. I just remember what my boss's boss told my department at a staff meeting one day.
Maybe it was an initial fixed-term contract.
Re: Project from Hell (2008)
#106I'd love to see this project on Github, though I'm sure that'd be highly unlikely - it's probably mired in a bunch of red tape, and there's probably some ridiculous technical reason why that wouldn't be feasible.
Re: Project from Hell (2008)
#107I think I've used the source code control system mentioned in the article. It was indeed a pile of garbage. Took a couple days of training in it, and the folks running the class kept telling us not to use certain checkboxes and features of the UI "or bad stuff will happen".
Re: Project from Hell (2008)
#108I think I've used the source code control system mentioned in the article. It was indeed a pile of garbage. Took a couple days of training in it, and the folks running the class kept telling us not to use certain checkboxes and features of the UI "or bad stuff will happen".
Just curious. What is it?
Re: Project from Hell (2008)
#109Way cheaper than jsf in USA. Also in c.
Re: Project from Hell (2008)
#110There are a lot of jobs like this in economies where stasis and stability are prized over creative destruction. These organization continue to exist because companies are considered sacrosanct ... they are sources of jobs that are to be protected at all costs. The jobs themselves are sacrosanct. Very hard and slow to fire people. So people hire slowly. So there are few jobs. So the few open positions are positions where the employer abuses the employees.
Have you ever noticed how many smart French programmers there are in the USA? People vote with their feet when given a chance.