Did you give it any useful information? I mean for example, I am subscribed to a bunch of channels about music theory, and Youtube will put other videos about music theory and analysis in my feed. They are highly relevant and at least somewhat popular, so usually reasonable quality. Sometimes it will start recommending videos from a channel that is not so good, and you can tell it to never show you that channel again.
If you only watch random Youtube videos linked from other sites with no particular theme, or generic news and political videos, or don't subscribe to any channels, I can imagine the recommendations would be pretty useless. But the algorithm does seem pretty good at recommending things related to your interests if those are clear from what you watch and subscribe to. It's probably the only recommendation engine I find useful.
My point is less about the content being useful/interesting and more about being mindful of our information diet.
How many videos do you need to watch about music theory? Does it ever feel like the same content but regurgitated in different ways? Do you watch this to genuinely learn? Or is it more enjoyment/infotainment? (honest questions)
I don't study music theory, but this is how I feel about productivity/self-help/business videos, which dominate my feed. Although these videos were life changing at one point, I'm not sure how much more value I'm getting by continuing to watch these anymore. When I get to the end of these videos, nowadays, I just feel a bit 'bleh'.
It feels nice to find new, refreshing content that is completely outside of what the youtube algo would give me, and sometimes that happens by talking to friends (esp in different industries), reading books, old blog posts, etc. I want to stay curious and proactive in finding discovering new things and hobbies and interests.
I appreciate the general point of being careful about one's information diet. It's easy to fool yourself into thinking what you're consuming is bettering you, when it's really just entertainment (I consider HN to be a good example of this!)
Regarding Youtube and music education, I feel like it's a pretty healthy stream of content.
>Does it ever feel like the same content but regurgitated in different ways?
Learning an instrument is such a challenging and broad topic, there's no shortage of things to learn. One thing I like about Youtube is that the better content can surface for everyone to access. Finding a good teacher in real life can be tricky, but with Youtube I can watch 10 different people's takes on a topic and see which explanation clicks for me.
>Do you watch this to genuinely learn? Or is it more enjoyment/infotainment?
It's both. Staying motivated, interested and enthusiastic is just as important as the learning itself. Often watching a good performance or explanation of some musical idea is what makes me want to pick up my guitar in the first place. Of course there's a balance to be found - just watching videos about things you would do if you weren't so busy watching videos isn't much use.
- Fine-grained permission control that offers more than iOS: control whether apps can access the network, which directories an app can access, if it can print, and even whether or not it can access PulseAudio.
- Cross-platform: runtimes are OCI container images and can be targeted on any distro that supports Flatpak (which is almost all of them).
It's gained adoption from a number of recognizable FOSS and proprietary names: Zoom, Spotify, Steam, Firefox, VLC, Discord, Libreoffice, Skype, Inkscape, both Minecraft and Minetest, Microsoft Teams, Krita, IntelliJ IDEs (both Community and Professional), and Blender are available as Flatpaks through Flathub.
GNOME and KDE release almost all their apps as Flatpaks through the `gnome` and `kdeapps` Flatpak repos, and copy them over to Flathub when they're confident that Flatpak-ing didn't introduce any bugs.
Flatpak also clutters your hard disk with gigabytes of copied libraries and other data. I had to deinstall it to prevent a system crash, because my root partition went out of space rapidly - source of the problem: Two flatpak apps.
Isn't this the problem with iOS apps too? They can't share libs or .so between them, which is why each iOS app is colossal for no good reason, eg. Google Sheets 180MB alone, Google Docs also 180MB, YouTube 280MB..... insane sizes for these.
Similar in character, but it's probably a factor of 10 worse with Flatpak. With your examples on iOS, the bloat is stuff that's common to the google apps but not part of the platform. With flatpak, it includes stuff that is part of the platform but can't be relied on to be the right version.
It would be nice if Apple would let packages signed by the same key share versioned libraries between them, but I suspect relatively few developers would be able to take advantage of that. Maybe only google and microsoft, to a rough order of approximation.
Does its sandboxing support fake (or altered) access? That might be the additional permission control needed. For example, to grant fake access to the audio, the program will work but there will be no audio output (and all audio input will be silent); or you can specify to save audio to a file instead of making it immediately audible, or change the volume control for that program only.
Android has. (Also I assume a pile of other, no longer available/not very successful mobile OSes, but the ecosystem is just Apple and Android at the moment).
Android has far too many apps that refuse to work unless you give certain permissions. One of my banking apps needs the camera permission to work at all. The permission prompt states it's to digitally cash checks, but it asks at startup and if you deny permission the app quits immediately. Most delivery apps won't work without giving GPS permission. The iOS app store does not allow this kinda bs.
Their big feature for the next major release is a Mac version, and until then it works quite okay in wine. Probably better in Linux/Wine, as that tends to have fewer graphics bugs.
My enjoyment factor of both DungeonScrawl and DungeonDraft is a bit different, as with 'Scrawl it's awesome sketching a big event location, whereas with 'Draft I get a Bob-Ross-ian spark when adding minor details. A candle here, a floating corpse there, some cobwebs and fungi…
I can pair DungeonDraft with FoundryVTT, where you can get virtual lighting support imported from the maps. So you don't have to "paint" your walls twice, once for the pure visuals and once to see where vision and movement is blocked.
Agreed. I'm pretty sick of the anti-JS kneejerk rhetoric that happens here.
It adds zero value to any discussion. It's nothing more than a desperate attempt to gain some internet points.
It's a popular language and it has flaws, but that doesn't automatically make it worthy of the amount of hate it receives here. This type of discussion has more in common with /r/iamverysmart than it does with valuable discourse that HN used to be known for.
I do enjoy "Professor Frisby's Mostly Adequate Guide to Functional Programming", which uses JS examples extensively. Despite the fact my last job was mostly JS, I had to look up functions all the time and stretch my brain muscles. Modern JS is different than "keep it the same" JS. But... converting a book to a different programming language rubs me the wrong way. I miss an opportunity to see another language, too. It's not even some very arcane language. If it really was a knee-jerk reaction, I'd have said:
Adapting a book for another language doesn't really make you miss an opportunity, though, right? The original is still freely available for you to look at and see another language.
It's not an attempt to get internet points. It's an expression of frustration that one of the most important platforms of our time has first class support for only one language, and the only reason that language is used is because of its monopoly on the platform. Were it no for that monopoly it would rarely be used.
I'm just glad JS is as good as it is, considering it didn't have to be good. It could have been even worse and still would have succeeded due to its monopoly.
But WebAssembly was just made a new standard by W3, which, correct me if I'm wrong, will allow browsers to natively support literally any other language the developers choose.
Yes, but only if those languages do not interact with the platform (the platform being "webpages"). DOM manipulation requires JavaScript. So, it is still the case that JavaScript is the only language with first class support.
I like JavaScript despite some of its quirks and there are some annoying ones. However with the mindset to embrace JS I find it easier to work with than blindly hating it. It could be worse. You could be coding in Monkey for Garmin.
The meaning of the second paragraph was ambiguous. Aside from Javascript dislike, which I don't pretend to deny, I believe learning new things is mind-expanding.
When an intriguing movie - or book - comes out, it's often intriguing because it's quite different. When you convert it to a common language - or Hollywood - it becomes less different. Reading "Working With Legacy Code" forced me to absorb some C#, but it also allowed me an opportunity to compare it with Java, which I learned at university.
What I understand from this is that people didn't really value Python as a pseudocode language. It was just fashionable at the time. Now it's Javascript's time. I wonder what's going to be next? Golang has a chance.
I like JS. I use JS daily. JS is part of the workflow for nearly everyone I know who works with code. For me, ES6 is fantastic to use. Some of the better books on JS [I'm thinking specifically of Haverbeke's "Eloquent Javascript"] are general computing classics in their own right.
I used to be a snob about JS, due to the fact that in the 90s / early 2000s, it had major shortcomings and produced a lot of slow, crashy web pages. But when I learned modern JS, I realized that it is now a fully mature language equal to any other, and easily used in a huge variety of contexts [thanks in no small part to Node]
I have to use Javascript almost daily at work, I hate it.
Up until a year ago or so I hadn't really had to use it much, I'm finding it so bad I'm seriously looking at how I can get into an alternate career. Working with JS is a profoundly miserable experience.
Previously I was working on C# and SQL. I'm no fan of either of those, but at least with C# I can understand what the designers were thinking. Ideally I would be working in Clojure if it was up to me. Or Scala or F#.
Now it's Javascript as that is the code base our client uses. The client runs a number of production factories and have an internal web app that is mostly Javascript on the front end for monitoring these production lines.
It's made me angrily punch my desk and consider just quitting on the spot on a number of occasions.
I don't know how anyone tolerates using this day to day and doesn't want to jump off the roof. It's absolutely idiotic.
JS is a terrible language. The amount of pitfalls, language features you must avoid, and obscure paradigms you must follow to make JS usable is mind-boggling. Just because you can use JS well doesn't mean it's a good language.
While I certainly wouldn't call JS "great", I actually do genuinely like a lot of parts of it. I like the Lispey style of embedding data structures (hashmaps and arrays) directly into the language, and I like that it has somewhat popularized some functional techniques and made them mainstream.
While callbacks aren't a great way of doing continuation-passing, at least we can credit JS with making continuation-passing mainstream.
In combination with the fact that JS actually does work pretty well on both frontend and backend, it is a language I use semi-regularly for prototyping, given its flexibility. Granted, if I decide to make a "real" version of the project, I'll probably do it with a more functional language, but I think JS doesn't suck too bad.
I love it and think it's a great language. It has bad parts, but they are easy to avoid, especially with a modern linter. So there you go. You're wrong. At least one experienced developer who has coded in many languages thinks JavaScript is a great language.
Basically, you install the `typescript` package which gives you `tsc`. Then you configure Node to run your program with `tsc` through your package.json.
But I’m happy for you that you like ES6. You all own the language now, so enjoy it. Us ES5 folks are going to have to rewind and fork so we can have a community again.
I do. I love vanilla JS especially. The way it interacts with the DOM and the way JSON works makes more sense to me than most other languages, and this is coming from a python user and newly lisp user.
Not everyone has the same brain as you. People enjoy things you don't understand.
It's useful and practical and has a lot of work put into it so it can't really be called bad, but it doesn't really stack up to what native languages can provide at the high end, and never will (even if it can get pretty darn close).
Though I acknowledge its immense utility, I feel like JS always tends to go for "good enough" solutions rather than "best in class" solutions. That is its own kind of quality, but there's good reason to dislike JS for people who focus on those particular qualities in a language.
For sure, if you have a shot at making a world class system you probably don’t want JS.
But I’ve never been in a job where we had a shot at building a world class system. Maybe I just have bad luck, but at each place I have worked the problems in the codebase are obvious and the impediments are institutional not technical.
There are hundreds of problems I could list in our current codebase that are causing slowdowns, bugs, etc. None of them are because of the programming language. They are places where someone put a square peg in a round hole, where someone copied a bug over and over because they assumed the existing code was correct, where someone used a fancy feature of the programming language that made the program worse.
None of that goes away if we start using Rust.
So yes, I agree with you if you are within striking distance of making a perfect application use a nearly perfect language.
I’ve just never been in that job. I’ve always been in the “let’s fix some of this low hanging fruit, and make sensible use of the tools we have” job.
The problem is that if the system was world class then it might actually be ok if it was in js. Most codebases are a bit of a mess, like you say, and js just makes it much harder to figure out what is going on. It's not just a dynamic language, it seems to encourage a gratuitously dynamic style. So you have to figure out everything in the debugger. That is if you can even determine where to set a breakpoint!
Yeah, I actually agree with you especially for ES6. Because it requires you to transpile, and because promises/async/await break the control flow model, it is extremely difficult, often impossible to place breakpoints. With await in particular, you can forget to await a promise and then your app just stops working, mysteriously, and there’s no way to find out what’s happening except to one by one disable parts of the app until the situation becomes clear.
Transpilation as a norm means it’s kind of 50/50 whether the source code you encounter while debugging will even be readable.
Actually what I see most often, professionally, is that JavaScript developers stop believing they can inspect their application at all, and when something is wrong immediately just try to guess what’s happening. Then see if their imagined fix helps, if not try again. Basically guess and check. Which is a fine technique but it’s pretty bad if that’s your only way to debug problems.
I am able to code in ES5 sometimes on independent projects (without Webpack) and it’s a joy. The debugger works everywhere, in a consistent way. I have callbacks everywhere so asynchronous code is simple to trace and easy to understand. It’s great.
I am working slowly towards a fork of NPM/Node ecosystem that starts over before ES6. I think early JavaScript is actually a wonderful, fast, elegant language.
I would say that ES6 is so bad in terms of debuggability that you almost have to use TypeScript to make coding in ES6 bearable.
The other aspect of what you’re saying: that you have no static analysis tools so you HAVE to debug, is spot on. I think to build a great JS application you have to put an equal amount of effort into designing the test harness. Basically all the time you would have spent wrangling the type system you have to put into the tests.
And you can’t just half- ass the tests. They need to really accurately mirror your business needs, and really model the relationship between your app and your tests, in order to provide an equivalent static analysis value to what a type system would give you.
However one final point, which is that the fact that ES5 is so impoverished in terms of control flow and data modeling, I think actually helps solve all of these problems. If you limit yourselves to basically just functions and literals, you are forced to write really strong clean interfaces. I find myself being able to focus almost entirely on separation of concerns. Because I’m not dealing with fancy language features, and because I literally can’t afford to build giant complex modules and applications, it forces me to build small, simple modules that have very clear responsibilities.
That might seem like a limitation to many, but I actually find it helps me to avoid headaches before they happen.
Do you find yourself accidentally doing that often? A few of the things from the "Wat" video fall into that category. "Things no one would have ever thought to try, yet a dynamic language will fully allow". If you want to point out valid concerns with JS, the double-equal implicit coercion is a far more frightening "gotcha".
Not lexically, no, but dynamically, sure, all the time. JS lets me receive an arbitrary value in a variable `foo`, and "add" it to another arbitrary value in a variable `bar`, without having any opportunity to specify what semantics I mean by "add." Fixing the semantics of the operation is the whole point of specifying it!
Personally, I favor languages that go "almost too far" in the opposite direction, e.g. Elixir. In Elixir, operator[] (a.k.a. the Access protocol) is generic across several types, but the semantics are very strictly constrained; not only does the access have to "mean" getting some kind of element from a container, but it's also only defined where it has a fixed O(1) time-complexity.
This sort of design being conventional in Elixir, means that you can usually predict, just from the lexical environment (a.k.a. "the code on the screen") what the runtime behavior will be of said code—which includes being able to "read off" a time/space complexity for the code—without needing to check how each ADT involved has implemented its generics, let alone having to check for implicit type coercions.
Few people do that outside of code obfuscation contests, but the point is JS has heaps of gotchas like that, each waiting to bite you. How about:
x = 5;
(no var declaration). Extremely easy to do by accident. Lots of these will be left for backwards compatibility. In JS errors often go silent and I developed a strong dislike for any language that does that, including Vimscript and Lua (and I do like Vim).
I'd agree that global declaration is far more egregious. A sibling comment recommends a linter, and I'd probably agree. It's sad that it was ever allowed as one that is copying and pasting code to another location can easily cause this case to happen.
Eh, I actually like JS but I have definitely forgotten to add a "var" or "let" a few times, or sometimes I will do it correctly, get a bit overzealous with cutting, and accidentally remove the initial var declaration.
I'm not saying that it breaks the language, but it definitely is irritating, especially if you're not using a linter.
Whilst I do find it irritating, I don't mind about the scope default so much, but I've certainly run into it (forgetting to specify) a lot.
Mostly because JS is not the only language that I'll be working with at a time, and if I'm dancing between three or four and they have similar syntax, then mistakes creep in.
Javascript is such a good language that, even after two decades of fixes, it's only good when you use a different language - specifically created to address JS's many problems - that compiles to it.
> develop on every platform natively (React Native)
If "native" means bundling a runtime and having your program pass serialized messages to a different thread where the actual native platform code lives, the same can be said for any language. You just need to build the wrappers for the native API – which is a lot of work but could be done for QBASIC running in DOSBox just as well as for JS running on V8.
