#dc comics#batman#dc#dick grayson#bruce wayne#dc fanart#tim drake#batfam#batfamily
seen from United States
seen from France
seen from Singapore
seen from United States
seen from United States
seen from United States
seen from United States
seen from Poland
seen from United States
seen from United States
seen from United States
seen from Malaysia
seen from Lithuania
seen from Poland
seen from United States
seen from China
seen from United States
seen from Romania
seen from United States
seen from China
Arrival Language
here you can see a language which has been clearly created to be more abstract to the human idea of language. It isn't on a solitary medium, and it also isn't permanent. Also the use of what is essentially a bodily excrement to create a neograph is really unique and not something I've seen before. I could end up using this in my language in the future
The fact that there exists a Rust source file which
contains something function-like being invoked called "try_call!", but
no definion or explicit import of that identifier, and
searching for
rust "try_call!"
on a couple search engines does not readily find a search result documenting what the hell "try_call!" does...
...necessarily means someone somewhere has done something unacceptably wrong. This is not a situation which should ever happen with a mature or widely used programming language.
Conlangs
A conlang is a constructed language, or a language in which that a person (likely an author) creates a language using linguistic analysis and understanding of the human psyche and communication.
There are often 3 parts to a language that need to be considered in conlangs;
Spoken Language
Written Language
Communal language
Spoken language is how the language is used to communicate between speakers vocally, things that often impact this are tonality and emphasis.
Written language is how the language is written down, in english we write uniform letters left to right in straight lines, whereas in other languages you might write up to down, or right to left, or you might even write in spirals. You can even dodge letters all together, but it is reasonably difficult to make a writing system that avoids repetition.
Communal language is how language changes in community, like for example english has evolved due to slang and simplifiers. For example; the word okay comes from the term all correct, and in some twist of the word it became Oal Korrect, then being shortened to OK. This shows evolution in language, and really cements a language in world and makes it feel real.
꒦ˎˊ˗ ︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶ ꒦꒷꒦₊˚
In Humanity I will be making 3 unique languages at least, one for each continent outside of the blank continent, however I may do some more, making some country based dialects or languages with same base sounds.
There are environmental factors you need to take into accout as well however, for example a conlang that i made before was for a desert civilisation where the rock around was too tough to carve, so the only written language they had was small spirals that would convey simple words before they were washed away by the winds. And so they were mostly spoken word.
You can then consider punctuation; will your language's written language even have punctuation? Or will it have punctuation for niche concepts like assertiveness and doubt.
꒦ˎˊ˗ ︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶ ꒦꒷꒦₊˚
As a newbie to conlangs, I first went to the Conlang Creation Society Website which then spurred me on to the Conlangers Library, which taught me some Conlang terms that will be important for this breif;
Artlang - Directly means artistic language, which is a language made mostly for fictional media or aesthetic reasons.
Natlangs - Natural languages, languages that are spoken in real life, or commonly in countries.
Babel text - Genesis 11:1-9, to my understanding, this is a text that is translated by most Conlangers. This allows for artists to understand each others works. Usually used as a test drive for conlangs and understanding.
Glossopoeia - The action of creating a conlang. A Glossopoeist is a Conlanger.
Neography - Meaning New Writing, it is the action of making a writing system for a conlang.
꒦ˎˊ˗ ︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶︶ ꒦꒷꒦₊˚
How to make a Conlang
In this I will be following the Conlanging 101 guide by tabby!
First, the question of purpose, this is obvious for me, as I will be making these for my animated series. However I will be doing this for fun also, so that will be how I treat this!
Second, Examples; I think before I find examples I will first need to find out what the landscape of the area is, the first continent I will be doing this with is going to be the music continent. So Im thinking of making the music continent mainly inhabited near jungle, and due to this I might make this continent directly inspired by Africa in terms of landscape and geology. Due to the Sahara desert being in close proximity to jungles.
Due to the geography of the area being humid and arid, the sand will be a large part of the belief system of some of the peoples of this continent, likely being one of 2 gods in a bitheist religion.
The way this language is going to have come about is likely through people mimicing the creatures of the jungle's calls, harmonious and unique, and so the language should likely be tonal and maybe melodious in its usage. Possibly using a metronomic bird or creature to keep plosives on beat
＼／＼／＼／＼／＼／＼／＼／＼／＼／＼／＼／＼／＼／＼／＼／＼
Language Examples (With Colour!)
Basque
Basque sounds very rhythmic and nice to the ear, the plosives are like small breaks from a song, I could use this to make a more fast paced variant of the language, the vowels are weighted very "A" heavy, which makes the language feel slightly more regal to me for some reason.
Igbo
Igbo has a nice feeling to it, with its plosives and nasals weighted the same it feels quite polite and welcoming. With emphasis on the glides, it feels far more open ended, which is a quality I enjoy.
Korean
The Korean language has very nicely weighted vowels, that are very nicely placed, the ends of words are also very vowel heavy, with Os and As, which make it sound very sharp with Ss and SHs
German
German has a large emphasis on the CHs (like in the word loch) as well as in the alveolar sounds in the language. This makes it sound quite harsh, however also oddly soothing, and with some of the opened letters it feels very comforting to me.
Na'Vi
This is a Conlang made for avatar with a 1000 word dictionary and speakers all around the world. This shows the prowess of the conlangs, something I might take from this is the creation of new word structure being ejectives (small stops before the end letter), creating new structure and word ideas is something I greatly enjoy doing, and so that is likely what I will take the most enjoyment in doing.
／＼／＼／＼／＼／＼／＼／＼／＼／＼／＼／＼／＼／＼／＼／＼／
Creating the sounds for my language!
For this part, I will be starting with the consonants, as they are the primary starting point for many conlangs, if you want to understand the IPA (international phonetic alphabet) here is a really informative video by TheLingSpace!
And here is the IPA wikipedia so you can listen to some sounds for your leisure!
There is a small question I need to think about in my language, do I want to avoid voiced or voiceless consonants, as I was planning on having all plosives be said on beats of a metronome, so there would be no need for the plosives to be voiced as they would need no note in terms of musicality, which is often why in musicals, they wont have a long pause for an actor to say a line (think the line "say hello~" where the o is held for about 20 seconds) on any voiceless consonants (like s or p) as they simply would never work in the context of music. But also I want there to be some voiced consonants to include in speech, so I think what ill do, is only add voiceless plosives, and every other consonant is voiced. That way when the plosives are said on the beat, all voices in the area will stop, giving the area a kind of "bump" to it. I also don't want to add very many difficult to pronounce letters like many uvular sounds, which can have notes, but in general can lead to throat issues more if you aren't used to it. Now I could add the fact they just are used to it, however; due to it hurting me, I will not be using them so I can speak this language for practice.
Here you can see I went with the plosives "p","t" and "c", as they are some of the only ones I could think that fully stop your vocality in place for air. Also, usually in making beats, humans will gravitate to Ps, Ts and Cs. I didn't note it down, however I will also be including the Glottal stop "ʔ" (which is seen as the stop in the word "UhʔOh" spelt Uh-Oh)
I also used the fricatives "v", "z" and "ʑ" as if you add a vowel after them they can easily sound nice and melodic.
Using the flap "ɾ" allows for a kind of half plosive, as it uses the same movement as a "d" but with less of a stop, kind of like a "d" with a hole in it if that makes any sense.
The usages of the nasal "ng" was so that I could add a bit of nasal to the language, seemingly very straightforward, but needed nonetheless Now, you will see this chart and think that there aren't enough consonants, thinking of english shows 21, but due to the unique way that the language is going to be spoken, these 9 should be all I need.
𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬
In terms of vowels, I was going to make the language use a bizarre one like "ɤ" but I realised that the base 5 vowels work perfectly for melody. So I will be using the vowels "a", "e", "o", "u", and "i"!
Diphthongs
Diphthongs are 2 vowels placed next to each other, now, I doubt there will be much use of diphthongs in the higher tempo areas of the region, but for the lower tempo out there; ill be adding the diphthongs "ou", "ae" and "ai"
Triphthongs
Triphthongs are 3 vowels placed together to make a single noise; like in the word "beau", in terms of this, I likely wont be using many, however I might use "eau"
𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬𐃬
Making words!
In order to make a lexicon for a language you need some root words that you can mash together to make more complex words. So I will be making 500-600 of these root words, which will overall make up the base lexicon of the language. I will be writing them in Latin characters (ʑ will be written zh, ɾ will be written r, and ʔ will be written ? ) as I will be making them into a writing system later. I should also likely make a name for this language. But I will make it after the lexicon so I can feel more of the understanding of the sounds etc.
For making adjectives, I will be using this list of these Gradable and Non-Gradable adjectives from the british council learn english page
⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢
Here you can see the way that I am formatting the dictionary.
⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢⌢
the reason why the dictionary is so important is so that words can be made through joinery of others, for example; The sound of wind is the combination of sound and air. Being Civ and Porov, so the word becoming Porciv means "woosh" in a sense.
Developer: I consent.
Language: I consent.
Isn't there somebody you forgot to ask? [Every other developer who has to read this code after you.]
What are your thoughts on Zig and the way it portrays a possible C descendant?
One of the best options in the space today.
Generally an improvement, and I tend to agree with the design decisions far more than disagree. Definitely worth looking at if you want to replace C somewhere, a more viable and likely contender for parts of C's niche than Rust, Go, D, C++, and so on.
Compile-time code, including manipulating types, all without raw text-replacing macros, is a huge yes. Safe-by-default building, with lots of nice error-catching features unless you deliberately opt-in to disable them for performance, is wise. Shorthand for propagating error returns is great. Cross-compiling as a first-class use-case that Just Works out of the box is long overdue and widely beneficial. Building on LLVM seems like the obvious best choice. The ability to compile existing C code and mix Zig with C is a really good move for increasing adoption in places with legacy C codebases.
Now for the not-so-positive:
At least once I came across a detail that reduced my confidence in the... thoroughness of design thought going into it: rejecting async "coloring" of code is probably a mistake, and since they mentioned it in a list of good things about Zig while only linking to the initial popular blog post critical of function color, I worry they might not have fully grokked that question before deciding on an answer.
Personally, I want meta-language capabilities - kinda like what Racket has. The value-add of switching from C to Zig seems worse than value-add of switching to "C with good meta language capabilities", because then there's almost no limit to what kind of improvements can be added to the language as just another library, and it's easier to implement those improvements.
From a strategy angle, it might be too early for a C challenger to be so much more complex to implement. Sure I can use Zig to compile my C codebase, but if LLVM and Zig don't support my target, then I have to add it myself or keep using C - and I'm probably not getting the time or money to do the former. (But this only matters for displacing legacy codebases.)
The way for a C challenger to always be able to stay ahead of C at all three of performance, keeping up with new hardware and OS capabilities, and portability, is to have a standard way of going lower-level than C too, not just higher-level. Imagine being able to say, in portable source code, "for that target, here is one or more machine instructions, and here is higher-level source code - you can trust that the former implements all of the defined behavior of the latter". Think of all the things an optimizing compiler can do with this! Think of how much hardware-specific and OS-specific optimization knowledge could move out of the compiler and into libraries which can update faster and independently!
The way for a C challenger to totally outclass C for systems programming is to be better at talking about all side-effects and resources. When writing security-critical system internals we need to be able to say stuff like "in this piece of code, those observable side-effects being the same regardless of inputs is a deliberate detail, not an incidental one". When writing real-time systems we need to be able to manually manage execution time and preemption like we manually manage memory. And so on.
Hyrum protection is ultimately just a type of defensive coding, but sometimes it's more indirect, because you're not limited to erroring out or coercing inputs into an acceptable state - you can also defensively manipulate your outputs and behavior to break attempts to depend on aspects you don't want depended on.
For example:
If you don't want someone to rely on the iteration order of a hashmap, you can randomize it by having the hashmap constructor initialize a random value that gets mixed into each key's hash, so that multiple test runs of the same exact code have good odds of iterating in different order.
Similarly, if you want to return multiple things in an iterator or data stream and you don't want the order to be relied on, you can efficiently randomize it without buffering the whole thing by holding back one or more elements for a random amount of iterations before randomly injecting them back in.
If you don't want someone to rely on race conditions or timing side-effects, you can add a randomized delay in the operation. In some cases you can also construct your logic or pad any data that you get so that it always takes a constant amount of time to execute for any input.
If you don't want other code to start to rely on being able to directly mutate a too conveniently accessible temporary file or memory buffer, you can grab some random bits and use it as a one-time pad or with a cypher, possibly also with a message authentication code or whatever.
Of course if you don't like the performance overheads of that, you can turn it off in explicitly safeties-off optimized production builds.
Variadic Functions in C
A Nicer Approach
So I've described the problem, and even why it maybe makes sense for that problem to exist at the low level of the language definition, but we can do better for actual humans writing C.
As of C99, we have variadic macros, and we have compound literals. This means that we can wrap variadic functions in macros that automate two common conventions for variadic functions:
pass a magic end-of-arguments value, or
pass the number of variadic parameters.
Let's take a function like `execl` for example: it takes some number of `char *`, and it expects the last one to be a null pointer. Behold:
#define EXECL(...) execl(__VA_ARGS__, (char * )0)
Boom. Problem solved. No more segfaults or stack corruptions or exploitable code execution vulnerabilities in your code just because you forgot to put a null pointer at the end, or forgot to cast it to the a pointer type with a compatible representation.
Now how do you count arguments? Well, if your arguments are all of the same type, or implicitly convertible to the same type, you can throw them into a compound literal for an array of that type and take the size of that array:
#define ARGUMENT_COUNT(type, ...) (sizeof((type[]){__VA_ARGS__}) / sizeof(type))
So then if you have a function like this:
int sum(size_t argument_count, ...)
You can wrap it like this:
#define SUM(...) sum(ARGUMENT_COUNT(int, __VA_ARGS__), __VA_ARGS__)
Same benefit: the function receives an automatically computed-at-compile-time first argument of how many parameters the wrapper macro call received. And since the stuff inside a `sizeof` operator is not evaluated - only the type of the expression is statically figured out per compile-time C rules - you don't get any of the problems with macros evaluating their arguments multiple times.
Over the last couple days I guided someone through implementing a basic "bingo" game in JavaScript, and it was a good reminder of just how much
technical knowledge,
familiarity with idioms and conventions and language that programmers use, and
trained cognition
it takes just to write any substantial software.
And more importantly, most importantly, very importantly: how unintuitive programming languages are, how much they perpetuate stuff that programmers have to be mentally broken into, that isn't obvious until you've had it explicitly explained.
Like "for" loops, the kind you find in C or Java, with two semicolons in the middle, are horrible interface design (if the goal is the best interface for humans working with higher-level concepts, rather than the best tiniest-increment improvement over previous methods for manually guiding the CPU instruction-by-instruction through an iterative loop). Python-style "for foo in bar" is much closer to reasonable. Could be even clearer if it was "for each foo in bar".
Do-while loops? Would be better if the syntax was `do ... repeat while`. Six characters could smooth the learning curve for that one construct profoundly.
More substantially than just syntax though, I have profoundly increased appreciation for the point made by Rich Hickey (creator of Clojure) that variables - places where values are stored and possibly are later overwritten, are inhuman unintuitive bullshit. He puts it more nicely than that. I appreciated this point when I first heard his talk, but it gains so much revealed wisdom when you see a programming novice think of a variable as a placeholder for code which is lazily reevaluated each time it is used rather than as holding the result of that code. I'm now convinced that it is a serious possibility that a programming language where everything is lazily evaluated and variables don't exist and mutable values don't exist isn't just easier to audit and optimize, but genuinely easier to understand and learn unless we've already had our logic severely bent to match all these programming languages which are optimized to express computer implementation details instead of human reasoning.
