Programming thread

[y a t s]

Do you guys ever design your own languages in your brain?

All the time. I have gone through with making a few of them, none of which I can name without doxing myself
Most of them are functional in nature, but I always do closures regardless because they're fun to implement.

Once I find the free time, I still wanna make my Smalltalk variant, Girltalk.

 

[Anti Snigger]

All the time. I have gone through with making a few of them, none of which I can name without doxing myself
Most of them are functional in nature, but I always do closures regardless because they're fun to implement.

Once I find the free time, I still wanna make my Smalltalk variant, Girltalk.

Most of the stuff I come up with is extremely boring. I want enums to have support for group operations for instance.

 

[Belisarius Cawl]

Don't we all? I'd assume it's almost a universal experience.

At some point I want to implement a Lisp (mainly for ease of parsing) and perhaps a Smalltalk. Don't know how I'd make them "special" though.

All the time. I have gone through with making a few of them, none of which I can name without doxing myself
Most of them are functional in nature, but I always do closures regardless because they're fun to implement.

Any tutorials on lexical scope and closures?

Once I find the free time, I still wanna make my Smalltalk variant, Girltalk.

I have a physical copy of the Blue Book even though PDFs are readily available.

How would you go about making "Girltalk"?

 

[sadrefrigerator]

Basically the whole game would be modeled as a function that takes the whole world state as a tree of various objects, and an event, and returns a copy of the old world state but with whatever changes that event would prompt. And one type of event might just be a time tick, so if the player didn't do anything, the update function would still tick things along.

The dirty secret for people who champion functional languages is that they never create the whole system in a functional manner. For example, if your app was in Haskell or Elixir, its still going to be interacting with a database in a nonfunctional manner. Only select parts of the business logic is going to be functional.

 

[geckogoy]

I mean, yeah, it was meant as a conversation starter about what kind of language

I wanna make a headerless flavor of C. I think that would be pretty awesome and have a lot of uses.

 

[macrodegenerate]

I wanna make a headerless flavor of C. I think that would be pretty awesome and have a lot of uses.

Yeah for just one guy.

 

[Agent Sandoval]

I more so meant more specifically what leads you to embed Guile or anything like it in a C application so that you reach that point.

Guile was made to be embedded in C programs, it just doesn't usually mix well with being embedded alongside other frameworks or in a plugin.

Have you had any experience with embedding Lua?

I haven't, but have it on good authority that Lua does a very good job of sandboxing itself. My impression of the syntax is that it's very semantically similar to C and so will solve problems in a very similar way. That puts me off it a little, but that's a personal preference.

 

[y a t s]

At some point I want to implement a Lisp (mainly for ease of parsing)

It's really fun. You should give it a shot.

Any tutorials on lexical scope and closures?

Good question. My grasp of closures was obtained primarily through trial and error; I wish I had better resources to give out.

Once you get how variable scoping and shadowing works (shadowed variable x gets stored as x_0, x_1, etc. per layer by the compiler), the rest of it is just handling the encapsulation and application of argument values (currying makes this pretty easy). If you can handle all the other moving parts of a compiler, this should come easily.

Edit: since you mention implementing Lisp, look into S-expressions (sometimes referred to as a sexp). Their nested, tree-like nature lends itself well to functional applications, and they originated with Lisp. They're a really intuitive way of representing all of the nesting and encapsulation, which is essentially what you're thinking of when you mention ease of parsing. Racket has a wealth of token handling features that make playing with them and writing compilers that use them a breeze. Also brush up on abstract syntax trees (ASTs).

How would you go about making "Girltalk"?

Just make my own custom Smalltalk VM. As an LFJ shitpost, it would mostly be dumb syntax edits, but it would be cool to add advanced features that extend the original ideas of the language more as well.

 

[306h4Ge5eJUJ]

Do you guys ever design your own languages in your brain?

I used to be big on it until I learned CL, noticed that it did like three major things I wanted to do except better and twenty years ago, and realized that making new languages is mostly a hamster wheel for people who don't know what came before, making minor improvements on currently popular things that should really be a macro or a compiler feature instead of a whole new language. The current crop of C-likes (e.g. Odin, Zig) are especially bad offenders of this.

 

[Belisarius Cawl]

I used to be big on it until I learned CL, noticed that it did like three major things I wanted to do except better and twenty years ago

What were those three things?

 

[306h4Ge5eJUJ]

What were those three things?

It's been a while, but I think among them were the abilities to redefine things at runtime and drop into raw integer arithmetic if requested. The latter is technically an implementation feature but CL intentionally makes it easier to support. The third was probably something that macros could handle.

 

[y a t s]

I used to be big on it until I learned CL, noticed that it did like three major things I wanted to do except better and twenty years ago, and realized that making new languages is mostly a hamster wheel for people who don't know what came before, making minor improvements on currently popular things that should really be a macro or a compiler feature instead of a whole new language. The current crop of C-likes (e.g. Odin, Zig) are especially bad offenders of this.

I like the somewhat recent trend of transpiled languages like Sass or TypeScript. It makes so much more sense to make either a preprocessor or a mini compiler for more widely adopted languages and let them do all the heavy lifting and maintenance instead of reinventing the wheel.

Hy (based around Python) is another good example of this sort of language, and it fits well with the Lisp discussion.

 

[Chiang Kai-shek]

I like the somewhat recent trend of transpiled languages like Sass or TypeScript.

Oh hell no, they made the programminng languages trannies too! How will we cope when the code 41%s itself?!

