Author Topic: bosque - new experimental microcuck programming language  (Read 1262 times)

everything you define is immutable so yes

only class fields are immutable. variables are mutable

immutable objects are daunting to work with but that's just because our abstraction of everything in real life is mutable. its hard to visualize a new 'person' being created every time you move from one place to another, rather than visualizing it as a person's position in space changing. working with immutable objects makes your code completely safe because there's nothing silently mutating objects and there's absolutely no chance for human error. but then you have to create a new object every time you want to change something. it all has to do with the scope of your design.

in every language primitive types are immutable. every time you do "string s = 'hello'" you're basically creating a new string object with the value "hello" and assigning that reference to s. its obviously more complex to do this with bigger typically mutable objects like 'cars' for example but if you compartmentalize/interface the fields of a car that are usually mutable and the ones that aren't then it becomes a lot less complex.

like the number of wheels a car has doesn't change during its lifetime. it'll always have 4 wheels, it'll have an engine. something that does change is the car's speed and position. so you can just create two separate concepts like 'CarImmutable' that includes final values like # of wheels or name of car, license plate, etc. and 'CarMutable' which includes position and speed and is rebuilt every time. you gotta keep track of two objects at once in an array and destroying and rebuilding an object does take extra memory and cpu but it is technically good practice or something

bosque works better more as standalone widgets that could probably be used to plug faster logic into heavier programs if they make it faster than other programs
« Last Edit: April 20, 2019, 01:10:06 PM by PhantOS »


bosque works better more as standalone widgets that could probably be used to plug faster logic into heavier programs if they make it faster than other programs
Maybe? We'll have to wait and see. If this project doesn't get canned, it might as well be that, but I really don't like the syntax or what it offers right now.

I really don't like the syntax or what it offers right now.
the syntax is pretty standard, it just takes a few minutes for your brain to adjust to the new format. "field i: int;" and "public int i;" are identical, all that matters is that the language is consistent with its syntax.

what it offers is 'less' which means less ways to write unsafe code. C# offers less than C++ but it pays off down the line when you're not spaghetti pointing between vast swaths of addresses and silently leaking memory. the lower the level of programming the more you as a programmer have to dedicate in brainpower to writing code that doesn't silently break 10,000 lines later. bosque is basically just taking away the freedom to write complex and unsafe code. it feels counterintuitive for a language to purposefully fight against the programmer but its a million times better than a language that lets the programmer fight themself
« Last Edit: April 20, 2019, 01:19:12 PM by PhantOS »



with everything being immutable, i can see issues with having to update many locations at once

currently if you have a single listener with functionality to do something like push a GUI, but can call it from 10 different menus, you can change which GUI is being displayed by changing values in that listener
with it being immutable, you'd have to keep a list of which objects need to be changed when you change the listener? but then you'll probably also need to change whatever is relying on those as well, so that they're updated to use the new correct object

holy duck that sounds painful

i definitely support some things being immutable, but not everything
i think i prefer creating things to be immutable if i want them to be