Seriously, the web is not an "API" at all, it's a distributed data graph: a giant state machine where the only permitted operations are reading state, changing state, and introspection, and data transfers are automatically transcoded to whatever representation is most mutually agreeable to client and server. Everything else—information access, emergent behavior, evolutionary flexibility and robustness—is defined and shaped by a handful of ridiculously simple, totally uniform, interaction rules open and available to all. Everyone can read from the web. Everyone can write to the web. Any document. Any time.
Instead of which, the 2Bn+ humans already online and the 5Bn more to follow are being reduced to mindless unquestioning serfdom at the hands of a few Fortune 100 theocrats and their high priesthood of micromanaging OCD martinets, as our ostensibly Open Web is reshaped into the absolute tyranny of these feudal App kingdoms we now have today. The web we have now is not the web we were all promised; it is what a handful of flaming Dunning-Kruger fools and cold calculating greed merchants have turned it into, the better to serve them not us. These endless streams of "Application security holes" and attendant betrayals of web users' data are merely one of myriad symptoms of a misunderstood misimplementation that is 100% rotten to its core.
But I digress.
To reiterate: "Web Programmers" are just absolute fucking [oxy]morons through and through; so preeningly self-assured in the incredible correctness of their Own Understanding and Grand Achievements they aren't even "Not Even Wrong" any more. Power corrupts, and the web has been corrupted completely. Thus humankind shall not be free until it has personally strangled the last Silicon Valley oligarch with the dripping intestines of its last code monkey intern—a much-overdue shitshow I for one hugely look forward to.:)
Any web software or web developer who seriously uses the phrase “REST API” possesses by definition an understanding of how the web is meant to work that is 100% complete and 100% wrong. And security is 10,000% more difficult to learn and implement correctly than HTTP is, so why anyone still trusts either one to such know-it-all idiots is entirely beyond me.
A retina-MBP update is overdue just to keep customers engaged, though with the new design already in the pipeline Apple won't be bumping the current design's specs again, so everyone just has to tought it out till it ships. The 12" MacBook did actually get a refresh earlier this year, though suffers more from its too-high price point than anything else; hopefully the new MBPs will force that down, making it more appealing to the mass-market who just want a nice simple portable laptop for everyday use, but aren't going to break the bank to do so.
That said, sluggishness in refreshing current lines is a secondary problem to failing to cull old lines - non-retina MBP, MacBook Airs - in far more timely fashion. For a company that traded its way to the top on its stunning razor-lean Adonis looks, that middle-age paunch now hanging about it is going to do way more harm to its fearless lead-from-the-front image than any laziness in combing its hair.
the 4 year old model referenced is the base model, that indeed does use the same parts
Yeah, and it's still the SAME PRICE! There's no excuse for that.
Hurrr. Rule #1 of Retail: Your product is worth precisely whatever your customers are prepared to pay for it.
What is truly unbelievable here is that Apple now would deliberately continue to sell such embarrassingly senescent products (non-Retina MPBs) at all. The previous Jobs-2.0 Apple knew that that the way to build new markets and new products was to aggressively kill all its old, stale ones with absolutely zero remorse; and the distraught wails of newly betrayed fanboys was as music to their ears while tens of millions of newly inthralled customers fell over themselves crying as one Take My Money Now!
Sure Cook's Apple is picking up nice easy chump change by continuing to flog such thoroughly matured merchandise. As in gaming consoles, the profit margins on Apple hardware products will improve over their lifetimes as their parts and production costs fall. However, the 2K-era Apple built itself into the world's greatest consumer technology business by selling its own image as THE creator of revolutionary must-have cutting-edge products as much as it did by selling the products themselves. Yet here is that same once-revolutionary knife-sharp Apple, gone fat and soggy, now flogging five-year-old frump off its remaindered rail like some cheap market hawker?
Honestly, when Zombie Jobs-3.0 arises from the grave, I guarantee the only thing round Cupertino still worth selling will be canned goods and shotguns, because the moment he breaks through the barricades he will utterly shred the whole useless lot of them for so casually pissing that incredibly hard-built, inconceivably priceless, and uniquely irreplaceable global reputation up against the washroom wall as these muppets have.
Algorithmic thinking is fatally overrated. Top-down deconstruction of complex problems is a trap into which generations of modern programmers endlessly fall, because all the algorithmic skills in the universe won't make up for a foundational ignorance of the problem domain. This is why so many modern business and government software systems royally suck: because the people—modern professional software engineers—who build them have zero knowledge or interest in learning the jobs those systems are meant to do.
What Logo taught was bottom-up constructionism, where you learn the problem space first though exploration and experimentation. As you go, you compose your own vocabulary of custom words to more efficiently describe it, until you've built up both your own understanding of the problem space and your own set of tools for working within it that you can start to construct solutions to the problems at hand.
For instance, if your task is to draw a city then you don't start by designing the finished roadmap with industrial, commercial, and residential zones, and the complete list of structures that should appear on each—because unless you're already an professional city planner you have zero knowledge or experience in how cities are structured or work. Instead, you start by learning the basics, such as how to construct a house using only the general-purpose primitives you get for free: lines and angles. Using only those, you can create your own words for drawing simple geometric shapes: rectangles, triangles, circles. You can then compose those into words for drawing the outline of a simple building (a rectangle with a triangle on top), a window (a grid of 4 rectangles), a door (a rectangle with a circle for doorknob).
Once you've got that vocabulary, you can very rapidly iterate a whole variety of words for drawing various shapes, sizes, and types of buildings, choosing to keep the words that work best and discarding the ones that don't. While you're learning how buildings are built, you can experiment with adding other kinds of words for drawing trees, park benches, traffic lights, and so on. And once you've built up your own "city-building" vocabulary, you can very rapidly experiment with different kinds of city structures and layouts to learn what works well and what doesn't, once again capturing the successful compositions as your own reusable words.
By the time you're done exploring this particular problem space, not only do you have a really good personal understanding of how cities are put together, you've also got an incredibly powerful—and shareable—language for building cities very quickly and efficiently. Thus your original problem requires only a little more top-down work to arrive at a complete solution. And then, if your first completed city isn't entirely to its inhabitants' taste, that same set of tools also enables you to rebuild it very quickly and easily as well; nothing is set in stone, and improvements made at one level automatically propagate to all subsequent levels as well. Or, you could even introduce them to some of the city-building vocabulary you've already created and let them adapt and enhance your initial cities for themselves.
...
BTW, if this bottom-up approach sounds vaguely familiar to older programmers, that's because it is: it's exactly how Lisp and Forth systems build things (and Logo, which is a hybrid of the two). When the CS profession created Algol, it made a fatal error: it mistakenly declared Algol a general-gurpose language when it was, in fact, a Domain-Specific Language: a procedural number-crunching language specifically designed for the subset of computer users whose job was to write procedural number-crunching systems. And that broken thinking has been steadily baked in ever since—through, C, Pascal, C++, Java, Swift, Python, JavaScript, and so on.
So now we have generations of modern mainstream programmers who are experts in using incredibly complex, dumb, and limited "progr
The key thing that a lot of later things that attempted to replace Logo missed was that Logo was not a tool to teach programming, it was a tool to teach computer-aided thinking. Programming follows naturally from that.
QFT. Papert was a mathematician, galled by the failures of existing math education, who determined to make math easy and accessible to kids. It was never about teaching kids how to code, it was about teaching kids how to teach themselves. Logo was a platform for students to learn and practise the structured thinking and analytical problem-solving skills that would enable them to explore and learn effectively by and for themselves thereafter.
The kids totally got this, of course, because kids can learn anything—in this case, how to love learning and how to learn for themselves. Most adults didn't, because they were raised in a system where "learning" means the blind acquisition and rote regurgitation of Aristotlean "facts", and so learned precisely the opposite. Thus they didn't understand what Papert was trying to do, so rejected it out of their own fear of disruption; or just reinterpreted it to mean whatever they already knew, thus giving us modern "computing" education—which is better termed "Computer Religion" for all the Scientific or Mathematical thinking that it teaches.
Funny enough, Papert himself failed to follow his own teaching: having botched his first attempt at deployment, he never seemed to ask himself what errors he had made and how to correct those and try again. His followup to his truly brilliant Mindstorms was the embarrassing Children's Machine which is pretty much an embittered rant against the evils of School (capitalized as shown); much like Marx on capitalism he identifies its problems but fails to come up with a solution worth poop. And so his vision stumbled and fell at its first real hurdle.
That does not negate the vision itself, however; instead it serves as a cautionary tale that it is not enough to conceive a truly revolutionary idea, but also build the tools and channels necessary to communicate that idea correctly and completely to other people, most of all the people comfortably ensconsed in the status quo who benefit least from such radically disruptive change (parents, teachers, school boards, education departments, politicians, etc.) but without whose buy-in and support that disruption will not get off the ground at all.
...
No doubt all the perfectly well-intentioned but also perfectly wrong idiots—the Scratch-ers, the "Learn to Code" movement, the RasPi-ers, etc.—will be falling over themselves to claim themselves the True Bearer's of Papert's legacy; but honestly they're all so far from being Not Even Wrong they aren't even fit to lick the mud from zombie Papert's toes when returns to chomp their brains in disgust at all the rank garbage they've sold.
And yet, all of Papert's brilliant ideas are still there for the taking; along with all his hard-won lessons of how not to turn them into a world-changing global success. If his little group could get as far as it did with the utterly pitiful computing and communication resources they had back then, imagine what a small group of genuine successors might yet build with the unimaginable wealth of cheap powerul hardware and planet-spanning internet available now. Thus Seymour Papert's real legacy lies not in what he did, but in the direction he set out for those who follow him: to pick up that original idea and run with it further; and keep on doing so until its vision of humanity as fearless and enthusiastic learners, thinkers, questioners, and creators finally wins through.
All it takes is a willingness to learn how to learn—and if 8-year-olds can do it, what's everyone else's excuse?
All good on the theory, hopeless on worked examples for actually testing if your interpretation actually matches his intent, but guess that's how academia rolls.
BTW, if you're wondering why not even the dog will kiss you, it's because you have a mouth like an open sewer.
Encoding information? JSON's just another serialization format; it says nothing about what information a document should contain or how it is organized (beyond being arranged in a tree shape, of course). Some folks prefer it over XML cos it's more lightweight and trivial to work with in JS, though of course there's nothing to stop a RESTful resource offering up representations of itself in both encodings - e.g. application/vnd.initrode.employee.v2+xml and application/vnd.initrode.employee.v2+json - or any other encoding for that matter - plain text, RDF, s-exprs, HTML, XSLX, and so on - if that's what clients are interested in consuming. RESTful content negotiation is about the server saying "here's the information I can provide you with in the encodings I support" and letting the client pick the one that best suits its needs and preferences.
Very likely. It's not about "APIs"; never has been. The web was original designed to be a vastly distributed document publishing system, where everyone could read and everyone could write. The first "web browser" was actually a WYSIWYG editor, kinda like Word except that instead of opening and saving documents on your local drive it opened and saved them across the internet. HTTP was the transport mechanism for that, and crucially it made no statements on what those documents were or how they were encoded; all it did was carry them between web server and web client. HTML was simply conceived as a new document format designed to be particularly well suited to the web, as established document formats back then were rather lacking in hyperlinking support; but there was nothing in the conception, design, or implementation of the web that said HTML was anything special or by any means the only document format that could be used.
So all the groundwork was done and all the pieces correctly in place to build a world-wide web as it was intended to be.
But TBL was lazy and impatient, and rather than making the time and effort port his entire "web browser" application from NeXT to Windows &co he just ported the read part only, because that was the simplest bit. Of course, back then there weren't any other apps (e.g. Word) that knew how to open and save documents across the web, so everyone who saw this read-only web browser in action naturally assumed that that was how the web was intended to work. Nobody piped up to say that actually, the other 80%'s still lying on a workbench in Cern waiting for Timmy to finish his tea, and Version 2.0 will be out Real Soon Now so wait for that before going too far, because if you think that 20%'s great then the full 100% will blow you away!
And then of course the likes of Netscape and Microsoft took this initial idea and codified and standardized and productized and turned it into a whole new "vision" of the web, a horribly crippled, gelded web where everyone could still read from it, but nobody could write directly to it; and the only people who could write to it at all were the tiny tech priesthood who knew how to manually transcode documents to HTML format, then stick them manually onto a web server by arcane backdoor FTP.
...
From that point forward, our entire World-Wide Web was officially Fucked Up Beyond All Recognition, with a constantly diminishing chance of ever being put right again before it could get worse. And then, of course, because nobody outside of TBL's original circle even realized - or was ever told - that the web was specifically designed to let you shift any kind of information from A to B (even automatically transcoding it if B told A it would prefer it in a specific format), it was only a matter of time till Ingeniously Clever And Inventive People like Dave Winer rolled in and decided what the web really needed now was a brilliant New Feature that would allow it to transmit data other than HTML - and hence gave birth to XML-RPC and SOAP and ultimately the ad-hoc RPC-over-HTTP-with-XML/JSON-encoded-parameters that is what today's so-called "REST APIs" are actually doing.
So now we have this utterly bizarre situation where ever web app has this schizophrenic split personality, where HTML-based information exchange is treated as this one huge special case over here, under/..., while information exchange conducted in any other format is conducted way over there, in/api/v2.1/..., each with a totally different data graph and verbs (or pseudo-verbs) for interacting with those graphs. And yet it's all the same bloody information! Refactoring 101 Fail, or What? There should just be one graph, one set of verbs (solely for getting and setting), and the only thing that ever changes is the MIME types that are attached to requests and responses (as Accept
"The fundamental problem with RPC is coupling. RPC clients become tightly coupled to service implementation in several ways and it becomes very hard to change service implementation without breaking clients"
Which is why RESTful HTTP isn't RPC, because we already know it's the wrong tool for this job. The fundamental problem is that today's web has an entire programming cult[ure] raised on OOP to the point where they're pathologically incapable of imagining any kind of interaction model except synchronous local message passing, so instead of bothering to RTFM until they understand correctly how REST works, the lazy toads simply reinterpret "REST" to mean what they already know. Which is 180 the opposite to what it actually is.
Actually, the best way to think about RESTful interactions is as a form of declarative programming, where you say how you want the state of a remote application to look, and then leave that application to figure out for itself how to transition into that state. That's why HTTP only has verbs for performing state changes; any other behaviors a RESTful application might manifest arise purely as side-effects to those state transitions.
But you try explaining this to a modern industry web developer, not only will they not believe you they won't even understand what words you just said. Dunning-Kruger wept.
REST isn't a mess, it's actually a very clean, logical, and elegant state-centric approach to interconnecting vast numbers of highly heterogenous state machines. It's the entire web programming "profession"'s atrocious inability to get what REST actually means, as to what they reinterpret it to mean, to the point where their total misconceptions are now raised to the status of "industry standard".
Protip: Any software developer who uses the phrase "REST API" has a deep detailed technical understanding of REST that is 100% perfectly wrong. Which nowadays is pretty much all of them. Remarkable.
-- It is difficult to get a man to understand something, when his salary depends on his not understanding it. -- Upton Sinclair
Congratulations to the Swagger team on achieving their impressive goal of officially codifying every RESTful anti-pattern ever invented, and let's wish them all the best in formally implementing every known security hole next.
Yup. The only experiment that needs to be performed is to discover what happens when you quietly tip a year's supply of anti-psychotics into their water supply.
Medication is what's needed here, not Faraday cages. Fixed delusions suck.
...feeding these neural nets random images is all fluffy and fun right now, but just wait until someone forgets to turn SafeSearch on; and then it's the rise of Skynet all over again...
Oops, apologies, a thoroughly derpy error on my part: the death rate from chickenpox is actually a teensy smidgin higher than 1 in 3 million, ranging from 1 in 100,000 in children [1], to 1 in 4000 in adults [2]. From CDC's Pinkbook:
The risk of complications from varicella varies with age. Complications are infrequent among healthy children. They occur much more frequently in persons older than 15 years of age and infants younger than 1 year of age. For instance, among children 1–14 years of age, the fatality rate of varicella is approximately 1 per 100,000 cases, among persons 15–19 years, it is 2.7 per 100,000 cases, and among adults 30–49 years of age, 25.2 per 100,000 cases. Adults account for only 5% of reported cases of varicella but approximately 35% of mortality.
My guess [3] is that s.petry took the US's 100 deaths per year and divided it by 300M population to arrive at 1 per 3M death rate, but of course that calculation would only work if the entire population was catching chickenpox every year, whereas only only few percent of the population actually do: those catching it for the first time, those who failed to develop an immune response after catching it previously, and those whose immune systems are compromised for other reasons.
--
[1] or "acceptable losses" in antivax-speak
[2] a.k.a. "they deserved it anyway for not getting sick sooner"
[3] Actually, I know this is what s.petry did, 'cos I made the exact same mistake doing a quick back-of-the-envelope conversion from CDC's description of chickenpox killing 100 people per year prior to varicella vaccine introduction. But it had that "off smell" to it, so I went back and researched further till I found the right numbers, posted them publicly apologizing for any confusion caused, and moved on. Self-correction, it's the nuts.
[s.petry] For example: The highest rate of mortality for Chicken Pox is 100 out of 300Million. This was what could possibly be attributed, which means that most of these people were already fatally ill with things like Leukemia when they contracted the Chicken Pox. The mortality rate of the vaccine according to the CDC is 1 in 30,000. (The actual wording on the CDC site is that 2 out of 15,000 will have extremely severe reactions to the vaccine, and 1 of those will be fatal.
[hondo77] You are completely full of shit. From the CDC site [cdc.gov]: "Serious health problems after (Varicella (Chicken Pox) vaccination are extremely rare."
[s.petry] Try actually searching the CDC site, and you can find some amazing information. Your page is quite different from this CDC page.
A vaccine, like any medicine, is capable of causing
serious problems, such as severe allergic reactions.
The risk of chickenpox vaccine causing serious harm,
or death, is extremely small.
Getting chickenpox vaccine is much safer than
getting chickenpox disease. Most people who get
chickenpox vaccine do not have any problems with it.
Reactions are usually more likely after the first dose
than after the second.
Mild Problems
Soreness or swelling where the shot was given (about 1 out of 5
children and up to 1 out of 3 adolescents and adults)
Fever (1 person out of 10, or less)
Mild rash, up to a month after vaccination (1 person out of 25). It is possible for these people to infect other members of
their household, but this is extremely rare.
Note: The first dose of MMRV vaccine
has been associated with rash and higher
rates of fever than MMR and varicella
vaccines given separately. Rash has been
reported in about 1 person in 20 and fever
in about 1 person in 5.
Seizures caused by a fever are also reported
more often after MMRV. These usually
occur 5-12 days after the first dose.
Moderate Problems
Seizure (jerking or staring) caused by fever (very rare).
Severe Problems
Pneumonia (very rare)
Other serious problems, including severe brain reactions
and low blood count, have been reported after
chickenpox vaccination. These happen so rarely
experts cannot tell whether they are caused by the
vaccine or not. If they are, it is extremely rare.
...
[s.petry] Sure, I'll retract the 1 in 30,000
How... magnanimous of you. Why not just a simple, honest admission that you were completely and utterly wrong, then leave it at that before you make an even bigger fool of yourself? Oh wait, too late:
[s.petry] Funny that attempt to call me a shill yet completely ignore the disclaimer on these pages. How did you miss the fact that the date of your information is from 2008, and provided by Merck. You do know that there are numerous manufacturers of different types of varicella vaccine don't you? And you only cover one.. shame on you.
Slashdot Mirror
Seriously, the web is not an "API" at all, it's a distributed data graph: a giant state machine where the only permitted operations are reading state, changing state, and introspection, and data transfers are automatically transcoded to whatever representation is most mutually agreeable to client and server. Everything else—information access, emergent behavior, evolutionary flexibility and robustness—is defined and shaped by a handful of ridiculously simple, totally uniform, interaction rules open and available to all. Everyone can read from the web. Everyone can write to the web. Any document. Any time.
Instead of which, the 2Bn+ humans already online and the 5Bn more to follow are being reduced to mindless unquestioning serfdom at the hands of a few Fortune 100 theocrats and their high priesthood of micromanaging OCD martinets, as our ostensibly Open Web is reshaped into the absolute tyranny of these feudal App kingdoms we now have today. The web we have now is not the web we were all promised; it is what a handful of flaming Dunning-Kruger fools and cold calculating greed merchants have turned it into, the better to serve them not us. These endless streams of "Application security holes" and attendant betrayals of web users' data are merely one of myriad symptoms of a misunderstood misimplementation that is 100% rotten to its core.
But I digress.
To reiterate: "Web Programmers" are just absolute fucking [oxy]morons through and through; so preeningly self-assured in the incredible correctness of their Own Understanding and Grand Achievements they aren't even "Not Even Wrong" any more. Power corrupts, and the web has been corrupted completely. Thus humankind shall not be free until it has personally strangled the last Silicon Valley oligarch with the dripping intestines of its last code monkey intern—a much-overdue shitshow I for one hugely look forward to.:)
You should patch it to /dev/null. It’s the only way to be sure.
Any web software or web developer who seriously uses the phrase “REST API” possesses by definition an understanding of how the web is meant to work that is 100% complete and 100% wrong. And security is 10,000% more difficult to learn and implement correctly than HTTP is, so why anyone still trusts either one to such know-it-all idiots is entirely beyond me.
Make Up To $37,000,000/Hr In Taxpayer Funds While Working From /Home!
Learn This One Simple Trick That Computer Scientists Don't Want You To Know About!
This Guy Learned 9 Programming Languages in 6 Weeks, You Won't Believe What Happ...SIGSEGV at 0x0
Eh, there's a MOOCher born every minute...
Now see, this attitude is precisely why we can't have nice things. Like girlfriends.
A retina-MBP update is overdue just to keep customers engaged, though with the new design already in the pipeline Apple won't be bumping the current design's specs again, so everyone just has to tought it out till it ships. The 12" MacBook did actually get a refresh earlier this year, though suffers more from its too-high price point than anything else; hopefully the new MBPs will force that down, making it more appealing to the mass-market who just want a nice simple portable laptop for everyday use, but aren't going to break the bank to do so.
That said, sluggishness in refreshing current lines is a secondary problem to failing to cull old lines - non-retina MBP, MacBook Airs - in far more timely fashion. For a company that traded its way to the top on its stunning razor-lean Adonis looks, that middle-age paunch now hanging about it is going to do way more harm to its fearless lead-from-the-front image than any laziness in combing its hair.
the 4 year old model referenced is the base model, that indeed does use the same parts
Yeah, and it's still the SAME PRICE! There's no excuse for that.
Hurrr. Rule #1 of Retail: Your product is worth precisely whatever your customers are prepared to pay for it.
What is truly unbelievable here is that Apple now would deliberately continue to sell such embarrassingly senescent products (non-Retina MPBs) at all. The previous Jobs-2.0 Apple knew that that the way to build new markets and new products was to aggressively kill all its old, stale ones with absolutely zero remorse; and the distraught wails of newly betrayed fanboys was as music to their ears while tens of millions of newly inthralled customers fell over themselves crying as one Take My Money Now!
Sure Cook's Apple is picking up nice easy chump change by continuing to flog such thoroughly matured merchandise. As in gaming consoles, the profit margins on Apple hardware products will improve over their lifetimes as their parts and production costs fall. However, the 2K-era Apple built itself into the world's greatest consumer technology business by selling its own image as THE creator of revolutionary must-have cutting-edge products as much as it did by selling the products themselves. Yet here is that same once-revolutionary knife-sharp Apple, gone fat and soggy, now flogging five-year-old frump off its remaindered rail like some cheap market hawker?
Honestly, when Zombie Jobs-3.0 arises from the grave, I guarantee the only thing round Cupertino still worth selling will be canned goods and shotguns, because the moment he breaks through the barricades he will utterly shred the whole useless lot of them for so casually pissing that incredibly hard-built, inconceivably priceless, and uniquely irreplaceable global reputation up against the washroom wall as these muppets have.
Algorithmic thinking is fatally overrated. Top-down deconstruction of complex problems is a trap into which generations of modern programmers endlessly fall, because all the algorithmic skills in the universe won't make up for a foundational ignorance of the problem domain. This is why so many modern business and government software systems royally suck: because the people—modern professional software engineers—who build them have zero knowledge or interest in learning the jobs those systems are meant to do.
What Logo taught was bottom-up constructionism, where you learn the problem space first though exploration and experimentation. As you go, you compose your own vocabulary of custom words to more efficiently describe it, until you've built up both your own understanding of the problem space and your own set of tools for working within it that you can start to construct solutions to the problems at hand.
For instance, if your task is to draw a city then you don't start by designing the finished roadmap with industrial, commercial, and residential zones, and the complete list of structures that should appear on each—because unless you're already an professional city planner you have zero knowledge or experience in how cities are structured or work. Instead, you start by learning the basics, such as how to construct a house using only the general-purpose primitives you get for free: lines and angles. Using only those, you can create your own words for drawing simple geometric shapes: rectangles, triangles, circles. You can then compose those into words for drawing the outline of a simple building (a rectangle with a triangle on top), a window (a grid of 4 rectangles), a door (a rectangle with a circle for doorknob).
Once you've got that vocabulary, you can very rapidly iterate a whole variety of words for drawing various shapes, sizes, and types of buildings, choosing to keep the words that work best and discarding the ones that don't. While you're learning how buildings are built, you can experiment with adding other kinds of words for drawing trees, park benches, traffic lights, and so on. And once you've built up your own "city-building" vocabulary, you can very rapidly experiment with different kinds of city structures and layouts to learn what works well and what doesn't, once again capturing the successful compositions as your own reusable words.
By the time you're done exploring this particular problem space, not only do you have a really good personal understanding of how cities are put together, you've also got an incredibly powerful—and shareable—language for building cities very quickly and efficiently. Thus your original problem requires only a little more top-down work to arrive at a complete solution. And then, if your first completed city isn't entirely to its inhabitants' taste, that same set of tools also enables you to rebuild it very quickly and easily as well; nothing is set in stone, and improvements made at one level automatically propagate to all subsequent levels as well. Or, you could even introduce them to some of the city-building vocabulary you've already created and let them adapt and enhance your initial cities for themselves.
...
BTW, if this bottom-up approach sounds vaguely familiar to older programmers, that's because it is: it's exactly how Lisp and Forth systems build things (and Logo, which is a hybrid of the two). When the CS profession created Algol, it made a fatal error: it mistakenly declared Algol a general-gurpose language when it was, in fact, a Domain-Specific Language: a procedural number-crunching language specifically designed for the subset of computer users whose job was to write procedural number-crunching systems. And that broken thinking has been steadily baked in ever since—through, C, Pascal, C++, Java, Swift, Python, JavaScript, and so on.
So now we have generations of modern mainstream programmers who are experts in using incredibly complex, dumb, and limited "progr
The key thing that a lot of later things that attempted to replace Logo missed was that Logo was not a tool to teach programming, it was a tool to teach computer-aided thinking. Programming follows naturally from that.
QFT. Papert was a mathematician, galled by the failures of existing math education, who determined to make math easy and accessible to kids. It was never about teaching kids how to code, it was about teaching kids how to teach themselves . Logo was a platform for students to learn and practise the structured thinking and analytical problem-solving skills that would enable them to explore and learn effectively by and for themselves thereafter.
The kids totally got this, of course, because kids can learn anything—in this case, how to love learning and how to learn for themselves. Most adults didn't, because they were raised in a system where "learning" means the blind acquisition and rote regurgitation of Aristotlean "facts", and so learned precisely the opposite. Thus they didn't understand what Papert was trying to do, so rejected it out of their own fear of disruption; or just reinterpreted it to mean whatever they already knew, thus giving us modern "computing" education—which is better termed "Computer Religion" for all the Scientific or Mathematical thinking that it teaches.
Funny enough, Papert himself failed to follow his own teaching: having botched his first attempt at deployment, he never seemed to ask himself what errors he had made and how to correct those and try again. His followup to his truly brilliant Mindstorms was the embarrassing Children's Machine which is pretty much an embittered rant against the evils of School (capitalized as shown); much like Marx on capitalism he identifies its problems but fails to come up with a solution worth poop. And so his vision stumbled and fell at its first real hurdle.
That does not negate the vision itself, however; instead it serves as a cautionary tale that it is not enough to conceive a truly revolutionary idea, but also build the tools and channels necessary to communicate that idea correctly and completely to other people, most of all the people comfortably ensconsed in the status quo who benefit least from such radically disruptive change (parents, teachers, school boards, education departments, politicians, etc.) but without whose buy-in and support that disruption will not get off the ground at all.
...
No doubt all the perfectly well-intentioned but also perfectly wrong idiots—the Scratch-ers, the "Learn to Code" movement, the RasPi-ers, etc.—will be falling over themselves to claim themselves the True Bearer's of Papert's legacy; but honestly they're all so far from being Not Even Wrong they aren't even fit to lick the mud from zombie Papert's toes when returns to chomp their brains in disgust at all the rank garbage they've sold.
And yet, all of Papert's brilliant ideas are still there for the taking; along with all his hard-won lessons of how not to turn them into a world-changing global success. If his little group could get as far as it did with the utterly pitiful computing and communication resources they had back then, imagine what a small group of genuine successors might yet build with the unimaginable wealth of cheap powerul hardware and planet-spanning internet available now. Thus Seymour Papert's real legacy lies not in what he did, but in the direction he set out for those who follow him: to pick up that original idea and run with it further; and keep on doing so until its vision of humanity as fearless and enthusiastic learners, thinkers, questioners, and creators finally wins through.
All it takes is a willingness to learn how to learn—and if 8-year-olds can do it, what's everyone else's excuse?
https://developers.slashdot.or...
https://developers.slashdot.or...
https://developers.slashdot.or...
https://developers.slashdot.or...
Doesn't cover all the philosophy or mechanics, but should do for starters. Ask specific questions where more information is needed.
Oh, and Fielding's writeup from his work on HTTP, natch:
https://www.ics.uci.edu/~field...
All good on the theory, hopeless on worked examples for actually testing if your interpretation actually matches his intent, but guess that's how academia rolls.
BTW, if you're wondering why not even the dog will kiss you, it's because you have a mouth like an open sewer.
Encoding information? JSON's just another serialization format; it says nothing about what information a document should contain or how it is organized (beyond being arranged in a tree shape, of course). Some folks prefer it over XML cos it's more lightweight and trivial to work with in JS, though of course there's nothing to stop a RESTful resource offering up representations of itself in both encodings - e.g. application/vnd.initrode.employee.v2+xml and application/vnd.initrode.employee.v2+json - or any other encoding for that matter - plain text, RDF, s-exprs, HTML, XSLX, and so on - if that's what clients are interested in consuming. RESTful content negotiation is about the server saying "here's the information I can provide you with in the encodings I support" and letting the client pick the one that best suits its needs and preferences.
Good grief, and I've AC'd my other reply too! Hey, I blame Firefox for crashing on me halfway through (it's trying to keep you from the Truth!).
Doh! My reply to you's just got posted as AC. HTH (Though you can still tell by the length, I'm sure.)
Please go read my other post then, preferably while washing your mouth out with Drano.
Well I must misunderstand REST then!
Very likely. It's not about "APIs"; never has been. The web was original designed to be a vastly distributed document publishing system, where everyone could read and everyone could write. The first "web browser" was actually a WYSIWYG editor, kinda like Word except that instead of opening and saving documents on your local drive it opened and saved them across the internet. HTTP was the transport mechanism for that, and crucially it made no statements on what those documents were or how they were encoded; all it did was carry them between web server and web client. HTML was simply conceived as a new document format designed to be particularly well suited to the web, as established document formats back then were rather lacking in hyperlinking support; but there was nothing in the conception, design, or implementation of the web that said HTML was anything special or by any means the only document format that could be used.
So all the groundwork was done and all the pieces correctly in place to build a world-wide web as it was intended to be.
But TBL was lazy and impatient, and rather than making the time and effort port his entire "web browser" application from NeXT to Windows &co he just ported the read part only, because that was the simplest bit. Of course, back then there weren't any other apps (e.g. Word) that knew how to open and save documents across the web, so everyone who saw this read-only web browser in action naturally assumed that that was how the web was intended to work. Nobody piped up to say that actually, the other 80%'s still lying on a workbench in Cern waiting for Timmy to finish his tea, and Version 2.0 will be out Real Soon Now so wait for that before going too far, because if you think that 20%'s great then the full 100% will blow you away!
And then of course the likes of Netscape and Microsoft took this initial idea and codified and standardized and productized and turned it into a whole new "vision" of the web, a horribly crippled, gelded web where everyone could still read from it, but nobody could write directly to it; and the only people who could write to it at all were the tiny tech priesthood who knew how to manually transcode documents to HTML format, then stick them manually onto a web server by arcane backdoor FTP.
...
From that point forward, our entire World-Wide Web was officially Fucked Up Beyond All Recognition, with a constantly diminishing chance of ever being put right again before it could get worse. And then, of course, because nobody outside of TBL's original circle even realized - or was ever told - that the web was specifically designed to let you shift any kind of information from A to B (even automatically transcoding it if B told A it would prefer it in a specific format), it was only a matter of time till Ingeniously Clever And Inventive People like Dave Winer rolled in and decided what the web really needed now was a brilliant New Feature that would allow it to transmit data other than HTML - and hence gave birth to XML-RPC and SOAP and ultimately the ad-hoc RPC-over-HTTP-with-XML/JSON-encoded-parameters that is what today's so-called "REST APIs" are actually doing.
So now we have this utterly bizarre situation where ever web app has this schizophrenic split personality, where HTML-based information exchange is treated as this one huge special case over here, under /..., while information exchange conducted in any other format is conducted way over there, in /api/v2.1/..., each with a totally different data graph and verbs (or pseudo-verbs) for interacting with those graphs. And yet it's all the same bloody information! Refactoring 101 Fail, or What? There should just be one graph, one set of verbs (solely for getting and setting), and the only thing that ever changes is the MIME types that are attached to requests and responses (as Accept
"The fundamental problem with RPC is coupling. RPC clients become tightly coupled to service implementation in several ways and it becomes very hard to change service implementation without breaking clients"
Which is why RESTful HTTP isn't RPC, because we already know it's the wrong tool for this job. The fundamental problem is that today's web has an entire programming cult[ure] raised on OOP to the point where they're pathologically incapable of imagining any kind of interaction model except synchronous local message passing, so instead of bothering to RTFM until they understand correctly how REST works, the lazy toads simply reinterpret "REST" to mean what they already know. Which is 180 the opposite to what it actually is.
Actually, the best way to think about RESTful interactions is as a form of declarative programming, where you say how you want the state of a remote application to look, and then leave that application to figure out for itself how to transition into that state. That's why HTTP only has verbs for performing state changes; any other behaviors a RESTful application might manifest arise purely as side-effects to those state transitions.
But you try explaining this to a modern industry web developer, not only will they not believe you they won't even understand what words you just said. Dunning-Kruger wept.
REST isn't a mess, it's actually a very clean, logical, and elegant state-centric approach to interconnecting vast numbers of highly heterogenous state machines. It's the entire web programming "profession"'s atrocious inability to get what REST actually means, as to what they reinterpret it to mean, to the point where their total misconceptions are now raised to the status of "industry standard".
Protip: Any software developer who uses the phrase "REST API" has a deep detailed technical understanding of REST that is 100% perfectly wrong. Which nowadays is pretty much all of them. Remarkable.
--
It is difficult to get a man to understand something, when his salary depends on his not understanding it. -- Upton Sinclair
Congratulations to the Swagger team on achieving their impressive goal of officially codifying every RESTful anti-pattern ever invented, and let's wish them all the best in formally implementing every known security hole next.
Never know what they're putting in our water supply. Water never used to do this: https://www.youtube.com/watch?...
Aerosolized unicorns, apparently.
Forty untreated psychotics, you mean. Sorry, I wouldn't want them next door either. Meds or GTFO.
Yup. The only experiment that needs to be performed is to discover what happens when you quietly tip a year's supply of anti-psychotics into their water supply. Medication is what's needed here, not Faraday cages. Fixed delusions suck.
...feeding these neural nets random images is all fluffy and fun right now, but just wait until someone forgets to turn SafeSearch on; and then it's the rise of Skynet all over again...
Oops, apologies, a thoroughly derpy error on my part: the death rate from chickenpox is actually a teensy smidgin higher than 1 in 3 million, ranging from 1 in 100,000 in children [1], to 1 in 4000 in adults [2]. From CDC's Pinkbook:
My guess [3] is that s.petry took the US's 100 deaths per year and divided it by 300M population to arrive at 1 per 3M death rate, but of course that calculation would only work if the entire population was catching chickenpox every year, whereas only only few percent of the population actually do: those catching it for the first time, those who failed to develop an immune response after catching it previously, and those whose immune systems are compromised for other reasons.
--
[1] or "acceptable losses" in antivax-speak
[2] a.k.a. "they deserved it anyway for not getting sick sooner"
[3] Actually, I know this is what s.petry did, 'cos I made the exact same mistake doing a quick back-of-the-envelope conversion from CDC's description of chickenpox killing 100 people per year prior to varicella vaccine introduction. But it had that "off smell" to it, so I went back and researched further till I found the right numbers, posted them publicly apologizing for any confusion caused, and moved on. Self-correction, it's the nuts.
OK, here for reference what that page says:
How... magnanimous of you. Why not just a simple, honest admission that you were completely and utterly wrong, then leave it at that before you make an even bigger fool of yourself? Oh wait, too late:
"Like there was all of a sudden a large amount of water full of particulates put on top of this land dwelling animal."
Must've missed that memo from Noah.