Sunday, September 4, 2022

Some things to learn from the British East India Company's growth and demise

The heroism that can win empire has no natural affinity with the wisdom and virtue that improve and consolidate it

Robert Grant

How to get large numbers of people to work together has been a Strange Loop obsession since the first few essays. What’s most interesting to me has been this isn’t a new problem, one that reared up its head in the late 20th century, and our supposed predilection for the complacent life.

Instead, since I wrote the canon, I’ve been wondering what the world looked like historically. After all, we’ve had large organisations before - the Roman empire, East India Company, Genghis Khan and Alexander’s conquering spree, the Chinese and Mughal empire. But in all the books and papers and articles about these that I read there seem some interesting and overlapping themes. This is a first look, and definitely not meant to be exhaustive.

So, to start with, one of the exemplars of administration that found success was the British East India Company. They ruled over an empire, created an empire in point of fact, and seemed to only be dislodged through the Queen’s velvet glove smacking them on the head, dissolving it in 1874 by government decree.

But almost two centuries of success is nothing to scoff at, even considering its ignominious means and the final end.

Chartered on the last day of 1600, the Company was a joint-stock corporation that grew to control most of the Indian subcontinent and wield a mercenary military larger than Britain’s army. Though a private monopoly, it was also a “quasi-independent state body,” writes Ratcliff, closely tied to the British Crown. The 1811 invasion of Dutch Java, for instance, was a combined Royal Navy and East India Company affair. And the British government would bail the joint-stock corporation out financially more than once on the “it’s-too-big-to-fail” model of state-capitalism.

It’s worth noting that in keeping with today’s worry about capitalist excesses, the reign of the Company over the ruled was so bad that the British Empire had to step in as as the good guys.

In 1857 the Indians rose in revolt against high-handed and oppressive Company rule – particularly its insensitivity towards their religions – and it took excessively brutal action by the Company's army to regain control of its possessions.

Following this failure of governance, the British state formally took over the East India Company's rule in India.

But in any case, let’s have a look at the organisation itself. At the top was the Board of Directors, 24 members who were elected by shareholders. below them were several different levels of management, including councils, committees, and officials. Each level had different responsibilities and authority levels. For example, the Board of Control oversaw all aspects of company policy, while lower-level officials were responsible for specific tasks such as trade or military operations. Their hierarchical system ensured decision-making could be centralized at the top levels while still allowing flexibility at lower levels, allowing quick response to opportunities or threats as they arose.

For instance the Company, once it started owning land, getting state appointments and engaging with the Nawabs in India, decided they needed court representation. But they of course couldn’t be full fledged ambassadors. And so they decided on a role called a Resident.

A Resident was effectively the cultural intermediary between the Company and the various Indian Raj’s they were with. They were knowledge conduits in both direction, had diplomatic duties both implicit and explicit, helped build bridges between the two people.

This level of responsibility is of course easily described in large, handwavy sentences, and impossible to describe in any meaningful detail. But the impact is extremely clear, whether that’s in identification and building of new ports, identifying new trade cargo and routes, or currying favour by lending their army to expand their empire.

So, they were undeniably effective, and grew fast, and survived for a long time. The question is how did they do this? Grow so fast and so effectively at a time when getting a message back and forth took months!

What did they do differently?

Efficiency

The first interesting thing is that while the structure, the charter and all that sounds about normal for any corporation, they had less than 200 people until the 1800s in the London office, part time clerks and all. That is efficiency!

