To be fair, all three can probably do what you’re asking for, in building a desktop application. So the real question comes as which flavor of language do you want to write. The only language of the three I can’t speak on is Ruby, as I haven’t used it.

Python is a “scripting language”, but by that token technically so is Javascript. It’s an immensely popular language due to its simple syntax, yet complex features as you get better with it. Python can build large-ish applications: web apps, desktop apps, terminal apps, and yes also of course AI, bulk data processing, etc. For GUI applications, I’ve personally used pyqt (4? 5? 6?)

Much of the same can be said for Javascript. As you said, there are “negative opinions” about JS, but everyone has their opinions (most factually-based) on the goods and bads of languages (although, yes, JS does get more negative opinions than others). Yet, Javascript is still a widely used language, and you’ll probably end up needing learning it anyway if you decide to go into web development.

What I personally suggest is this:

• See the learn x in y minutes pages for Python, Javascript, and Ruby. Make sense of the quick-tour of the languages.
• Make a simple project using each of the three languages. Something that just reads something from STDIN, does some work, prints stuff, as an example. This helps you get to know the basics of the syntax, tooling, and quirks of a language, and helps you narrow down which language you’d like to be working further with.
• Pick one of the languages you’re leaning in favor of and go build your application. If you come to a point where you feel like the language you choose is no longer suitable for what you wanted to do, you can always retry with another language, and then you will know at least a fair part of more than one language.

When the enum reaches your JSON, it will have to be a string (as JSON does not have a dedicated “enum” type). But it at least ensures that languages parsing your JSON will should have a consistent set of strings to read.

Consider this small bit of Elm code (which you may not be an Elm dev, and thats okay, but it’s the concept that you should look to get):

-- A Directions "enum" type with four options:
-- North, East, South, West
type Directions
    = North
    | East
    | South
    | West

-- How to turn each Directions into a String
-- Which can then be encoded in JSON
directionsToString : Directions -> String
directionsToString direction =
    case direction of
        North -> "north"
        East  -> "east"
        South -> "south"
        West  -> "west"

-- "Maybe Directions" since not all strings can be parsed as a Directions.
-- The return will be "Just <something>" or "Nothing"
directionsFromString : String -> Maybe Directions
directionsFromString dirString =
    case dirString of
        "north" -> Just North
        "east"  -> Just East
        "south" -> Just South
        "west"  -> Just West
        _       -> Nothing

The two functions (directionsFromString and directionsToString) are ready to be used as part of JSON handling, to read a String from a key and turn it into a Directions enum member, or to turn a Directions to a String and insert the string to a key’s value

But all that aside, for your restructuring, and keeping with the license plate example, both type and license number could be contained in a small object. For example:

{
    ...
    "licensePlate": {
        "type": "government"    <- an enum in the language parsing this
                                   but a string in JSON
        "plateNumber": "ABC123"
        ...
    }
    ...
}

If its something that represents mutually exclusive states, like the license plates examples (Gov’t, Embassy, Learner), an enum like 4wd mentioned is a better idea than many boolean keys. This would also be the switch/case question you posed. For a “regular case”, I would include that in the enum, but if you create an enum that only contains “special cases”, you can always set it to null.

On the case of booleans, I would suggest avoiding them unless it is necessary, and truly a binary (as in, two-option, not binary numbers), self-contained-in-one-key thing (obligatory anti-boolean video). If the use case is to say what a different key’s object represents, you don’t need it (see: enums. You’ll thank yourself later if you add a third option). If the use case for using it is saying another key contains value(s), you don’t need it. Many languages can handle the idea of “data is present, or not present” (either with “truthy/falsey” behavior interpreting “data-or-null”, or “Maybe/Option” types), so often “data-or-null” can suffice instead of booleans.

I would suggest trying to always include all keys of a present object, even if it’s value is null or not applicable. It will prevent headaches later when code might try to access that key, but it isn’t present. This approach might also help you decide to reduce the quantity of keys, if they could be consolidated (as in taking booleans and converting to a state-like enum, as mentioned above), or removed (if unused and/or deprecated).

