ericelliott

This example will probably include detailed justifications. I liked the response, but if you just want rank and name, just say so in natural language.

I might do something like this in SudoLang:

list top 10 hip hop artists from the year 2014 |> sortBy(chart performance, descending)

Unit tests. SudoLang has a port of the Riteway unit testing framework, and programs can be stepped through in debug mode to show intermediate processes. Such debugging sessions could be used to fine train future models on algorithmic thinking.

This stuff is experimental and not 100% yet, but it does mostly work today, just days after SudoLang was specified. And you don't even need to paste the spec: the whole language is inferable by GPT-4.

You're just seeing people's knee jerk reaction to new ideas here.

What you don't see in these comments is that SudoLang went viral overnight. Tens of thousands of people heard about it and the blog post comments are overwhelmingly positive.

As a programming assistant, SudoLang is already saving me time producing traditional software in JavaScript, but the real unlock is defining unambiguous requirements for complex programs that run directly on the LLM: Chatbots or productivity tools that require NLU - programs with enough complexity that a freeform natural language prompt just doesn't express easily (see the examples folder).

SudoLang meaningfully extends our ability to clearly communicate complex ideas with LLMs, and it's a language that LLMs and programmers and beginners learning to code all intuitively understand.

It opens up a middle ground between natural language and formally structured language and that does in fact open up new possibilities.

The people comparing the syntax of one-liners are missing the point. If you can clearly communicate the idea in natural language, just do that. In fact, that recommendation is right inside the style guide. But you can also do things like declaratively communicate the structure of objects for talking with REST APIs, clearly specify behaviors and requirements, etc.. things that need to be clearly specified and not just invented/improvised/hallucinated by the LLM.

SudoLang's infinitely inferable standard function library with modifiers can be easily and declaratively chained to radically simplify chain-of-thought reasoning: a process that helps LLMs think about tasks more carefully and produce better results.

It's OK that lots of people don't see the value, yet. It often takes time to warm up to new ideas. When I first started using GPT-3 in 2020 nobody believed me when I said it could code. Today, coders who employ AI tools are 2x faster than those who don't (this stat comes from a study on GitHub copilot comparing 95 devs working on the same task).

Thanks for your encouraging remarks.

It's packed with data and cited sources, and it does not rely only on download stats as your comment implies.

I've built multiple Angular apps, too. All of them imported at least a dozen other libraries as well.

There are a few first principles from which we can design code.

The first is: Requirements change.

For many reasons. User needs change. Business processes change. Technology evolves.

If you're going to keep up, you must design code that is easy to change.

Code that is easy to change tends to be code that can work with lots of different code.

Code that can work with lots of different code tends to lean towards the general end of the spectrum, rather than being too specific.

Designing code that is modular does not mean that you need to over-engineer, and it doesn't even mean that it needs to be used more than once.

It should mean that the code has locality: The ability to understand the full effect of the code without also understanding the full context of the code around it or the full history and future life of every external variable it uses.

It may sound to new developers like I'm talking about something complicated, but it's the opposite:

Code that can be easily adapted to future use-cases tends to be more simple. It tends to know the least about it's environment. It tends to do only one thing, but do it so well as to be perhaps the optimal solution.

What follows from the first principle is perhaps the most important principle in software development. Remember this and you'll find yourself needing to do a small fraction of the work you once did to produce the same value:

A small change in requirements should lead to only a small change in implementation.

The TypeScript engine in VS Code does the same type inference for standard JS, and automatically downloads d.ts typings for libraries you use to enhance it.

Yeah. I've done that, too, and TypeScript certainly can catch up to 20% of the public bugs on GitHub. But I find that after all the other measures I use (particularly TDD and code review), there just aren't many type-related bugs left to catch (very near zero).

Mileage can and does vary. Airbnb noted a significant benefit from TypeScript. I suspect you could reproduce Airbnb's results if you had a good design review process and poor test coverage.

Lots of people share your views. A lot of people love using TypeScript because it feels satisfying and the intellisense you get with it is really nice. I'm not saying anybody is wrong for feeling that way -- only that on the projects we used it for, ROI was not good.

TypeScript annotations are also optional.

In my experience, TypeScript does not reduce the number of tests you need to write.

This is all true. It's also true of JSDoc (using the TypeScript engine or TernJS with standard JS) - but JSDoc also includes space for human readable descriptions which can be used to auto-generate thorough API documentation. And JSDoc has the advantage of working inline with standard JS.

It has the disadvantage of being annoyingly verbose compared to TypeScript though, so I guess the score here is:

JSDoc: Documentation that stays in sync, powers editor tooling: 1 Works with standard JS: 1 Generates better API docs: 1

TS: Documentation that stays in sync, powers editor tooling: 1 Requires compile-to-JS: 0 Less verbose than JSDoc: 1 WAY more fun to write: 1 Lacks prose descriptions for documentation: 0

JSDoc: 3 TypeScript: 3

If you follow the link in that reference, you'll see that the claim that TypeScript does not reduce bugs much is backed up by 4 independent sources.

