annywhey

Most of the effort in making a language a production language is on the tools and libraries end of things, and LSP is sort of the tip of the iceberg in terms of getting into that stuff. Before that, you probably want to have features like "good error messages" or "working string and math libraries".

For a long period in the past 15-odd years, new "Web" languages were getting plenty of adoption because the state of the tooling for that segment remained barebones everywhere, with a lot of functionality already in SQL or JS and anything in between being glue, and so competition on language features and syntax took precedent. It's probably in a consolidation phase now - things are getting more exciting in the lower layers of the stack instead.

The silver lining of this cloud is that it acts as a selection force on institutions, too: If people are harder to pacify, institutions have to step up their game and deliver, or failing that, market themselves better. And that parallels a broad trend that's been in place since antiquity: building sustainable institutions instead of succumbing to warlords and despots. Legal codes, religious orders, and so forth have built up a vast underlying structure to face the ordinary challenges of humanity at its worst. There's nothing to suggest that that trend ends because we have some new gadgets.

But it takes place as a reaction, a series of rapid cultural changes. I would say that we had such a shift take place post-2008: besides the economy, the smartphone era took off and everyone since then has contended with a new status quo of limited privacy, temporary status, broad-not-deep social networks, and a constant background noise of gossip and scandal. Have we gotten better at navigating this world since 2008? Absolutely, I would say. In the first four-to-five years we had a whole bunch of theories about a massively connected world get tested in reality, culminating in stories such as Anonymous, Wikileaks, Arab Spring, Occupy, Black Lives Matter, and Gamergate. The years since then have seen various reactions to those stories play out as one major figure after another gets embroiled in scandal.

Even if this is fostered by state actors, the overall effect is one of "boiling down" institutions to their basic premise, where they are easier to challenge, as the arrangements that locked them in before get severed.

And I think the public recognizes that to some degree - the low empathy comes in combination with a renewed interest in a private approach to philosophy, rather than a collective one - a sense that existing institutions fundamentally don't have the right answers and something has to be done. We're merely acting in accordance with the times.

1. Philosophers derive measures of truth from theories of truth. To accept the measure you have to accept the theory. If you question all the theories you simply arrive at well-trodden metaphysical debates within philosophy.

2. Argument over progress in philosophy is a debate borne of logical positivism, and it valorizes the goal of accumulating one ever-larger shared pool of knowledge as the only one that matters. But why does it matter?

Throughout history philosophers have often been more interested in personal development than grand collaboration. Empiricism just happens to have this property of creating tangible objects that others may study, which makes it apparently dominant in a world dominated by "whiz-bang" science - we're always looking at the next big thing. But merely knowing physical properties of the world does nothing to inform us of how to use them in a productive manner. That's where philosophy will perpetually re-enter as a way to add holistic breadth: the principles are often old, but they need a new adaptation to the circumstances brought about by technical changes.

And that also means that philosophers tend to be unpopular. If their nature is always to question how we're doing things, the natural consequence is that they are outcast for "rocking the boat". This is why it is important to draw some distinction between philosophy, the contemporary academic job title, and philosophy when it is practiced by ordinary people every day. The former is a strange outgrowth of the post-Enlightenment enterprise, the latter is something anyone can claim. Defining oneself as "artist", "maker", "entrepreneur" - these ideas encode philosophical purpose.

The thing I've seen with estimation practice last I researched it is, it works best if you can calibrate. That's something an established shop can do by extrapolating from their previous work, but it is also often as simple as "This other team took 7 months to do a similar thing. Therefore we will also take 7 months." An estimate like that is usually only wrong by days-to-weeks, since it encompasses all phases, eliminating the fudge-factor, unknown-unknowns and wishful-thinking aspects.

When it takes much longer, it's almost always due to design issues or political issues that create design issues. When the design is well-understood(and prototyping is hugely important to finishing design ASAP) the implementation goes smoothly. When stakeholders take turns stirring the pot to "make their mark", it goes haywire very quickly.

I believe most of the FUD is, in fact, coming from those rivals.