On a serious note, I think I’m starting to understand pointer arithmetic(?) better. I managed to create a program with an array of structs and loop through it all. It took me an embarrassingly long time to realize I needed to type *(pointer + i) instead of *pointer + i for all the values. However, pointers to 2D arrays confuse a bit. You have to apparently type *(pointer + i+1) to increment the rows. I probably should’ve just done array[i] but I really wanted to use a pointer to go through an array.

 

[Anti Snigger]

People who bitch about zero indexed arrays are absolutely brainlets

 

[y a t s]

It took me an embarrassingly long time to realize I needed to type *(pointer + i) instead of *pointer + i for all the values.

The parentheses always help a lot with this, even just for readability purposes. When in doubt, use them wherever feels right when handling mathematical (not just numerical) expressions.

However, pointers to 2D arrays confuse a bit.

2D arrays are quite simple structurally.

1D arrays are just pointers to contiguous chunks in memory. By extension, 2D arrays are pointers to contiguous chunks in memory that contain other pointers to contiguous chunks in memory (i.e. an array of pointers).

To do this, we simply define a 1D array for each row, and then store the pointers to each of those row arrays in another 1D array. So when we use an index in the first set of square brackets on that array of pointers, we access the pointer to the array for that row. Since arrays are just pointers to chunks of memory, we can once again use a 2nd set of square brackets to index the array we're now pointing to, as if it were a traditional 1D array (it is), to access the desired value. Using anything but square brackets with this XY coordinates setup is rarely ever necessary nor worth doing.

 

[Chiang Kai-shek]

Do you guys ever design your own languages in your brain?

Sometimes I make up syntax for imaginary languages. For example:
void fun doSomething -> int p1, int p2:
This is probably terrible syntax, but it can be fun to mess around with new syntax. But I also want to create the most memory unsafe language known to man. Freedom is about being able to fuck something up! Kierkegaard once said that anxiety is staring down a bottomless pit knowing you can jump down it. That’s what true freedom is! That is my dream.

 

[Kosher Salt]

On a serious note, I think I’m starting to understand pointer arithmetic(?) better. I managed to create a program with an array of structs and loop through it all. It took me an embarrassingly long time to realize I needed to type *(pointer + i) instead of *pointer + i for all the values. However, pointers to 2D arrays confuse a bit. You have to apparently type *(pointer + i+1) to increment the rows. I probably should’ve just done array[i] but I really wanted to use a pointer to go through an array.

Would that be *(*(pointer + i) + j)?

I think, if you manually define an array e.g. int array[2][5], then an array[i][j] is the equivalent to *(array + i * 5 + j), but if you dynamically allocate the array as an array of pointers that point to row arrays, you don't necessarily get contiguous memory like that.

I'm with @y a t s on this one, square brackets are easier here.

 

[Creative Username]

2D arrays are quite simple structurally.

1D arrays are just pointers to contiguous chunks in memory. By extension, 2D arrays are pointers to contiguous chunks in memory that contain other pointers to contiguous chunks in memory (i.e. an array of pointers).

To do this, we simply define a 1D array for each row, and then store the pointers to each of those row arrays in another 1D array. So when we use an index in the first set of square brackets on that array of pointers, we access the pointer to the array for that row. Since arrays are just pointers to chunks of memory, we can once again use a 2nd set of square brackets to index the array we're now pointing to, as if it were a traditional 1D array (it is), to access the desired value. Using anything but square brackets with this XY coordinates setup is rarely ever necessary nor worth doing.

I personally use a 1D array and a helper function for indexing it, because I never want to call malloc() more than the minimum amount necessary.

Maybe it's just my lack of experience. A (rather specialized) benefit of my strategy I see is that I could easily change the index function to possibly do things like Morton ordering.

A good way to index 2D arrays is *(array + (y * width + x)), or with square brackets, array[y * width + x].

 

[y a t s]

I personally use a 1D array and a helper function for indexing it, because I never want to call malloc() more than the minimum amount necessary.

Maybe it's just my lack of experience. A (rather specialized) benefit of my strategy I see is that I could easily change the index function to possibly do things like Morton ordering.

A good way to index 2D arrays is *(array + (y * width + x)), or with square brackets, array[y * width + x].

If I need to dynamically allocate such a thing, I would just do a traditional buffer. Any time I need to allocate something big, it's almost always binary data, which makes simple hex indices much easier. If I do need something closer to a 2D array for a particular task, I can't imagine myself ever using malloc repeatedly for it. Just the thought makes me shudder. Regardless, handling any 2D array dynamically is going to be convoluted in some way.

You could handle indexing the row with a simple #define macro instead of a helper function.

I think, if you manually define an array e.g. int array[2][5], then an array[i][j] is the equivalent to *(array + i * 5 + j), but if you dynamically allocate the array as an array of pointers that point to row arrays, you don't necessarily get contiguous memory like that.

Yeah, stack memory due to its very nature tends to be packed closely together like that. When it comes to heap allocation, shit gets allocated just about anywhere that works.

void fun doSomething -> int p1, int p2:
This is probably terrible syntax

Lmao this looks a lot like rust

 

[Napoleon III]

The current crop of C-likes (e.g. Odin, Zig) are especially bad offenders of this.

I have heard good things about Odin specifically for Game Dev. I know Odin was also inspired by Jai which is made specifically for game dev by a programmer with something like 20 years experience.

I tend to agree though there are many many cases of people making things not because they have a specific problem they want to solve and they can't solve it any other way than making something big, but because they want to make something slightly better.

Just make my own custom Smalltalk VM. As an LFJ shitpost, it would mostly be dumb syntax edits, but it would be cool to add advanced features that extend the original ideas of the language more as well.

If you ever did make it I know a lot of people would laugh at it. I find the idea of something like a segmentation fault being renamed to consent accident hilarious. Also if you don't mind sharing or you want to save it until/if you actually make the language what else would you rename?