7
jestdotty
43d

the irony appears to be that JavaScript is more consistent than rust

so let's say you want to create some enums to represent some potential values in a REST JSON payload

well you can implement Display trait but that won't determine the JSON output
you can make a as_str() method and that doesn't even make sense frankly, I guess it's not even a trait even though it's everywhere in the std library? (traits being rust's version of interfaces, so you'd think they should be consistent)

I have a halfway urge to say rust was a beloved language but then the foundations' drama made everyone escape the ship, leaving behind a mess

well evidently the answer is you use the stupid annotations:
enum Lang {
#[serde(rename = "en-US")]
EnUS,
}
well then this only works in serialization with serde. way to go.

how about if I have some JSON data that starts with numbers? I have an interval field in the REST that expects things like 1m, 15m denoting time scale
well no deal
because rust doesn't want enums starting with numbers

and here I thought rust was superior with its static typing. but I am having to rename things all the way down and nothing is consistent. this would be so trivial in JavaScript. and there's only one toString() method! and no interfaces people say you should use while nobody uses them!

Comments
  • 1
    🍿🍿🍿
  • 2
    I knew rust isn't as good as devs make it out to be
  • 6
    Rust is merely an extension of every bad thing about C++, save for fool-proofing memory.

    Frankenstein syntax, overly-diarrheic verbosity, fucking turtle ass compile speeds, obnoxious mass circlejerk community, etc.

    And then you get to type *more* to do the exact same things, which is to be expected at a lower level, except I can build better abstraction with shellscript ductape and a few fucking assembler macros. God, I wish I was just kidding.

    After over 60 years of jacking off, it's become clear that language designers can't come up with anything to conclusively solve the dilemmas of abstraction, and as retribution for their crimes we have been granted the divine right to joyfully drill into their buttholes with unparalleled savagery.

    My apologies, I forgot what my point was.
  • 2
    first and foremost: JavaScript does not have enums.

    An enum starting with numbers is simply an array. If you want the "m"s aswell, use a HashMap. It's really not that hard.

    The display trait is for what it says on the tin: displaying your stuff. JSON is not even mentioned in the docs. You create your own function like as_json(), because that shows the intent to actually give you the JSON representation. Even better, make a trait out of it.

    however: the thing with the foundation is a huge problem, and i hate the rust foundation too, that doesn't invalidate how i feel about rust though.
  • 1
    @Liebranca instead of bitching about it, how about getting shit done with it instead. That's something i feel a lot of poeple do, instead of actually getting to their goal, people start using languages by forcing all their bells and whistles of a language, that you don't even need. They start building exotic constructs of shit, where simplicity would shine.

    If you for example only care about the data of a json, you don't need to do any bullshit like mapping shit to a struct, just use the damn json crate. i know you would do that in js. if you want to map data to structs use bincode or ron.

    I have pivoted from C++ to Rust, because i'm tired of debugging invalid memory shit, race conditions, ownership bullshit, constructor (and default constructor) bullshit including their convoluted rules in when is being executed what, non exaustive enums, and more. since I don't deal with this anymore, i actually make progress in the software i work on.
  • 2
    I'm actually legitimately considering just writing my own language because everything is so garbage. who needs another goddamned language though. at least it would be consistent though.
  • 1
    @jestdotty if you don't want intent, please stop using rust then. It's just not a language for you.

    Do something else. Come back in a few years and try again.
  • 2
    @jestdotty no do like it, but you sound like you misunderstood the very principles of software development, a language like rust just is not suitable for you.

    I don't mean it in a negative way, but there's no point in forcing to learn something, if you already have a negative bias to it, because you either don't see how shit relates to js, or how people talk about it. It's fundamentally a different language is what you need to understand.

    Every single time i give you advice, you choose to ignore it, or do whatever. I even offered you to speak on discord, which you also refused.
    you always keep talking about stuff, that's not entirely correct or just not true at all.

    Idk, you mentioned making your own language, go make that. Maybe it's better than rust, who knows.

    Join some Rust related discord, people actually want to help you there. Bevy discord is nice

    Try Zig, C++, or even Python, to understand how the dev world thinks. Then maybe come back, you will look at things differently.
  • 3
    People don‘t believe me when I say that long term exposure to JS leads to permanent brain damage.
  • 1
    @jestdotty Consider that writing a language is quintessentially the ultimate middle finger to everyone, by itself and merely for fuck's sake, it is truly a most honorable deed.

    I say do it. Even if you just wind up copying brainfuck because life is short, it's still well worth it. Get the experience. AND the bragging rights.

    @thebiochemic I take a fat fucking shit on Rust's whore ass mouth for having terrible, needlessly complicated syntax that somehow manages to be even worse than whatever crack cocaine the C++ comittee smokes on a daily basis.

    If the logical conclusion was just accept a language for being a failed abortion then we'd all learn COBOL for job security and shut the fuck up about it until the end of time, which hasn't happened so I rest my case.

    If you like holding hands with the compiler that's fine, you can have it be your helicopter mommy *without* making the language more complicated than it needs to be or building a community of touchy fuckwads around it.
  • 0
    @thebiochemic I hereby apologize for calling you a fuckwad. ;>
  • 1
    @Liebranca
    @jestdotty

    how unprofessional, of both of you.
  • 1
    @jestdotty
    i also just checked, and i didn't find comments targeting you about the discord thing, i think it was somebody else. It's quite hard to keep track sometimes.

    So apologies for that.

    However i mentioned you atleast twice talking about intent in software development and specifically rust. This language wouldn't exist, if there would be no need for being intentional. That's why you cant overload functions for example.

    And since you and @Liebranca became personal, let me tell you that i have over 15 years of industry experience and _every single_ project, that failed was partly due to bad written code or missing documentation. So i might have a very different perception, of what a good way of doing things is.

    The other thing for improving a language by criticizing is correct. But the people criticizing it usually have one thing in common. They know the language well enough, to make educated guesses about it.

    The thing with react: it is the most popular framework, no?
  • 1
    @Liebranca can you give me an example, how rust is so much worse than C++?

    so far i only heard you throw random insults, but no substance to it
  • 0
    @jestdotty where did you even got that junior thing from? I literally said, maybe this language is not for you, and you might enjoy something else, and then come back. I didn't say that you're bad at developing in general. You're propbably the better JS dev person anyways.

    But since you got personal twice now, and things you said in other threads, makes me believe you're not even a dev at all. I even expected you to jab on my experience, maybe youre the kid here..

    i can also give you the same argument, that JS is artificially boosted because of the web, so that goes both ways.

    Like me or not, i don't give a shit.
  • 1
    @thebiochemic This is a prime example, actually: https://github.com/TheBiochemic/...

    I mean, taking the bait much?

    Compare that to the worst piece of C++ I have, there's bound to be some downright illegible template shit laying around so you can take your time. Don't worry, I'll wait, you can go cherry pick the most disgusting bits if you like.

    And if even then you still can't see how Rust does nothing to simplify syntax but rather adds further complexity to it, then I'm sorry but those 15 years you speak of were spent in perpetual masturbation, waiting for Rust programs to compile, rather than useful labor.

    I fucking hate C++. Yet it *is* the simpler language of the two, Lord have mercy. And that's what I originally pointed out; no more, no less.

    But perhaps you were indeed a fuckwad after all.
  • 0
    @Liebranca i don't see bait. It's not the best code, i probably would've done it differently nowadays, and i really don't like how i designed some UI stuff in the tool anyways, but since i threw it together within a week or two, as a learning rust project, it's not too bad.

    And no, I won't look up your stuff for sake of some random argument. I'm not that much of a degenerate.

    But since we're here, i want to ask you, what's so unreadable about it?

    Every function is clearly documented, there are no overloaded functions; so when i call get_type_name you know it's the internally used name.

    Sure i could've used lambda shit for loops, but i don't see how that's any less readable than C++ or even js for that matter.

    The mutexes i use are the std ones, and they work exactly as a Guard in C++.
    I can probably write it cleaner and for example with parking_lot, but i was too lazy.

    And then accessor functions while implementing a trait, so no crime here.

    Matches are a thing to get used to.
  • 0
    C++ is simpler to initially write a piece of software sure. But have you ever tried to change some stuff after like a year?

    For me that's a big "No thanks"
  • 0
    ah.. and the best part of your provided example is, since i'm not using a concept of pointers, or NULL for that matter, you as a non rust programmer don't need to worry about it randomly crashing, when modifying shit. I see this as a big win.
  • 1
    @jestdotty makes it possible for you learn from my mistakes now ;)

    as i said, you can avoid a lot of headaches, by just using the json crate. It's what it's for. But hey, you're such a great dev, you probably knew that, before i even mentioned it. As a matter of fact, you know every crate, but just don't use it, to not make us mortals uncomfortable.

    keep living in your little bubble. Nobody can hurt you there πŸ‘
  • 0
    coming back to the original question, what speaks against just doing an enum with Months(u8) etc.? It's more readable anyways.
  • 1
    @jestdotty so basically you're trying to communicate with a rest api, that takes a json with members starting with numbers?

    where's that consistent? Since when can members start with a number in js? Js literally needs the first character to literally identify, if it's a name or a value.

    I guess you didn't make it clear enough, or it just didn't occur to me that you don't have a choice, how to send stuff and don't want to reimplement a whole lot of shit.

    Given the circumstances your solution with the rename(...) is already good enough. And i don't see anything wrong with it really. Another solution would be to serialize it yourself, and you definitely don't want to do that, since it's annoying to deal with serde itself.

    You can ofcourse avoid it altogether with streams similar to how you'd implement and deal with the display trait, but that depends on how complex the json is, you want to get out. That would be the best and probably most future proof way, but less readable though.
  • 1
    @jestdotty youre saying it's bad design, while you pretend that a dictionary is an enum.

    What the actual fuck..

    It was a bait post after all.
  • 1
    @thebiochemic I guess that for a JS dev, there is no difference between an enum and a dictionary, or even an object.
  • 0
    @jestdotty I agree. Have you read this?
    https://graydon2.dreamwidth.org/307...

    This is the rust I wish we had and we almost got it
  • 0
    @jestdotty bruh🀣
    you're the one who says "this would be so easy in Javascript" while in the same sentence you describe a feature from TypeScript.

    this is no javascript. And was the reason why i told you to go learn something else first. Learning rust as someone who never has touched Programming before is fine. Learning rust for someone, who's coming from Systems languages is fine. Learning rust as a js dev is probably not a good idea, as demonstrated by you multiple rltimes on this platform now.

    I say this, because i actually stopped messing around with rust for a few years and came back to it.

    But this doesn't matter, because it's about you. And only you, since youre the all knowing js dev here. And the world needs to bow to your feet.

    I'm not the one who's spazzing here.
  • 0
    I’m new to coding. After reading up a bit on different languages to make up my mind about which one I should pick up learning, I had come to the conclusion that rust was far better than JavaScript.
    But now I read this and I’m confused. According to you, one can get the same amount of work done with with much less code written in Java script than in Rust.

    I was pumped about getting into coding, but it now seems like there are unending debates about what’s best or worst. You think you’re working with the right tool. Next thing you know,it’s not the right tool because there’s something better/ more adapted. So you pick to that tool until someone else walks by and says there’s an even better and more adapted tool. It never ends
  • 0
    @fumey it depends on what you want to do. There is no programming language, that is good for everything. And there never will be.

    rust and js are fundamentally different languages.
  • 1
    @thebiochemic I get there’s no programming language that’s good at everything.
    But it seems that even for a specific job noone agrees on what the right tool is.
    At the end of the day, it’s all about personal preference. One likes less verbose, the other prefers more verbose. One likes vanilla, the other prefers framework. One likes loose typing, the other prefers strict typing. Everyone’s got valid arguments for what they prefer.

    People love to demolish jQuery but apparently there are so many platforms that rely on it. People say it’s deprecated, but in reality a new version was just published
    I initially had good vibes about IT people. Now I feel it’s like everything else. It’s all about people’s egos
  • 2
    @fumey yes, it's a circle yerk everywhere. I mean.. that's literally why devrant exists lol.

    the best for you would be to just choose something, and don't shoot against anyone else. That's the best course of action always. Doesn't matter if you like to learn TypeScript, Python, C#, C/C++, Java, PHP or anything else.

    Shooting against people in the fashion of A is better than B, because of nativity, habit or lack of knowledge is exactly the kind of thing that breeds trouble, almost without exception.

    You should definitely immediately get rid of the notion, that you learned Tool A, and use it for everything now akin to the saying "Everything looks like a Nail, when the only tool you have is a Hammer". Just.. don't
  • 1
    @jestdotty you could run a js interpreter and launch from the command line. Then you wouldn't have changes unless you upgrade the interpreter.

    I like Python for testing things out fast.
  • 1
    @thebiochemic @fumey @jestdotty
    Couldn’t disagree more.
    You know that languages are not people, right? They don‘t have feelings which can be hurt if you criticize them.
    Why do people get so upset about discussions about languages?

    Languages ARE very different, it’s not comparable to subjective things like your favorite color. We can talk about problems or benefits of languages in an objective way.
    There are some subjective things like the syntax but most things are quite objective.

    I say this because it sounds like you guys are suggesting that all languages are practically the same and it’s all about the little things which are a matter of preference.
    And this is simply wrong.
  • 1
    @Lensflare So what you're saying is, no hard feelings if we all agree to shit on Swift?
  • 2
    @Lensflare for instance: ML and other forms of AI are being a done a lot in Python. So in the future a Terminator style robot might view Python as some sort of AI god.
  • 0
    @Liebranca no hard feelings as long as your criticism isn‘t a stupid reason like

    "Because its from Apple"
    "Because you insulted my favorite language"
  • 1
    @Lensflare I’m not suggesting anything. I’m just observing how people argue over languages, each person acting like they hold absolute truth.
    I’m new to coding so what do I know?
    I’m told JavaScript is the language of browsers. Oh but it’s also trash! So how else are you supposed to code a website? Use jQuery! Well that’s trash as well and it’s deprecated! Well v3 was recently published. Yeah but it’s still trash.
    Gosh seriously guys, it’s like you can never come to a consensus
  • 0
    @fumey "JavaScript is the language of browsers"

    goats don't know how to javascript.
  • 0
    @fumey and that‘s also one of the reasons why languages are not just preference. Sometimes you don‘t have much of a choice.

    In your case, I suggest to use TypeScript. It is quite popular and it makes JS a little bit less shit.
    That is if you really want to be a masochist and go into web development.
  • 1
    @Lensflare Alright then, let me read the manual real quick...

    Oh, 'let', 'var' and type annotations. Fucking delightful. Because CLEARLY (keyw name (?<:type)? (?<=value)? \n) is simpler than (type spec* name (?<=value)? ;).

    Errors on unsigned set to negative? Fucking shit, so there *is* people who only ever underflow by accident, I thought that was just a myth. No wonder we have to neuter every language for these assholes to get anything done without setting shit on fire, idiots can't even work with binary.

    Can't sum ints of different widths? That makes sense in assembler, not so much at a high-level with inference and training wheels. If you've anotated the width of the destination, then it should zero extend; explicitly casting is just redundant bullshit in such cases.

    I'm running out of characters, so I give it a 6/10 for now; overall, I get the impression of a bland, lame ass safety blanket-type language.

    Also I can't tell it apart from JavaScript.
  • 2
    @thebiochemic if you've an array and bitwise ops thou shall have enums unless thy art in mediocriland

    @Liebranca ok, I'ma be honest here, that code smells, specially line 159's scope, @thebiochemic, it's been 2d since @Liebranca's doxed it, either clean it or stop defending it o.O

    @jestdotty yup, that's about how it went with me thou at the end I wasn't grieving, I was raging. I mean, Green Threads, we could've gotten green Fucking THREADS! For fuck sakes that would've given me a fuckton of ways to fix my recursion issues with Rust. And optional lifetimes? Maaaaaan, ok, that one was a downer

    on writing another language, I haven't gone thru all of it, but mastering Rust macros might just be what your heart desires
  • 0
    @kobenz please read the README.md to that project. Since i know you wouldn't and nobody else will, i'm gonna post the relevant snippet here.

    If you want you can make a PR yourself lol, or atleast create an issue then.

    I know you wouldn't
  • 1
    @Liebranca what‘s your point? You just read something about what you are unfamiliar with for 5 minutes and then awkwardly tried to criticize some random things about it. Good job? Do you expect me to be offended or should I just cringe?
  • 2
    @Lensflare I think I am kinda dumb when it comes to languages. Unless the code is really ugly I just kinda learn how to do something and not worry about syntax quirks. Except Lua data structures. Those feel painful to me.
  • 0
    @Lensflare Oh! So you're *not* cool with me shitting on Swift. Glad we could clear that up, honey.
  • 1
    @Liebranca If it would be something that honestly bothers you with Swift, we could discuss it in a professional manner.
    But instead of this, you just desperately try to prove that I am bothered by your pathetic attempt of criticism, so I won’t waste any energy try to argue about it.
  • 1
    @Lensflare not that all these little details are related to code that I've written, it's not like I study compilers or anything. Oh wait...

    "me professional ur postz so pathethics and desperate" spare me bitch. I'm RANTING.
  • 0
    @Liebranca that makes your statements even more pathetic then. You are ranting about what again?
  • 0
    @Lensflare C'mon sweetheart, I know it's hard on you, but you *do* know how to read! ;>
  • 0
    @Liebranca says the one, who didn't bother to read a Readme file.
  • 2
    @thebiochemic You asked for an example of Rust syntax being more complex than C++, so I gave you your own code and asked that you compare it to the crappiest of my own files you could find.

    To my knowledge, you still haven't fulfilled your end of the bargain, and until you do, I'm not taking you seriously.
  • 0
    @jestdotty why is consensus lame? Imagine we all wrote our own languages. We wouldn’t get anything done
  • 0
    @jestdotty why is consensus lame? Imagine we all wrote our own languages. We wouldn’t get anything done
  • 3
    @fumey you know, there's LLVM nowadays, we could have our own languages and still get shit done
  • 2
    @Liebranca you don't even have anything remotely complex in your repos that would warant a comparison.
    Haven't even seen a single mutex in your stuff.

    But let's go break some Guarantees with:
    https://github.com/Liebranca/...

    You're using ELEM_DEFAULT, etc. like enum values.. where's the enum? What happens if you need to add a new value?
    do you want to go through each file by hand and check for switch cases, that have the missing case?

    What about invalid values? Nobody knows if that used value is valid or not.

    Let's go to the source:
    https://github.com/Liebranca/...

    What's with a?b:c; What's that supposed to mean?

    all the m_... stuff. C++ hiding this, why? oh so it's so YOU know that's it actually belongs to the struct.

    member methods being called with this->etc() so the this is mandatory now? no consistency, fuels confusion.

    also why do you use this in the constructor?

    This shit's not even complex, but a mess already.
  • 2
    @fumey consensus is used to strongarm people into agreement in modern era

    it isn't that everyone hears all ideas and has an opinion that one idea is better and therefore become in consensus with that idea, naturally

    rather it is something modern humans are coerced into following, for the merits of "consensus is good"

    consensus, like many other things, is only good if people voluntarily want to be there consenting to the census in the first place. the benefits are mostly tied to that (other than signalling)

    what makes something lame to me is when people put in the veneer of something to look like it but don't understand why that thing was good in its original, naturally emergent form. it loses its animating spirit. they break down something beautiful into reductive nonsense and think correlation means causation instead of gaining true understanding of something. that makes it cheap at first then lame once it becomes ubiquitous... consensus
  • 0
    @jestdotty frankly, i don't care how you feel about me.
  • 0
    @jestdotty come on... everybody's doing it. Need a shared value system in the first place. Causes division otherwise.
  • 1
    @jestdotty yes, and everyone's insides have been on public display the last 4 years. Find out who is a douche and who isn't really fast.
  • 1
    @thebiochemic Good sport!

    Valid concerns on the panel element state flags. Now that I think about it, it's dumb of me to have made them public, as those should only be used internally! Good catch, I should totally fix that.

    You mean one-letter vars are vague? I can see your point. I try to use shorthands that relate to the variable's type, and as I've grown comfortable with a lot of them, I've neglected documenting them. That's my bad.

    The "m_" prefix is a pretty dumb standard, absolutely. And there *is* a loss of consistency because I'm then using "this" when calling methods! The style is fool of stupid, that much is true.

    But my code being simple? That's a good thing! ;>

    And even my shittiest C++ dumpster fire being much simpler was, if you recall, my entire point: that I'd much rather deal with the mess that I have -- and indeed it is a mess! -- than the ones you have to put up with.

    Like, just compare *one* function signature. You'll see what I mean ;>
  • 0
    @Liebranca that might be. But that's like saying, that this:

    struct Bla {

    member: u8

    }

    impl Bla {

    is_zero(&self) -> bool {

    self.member == 0

    }

    }

    is simpler than this:

    class A

    {

    public:

    A():val(0);

    ~A();

    int getVal(void);

    static void cbMethodA();

    static void cbMethodB();

    private:

    Mutex m_mutex;

    int val;

    }

    int A::getVal(){

    {

    int returnVal = 0;

    lockMutex(m_mutex);

    returnVal = m_val;

    unlock(mutex);

    return returnVal;

    }

    void A::cbMethodA(void *ptr)

    {

    A* ptr = static_cast<A*> (ptr);

    lockMutex(ptr->m_mutex);

    int tempVal = ptr->m_val;

    unlockMutex(ptr->m_mutex);

    }

    void A::cbMethodB(void *ptr)

    {

    A* ptr = static_cast<A*> (ptr);

    int tempVal = ptr->getVal();

    }

    which is completely missing the point. And you know that.
  • 1
    @thebiochemic I didn't have the differing nature of the projects in mind honestly, but I'll humor you.

    The bits you linked build on top of the other repos: it's one giant codebase split into modules, which I've been working on for a long time, for my own use, as opposed to a short span for learning purposes.

    So it is a very unfair comparison by every metric: two weeks of work versus four or five years. I have no right to judge your code too harshly, and I don't think I have, besides mentioning the signatures just now.

    You pointed at the lack of mutexes in my code. Fair enough. I could point at your lack of a 3D renderer, GLSL preprocessor, custom build system, FFI bindings generator, etc. I haven't, and I won't, because that would also be unfair.

    I picked that one file solely because I felt it illustrated Rust being as messy as C++, while also showing some of it's thicker syntax; what it was doing didn't really matter.

    And I don't think it's bad either ;>
  • 0
    @Liebranca I guess it was somewhat communication issue then. So fair enough.

    I mean sure, the syntax is a bit more verbose in systems languages than in python or js. And i agree on rust being slightly more verbose than the C Family. But it arguably depends and is not a simple question to answer at all.

    The thing is, once you understand the clutter in rust, you'll find it not only useful, but necessary. You get a lot of guarantees for free and can focus on important things.

    For me it felt weird to look through your code for example, and to actually not know, what lives for how long, and is owned by who, or if it lives on the heap or stack. Or seeing all the numbers, that represent god knows what.

    However, i personally prefer the file structure of C++ Projects. Having headers, that contain the API Docs and the source files.

    I'm still surprised, that you pulled out some random example without matching C++ code.

    But at this point i guess it doesn't matter anymore
  • 1
    @thebiochemic Verbosity is the core tradeoff for having higher contol over the computation; more code is just to be expected.

    But I started to take issue with a lot of languages when I realized how much smaller I could make assembler code with a few macros and a preprocessor; I simply cannot unsee it. Anything "above" assembler that doesn't give me the same ease when programming just gets on my nerves.

    Headers, now that you mention them, is one of the things I'm simply leaving to code generation nowadays, for the low cost of discriminating between public and private symbols and dependencies directly in the source. It's just easier having *less* code to maintain.

    Which circles back to enforcing via toolchain as opposed to trusting the programmer, which does align with my reasoning here to some degree. Some things are better left handled implicitly, rather than through a special notation. Less cluttler is *generally* better.

    Wait, I'm going to need another comment...
  • 1
    @thebiochemic It's a question of what needs to be on my mind as I work, to which less is generally better.

    Ideally, one should have as much verbosity as is needed, but only when specificity is needed. This is not an idea strange to systems languages, the point is in how it's implemented.

    Additional information should be there if it matters; the code is also for us to read, not just the compiler. So there's a fine balance to strike: easier for a human to process, but convenient for tools to analyze the code and generate output.

    Tying lifetime to scope, for instance, requires no additional notation. "Clutter", as you call it, could be useful when the object *outlives* the scope in which it was created, plus the one before it, and beyond.

    But this shouldn't be the norm: much better to simply reserve memory when you need it for a task, carry it out, and then release that memory. When you stray from that, *then* get specific.

    I could go on, but I'll end it here for now. ;>
  • 0
    @Liebranca isn't what you describe pretty much, what rust does?
    If the lifetimes can be inferred, you don't need them. If the type can be inferred, you don't need to write it down, similar to auto in C++. If generic parameters can be inferred, they disappear aswell. When they become important is when you write it down, as per suggestion of the compiler, or just redesign so it doesn't need it.

    The stuff is not on my mind per say since let's face it, nowadays IDEs much like the toolchains you use, help you immensely to focus on important things.

    The other thing is sure, with assembler you have control. But you only have control in one dialect. So if you want to deploy software you need to keep the different Arch Types in Mind (im actually not sure if Intel vs AT&T matters here). What about the different RISC Variants as opposed to x86_64? Like ARM and apples M Chips? What about WASM?

    Do you really want to write your stuff for all of these, if you intend to deploy to multiple systems?
  • 1
    @thebiochemic If only it had better syntax...

    I don't use an IDE, we just do everything with our own build system and commandline tools. It's much better this way, I honestly prefer the terminal.

    You can translate between instruction sets, I wouldn't call it trivial, but it's not too bad either. But that would be assuming I actually need portability, and mostly I don't.
  • 0
    @jestdotty you can’t debunk the concept of consensus by describing the opposite of what consensus truly is. Consensus requires humility and involves concessions. If you take you also have to be willing to give (aka to give credit to others' opinions). There's no true consensus if people are being strong armed into accepting something. If that’s what you've experienced, then it wasn't a true consensual process and you shouldn’t discredit the concept of consensus just because you had a bad experience.
    I believe endeavors that are truly worth it and that have strong impact are built upon consensus.
    I’m sure writing your own language will be a great experience for you and you’ll learn a lot in the process. Or you could join in a community effort to make something OK even better. I hear anybody can submit ideas to EcmaScript’s TC39 committee to bring improvements to the language. The learning experience may be just as rich and you’ll even make friends in the process
  • 0
    @jestdotty seems like you clenched to the part where I talked about humility and nothing else. If you don’t like the word "humility", perhaps you can call it "biting the bullet".
    Also, I’m not defending the idea of self cannibalism, I’m simply talking about working with others without plowing through them to reach your goals, which unfortunately is what today’s culture encourages and what you seem to be fully buying into.
    I do my best surround myself with people that I can work with in a healthy way, those who may have differing views but who are smart enough to agree to a middle ground.
    I steer clear of those who want to make me think we’re working toward the same goals but who in reality are IN it for themselves and no one else: that’s the individual you seem to be describing.
  • 0
    @jestdotty I’m sorry if I went overboard. Apologies for the slander πŸ˜…

    I don’t understand the connection with the other rant where the person talks about being a "menance". Did he mean menace? Or is menance some sort of programming concept or something else?

    Anyway, I think we got side tracked from the original conversation, which was about coding languages.
    I will say this: If you do end up writing your own language, maybe I can be an early adopter.
    I’m still new to coding but am eager to learn new coding language. Even more so if the language was written by someone I know 🀭
  • 2
    @fumey now is the best momento to write yourself your own language then, you'll pick up new languages very fast after doing it.

    edit:

    Try this one: https://norvig.com/lispy.html
  • 0
    @kobenz but I’m new to coding. It may be too early for me to write a language of my own
  • 0
    @fumey you do not sound like someone who enjoys it, else you'd have visited the link and read the post and wouldn't be saying that.
  • 0
    @kobenz but I did open the link.
  • 0
    @fumey then why do you think it'd be your language? It's a copy-paste tutorial
  • 0
    @kobenz I opened the link on my iPhone but it’s not responsive so I’ll have to take the time to check it out once I find a computer
  • 0
    @kobenz thanks for sharing by the way
  • 0
    @jestdotty
    Who are you to say I’m not excited? I’m trying to learn three languages at the same time (jQuery, JavaScript and css). I’m having a lot of fun doing it although some of the algorithmic stuff like loops and whatnot are quite a challenge and give me headaches.
    @kobenz sorry I don’t feel quite ready to delve into writing my own language. Again, who are you to say I’m not enjoying the journey I’ve embarked on? Did you start learning how to code directly with writing your own language??
  • 1
    you must be trolling, jQuery's not a language, @fumey
  • 2
    crap, CSS is now a language, isn't it...
  • 1
    @jestdotty i mean at the end of the day it's a styling language describing presentation. But yeah i agree, it's not a programmjng language per say. Making it turing complete would be undesirable anyways.
  • 1
    @thebiochemic being turing complete doesn’t make it a programming language. Maybe technically it does. But it would mean that a turing machine would be a programming language. And JS too.
  • 0
  • 0
  • 2
    @fumey technically correct barrage 🀣

    except it's not even technically correct 😝

    also I was making a lighthearted joke. laugh, idk
  • 1
    @fumey both articles are wrong.
  • 1
    @fumey jesh, man, you're embarrassing yourself, git gud
  • 2
    @Lensflare @kobenz you guys are right. It says it right there on the jQuery documentation page: "jQuery is a fast, small, and feature-rich JavaScript library" 🀦🏼‍♂️
Add Comment