Programming thread

[CEO of Pickles]

Posting for posterity and it can be used as a resource.
I have taken the fortunes from random.txt and compiled them into an actual fortune file, which delimits its entries with lines containing only a single %.

I have taken the liberty of reformatting it from HTML to TXT (removing text effects, urls, images).
As a result, I removed the neckbeard emoji and the Phil Harel fortune is now just Harel.
Let me know if some other heroic time waster updates this file to mirror random.txt as that updates.

 

[macrodegenerate]

The thing is that as your app gets more and more complicated and you start growing a user base, the limiting factor in improving your app is going to be scalability. This applies both in making an app that can support millions of users, and having a codebase that can support multiple teams touching the same files and building new features concurrently. The complexity of your app also increases, which you use js libraries to help handle. This is why just using DOM isn't good enough. Without js libraries, the website we have at my job would not be possible to make. It would have to be hacked together with a bunch of random js scripts and no one would want to work on such a piece of shit. If you were looking for jobs and didn't know react, you could probably only work on maintaining legacy systems.

The usage of Vanilla JS alone is perfectly fine for creating scalable code. In 2020, the web component standard became widely adopted allowing for the usage of encapsulated components with state that can import js libraries. This makes react obsolete as its purpose is now available in vanilla js. The global state tracking used in the react/redux stack could just as easily be implemented using a combination of element interactions, promises and element IDs/selectors as accessors to state values of fields.
At the end of the day, on any team there will be people who write shitty unmaintainable code if they can. Altering the language and enforcing standards via a framework is a solution to mediate the issue of scaling as a result of a lack of skill or effort. The problem is that the skill/effort gap is still there and inevitably will resurface when your team develops anti-patterns in response to it, and the restrictions put in place to help you will trap you in them. I've seen in happen on teams and it's not pretty.

 

[wtfNeedSignUp]

The `std::function` template is basically a type-erasing wrapper for an arbitrary function pointer, function object, or lambda that satisfies a specified signature.

std function is something that once you get comfortable with, really makes life as developer easy and is surprisingly harder to fuck up than it looks like.

 

[SIMIΔN]

When you combine discord with programming and janitors, this is expected.
Hazem just joined as well.

 

[Whatevermancer]

The usage of Vanilla JS alone is perfectly fine for creating scalable code. In 2020, the web component standard became widely adopted allowing for the usage of encapsulated components with state that can import js libraries. This makes react obsolete as its purpose is now available in vanilla js. The global state tracking used in the react/redux stack could just as easily be implemented using a combination of element interactions, promises and element IDs/selectors as accessors to state values of fields.
At the end of the day, on any team there will be people who write shitty unmaintainable code if they can. Altering the language and enforcing standards via a framework is a solution to mediate the issue of scaling as a result of a lack of skill or effort. The problem is that the skill/effort gap is still there and inevitably will resurface when your team develops anti-patterns in response to it, and the restrictions put in place to help you will trap you in them. I've seen in happen on teams and it's not pretty.

I think web components have some limitations that make them less convenient to use than React, e.g: you're only able to pass strings as attributes, if you want to pass function/object, you'll have to put it into some globally accessible context instead.

 

[glow]

I think web components have some limitations that make them less convenient to use than React, e.g: you're only able to pass strings as attributes, if you want to pass function/object, you'll have to put it into some globally accessible context instead.

Yes, the web component API seems quite low level. I think you would use it to optimise the internals of React or Angular or some kind of custom internal framework, but I don't think you would use it to directly build your front-end.

 

[Null]

https://github.com/jaw-sh/stream-nexus/

Would anyone know how to use a nodejs publishing module like webpack or browsify to simply the creation of UserScripts?

 

[Whatevermancer]

https://github.com/jaw-sh/stream-nexus/

Would anyone know how to use a nodejs publishing module like webpack or browsify to simply the creation of UserScripts?

Do you want to compile multiple JS modules into a single file? I'd assume it's no different for user scripts than with regular scripts.
For browserify that was something like

browserify <path to main js file> -o <path to output file>

But I haven't used browserify in 6 years, it could've changed a lot since then.

 

[Null]

yeah basically I want to restructure it so that it's a single user-mod that works on all targeted sites but has branching logic depending on URL, though I would like the JS itself to be modern JS and managed by webpack or something so it's easier to write, preferably with inheritance so that editing it isn't such a huge pita.

 

[Estate]

https://github.com/jaw-sh/stream-nexus/

Would anyone know how to use a nodejs publishing module like webpack or browsify to simply the creation of UserScripts?

Assuming I understood your problem, let me give it a crack.

Let's go with the following folder structure.


Add "webpack-merge" as another dependency package.

Your <webpack.config> should look something like this

const { merge } = require('webpack-merge');

module.exports = function(config) {
  let CONFIG = { // default config if nothing is passed from CLI
    environment: (config && config.environment) ? config.environment : 'dev',
  };

  return merge({
    entry: {
      polyfill: [
        path.resolve(path.join(process.cwd(), 'src/polyfills.js')) // this is only relevant if you plan to use polyfills
      ],
      app: [
        path.resolve(path.join(process.cwd(), 'src/main.js'))
      ]
    },
    output: {
      path: path.join(process.cwd(), 'dist'),
      filename: '[name].js',
      chunkFilename: '[chunkhash].[name].js'
    },
  }, require('./webpack/' + CONFIG.environment)(CONFIG))
}

