Ask HN: What are the nice feature you need in a programming language?

REPL, Polish notation, extensible language, recompilation of software functions without stopping the software.

I like the c style for loop syntax. Swift creator's decision of removing it doesn't make sense to me.

I've found that a set of features is not all that important, and in fact leads to languages like C++ or Java that are actively unpleasant.

Better to have some guiding principles or philosophy, and arrive at C, Lisp, APL, Lua, SML or Haskell.

Features from other languages I wish were Python builtins:

- Haskell algebraic data types + syntactic sugar

- C/Lisp macros

Language support protocol for ide/editor (aka pigments[1]/treesitter[2] bnf for emacs, neovim, zed, etc)

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 ~

Native wrangling of JSON objects. Instead of stringify, parse, convert to arrays; treat JSON as a primitive object with properties. When you assign a JSON object to a string, the language should have an official casting mechanism of JSONtoString. Even better it should have an official way of casting JSONtoStruct so you can easily insert it to a table.

Strings that are automatically allocated, reference counted, copy on write, counted, can contain binary data, and are null terminated for compatibility. Like the strings in Free Pascal

Im going to save you time and describe what the optimal programming language anyone actually wants, no matter what they say:

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.

Yes it definitely saves lot of time & effort. Great :)

Instead of going up in abstraction, I think it’d be nice to have a lang that tries to go down, more coherent with the hw, without “historical” assumptions.

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.

n:m scheduled green threads in the style of goroutines or erlang/elixir processes. await is an abomination.

Make it easy to use multiple cores without forcing the user to think about it constantly.

- Sum types / discriminated unions

- Pattern matching (arguably a more flexible and general way to do the type of thing you have in your number 4 if syntax)

Nice. I am not sure we need 128bit data types. I think 64bit is enough for now. Matrix collection is really essential. We'll discuss about it. So we might ignore Multi dimensional array complexity.

I actually like javascript.

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.

Apparently, x86-64 has:

    981  unique mnemonics
    3684 instruction variants

Since the architecture and instruction set has been evolving for decades, I often wonder whether the compiler is generating code for some lowly common denominator. If a sufficiently smart compiler were to compile code for the developer's most current CPU, the code will need to be recompiled for lesser systems.

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.

Confused by this approach, people want to write in interpreted languages and have it compiled with an LLM?

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

I think Swift already does this but I appreciate good type inference. Writing functions in a Pythonic/dynamic looking way (i.e. without a bunch of type declarations unless you want them) but still actually statically typed and enforced at compilation/runtime.

Is

  a == (10 || 20 || 30)

really better than

  a in (10, 20, 30)

It seems the first is just ambiguous, and longer.

A formatter with little to no configuration, similar to black.

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.

Wow great, yes good approach. Thanks!

The second is Python :)

* functions as first class citizens

* 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

If you can squeeze it in.... A magical assignment like :== which declares the left value is ALWAYS equal to the expression on the right after that point, so that if any part of the expression on the right changes, the left gets updates as a dependency.

I once saw this in a language called metamine and the demo was amazing, mixed imperative and declarative programming interweaved.

A vast open source community. If you want to go fast, go alone. If you want to go far, go together.

The same way c# used to do it. C# provided dynamic code generation in both byte-code-level, and AST/lamba implementations. And even provided an interactive C# "interpreter" that actually used dynamic code generation under the covers. All of which died with .net core. I rather suspected that Microsoft decided that dynamic code generation was far too useful for writing cloaked viruses, and not quite generally useful enough to justify the effort.

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.

I don't know how. And the answer may be Lisp (!) ... but a decent way to deal with tonnes of cross cutting concerns out of the box for many use cases.

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!