You can feign immutablility on class attributes by playing with __setattr__. I don’t remember the exact way to do it, but its roughly like this:

class YourClass:
    def __setattr__(self, name, value):
        if not hasattr(self, name):
            super().__setattr__(name, value)
       else:
            # handle as you wish if the
            # attr/value already exists.
            # pass, raise, whatever

I say “feign immutability” because there are still cases in which an attr value can change, such as:

• the underlying attribute contains a list and appending to the list
• the underlying attribute is a class and modifying the class’s attributes
• pretty much anything that does “in place” changes, because so much of python is referential and has side effects.

I say there are four categories:

• “standalones”: anything that is only described as itself. Separation just results in smaller versions of itself.
• sandwiches: organized or layered arrangements of foods. Can typically be separated into it’s composing parts.
• salads: tossed or jumbled arrangements of foods. Could be separated into its parts, albeit cumbersome.
• sauces: perfectly combined or blended arrangements of foods. Can no longer be separated into its composing parts, but differs from a standalone because it was still composed of other foods, and can still be identified or described as all of the parts.

I was using VSCode prior. VSCode works, sure, I just like the layout and flow of how I have Zed configured at the moment.

Also, preferably less Microsoft in my everything

Which plugins? I dont really care about many of them. Does the editor type my funny robot words and help me make sure the words I typed made sense for the language (aka, language servers)? Yes? Good.

Neat. I use Zed at work, but now also having it on my personal desktop will be nice. Bye, VSCode.

On my system, just one note that it didn’t render a menu bar. Not that I use it much anyway, just had to find the default keybind to open the keybinds config (btw: ctrl K |> ctrl S) and pasted what I used from work (then bulk-replaced all cmd’s with ctrl’s)

Theme change was not sticking on first launch, but second launch I guess it realized “Oh, I’m supposed to be this color now. Got it”. Ligatures don’t do, but it is a preview and that’s just an aesthetic.

Also, I take issue with the claim that OOP is all about “objects”. It’s also about classes.

Depending on the language, classes are just objects too. So its still just about objects.

Hello world should look something like this: print("Hello, World"!)

You don’t need the annotation line in Haskell-esque languages, most of the time. Without the annotation, this is Hello World in Haskell:

main = print "Hello, World!"

And when you need more complexity, it can still be far simpler than Unison (or Haskell)

import qualified Data.List as List
import Data.Function ((&))

processNumbers numbers =
    let
        isEven n = mod n 2 == 0
    in
    numbers
        & List.filter isEven
        & List.map (^2)

main =
    processNumbers [1, 2, 3, 4, 5, 6]
        & print

i starts at 0, checks if i is less than n (the first time it will be, no matter what), prints a “#”, then increments i by 1 and loops

Why does the for loop repeat after it exits to print a new line? If it exits the loop, shouldn’t it be done with it?

There’s the new line after the for loop to make sure that the next recursion starts on a fresh line. Otherwise the next recursion would print on the same line, right where it left off, and you’d just have a line of “#”'s. The for loop itself is just for printing “#”'s.

Why is n incremented and not i as stated with i++?

I think this is a confusion with the recursion. Look at the line with draw(n - 1); this happens before any printing of hashes happens, and only continues after its done. And it calls itself as long as it’s not less than or equal to 0. To psuedo-code the order of operations here:

draw 3 {
    draw 2 {
        draw 1 {
            draw 0 {};
            print "#" * 1;
        };
        print "#" * 2;
    };
    print "#" *3;
};

so n is never incremented as you think, it just calls decremented versions of the draw function before the current one finishes. The i’s are purely involved in the for loop, which only prints hashes. Does that make sense?

Although, i would agree with it not necessarily being “friendly”, since its a drastically different syntax than many beginners would be used to, the brackets and parenthesis here are not what you think they are.

Unison is a language in the style of Haskell, F#, Purescript, Elm, etc. So that first line is actually type annotations.

In Haskell, this would just be helloWorld :: IO () , meaning a function named “helloWorld” with no arguments and produces what is essentally a potentially-unsafe IO action with a Void return (the empty parenthesis () ).