Brave proposes cutting out a bunch of middlemen through the token market and making the browser something like an anticheat system: opt in and it does its best to serve quality ads while preventing click fraud.

There are a lot of details in the execution that matter to make this competitive, but the basic idea resolves many of the current conflicts of interest that make adtech a miserable market.

Here, watch this:

https://youtu.be/ffryiLmQb1U

This is Fortnite build battling. BR as a whole just refers to a game ruleset that forces and encourages a last-man-standing situation. That part has been done before there was a video game. But the details of what's being communicated are different. They're different even between Rust and PUBG, despite both of them being military styled. Fortnite is in a class of its own since it's cartoonish and the building and mobility options present a lot of unique options. Even comparisons to Minecraft don't fit since the build system is different.

Performing jadedness about the games being "done before" is basically like saying new movies are just collections of old cliches. Even when they are, they end up saying something different.

I think this one is mostly reflective of the risk/reward payoffs of aggressive and unusual play in any particular game. Play to win means - force the confrontation, take gambles, push your way into a surprise advantage. Play to not lose means - lean on your techniques, stay in control of the situation, build an advantage gradually.

And for most games, most of the time, playing to not lose is a more reliable way to win, because it is more consistently rewarding to practice, even though it can result in a boring risk-assessed playstyle. Playing to win is an emotionally-driven way to do things and good technique will usually counter it, but every once in a while, late in a match, the mask slips and there's an opportunity to make a play on an overwhelmed opponent.

Although I'm not intimate with the BBC hardware this kind of thing doesn't necessarily indicate a hardware mode switch - the renderer could use double width pixels in the HUD simply to lower draw times(simpler rasterization loop) and conserve memory.

AFAIK really complex scanline tricks mostly appeared on the Atari and Amiga platforms first because they exposed explicit programmability that made it simple to define exactly what you wanted the memory layout to map to. Other hardware could do similar things, but needed to code a cycle-exact loop - a feat that was certainly known in the 80's, but also relied on a good understanding of the timings of all the hardware.

What you are looking for here is primarily a feedback mechanism issue. This is something that is a hard problem, since good, useful feedback is never quite as simple as just asking someone. Employees are looking for it. Managers are looking for it. Executives are looking for it.

With respect to work time and workload there's always an element of presentism - if "enough" surfaced activity happens over the course of each week and the work is not obviously deficient, then most managers won't ask questions. And you already know that much, since you had many years of school to get that idea in your head. And when it's on-site, it's simple to get to that level - if you're in the office, you're at work, even if it isn't time-on-task.

But there is always going to be a level beyond that, of taking on tasks that are a good combination of "builds up a career" and "builds up the company" - stuff where you can act more independently, and likewise fail independently. You can easily fall into work that does neither or only one of those things, or convince yourself into workaholic behavior and sacrifice everything else. Nobody can offer a clear bright line of "this is the best possible course of action". But there is a "better" out there somewhere!

So if you can measure yourself by whether you did something of both career and company and other life things each day, then you already have a more balanced self-measurement than "quantities of issues" or "lines of code" or "hours in seat".

I literally sat down last spring and focused on this problem with a bit of brainstorming and philosophizing.

My goal was to figure out what parts of me added up to being a coherent whole as a person, at least w/r to career. (With other aspects, too, but mostly "what should I spend my time on, really?")

And this kind of thing is never wholly about skills, interests and talent - they are starting places, but personality and natural tendencies were a much bigger factor in my judgment.

And it helped. I found some insights about what I could/wanted to do, my personal principles, and how I might put these things together in the form of a career - like, ah, yes, I like teaching things and advising, but no, I don't want to do it in the form of formal education. And so on, probing different aspects of the process and teasing out what was most and least painful and working towards "mostly painless so that I can really focus on perfecting it".

Then over the summer I tested out some of these ambitions and found where I was and wasn't limited - like, if I wanted to teach, could I do it by streaming? After working through the logistics I realized that I had something more like lectures in mind, which would communicate better as video. Then looked into video editing and polishing up my voice work and realized that I needed more than one format to do everything I wanted. So I decided that I would have a "multimedia blog" with writing coming first, but lots of images and supplementary content.

