346 karma · joined June 5, 2009
Aside from Ukraine and Kazakhstan (both under the control of "one particularly nasty Georgian") which other regions of the globe suffered from mass (1+ million) deaths caused by famine in the 1930s?
Is the above an inaccurate perception?
And yes: So. Many. Floppy. Swaps. The codegen was not horrendous, but IIRC its price kept it well out of reach of non-commercial users.
[0] https://support.google.com/earth/thread/139934632/rail-lines...
Having now experienced the absence of the daily grind for over 4 months (for the first time in my adult life), I am getting so used to being away from it that I realize I would probably have a hard time going back to the grind, regimentation, and employer expectations of "gung ho" spirit pursuing the idealistic mission statement proffered by top management (yes, I'm cynical). So in the end I think where I'm at is good for me for now. I've been blessed to have a successful, lucrative (though perhaps only slightly above average in my field) career that (combined with aggressive saving and investing for that duration) enables me to uncouple from it at this time without financial worry. And you never know when a sufficiently interesting (while simultaneously lacking in BS) opportunity might appear...
What do you think you'll do now? Given that you're wholly self-taught, I would assume you would dive in to your interests.
I have one personal Open Source project that I will likely continue to slowly enhance (I was its only user, and I used it at work, so less need for enhancement going forward). I have some other stuff (CGI Perl) which I run on my home server, which I'll probably enhance. And a few related things I'm thinking of starting work on (in definition phase right now). All very utilitarian stuff just for me. I've sent (had accepted) a tiny PR or two to a project I used daily, but I doubt I'll get more involved than that.
But that's looking at the SW Dev side of my life, which has dominated my time for the past 30-odd years; drawing back from that (continuous learning engagement) while understandable (in the sense that breaking any 30-year-old habit is tough, and if no longer being employed in the sector, what's the point?), makes sense. I need to find other things beyond tech stuff to spend time on; home repair is a probable direction, and auto repair too. I did that stuff to some degree always, but always because I was a cheapskate who objects to paying beaucoup for what I (these days anyone capable of watching Youtube can figure out how to) do, and do to my own satisfaction (perfectionism) level (vs. accepting what a contractor is content to deliver).
Besides that (which won't consume much time), traveling (by motor vehicle) the western USA with a lot greater frequency is on my agenda. I'm not sure what else might happen; I'm open to opportunities, but not really to frivolities... fortunately now I'm in no rush to achieve any goal.
Yes, and while going thru the past few months' "let me see if I can find something that engages me and my interests (w/o too much concern about pay level)" job search, I repeatedly ran into Job Descriptions containing criteria BS/MS CompSci, EE, or equivalent required. I have a BSEE, but in fact, the underlying premise of Leetcode testing is CompSci. So the allowance for EE degreed candidates is IMO bogus/deceptive. I never got near a CompSci Data Structures or Algorithms course during my uni days, and aside from Leetcode, never suffered an inability to get my job done due to that omission.
From the linked article:
Another place the non-fungibility of people causes predictable problems is with how managers operate teams. Managers who want to create effective teams end up fighting the system in order to do so. Non-engineering orgs mostly treat people as fungible, and the finance org at a number of companies I've worked for forces the engineering org to treat people as fungible by requiring the org to budget in terms of headcount. The company, of course, spends money and not "heads", but internal bookkeeping is done in terms of "heads", so $X of budget will be, for some team, translated into something like "three staff-level heads". There's no way to convert that into "two more effective and better-paid staff level heads". If you hire two staff engineers and not a third, the "head" and the associated budget will eventually get moved somewhere else.
One thing I've repeatedly seen is that a hiring manager will want to hire someone who they think will be highly effective or even just someone who has specialized skills and then not be able to hire because the company has translated budget into "heads" at a rate that doesn't allow for hiring some kind of heads. There will be a "comp team" or other group in HR that will object because the comp team has no concept of "an effective engineer" or "a specialty that's hard to hire for"; for a person, role, level, and location defines them and someone who's paid too much for their role and level is therefore a bad hire. If anyone reasonable had power over the process that they were willing to use, this wouldn't happen but, by design, the bureaucracy is set up so that few people have power.
These observations ring completely true to me. I'm a generalist, not a single-purpose actor, but the value that such an actor brings seems to run directly against the bureaucratic compulsion to categorize each employee.
I still loved (and was/am capable of) doing the work, but having gone another few rounds of "Leetcode interview process" in the past few months, and having realized that I've reached the end of my willingness to tolerate what seems to be near-pervasive "Agile cargo-cult ceremony" (and everywhere, "Agile is whatever we decide it is") and (less pervasive but still frequently encountered) technically clueless headline-chasing (micro-)management in the presence of increasing active monitoring/collection of (remote) employee activity metrics and pervasive exhortations (mapped to KPIs) to "deliver innovation!" and "do it together!". Why run the Leetcode gauntlet (which seems to closely resemble Final Exams Week from my Uni days, with the same intense cramming prerequisite) only to land in a team/management circumstance of uncertain quality (bail out and do it again?)?
Likewise I've realized that maintaining my W2 income via FTE at my age and position would mostly serve to raise my tax bracket and preclude me from taking minimally taxed withdrawals from my IRA starting in a few months (these have to be taken sometime, and the less taxation, the better).
The process of "letting go" of my working career and adopting a true retirement mindset has taken me at least the past 4 months (I might not be done with it yet), because I do really love and have excelled at the hands-on work (and being self-taught and very motivated to stay abreast of much of what is changing for the better in SW Dev, I've been operating in long-term independent self-study mode for my entire career, turning this background process off is proving challenging).
Of course, even if the proposal becomes law, it might take a decade or two to come into full force (someone else mentioned CA's High Speed Rail project, but healthcare as it exists today is a far larger Gordian Knot), so I think I'll watch from the sidelines to see how such a grand plan works out in reality.
The COBRA monthly pricetag is $2093.
While employed (at this Fortune 300 company's San Jose, CA office), I was paying $425 per month out of pocket for the same set of plans.
Since this conversation occurred within the "COBRA dead interval", there was no feasible way to ask the soon-to-be-restored insurance provider how much they would be able to discount and/or adjust the $3700 price of this same procedure downward... based on past history, I'm not confident that an insurance company would pre-commit to a set of discounts and/or adjustments for a procedure price (i.e. the final price we'd be required to pay out of pocket if below our deductible) prior to a (post-service-delivery) claim being filed and processed. Catch-22? Or "we can't know what's in the [legislation] until we pass it"?
edit: add [1] the "self-pay" amount would constitute payment in full.
The pandemic's normalization of remote work enabled this move (which otherwise would have been deferred until retirement) to occur with minimal risk to my existing W2 income stream, which made what would otherwise have been a somewhat fraught transition largely worry free. I am also grateful that the pandemic in its first 9 months also removed one of my primary pre-move daily-life stressors: a heinous twice-daily commute on massively oversubscribed south bay roads and highways (which was far from being the worst possible).
As far as storage: it all goes on my home (Samba) server with nightly (onsite) backup. Yes, this is a "hoarding" situation; it's easier to keep accumulating than to make (irrevocable?) decisions about what to delete. I know my backup solution is only robust against certain failures, but paring down the huge collection in order to make offline backup feasible means grappling with aging out the appropriate parts of it. This is on my to-do list... Also on my to-do list, once I establish a mission-critical doc-subset, is storing those docs on https://www.fidsafe.com/
edit: re organizing: it's all manual; pdf file(name)s are auto-prefixed with date-of-scan, and I rename to add a content-denoting suffix, plus move into a dir structure (which has evolved a bit). So, not very efficient, but still much better than pre-scanner (papers stuffed in 2 actual filing cabinets).
The Turbo C 1.0 User's Guide [1] page 244 (257) "Turbo C's Six Memory Models" lists these as tiny, small, medium, compact, large, huge. Also, page 220 (233) "The near, far, and huge Modifiers".
You claim that these same capabilities were present in TP 5.0, 5.5, 6.0, 7.0 and TPW 1.5. Can you provide a reference for that?
[1] http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/tur...
I didn't miss them, but because IIRC all the versions you mentioned (and also Delphi 1.0) were x86 16-bit (only) Borland/Turbo Pascal evolutions having effectively the same memory model support as TP 4.0, felt they were not important to enumerate. These releases certainly added other features, but IIRC made no architectural changes affecting the performance of their generated code on the 16-bit x86 platform.
(Again IIRC) all Borland C/C++ variants >= TC 1.0 offered the same 16-bit x86 memory model (and ability to manually mixing memory models) support (that already being comprehensive), with gradually improving codegen optimizations.
My larger proposition is that the perception of (Turbo) Pascal's performance being perceived as poorer than that of C (in the interval when Pascal was being eclipsed by C/C++), while accurate, was influenced to some degree by the incidental factor of the dominant x86 CPU architecture of the day having a segmented architecture upon which extraction of optimal performance across the range of applications necessitated the extensive/comprehensive memory model support found in all competitive C/C++ compilers of that day, which none of the competing Pascal compilers (which is to say: Borland's plus MS' QuickPascal (which implemented the Borland language definition [1])) possessed. It would have taken those Pascal vendors more resources to add such memory model support (and other optimizations offered by their C/C++ competition), and they elected not to do so. Borland moved on to Delphi which continued the pattern wherein raw performance of the Pascal compiler's generated code (x86 32-bit as well as 16-bit) lagged behind that of the C/C++ competition; Borland's finite resources were expended on the IDE & RAD aspect of Delphi rather than on codegen. "The rest is history". But I don't think there was anything intrinsic to Borland's Pascal dialect (the only one I ever used) which doomed it to take a backseat to C in terms of performance: I used both TC and TP 4+ without ever feeling a vast difference between the two languages (and found many aspect of Pascal preferable to those of C/C++).
Also, aftermarket exhaust systems for motorcycles (99.9% of these being much louder than stock/OEM) are a huge business: I'd guesstimate that 50% of motorcycles sold in the USA soon (< 1 year old) end up running aftermarket exhaust systems; it's a standard first modification done by almost all enthusiast owners.
TP 3.0 generated COM files (near code, near data, far heap-allocated data).
TP 4.0 generated EXE files (far code, near data, far heap-allocated data).
(the above is "to the best of my recollection": I no longer have the manuals for these toolchains; it might be the case that in TP 4+ all data is far (pointers to data were far)).
A TP coder was generally forced to live within these constraints (and adapt to the memory model changes described above across the 3 -> 4 transition).
Turbo C 1.0 came along within a year or so of TP 4.0, and (because it was actually not a 1.0 implementation but a rebranding + enhancement of an existing toolchain acquired by Borland) supported all permutations of x86 memory models, allowing the coder to choose according to their needs (and explicitly define near and far functions and data as needed independent of the memory model used w/o a need to drop into [inline] asm).
Turbo C's giving the programmer total control and optimization flexibility along these axes, which was a function of the language _implementations_, not the languages themselves, I believe contributed to the "C was faster" outcome (from TP 4 onward, there was (inline asm aside) IIRC no way to instantiate near functions). Turbo C was not the only C implementation for MS-DOS, but IIRC it immediately became the most popular, and held that crown for many years; other entrants needed to match Turbo C's features or die.
[edit]
Microsoft offered a MS-DOS C compiler (long?) prior to the release of TC 1.0, which supported the same memory-model permutations as TC 1.0. However it was at least 3x more expensive than TC 1.0, so when TC 1.0 was released at such a low price, it grabbed a lot of market share (by expanding the market to include programmers with smaller budgets). There were at least a few more MS-DOS C toolchain competitors already on the market when TC 1.0 was released (but I never used them so cannot comment futher on them).
TOTAL SUMMARY OF REMEDIATION PROBABLE CONSTRUCTION COST $9,128,433.60
http://tlindner.macmess.org/wp-content/uploads/2006/09/Byte_...