Ask HN: What are the nice feature you need in a programming language?
I'm developing a programming language, the keywords and features mostly based on Swift 5 but some additional features like,
1. async function will be called from no async function but no async/await keyword. If you want to block main thread then block_main() function will be used. block_main() /* operations */ unblock_main()
2. protocol can inherit another protocol(s) & protocol can confirm a class like swift.
3. no `let`. only `var`. compiler can optimize further.
4. if (a == (10 || 20 || 30) || b == a) && c { }
5. `Asterisk` is replaced to `x` operator for mul operations.
What are the features you found or you need in a programming language?
51 comments
[ 3.2 ms ] story [ 110 ms ] threadBetter to have some guiding principles or philosophy, and arrive at C, Lisp, APL, Lua, SML or Haskell.
- Haskell algebraic data types + syntactic sugar
- C/Lisp macros
For sum types we have enums, and for product types we have tuples (or namedtuples or dataclasses). Sugar could be done with decorators or metaclasses.
For Lisp macros, there's macropy and Hissp.
https://www.gnu.org/software/m4/
https://threeofwands.com/algebraic-data-types-in-python/
https://github.com/lihaoyi/macropy
https://github.com/gilch/hissp
There are issues with using stand-alone implementations of C preprocessing like GNU cpp with languages that deviate from C in their token syntax.
Because of the similarity to swift language, perhaps hazel[3] option to highlight differences between standard swift & swift-like language.
-----
[1] Pygments, generic syntax highligher : https://news.ycombinator.com/item?id=41324901
[2] Treesitter : https://news.ycombinator.com/item?id=39408195 / https://github.com/mingodad/plgh
[3] : Hazel: A live functional programming environment featuring typed holes : https://news.ycombinator.com/item?id=42004133 ~
People want to be able to write either python or javascript (i.e the 2 most widely used languages) , and have a compiler with an language model (doesn't have to be large) on the back end that spits out the optimal assembly code, or IR code for LLVM.
Its already possible to do this with the LLMs direct from the source code, (although converting to C usually yields better results than direct to assembly) but these models are overkill and slow for real compilation work. The actual compiler just need to have a specifically trained model that reads in bytecode (or output of the lexer) and does the conversion, which should be much smaller in size due to having a way smaller token space.
Not only do you get super easy adoption with not having to learn a new language, you also get the advantage of all the libraries in pypi/npm that exist that can be easily converted to optimal native code.
If you manage to get this working, and make it modular, the widespread use of it will inevitably result in community copying this for other languages. Then you can just write in any language you want, and have it all be fast in the end.
And, with transfer learning, the compiler will only get better. For example, it will start to recognize things like parallel processing stuff that it can offload to the GPU or use AVX instructions. It can also automatically make things memory safe without the user having to manually specify it.
How would you do things like dynamic code execution or reflection? Lots of properties are stripped as part of the compilation that you wouldn't be able to refer back to.
Are you just saying write python -> interpret it -> compile it -> convert to assembly? Because I believe that already exists, but is difficult to just do that all the time because of the compile step and having to convert to static typing
You'd have to generate reflection data at compile time. And llvm supports dynamic code generation, so that's not a problem either.
Not really sure why anyone would want to do an interpreted language though.
Run the code through actual Python or NodeJs. Once you are happy with result, compile it to native.
>reflection.
Reflection can be "unrolled" to static values during compilation.
>Are you just saying write python -> interpret it -> compile it -> convert to assembly? Because I believe that already exists,
It exists in the sense that you still have all the python interpreter code for dynamic typing baked into in the executable. This would remove all of this.
I find it even more dubious that someone would want something that could hallucinate generating machine code. The difficulty of optimizing compiler passes is not in writing code that appears to be "better" or "faster" but guaranteeing that it is correct in all possible contexts.
The reason its different is because you are working with a finite set of token sequences, and you will be training the model on every value of that set, because its fairly small. So hallucination won't be a problem.
Even without ML, its a lengthy but P hard task to really build a python to C translator. Once you unroll things like classes, list comprehensions, generators, e.t.c, you end up with basically the same rough structure of code minus memory allocation. And for the latter, its a process of semantic analysis to figure out how to allocate memory, very deterministic. Then you have your C compiler code as it exists. Put the two together, and you basically have a much faster python without any dynamic memory handling.
The advantage of doing it through ML is that once you do the initial setup of the training set, and set up the pipeline to train the compiler, to integrate any pattern recognition into the compiler would be very trivial.
No, you don't, and that's why there are many engineer years invested into designing AoT and JIT compilers for JS and Python.
If you write C like Python you get Python but slower.
> The advantage of doing it through ML is that once you do the initial setup of the training set, and set up the pipeline to train the compiler, to integrate any pattern recognition into the compiler would be very trivial.
Except this has already been done, so what advantage does ML bring? Other than doing it again, but worse, and possibly incorrectly?
The advantage is that you get native optimized code like someone wrote it in C directly, and ability to automatically generate code to be offloaded to GPU as people start doing expanded training with higher level pattern recognition.
The incorectness part I adressed already, stochastic output doesnt matter when your domain is finite.
My pet peeve is multiplication: u64*u64=u128. true on any modern hw, true in math, false in any programming lang that I know of. There are many others like unnecessary assumptions on how easy is to access memory.
Vector and matrix ix should be another first class citizen.
The reason for a lang vs just writing in asm are 1) I don’t want to distinguish x86 vs arm, 2) I want a compiler + optimizer.
Make it easy to use multiple cores without forcing the user to think about it constantly.
- Pattern matching (arguably a more flexible and general way to do the type of thing you have in your number 4 if syntax)
I want types, like typescript, but instead of compilation, there should be a "boot type check" which does about the same checks as tsc, but the types should be first-class, available at runtime, so I can pass them around, create, read, update and delete them at runtime.
I want runtime code creation that is more robust than creating source-code as strings and then compiling them, I want first-class code-as-data like in LISP. I want to be able to define some blocks of code, and conditionally combine them the new blocks which I can compile to functions. I want to be able to derive functions that is more, less or different from their parents (for example, removing or replacing a number of its statements) (basically, I want to have enough control that I can chose a pattern of generating ideal callbacks with no conditionals)
I want to be able to express (I use % for lack of a better idea right now, this is the type-safe version of the syntax))
const someBlock = (a: number, b:string)=%{ console.log(a+2+c); }
And pass it to a function: myFunc(1, someBlock, 3);
(and someblock should be able to use it: function someFunc( aBlock: % ) { const a = 1; const c = 3; someblock; }
I want better introspection, if I pass a function, there's no reasonable, robust and performant way to reason about that function.. You can't access its parameter list to learn the names of its parameters, their type or number, you can't access its body to learn what it does, you can't even see its return type, to determine what to do with its result, mind you, most of this metadata is already present in the js runtime, just not exposed in a good way to the language.. You can't even access the ast.
const someBlock = function () { console.log(this.a + 2 + this.c); }
const myFunc = someBlock.bind({a: 1, c: 3})
myFunc(); // => 6
ARM architectures are getting instruction set bloat and RISC-V is also tending that way with many variants being produced.
I prefer minimal syntax, e.g. Lisp, Smalltalk, Self. Then let the abstractions be plugged in with appropriate compiler support. I find the idea of blessed built-in types constrain implementation designs due to their prevalence.
Not only that, I would like to see OS install to profile the hardware and then automagically recompile for that specific hardware. As I understand it: Linux probes for hundreds of potential devices only to load perhaps a dozen or so. I don't know how many device drivers are actually integrated into the kernel. Probably far more than is really necessary. But I'm rapidly getting out of my depth here.
A linter what the reasoning for all rules is well explained, similar to shellcheck or eslint.
Both ideally integrated in an LSP, which also has all the common features of a modern LSP.
* procedures as first class citizens
* lexical scope
* strongly typed
* single character syntax and operators
* inheritance and poly instantiation as a feature of language configuration but remove from language instantiation
* event orientation via callbacks. many developers don’t like callbacks but they provide the most flexible and clearly identifiable flow control path
* single string format with interpolation
I once saw this in a language called metamine and the demo was amazing, mixed imperative and declarative programming interweaved.
It could also just be defined in the "setter" for x, that x Y = x + 2, so everything you update x you update Y
I don't particularly like it because, what if you want to change y? Do you have to change x correspondingy?
For example a web server needs authcn, authzn, logging, metrics, db retrys, and all the usual gubbins. A DSL for this would rock.
Elm is an example of a language that went down the DSL road and while arguable make some rough choices it proved that a DSL can work really nicely. One side effect is dep management was perfect!
Observables/reactive programming are pretty important to me on FE too, especially if you have async threads all over the place (looking at you web tech).
Stop caring about syntax and start caring about semantics. For example
> if (a == (10 || 20 || 30) || b == a) && c { }
I get what you're after, but don't optimize syntax for bad code. `a in [10, 20, 30, b] and c` makes a lot more sense to me conceptually than trying to parse nested binary operators, especially when you consider the impact on type checking those expressions.
> async function will be called from no async function but no async/await keyword. If you want to block main thread then block_main() function will be used. block_main() /* operations */ unblock_main()
Think very carefully about the concurrency model of your language before thinking about how the programmer is going to express it. In particular, this model leaves a footgun to leave a program in invalid state.
> What are the features you found or you need in a programming language?
The biggest misdesigns I see in languages are a result of PL designers pushing off uninteresting but critical work so they can explore interesting language semantics. Like the compile/link/load model and module resolution semantics have far more impact over the success and usability of any new language (because they empower package management, code reuse, etc) and the details are hairy enough that taking shortcuts or pushing it off until later will kneecap your design.
Typescript is the best syntax-wise language currently that fulfills that on dynamic side.
Swift has also a decent DevX and close to that on a "static" side of universe.
Sorry to disappoint but there are much more important problems begging for solution in infra, package management, transpilation and other domains in all popular languages today.
All syntax sugar and features are already good enough for your next Goodle or facebook.