HN user

_8ljf

389 karma
Posts0
Comments64
View on HN
No posts found.

So use C++ already; that’s what it’s for.

Don’t go complaining that C++ is “too complicated” and then be hauling its complexity into C, because all you’ll end up with is a bloated schizophrenic mess that is neither a good C nor a good C++ [alternative].

“I can't believe the C standards committee is entertaining this.”

Hey, standards committee’s gotta eat.

'defer'? I occasionaly use it in Swift to clean up resources; s’okay there, I guess, though I’m not convinced it’s better than Python’s 'with' block. But in C?

One of C’s few distinguishing strengths is that the language is relatively† small and stable, and well understood. For that kind of cleanup there is already 'goto', which again is small, stable, and well understood. I just used it for that the other day: it works, it’s fine; I’m a grown-up.

Yeah, sure, 'defer' is “safer” and “more elegant”… did we mention this is C? That ship sailed fifty years ago. Don’t try to make C into something it’s not: that’s C++’s job so go fill your boots there instead.

I just posted Tony Hoare’s excoriation of ALGOL68 the other day, but clearly it’s needed again:

http://zoo.cs.yale.edu/classes/cs422/2011/bib/hoare81emperor...

Simplest solution: track down the ruddy C standards committee and beat them in the head with a leather-bound copy of Zawinski's Law (wrapped around a large gold brick), till either they’re dead or they leave C be. It does what it was designed to do, and that along is reason enough not to dick with it just because they’re bored and struggling to justify their continued existence.

The only thing C needs to do is keep on working. That will only get harder the more crap they pile on top. A good artist knows when to stop.

Which brings us to…

“panic/recover”

K&R give us strength! Tell these frustrated wannabe language designers to go make their own damn language, instead of screwing up someone else’s!

Okay, now I’m done. And get off my lawn!

Quite right: Apple is entitled to make (and not make) whatever products it chooses.

Could’ve made a great, and timely, horrible-warts-n-all show about freedom of speech and those who’d manipulate it, but Cook is not one for such exuberant boldness. Hey, I’m fine with that: last thing I want is a desire to spend any more money on their overpriced tat.

Guess it’s The People vs Larry Flynt for movie night tonight. Now where did I put the DVD…

“this is the language that powers Cloud Firestore / Cloud Storage security rules”

This really needs to be stated on its front page. Right now it’s all “Hows” and no “Why”.

First question anyone looking at it asks: What problem does it solve?/What need does it fill? A real-world use case provides an easy relatable answer.

Incidentally, with existing links to protobuf and no halting problem to worry about, it sounds like you’re halfway to having a remote query language a-la SQL too.

https://www.researchgate.net/publication/221553413_Safe_Quer...

“I think the next leap forward in programming is going to offend the sensibilities of current programmers.”

Honestly, programmers have been railing against progress ever since the first machine coders shook their canes at those ghastly upstart programming languages now tearing up their lawns.

Meanwhile, what often does pass for “progress” amounts to anything but:

https://fermatslibrary.com/s/the-emperors-old-clothes

--

“It’s a curious thing about our industry: not only do we not learn from our mistakes, we also don’t learn from our successes.” – Keith Braithwaite

“But there's a big difference between little experiments and betting the company on an auto-cannibalization strategy. DEC didn't have the guts to go there.”

See also Kodak (invented the digital camera in 1975!), Xerox (We’re a photocopier company! We sell photocopiers!), Microsoft (owned the entire global PC market for damn near 20 years—till Apple overnight redefined what “Personal Computing” meant). All caught out while sitting atop their laurels.

The only thing today’s successful product is good for is funding the development of tomorrow’s—because if you don’t disrupt yourself first then sooner or later your rivals will do it for you, and then it’s already far too late to do anything about it.

I was a company director. Started the company, put in the major investment, brought in two other people I knew and trusted as fellow directors, and I still had to walk away 18 months later because all three of us—as first-time directors with more lofty ambition than hard, dirty experience—made a thorough cock of the business.

