Quantcast
[ 3 / biz / cgl / ck / diy / fa / g / ic / jp / lit / sci / tg / vr ] [ index / top / reports / report a bug ] [ 4plebs / archived.moe / rbt ]

Support us on Patreon!

/g/ - Technology


View post   

[ Toggle deleted replies ]
File: 331 KB, 900x745, bigstock-Programming-Web-Banner-Best-P-258081862[1].jpg [View same] [iqdb] [saucenao] [google] [report]
70249625 No.70249625 [Reply] [Original] [archived.moe] [rbt]

Have you ever thought about designing your own programming language? Did you get anywhere with it? Have you written a compiler/interpreter?
What sort of things would be must-have features in a programming language of your own?

>> No.70249648

>>70249625
no i honestly dont see the need to make my own programming language
C and some parts of C++ does everything that i could ever need to do

>> No.70249690

>>70249648
I like C for how minimal and "do it yourself, faggot" it is, but it's missing a lot of convenience features and feels like it's still stuck in the 70s with a bunch of half-baked "modern features".
C++ on the other hand is a monstrous fucking mess in every aspect and I would never use it out of my own volition.

>> No.70249891

>>70249690
what half-baked "modern features" are you talking about? and just exactly what is a fucking mess in c++?
i regularly use c++ features (compile-time directives, enum classes, namespaces, some classes and inheritance stuff, copy by reference) but stick with c-style pointers/arrays and mostly do everything "c style"
i get that the c++ stl is shit and therefore i avoid it
dont go looking for shit where you are bound to find some

>> No.70250214

yes
>Have you written a compiler/interpreter?
did according to courses and books, didn't work on my own lang.
>What sort of things would be must-have features in a programming language of your own?
most of them are easy to complain about when designed badly and hard to design right. Zig seems to have a similar idea to what I want

>compilation unit
C has file-scoped object files, that's pretty trivial. Multi-file modules would be handy. But then you have to design namespacing, how to export stuff, visibility rules, ... This part can also make incremental compilation either robust or nightmare.

>syntax
I like C-like structured syntax, but type notation in C is whole backwards. Go did types better but brought a lot of annoying crap to it. I don't mind semicolons, so would keep em.

>type system
static dispatch and code generation, templates with just type arguments are easy to implement. But then name mangling is annoying, exporting templates to other modules is tricky. I don't want function overloading with implicit inference of the right option, this can get error prone. But what else?
Dynamic dispatch with classes is also pretty easy but I don't like it.
Features like optionals that could with robust error handling, that requires to be part of type system. But Rust is getting too crazy with type system imho.

>macros, conditional compilations, ...
Zig criticizes C preprocessing for not checking unused options. But bringing CTE features and not just string substitution is haaaaaard.

some small features:
- built-in string matching optimized on compile time
- sane integer promotion and implicit casting rules

And - the reason why I'm so unsatisfied with current languages - compiler should do much much more than just generating binaries. Static analysis, custom linters and pragmas, codebase analysis (e.g. call graphs), analyze stack size, test and benchmark units that can bypass visibility rules, interpreter for otherwise compiled language, and maybe more.

>> No.70250279

>>70250214
also: no RAII (thus no """smart""" pointers), no exceptions, no GC, no operator overloading, no crazy turing-complete metaprogramming

>> No.70250297

>>70249625
I worked on the Solidity compiler for Ethereum. It was a good experience to understand how a language is made and how it works. But it could honestly have been done much better.

>> No.70250310

>>70249891
>thinks STL is shit
LOL. Ok Linus Fagvolds. Enjoy spending a month to write something that's already been written 10000 times.

>> No.70250353
File: 95 KB, 1532x709, solidity.png [View same] [iqdb] [saucenao] [google] [report]
70250353

>>70250297
is this true?

>> No.70250407

>>70250353
Most of it yea, especially when that was written. Alot of that has been fixed in recent versions and I don't think it should have ever been thought of like a general purpose programming language so much as an OOP scripting language. A lot of folks upset that it doesn't do functional tricks but blockchains imo are inherently stateful and thus fit better under the OOP paradigm. Plus OOP is more accessible and you have the JVM to look to for inspiration.

>> No.70250438

>>70250407
In particular, the dynamic array problem and the problems of `this` and `var` have been alleviated and taken care of. You should never use a dynamic array in Solidity, it's only there for completion, but if you're looping over a dynamic array, you're doing smart contract development wrong. Christian and Alex should have been a bit more stringent with this from the outset but they didn't fully know what they were doing when they built the language (nobody ever does) and did things to the best of their abilities. It's a lot better working with Solidity today but I think a lot of people are moving to Vyper because it looks and feels just like Python with an emphasis on security.

>> No.70250468

>>70249891
God help you if you need to use C++ templates.

>> No.70250495

>>70249625
I've worked on a simple weird hybrid language that looks like pseudo-code and can do statements and mutability, but ideally favors functional code. I think something like this is missing from the landscape currently - Python tried but it's a shit and badly designed language (functional style in it is especially clumsy), modern JS probably comes closest but it's not as simple as it could be.

The real language is statically typed, but here's a simplified sample

let map <- func f lst:
let n <- #lst!length.
while n > 0:
#lst[n] <- f #lst[n].
n <- n - 1.
;.
;.

let inc <- func n: n + 1.

let arr <- alloc {1, 2}.
map inc arr.

system!printLn (intToStr arr[1] + intToStr arr[2]).

system!exit 0.


All in all, I think first-class functions (and consequently closures) are one of the most important features for a modern language. A static type system is nice, but a good one is hard to implement - ML family languages have a great type system, but simple static type systems such as C's are almost useless.

>> No.70250935

No
Yes
If you didnt take a compiler course and implemented one you went to a shit tier university

>> No.70251257

>>70249625
Yes. I've always wanted to make an assembly-like language for a fantasy retro console. Instead of writing bytes to certain addresses you would have built-in macros (as cpu/vpu ops) like

SPRITE 0xFF 0xFF 0xFF 0xFF 0xFF
PAL 0xFF 0xFF 0xFF
MUS 0 0xFFFFFFFF
PLAY 0
STOP 0

>> No.70251698

>>70249625
the world will be a better place if everything was build using a Lisp dialect.

>> No.70252621

>>70250495
Look up Myrddin

>> No.70252675

>>70250279
>no operator overloading
So different operators for float + and int + like in OCaml?

>> No.70252926

>>70252621
Nice, looks pretty good and also complete. I'd have done away with the significant whitespace though, it always seems like a good idea but eventually bites you.

>>
Name (leave empty)
Comment (leave empty)
Name
E-mail
Subject
Comment
Password [?]Password used for file deletion.
reCAPTCHA
Action