apotheon

> If I would propose new extension to C language, I would propose completely new language that can be optionally compiled into C and works side by side with old C code.

There are a few somewhat popular languages that fit that description already, and none of them are suitable replacements for C (as far as I've seen). That's not to say there couldn't be a suitable replacement -- just that nobody in a position to do something about it wants the suitable replacement enough for it to have emerged, apparently.

I suspect the first really suitable complete replacement for C would be something like what Checked C [1] tried to be, but a little more ambitious and willing to include wholly new (but perhaps backward-compatible) features (like some of those you've proposed) implemented in an interestingly new enough way to warrant a whole new compile-to-C implementation. Something like that could greatly improve the use cases where a true C replacement would be most appreciated, and still fit "naturally" into environments where C is already the implementation language of choice via a piecemeal replacement strategy where the first step is just using the new language's compiler as the project compiler front end's drop-in replacement (without having to make any changes to the code at all for this first step).

1: https://www.microsoft.com/en-us/research/project/checked-c/

> A lot of this is a direct result of feeling that one always needs to be on the bleeding edge, which is both unnecessary and also a recipe for wasting time on fads.

The problem with this is that everyone jumps on new fads so quickly that, if you don't, you're likely to endup with a bug-ridden, half-baked, vulnerability-riddled, unmaintained/abandoned, slowly collapsing, termite-infested framework as the basis of your entire SAAS business, or whatever it is you're trying to run on something that even the creators abandoned for the next fad.

> What happens to me, personally, is I start on some new project or company using a pretty recent stack at the time. Over the course of the next few years, that stack becomes "outdated" as new things are released. However, it also matures as its documentation improves and its community grows.

You have to be very, very lucky to accidentally end up with a "pretty recent stack" that will still be maintained in five years. On the other hand, the next part shows that you don't actually go with the 5+ year old "stood the test of time" tools:

> Eventually, after 2-5 years, I move on to another project, and just take that time to catch up on the latest.

Having to learn a whole new sub-ecosystem in as little as two years is exactly the kind of mind-destroying grind everyone's complaining about. I don't think anyone's just jumping on the newest thing that appears every six months; they're all just having to move to some new toolset every two to five years and burning out ten years into a career because otherwise they'll end up having to be the new maintainers of whatever tools they're using due to the fact nobody else is using them (and thus no one else is maintaining them) any longer.

We won't lose the right, period. It cannot be lost. Only the power to exercise it can be lost.

It's true that people are increasingly eager to infringe the right to express oneself freely by using government to curtail the power to exercise that right. It is true that exercising the right responsibly is important -- because failing to do so involves infringing other rights.

In short, there is good reason to differentiate between rights and powers, even though they may apply to the same things. The right is a matter of ethics, and any system of universal ethics doesn't change because of how people behave. The power to exercise a right is subject to social order, and if that power is curtailed the social order is, in that respect, unethical -- but how people behave may change the likelihood of the social order to change in that manner.

The statement that free speech is a right is, itself, an ethical statement. Claiming that ethics is arbitrary is basically saying that free speech is inviolable is an arbitrary claim that holds no weight. I'm constantly annoyed by the unfounded post-modernist claims of arbitrariness and subjectivity in ethics. The truth is that ethicality is a "Hard Problem" of philosophy (also an oft-devalued field, but one without which there would be no math or science).

I agree with both you and Voltaire, that freedom of speech is an important right that is "inviolable". That is, it posible to infringe that right, but doing so is wrong, and infringement of free expression is ethically subject to defense against the aggression represented by that infringement. In short, even if you don't know what the fuck you're talking about with your use of the word "ethics", and even if you contradict yourself by saying that free speech is a right (an ethical claim) and that ethics "are totally arbitrary", I fully agree with your basic assertion that free speech is a right, and anyone who wants to claim otherwise had better be able to provide a valid, deductive argument from apodictisms (or at least agreeable axioms) -- especially because I can provide such an argument in support of free speech -- before I'll give that claim the time of day.

Just to restate, in brief:

1. Yes, you're absolutely correct in your statement that free speech is a right, and it should be defended, and not deprecated by claims it's a "privilege". Yes, there is responsibility associated with that right, but that doesn't make the right into a "privilege".

2. Your statement that free speech is a right is an ethical claim, so maybe you should re-examine your dismissal of ethics. Thanks in advance for thinking it through.

The most powerful force for reform is talented and skilled people finding ways to make money that isn't subject to the games played in large bureaucracies. As they do other things, those other things outcompete the big bureuacracies and those bureaucracies either adapt (thus reforming) or wither away (thus getting replaced by something better).

The problem with this is that government is easily swayed by megacorp money. That money actually creates additional regulation, first by spooking people into thinking the megacorps need to be reined in then by using their influence to ensure the congresscritters hungering for megacorp attention create regulations that are more damaging to industry upstarts than to megacorps that currently dominate their industries. As a result, all these business regulations end up strengthening the hold of industry dominators over their industries, and they just find ways to keep their games going, serving goals wildly different from what most people imagine they really serve. As a result of those regulations being so crushingly bad for small industry upstarts and basically just a drop in the bucket for megacorps, the businesses that could have unseated the current kings -- with an influx of great talent leaving the megacorps -- end up being ground up by regulatory costs until they give up and get bought out by the megacorps, then destroyed or absorbed into efforts opposed to the companies' original high ideals.

Once in a while, someone manages to break through the competition glass ceiling, but usually it's at the cost of selling the soul of the company's original vision and becoming exactly what they originally meant to make obsolete.

Be fair to the original comment, which referenced people saying something about learning a language, and it making learning any others easy, not about learning many languages, and it making learning any others easier.

> If you learn to program in one language, it's easy to learn another.

That's often the case: many people who think that don't really use the strengths of the languages they use.

On the other hand, I've written a basic lambda calculus parser for fun and gone on to write (non-distributable, if I care about people) software using it, also for fun; I've written idiomatic, well-formed code in BASIC, C, Perl, Ruby, Scheme, Standard ML, and a wide range of other things; and I've basically added features by removing code. At some point, even if you know what you're doing, there comes a point where, kinda-sorta, it becomes easy to learn others.

It just takes a lot more than learning only one language to get to that point. Whether the person who first coined that comment about learning languages meant it as a simplification of a wise concept or was a blubdev who never really figured out the significant differences between programming languages is a question I'd like to see answered definitively, based on knowledge of the individual rather than guesses.

Regarding PHP, if you want it as a rite of passage it should come after writing software in better languages with better tools. PHP-first means bad-habits-first.

C imposes similarly rigorous proving grounds for developers, but without pushing new developers into bad habits that would come back to bite them later. If you want people to start with more requirements for hard thinking about how to not build a deathtrap, choose C instead.

As for the benefits of rendering server-side, they are legion, and most important among them is the fact that pushing everything to the client-side part of the system means not really knowing what your code will do in the wild, imposing whole new classes of frustration on users, and piles of other horrors. Yes, we could benefit from falling back on far more default-server-side technologies and using JavaScript only where it's needed, I think, for the sake of the users first and foremost.

JavaScript is great for some things. It's terrible for others, and all too often trying to use JavaScript for everything means coupling the wrong tools for many jobs together with the wrong place to run code, too. Even when I enjoy JavaScript work, the simple act of checking online documentation for the JavaScript tools I'm using ruins the whole experience for me as I realize how we're punishing our users when we don't think about how we're using JavaScript from a user's perspective.

I personally loathe JSX, not because of JavaScript, but because it's a wholly unnecessary different syntax for JavaScript that just forces me to deal with SGML/XML problems in a new and more painful way, because it has crept into the application logic as well.

Maybe "it's not Redux" is meant in the same way as "Toyota Camry isn't Car". It's a car, but you can have a car that isn't a Camry.

Otherwise, I'm really not sure what that "it's not Redux" comment means, either.

edit: Oh, crap, I just made a software/car analogy. I hate those.

I'll have to look at that the next time I need to build the kind of JavaScript app for which it's appropriate. I haven't done that kind of work in a couple years or so.

Thanks for the explanation.

Elsewhere in this discussion, I described my first Flux experience.

In that same job, the boss decided (after we switched to a pseudo-Flux, Frankenstein's monster of MVC component libs that slowed development to an excruciating crawl) to bring in a consultant to "help". He was the "crap out apparently-working code quickly" brand of "10x Programmer". Some basic functionality for new features got added in a hurry, over a couple weeks' time. The following couple weeks were dedicated to fixing everything he wrote.

Yes, I agree: "grown up" programmers think beyond what seems to work right now.

Sure, I use dirty hacks semi-regularly, but only when I'm first feeling out how something works. It doesn't last more than a couple hours, usually far less, because the point isn't to commit that code but to learn how to think about the problem so I can do it right, and a "done right" rewrite takes less time to get working than the initial dirty hack.

The "done right" rewrite also doesn't impose tremendous maintenance and continuing development costs over months to come the way the dirty hack would.

If the author means real programmers use dirty hacks to figure out what they're doing, then they make it right, that's fine. If not, that's not fine at all.

Before Redux was probably even an idea, when Flux was reasonably new, my boss at the time basically said this new Flux thing looked like what we needed for a project and told me to learn about what made Flux tick and start building the project on that pattern.

I dug around, I looked at Facebook's documentation and propaganda for the pattern, and I came to the conclusion that Facebook people didn't know how MVC worked and decided to invent their own thing as a replacement. Then, I started building something, and realized that Facebook's Flux dispatcher library was getting in the way.

I built my own from scratch, and suddenly I understood the elegance of the pattern. It was not at all what Facebook's marketing about it said. It was not an MVC replacement at all. It was something else entirely, and should never be treated as an MVC replacement. The explanations about how it solved problems with MVC were nonsense: it was just a different pattern, for wildly different use cases, and the MVC-replacement propaganda I read still made it seem like people at Facebook just didn't understand how to use MVC.

My dispatcher was lightweight and clean. It was one of the nicer bits of code I've written, and I'm still quite proud of it, years after leaving that job.

I was the principal dev on that project. After a couple of weeks of building a complete application with a deceptively simple architecture that did all the heavy lifting with ease, I took a day off.

It was one day. It was a Friday, which meant that for the people there a quarter of the day was taken up with meetings. Somehow, in the midst of this, disaster struck.

When I came back on Monday, I discovered that the boss and a co-worker had decided they would just replace all the guts of the application with a pile of libraries designed for MVC, but bend them into a Flux shape, kinda, sorta. The result was slower to build (q.v. JavaScript "build" crapola), slower to deploy, slower to test, and slower to operate. It was slower to debug, slower to extend, and generally miserable. It required fixing or changing something in the plumbing almost every time a feature had to get added. My work on a small, beautiful, efficient architecture was destroyed, and nothing we ever did with that application ever actually required any of what they did to it.

They told me I hadn't documented how to use the architecture in place well enough, so they had to rewrite it to get anything done, but the result was half-broken, and I had to finish what they started to be able to continue myself on Monday, and they never actually did anything with what they created that justified that claim.

A couple months later, I learned they hadn't actually looked at the documentation I wrote at all. They just decided that my bespoke implementation must be wrong because I didn't use existing tools. Well, shit, I didn't need existing tools. The whole dispatcher was something like twenty lines of code. The rest of the basic structure was in parts even smaller than that. The "rewrite" of the system was probably a thousand lines of library code (I'm guessing; I didn't count) and close to two hundred lines of junk around them to make things fit together, all so we could write a bunch of boilerplate for every single thing we wanted to do thereafter.

(Note that my references to all this code excludes the React tools themselves, installed directly from npm because yarn wasn't available yet.)

long story short:

I think I understand what you mean about a pattern, as opposed to a framework or toolset. Also, even if the origins of Flux (and, thus, ultimately of Redux) were in some Facebookers possibly grossly misunderstanding how to apply the MVC pattern, Flux as a pattern was an excellent approach to addressing some specific needs for application architecture.

In China, nobody's allowed to complain about mercantilist policies.

In the US, nobody noticed until the US government started employing stronger mercantilist policies, then started complaining about it at home because they don't like that their own government is employing such policies.

That's probably why.

It's worth noting that punitive tariffs, in the end, are taxes on businesses in your own country, because it just raises the price of US businesses doing business (and often gets passed on to consumers, when demand for the product is strong enough to pass the cost on to consumers; otherwise, businesses just suffer and have to start cutting costs in other areas, such as by laying off workers).

Mercantilist policies hurt the local economy as much as they hurt foreign economies. Every act escalating a trade war hurts both sides.

It would probably be more meaningful to cancel registration, and maybe even picket the place wearing that stuff (or at least post photos of wearing that gear on social media announcing they cancelled their registrations for the convention).

I worked for an employer that had a different PROCESS.md document in every project repository. At every retrospective, we'd evaluate the process for that project to determine whether it needed updating. It was awesome.

Eventually, things changed, but for a while there it was awesome. Things got done well, in reasonable amounts of time, with a lot of attention to quality work.

I think the beginning of the end was probably around the time when the company (a software development consultancy) started using fine-grained hourly measures of time pre-sold to clients. This started happening around the time investors in certain clients got more involved in trying to dictate company policy, and I'm pretty sure it was all part of an attempt by investors to ensure there were "better metrics" for evaluating their investments.

You can't measure something without it directly affecting the measured thing's state. In this case, it started having detrimental effects on almost everything. Previously happy and productive devs started burning out, mediocre devs became new management favorites, more bugs got into production, projects suffered under less and less reasonable goals (including at one point my task effectively being to solve one of the Hard Problems of software dev -- cache invalidation), and so on.

In the US, management culture seems to have a monomaniacal focus on metrics. (I'd say "simplistic metrics", but the way they use them guarantees they're always simplistic.) This is driven, in part, by bureaucratization, which is in turn driven by a bunch of other things (mostly stemming from politics, directly or indirectly) in our business culture. Many managers would complain that without metrics they can't evaluate team productivity, individual value to the organization, and other important stuff, and they're right. The solution is not to double down on those metrics obsessions, though; it's to replace those managers with managers who are capable of effective, qualitative evaluation, instead of the almost purely quantitative approach that holds the high ground.

The solution is to stop blaming the methodology for the failures of management, and just accept that bureaucracy breeds mediocrity. Corporations grow into bureaucracy, inevitably. Choose accordingly when evaluating potential employers. Keep this in mind when running a business.

Scrum always looked to me like pseudo-waterfall with an Agile™ coat of paint.

That assumes really good (measured against the norm) management. If your management is "normal" (or worse), giving management access to that just destroys the whole value of the scoring system. (Always remember that fifty percent is worse than the centerline, to say nothing of the still-within-a-standard-deviation "better" that isn't enough better to matter.)

Management has, culturally, become very metrics-oriented. This is the root of the problem under discussion here. See Goodhart's law for a brief statement of why this can't work.

Almost every time I bring this up somewhere, someone pops up to say that metrics are important, key to fair and impersonal management. Without it, everything would suck, and managers couldn't do anything. The problem with that thinking is two-fold:

1. It ignores the fact that, as soon as there's a metric that determines someone's rewards and punishments in a management system (whether it's governmental regulation, corporate middle-management, anarcho-communistic self-management, or anything else), the system of measurement will get gamed, and the most overtly "successful" will end up being the most cleverly sociopathic about it.

2. There is an alternative to strictly quantitative evaluation. The alternative is qualitative evaluation. This requires good judgement, intimate knowledge of the problem domain, good intentions, and the ability to consider context, among other things. Sadly, this is incompatible with bureaucracy, which means you need to either carve a bureaucracy-free zone out of the larger organization to manage a team well or stay out of medium-to-large corporations (and out of small businesses that ape the behaviors of large bureaucracies).

Managers who insist on doing everything quantitatively (and sometimes they're forced to do so by their managers) will not get good results. "Good" is qualitative, not quantitative. Equating "good" with metrics just gives you results that look "good" on paper, but really aren't good.

Probably the biggest benefit of a small organization is the ability to eschew managerial bureaucracy in practice.

It seems like the problem might be that people assume agile software development is, in and of itself, supposed to be a methodology. As I understand it, agile software development is meant to be a set of principles describing any methodology that serves those principles. As such, Extreme Programming is an agile methodology, intended to serve those principles when employed well, and Scrum is a pseudo-agile methodology that serves as the halfway point to which one might be able to drag management, but more often ends up being an excuse to measure developer productivity in story points.

There's value in enumerating important principles for consistently pursuing quality work product. That's why the Agile Manifesto has value. The manifesto is just a manifesto, a statement of intent and principle, and not a methodology in and of itself. One doesn't need a published, monetized methodology to engage in agile software development. One simply needs a methodology -- whether unique to one's project, or widely known -- that reinforces those principles to engage in agile software development.

The biggest problem with agile software development as a concept is that it, like any other elaboration of any principles of quality work, is that most people will fail to see the forest for the trees, will marry themselves to some well-marketed thing that pretends to be about principles, and will end up largely doing the same dumb crap they've always done.

> being self executing

Please elaborate.

Licenses that have legal compatibility problems with other licenses are problematic. In fact, that's one of the reasons copyleft licenses are problematic: legal incompatibility with many other licenses. In that respect, AL2 is as problematic as some copyleft licenses.

It also comes with some weird bookkeeping issues, like having to mark changed files in ambiguous circumstances, and requirements for how a file with a particular name (NOTICE) must legally be treated. These kinds of things can add to the burdens involved in building derived works, maintaining modified forks, or borrowing code.

> the OpenBSD developers were grognards who rejected it because they weren't interested in a web server that deviates from tradition

That doesn't seem like a fair description of what happened. I think it was more that the OpenBSD project didn't want Apache 2.x in the base system, and thought that if people wanted it they could get it from the package manager. There might also have been some licensing issues in the sense that they'd prefer no Apache license at all, but that was apparently secondary to the changes in Apache code that contributed to the decision.

Software licensing is not necessarily related to contract law. Many software licenses do not fully qualify as contracts, because they are just a grant subject to qualification, rather than an (assumed) agreement between parties about terms of exchange or something to that effect.

I'm not entirely sure how patent grant drags in contract law, though. It might be the fact that it implies reciprocal patent grants. You might have to ask a lawyer for the distinguishing issue here.

I think I know what you mean when you say "consensus" here, but that's not what "consensus" really means. Perhaps you want a word more like "majority".

Also X1 Carbon and T4XX series, for light/small laptop types, to say nothing of other X-series ThinkPads. I found a guy on Twitter recently, Roman Zolotarev, who runs a small job board and documents OpenBSD installation, configuration, and so on, for X1 Carbons in excruciating detail -- and apparently the detail is well beyond the needs of the typical install because X1 Carbons are evidently very well supported. My own T4XX is also very well-supported, as are those of other people I know personally who bought ThinkPads in that series for use with FreeBSD and OpenBSD after hearing about my positive experience.

I know some people consider lack of Bluetooth support a show-stopper, and maybe for some of them it actually is, and is actually worth the downsides of Bluetooth, but I think the practical effect is actually much smaller than one might think. While some needs are only filled by specific products, and those products only come with Bluetooth support for connectivity, most needs people imagine when bringing up lack of native Bluetooth support are easily supported (perhaps even better) with other connectivity options, and Bluetooth really does come with substantial downsides even on platforms that support it.

I, for one, have yet to encounter a "need" for Bluetooth that is not better filled by something other than system-native Bluetooth support, and am happy to avoid the negatives (e.g. security issues) by avoiding Bluetooth-only products. The one case in my life where the only option is Bluetooth is something that that is designed to connect to my Android smartphone, which is not (yet?) ready for OpenBSD anyway.

I see more non-ThinkPads than ThinkPads, in coffee shops, in small consultancies, in startups, and in corp teams, but I see more ThinkPads than any other single brand except Macs, and I only see that many Macs because of all the hipster fullstack devs around me on a day to day basis.

My spouse's employer just decided to kill its Dell contract for laptops and go with ThinkPads because Dell's warranty service is so limited/shoddy, and the reason cited is actually a common story. There are more Lenovo enterprise contracts than you think, and those that still use Dell aren't measuring all the costs or are getting very, very special deals.