So I started on that, and have posted a few articles and shared them(mostly with friends). I don't post at a high rate but it is proving to be a good way of directing my writing energy away from comments like this one(hmm...)

Since the season has changed, I'm probably due to try evaluating myself again and looking for another way to inch forward and focus on what topics and techniques I'm meshing well with.

It's a big step, both assets and codepath have to change to make full use of it. It's possible to change some effects to work in a forwards-compatible way, but this isn't a free lunch. As an traditional GPU, the RTX is only slightly better than the existing 10-series.

Since AMD continues to hold console developers with their semi-custom chips, this is only likely to impact a limited set of titles in the near future.

I think the devil is in the details of this one.

The shop coder may have never heard of a formal method and thinks it is something that must be "slow" or "too complicated", but they inevitably come crashing into tools and techniques that were informed by formal methods. In the 80's it was hard to get your hands on a C compiler. In the 90's, everyone still thought that OOP was going to change everything. By the 00's we finally saw widespread adoption of garbage collected languages. And more recently we've had better package management and efforts to rework lower level coding.

We've never left behind cargo-culting, given the growth in the number of programmers, but the strides are there, always hovering a few steps behind the code that is considered the "production code". The production code is seen as far too fast moving to be considered for "formal methods", yet it still ends up using "design patterns", echoing Hoare's notes about defensive coding techniques. We don't "prove" our C++ code is good, but we run a "static analysis" tool or a "fuzzer" on it.

Perfect, the enemy of good enough.

Honestly, direct pay for attendance would be a great incentive for the poorest demographics. A few dollars can be make-or-break at the margin and even greedy parents that misuse the funds would end up wanting to get the kid showing up and not getting in fights - the bare minimum for a school day to go by undisturbed.

We've had runs spanning a week plus this season where the AQI never gets under 50...SF is not really safe when it's wildfire smoke from the north because it ends up recirculating.

In fact we're in that kind of scenario right this minute.

This looks like it takes influences variously from Haxe, Rust, and Haskell, which are all great in my book. But the first thing that crossed my mind was, "could it compile to other languages besides C?"

The reason being that I think the way to really move up the baseline is to take another page from Haxe and aim for cross-compatibility between different systems languages, becoming a "language that unites them all". So that could mean relatively new and hip ones like Rust, D or Zig, or older ones like Pascal(Delphi), Fortran, Cobol...

And those are niches relative to C, but they're nearly unserved niches AFAIK.

Another "too many programming languages" comment. God! I have no idea - what's happening to the world? Are people not skilled enough to evaluate new languages?

There are new type systems and static checks, integrated build systems and package managers, backwards-compatibility features, debugging tools...

What is the primary reason to complain about new programming languages?

Lua is emerging as a "everything compiles to it" source target - you can have Lisp style syntax, you can have static types and JS style syntax with Haxe - it's designed to piggyback off C codebases well - and on its own, it makes a decent Lisp too. So there are a lot of potential benefits to building a stack centered around Lua.

I took the approach of bolting a second compiler on top of Hugo(a custom Python script) to get the extra things I wanted in Hugo.

It still took a while, but I did get to leverage the parts of Hugo that already work well.

I don't think there's much in the way of winning either way, since now I have a Build Process.

The folding scooters(which do come in e-form) strike a good balance between transportation and transportable: You can take them on transit, and carry them inside. Folding and unfolding - on well designed examples, with a bit of practice - can be accomplished in seconds. Walking a bike really doesn't compare. I see non-folding e-scooters as a category restricted to "stunt users" (who need the extra structural integrity) and "rental companies" - who, as we know, are going to encourage leaving them on the sidewalk.

Electric skateboards and roller skates can boast being even lighter, but most folks will gravitate away from them as a commute device since maintaining control is much more difficult.

In short: sum types.