The link should not be paywall protected. Did you try it?

See https://news.ycombinator.com/item?id=20326045

The problem seems to be that the software blindly trusted input from a single sensor. The issue I take with that is that multiple sensor readings are available on the aircraft. Even in non-life-critical applications like video games, software engineers absolutely are responsible for validating inputs from untrusted sources.

Beyond that, a good software engineer would have ensured that the specification made sense, that the integration with the rest of the system made sense, and that a sensible override system was part of the system design.

That said, the bulk of the article focuses on management's failure to ensure that quality was a priority, and to communicate that clearly in the company culture.

The number they consider conservative is that TypeScript can address up to 15% of public bugs. That's a different number than the proportion of public bugs found ts-undetectable because they're not type errors at all.

It's not less overhead, but you can't skip TDD with TypeScript because at least 80% of bugs are not detectable by TypeScript.

I get the same real-time error detection and refactoring help from type inference, lint, and TDD. Lint and inference gives me real-time editor feedback, TDD runs automatically on file save.

I do consider TDD and code reviews are costly but you can't skip them with TypeScript because at least 80% of bugs are not detectable with TypeScript.

First of all, you're wildly over-stating the difference. The scale based on percent of time spent or saved. It's impossible on this scale to even say that TypeScript is three times worse than no types, let alone thirty times.

As for the bug reducing benefit, yes it's up to 20% if you do nothing but TypeScript. As explained in the article, 80% of bugs can't be addressed by static types at all, so you can't skip the other measures safely. The zero point includes the other measures, which easily cover 90%+ reductions, combined.

Since other measures catch type errors, too, we apply the TypeScript reduction after discounting the other errors caught. Even with the maximum benefit of the doubt, assuming TypeScript catches 20% of the remainder, it's still a small percent of a small percent. You get exponentially diminishing returns with each bug prevention measure you apply, and TypeScript can't catch the lion's share of bugs, so it's the only one that makes sense to leave out as a quality control measure.

Those tools have a negligable learning curve because once you set them up, you can simply forget about them and write JavaScript code.

Please show me the proper typing of the map transducer in TypeScript. I'm willing to learn.

Some good reasons for that:

1. I get type feedback in my browser with inference. 2. I get near real-time feedback from TDD on file save. 3. I get real-time lint feedback, too.

The net result is I get several multiples better bug coverage than TypeScript alone can provide at about the same speed -- while writing idiomatic JS.

The trouble is most projects are NOT employing the other reviews properly. The study made no effort to determine the quality of the test and review process, and instead assumed that they had been done by virtue of the bugs being merged to the master branch.

The study then finds that about 80% of the bugs they found were not simply ts-undetectable, but not type errors at all. Instead, they're things like the wrong URLs being used (sting errors), wrong branching logic, wrong predicate logic, etc.

That means the maximum effect must be less than 20%, but the authors couldn't detect 20% even knowing exactly what the bug and fix was, down to the line numbers and exact code used to fix the bug.

Even being extremely generous and assuming they could fix 20% of remaining bugs, it's too far down the ladder of exponentially diminishing returns to make much difference at that stage.

I've seen this happen for a handful of functions, but implementation correctness proofs for general applications are far beyond the expressive capabilities of TypeScript.

I had not seen that before. I will fix the mistake.

I have all those benefits already. The zero point includes inference, lint, design review, spec review, code review, and TDD -- and you can't leave those out safely because 80% of bugs are not type errors.

I get the same benefits from my other tooling. Lint and type inference provide real-time feedback similar to TypeScript, and TDD gives me continuous test feedback every time I hit save. That's the zero point on the ROI scale, and while I admit that well annotated TypeScript code does it a little better, it's not better enough to justify the cost.

The reasons you don't understand are clearly explained in the article (you can't skip them because 80% of bugs are not detectable by TypeScript), and if TypeScript actually could catch 100% of bugs, I'd rate it a perfect 10 on that point and the ROI would be game over. TypeScript would win because you could skip the other quality controls and save a ton of time.

I wish.

Hello. Eric Elliott here. Which codebases were those, exactly?

Hello. I wrote it, and the article cites a lot of data that came from objective data sources including studies by companies like Microsoft, IBM, and universities to make the points about the limitations of bug reduction.

As for the ROI analysis, the article clearly states that the objective data was too noisy to use, clearly explains why, clearly states which data is subjective, and provides readers with guidance on how to interpret the subjective data.

There's nothing dishonest about it. It is not "science", and does not claim to be, though it does cite some real science. It is an anecdotal opinion piece, though that opinion is well informed and supported by some "real science".

It should be interpreted as an anecdotal opinion, not a formal research study -- as with any small data sampling. You can't draw definitive, objective conclusions from it.

Some people have had overwhelmingly positive results with TypeScript. We need a lot more people to share their experiences before we can start to say anything objective about it. Please don't discourage them from sharing their opinions, no matter which side of the ROI spectrum they favor.