For windows: Sublime
For linux tty: Vim

VSCode is a bloated piece of shit which can't open a folder without rebooting the whole window. It's only nice next to the rest of the bloated shit out there.

  • 6
    How it handles opening folders is indeed pretty annoying (also forcing you to close all yet unsaved editor tabs) but apart from that it's pretty awesome. Without a doubt the best text editor in existence that will even do as an IDE in a pinch
  • 3
    With the right extensions, I can turn VSCode from a heavy text editor into a lightweight IDE. So that's the main reason why I use it.
  • 0
    @12bitfloat IDEs are an unnecessary layer of GUI abstraction from what goes down there. Sources are sources! >Math_is_math.png
  • 0
    @EmberQuill On less than 5 years ago hardware maybe it works smoothly (less than 10 years if you're from the first world), but simply using it as a code editor was painful for me. Zero plugins. Only higlighting the syntax. Still lagged. Come oooon!
  • 2
    @OneOfSimpleMind lolwat
    I don't enjoy wasting time on unnecessary grunt work. I couldn't live without a call stack, type hierarchy, context-based refactoring, etc.

    Hell, the only reason I use Eclipse over IntelliJ for Java is because things like "Open return type" take one single button click less. Productivity is sacred, man
  • 0
    @12bitfloat Dude you blinded by them fancy tools. Makefile + gdb is all you need. And if using a tool for refactoring saves you more than a minute it means the codebase is out of control. IDEs hide code smells!
    The one thing you need is a nice recursive sed command on a clean .sh to rename identifiers occasionally and voilá.
  • 1
    @OneOfSimpleMind I don't mean refactoring as in refactoring code but stuff like renaming types, moving types to different modules and the like.
    Don't worry about my architecture I'm glad if I can program anything because I'm the biggest perfectionist. My codebase is just fine

    I have seen the light of good tooling, I can never go back. If anything you might need an upgrade :D
  • 1
    @OneOfSimpleMind Also, don't take this the wrong way but Make is one big, outdated, ugly abomination that I never want to see again. C and C++ toolchains and their ecosystem in general are so bad, I'm glad I found Rust. Such a nice language and such a nice toolchain. Ahh, just thinking about it makes me happy
  • 1
    @12bitfloat Don't worry man, I argue only for sport so you can say yell your opinions like they're the ultimate truth no problem.
    Back to it though, Rust is like C++ and I hate them both. They screw up their syntax horribly and fill everything with implicit calls and overloading hiding who knows what clusterfuck of vtables and call stacks filled with longass namespaces with little underscores and numbers behind them so you gasp a little and forget everything you think you knew about what goes on down there.
    C is the sexiest language alive.
    Simple as fuck.
    Memory is memory. Everything is a variable and that's it. If you use an operator it's only doing one thing. If you loop through something you know where the iterator is defined and incremented. Calls are made only when you make a damn call. EXPLICITLY. It's the most honest shit I've ever used only second to assembly in that regard and the MOST portable one in the universe.
    Thanks for reminding me how much in love I was with C. :)
  • 2
    @OneOfSimpleMind I can somewhat understand your love for C. It's simplicity really does have it's appeal. But I wouldn't call it a "good" language. It's soooo unsophisticated, unsafe, boilerplate heavy and just not good looking

    No modules, no generics, bad preprocessor, seperate header files, forward declarations, no private visibility to speak of, purely procedural (not to say that OO is better, but procedural with methods aka OO without polymorphism like in Rust is certainly better), barebones std lib that isn't even good, wonky portability, no standardized collections, no exceptions (yes, I do like exceptions), horrible dependency management, enum variants have their names in the global namespace (like why lol), super unsafe memory management due to lack of standard primitives (smart pointers, or whathaveyou), no interfaces or traits to allow for some sort of abstraction, and so on
  • 1
    @12bitfloat I consider most of the lack of features you mentioned alluring though I'll give you a point regarding the preprocessor. Sometimes I find myself wanting a bit more than what it offers.
    BUT all those restrictions and boilerplate code don't make the code look ugly. From wannabe perfectionist to perfectionist, the C language is as ugly as you make it to be. I have seen macro-less C code so beautifully written it looked like libc had standard collection and dictionary types.
    Struct initializers really save C ass in eye-candyness.
    I was told I need an update before too.
    But honestly, I'm tired of updates.
    I crave simplicity dammit.
  • 1
    @OneOfSimpleMind Hey, you do you. I personally find the lack of features more annoying than anything. It's the same reason I don't like JavaScript or other dynamically typed languages. The supposed simplicity quickly crumbles under any real task because programming just isn't simple. By making a language simpler than it should be what happens is actually the opposite: It becomes *more* complex as the programmers now have the burden of picking up the scraps and implementing (and keeping track of!) the needed features themselves.
    I've seen so many half-baked polymorphism and smart pointer implementations in C. The unreal engine kinda has it's own OO stuff for entities so each entity class is riddled with boilerplate, etc.

    Sometimes you have to embrace the complexity in order to truly do something simple
  • 1
    @OneOfSimpleMind Here's a little taste of the awesomeness that is Rust (please don't mind the dumb implementation of the average using a vector, it's just for illustration purposes lol)
  • 1
    @12bitfloat Yeah in the pragmatic real world today we depend on that complexity you described.
    Can't help but dislike it.
    One day I'll make everyone C. :P
    Thanks for not leaving me mid rant btw. It always feels sad when a big unanswered comment is the last thing in the thread.
  • 1
    @12bitfloat Wow what is that Ok(())?
    And what is |e| ok() in the filter?
    Also what is going on in the fold lambda.
    Looks pretty compact but I probably need Rust to get all that?
    I know the basics of functional programming (filter, fold got them) but the specific syntax is boggling me.
  • 1
    @OneOfSimpleMind The `Ok(())` constructs an Ok variant value of the Result enum. It's in the prelude (imported by default) that's why it's not `Result::Ok(())` or even `std::result::Result::Ok(())`. Result is basically either Ok(T) with a generic value T, or Err(E) with an error value. The value in this case is (), the unit type, bascially void, thus Ok(()).
    Leaving off a semicolon acts kinda like a return. In this case it returns from the function with that value, but you can also do stuff like `let a = if true {2*2} else {0};`

    map_filter is cool as it both maps and filters an iterator, in this case a Lines iter. It's generic over the previous iterator so it takes a Result<T> (Result<String> as returned from the Lines iter) and returns an Option<U> which tells it whether to filter the value out (`None`) or keep it (`Some(U)`). Result::ok() is neat in this case as it already gives an Option<T> only if the Result was Ok(T), so we effectively filter out all bad (Err) lines
  • 1
    @OneOfSimpleMind The fold for the average calculation (`|acc, x| *x as f64 / total as f64`) is a bit messy but it takes the accumulator (initialized to 0f64) and the next element x, then dereferences x (as it's an &u32 -- a reference) casts it to f64 and divides by the total, also cast.

    Another cool thing is that this is super efficient.
    In the number parsing part, at no point does it have to allocate a buffer to cache the elements. lines() returns an iterator over lines, filter_map produces another iterator and that is then consumed by the for each loop. So the file is parsed completely incrementally without having to buffer multiple elements/lines
  • 1
    @12bitfloat Thanks but daaamn son this is brutal. Can't dig it like this, sorry. Maybe some day I'll give in.
  • 1
    @OneOfSimpleMind I'll be waiting on the other side. Let me know when you're ready :D
Add Comment