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).
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.
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
I love JSDoc but it has the fatal flaw of being optional. It requires human discipline which, when your boss is breathing down your neck to get that feature out, you aren't gonna do. Same goes for robust tests etc. TS is self documenting even if it's less verbose you'll get more coverage overall in your system and maybe have some hope of being able to to back and write those JSDoc comments later. You also don't have to write as many tests as you can be somewhat assured of data integrity since you've defined a robust contract.
Well yes and no. Even if you don't add any type annotations you still get some implicit type safety. You have to opt out with an Any type of something to totally turn that off.
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.
My claim comes from having built large scale systems with and without TS. I have the scars from working without it and I'll never do it again if I can help it. I'll also say that it's possible to write bad buggy code no matter what tooling you use. It's a "pit of success" thing for me. I want to at least make sure the super dumb stuff doesn't make it through.
IMO you should use all the TDD, documentation, and code/design review in ADDITION to a type system.
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.
list top 10 hip hop artists from the year 2014 |> sortBy(chart performance, descending)