If behavior is controlled from the top level(as is suggested by the cases where the main loop grows to 10's of thousands of lines) your behavior branching also appears there. The data is still driving everything, but if the data model is inherently complex it bubbles up to the surface. And you can use sum types(whether provided by the language or in less structured "match a magic constant" type deals) to check your coverage. During prototyping, you can lean on dynamic types instead and get a similar outcome with more fluidity in model changes and lower debuggability.

That feels instinctually wrong if you're dosed up on polymorphism and expect a kind of "ultimate abstraction" where any of the enemy types could be totally different and you just write to an interface, but - the thing you want, and that is the practical situation in most gameplay logic, is not "wholly bespoke behavior per type of enemy, hide everything behind a facade and either duplicate code or use a complex indirection to reuse it where it's the same" but "98% of the behavior is on the same code path and reads top to bottom, except for the one or two important pieces of business logic that isn't". The latter is both more compact in total SLOC and by being surgically precise, gives more visibility into what the code does at the moment you try to debug or extend it - which is what we're really aiming for.

And if you have really complex behaviors, you do end up with Turing-complete script logic embedded in the data, just naturally growing out of data model extension to cover FSM logic. That indicates that you are never really "giving up power" at any point in this process - you're just gradually moving things up the abstraction chain in a controlled fashion, until your main loop is really an interpreter that deals with "opcodes" and "commands" more than it does any particular algorithm or data layout.

And then when you get there, you can go, "well, now that I have a virtual machine, let's optimize around that..." and then you start writing some tech to lower the overhead of the interpreter...and it just goes from there. You never have to jump off that train, but you can usually ship something well before you get it even to the Turing-complete level of programmability, too.

In phases, this is roughly how I learned:

1. Cute hacks like using the eval function in Python and rewriting the string before passing it in. This is basically metaprogramming by macro-processing and a good stepping stone to thinking about what a programming language really accomplishes.

2. Writing various Forth-like and Lisp-like languages. This let me explore a working system without spending too much time on parsing - I could try interpreting the AST directly or compiling it to an intermediate language.

3. Gradually learned that a lot of the features and technologies in general purpose programming languages aren't things I want to care about(how to implement arithmetic, perform variable assignment, perform typechecking etc.). Focused on data languages like JSON and small supplemental languages for e.g. scheduling concurrency.

4. Found a useful model for prototyping semantics before adding a syntax, by envisioning the whole language in the form of a state machine that builds expressions one API call at a time, then compiles/executes the result with a "commit" call or similar. This is a practical technique for many domain specific problems, and makes the necessary syntax emerge naturally.

A lot of what goes into making a useful production language isn't really on the theoretical side, but on finish-and-polish stuff: fast builds, helpful docs and error messages, well-rounded libraries, debugging tools, ease of deployment and so on. Learning this through the process of writing small PLs helped change how I viewed language selection to be more like picking any other application, vs a point of religion: choosing something with approximately the right features and tooling so that the groundwork is easy, and then magnifying that leverage by adding a bit of custom syntax, static checking, code generation, what-have-you on top. Turning the tech into an airtight abstraction generalized across a whole language is a ton of work, but getting 80% of it in for the specific app takes a fraction of the time in comparison.

Although browbeating does have a lot of value, especially when there are already some bounds on what the problem is and how it can be solved with your product, you will hit a point where your customers say, "I don't know" and mean it. And that's when you have to start to treat feedback more holistically and use the customer as a final validation of an internal model. [1]

[1] http://ludamix.com/dive/performance/

The pattern of "stay silent and look dubious to make the candidate feel dumb" is a really common interview hazing strategy in my experience.

I think the next time I see it, I'm just going to question whether this is how they behave in their job too, even if it means ending the interview right there.

It's associated with an older style of "white tablecloth" dining that has faded away since the midcentury. If you go to the right kind of small-town diner you'll see liver and onions on the menu.

Although I wouldn't argue against unit testing(I use it too), I'm a little more hesitant about incentivizing test quantity. Many times when this comes up having been tried it gets attached to a anecdote that goes: "And so we wrote very bad tests and atomized the codebase into unmaintainable pasta code that could be trivially tested to make the number go up."

Which leads me to a hypothesis that there's some other quantifiable out there that would work better than unit test coverage: a "diversity test" metric. The software artifacts produced by writing code and after a build are not "the software" in the sense of the whole project. Documentation, support, and so on are also "the software." Logging and profiling tools enable debugging methods other than "stare at the code very intensely". If you start from a holistic standpoint and assume quality requires multiple angles of inspection then your choices of technique broaden substantially.

If you changed a mandate of "must test all code" to a mandate of "must either test, log, profile, or document all code" you would add leeway for the corners that are test-averse to be documented or logged instead, and vice-versa. The combination gives you a palette of feedback: if it's hard to do any of those things, you have bad code. Ideally you can get all of it, but that is unlikely to be the norm for most organizations most of the time. But more bugs will be caught by this web of feedback than if you mandate any one of those methods alone.

In my early 30's now and I often muse on how poorly prepared I actually was, coming right out of school.

Basically, society molds the young to fit an image. Then those young people all compete over that image, hopefully start to realize this is a terrible idea and there are better things, and start looking for a niche to exit to. And then perhaps 20 years later they've learned enough to successfully hit that niche!

In agreement. IMHO generics basically have one place where they work well: abstract containers. Your queues, linked lists, what-have-you can benefit.

But most other data structures? Nope. Too much of the algorithm depends on the primitive type.

And that makes generics a nice boon for computer scientists and certain library authors, but of middling benefit for day-to-day coding. If the container works, you can copy-paste-modify your way to the types you want, or automate the same in a macro or code generator. It's not beautiful but it doesn't have to be.

I actually had a spell the other day where I looked at alternatives to SQL, which mostly produced Tutorial D variants. And there are some nifty ones, there are query languages that will compile to specific SQL dialects so that you can keep using a familiar database engine. They just aren't used much.

Somehow, we've come to accept a Babel of general purpose programming languages(albeit mostly centered around Algol variants) but the same really hasn't happened with databases. Either it is a form of SQL or it is pooh-poohed as weird and bad.

And I don't think that that's because SQL got everything right and we should worship vintage language design - I think it's just a case of specialized demand and barriers to entry making the database market move slower. A lot of shops fail even at using basic features of SQL, so maybe it's asking too much to get beyond a passing familiarity with relational concepts and one syntax to interact with them.

There's a lot to be said for a "keep moving" approach to project work. I'm a worrier with a perfectionist streak, but I do better with multiple projects because I ruminate less on each one: If I cycle through them over the course of a day, I forget what I was worried about and just focus on accomplishing something I had put in the to-do, which levels things out and lets me do more work at less than 100% when it's called for. When I do work at 100% it means I'm destroying myself trying to calculate every possible option. The 100% work only needs to come out some of the time.

The answer is pretty obvious to me: all of the above are potentially sensitive. They aren't professional. They suggest unsavory intent. They can harm people who have experienced those concepts within their personal lives. You wouldn't want to use them when reporting to shareholders. But the degree of consequence is more contextual.

That one or the other is being called out now, specifically, is a matter of political fashion. Sexualized language, racist language, those get airtime because there's groundwork there to carry those stories widely. In the past, it was religious oaths and the like that were transgressive. On the other hand, language around mental illness and disability, for example, has less of a support system now. You will easily get away with saying that an idea is "fucking retarded". I know I've said similar things many a time and I have some regrets about it.

And that's a thing that the culture negotiates one conversation at a time. It might not matter in any one instance, and if you look at it in more weaponized terms of "oh, I need to call out that guy for using a bad word" it gets embittered and negative really quickly, but any sensationalization ultimately hinders intended use of the term. When you go looking for strong language of this sort, you end up in a space where you're going to borrow the imagery and insert it in situations that are just flat out not the same, and make people think: "What? Is that normal? Should I play along?"

On an individual basis what's most important is just communicating clearly to make language and conversation pleasant and not going for "colorful" just because you can.