In fact, there’s a wonderful dataset of all the clerks employed by the Company over a period of more than a century. (The category of clerk, which forms the basis for this dataset, includes a high proportion of the Company's home employees, ranging from low servants to senior managers with executive authority.)

Bear in mind by this time they had conquered plenty of land, especially Marquess Wellesley (1798-1805), and the Marquess of Hastings (1813-23).

In fact by 1856, with the annexation of Oudh, all the Indian subcontinent up to the Himalayas, and much of Burma, was ruled directly by the Company itself or by local allied rulers.

Even having a commanding army at their disposal, this is a small fraction of what it takes to do anything today.

Compensation and incentivisation

The Company seemed to pay its employees pretty well, had a ton of perks, and gave them the opportunity to profit alongside the organisation. For instance, at the headquarters as time went on, they did get more professionalised (or so it looks like), as the average incomes went up considerably.

Part of this is due to the fact that there were quite a bit of part time employment that started in the late 1700s/ early 1800s, when they were scaling quickly and needed help, and partly because the tenure of employees was increasing over time.

In 1815, a new clerk would start at £40 per year (compared to average worker salaries, about £28,590 today ($41,138). But that would rise: an employee working for 11 to 15 years would earn £220 a year (£157,200); after 39 years of service, £600 a year (£428,800).

The working conditions seemed to be quite variable. While in London they didn’t have any annual leaves and often worked 10-12 hour days (with a 2 hour lunch), the conditions in the factories were slightly different.

And at the Surat factory in the 17th Century, Ovington tells us, clerks rose at dawn, prayed, worked from 10 to 12, ate a large lunch, took a siesta, and worked again from 4pm to 6pm, followed by prayers, supper and relaxing by the water or a garden.

Moreover, in order to keep people engaged in their work, especially to take on perilous sea voyages and be away from home for years on end, there were plenty of perks.

While not quite Google cafeteria, the lunches and dinners served were exquisite! Free breakfasts in London, and on-site cooks (English, Portuguese and Indian) in factories, with plenty of alcohol to go around.

On Sundays and holidays, that menu could swell to 16 courses and include peacocks, hares, venison and “Persian fruits” like pistachios, apricots and cherries.

In one year at a factory in Sumatra, the 19 workers consumed “74.5 dozen bottles of wine, 50 dozen of French claret, 24.5 dozen of Burton Ale, 2 pipes and 42 gallons of Madeira, 274 bottles of Toddy and 164 gallons of Goa arrack”.

If that’s not enough, if you were a senior officer you got a pretty great stipend to spend on entertaining others.

In the early 19th Century, some official East India Company dinners cost more than £300, equivalent to some £19,850 ($28,554) today, while the Chairman received another £2,000 per year (about £132,300) for entertaining.

Also, they had an incredibly sexy headquarter to work in (marble bas-reliefs, pipe organ of a tiger devouring a European and jewel-encrusted gold throne of the Sultan of Mysore Tipu). Even the warehouses were elegant and stylish in the City.

Also, in one of the most interesting ways to ensure alignment, personal trading within the employees was allowed. Which means that someone who was truly enterprising could create their own bonus structure, and if successful make enough to comfortably retire thereafter.

Furthermore, the decentralization that took the form of private trade allowances, served as a motivation for the employees to stay for longer periods in the East, and help integrate the existing English settlements within a tight communication network while also caused a surge for exploring new ports.

It perfectly aligns the risks that the Company wanted their employees to take while not having to specify exactly how they took those risks. Talk about ESOPs.

The reason looking back at this era is so interesting is because communication latencies make almost any remote management impossible. Which means we get to see the benefits (and drawbacks) of having and needing high agency people to basically do anything with minimal oversight.

Hiring

EIC had to hire folks who could be relied upon to do their duty under reasonably autonomy and minimal instruction. At first, the Residents and other similar positions were fulfilled by military personnel. After all, the military was the most powerful part of the Company in a rather literal sense.

Soon after though, they started being brought in from civil services or those educated in specialised colleges.

Even taking into account the incredible amounts of nepotism, for everything including manual labour jobs, you needed a nomination from one of the company’s 24 directors. According to Huw Bowen;

Success was ultimately dependent upon connection and influence rather than the possession of any skills and aptitude for the post

You often needed to demonstrate commitment to the job by putting down cash, often £500 (this would be 100x bigger today). The amount increased by about 10x, or $5k, if you wanted to be the president of an overseas factory. What this did of course is that the jobs went mostly to those who could pay.

The Indian Service was confined to comparatively few families and he might reasonably expect to find relatives or friends of relatives at any of the three Presidencies, and these would give him hospitality and guidance. His initial employment would be as a copying clerk ; as such he would become familiar with the routine of the service before being given a post of responsibility.

Eventually they created the East India College to help educate the clerks, teaching all the essentials - “On the curriculum: history, the classics, law – and Hindustani, Sanskrit, Persian and Telugu.

A step down from the leaders though the clerks were treated as if they were apprentices to be kept an eye on. For instance:

the depots were set up like monasteries or Oxford colleges, and workers slept, ate and prayed under the eye of their superiors.

The college had plenty of detractors, even during its life. It combined worries of high expense, the curriculum to train recruits, regarded as “a sink of immorality and vice, of disorder and irregularity”. As today, the major education method to create future Colonial officials had plenty of armchair theorists to naysay.

They even had their share of celebrity teachers.

Paying high salaries and granting generous pensions, the Court was able to employ a large number of prestigious educators, including in the first corps Thomas Malthus.

But the very movement from having appointments done by patronage to appointees educated specifically to be helpful in the local context is a major change.


Putting this together, the methods of hiring, incentivisation and operational efficiency seems to align reasonably well with some models of management today. However one major difference I can see is that with the communication latency being so low, it’s well nigh impossible to do anything beyond giving your employees autonomy.

The natural end result of the low communication latency was that the authority atop almost always had duties of punishment rather than the ability to charge exactly what a subordinate officer should do.

This, of course, is a highly charged strategy. After all, there are plenty of things for which forgiveness cannot be sought and punishment cannot fix.

Moreover, this is only possible if the people in whom you place the trust are capable of using it in the right fashion. There were the usual rules, for instance, on the need for strict separation of public duties from private enrichment, though by all accounts those were almost always ignored.

The really interesting bits were not just ornamentation though. They were integral to how the Company was set up and organised. They were definitely not afraid to move fast and break things, even when things meant entire regions and huge swathes of local population.

But despite this, from an organisational lens, the interesting bit is the dichotomy between the centralised planning and governance and rule-setting that they did from London, and the freewheeling nature of the local administration and the representatives. It’s also a dichotomy between the long hours and hard work that the yardmen put in in the London warehouses and Bombay factories, compared to the gunslinger approach that the Residents or Governors took towards finding new opportunity and capitalising on it.

We take it as an article of faith that the higher levels of information transparency and speed is a good thing. And it indisputably is. But a consequence of it happening has been that in many (most?) cases it’s been used as a reason to reduce the autonomy at the edge.

Today, in a similar situation to where EIC found itself, you would have a much larger corporate office, reviewing and validating each piece of information that came in from the field, analysing it, and sending out crisp commands that those Residents would have to obey.

Does this world function better? Well, depends on your assumptions on the inputs.

If the people being hired are pretty good, then no it’s not that much more of a benefit. If the people being hired can’t easily be trusted, then yeah, more oversight is gonna help a lot.

In the case of EIC at least, though they had strict governing rules they were rarely applied, which meant they were functionally quite decentralised.

Through the fostering of the utilization of social networks and the cohesive internal structures, the Company and its private army managed to integrate and expand the operations of the Company in the East, in a coordinated manner. It is noteworthy that the social networks utilized by the Company were instrumental in transferring crucial information among the employees, and thus resulting in the incorporation of new ports to the ever-growing trade network of the Company.


This same premise that worked for EIC might not exactly work in today’s more complex world. There is a world of difference between a PM working at Stripe trying to figure out the way to make a new product work and a new Resident using his own initiative and intuition to figure out the best way to expand the Company’s purpose. Where to deploy your private army is a reassuringly rare problem for the modern graduate.

The latter is much closer to freeform Partnerships or Enterprise Sales functions, where success is measured and measurable. Similarly, opening a new office in a different country, or starting a new skunkworks project, could be run with much more autonomy provided to those running it.

But even this process still runs with much faster and tighter feedback loops today! Iterations happen much faster, not just with the customer, but also internally. CEOs get to block new initiatives, GMs get much more frequent instructions from above, below and from her peers. Decision making is frequent, as are decisions made about decisions made by others.

If you think of any company as a network, with nodes linked through communication, then this is effectively a question of how much computation you believe should be done by the nodes at the edges, vs the central nodes.

The individual “nodes” don’t make many decisions on their own. The decisions they do get to make are often reconsidered, evaluated, analysed and often overridden under fairly short term time pressures.

How much of the decision making should be made central vs how much at the edges is a central question in organisational design. But no matter how we decide upfront, the end result inexorably pushes towards higher centralisation as the information latency decreases.

After all, if you are the boss and you get to see the information your subordinate sees roughly at the same time, the urge to make the decision over her head is quite high!

Some of this is even sensible. After all, if you can centralise analysis of multiple incoming data streams, you can create better action plans. But this is rarely universally true. Computational power with all new data-flows about everything happening at the company everywhere does asymptote, which makes central decision making ineffectual.

But amongst everything else, I think my biggest takeaway thus far is that we confuse communication latency with analysis speed.

Just because we can see more information faster, doesn’t mean we know how to make sense of any or all of it. The lessons are more complex than “treat your people as ends not means”, though that’s a big part of it. It combines:

  • People knew when they could ignore the rules so they could do things that helped the Company

  • They ran with a much smaller bureaucracy centrally than what we’d think necessary, even with multiple committees to devolve decision making into

  • In many cases the employees could trade for themselves on the side, i.e., helping the Company helped themselves - like a franchise model in miniature, or even a version of equity shares

  • When you ask a lot from employees, its good to give them a lot - whether its salary, perks, nap rooms or better working conditions

  • You need at least a few people who are freelance gunslingers to go unlock opportunities you can’t know about, to explore more of the territory

  • There’s an increase in focus on assessments (and punishment) after the fact rather than permission to perform an action

It’s an interesting test of how to design an organisation to stand the test of time and expand across multiple continents, and to ensure you get maximum use of employee creativity by giving them autonomy, while still creating enough safeguards to align them with your own interests.

All that said, one final note, from the famous Charles Lamb, the eminent essayist, who worked for the Company. As he wrote to William Wordsworth.

I grow ominously tired of official confinement. Thirty years have I served the Philistines, and my neck is not subdued to the yoke. You don’t know how wearisome it is to breathe the air of four pent walls, without relief, day after day, all the golden hours of the day between ten and four, without ease or interposition. O for a few years between the grave and the desk!

Some things never change.

Share

Addendum: this tweet is precisely the point!



from Hacker News https://ift.tt/EFI6A81

Why Was Western Printing Superior to Asian Printing?

Traditional Chinese Printmaking Panel
Traditional Chinese Printmaking Panel

We likethink of Johannutenberg as inventor of the printing press and movable type in 1450. Yet, the first movable type got invented in China around 1040 by Bi Sheng. The types were made from porcelain material. Later wooden movable types were developed by Wang Zhen around 1297. Koreans evolved the movable type technology further. In 1234 the first books known to have been printed using metallic types was published in Korea. It happened during the Goryeo Dynasty.

So, why are we giving Gutenberg all the credit for inventing printing? Because Gutenberg served the same role for printing as James Watt did for the steam engine. Neither of the men were the original inventors of the concept, but they made improvements so radical that they made the technology transformational.

Old printing press in similar style as Gutenberg's printing press

Gutenberg made a mechanical machine, a printing press, which allowed printers to greatly speed up the printing process. Asian printing in contrast involved rubbing paper into types covered in ink. It was not done using a machine, and it was not done using mass-produced metal types. The difference was profound. Around 1600 European printing presses could output 1500 to 3600 pages per day. Chinese printing technique in contrast could only do about 40 pages per day.

Development in book prices and productivity
Development in book prices and productivity

The printing press led to a sharp drop in book prices. From the invention of the printing press to 1500, books got about 60 times cheaper. By 1600 books had gotten 300 to a 1000 times cheaper. This price reduction made it possible to spread scientific knowledge cheaply all over Europe. With the lower price came a sharp increase in demand for scientific and academic study.

The printing press also allowed Europeans to catchup with China in literacy. Why were Europeans far behind the Chinese in literacy? A key reason was the lack of a cheap material to write on. Europeans used parchment and vellum, which are both made from animal skins, which make them excessively expensive compared to paper. Although you should keep in mind that the cheap paper we use today, based on wood pulp, wasn't invented until 1844. Thus, when I discuss paper in this story, I am talking about paper made from textiles.

Paper didn't arrive in Europe until the 11th century in the Islamic parts of the Iberian Peninsula (Portugal and Spain). Meanwhile, the Chinese had paper at least since the Han dynasty (25–220 AD).

Old Chinese traditional medicine ancient book.
Old Chinese traditional medicine ancient book.

Lacking paper caused Europe to fall far behind China in terms of literacy and published works. From the 4th to the start of the 16th century, the largest Chinese library collections were 3-4 times larger than the largest library collections in Europe.

What is remarkable is that we don't have evidence of paper-making in Germany until 1390. Thus, from the arrival of paper in Germany, it only takes 50 years before Johannes Gutenberg begins working on his printing press in 1440. Ten years later, in 1450, he has perfected the printing press enough to use it for commercial operations.

How the size of the largest book collections grew after invention of the printing press
How the size of the largest book collections grew after invention of the printing press

Thus, from the 15th century European intellectual life became supercharged and a staggering transformation takes place. For instance, the Venetian Domenico Grimani's collection numbered 15,000 volumes by the time of his death in 1523. That was 3 times larger than the largest Chinese book collections. After 1600, European collections completely overtook those in China. The Bibliotheca Augusta numbered 60,000 volumes in 1649 and surged to 120,000 in 1666.

We can agree that the transformation was profound, but the question is: Why was European printing superior to Asian printing? Was it only because of the printing press? And why couldn't the Chinese or Koreans invent a printing press?

It took Germany only 50 years from paper production starting until development of a printing press began. China, in contrast, had a head start of over a thousand years.

Answering this question is actually quite complex because it involves mechanical knowledge, metallurgy, mills and writing systems. I have read numerous articles on this topic, but I started to notice that everyone leaves out some different essential part of the story. Here I am trying to include all the factors involved.

To fully appreciate the next section, I advice you to read my article describing printing terminology and technique.

The advantages of Western printing derives from several innovations by Gutenberg:

  • Using a machine, the printing press, to speed up the printing process

  • A hand mould for creating lead types quickly

  • Using a lead, tin, and antimony alloy for types

  • Oil-based ink rather than traditional water based ink

Imprinting ink on a sheet of paper was a manual and careful process with the Asian movable type system. The printer would rub the paper into the typeset page repeatedly. Gutenberg in contrast used a screw press to transfer ink from the metal types to the paper in one single action. That made printing a page significantly faster.

A simple metal screw press. The Gutenberg printing press used a wooden screw press.
A simple metal screw press. The Gutenberg printing press used a wooden screw press.

The printing press also had several features to help align the paper correctly, reducing the chance of human error.

China used carved wood based characters for a long time. Even as late as 1733 we can find major works printed using wood carved characters. The reusable metal matrix pioneered by Gutenberg allowed a single experienced worker to produce 4,000 to 5,000 individual types a day. With wood carving, no more than 70 types could be made per day.

What made it so fast to make types was a simple hand mould similar to the one seen below, where a matrix could be slotted in. The two pieces shown below would be placed on top of each other before pouring the lead alloy into the funnel-like shape at the top, marked c and b.

A mould for creating types
A mould for creating types

The alloy was such that a type would cool and turn solid almost instantly, allowing for quick production of identical types.

As mentioned earlier, Korea developed bronze-based types for printing, which later got adopted in China. Wouldn't that put Asia on equal footing with Europe in terms of printing?

No, because bronze is not ideal for making types. The melting temperature is twice as high, making it far less practical to use. Secondly, bronze, like most metals, shrink when cooled. That made it hard to make an accurate duplicate of your type.

The Korean method relied on creating a matrix (mould) in clay using a carved wood type. In other words, a wood type was used as punch instead of a steel type. A clay mould is naturally not very durable. Gutenberg's method involved punching an indentation into a copper plate. A copper matrix was naturally far more durable and could be used repeatedly.



from Hacker News https://ift.tt/PKMBw3T

Saturday, September 3, 2022

Python multi-level break and continue

Welcome to LWN.net

The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider subscribing to LWN. Thank you for visiting LWN.net!

By Jake Edge
August 31, 2022

A fairly lengthy discussion of whether there should be a way to break out of (or continue) more than one level of nested loops in Python recently took place in the Ideas category of the language's discussion forum. The idea is attractive, at least in an abstract sense—some other languages support jumping out of multiple loops at once—but it seems unlikely to go anywhere for Python. The barrier to new features is fairly high, for sure, but there is also a need for proponents to provide real-world examples that demonstrate their advantages. That, too, is a difficult bar to clear, as was seen in the discussion.

Idea

A user called "Python Millionaire" posted an example of some loops that they had written to process data about some basketball players; "I want to continue or break out of the nested loops because I am no longer interested in the player". They proposed adding an integer to break and continue statements to specify how many loops to operate on. For example:

    for player in all_players:
        for player_tables in all_tables:
            for version in player_tables:
                # things have gone wrong, need to break
                break 2

            this_is_not_reached = True

        this_line_is_called()

If Python ever gets this feature, though, the (un-Pythonic?) integer mechanism will surely not be part of it. It is terribly fragile when code gets shuffled around, for one thing. Also, as Bryan Van de Ven observed, it would be "a usability nightmare" because it would be difficult "to quickly locate the target of your fancy goto by means of a simple code grep".

This is not the first time the idea has come up; the feature was raised 15 years ago by Matt Chisholm in PEP 3136 ("Labeled break and continue"). The PEP was rejected by Guido van Rossum for a variety of reasons, including a worry that the feature would "be abused more than it will be used right, leading to a net decrease in code clarity". Peter Suter pointed to the PEP in the discussion, noting that Millionaire "would presumably need at least some very convincing examples that outweigh the reasons given in the rejection notice".

PEP 3136 offered several possibilities for the syntax of the feature, and did not choose one, which was another reason Van Rossum rejected it. But it seems clear that the labeled version is seen as the most viable path, even among those who are against adding the feature. A labeled break might look something like the following:

    for a in a_list as a_loop:
        for b in b_list as b_loop:
            if ...
                break a_loop

That break would exit both loops immediately; a labeled continue would go to the next iteration of the named loop.

Millionaire thought that after 15 years it might be time to reconsider the idea. They lamented that the approaches suggested to work around the lack of multi-level break are "infinitely clumsier" and "anti-pythonic". Suter agreed with that to a certain extent, noting the first search result for "python multiple for loop break" is a Stack Overflow answer that is overly clever. Suter adapted it to the original example as follows:

    for sport in all_sports:   # "for sport" loop
        for player in all_players:
            for player_tables in all_tables:   # "for player_tables" loop
                for version in player_tables:
                    # things have gone wrong, go to next iteration of all_sports loop
                    break
                else:
                    continue
                break
            else:
                continue
            break

That uses the else clause for loops, which will execute if no break is used in the loop, thus the loop runs to completion. So if the innermost loop runs to completion, the continue in the else will result in another iteration of the "for player_tables" loop. If the inner loop uses break, however, it will break twice more, all the way back to the "for sport" loop. As can be seen from that convoluted description, the construct is far from readable—or maintainable.

Other ways

There are multiple ways to accomplish what Millionaire is trying to do, some of which were described in the discussion. Using flags is one obvious, perhaps clunky, mechanism, another is to use exceptions, but that may not be much less clunky. Overall, though, several participants thought that the code itself should be refactored in some fashion. Chris Angelico thought that moving the search operation into its own function, which can return once the outcome is known, would simplify things. Steven D'Aprano agreed:

The obvious fix for that ugly code is to refactor into a function:
def handle_inner_loops(sport):
    for player in all_players:
        for player_tables in all_tables:
            for version in player_tables:
                if condition:
                    # things have gone wrong, bail out early.
                    return
                block()

for sport in all_sports:
    handle_inner_loops(sport)
The solution to "Python needs a way to jump out of a chunk of code" is usually to put the chunk of code into a function, then return out of it.

Millionaire thought that requiring refactoring into a function was less than ideal. It is also not possible to implement a multi-level continue that way. Beyond that, Millionaire pushed back on the notion that labeled break/continue was a better syntactic choice in all cases; offering the numeric option too would give the most flexibility. There was little or no support for keeping the numeric version, however.

But the arguments given in support of the feature were generally fairly weak; they often used arbitrary, "made up" examples that demonstrated a place where multi-level break could be used, but were not particularly compelling. For example, "Gouvernathor" posted the following:

    for system in systems:
        for planet in system:
            for moon in planet.moons:
                if moon.has_no_titanium:
                    break 2 # I don't want to be in a system with a moon with no titanium
                if moon.has_atmosphere:
                    break # I don't want to be in the same planetary system

As D'Aprano pointed out, though, that is hardly realistic; "your example seems so artificial, and implausible, as to be useless as a use-case for multilevel break". He reformulated the example in two different ways, neither of which exactly duplicated the constraints of Gouvernathor's example, however. He also had some thoughts on what it would take to continue pursuing the feature:

To make this proposal convincing, we need a realistic example of an algorithm that uses it, and that example needs to be significantly more readable and maintainable than the refactorings into functions, or the use of try…except (also a localised goto).

If you intend to continue to push this idea, I strongly suggest you look at prior art: find languages which have added this capability, and see why they added it.

Angelico noted that he has used the Pike programming language, which does have a labeled break. He found that he had used the feature twice in all of the Pike code he has written. Neither of the uses was particularly compelling in his opinion; one was in a quick-and-dirty script and the other is in need of refactoring if he were still working on that project, he said. That was essentially all of the real-world code that appeared in the discussion.

Paul Moore suggested that needing a multi-level break may be evidence that the code needs to be reworked; "Think of it in terms of 'having to break out of multiple loops is a code smell, indicating that you should re-think your approach'." Though he questioned the value of doing so, he did offer up a recent example:

I don't think everyone piling in with their code samples is particularly helpful. The most recent example I had, though, was a "try to fetch a URL 10 times before giving up" loop, inside the body of a function. I wanted to break out if one of the tries returned a 304 Not Modified status. A double-break would have worked. But in reality, stopping and thinking for a moment and factoring out the inner loop into a fetch_url function was far better, named the operation in a way that was more readable, and made the outer loop shorter and hence more readable itself.

Workarounds?

Millionaire complained that all of the suggestions that had been made for ways to restructure the code were workarounds of various sorts; "They are all ways of getting around the problem, not actual solutions presented by the programming language, which should be the case." But Oscar Benjamin said that he could not "picture in my mind real maintainable code where labelled break is significantly better than a reorganisation". All he can see in his mind is the feature "being used to extend the kind of spaghetti code that I already wish people didn't write". There is, of course, an alternative: "if real life examples were provided then we could discuss the pros and cons in those cases without depending on my imagination".

Meanwhile, others in the discussion pushed back against the workaround complaint and also reiterated calls for real-world code. Millionaire returned to his earlier basketball example, with a beefed-up version that uses labeled break and continue. While Millionaire seemed to think it was a perfectly readable chunk of code that way, others were less impressed. Angelico questioned some of the logic, while Van de Ven thought it did not demonstrate quite what Millionaire was claiming:

A 50-line loop body and eight levels of indentation (assuming this is inside a function) and this is the good version? Having a multi-break won't didn't fix that. All the complexity in that code stems from trying to do ad-hoc relational querying with imperative code, at the same time as pre- and post-processing.

Van de Ven and Millionaire went back and forth a few times, with Millionaire insisting that Van de Ven's refactorings and other suggestions were not mindful of various constraints (which were never mentioned up front, of course). Van de Ven thought that the episode was an example of an XY problem, where someone asks about their solution rather than their problem, but he still persisted in trying to show Millionaire alternative ways to structure their code. There are, seemingly, several avenues that Millionaire could pursue to improve their code overall, while also avoiding the need for multi-level break—if they wished to. But that is apparently not a viable path for Millionaire.

The discussion was locked by David Lord shortly thereafter; it was clear that it had run its course.

The convoluted examples presented in the thread were not particularly helpful to the cause, in truth. Users who want to add a feature to Python should have an eye on compelling use cases from the outset, rather than generalized feelings that "this would be a nice addition" to the language. If, for example, code from the standard library had been shown, where a multi-level break would have significantly improved it, the resurrected feature idea might have gained more traction. There are lots of other huge, open Python code bases out there, as well; any of those might provide reasonable examples. So far, at least, no one has brought anything like that to the fore.

This is something of a recurring theme in discussions about ideas for new Python features. To those who are proposing the feature, it seems like an extremely useful, rather straightforward addition to the language, but the reception to the idea is much different than expected. Python developers need to cast a critical eye on any change to the language and part of that is to determine whether the benefit outweighs the substantial costs of adopting it. That is not going to change, so it makes sense for those who are looking to add features to Python to marshal their arguments—examples—well.


(Log in to post comments)



from Hacker News https://ift.tt/gWLfrmG

The Best Debugging Story I've Ever Heard

The Best Debugging Story I’ve Ever Heard

Back in the early 80’s, my dad worked at Storage Technology, a now-defunct corporate entity that made tape drives and pneumatic systems to drive these tapes at high speeds – for that period of time.

(Used under license from Laughing Squid. The original is available here.)

They had hacked engineered the tape drives such that you could have one central drive – the ‘A’ drive – connected to seven other 'B’ drives, and a small operating system on some RAM attached to the A drive would delegate the reading and writing of data across all of the B drives.

Every time you started up the A drive, you had to insert a floppy disc into a peripheral drive connected to the A drive so that the operating system could be loaded onto the A drive’s RAM. The operating system was appallingly primitive - it derived its processing power from an 8-bit micro controller.

The target audience for this sort of thing were corporations with very large data sets - banks, magazines, et cetera - that needed to print huge amounts of address labels or bank statements.

One customer had a problem. In the middle of a print run, one particular A drive would stop working, causing the entire print run to stop. To restore the drive the attendants had to reboot the entire drive - and if this happened in the middle of a six-hour print job, there’d be a ton of expensive computer time lost and the whole operation would fall behind schedule.

So Storage Technologies sent out technicians. The technicians, despite their best efforts, could not reproduce the bug in test settings: this bug seemed only to happen in the middle of large print jobs. So, on the off chance that this was a hardware issue, they replaced everything they could - the RAM, the microcontroller, the disk drive, every conceivable part of the tape drive - but the problem kept happening.

So the technicians phoned up headquarters and called in The Expert.

The Expert got a chair and a cup of coffee and sat in the computer room – these were the days when they had rooms specifically dedicated to computers, after all – and watched it as the attendants queued up a large print job. He waited until it crashed - which it did. Everybody looked to The Expert – and he didn’t have a clue what was causing it. So he ordered that the job be queued up again, and all the attendants and technicians went back to work.

The Expert sat down in his chair again, waiting for it to crash. It took something like six hours of waiting, but it crashed again. He still had no idea what was causing it, other than the fact that it happened when the room was crowded. He ordered that the job be restarted, and he sat down again and waited.

By the third crash, he had noticed something. The crash occurred when the attendants were changing the tapes on an unrelated drive. And furthermore, he realized that the crash occurred as soon as one of the attendants walked across a certain tile on the floor.

This type of floor was made of aluminum tiles propped up by posts about 6 to 8 inches tall. The massive amount of wires that these computers needed were threaded under the floor tiles so that an unwary attendant wouldn’t trip over a crucial cable. The tiles were put together very tightly so that no debris would fall into the space where the wiring went.

The Expert figured out that one of the aluminum tiles was warped. When an attendant stood on the corner of the warped tile, the edges of the tiles rubbed together. As the plastic connecting the tiles rubbed together, they produced microsparks, which in turn caused RF interference.

Nowadays, RAM is much more thoroughly shielded from RF interference. But back then, this was not the case. The Expert figured out that the RF interference was corrupting the RAM and, in turn, the operating system.

The Expert called the maintenance office, got a new tile, installed it himself, and the problem went away.



from Hacker News https://ift.tt/R9LO3FE

Dear Oracle, Please Release the JavaScript Trademark

In 1995 Netscape partnered with Sun Microsystems to create interactive websites. Famously Brendan Eich spent only 10 days to create the first version of JavaScript - a dynamic programming language with a roughly syntactic lineage from Sun’s Java language. As a result of this partnership Sun held the trademark “JavaScript”. In 2009 Oracle acquired Sun Microsystems and the JavaScript trademark as a result.

Read More

An international exchange program should be established for workers in local city services to foster the sharing of ideas. There are few opportunities for local tradespeople to share ideas and techniques outside of their region; the goal is to fix that.

Read More

The majority of server programs are Linux programs. They consist of a file system, some executable files, maybe some shared libraries, they probably interface with system software like systemd or nsswitch.

Read More

This post is in response to the Optimistic Nihilism video by Kurzgesagt. Optimistic Nihilism perfectly describes my perspective on life and the universe. I want to add my interpretation of the philosophy and spice it up with some science fiction ideas.

Read More

Last year, after nerding out a bit on TensorFlow, I applied and was accepted into the inaugural class of the Google Brain Residency Program. The program invites two dozen people, with varying backgrounds in ML, to spend a year at Google's deep learning research lab in Mountain View to work with the scientists and engineers pushing on the forefront of this technology.

Read More

Have you seen Reddit's /r/colorization sub? People use photoshop to add color to old black and white photos. This is a good problem to automate because perfect training data is easy to get: any color image can be desaturated and used as an example.

Read More

It's unnecessary and complicated at almost every layer. At best I can congratulate someone for quickly and simply solving a problem on top of the shit that they are given. The only software that I like is one that I can easily understand and solves my problems. The amount of complexity I'm willing to tolerate is proportional to the size of the problem being solved.

Read More

This document was an attempt at understanding how best to port Node.js to Windows. The result of the port was the library libuv, which (among other things) provides a unified interface for asynchronous networking on the three big operating systems: Linux, OSX, and Windows.

Read More



from Hacker News https://tinyclouds.org

Master Foo and the Recruiter

Master Foo and the Recruiter

A technical recruiter, having discovered that that the ways of Unix hackers were strange to him, sought an audience with Master Foo to learn more about the Way. Master Foo met the recruiter in the HR offices of a large firm.

The recruiter said, I have observed that Unix hackers scowl or become annoyed when I ask them how many years of experience they have in a new programming language. Why is this so?

Master Foo stood, and began to pace across the office floor. The recruiter was puzzled, and asked What are you doing?

I am learning to walk, replied Master Foo.

I saw you walk through that door the recruiter exclaimed, and you are not stumbling over your own feet. Obviously you already know how to walk.

Yes, but this floor is new to me. replied Master Foo.

Upon hearing this, the recruiter was enlightened.



from Hacker News https://ift.tt/EPMYZvs

The Last Days of Sigmund Freud

Although he lived more than a century ago, Sigmund Freud abides. Despite the magazine features and nonfiction bestsellers that regularly proclaim him a charlatan, a reactionary, an intellectual dead end, or simply “dead,” we live in a world fundamentally shaped by his legacy. We accuse one another of “projecting”; we laugh—uncomfortably or with knowing glee—when someone else’s speech slips; we read novels and speculate about the author’s childhood, love life, and traumas; and we struggle not to think too hard about our more embarrassing dreams. If anything, the anxious protests (“I don’t believe in Freud, but …”), like the apparently inexhaustible need to ritually slay Freud the Bad Intellectual Patriarch in print, reflect his durability, and our anxieties, in a quintessentially Freudian way. Why would people feel so compelled to disavow him, after all, if Freud, like the repressed, didn’t always return?

Freud is dead, as more than a few have quipped, because Freud is everywhere. Or as W.H. Auden put it, in an obituary poem, “to us he is no more a person / now but a whole climate of opinion.” As a stand-in for a body of work (the English Standard Edition of his writings—which doesn’t include his letters—runs 24 volumes), as the Father of Psychoanalysis, and as a metonymy for a suite of still-disquieting claims about aggression, sexuality, and the unconscious dimensions of human behavior in general, “Freud” endures, overdetermined, signifying far more than just a name.



from Hacker News https://ift.tt/vbu2QDR