Your <package.json> should have a script that looks like this

"scripts": {
  "build:dev": "webpack --config tools/webpack.config",
  "build:prod": "webpack --config tools/webpack.config --env.environment=prod",
},

And one of those files (i.e prod/test/dev) from the webpack folder should look like this

const path = require('path');

module.exports = (config) => {
  return {
    entry: {
      app: [
        // add here whatever you want for that particular build, be it different files or libraries
       // what you'll add here, will be added on top of what's already in the common file, for the app entry
      ]
    }
  }
}

Basically, you have a common webpack configuration, then you have different files with very specific configs, and those files get merged with the common one, using the webpack-merge library and specific command args passed to your scripts.

 

[teriyakiburns]

I've spent too long working with typescript and shit. I think it might be making me legitimately retarded. I'm considering running out a library or two in another language, for a project I'm consulting on, mostly for kicks (but also because it might be beneficial to have in the future, ifwhen we decide to migrate to something more robust). What I can't decide is whether to go with go, rust, or the dark horse candidate swift. It'd help if I could get an idea of which one generates the most complaints.

Or hell, maybe I'll just go back to cpp, even though I've barely touched it since university. What could go wrong?

 

[DiggieSmalls]

I've spent too long working with typescript and shit. I think it might be making me legitimately retarded. I'm considering running out a library or two in another language, for a project I'm consulting on, mostly for kicks (but also because it might be beneficial to have in the future, ifwhen we decide to migrate to something more robust). What I can't decide is whether to go with go, rust, or the dark horse candidate swift. It'd help if I could get an idea of which one generates the most complaints.

Or hell, maybe I'll just go back to cpp, even though I've barely touched it since university. What could go wrong?

I hate the rust community. But i love the language. The tooling is top notch, traits are cool. When i write something and it compiles, it normally works as intended. I like it so much i really dislike other languages. But thats just me.

 

[Harambe]

Hitting my first wall of comprehension and execution in my intro CS course in python, feel dumb for not being able to figure out how to make these two functions work together. One function takes a list of codes, and outputs a tuple of price and item name. The next function compares it to a budget, but with a special flag enabled it can ignore budget and try to find another item that is affordable, but gives up after two tries. No matter what I do my list is coming up one value short, because of some bizarre problem in the test code where the last item it can't afford gets appended to the output list, but I can't get my code to behave that way, and keep coming up a value short.

After that, I have to figure out how to take that list of values from the budget function and append each item in that list to a list of lists representing a calendar, so the output will tell me what I can afford on what day, and if I run out of money, it will append that to each day in the calendar list.

If anyone is interested in helping it'd be pretty cool, otherwise I'll wait for the TAs next week and tackle it again.

 

[Peenix]

Do you have the actual problem description or some code to share?

 

[Scale Smerch]

I've spent too long working with typescript and shit. I think it might be making me legitimately retarded. I'm considering running out a library or two in another language, for a project I'm consulting on, mostly for kicks (but also because it might be beneficial to have in the future, ifwhen we decide to migrate to something more robust). What I can't decide is whether to go with go, rust, or the dark horse candidate swift. It'd help if I could get an idea of which one generates the most complaints.

Really depends on what you're trying to do, but from a pure complaint (or proselytization) standpoint definitely Rust; Go and Swift bitching is equally divided based on whether you love or hate Apple. I'm biased towards Go because I work with it more and like its approach to multithreading, but Swift makes a lot of sense if you intend on living in Apple's ecosystem.

 

[The Ugly One]

std function is something that once you get comfortable with, really makes life as developer easy and is surprisingly harder to fuck up than it looks like.

...and here comes std:opyable_function, because God forbid they fix the const-correctness in std::function in a way that isn't insane.

 

[306h4Ge5eJUJ]

...and here comes std:opyable_function, because God forbid they fix the const-correctness in std::function in a way that isn't insane.

By C++35, I expect them to have parameterized every type and function in the stdlib with an int specifying the version number. The committee is the worst thing that ever happened to C++.

 

[Rusty Metal Skull Gun]

...and here comes std:opyable_function, because God forbid they fix the const-correctness in std::function in a way that isn't insane.

If you're in a situation where you can use templates, using the std::invocable concept instead is pretty comfy.

 

[y a t s]

yeah basically I want to restructure it so that it's a single user-mod that works on all targeted sites but has branching logic depending on URL, though I would like the JS itself to be modern JS and managed by webpack or something so it's easier to write, preferably with inheritance so that editing it isn't such a huge pita.

This sounds like a simple browser extension in form and function, which is what I was getting at on github. A WebExtension is basically a manifest file that handles the branching logic and loads specified content scripts for all urls matching specified patterns. After that, the JS itself can basically remain the exact same. Content scripts in a given extension share the same environment/namespace, so you can do modular setups by calling functions in a generic script that get implemented in a different site-specific script that is loaded in parallel. In my opinion, userscripts bring more dependencies and seem unnecessarily convoluted here when there's a very flexible unified API built right into the browsers.

 

[The Ugly One]

If you're in a situation where you can use templates, using the std::invocable concept instead is pretty comfy.

I'm switching to F77, fuck this gay earth.