_8ljf
I do not want to have to ask again.
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].
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!
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 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...
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
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.
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?).
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.
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.)
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.
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.
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.
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.
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.
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.
I said “far too many”. Although judging by the amount of crap software around, it’s certainly a lot.
“it's also true that business stakeholders need to take the time and understand the impacts of their 'ship fast always' mentality”
You’ll note where my original post points out programmers are not the only culprits at work. Learning is a two-way process. But developers are ostensibly the experts in turning requirements into solutions and what is needed to do that; so if users have utterly unrealistic expectations of what is/isn’t achievable then whose fault is that?
Often what users want is feedback: they want to know when they’ll be getting their solution, and be confident it does what they need. Both of these are engagement problems. That points to logistical shortcomings in the development cycle, particularly the siloing of parties and processes, which I know is a blight in which everyone is at fault.
But a lot of programmers would far rather wrangle code than wrangle users, even though user-wrangling is by far the more important of the two. So what does that say about these “solutions providers” and their ability to deliver?
Me, I’ve only been coding 20 years; professionally the last 10. My first programming job, I was one of two devs attached to the IT team out on the shop floor, working directly with users developing them quick-turnaround solutions to their immediate problems. In the 3 years I was there, I never once saw a developer from their 20+ Enterprise Applications department walk out of their glass cage onto the shop floor and spend some time talking to users about how they were getting on with their software and any problems they might be having.
Sure our code was small and simple, and theirs large and complex. But that’s all the more reason for them to engage closely and constantly with users, in order to avoid large and costly errors downstream that embarrass and frustrate everyone.
As I say, the problem is not in the code but in the people and their processes. Yet, no prizes for guessing where most programmers will try to solve it.
Dealing with uncertainty and incompleteness is a core part of the job.
The problem is that far too many programmers are gloryhounds and cowboys who think all that is beneath them; cramping their style when they’re trying to be the coding heroes.
This is compounded by many programmers being lazy incurious bums who have zero interest in doing anything that isn’t writing code. They don’t want to learn the user’s problem domain, so they don’t. Instead they demand users describe exactly how the software should work down to the very last detail; but if users could do that for themselves then they wouldn’t need programmers to write it for them!
Starting from ignorance, instead of writing software that encapsulates the users’ expert requirements, they write clever code that solves their own problems: entertaining themselves, and getting paid.
Writing code is not hard. Any monkey can do that. The challenge is knowing what code to write; and that’s made needlessly hard by programmers who can’t be arsed to understand their users, what they do and why they do it, learning their needs and problems in order to synthesize more effective solutions.
Instead of raising themselves up to users’ level of knowledge, they drag the problem down to their level of ignorance and whale on it with their crappy tools to give the illusion of “productivity”. Instead of being problem solvers, they’re problem multipliers.
Slap on several more layers of equally useless management, marketeers, beancounters, etc, and factor in that while deadweight accummulates expertise walks, and it’s no surprise most software projects are rolling Katamari disasters that makes everyone miserable until finally put out their misery; only for the whole process to start over again, with zero lessons learned.
--
TL;DR: Programming is hard because programmers make it hard. Because they don’t want to do the job right. Because they’re children.
Of course, that was in back in the days when an entire platform from hardware to userland could be exclusively optimized to utterly and comprehensively smash it in just one very specific and precisely targeted market. Which is, of course, exactly what the iPhone was.
Just as the first Apple Macintosh a decade earlier eschewed not only multi-user, multi-process, and even a kernel; every single bit and cycle its being being exclusive dedicated to delivering a revolutionary consumer UI experience instead!
In comparison, NeXTSTEP, which ultimately became iOS, is just one great huge glorious bodge. “Worse is Better” indeed!
..
Honesly, poor Be was just really unlucky in timing: a few years too late to usurp SGI; a few too early to take the vast online rich-content-streaming world all for its own. Just imagine… a BeOS-based smartphone hitting the global market in 2000, complete with live streaming AV media and conferencing from launch! And Oh!, how every Mac OS and Windows neckbeards would’ve screamed at that!:)
Yes. Except that it wasn’t acquiring NeXTSTEP that saved Apple’s skin; it was acquiring Steven P Jobs.
True, version 1 had been rough and flakey as hell, and honestly really didn’t work all that well.
But Steve 2.0? Damn, that one could sell.
fungus is coming
(Though when end-user automation does work it is epic AF.)
Back when appscript was still a thing I hacked together a quick-n-dirty AppleScript-command-to-Python/Ruby/ObjC translator app which appscript users absolutely adored, plus it greatly reduced the number of “How do I…” support questions because, more often than not, users already had a working example in AppleScript which they could just run through the translator to get the answer for themselves.
Needless to say, Sal Soghoian completely ignored my expert recommendation for this killer feature which could be implemented in a day, choosing instead to dump JXA and its few hapless users down the same black hole of nothingness as all his other product failures. PEBKAC. Not Invented Here. So it goes.
--
[edited to add]
Just d/led the JavaScriptOSA zip from the appscript project page on SourceForge, and the bundled JABDemo.app still works. It’s not codesigned so you’ll have to right-click the app to Open it, overriding the security warnings, but it still works even on 10.15 (caveat any bugs in the underlying JavaScript Apple event bridge, of which there were a few, plus the endless string of permission requests whenever you try to control another app). Example:
Original AppleScript commands:
tell app "textedit" to get name of document 1
tell app "finder" to count every folder of home whose name begins with "D"
app("TextEdit").documents.at(1).name.get()
app("Finder").home.folders.where(its.name.beginsWith("D")).count({each: k.item})
Worst part is: it should never have come to this.
(For those that don’t know, I am the world expert at building production-ready Apple event bridges, with half-a-dozen under my belt. Outside of myself, Dave Winer’s Userland, and the original AppleScript creators, no-one else on the planet has ever managed this.)
Immediately after JXA was surprised-announced at WWDC14, I dropped everything else, reached out to Sal Soghoian (Mac Automation PM), and crash-coursed six weeks of testing and critiquing JXA, up to and including writing a nearly-complete “JavaScriptOSA” reference implementation for the JXA devs to learn from, or just outright steal.
Even rushed and unfinished, JavaScriptOSA showed what JXA should’ve been. And they had double the developers, all the AppleScript source and internal Apple documentation, and a year. You can d/l it here:
https://sourceforge.net/projects/appscript/files/JavaScriptO...
While the Xcode project is far too old to build now and some of that code is a lashup of which I’m not proud, the prebuilt component may still work in Script Editor (though I’ve not tested it in years), as should the standalone “demo” app I bundled with it.
Bear in mind, my JavaScriptOSA implementation[1] was based on my previous appscript work [2], which had alrady proven itself a genuine AppleScript replacement years earlier. Apple even considered including Python and Ruby appscript in Mac OS X Leopard, so it’s not like my code wasn’t already known about, read, or used by folks within Apple. But the Mac Automation team still thought they knew better than a production-proven solution that had at its height a couple thousand extremely happy users, whereas their own previous attempt had only proven an embarrassing failure.
I didn’t get so much as a thanks-but-no-thanks; 200+ work hours straight down the crapper. And JXA shipped half-baked and broken, and immediately abandoned to sink without trace. I scrapped my plan to write the book on Automating your Mac with JavaScript, because you can’t write really good books about really lame broken technology, at least not without losing your mind. (I should know: I lead-authored one of the last AppleScript books.) Apple’s last, best chance to turn Mac Automation around, pissed up the wall and forgotten just as fast.
Honestly, Apple’s real mistake was not firing that preening incompetent, Sal Soghoian, years sooner, while there was still something worth saving.
..
Okay, so with hindsight, JXA was never likely to succeed, even if they had done its implementation and marketing right. As an OSA language component, it lives in its own little closed world, completely separate to Node.js and its vast npm ecosystem. Even in 2014 Node was already killing it in the JS-on-server-and-desktop wars, but instead of “Embrace and Extend” JXA chose “Not Invented Here” instead.
Worse, JXA is built on OSA which is a ComponentManager technology; a hideously ancient, inherently insecure, and long-deprecated in-process plugin architecture. Thus the JXA implementation was already obsolete even before it shipped. A straight port of node and npm CLI tools onto JavaScriptCore with a V8 API compatibility layer for C-based extensions would have been the right choice. But the Mac Automation team didn’t see, because like their technologies they exist in a closed little world completely isolated from everything and everyone else.
One More Thing: Around the same time as Sal was getting his ass ejected from Apple, I wrote one more Apple event bridge, nodeautomation, just to prove my point that creating a competent AppleScript alternative for a massively popular, developer-friendly language is both quickly and easily achievable, so Sal’s team had absolutely no excuse for fucking it up twice.[3] Although it looks like recent macOS/Node updates have broken the build (again), so you’d need to run it on an older platform if you wanted to play with it.
I can still vouch for Python3-appscript, as that’s what I use myself, but I no longer provide support for any of them because as much as I love Apple event automation and the incredible solutions it makes easy to build, even I accept it has been utterly buggered to death now, and the only question remaining is how much longer till Apple finally put it out our misery for good.
..
That said, if any Hammerspoon fans wish to cross my palm with silver, I’ve previously offered to do a Lua-Apple event bridge for it, and would be happy to do so even now. (Misery loves company.:)
--
[1] No relation to Late Night Software’s original JavaScriptOSA, which like JXA was also riddled with flaws and never went anywhere.
[2] http://appscript.sourceforge.net/
[3] Or thrice, if you count the time after the JXA fiasco that I offered to give Sal my SwiftAutomation bridge [4] outright, just as Swift was starting its meteoric rise, and he threw it back in my face. I’ve dealt with some stupid PMs over the years, but Jebus that one was dumber’n all those other stumps put together. What a waste.
Congrats on finally realizing: Not your paygrade, not your problem to fix.
First rule of automation success: choose the jobs that are amenable to it, not the ones that aren’t. And never forget that people, not machines, are the heart of it.
In which case, why didn’t you just use bash?
Yeah, I know bash stinks. But this is not my fist rodeo* so I’m struggling here to see how CWL stinks less. See again: Inner-Platform Effect, Greenspun’s Tenth Rule.
--
* i.e. I already know how easily “workflow engines” go up their own arse because I’ve done it myself. And CWL fails the same sniff test. Not a good start.
So, more along the lines of https://en.wikipedia.org/wiki/Dataflow_programming. A good problem space to bring declarative/functional/logic/concatenative concepts and tools, IMO, as opposed to the ubiquitous “hit it with a rock” of the usual C* suspects. Be great to see real progress here, but my bullshit detector is immediately dialed to MAX.
The great problem with “workflow systems” is that they very easily disappear up their own ass: “Potemkin solutions” that solve every problem except the customer’s own. (See: https://thedailywtf.com/articles/The_Inner-Platform_Effect). “Enterprise workflows” in particular I think are just a way for indolent code monkeys to shirk learning how the business works for themselves. Looks all very impressive without ever solving shit.
..
FWIW I do think Alan Kay was onto something with his Nile strategy (https://news.ycombinator.com/item?id=10535364). Pity there wasn’t followthrough (bit of a mayfly, Kay). Ditto Iverson and APL, although APL’s sidelining was more down to a nascent Programming Profession redefining Programming™ to be what they do for users rather than what users (mathematicians in this case) do for themselves.