←back to thread

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

16 points Hashex129542 | 4 comments | 21 Nov 24 01:23 UTC | HN request time: 0.612s | source

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?

Show context
ActorNightly ◴[21 Nov 24 04:08 UTC] No.42201001[source]▶
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.

replies(3): >>42201027 #>>42201547 #>>42205824 #
1. blharr ◴[21 Nov 24 06:01 UTC] No.42201547[source]▶
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

replies(2): >>42202350 #>>42208500 #
2. rerdavies ◴[21 Nov 24 08:48 UTC] No.42202350[source]▶
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.

replies(1): >>42203833 #
3. neonsunset ◴[21 Nov 24 12:49 UTC] No.42203833[source]▶
Expression Trees and IQueryable<T> compilation did not die and remain fully supported features. For example EF Core uses them for query compilation. 'dynamic' did not die either even though it should not be used because there are usually better constructs for this.
4. ActorNightly ◴[21 Nov 24 20:47 UTC] No.42208500[source]▶
>dynamic code execution

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.