knighthack

I beg to differ. Having dealt with the insanity of abbreviated variables/field names in cancer research, I can tell you that abbreviations often (1) do not immediately indicate what the actual underlying field is, and/or (2) will mislead, especially when variants are involved.

I don't find your second example exhausting to read at all - in fact I find it far _easier_ to read, especially to an astute reader (who is trying to make sense of a particular scientific literature).

No person will have any idea what `z = A*x-y` could mean 'in context', when it's so damn abstract of a reference.

Brevity in variable names is horrendous when cross-checking against papers. It is also a waste of time for scientists to reiterate what the legends/variable names mean, especially when their code could have used clear, unambiguous, verbose names instead.

I've always wondered: how is this different from packages like Dataset (https://dataset.readthedocs.io/en/latest/) or IDEs that offer ways of doing things like Jetbrains' Datagrip?

I've read your site, but could you offer a brief summary?

Generally, lawyers can only be managed by other lawyers. Exceptions apply in limited circumstances (e.g. see Australia).

As to your reference to the word 'legal counsel': a distinction must first be made.

The use of the word 'counsel' is often confused by non-lawyers. 'Counsel' is a specific term used to refer to lawyers appearing in court ('counsel of the courts', or 'court practitioners', or 'barristers').

Whereas 'legal counsel' is more specifically used in reference to in-house employees of companies, who handle regulatory compliance, general legal affairs of their companies, and so on. Such legal counsel may be legally trained/qualified, and may have had prior experience in legal practice. But they are not considered 'lawyers', in so far as they are not active/practising members of the bar at which they are practice, and in some instances are referred to as 'non-practising' lawyers. This is about the same distinction as e.g. a graduate of civil engineering, who has decided not to practice as an engineer and has gone on to some other field. Lawyering is however a very traditional profession, and the distinction between practising vs non-practising lawyers is very marked, and generally 'legal counsel' (as described above) are not treated as lawyers at all. It is not uncommon to find an in-house 'legal counsel' who has absolutely no idea what they're doing in practical/commercial reality, as they've never handled proper disputes or difficult contracts before except in non-contentious settings.

Thus in certain jurisdictions legal counsel are often prevented from performing any acts that must and can only properly be done by actual practising lawyers - e.g. 'legal counsel' cannot represent other companies/people/entities in courts (as they have no right of audience or locus to represent third parties), they cannot give legal advice as lawyers, etc. 'Legal counsel' as referred to in such context may be 'managed' by a CEO, but that's only because they are staff with legal knowledge, and not lawyers per se.

> Every skilled profession has people who are managed. Doctors, lawyers, they all have managers, and most of them interact with the public, who can override their expert opinions.

Speaking as a lawyer, and as a programmer: your statement is utter falsehood.

In many countries lawyers are not 'managed' by other lawyers. In fact, most non-lawyers have no say in how lawyers practice, and are there to assist only in clerical/administrative matters. In some jurisdictions, non-lawyers are even barred from taking any cut in the outcome of matters (e.g. possible champerty/barratry), and definitely cannot override expert opinions.

We even have a derogatory word for those who 'manage' lawyers: touts.

In a similar manner, the non-professionals who think they can 'project manage' professionals often over-evaluate their own ability at management; I've seen them make plans that have no basis in engineering reality or technical compliance/requirements especially when it comes to development timelines. Your defensive posture of non-programmers is very indicative of the kind of mentality that true professionals must guard against. Professionals must do a job well, and not just be told to rush out buggy, unsafe products by non-programmers the majority of whom cannot even program to save their lives.

> If you're trying to make the software perfect, you're likely doing something very wrong.

...Tell that to the programmers writing robust, highly-tested systems for aerospace/flight applications, which have to be designed to be as safe/'perfect' as that can be, since mistakes can not only cost millions, but be directly fatal to end users.

I can accept the proposition that the general commercial end goal of software development is the product, rather than a _perfect_ product.

But your claim that one's striving to achieve perfection in software is "very wrong" is a questionable statement, and ignorant of the 'engineering' aspect of software development.

I had no idea that/how the economic sustainability of a career in wizardry would be so closely founded upon sheep. And that wizardry would, amongst the practising masters, inevitably lead to sheep-rearing.

I also loved how it all tied back to adventurer plot lines, political machinations, quests, guilds, and the like.

What a wonderful read. Fascinating.

I don't see anything particularly broken with the keyboard. Much as the design of a knife is a convergent, functional end-design of a utility, I'd say that keyboards are the same.

As with knives you could make variants for specific purposes (fruit knife, chopping knife, serrated knives) but that doesn't mean that we have to 'redesign' knives altogether, or in the same way, keyboards.

Why does the author keep referring to the player as 'her'?

This neither seems in line with the traditional use of 'he/him' in English texts, or even the neutrality of 'he/him and or she/her'. It reads more like a stunted attempt to virtue signal. I'm quite confident that Civilization games skew to male players, rather than female.