Glad I did it. Not happy about that particular outcome, but at least now I know it’s harder than it looks and some of the errors to avoid in future. And hopefully once I’ve finished dusting myself down I’ll be back up on another horse to try again.

It’s real easy to sit in the peanut gallery pontificating loudly. I’ve more respect for those who actually do it, even if they are assholes as people (but really, who isn’t?).

Why? Will the market be any nicer to them? They’ve failed to make their case as to why anyone should care that Vale exists; never mind actually differentiate it from the current swathe of robust, established Rust-style languages already in full production use and battling each other for the market’s next 20 years of attention. And they’ve barely reached v0.1, and expect to make a difference when make their grande entrance into that bullpen? Who’s fooling who here?

Look, if they just want to be another D then by all means have at it. It’s great that they have a personal hobby, but at least have the good grace to put up a notice saying they’re making this thing to please nobody but themselves. That way anyone else looking at it knows not to invest their own time into a toy project that doesn’t even take itself seriously, never mind have the chops to make the rest of the world believe in it too.

Oh, and by the way, I’ve said nothing about Vale that I’ve not said of my own projects… right before I’ve pulled the plug on them for failing to hit their overall objectives. And the best of that work’s been technically excellent, with sitting users royally pissed that I’ve just chucked their investments on the scrapheap along with my own. But I’m a realist; and it’s better to pull the trigger now and move on ASAP to the next thing, than drag out a slow but inevitable death and then have to junk an even larger investment further down the line. See also: sunk cost fallacy.

You want to ask other people to believe and invest in you? You’d damn well better bring more than just a tick list of features and your delicate feels. Else you’re just messing them around for your own personal ego.

/fin

--

TL;DR: When someone offers you difficult questions and brutal honesy, take it and ask for more, ’cos that’s the best gift they can offer. But if all you want is a pat on the head, then go ask your mom as I’m sure she thinks everything you do is wonderful.

I’m not a Rust user. I have no particular nag in this race. What I do understand, or at least am start to learn, is the difference between a Technology and a Product, and between a Product and Success.

So once again: What is Vale’s USP†? Because it isn’t on their frontpage; which it would be had they thought to ask that question of themselves.

--

TL;DR: Goddamn it, all you noobs, but learn How To Sell already. Some of us are just too damned old and tired to want to hold your diapers till you learn to grow up. Try making our lives a bit easier for once; not just to benefit us but your own products as well.

.

(† And if you don’t even know what “USP” means, well there you are. As someone who has already tried to bring truly groundbreaking new tech to market and flubbed it, and is just about to roll up sleeves and try, try again, I’m not asking these questions just to be obtuse but to be helpful. However, if you’d rather just insult than ever amount to squat then by all means carry on.)

Be aware that on the scale of complexity, the immune system is at the deep end of the pool. Your motives may be admirable, but the chances of you jumping straight in and emerging with the Olympic gold medal are good as zero.

If you want to get into the science of it then I’d suggest you start with general courses in biochem and physiology at the undergrad level and build your way up from there†. Expect to invest a good hard 10-20 years of your life getting up to speed, with no hard guarantees of success at the end of it.

Or, if you just want to help people right now, go get yourself involved in charitable fundraising for an organization that’s already working the problem. Still no guarantees, but at least they’ve got a big head start. Just don’t end up on a list like this, ’kay:

https://sciencebasedmedicine.org/?s=immune+scam

--

† Courses I flunked myself, BTW, but at least I learned just how much I don’t know—an insight I’ve subsequently found both invaluable and frighteningly scarce in tech.

What people say and what people do are not the same thing. Society, when given a recent choice, declared outrage for the children then promptly chose the institution. Any other business with a child abuse record the length of the Catholic church’s would be publicly shunned, closed down, and its assets sold off to compensate its many, many victims. And yet, it’s as strong as ever; a bastion of conservative establishment “do as I say not as I do”.

