Can anyone define "succeed" in this context? Is it purely popularity? What if a language is inferior but popular?
If a language is effective for its user(s), then is it a "success"?
Is there some minimum number of users that delineates a threshhold for "success/failure"?
What about DSL's that might have a limited number of users?
I like that the author recognized the "success" of shell and C as tied to the "success" of UNIX . But he forgot others, such as sed.
Some my favorite and most powerful languages are not widely used. I have no idea what "succeed" means to others in the context of programming languages, but these languages have "succeeded" for me. They get the job done. Efficiently.
Nothing has surpassed Snobol for pattern matching. (If you are in doubt, post a pattern matching challenge and let's see how the solutions in various languages stack up.)
Meanwhile other implementations of pattern matching have become more popular (=successful?)
Perhaps the word "succeeded" here simply means "succeeded in becoming popular?" If so, then I apologize for the gibberish.
Whenever this gets posted, comments seem to focus on what to use going forward. It seems obvious for most projects there are better alternatives.
However whenever I see autotools documentation I think of only one thing: it's worth learning how this old system works because, even if you will never yourself use it for your own projects, so much code written by others over past decades requires autoconf, automake, often libtool, and sometimes pkg-config.
For me, understanding how these old hacks work is very important in getting a large majority of open source software projects to compile after I make modifications, e.g., removing code.
Oftentimes I think that people who use autotools do not truly understand _how it works_, they have only figured out _how to use it_. This is reasonable but the problem is that autotools is very brittle, and if it breaks they have little idea how to fix it.
To the author: I could not agree more. In the long term history of computing, I would hope this stage we are in now is not the height of the "revolution".
In my humble opinion, to which I am entitled, current Apple hardware is still well-designed like the Apple hardware of the past, but none of it resembles a "bicycyle for the mind".
These phones and tablets are "computers" but are programmable only by permission; they are consumption instruments that are meant to support some plan to dominate the communications, media, entertainment industries. Not my idea of a programmable, pocket-sized, networked computer.
All due respect to Apple and their wild commercial success, but looking to the future, I get more excited about my RPi or Teensy than I do about my Apple devices.
I have little interest in paying for a license to a bloated, complex, proprietary IDE (Xcode) and seeking approval from an "app store" when I can write ARM assembly from a netbook or laptop using a free and open source assembler and run it instantly on the RPi.
The revolution is yet to come. I hope. kparc.com/o.htm
It could also be less than a page. It could be a dummy resource. For example, in the case of an ad server and a smartphone app that has some screen space reserved for ads. You might want your own resource to appear in that space instead.
Another example is reverse engineering API's and protocols for popular web services, social media, storage, etc. In that case you might want a "dummy server" that serves certain responses.
"... but it is not how anyone in their right mind writes C."
If I were going to place blame (I think a better approach is to skip that and just solve the problem), then I would blame developers, not the language.
To me, the code you are criticizing is very "regular" -- it follows predictable patterns. I find it easier to follow than most other C code I read.
More importantly I believe it is worth following. Obviously he is doing something right as reliability, performance and paucity of bugs shows.
All this despite not being in the "right mind", whatever that means.
I wish all the programs I am forced to use were written with such care.
For example, do you have an httpd listening on 127.0.0.1? Do you bind any other daemons to 127.0.0.1 or the broadcast address?
If you operate your own root you can reassign the authoritative nameservers for doubleclick.net to nameservers you control. You may or may not choose to return "A" records.
If sites start moving to HTTP/2, is it true the untrustworthy code can be inserted into the same stream as the "content"?
Everything could be coming from the same domain/IP? This might make blocking ads and tracking more complicated?
My solution as HTTPS spreads is to MITM my own connections so I can see what is being sent and received over the wire. As the article says, it is a PITA. But it is necessary.
Blog posts are just too boring most of the time. We need more direct quotes from the people toeing the creepy line.
That is the behavior that should be tracked. What do you think these "engineers, designers and policy makers" get up to each day? Maybe lots of "pretending to believe" they are doing something meaningful?
The last line from the article you quote is spot on.
Why are alleged "services" provided for "free"?
One group will tell you it's because advertisers are picking up the costs for "content". Another group will tell you that it's because no user (cf. advertiser) would pay if a "fee" were charged to use the www.
Of course, no "free" business model will dare test the theory of the later group, so I guess we'll never know how the user values these "services". Instead the investors and advertisers set the value. Grossly inflated.
In the early days of the internet as I remember it the real (non-hardware) costs for the internet were tolls on telephone calls (dial-up). Organizations picked up the tab for employees who used the internetwork. Tuition-paying students also got access.
Then came UUnet and "ISP's". And then people had their own personal computer, at home, with a network card.
As far as I'm concerned, the internet connection fee is still the only real cost.
I think the browser you allude to is possible. But I think some changes in thinking in how information is structured and presented on the www is needed. If we let the www be shaped solely by web developers with a lust for layers of abstraction and increased complexity and being given carte blanche to run code on others' computers, then it forces the "browser" to be something that is far too complex and too much trouble for any open source volunteer programmer to deal with.
Make the www easier to parse and then the www "browser" becomes easier to replicate. This is only my opinion. Others would certainly disagree.
"The next step... is to merge the different components by using basic computers and have software turn it into servers, storage devices or routers as needed."
This statement is rather enticing because I have been executing this exact process for years using one of the free, open source kernel/userland options available for download. The "OS" is kept small and runs entirely in RAM. Works well enough for my purposes.
It is also interesting to juxtapose this statement against the usual negative comments on HN anytime the discussion turns to building home routers using "basic computers".
But maybe the meaning of "basic computers" by the journalist here is not what I think it is.
My observation: The "discussion" never seems to focus on systemd. Instead it usually turns to comments on the former sysvinit system or other init systems.
That avoidance is perhaps something to ponder. And maybe it's why this author felt the urge to put some focus on systemd itself.
Love the quote from djb. In sum, the best interface is no interface. Parsing amounts to high margin for error and often an incredible nuisance.
In another thread today I wrote about the command line interface and "expecting a reponse". Truthfully, djb's utilities that simply return an exit value and no output are the best ones I have ever used.
(It seems djb himself is a systemd user. Not sure what if anything that means.)
Imagine if the information dissiminated via www was as easy to "parse" as text0. Writing a simple "web browser" might be easy enough that programmers would not need to be paid to do it.
"Want to know why the command line is hard for plebs?"
Not really.
These type of comments are almost always pure speculation, based on one's own experience.
Here's one thing that is true: Everyone who uses the command line was once a "pleb".
Txt'ing is what its name implies. Typing short lines of text. (And anticipating a quick response.) Seems reasonable to make a comparison to using the command line.
IRC, or today's "chat", is also arguably similar. Typing short lines of text, and expecting a quick response.
I have wondered about this for years as SMS and later Twitter, and now "enterprise chat", i.e., typing short lines of text, became popular.
But winning a popularity contest for how people interact with a computer is not something that really interests me.
My prediction based on last 30 years of computing history is that command line interface is never going to disappear (that is one reason I stick with it). It is there for whomever may discover and choose to use it.
"They don't even know what they don't know."
Exactly.
And yet countless GUI lovers/CLI haters continually ask us to believe that some hypothetical user would _choose_ not use a command line interface when they do not even know that such a thing exists; they were never given a real choice.
Who cares what other users want to use? It is their choice, not yours.
"Performance is just the story they are selling in exchange of absolute control of the Web."
To be fair, they are not the only ones that use this "story" as a ploy to get more control over users (and hence gather more saleable personal information).
Phrases like "make the web faster" are disingenuous and should not pass any intelligent user's BS filter.
The very reason the web is slow is because of these companies which need to serve ads and other crud to survive. That means more DNS lookups, more TCP connections, more HTTP requests, more Javascript, longer URL's, more unwanted IMG's (e.g., beacons), more tags, etc., etc. The list is so long I cannot even hope to capture it all. That end result is simple: staring at a screen waiting for the computer to respond. Not to mention frequent leakage of personal information.
As a user of netcat and text-only browsers that retrieve pages in milliseconds, I am astounded at how long users today are willing to wait for their content (i.e., "page loads"). I also run my own web servers at home to serve content to my family's mobile devices. I am well-aware of what (i.e., who) slows down "the Web".
The user does not start from the assumption that she needs to (down)load "resources" (as in Uniform Resource Locator) from a number of advertisers for every page she views. Those are the assumptions that the web company starts with. Those are the constraints they must work within. Not true for users.
I do not need Google DNS. I run my own locally, primed with all the domains I routinely visit. No remote DNS cache is going to be faster than my loopback.
Nor do I need HTTP/2. I just use HTTP/1.1 pipelining to retrieve 100's of pages of content, usually 100 pages at a time. HTTP/2 is something the web companies may need to accomplish their goals of serving ads and collecting personal information. But it is not something users need.
To drive adoption they must convince users that users need these "improvements". So the web companies purport to offer "solutions" to the problem they themselves created: a slow, bloated www.
If a language is effective for its user(s), then is it a "success"?
Is there some minimum number of users that delineates a threshhold for "success/failure"?
What about DSL's that might have a limited number of users?
I like that the author recognized the "success" of shell and C as tied to the "success" of UNIX . But he forgot others, such as sed.
Some my favorite and most powerful languages are not widely used. I have no idea what "succeed" means to others in the context of programming languages, but these languages have "succeeded" for me. They get the job done. Efficiently.
Nothing has surpassed Snobol for pattern matching. (If you are in doubt, post a pattern matching challenge and let's see how the solutions in various languages stack up.)
Meanwhile other implementations of pattern matching have become more popular (=successful?)
Perhaps the word "succeeded" here simply means "succeeded in becoming popular?" If so, then I apologize for the gibberish.