What a great way to alienate readers. More so when gender was not a central feature of the article at all.

Why is this flagged? This should not be flagged.

...And then we'll have Squarespace.

> You can throw 30 software engineers and have a system and increase velocity that way.

This makes absolutely no sense at all. You obviously have not read _The Mythical Man-Month_, and judging by what you've written I completely doubt the entirety of what you've said.

Speed is one thing. The long-term maintainability and usability of a system is another thing altogether. I have serious doubts about this 'no code' movement.

> They go on for several years with several people, usually women, making the sacrifice and doing what needs to be done.

While I agree with most of what's said above, the proposition about "usually women, making the sacrifice" is dubious at best, if not untrue.

In any society or commune few will lead - the rest will be workers or followers. These will be both men and women, and they will both suffer from necessary sacrifices. Women are not a special class of people in those societies, and to claim that they suffer more prejudice is the usual sort of feminist-speak that has nothing to do with the reality of such communes.

I love how poetic this sounds.

Women are not 'being segregated' (which is a strawman argument on your part).

Men are refusing to giving advice, because there is past history of women falsely accusing them of being sexist when they do give it. Your claim purporting that it never happens - i.e. 'before having any occasion' - skews the time-perspective. And is against the odds that male investors have faced, which is why they now clam up.

This is nothing to do with 'segregation' - that's a silly interpretation on your part. Investors are wising up to hold their tongue, than to let aspersions be (falsely) cast upon them otherwise.

1. 'Sexism' should be limited to acts of discrimination that undermine another sex.

2. Advice (which is essentially a gift of knowledge/experience) is not something you are entitled to by virtue of your sex.

3. A man cannot be said to be 'sexist' when he chooses not to give advice that could potentially incriminate him, especially falsely. If a person (whether a man or a woman) chooses to keep silent, and especially where no fraudulent aspect is involved, that is part and parcel of doing business. You are not entitled to call a person 'sexist' just because they do not want to give advice to you.

4. There are virtually no consequences to the woman who accuses. Yet in comparison, the long-lasting consequences of an investor being falsely accused in public far outweigh any advantages to the contrary. This is enough to make any man clam up, and is a legitimate cause to withhold advice.

5. More importantly, in a commercial setting, no one is obliged to give you an advantage just because you're a woman. If you expect such an advantage/benefit because of your gender, then you are being sexist. A woman who wants to do business should not posit that a man is actively being 'sexist' if he chooses not to help her. That makes no sense.

> There's too much emphasis on closing questions that are duplicates (when in fact they are not)

This is a great point. And it also relates to abuse of power.

Recently I raised a question without precedent on Stack Overflow. A person had given a detailed answer, which pointed to issues not available in documentation. His answer was in fact an expanded analysis of the overall language specs - without it, I had no idea how to debug my code.

One megalomaniacal moderator marked my question as 'duplicate', and then pointed to another question -- where he claimed to have answered the question 'definitively' (he had not) and wanted me to upvote his answer.

There was no way for me to challenge his 'duplicate' mark, which is a real loss for anyone else encountering the same issue as I did.

"Customer's choice" is a strange word to use for people who are not purchasing anything.

The loud, insane voices on Twitter and other social media demanding cancellations are rarely purchasers of products/speeches/people they attempt to cancel.

Ideological mobs are not customers, they are censors.

> If a lot of people use a shovel as a hammer, the people making shovels should start considering that use case. The spade manufacturers already did so they could take inspiration.

I completely disagree.

Your example of soldiers and their multi-tool use falsely conflates utility with necessity.

First, civilians generally don't have access to assault rifles (to even consider using it as a bottle opener) - i.e. soldiers are an edge case. Secondly, civilians who have direct access to bottle openers don't even need assault rifles - i.e. most people don't need edge-case solutions.

In the real world, when people want a hammer, they buy a hammer. They don't use shovels for hammering, unless they're forced to use one, or have no other option.

In the programming world all popular programming languages are virtually free. Programmers can choose and select between them. Modifying a language just so that it can do every specific thing (rather than the few things it is good at, or which its ecosystem is good at) is architecturally poor language design. And an excellent way to mess up the language - e.g. see PHP.

A tool should not need to accommodate to the whims and needs of every user. To use your analogy, if the shovel users have easy access to hammers, then they can grab the hammers when they need it, not force shovels into hammers.

To do otherwise is a stupid choice on the part of users, and is in no way a weakness of the design/utility of the language/tool itself.

The Methuselahs of Altered Carbon soon come alive.

... Or continue their extended living. (At least until they get a chance to swap sleeves.)

I have no idea why you would want to declare an x in the loop, and then use it outside the loop. There are better ways of doing things.

The fact that you can do such a thing in JavaScript is exactly why JavaScript is such a mess of a language with its globally-declared and hoisted variables.