Look, this is not hard to understand: the increasingly fascistic US Right and its Qanon sturmtrupplers are using their “deep state cannibal pedophiles” narrative (amend as appropriate) as a modern-day blood libel in which to paint all their enemies. Mignonnes is simply one more convenient hook upon which to hang the greater attack. To fixate on the film is just one more layer of misdirection, to keep people angry, active, and blind to the big picture. You cannot understand anything until you understand that.

There is nothing innately anti-pedophile abould US Conservative culture; if anything, it’s proved one of the great hiding places for abusers (51st Speaker of the House, anyone?), precisely because it controls what gets said publicly and what is kept private, cultivating and misdirecting popular rage onto its political enemies, and edging ever closer to repeating the great atrocities of history, from the blood libel-stoked slaughters of first European Jews by Catholics, then of those Catholics by the new Protestants, through to the ethnic executions of the Bosnian war and the wholesale genocide of Rwanda, and everything inbetween.

Now I consider myself European despite being stuck here on reactionary backwards Airstrip One. My granddaddy was Antifa back in Africa and Italy. I also know firsthand how much damage one can do just by choosing a pleasing lie over a painful truth. I have few illusions about how bad things can get, and all it take to get it underway is for enough people to buy into a Big Lie to justify everything that comes next. I have the limitations but also the benefits of an outside perspective on what’s happening in the US right now, and I’m legit worried for the future of our whole damn planet as a large chunk of America charges proudly towards a Russia-like one-party state.

If you don’t wish to repeat humanity’s bloody history (which I can assure you won’t spare the children from anyone else) then you really need to start paying attention to who is spinning the popular narratives and to what goal. Starting in a mirror—because if you can’t be brutally, rigorously honest with yourself about your own understanding and motives, then what makes you think you can defend yourself from others’ deceptions any better?

https://www.theatlantic.com/culture/archive/2020/10/watching...

https://www.adl.org/education/resources/glossary-terms/blood...

https://www.bbc.co.uk/news/world-africa-26875506

https://www.youtube.com/watch?v=E5eFubO_iLM

--

“Dear America: You are waking up, as Germany once did, to the awareness that 1/3 of your people would kill another 1/3, while 1/3 watches.” – William Pannapacker

“The show”

Perhaps you’re confusing it with Dance Moms? Or preteen beauty queen pagents? Both of which are obvious targets of this film, being an attempt (whether good or bad) to criticize that culture. And both of which are also, I’d wager, solidly red state phenomena.

Besides, at this point it’s pretty much a given that everything the Titular Right accuses its enemies of is what it’s balls-deep in itself, so outrageous hypocricy there is no surprise either. See also: alt-right incels, Qanon’s 21st-century blood libel, Kentucky and Oklahoma Trump campaign officials currently serving time for child sex trafficking, undocumented kids stolen from family and locked in cages, and so on.

None of which should Netflix’s appalling advertising campaign nor its lousy attempts to suppress the right-wing tweets attacking them, but let’s not pretend all these Twitter “critics” are suddenly thinking of the children. Obvious propaganda war is so obvious that even a passing student of history can see exactly what’s going on.

At this point in time, it’s a fair assumption that anything the Titular Right accuses its enemies of doing, is what it’s doing itself. Even that notorious house of flaming liberals, the Wall Street Journal, concluded the Hunter Biden thing is nonsense. See also: Swift boating, Obama is a sekrit Kenyan Muslim with fake birth certificate, and so on. It’s the Roger Stone 101.

Meantime, the Trump family kleptocracy is nuts-deep in its graft on the taxpayers’ dime and the fanbois don’t raise so much as an eyebrow because calling that out just isn’t exciting or self-serving enough. This is how democracy dies, drowned beneath addlepated addicts grasping at their next fix and just don’t care about anything else.

“it's really helpful to have one obvious way”

