CyberFonic
Joined 17 years ago
Joined 17 years ago
Hate to put it bluntly, but you are attempting to swim against the tide by attempting any form of debate and examination of dissent. The management team around you have played their hand. It appears that you are vastly out-numbered.
You have two choices: go with the status quo; or the highway.
Power CPUs tend to power either iSeries (latest iteration of AS/400 - System38 etc) systems or AIX based. The large AIX systems use lots of CPUs, cores and typically vPars - but I wouldn't call them supercomputers. Disk I/O is generally FC attached SAN, i.e. performance is achieved through off-loading. A typical SAN array contains gigabytes of caching memory, CPUs on each disk drive with yet more RAM and multiple optical FC links to each node.
Use Power RISC with AIX in established IBM user organisation that wanted to run Unix software so we ported existing software to AIX.
Use existing s390 system running several core systems, to run Unix partitions to deploy software already written for Unix in C.
I have never even heard of any company not already being an IBM account migrating to either of those systems. The capital and operating costs are typically far higher than for comparable performance x86 based deployments. Technical staffing is much harder still.
I have worked extensively in finance and have never seen nor heard of a PDP-11 being used. A long time ago some DecSystems were in use. But those were all programmed in COBOL.
When you are new in an organisation, it is very common to feel awkward in making smalltalk and being remote would make it even more so. What technology are you conducting your conversations with? With Zoom you can read body language, etc. Using messaging alone provides far less clues.
I presume that you have been assigned a mentor and some tasks to perform. In which case, I would expect that your conversations pertain to the work you are doing and not shooting the breeze by the water cooler. Perhaps a good starting step would be to talk about aspects of the tasks at hand and then expand from there, asking about the decisions that led to the design / architecture / tool choices and from there the roles and personalities involved.
So they are not only saving on salaries, but on rents as well. Cheeky bastards.
If you want to paid very well, then churn out thousands of lines of rubbish code, be in the office for 70+ hours, attend their meetings, pay rapt attention to their PowerPoints and laugh at their jokes. Bingo!
As always, best to choose the tool / language that best suits the problem.
There are many Common Lisp and Scheme environments. Many have excellent JIT compilers. They all have their relative strengths and weaknesses. So it really depends on your specific use case as to which environment has the best support. For me the biggest factor is that Lisp is very productive for use by a small and competent team. In those situations they tend to create a DSL and evolve the system. PG's essay describes the reason Lisp fails many projects in the section "The Blub Paradox".
Looking at what factors lead to such results might provide some insights as to what could be done to foster such contributions.
Too much experience. No patience :-(