That sort of practice has never made sense, and is not a language design that Python should follow.

I agree with you that Python now features some redundancy. Yet I do not agree with you that there is 'complexity', going by your examples.

Notwithstanding the various ways of doing the same thing (which sometimes goes against the zen of Python), as of Python 3.6 there's been a constant trend towards f-strings above all else (barring maintenance and legacy code), and generally beginners have no need for anything beyond f-strings. If they'd like to go into the old string formatting techniques, they're welcome to, but they're not that complex.

I don't understand how type annotations constitute a 'compromised design' - they've worked quite elegantly with Python's dynamic typing, they greatly assist linters and IDEs when you turn them off, and they can be disregarded when you don't need them, which is a far cry from the enforced typing of other languages.

And I certainly do not agree that there is a need for a "next Python". Python does a lot of things very well - it's design is clear, the design patterns are methodical, the language is well-governed, the central packaging system is reliable (and not like the insane NPM and dependencies of JavaScript), there is a distinct idiom/style consistency amongst Pythonistas, a and a large gathering of minds behind the language. Further, Python reads very well, and can be even pseudocode without being pseudocode, which makes it very much suited for beginners who can stray as far as they want to into the language when they feel ready for it.

Python is a great language for beginners, so I have no idea what you're talking about.

If your attitude is that you "can't be bothered" to use a dependency when there is no proper documentation, you probably aren't working on difficult problems, or you're not really doing enough serious programming work where SO becomes the only resource available to solve a hard engineering problem.

Completely disagree, and you're wrong.

Depending on the area you're looking into:

1. Many Stack Overflow answers do not exist in documentation at all.

2. Some answers are especially valuable because they touch issues in actual production (which are not foreseeable by documentation).

3. Answers (chronologically given) help ongoing document changes in APIs, which many documentation don't do or make it very difficult to do.

Take Python's Tkinter for instance - a lot of answers in in Stack Overflow supplement many things not covered by the official documentation. You'd either have to look at Tcl's documentation (but have no idea where to look, or how to read it), or figure out the source code yourself which will be confusing since the official documentation does not actually document every part of the library that it's sourced/ported from even though they exist for use.

4. SO answers often point you in the right direction, or to third party explanations and sources, and often compare between different semantic versions. (E.g. answers for D3 in JS often compare changes between APIs in the different versions 4, 5 and 6.) While official documentation sometimes chronicle their API changes, comparative usages/change in idiomatic usages are not always elucidated and it is in Stack Overflow that many of those are found.

Your attacks on him shows how biased you are - for instance, you called or used the word 'crazy/crazy' 5 times, without mentioning a single actual concrete instance of what makes his assertions crazy.

There are various videos of him online engaging in straightforward, evidence-based debates with others, and where some of the things he's said has been subsequently proven by more recent discoveries.

Your opinion of him seems entirely prejudiced. You have no substance in your description of him at all.

I jumped on Sublime Merge so fast. No regrets, it's such a fantastic and speedy Git client.

If they did email, I'm 100% buying it the day of its release. Even before, if possible.

> ...it takes a hacker to organize entire groups of people. These folks are hackers in every sense.

I think we may have a very different definition of the word "hacker". Yours is very likely incorrect.

> You will see some well grounded, expert opinions here down-voted into oblivion simply because they clash with the mental picture of a number of HN users.

I don't agree. I read HN constantly.

As far as I see, the areas where downvotes tend to occur are where they skew to opinion, or have some tidings to politics. In other areas, HN comments are generally high quality, and have a high signal-to-noise ratio.

I wouldn't also correlate expert opinions being downvoted as just because it would "clash with the mental picture of a number of HN users". That's a false correlation.

For the accusations that the NYT makes, are the women and black employees doing exactly the same job as the others, or are they in different/easier/less technical roles?

I don't have access to the article, and I'd need to know that before I can make any judgment call.

I like to think of Git in analogy with cars.

Everyday folks aren't expected to know how their car works, much less tinker with it. Not the enthusiasts, who will find a way to grok the full specs of cars and tinker even if you tell them not to.

Normal everyday folks should be content leaving the gory details to their mechanics. I'd wager it to be the same with Git, as an everyday tool of software engineers, rather than that of layperson. This is not gatekeeping; it's a fact that Git is not your usual point-and-click stuff and UIs that attempt to do so can only simplify it so much. Real enthusiasts can always learn how to use Git if they want to, there's no need to make it simpler or easier for the 'casuals'.

The fact that people even have trouble with self-descriptive software like Microsoft Word - which is probably, in terms of UI, one of the easiest, most accessible UIs ever with years of research and iteration - speaks to the fact that not everyone will 'get' Git, nor sho uld there be a need to please or try to reach to everyone with a software that has as many complicated features as it does for the multitude of engineering problems it tries to solve.

Hasn't there been many attempts of that sort over the years? I recall some similar efforts being made to simplify Git for use with writers, etc.