Counterpoint: Python format strings. (I think there’s four or five different built-in ways to do those now.) Python’s “batteries included” may have helped it to win vital audience early on, but it’s also locked in a ton of deadweight that’s seriously slowed down its own evolution since, while bloating its feature complexity to such a level I could not recommend Python as a good language for beginners now.

Which suggests there’s a more general meta-problem waiting to be solved here: how to [automatically] mass-migrate code written against interface A when a superior successor B comes along. I have many gripes about Apple’s #SwiftLang, but seriously appreciate that this is one requirement they’ve given some thought to. Having seen the decade-long logistical horror of Python’s relatively minor 2-to-3 upgrade, Xcode’s ability to auto-update projects written for one Swift version to another has let them evolve the language with minimal pain.

And while I’m not a fan of Lisp itself (a decent first attempt that should’ve been vastly bettered by now), I think its metaprogramming model an obvious foundation for such an automated migration system. Thus, rather than bake in all the libraries, keep the libraries external and build in a standard mechanism for migrating codebases written for one onto another. In essence, automated refactoring by “recipes”, where these recipes are as common and easy-to-use as the libraries themselves.

..

Of course, this still leaves the other (larger) problem of how to sort out current trash houses like PyPI, NPM, LuaRocks, et al, where contributors’ enthusiasm is not necessarily matched by their knowledge, competence, and ability to savagely critique their own work before inflicting it on the world (you know, the “Science” bit in “Computer Science”). Preferably without destroying that enthusiasm in the process, since there’s no point having a wonderfully polished platform without bums on seats as well—a perennial Lisp failing, it should be noted.

This is not merely idle speculation on my part. Many years ago I cut my teeth on AppleScript, which makes the stdlib-starved Lua look like fat Python 2, and tried to bootstrap a library ecosystem for it more than once. Good practice. Zero success†.