Here in Unison they call the bracket part “abilities” or something. Its saying the same thing as Haskell, but being more explicit in saying it can raise an exception.

I think maybe starting with Leninism, what youre saying may be true, but not with Marxism. I think this comment explains it a bit well:

comment

So the original Marxist idea would lead to withering-away of government, and thus zero parties, not one-party authoritarianism. But due to all the authoritarian implementations, people think of states like the USSR when they hear/see communism

The problem is these people are voted in by states who comprise of residents who have brain injuries, misogynistic views, extremist ideals, and/or a myriad of other skewed thoughts.

So unfortunately we get stuck with the consequences of other state’s resident’s decisions

Well I ask these cause authoritarianism seems counterintuitive to the main philosophy around Marxism. Saying “the proletariat should have greater value and power in a business, since they’re doing the actual labor”, but then rolling over and accepting a dictatorship where the populace has no political say seems nonsensical.

Hence why I suspect the authoritarianism must have come first. So I can’t necessarily agree to “communism predisposing itself to authoritarianism” since it doesn’t make sense for a True-Marxist society to want to accept that sort of government.

As for how to set up the government in a communist-economy state: probably more of a Republic. People elect multiple representatives, and these representatives meet and decide on policies for the country and how to run it

Every major country that has ever gone down the communist road ended up a dictatorship

While I don’t think full-on Marxism is necessary and am in agreement on the democratic socialism, I think the reason for this is really more towards the political end of it than the economic.

If a country practicing a communist economy had a more representative/democratic political system from the start, I’d like to see how the results panned out. And I’d also like to see which came first, the dictatorship, or the communism. The former being first makes more sense than the latter.

Agreed. Functional languages really raised my standard for what a language could be.

Stronger typing. More functional flow. Less dumb errors.

I’ll be honest, I thought She-Hulk was alright. Was it Marvel’s best work? Not really. I think the ending was pretty… Different? Not good? A cop-out? Unsure.

It kinda feels like they just slapped together something for the sake of slapping together something, for money. If it felt like it was a bit more planned out in terms of story line, flow, and if the ending was an actual ending, then I think it’d be better rated.

Of course, the female-lead movies will have the misogynists that tank the ratings, and that’s unfortunately unavoidable. But I think some of She-Hulk’s ratings was that people were expecting a fully-fleshed-out season like their other streamables, like Daredevil, The Punisher, Wandavision. Those felt like complete, planned stories, even if meant to be supplemental to the movies. This felt different. In fact, most of the recent episodic stories feel different. Because I think they feel episodic: divided up while also trying to be a story.

I’m not sure if the portayal of She-Hulk is true to her comics. I honestly have only read a small handful of comics, so I go into the movies and shows just taking it in as it’s shown.

She-Hulk felt like they tried to slap some laughs, fourth-wall-breaking, and a variety of cameos into a sort of “what whacky adventures will Jen the Hulk Lawyer get into today?”, followed by a botched ending to wrap it all up.

Now all of that said, I did enjoy it. Except the ending, if I haven’t made that clear enough. It was nice pieces of a story. I have nothing against She-Hulk as a character, or any of the female characters. I think its great to bring a wider variety of people (sex/genders, religions, sexual orientations, etc) into the multiverse. I just think this story was not great, and I hope that botching the story and causing bad ratings as a result wasn’t an intentional act in order to say “See, people don’t want this Marvel hero.”

Haskell for sure has a very sloped learning curve. The functional style, different syntax, a myriad of symbols and pragmas, as well as the tooling around it.

The only reason I was able to pick it up as quick as I did was because I was used to Elm due to my job. Then it was just learning about the IO type (and how to use it), cabal, stack, built-in symbols, and the most common pragmas.

But the symbols part is especially harsh, since symbols only hold meaning if they’re universally understood. Sure, the base- language ones are kinda adopted at this point, so they’ll stay, but the fact that external modules can also make symbols (sometimes without actually-named counterparts) adds some confusion. Like, would you just know what .: is supposed to mean off the top of your head?