TypeScript of course. The compiler often times catches mistakes in variable names, API methods, whatever. So it saves time by not having to run the whole application all the time. Also the input help is much better, when the editor knows sth is a string or a number, for example.
I absolutely do. Spreading the idea that news sites are all propaganda and the only entities involved in this kind of practice is, in itself, propaganda.
Infowars tells you Nazis are something you disagree with? Haven’t heard from them in a while. Would have thought they’d quietly drop the Nazis are evil thing.
I wouldn’t say JavaScript is horrible, it’s a fine little language to do general things in if you know JS well. I would say, though, that it is not a great language. Give me F# and I’m happy forever. I do not like typescript that much more than JS.
The only thing JS really has going for it is ease of execution, since any browser can run your code… though the ubiquity of Python is closing that gap.
There are a lot of gatcha moments in JS with weird behavior that makes it really easy to shoot yourself in the foot. It does get better as you get more experience but a lot of the oddities probably shouldn’t have existed to begin with. For what it was originally intended for (adding light scripting to websites) it’s fine but it very quickly gets out of hand the more you try to scale it up to larger codebases. TypeScript helps a little bit but the existence (and common usage) of ‘any’ has the potential to completely ruin any type safety guarantees TypeScript is intended to provide.
That’s true but at the same time the fact that JavaScript equality is so broken that they needed a === operator is exactly the problem I’m talking about.
And those examples were low hanging fruit but there are a million other ways JavaScript just makes it easy to write buggy code that doesn’t scale because the JavaScript abstraction hides everything that’s actually going on.
For example, all of the list abstractions (map, filter, reduce, etc.) will copy the array to a new list every time you chain them. Doing something like .filter(condition).map(to new value) will copy the list twice and iterate over each new list separately. In most other languages (Java, C#, Rust, Go, etc.) the list abstractions are done over some sort of iterator or stream before being converted back into a list so that the copy only has to be done once. This makes using list abstractions pretty slow in JavaScript, especially when you have to chain multiple of them.
Another simple but really annoying thing that I’ve seen cause a lot of bugs - Array.sort will convert everything into strings and then sort if you don’t give it a comparison function. Yes, even with a list of numbers. [ -2, -1, 1, 2, 10 ] will become [ -1, -2, 1, 10, 2 ] when you sort it unless you pass in a function. But if you’re looking over code you wrote to check it, seeing a list.sort() won’t necessarily stand out to most people as looking incorrect, but the behavior doesn’t match what most people would assume.
All this is also without even getting started on the million JS frameworks and libraries which make it really easy to have vendor lock-in and version lock-in at the same time because upgrading or switching packages frequently requires a lot of changes unless you’re specifically isolating libraries to be useful (see any UI package x, and then the additional version x-react or x-angular)
For example, all of the list abstractions (map, filter, reduce, etc.) will copy the array to a new list every time you chain them.
This methods were added to generator recently. So you can avoid copying the array in memory.
All this is also without even getting started on the million JS frameworks and libraries which make it really easy to have vendor lock-in and version lock-in at the same time
In my opinion, it’s also what make JS good. There a package for almost everything.
That’s fair. I was mostly commenting on my own experiences with JS/TS, I’ve never used PHP so I can’t say if it’s better or worse but a few people I know have said that modern PHP is actually pretty good for personal projects. I’m guessing it would have its own set of nightmares if it was scaled to an enterprise level though.
To its credit JavaScript has made quite a few improvements to the underlying structure since 2016. JS is one of the most used languages because it is fast to adapt to changing environments along with wide support.
It is not a safe language by any means, it can be easy to fall down holes of unwarranted expectations. Like any language once understanding limitations will open up its power and potential.
Back when I was still doing JS stuff, switching to TS was so good for the developer experience. Yeah, there’s still JS jank, and types are not validated at runtime, which was a pain in the backend (pun intended), but still I much prefer it to vanilla JS
Just an FYI, Windows likely just moved your files from users[username] to users[username]\OneDrive instead. When OneDrive sets itself up, it basically grabs all of the relevant folders and moves them into a single “OneDrive” folder. Not a huge issue if you’re setting up the PC for the first time. But if you’ve been using the PC for a while, it’ll break everything because now all of your local files have moved and none of your systems are pointing at the right location anymore. For instance, your desktop is likely black because your image file got moved into that OneDrive folder.
There’s a lint rule that looks for @nocommit in all modified files. It shows a lint error in dev and in our code review / build system, and commits that contain @nocommit anywhere are completely blocked from being merged.
(the code in the lint rule does something like “@no”+“commit” to avoid triggering itself)
Neat idea. This could be refined by adding a git hook that runs (rip)grep on the entire codebase and fails if anything is found upon commit may accomplish a similar result and stop the code from being committed entirely. Requires a bit more setup work on de developers end, though.
Would a git hook block you from committing it locally, or would it just run on the server side?
I’m not sure how our one at work is implemented, but we can actually commit @nocommit files in our local repo, and push them into the code review system. We just can’t merge any changes that contain it.
It’s used for common workflows like creating new database entities. During development, the ORM system creates a dev database on a test DB cluster and automatically points the code to it with a @nocommit comment above it. When the code is approved, the new schema is pushed to prod and the code is updated to point to the real DB.
Also, the codebase is way too large for something like ripgrep to search the whole codebase in a reasonable time, which is why it only searches the commit diffs themselves.
At my workplace, we use the string @nocommit to designate code that shouldn’t be checked in
That approach seems useful but it wouldn’t have prevented the PyPI incident OP links to: the access token was temporarily entered in a .py python source file, but it was not committed to git. The leak was via https://docs.python.org/3/tutorial/modules.html#compiled-python-files which made it into a published docker build.
Not just for credentials, there are many times where I change a setting or whatever and just put “//TODO: remember to set it back to ‘…’ before commiting”. I forget to change it back 99% of the time.
PRs? Isn’t the point of @nocommit that something does not get committed, and therefore no credentials are stored in the git repository? Even if the PR does not get merged, the file is still stored as a hit object and can be restored.
I mean, presumably there’s a microcontroller in this radio. For programming that, your only real mainstream choices are C, C++ and Rust, since you can’t have a language runtime without a filesystem.
But yeah, it’s neither the case that Rust is overwhelmingly popular for that (C/C++ do stick around still), nor is it the only discipline where Rust shines.
Like all sayings, there is context for moving fast and breaking things.
The saying means that when creating something new for profit, don’t worry too much about trying to figure out all the details beforehand and figure it out as you go. This will inevitably cause things to break, but being able to quickly fix that when it happens is the same skills needed to create new features as you go.
The saying does not work with large and complex established systems where breaking things wreak havoc.
It also feels like they chase the “break things” part as if not breaking stuff is a bad thing, and like we should be proud of them for releasing broken and poorly tested updates.
Move fast, break things, fix the broken things, push update/product whatever. They keep forgetting the third step.
Like the startups that ‘disrupt’ the established system by ignoring laws and breaking the parts that worked and selling it like an improvement.
‘Ride sharing’ (unregulated cabs) was only cheaper because of investor funding allowing them to undercut on pricing, abusing the concept of contract workers, and the companies ignoring laws. That isn’t ‘disruptive’ by being innovative, that is cheating the system.
And that’s exactly it. Capitalism rewards having money and how you get it isn’t important. It doesn’t breed technological innovation but it sure as shit pumps out new, fun ways to spew propoganda and avoid laws! And oh boy is paying employees well not even close to a metric by which to measure a successful company.
It’s the least people clever in the room having the volume to make sure that no one smarter than them can speak and then claiming they’re geniuses when only their idea gets through.
I think there is another aspect that is important: limit the blast radius. Shit inevitably happens when you create something new and complex, and when it does, you’d rather minimise the impact where possible.
Or at least a sorta-wealthy family, and the further “foresight” to be in the exact right place at the right time.
That’s the background of most of the Western ultra-rich, just as a consequence of there being vastly more sorta-wealthy families than already ultra-rich ones. Some of them are bound to stumble into situations that add a digit or two to their net worth. For an example, Elon Musk is notable for being tangentially involved in a huge success like three times, despite being a well-known moron.
One project I worked on had 10 different languages. That was rough. But even your basic full stack web application is usually 5 languages: SQL, a backend language, HTML, CSS and JS. Usually some wheel reinventing frameworks thrown in for good measure. 5 languages is light these days.
I work in Java, Golang, Python, with Helm, CircleCI, bash scripts, Makefiles, Terraform, and Terragrunt for testing and deployment. There are other teams handling the C++ and SQL (plus whatever dark magic QA uses).
Define your terms before relying on platitudes. Mutability isn’t cleaner if we want composition, particularly in the face of concurrency. Being idiomatic isn’t good or bad, but patterned; not all patterns are universally desirable. The only one which stands up to scrutiny is efficiency, which leads to the cult of performance-at-all-costs if one is not thoughtful.
I agree somewhat, but I’d also say any codebase needs some level of “dogmatic” standard (ideally enforced via tooling). Otherwise you still end up with bad, messy code (I’d even say messier, as you don’t even get consistency)
I’d agree with the first half, but not the second. Sometimes mutability allows for more concise code, although in most cases it’s better to not mutate at all
I think the general idea would be to take the original const, and create a new const with the new location applied. Destroy the original when it’s no longer needed or scoped. State maintained through parameters passed to the move function e.g. move(original const, new location) -> new const object instead of stateful members in the object like move(mutable, new location) -> updated mutable.
Random example, imagine a variable that holds the time of the last time the user moved the mouse. Or in a game holding the current selected target of the player. Or the players gold amount. Or its level. Or health. Or current position.
Keeping state managed. The data for the function will be very predictable. This is especially important when it comes to multithreading. You can’t have a race condition where two things update the same data when they never update it that way at all.
Rather than me coming up with an elaborate and contrived example, I suggest giving a language like Elixir a try. It tends to force you into thinking in terms of immutability. Bit of a learning curve if you’re not used to it, but it just takes practice.
I’d say this example doesn’t fully show off what immutable data can do–it tends to help as things scale up to much larger code–but here’s how I might do it in JS.
<span style="color:#323232;"><btn mobile big>
</span><span style="color:#323232;"><btn desktop small solid my-class>
</span><span style="color:#323232;"><btn medium>
</span>
Notice that JavaScript has a bit of the immutability idea built in here. The Array.flat() returns a new array with flattened elements. That means we can chain the call to Array.join( " " ). The classes array is never modified, and we could keep using it as it was. Unfortunately, JavaScript doesn’t always do that; push() and pop() modify the array in place.
This particular example would show off its power a little more if there wasn’t that initial btn class always there. Then you would end up with a leading space in your example, but handling it as an array this way avoids the problem.
Very interesting. Actually the part you mention about there being an initial ‘btn’ class is a good point. Using arrays and joining would be nice for that. I wish more people would chime in. Because between our two examples, I think mine is more readable. But yours would probably scale better. I also wonder about the performance implications of creating arrays. But that might be negligible.
The app working isn’t good enough, it needs to be maintainable. From a professional perspective, unmaintainable code is useless code.
Code that mutates everywhere is generally harder to reason about and therefore harder to maintain, so just don’t do it (unless there’s literally no other practical way, but genuinely these are very rare cases)
Fair play, I guess we’re probably just gonna disagree.
In my experience I’d say mutable code (larger than anything other than toy examples) always results in more time spent fixing bugs down the line, predominantly because it’s objectively harder for humans to reason about multiple one to many relationships rather than multiple one to one relationships. I’d say because you need to think about all possible states of the set of mutable variables in your code in order to completely understand it (and I don’t just mean understanding the intended purpose of the code, I mean understanding everything that code is capable of doing), that usually results in a more convoluted implementation than the pretty linear way you typically read functional code.
Longer code is practically always better if it’s easier to understand than the shorter alternative. Software engineers aren’t employed to play code golf, they’re employed to write maintainable software. Though I’ll say ultra high performance applications might be the exception here—but 99% of engineers aren’t doing anything like that.
I’m always happy to be convinced otherwise, but I’ve never seen a convincing argument
Not OP but many Linux project I follow, since they don’t have many resources, publish their releases through Torrent, a seeebox is fairly cheap (something like €10 a month) and could be easily crowdfunded even for a small project, and isn’t a huge expense anyway. And the site could just be a static page, or better yet the magnet link could be aviable on Github for people that want the precompliled binaries instead of the source.
Same thing that’s wrong with oatmeal: Nothing, that’s just not what it’s for.
Github and tools like it are designed for codebase versioning. It’s a great tool for developers who have a need to collaborate with others and manage releases/branches. But, it’s really not great for distributing executable apps to end users because it’s not for that. You shouldn’t tell end users to clone a git repo and type make install, because that’s not normally how people manage software.
If possible, the app should be packaged and in a software repository/app store typical of the platform. Chocalatey on Windows (Microsoft has their own Windows Store, but fuck that), Brew on MacOS…if we’re talking about an end-user application for Linux, I’d recommend Flatpak because it’s become the de facto one to rule them all; if you really must host something on your own website right next to a windows .exe I will say go with appimage.
You can get hosting for distributing end user apps, Github has a service called Github Pages for this purpose, for example. But especially in the Linux world, too many creators of little things like to just point you at their git repo and only accept user feedback in the form of pull requests.
“I went to the farmer’s market but they didn’t sell me a complete meal, only all these fucking plants. They think everyone’s a cook, and expect to know cooking, but i’m not and I don’t. Make a fucking meal and give it to me! Stupid fucking smelly farmers” – that’s how that sounds
The point, which you missed, is that going to github, a source code hosting service, to look for downloading executables for your specific platform - is like going to a farmer’s market to try and get a ready made meal. You’re at the wrong place, and it’s not meant for you if that’s what you’re looking for.
Github is fairly user friendly, but it’s users are developers.
I’m a developer and I hardly ever compile shit for my personal computer from source. I’d rather use a package manager, sure, but on Windows that’s by far the exception to the rule and if you want regular users to use your app, it needs to be a downloadable EXE.
This. Building a random app from source and tracking down its many dependencies is a massive pain in the ass, doubly so on Windows where you have to jump through a ridiculous number of hoops just to install a C compiler.
But when consumers get in contact with Github - and they do get in contact at some point - it is to download executables, since a good number of consumer-facing software which isnt on an app store does simply release their executables on github. That twists people’s understanding of what the platform is.
I mean, there is at least one, it’s called the releases page. Maybe what you want to eat hasn’t been prepared there, though. That’s not because they don’t realise people can’t all cook, but because they haven’t done it yet.
Not really, no. There’s a releases section where the developer can upload an exe for example but it’s really not easy to tell that that’s where you need to go if you just want to use the program/script, etc and you’re not a tech savvy person.
To strain your metaphor, I think what most people are looking for is a sign that says “FOOD COURT THIS WAY ->”
If they just had a prominent link to “download latest stable version” in a consistent place, people wouldn’t be so confused (and devs wouldn’t have to do extra work to try and make it obvious).
The specific repo in question had (and still has) a USAGE section.
And again, I have to point out that it is a python script, not an executable - it’s not standard, common or expected that python scripts be provided as a standalone executable. What makes you think even if there was a download link the guy would have gone down to find it?
Metaphors aside, the guy who originally posted this literally went on a source code-hosting website that primarily aims at making source sharing easier, yelling that he didn’t want to see said source-code, only an executable for a product that literally does not compile to an executable, did not bother reading the instructions, but instead posted on a public forum, in full arrogance, insulting developers by calling them “SMELLY NERDS”.
I’m astounded that there’s still people defending this guy like that’s a totally normal thing to do.
If you only want to download an executable, GitHub is NOT the best place to look for that. Yes, many developers do provide compiled versions of their code, and yes, it is often very convenient that they do so - but it is neither the intended purpose of GitHub, nor is it required that developers provide one.
But a lot of developers do do exactly that. They not only distribute binaries on their github, it is the only place where they distribute binaries. Github should probably recognize that it is a common use case and accommodate it better.
I’m also sure that a lot of people, like myself, took no notice of what specific package this user was complaining about, and are simply agreeing with the general sentiment that github could make things easier for non-technical users (which would, in turn, make it easier for developers since they would not need to field questions from users about how they download the software).
It’s more like going to a restaurant expecting them to make a recipe but instead they tell you to select this random list of things and then they cook it (like US Mongolian bbq places).
If you know what you’re doing you get a good meal. If not? Ketchup on rice.
just go to the releases? yes it’s slightly hidden but that’s because github isn’t supposed to be a way to publish release files, it’s supposed to be a place to host and collaborate on source code.
but so long as the developer handles releases correctly it’s just like 2 clicks to download an executable file…
Yeah seriously, I don’t understand why Github can’t just have a dedicated download button. Instead you have to dig through the Readme to find it and it’s in a different place every time.
programmer_humor
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.