And now I’m trying to devise a “stealth Lisp” successor to them all (https://github.com/hhas/iris-script), I realise cracking the greater library problem is what will make the next generation of languages. A platform is only as robust and dependable as its weakest component, and for as long as a buggy or withdrawn left-pad function can tip the whole stack over then it’s not robust at all.

But this is as much a sociological challenge as a technical one, and not one I’ve got answers to yet.

--

† After which I realized it’d be far easier just to port the useful bits of AppleScript to Python instead. Which almost worked too… but that’s another story.

C. The popularity and mindshare of C means most languages of the last 50 years have selectively evolved to be C knockoffs.

A pity Bliss wasn’t their role model instead, but that’s the value of market positioning: you don’t need the best product, just the product that everyone knows.

Yep, but there you are refactoring as a necessary prerequisite to achieving a clearly-defined end goal. That’s part of the development roadmap and should be planned and budgeted accordingly. When building a house, a professional builder knows to dig out and pour a solid foundation, so that by the time they get to tiling the roof the walls beneath it aren’t already sinking and tearing apart.

That’s very different to just dicking with the company codebase for one’s personal amusement. That’s the bloke with the dozen rusted automobile shells sitting on bricks in his front yard, while he’s in his shed “busy working” on number thirteen. He’s not productive, he’s just playing with himself. And making the whole place look like trash while he’s at it.

“UNIX descendants follow the pattern of encoding data types with filename endings.”

An ad-hoc arrangement with little formal support at the GUI level and none at all at the shell level.

`some_program --out_type=json | jq` to `some_program | jq`.

JSON only tells you how the data is encoded, not what it means. Contrast this MIME type:

application/atom+json

Knowing data is JSON-encoded only enables (unsafe) generic JSON operations. Knowing the data is, say, ATOM allows task-specific operations. Consider a search tool. Having precise type information enables format-specific parsing operations to be decoupled from generalized tree/table searching operations.

Not only that, but looking up parsers and inserting them into the pipeline can be completely automated away. `some_program` doesn’t need to be told to output JSON; it can negotiate that itself with the program that follows, the shell acting as broker. (Content negotiation is one of the Great Ideas of HTTP; sadly utterly ballsed by the WWW, but that doesn’t mean others couldn’t do it right.)

Or consider `ls`. How many options/arguments does that have? (If you don’t know off the top of your head, I totally understand and am happy to wait.) Now, how many out of those options relate to recursion, filtering, and presentation? Because none of those should be built-ins; they should all be separate, general, composable tools. How much duplication of effort would be eliminated across the entire Unix command line? How much easier would it be to learn the entire system?

This is Unix Philosophy 101, yet even a simple standard tool like `ls` utterly fails it. Why? Because for effective, efficient, safe composition to be the easiest route, it needs to Just Work. Which it can’t do, because lack of IO typing and tagging means that What You See Is All You Can Get. Consider: for some consumers it’d make more sense for `ls` to output a list of inodes; for others, a list of full paths; for others, URLs. Outputting a list of file names is crap (assumes shared global state—cwd—that will not change between time of creation and time of use). Outputting a list of file names arranged in multiple vertical visual “columns” each offset by N spaces is insane. This is the very definition of Big Ball Of Mud.

Like I’ve said, there is no point trying to “fix” Unix because fundamentally it does not want to be fixed; never mind whether or not fixing it is even technically feasible. But that’s fine: there’s value in stability and it is a sunk cost so nothing is lost. Just leave Old Unix to be itself, which is what it’s good at, and build a new system unencumbered by legacy baggage and baked-in mistakes, making full use of all the wisdom and resources gained over the decades since.

Okay, so a brand new system will have to be radically better than the old in order to attract audience, but that’s totally doable. Heck, there were already way better CLIs forty years ago (VMS, Plan9, Symbolics Lisp, Smalltalk), so it’s not like there isn’t a wealth of knowledge and experience to purloin for free. It’s just a question of motive: who now benefits from propping up all the old complexity and makework vs who’ll benefit by completely disrupting it. And you just have to look at how an aggressive reborn Apple handed the mighty untouchable Microsoft its own ass back in the 2000s to work out the answer to that. Or Kodak. Or Xerox. Or the US car industry. Or the British Empire. And so on.

Qui audet adipiscitur. She who dares, wins.

“It doesn’t make sense to put these types in the operating system”

The OS doesn’t need to hardcode individual types, and to do so would defeat growth. It only has to provide a standard mechanism by which files can declare the type of data they contain, and executables can declare the type(s) of data they consume and/or produce. BeOS, for instance, tagged files with MIME types. The original Mac OS used “four-char codes”. Even DOS had file name extensions, as awful as that particular design choice was.

Storing arbitrary data with no way to indicate how that data is encoded is rank insanity. Saying “it’s the app’s job to deal with encodings” is not wrong, but if apps have no way to know what encoding a given file was written in, how can they know how to decode it?

Please do not rationalize away the longstanding and well-known deficiencies of Unix. These deficiencies do not aid progress; they hinder it. As do apologetics.

What you want is tagged and/or typed pipes. Once a pipe declares how its data is encoded, you can build all kinds of modern tooling and high-level automation on top of that.

The whole “But everything’s a text file!” is an outrageous lie, and always has been: just an excuse to cover up a massive omission in the design of the Unix file system (untyped, untagged “file” resources). Such egregious corner-cutting might have been understandable—even forgivable—back in K&R’s day, when they were bootstrapping C and Unix on hardware with less processing power than a modern microwave oven controller. But we’re decades on from that now and there’s no excuse for perpetuating it: we know how to build safe powerful modern static and dynamic type systems, and we’re spoiled rotten for the hardware resources to support it.

Fifty years ago, K&R built C and Unix, in a cave, with scraps. Nowadays you can bootstrap a complete hardware stack for less than the cost of a 360, and there are modern kernels (L4) and systems language (Rust) already available for free off the shelf. So pick a target market and build the userland for that. All that’s missing is a modern-day Kernighan and Ritchie to step up and get on with it, so it’d be a sorry indictment of this generation if they do not exist.

“somewhat miss the point of the shell in the first place”

This presupposes that the Unix shell is the way it is because of careful, considered, forward-thinking design, rather than being a haphazard heap of mouldering hacks upon lazy corner-cutting upon quick-n-dirty bodges that should’ve been thrown out and replaced decades ago.

I agree that trying to improve the *nix shell is a bad idea… because the _Unix shell itself_ is a bad idea. Fifty years is long enough. Instead of bending over backwards for that obsolescent garbage heap (for which no-one will thank you, as we see), study it, learn its lessons, and draw a line under it.

Then go build a clean, modern shell architecture from scratch, using modern tooling and techniques, unhobbled by the myriad defects and deficiencies of the old. It’ll take a tenth of the time and be ten times better (if not, you’re still doing it wrong).

See also:

https://www.google.com/search?q=sunk+cost+fallacy

https://homes.cs.washington.edu/~weise/uhh-download.html

--

p.s. As for driving early adoption, don’t even think of trying to win over the Unix old guard (who will only bring regressive practices and complaints with them), but sell it hard to the new generations of users who are accustomed to modern UI/UX standards and much less impressed by what the “Old Unix” dogpile has to offer.

“The LibreOffice project's imprimatur should be to stop existing.”

100% agree with that. But your proposed substitute is nonsense on stilts. Markdown? Please. WYSIWYG exists for a reason.

LibreOffice’s problem is that it’s playing Microsoft Office’s game by Microsoft Office’s rules. That is a game it cannot win. Microsoft Office succeeds not by being good at what it does but by being a massive monolith that no-one else can match. Those who try to replicate it only work themselves to death trying to do so. That’s a fools’ game.

Instead of trying to build a better Office, look at what users try to/actually do with it and target that. For starters, a lot of people use Excel not as a programmable parallel calculator (spreadsheet) but as a tabular layout tool for ad-hoc/databaseable information. So build a grid layout tool that is entirely agnostic on programmability and back-end storage, and allow different components to plug in as needed.

I’m always leery of pointing to component architectures like OpenDoc as those are a whole ’nother honeytrap in themselves, but Unix Philosophy posited that lots of small, simple, highly focused, and freely pluggable tools would scale better to solving users’ problems than the vast impenetrable monolithic architectures of Office et al. Unix/Linux may have failed to pay its own philosophy more than lip service (I mean, how many features is `ls` up to now? 50? 100?), but whereas MS Office is also mired in its own market success it’s never too late for the also-rans to rethink their losers’ game and rewrite its rules to be one they can win. They just have to want to change, and try something that hasn’t been tried.

And yes, change means risk and potential for [greater] failure. But just look at Steve Jobs: he never beat Microsoft by building a better PC; he did it by radically redefining what “Personal Computing” means, inventing a completely new market of Personal Computing users, and being first to that market with the right product to sell them.

So, no, an Office suite that runs in a web browser is not the sort of thing I’m talking about either. Although the web should, as you say, provide the foundation for a modern data editing and sharing system. But look at what people actually do today with “Office” software, regardless of whether it’s what that software was designed to do or not, and from there pinch off one well-defined use-case at a time and reformulate it in terms of basic reusable components joined together with some task-specific glue, then push that to that market as a tool just for them that does what they need done so much quicker, easier, and safer than anything else.

(Ironically, the web originally conceived as a fully read-write platform where everyone could read and everyone could write, and it was only Berners-Lee’s corner-cutting impatience that recast it as a read-only platform with its editing keys jealously kept by a new high priesthood of “Web Developers”.)

--

TL;DR: Let’s build a better “Office Suite” is the wrong game to play. “Let’s identify solve individual specific real-world problems that users actually have today”, and just happen to build those solutions in a way that keeps everything small, agile, flexible, and humble; instead of bloating into the traditional Big Ball of Mud that is wonderful for developer egos and customer lock-in and absolutely awful for anything else.

“after a few years”

Key phrase right there. Because it doesn’t matter what language a system is written in: if management doesn’t bother to hire replacements until after everyone who understands that system and why it works the way it does has already left, of course it’s going to crater shortly thereafter.

That’s not a language problem, that’s a business continuity problem. And it’s lamentably common as dirt.

Any monkey can learn to churn code. Learning the business domain, what its problems are, and how to solve them; that’s the bit that actually matters.

PEBKAC, at every level.

I recall digging into Python subinterpreters a decade ago. Abandoned it because the real killer wasn’t shared GIL, it was shared modules. If one subinterpreter imports a module and modifies that module’s state, then every other subinterpreter that uses that module is impacted too.

Article says nothing about that, which makes me very cautious. The GIL only impacts performance; module sharing wrecks robustness.

Even if each subinterpreter does now keep its own module cache, there’s still the challenge of working safely with common C-level resources such as file handles. (Other than telling users “don’t do that”—and GLWT.)

I’ve used Python now for 17 years and it’s been a very productive tool for me. But it definitely has its baked-in limitations and fighting those is an exercise in rapidly diminishing returns.

Something as fundamental as parallelism can’t just be slopped on top of a language as an afterthought; it needs to be designed for it from the start. So rather than trying to retrofit bad parallelism to Python, perhaps it’d be sense to bring the positive parts of Python over to something that already does parallelism right, such as Erlang, and build from there.

Where the heck are you getting that 490,000 number from? The oral polio vaccine (aka OPV/Sabin) uses a weakened form of the live virus, which known to revert occasionally to virulent form.

Here’s what the WHO site says:

“Since 2000, more than 10 billion doses of OPV have been administered to nearly 3 billion children worldwide. As a result, more than 13 million cases of polio have been prevented, and the disease has been reduced by more than 99%. During that time, 24 cVDPV outbreaks occurred in 21 countries, resulting in fewer than 760 VDPV cases.”

https://www.who.int/news-room/q-a-detail/what-is-vaccine-der...

BTW, I think you’ve misinterpreted “don’t know what they’re doing”†. I’m not talking about code, I’m talking about the business domain. (I thought it obvious from context, but clearly not.) And yes, a depressingly large number of working programmers today have zero interest in learning anything except how to write more code. But how can you write code that solves a user’s problem if you refuse to learn what that problem is and how it was arrived at?

And then you blame the users for “not speccing the job right” when they discover your “solution” not only fails to make their lives any better but often makes it even worse. I’ve worked a decade professionally as a user-turned-developer, so please don’t say this attitude isn’t cultural right down to the bone. I’ve seen it, I’ve dealt with it, I’ve walked out because of it. And looking around me that seems pretty much par for the course.

This is why I like a philosophy of reshaping your stock language into something that much better expresses the business concepts and processes you’re dealing with, then writing your solution in that. It forces you to learn the user’s job before you get underway, because you can’t fake understanding: your new “business language” either does the job or it sucks.

Building up that vocabulary is the first test of whether or not you understand what you’re doing; and until it proves you do you’ve no business proceeding or you’re just wasting everyone’s time (including your own), and giving this industry an even worse reputation for shafting the customer by giving them shit than it already possesses.

--

† Ironically for exactly the reasons I’m talking about: you’re unable to see anything that isn’t about coding. But the code is the least significant part of the overall puzzle; and until you understand the puzzle in its entirety you’re not fit to solve any of it.

TL;DR: I may be nuts, but I ain’t what’s broken.

“ Imagine interoperability nightmare when we cannot rely on everything being just bytes being streamed.”

As I’ve noted above, the problem isn’t transmittability; the problem is never knowing what the bytes being transmitted represent.

I mean, C is hardly renowned for the robustness or expressivity of its “type” system, but untagged untyped byte streams are tantamount to declaring all data as void*. That is a ridiculously shaky foundation to build on, yet could have been entirely avoided by simple addition of one more piece of metadata and an ftype() API.

K&R were brilliant, but also kinda dumb. I certainly wouldn’t want to eat chicken cooked by either one.