For something you're getting paid for, sure. But if you're contributing in your free time for fun or whatever, presumably you'd prefer to use a language you actually like.
Real programmers will write in a way that user’s resources are not being wasted because you need a full browser, a JS runtime, and DOM juggling, to show even the simplest application.
It’s not rare for simple JS applications to consume over half a gigabyte of RAM on startup, and way more CPU than their native counterparts. That this was normalized and even defended is stupid.
I think you’re thinking of Electron apps, but that’s not really a criticism of JavaScript, that’s a criticism of Electron. There are plenty of JS platforms that don’t require a browser/DOM. React Native is the biggest example. Also, GJS if you want native Linux apps.
But why Node? Node cost five seconds just to start up back when I worked on my embedded ARM v7 platform, and on modern x86_64 computers, npx anything takes just as long. Why rely on another runtime? Why not native binaries instead?
Because you have to figure out how to build them. And with that I mean, how do you make sure that whatever you're doing will work and work the same way not only on your "embebbed ARM v7" architecture and all the other CPU architectures, but also the operating system libraries included? How do you make it work the same way on Mac, Windows 7, Windows 11, Ubuntu, custom Arch installations, FreeBSD, etc etc?
If you build native binaries, you personally are the one who has to make sure it runs. This means (depending on how much you want to support) a lot of development or support time. (Or you make your users build it themselves and fix errors, which means a massively reduced userbase, good luck with adoption...)
If you use Node, (or other virtual machines) you literally don't have to do anything, because it just works.
What you mentioned is compatibility across platforms. A program written in C is also guaranteed to run on all the systems you mentioned, given that the system has a C compiler and libc that stick to the standard. You, the programmer, does not have to anything to "make sure" your program works.
We've invented high-level programming languages like C 53 years ago, just to get away from assembly, and to avoid dealing with the "cross-platform" problem you mentioned, remember?
What if the system does not have libc? What if your program needs obscure library X?
Why do you think anyone even came up with the idea of virtual machines? Don't you think they had a problem they wanted to solve, that was not solved adequately before?
Yes and no. "Real" programmers care about engineering choices ; and JS is the cardboard of programming languages.
Perfect for packaging (which in this metaphor is UI), horrible for building a bridge with. And vice-versa, I wouldn't try and make amazon packaging out of reinforced concrete.
JS has saved me many hours of mind-numbing, error-prone manual keyboard work by giving me a way to hack together a simple bit of automation as a web page.
Even when a computer has been ham-fistedly locked-down by an overzealous IT department, I can almost always still access a text editor and a browser that will load local HTML files.
It's silly that IT departments forces us to resort to techniques used before browser extensions became a thing, and it's ironic that it's because they don't know how to code, but here we are.
Except if they then have to run it on their machine and the setup instructions start with setting up a venv. I find that a lot of Python software in the ML realm makes no effort to isolate the end user from the complexities of the platform. At best you get a setup script that may or may not create a working venv without manual intervention, usually the latter. It might be more of a Torch issue than a Python one but it still means spending a lot of time messing with the Python environment to get things running.
This may color my perception but the parts of the Python ecosystem I get exposed to as an end user these days feel very hacky. (Not all of it is, though; I remember from my Gentoo days that Portage was rock solid.)
Figuring out venvs was a bit frustrating for me. Particularly since the steps I was following to install a particular app mentioned nothing about them, so I just got an error when I tried to follow their instructions. Thankfully managed to get it figured out, but yeah, definitely wouldn’t have been my first choice for an install method if others were available for that app.
There are reasons why Common Lisp (that I absolutely prefer as well) is still a big thing in AI-related applications. Some of those are listed in your comment.
Personally, I find that (complex) software implemented in Python tends to be so unreliable that I typically don't want to use it after all, but I only find that out after wasting a bunch of time learning the software.
It's just frustrating, especially if I come back to the software every so often, naively thinking that it's been a few versions, so maybe they've fixed it. It's always just different bugs, which still end up being too frustrating to use the software.
To give an example, I like to compose music using Lilypond, which is more-or-less a programming language to create sheet music. And there is a program that's supposed to give you a well-integrated workflow for that (i.e. an IDE), called Frescobaldi.
The first time I tried it, playback of the composed music wouldn't work.
The second time, I couldn't click on notes to jump to the respective code snippet.
And I tried it again a few weeks ago and it just crashed immediately with an obscure error message.
Instead, I've slapped together a script, which just opens the sheet music in my PDF viewer, the code in my normal editor and then uses a CLI tools to generate and playback the sheet music. And while it's definitely not perfect, it has been working more reliably for me than Frescobaldi ever has.
I'm going to go with the multiple causes for slowness (and that's interpreted languages in general). In some cases, things might be usable if I weren't on Zen+ still (newer stuff has better IPC among other things).
Things like JIT or no-GIL might reduce that, but I'm not sure that it's that easy to fix (not being default (plus multiple options) seems to complicate bindings even).
What do you think of JSDoc? As someone who knows neither I find the idea of no required transpilation very appealing, while still getting the TS ecosystem tools.
JSDoc is much more cumbersome than using TypeScript. That's it. It clutters the code in a way that TypeScript somehow avoids. TS types are smoothly integrated in the code itself, IMO. Not as much the case with JSDoc.
Ah alright 🙂 My pleasure! Yeah I wouldn't even consider JSDoc if I had the choice of TypeScript. I even did some years of Advent Of Code in TypeScript. It's performant enough and simple to employ some kind of quasi functional programming style with it. I think it's great.
I think Rich Harris famously migrated Svelte from TypeScript to JSDoc, while still supporting TypeScript via JSDoc. I don’t use Svelte, so I have no idea how well this works in practice. However, Rick Harris seems smart to me, unlike other overly opinionated devs like DHH. I still wouldn’t use JSDoc over TS, but I guess if it works for your project, who cares. What matters is that we all remember the one true enemy, DHH
Being honest, I'm an outsider looking in. Most likely these things are solved problems, but alternates are always interesting to hear insider opinions on.
Sounds like it's developer experience Vs required post processing in this case, which is a reasonable tradeoff to think about
i wish a more performing language would have this type system. the only other ones I know are Rust which is a bit strict and slow to dev on, and Haskell which is too much.
If it looks mostly like Haskell but has better tooling, I'm in. I have yet to manage to successfully set up a Haskell environment on my own PC. 😅 I am obviously missing something.
I used it either through my distro's package or using stack install. there's also cabal install, but that doesn't install the compiler, at least not in 2017 when I played with it.
It's funny because I learned to program with strongly types languages and when I moved over to JavaScript I always complained about it for the longest time but now that I use mostly typescript at work I kind of miss some of the old JavaScript patterns and their flexibility. But for working with large teams or large projects in general it's nice to have typescript
JavaScript really depends on the people writing it restricting themselves to a sane (ish) subset, just like C++
My personal gripe with JavaScript is how horribly slow it is. C++ at least has the merit of being fast once compiled. I wouldn't feel great contributing to a JS project knowing fully well that a rewrite in a faster language would be 10x as effective as anything I could improve as is.
That’s funny because I - having not written much C++ - have an irrational hate of the language. But I like JavaScript. I think I need to look at C++ through the same lens I look at JS through.
Imo you can write pretty performant websites in JS. I guess it depends what you’re doing, but e.g. if you pay attention to you’re rerenders in React, you’re gonna have a much better time.
But I also totally understand as soon as you wanna do some compex stuff, JavaScript is not a good time. I don’t think webassembly has worked as smoothly as promised, but in theory, that should let you bring some C++ into the browser.
The Cinnamon desktop environment found in Linux Mint uses JavaScript on the back-end. My knowledge doesn't extend much beyond that (other DEs, and what they do, nor the full extent of JS in Cinnamon), but I did look at it at one point.
Makes me wonder if OP was talking it about that in particular or if there's some other project with a bundled JS interpreter they decided not to work with.
You’re not wrong, but newer version of the language have steered devs away from these quirks. The quirks remain because the JavaScript language is 100% backwards compatible. It’s fun to laugh at these quirks, but I’ve been a full time JavaScript developer for 4 years and part time since 2015, and I’ve never seen any of these quirks come up in the real world. If you tell your developers to use === instead of == in code review, you eliminate most of the problems imo.
JavaScript tooling deserves more hate imo. The ecosystem is kinda a disaster, but Vite is making a lot of progress in fixing that. If you ignore React Native and metro bundler, I think the state of web is looking pretty optimistic right now. At least from a technology perspective. From a business/AI/enshitification perspective we’re cooked lol
I got a little under half in the first two, which I'm very happy with haha. JS certainly has some quirks, but you've really got to go looking for them IMO. TypeScript resolves most of these issues with comparing types, and the rest aren't that unique to JS.
I'm 100% sure I can make Rust code (not even compiled to WASM) run natively in a browser like Firefox, given I have enough will power, time, energy, and money. The problem is getting everyone else to agree to this new standard.
In a scripting language, is there an advantage to no garbage collection? (I honestly don't know)
Someone else also pointed out to me, when I made a similar suggestion, that ability to partially fail but keep going is desirable in a web context. I don't know, maybe there's some way to make Rust do that more automatically than C. Python seems the be the standard for general-purpose scripting, which is why I mentioned it.
More specifically, my programming background is in industrial automation and I'd like to add some more 'robust and flexible' algorithms to CoolerControl so I can control my system fans / temperature better, but it's written in a mix of TypeScript and Rust.
I've spent 20 years programming hard real-time z80 assembly and know quite a few higher-level languages. (Although I prefer the lower-level ones.) Not those ones, however, so it's not just a couple of hours work to raise a PR against that project. Going to need to crack some books.
Genuinely curious, how many of you hating on JS have done professional frontend work recently? If you have done professional work, was it part/full time, using TypeScript, how big was your eng team, did you have to worry about Server Side Rendering? Maybe some extra context will show certain types of projects yield devs that hate the language.
I don't know what you mean by supports tray but have you tried KDE connect? It has a lot more features than just sending files but I use it for a few things.
And if you don't care about having GUI, I love miniserve for sharing files. It'll open a web server and you can connect to it to download/upload files.
This doesn't really conflict with the post. They use and appreciate the software, so presumably it's decent. You can write good software in any language, so it doesn't prove that the language itself is good. IMO JS is a popular language, not a good language.
I’ve never really found the type conversions that bizarre, unless you’re doing something weird like casting an array to a string or number. I don’t really use strange type casts, since I use TypeScript and avoid using the “==“ operator. What other things make it not good?
I'm pretty sure most people do not like JS's loosey-goosey, who-knows-what-ur-gonna-get type system, which is why TS is so popular. Not really surprising since the bones of the language were basically spat out in a couple weeks. TS is a custom type system on top of JS, meaning it's not just JS's type system expressed through strict typing. They added a bunch of useful features like discriminated unions and so on to make using TS more pleasant than raw JS.
TS is actually usable (although NPM and the environment built around it still suck). It's inherited a bunch of weird shit from JS, but the type system generally makes them bearable.
I started my career with Visual Basic (3!) and I appreciated the loose typing because it meant I could get going and actually have something running quickly as a newbie. A few years later I switched to C# and saw how an entire class of errors disappeared because of the strong typing. Both have their place, depending on the skill level of the coder and the needs of the application.
Yes, but some are VERY opinionated about it. It's almost religious with them. I think it's silly. Both have their pros and cons. I honestly enjoy both and never had a big issue with loosely typed languages. I assume it's just bad developers that mess up and get confused about it.
Yes, if you do silly things with JS, you generally get silly results instead of TypeErrors. I wouldn’t say that makes the language bad. It makes the language resilient to bad programming, which you’d generally want in the case of web pages.
Well, all websites are written in JS (on the frontend), so I don’t think that’s fair. And I don’t think 90% of the worst software is made in JS. Even if you’re an Electron hater, Electron apps aren’t bad software, they’re just bloated. There’s tons of shit software written in C. I would guess a lot more than is written in JS, just because more software is written in C. C is also way easier to shoot yourself in the foot.
Uptime Kuma (and others) show that JS can be used to make awesome software. The language doesn’t really hold you back, it’s just your own skill. If you suck at writing software, it doesn’t matter what language you use, your software will be shit.
I didn’t say that. You can make great software in Brainfuck, but I don’t think anyone has ever said it is good because of that.
People do make good software in JavaScript. Knowing JavaScript is an exceptionally useful skill, and JavaScript is pretty easy to become decent at. The learning curve for JavaScript is relatively low. As such, there are tons of JS devs, many of which want to make cool things. JavaScript is undeniably an approachable language. Whether you personally think it’s a good language doesn’t have any bearing on that, but that means tons of people are going to use it to make cool software. To me, its approachability is one of the many things that make it good.
Edit: Ok the "apparently" is doing heavy lifting, since now I can't find the original source I read about it. Turns out "X" is a garbage name with no searchability, only an idiot would use it.
Using only VSCodium in this llist. But not much, because i always have to close it on evening, or the casual game with 300 mods wouldn't run beside it and the webbrowser reserving about half of my 32 GB RAM.
Your VSCodium reserves ~8 GB of ram? You might want to check the extensions you’re using. I’ve got mine running with tons of open files and it’s using ~2 GB.
Also, you should definitely give Immich a try. It’s an awesome piece of software.
Technically typescript. I know it transpiles to J's but half the complaints I read are about the typo conversion and so on, which ts heavily alleviates.
163 Comments
luciole@beehaw.org · 92 pts · 267d
Real programmers are language agnostic. Anyways what's the project?
kayzeekayzee@lemmy.blahaj.zone · 117 pts · 267d
We're writing an online banking service entirely in brainfuck. Backend, frontend, even middleend if we have to
Deebster@infosec.pub · 69 pts · 267d
I enjoy the contradiction of middleend
Randelung@lemmy.world · 20 pts · 267d
The middlemiddle
E: My backend don't middlemiddle, it forks
PabloSexcrowbar@piefed.social · 5 pts · 267d
It took me a solid half-dozen tries not to pronounce it "mid-leend." After that much effort, I decided to let my dumb brain win and go with it.
Duamerthrax@lemmy.world · 2 pts · 267d
Would you take a Quake-like written in Pascal?
arcterus@piefed.blahaj.zone · 89 pts · 267d
For something you're getting paid for, sure. But if you're contributing in your free time for fun or whatever, presumably you'd prefer to use a language you actually like.
TeamAssimilation@infosec.pub · 38 pts · 267d
Real programmers will write in a way that user’s resources are not being wasted because you need a full browser, a JS runtime, and DOM juggling, to show even the simplest application.
It’s not rare for simple JS applications to consume over half a gigabyte of RAM on startup, and way more CPU than their native counterparts. That this was normalized and even defended is stupid.
hperrin@lemmy.ca · 58 pts · 267d
I think you’re thinking of Electron apps, but that’s not really a criticism of JavaScript, that’s a criticism of Electron. There are plenty of JS platforms that don’t require a browser/DOM. React Native is the biggest example. Also, GJS if you want native Linux apps.
Azzu@lemmy.dbzer0.com · 15 pts · 267d
Node does not require an excessive amount of resources.
racketlauncher831@lemmy.ml · 1 pts · 265d
But why Node? Node cost five seconds just to start up back when I worked on my embedded ARM v7 platform, and on modern x86_64 computers,
npxanything takes just as long. Why rely on another runtime? Why not native binaries instead?Azzu@lemmy.dbzer0.com · 2 pts · 265d
Because you have to figure out how to build them. And with that I mean, how do you make sure that whatever you're doing will work and work the same way not only on your "embebbed ARM v7" architecture and all the other CPU architectures, but also the operating system libraries included? How do you make it work the same way on Mac, Windows 7, Windows 11, Ubuntu, custom Arch installations, FreeBSD, etc etc?
If you build native binaries, you personally are the one who has to make sure it runs. This means (depending on how much you want to support) a lot of development or support time. (Or you make your users build it themselves and fix errors, which means a massively reduced userbase, good luck with adoption...)
If you use Node, (or other virtual machines) you literally don't have to do anything, because it just works.
You really don't see the value in that?
racketlauncher831@lemmy.ml · 1 pts · 265d
What you mentioned is compatibility across platforms. A program written in C is also guaranteed to run on all the systems you mentioned, given that the system has a C compiler and libc that stick to the standard. You, the programmer, does not have to anything to "make sure" your program works.
See this insane list of platforms GCC supports.
https://en.wikipedia.org/wiki/GNU_Compiler_Collection#Architectures
We've invented high-level programming languages like C 53 years ago, just to get away from assembly, and to avoid dealing with the "cross-platform" problem you mentioned, remember?
Azzu@lemmy.dbzer0.com · 1 pts · 263d
What if the system does not have libc? What if your program needs obscure library X?
Why do you think anyone even came up with the idea of virtual machines? Don't you think they had a problem they wanted to solve, that was not solved adequately before?
racketlauncher831@lemmy.ml · 1 pts · 263d
No offence but I think I need to stop discussing with you.
CeeBee_Eh@lemmy.world · 27 pts · 267d
Thought terminating sentence.
Sonotsugipaa@lemmy.dbzer0.com · 17 pts · 267d
More like, no true scotsman
Clent@lemmy.dbzer0.com · 0 pts · 267d
Real carpenters don't walk away from a job because the hammer is their least favorite brand.
RheumatoidArthritis@mander.xyz · 17 pts · 267d
their least favourite hammer brand:
tinyvoltron@discuss.online · 11 pts · 267d
Real carpenters bring their own hammer.
homoludens@feddit.org · 9 pts · 267d
I once had a hammer head get loose and fly off the handle.
MonkderVierte@lemmy.zip · 6 pts · 267d
But if the screws are nails.
getoffthatchronic@lemdro.id · 4 pts · 267d
It can't be a programming humor post without somehow even more mind-numbing stuff in the comments. Just part of the fun
termaxima@slrpnk.net · 25 pts · 267d
Yes and no. "Real" programmers care about engineering choices ; and JS is the cardboard of programming languages.
Perfect for packaging (which in this metaphor is UI), horrible for building a bridge with. And vice-versa, I wouldn't try and make amazon packaging out of reinforced concrete.
sukhmel@programming.dev · 1 pts · 267d
But for fun both bridge out of cardboard and packaging out of concrete might work, tastes differ ¯\_(ツ)_/¯
30p87@feddit.org · 9 pts · 267d
Sorry, but Rust triggers me way too much.
lime@feddit.nu · 4 pts · 267d
the bash language server is in nodejs...
cbazero@programming.dev · 5 pts · 267d
And it shouldn't
sga@piefed.social · 1 pts · 267d
luciole@beehaw.org · 7 pts · 267d
Also real programmers have impostor's syndrome.
Redkey@programming.dev · 60 pts · 267d
JS has saved me many hours of mind-numbing, error-prone manual keyboard work by giving me a way to hack together a simple bit of automation as a web page.
Even when a computer has been ham-fistedly locked-down by an overzealous IT department, I can almost always still access a text editor and a browser that will load local HTML files.
mirshafie@europe.pub · 25 pts · 267d
Add to that the beauty of bookmarklets.
It's silly that IT departments forces us to resort to techniques used before browser extensions became a thing, and it's ironic that it's because they don't know how to code, but here we are.
dejected_warp_core@lemmy.world · 2 pts · 257d
The amount of work I have completed with Tampermonkey in situations like this should have made that same IT department quite anxious.
SethranKada@lemmy.ca · 52 pts · 267d
Feels the same whenever a project is written in python, but I uninstall it too.
Quill7513@slrpnk.net · 25 pts · 267d
why?
tux0r@feddit.org · 70 pts · 267d
Same, so I’ll only answer for me: Python is dependency hell, also breaking existing code with every second update. Hard pass.
nixfreak@sopuli.xyz · 33 pts · 267d
Python versioning is terrible
lauha@lemmy.world · 20 pts · 267d
Still remembering python 3 release from 17 years ago?
Ephera@lemmy.ml · 9 pts · 267d
They have breaking changes in their minor versions...
SSUPII@sopuli.xyz · 17 pts · 267d
We are no longer in the Python 2 days. You have lots of wiggle room for using the version you want and are rarely forced to use specific releases.
Jesus_666@lemmy.world · 29 pts · 267d
There still plenty of "this version of pytorch doesn't run reliably with Python 3.12, please use 3.10", though. It's not all sunshine and roses.
lime@feddit.nu · 15 pts · 267d
pytorch is a unique kind of mess
FishFace@piefed.social · 2 pts · 267d
If you're writing python code you have to deal with versioning, yeah. But the end user basically never has to care.
Jesus_666@lemmy.world · 14 pts · 267d
Except if they then have to run it on their machine and the setup instructions start with setting up a venv. I find that a lot of Python software in the ML realm makes no effort to isolate the end user from the complexities of the platform. At best you get a setup script that may or may not create a working venv without manual intervention, usually the latter. It might be more of a Torch issue than a Python one but it still means spending a lot of time messing with the Python environment to get things running.
This may color my perception but the parts of the Python ecosystem I get exposed to as an end user these days feel very hacky. (Not all of it is, though; I remember from my Gentoo days that Portage was rock solid.)
Confused_Emus@lemmy.dbzer0.com · 5 pts · 267d
Figuring out venvs was a bit frustrating for me. Particularly since the steps I was following to install a particular app mentioned nothing about them, so I just got an error when I tried to follow their instructions. Thankfully managed to get it figured out, but yeah, definitely wouldn’t have been my first choice for an install method if others were available for that app.
Valmond@lemmy.world · 4 pts · 267d
Security issues aside, you can freeze python code to an executable, linux, mac, windows.
Kind of neat IMO. Except the security concerns ofc.
tux0r@feddit.org · 3 pts · 267d
There are reasons why Common Lisp (that I absolutely prefer as well) is still a big thing in AI-related applications. Some of those are listed in your comment.
Quill7513@slrpnk.net · 1 pts · 267d
if they do that's not release ready software that you should concern yourself with imo. that's a problem of project maturity not runtime choice
FishFace@piefed.social · 1 pts · 267d
ML is a very new field and so most programs are not mature, and indeed they can have you messing around with venvs and such.
But most python software people actually used is packaged by a distro already.
lastweakness@lemmy.world · 5 pts · 267d
I mean, flatpaks are great...
tux0r@feddit.org · 5 pts · 267d
Solving problems you shouldn’t have?
lastweakness@lemmy.world · 2 pts · 267d
You already have those problems, clearly.
MonkderVierte@lemmy.zip · 1 pts · 267d
Ephera@lemmy.ml · 39 pts · 267d
Personally, I find that (complex) software implemented in Python tends to be so unreliable that I typically don't want to use it after all, but I only find that out after wasting a bunch of time learning the software.
It's just frustrating, especially if I come back to the software every so often, naively thinking that it's been a few versions, so maybe they've fixed it. It's always just different bugs, which still end up being too frustrating to use the software.
To give an example, I like to compose music using Lilypond, which is more-or-less a programming language to create sheet music. And there is a program that's supposed to give you a well-integrated workflow for that (i.e. an IDE), called Frescobaldi.
The first time I tried it, playback of the composed music wouldn't work.
The second time, I couldn't click on notes to jump to the respective code snippet.
And I tried it again a few weeks ago and it just crashed immediately with an obscure error message.
Instead, I've slapped together a script, which just opens the sheet music in my PDF viewer, the code in my normal editor and then uses a CLI tools to generate and playback the sheet music. And while it's definitely not perfect, it has been working more reliably for me than Frescobaldi ever has.
insomniac_lemon@lemmy.cafe · 1 pts · 266d
I'm going to go with the multiple causes for slowness (and that's interpreted languages in general). In some cases, things might be usable if I weren't on Zen+ still (newer stuff has better IPC among other things).
Things like JIT or no-GIL might reduce that, but I'm not sure that it's that easy to fix (not being default (plus multiple options) seems to complicate bindings even).
melfie@lemy.lol · 52 pts · 267d
sip@programming.dev · 17 pts · 267d
agreed. typescript is excelent, especially if you make it strict and know a bit of complex types to make sure things stay put.
victorz@lemmy.world · 7 pts · 267d
Chiming in as a professional TS dev. It's really a joy to do web dev work in the post TS world.
biggeoff@sh.itjust.works · 4 pts · 266d
What do you think of JSDoc? As someone who knows neither I find the idea of no required transpilation very appealing, while still getting the TS ecosystem tools.
victorz@lemmy.world · 4 pts · 266d
JSDoc is much more cumbersome than using TypeScript. That's it. It clutters the code in a way that TypeScript somehow avoids. TS types are smoothly integrated in the code itself, IMO. Not as much the case with JSDoc.
biggeoff@sh.itjust.works · 4 pts · 266d
Thanks! As a hardware guy it'll be a long time before I do anything with this information. Nice to hear the opinions of actual Devs.
moseschrute@lemmy.world · 2 pts · 266d
I suspect most Lemmy users hating on JS haven’t done much professional JS work. Especially these days with TypeScript and all the modern conveniences.
I’m curious, what kinda hardware do you work on?
biggeoff@sh.itjust.works · 1 pts · 266d
Digital hardware, mainly top-level design in verilog and associated checks using python/perl (sad)
Right now working on a GPU which is fun!
victorz@lemmy.world · 1 pts · 266d
Ah alright 🙂 My pleasure! Yeah I wouldn't even consider JSDoc if I had the choice of TypeScript. I even did some years of Advent Of Code in TypeScript. It's performant enough and simple to employ some kind of quasi functional programming style with it. I think it's great.
moseschrute@lemmy.world · 1 pts · 266d
I think Rich Harris famously migrated Svelte from TypeScript to JSDoc, while still supporting TypeScript via JSDoc. I don’t use Svelte, so I have no idea how well this works in practice. However, Rick Harris seems smart to me, unlike other overly opinionated devs like DHH. I still wouldn’t use JSDoc over TS, but I guess if it works for your project, who cares. What matters is that we all remember the one true enemy, DHH
iglou@programming.dev · 3 pts · 266d
Why is transpilation unappealing to you?
biggeoff@sh.itjust.works · 2 pts · 266d
Being honest, I'm an outsider looking in. Most likely these things are solved problems, but alternates are always interesting to hear insider opinions on.
Sounds like it's developer experience Vs required post processing in this case, which is a reasonable tradeoff to think about
sip@programming.dev · 3 pts · 266d
i wish a more performing language would have this type system. the only other ones I know are Rust which is a bit strict and slow to dev on, and Haskell which is too much.
victorz@lemmy.world · 2 pts · 266d
Fully agree.
I hear good things about OCaml? Anyone tried that?
sip@programming.dev · 1 pts · 266d
I asked chatgpt for a few languages with a good typesystem and it suggested ocaml among other (scala, rust, haskell, f#)
Then asked for a 100 line ocaml REST API example with a popular framework and db lib.. and it looks mostly like Haskell.
edit: async is done with monads
victorz@lemmy.world · 1 pts · 266d
If it looks mostly like Haskell but has better tooling, I'm in. I have yet to manage to successfully set up a Haskell environment on my own PC. 😅 I am obviously missing something.
sip@programming.dev · 1 pts · 266d
I used it either through my distro's package or using stack install. there's also cabal install, but that doesn't install the compiler, at least not in 2017 when I played with it.
sip@programming.dev · 1 pts · 266d
I think ghcup is the simplest way
RagingRobot@lemmy.world · 2 pts · 266d
It's funny because I learned to program with strongly types languages and when I moved over to JavaScript I always complained about it for the longest time but now that I use mostly typescript at work I kind of miss some of the old JavaScript patterns and their flexibility. But for working with large teams or large projects in general it's nice to have typescript
lonlazarus@lemmy.sdf.org · 32 pts · 267d
Prissy little programmers
termaxima@slrpnk.net · 26 pts · 267d
JavaScript really depends on the people writing it restricting themselves to a sane (ish) subset, just like C++
My personal gripe with JavaScript is how horribly slow it is. C++ at least has the merit of being fast once compiled. I wouldn't feel great contributing to a JS project knowing fully well that a rewrite in a faster language would be 10x as effective as anything I could improve as is.
moseschrute@lemmy.world · 1 pts · 266d
That’s funny because I - having not written much C++ - have an irrational hate of the language. But I like JavaScript. I think I need to look at C++ through the same lens I look at JS through.
Imo you can write pretty performant websites in JS. I guess it depends what you’re doing, but e.g. if you pay attention to you’re rerenders in React, you’re gonna have a much better time.
But I also totally understand as soon as you wanna do some compex stuff, JavaScript is not a good time. I don’t think webassembly has worked as smoothly as promised, but in theory, that should let you bring some C++ into the browser.
termaxima@slrpnk.net · 2 pts · 266d
JavaScript is great for making websites !
menas@lemmy.wtf · 18 pts · 267d
Javascript turn our computers into toasters
lessthanluigi@lemmy.sdf.org · 4 pts · 267d
You know what they say! All Javascripts Toasts Computers!
Agent641@lemmy.world · 1 pts · 267d
And our toasters into computers
mexicancartel@lemmy.dbzer0.com · 2 pts · 266d
That would be java i guess
PearOfJudes@lemmy.ml · 17 pts · 267d
I like minecraft
tux0r@feddit.org · 15 pts · 267d
Real men use Lisp.
RalfWausE@blackneon.net · 8 pts · 267d
You spelled Forth wrong.
nixfreak@sopuli.xyz · 3 pts · 267d
Guile hoot is pretty impressive , guile to wasm
tomenzgg@midwest.social · 4 pts · 267d
Not to mention the entire Guile OS (Guix).
dreadbeef@lemmy.dbzer0.com · 1 pts · 267d
clojurescript
tux0r@feddit.org · 3 pts · 267d
Oof.
Feathercrown@lemmy.world · 14 pts · 266d
If you care this much about JS being cringe I don't trust you to contribute good code to a project anyways
moseschrute@lemmy.world · 9 pts · 266d
People on here really think the language determines the quality of the project lol
racketlauncher831@lemmy.ml · 0 pts · 265d
Not determine, but allows. C is a shitty language too. Linux is great because Linus bars off shitty contributors.
Supervisor194@lemmy.world · 13 pts · 267d
I like JavaScript a lot and would be excited by its use in this context.
palordrolap@fedia.io · 4 pts · 267d
The Cinnamon desktop environment found in Linux Mint uses JavaScript on the back-end. My knowledge doesn't extend much beyond that (other DEs, and what they do, nor the full extent of JS in Cinnamon), but I did look at it at one point.
Makes me wonder if OP was talking it about that in particular or if there's some other project with a bundled JS interpreter they decided not to work with.
cypherpunks@lemmy.ml · 10 pts · 266d
A few lists of javascript WTFs:
To anyone who thinks they know JS well and that its quirkiness is not a problem, let me know how you do on these quizzes:
moseschrute@lemmy.world · 7 pts · 266d
You’re not wrong, but newer version of the language have steered devs away from these quirks. The quirks remain because the JavaScript language is 100% backwards compatible. It’s fun to laugh at these quirks, but I’ve been a full time JavaScript developer for 4 years and part time since 2015, and I’ve never seen any of these quirks come up in the real world. If you tell your developers to use === instead of == in code review, you eliminate most of the problems imo.
JavaScript tooling deserves more hate imo. The ecosystem is kinda a disaster, but Vite is making a lot of progress in fixing that. If you ignore React Native and metro bundler, I think the state of web is looking pretty optimistic right now. At least from a technology perspective. From a business/AI/enshitification perspective we’re cooked lol
el_abuelo@programming.dev · 5 pts · 266d
this quirkiness doesn't materialise in real world applications on any scale that makes it harder to deal with than the alternatives.
jpeps@lemmy.world · 2 pts · 266d
I got a little under half in the first two, which I'm very happy with haha. JS certainly has some quirks, but you've really got to go looking for them IMO. TypeScript resolves most of these issues with comparing types, and the rest aren't that unique to JS.
Hupf@feddit.org · 2 pts · 265d
Brian Leroux
Korhaka@sopuli.xyz · 10 pts · 266d
Unless you are making a HTML/CSS only site (based) what do you want to use instead?
CanadaPlus@lemmy.sdf.org · 8 pts · 266d
Invent a new internet where you can script pages directly in Python or TypeScript.
Otherwise, you get to enjoy a silly toy language from the 90's.
racketlauncher831@lemmy.ml · 2 pts · 265d
I'm 100% sure I can make Rust code (not even compiled to WASM) run natively in a browser like Firefox, given I have enough will power, time, energy, and money. The problem is getting everyone else to agree to this new standard.
CanadaPlus@lemmy.sdf.org · 2 pts · 265d
In a scripting language, is there an advantage to no garbage collection? (I honestly don't know)
Someone else also pointed out to me, when I made a similar suggestion, that ability to partially fail but keep going is desirable in a web context. I don't know, maybe there's some way to make Rust do that more automatically than C. Python seems the be the standard for general-purpose scripting, which is why I mentioned it.
Valmond@lemmy.world · 2 pts · 266d
I'm on, but no one is interested.
FunkFactory@lemmy.world · 2 pts · 266d
Kotlin/JS would be my first choice ( ͡° ͜ʖ ͡°)
addie@feddit.uk · 9 pts · 267d
I'm in this photo and I don't like it.
More specifically, my programming background is in industrial automation and I'd like to add some more 'robust and flexible' algorithms to CoolerControl so I can control my system fans / temperature better, but it's written in a mix of TypeScript and Rust.
I've spent 20 years programming hard real-time z80 assembly and know quite a few higher-level languages. (Although I prefer the lower-level ones.) Not those ones, however, so it's not just a couple of hours work to raise a PR against that project. Going to need to crack some books.
moseschrute@lemmy.world · 6 pts · 266d
Genuinely curious, how many of you hating on JS have done professional frontend work recently? If you have done professional work, was it part/full time, using TypeScript, how big was your eng team, did you have to worry about Server Side Rendering? Maybe some extra context will show certain types of projects yield devs that hate the language.
MonkderVierte@lemmy.zip · 4 pts · 267d
thevoidzero@lemmy.world · 5 pts · 267d
I don't know what you mean by supports tray but have you tried KDE connect? It has a lot more features than just sending files but I use it for a few things.
And if you don't care about having GUI, I love miniserve for sharing files. It'll open a web server and you can connect to it to download/upload files.
TheFederatedPipe@fedia.io · 2 pts · 267d
Localsend is built with Dart/Flutter.
MonkderVierte@lemmy.zip · 0 pts · 267d
The same but different.
eemon@programming.dev · 3 pts · 267d
So true.
calisti@lemmy.blahaj.zone · 2 pts · 266d
Written in PHP
url@feddit.fr · 2 pts · 267d
I that's me😁
sirico@feddit.uk · 2 pts · 266d
This meme should be rewritten in js
cupcakezealot@piefed.blahaj.zone · 1 pts · 266d
id say it could be worse it could be written in dhtml but that's pretty much better than js these days
hperrin@lemmy.ca · 1 pts · 267d
Some of the best software is written in JavaScript.
arcterus@piefed.blahaj.zone · 40 pts · 267d
This doesn't really conflict with the post. They use and appreciate the software, so presumably it's decent. You can write good software in any language, so it doesn't prove that the language itself is good. IMO JS is a popular language, not a good language.
hperrin@lemmy.ca · 5 pts · 267d
What makes it not good?
arcterus@piefed.blahaj.zone · 21 pts · 267d
The completely bizarre implicit type conversions, for one thing.
hperrin@lemmy.ca · 7 pts · 267d
I’ve never really found the type conversions that bizarre, unless you’re doing something weird like casting an array to a string or number. I don’t really use strange type casts, since I use TypeScript and avoid using the “==“ operator. What other things make it not good?
arcterus@piefed.blahaj.zone · 17 pts · 267d
I mean, just the fact that you're using TS instead of plain JS (and that TS even exists) should tell you that the language has issues...
hperrin@lemmy.ca · 4 pts · 267d
It’s just strict typing on top of plain JS. I like strict typing. Some people like loose typing.
arcterus@piefed.blahaj.zone · 11 pts · 267d
I'm pretty sure most people do not like JS's loosey-goosey, who-knows-what-ur-gonna-get type system, which is why TS is so popular. Not really surprising since the bones of the language were basically spat out in a couple weeks. TS is a custom type system on top of JS, meaning it's not just JS's type system expressed through strict typing. They added a bunch of useful features like discriminated unions and so on to make using TS more pleasant than raw JS.
TS is actually usable (although NPM and the environment built around it still suck). It's inherited a bunch of weird shit from JS, but the type system generally makes them bearable.
ChickenLadyLovesLife@lemmy.world · 3 pts · 267d
I started my career with Visual Basic (3!) and I appreciated the loose typing because it meant I could get going and actually have something running quickly as a newbie. A few years later I switched to C# and saw how an entire class of errors disappeared because of the strong typing. Both have their place, depending on the skill level of the coder and the needs of the application.
SaharaMaleikuhm@feddit.org · 2 pts · 267d
Yes, but some are VERY opinionated about it. It's almost religious with them. I think it's silly. Both have their pros and cons. I honestly enjoy both and never had a big issue with loosely typed languages. I assume it's just bad developers that mess up and get confused about it.
FishFace@piefed.social · 9 pts · 267d
If you use typescript you will obviously never see the weird type system of JavaScript
Baguette@lemmy.blahaj.zone · 5 pts · 267d
still possible, typescript is only strongly typed if you and everyone else working on the project wants it to be.
hperrin@lemmy.ca · 2 pts · 267d
Considering TypeScript is a superset of JavaScript, you certainly can. But, that generally means you’re using TypeScript poorly.
FishFace@piefed.social · 0 pts · 267d
Just look up the video entitled "wat" which is mainly about JavaScript
FrankDeath@infosec.pub · 3 pts · 267d
https://www.destroyallsoftware.com/talks/wat
hperrin@lemmy.ca · 2 pts · 267d
Yes, if you do silly things with JS, you generally get silly results instead of TypeErrors. I wouldn’t say that makes the language bad. It makes the language resilient to bad programming, which you’d generally want in the case of web pages.
CeeBee_Eh@lemmy.world · 16 pts · 267d
Taking Immich as an example, there's a lot of heavy lifting happening there behind the scenes in external libraries that are not written in JS.
hperrin@lemmy.ca · 1 pts · 267d
It’s written for Node and Svelte. But sure, just like nearly all other software, they use external libraries.
Oisteink@lemmy.world · 6 pts · 267d
So uptime kuma being written in JS proves what about the language?
90% of the worst software and websites are made in js
hperrin@lemmy.ca · 11 pts · 267d
Well, all websites are written in JS (on the frontend), so I don’t think that’s fair. And I don’t think 90% of the worst software is made in JS. Even if you’re an Electron hater, Electron apps aren’t bad software, they’re just bloated. There’s tons of shit software written in C. I would guess a lot more than is written in JS, just because more software is written in C. C is also way easier to shoot yourself in the foot.
Uptime Kuma (and others) show that JS can be used to make awesome software. The language doesn’t really hold you back, it’s just your own skill. If you suck at writing software, it doesn’t matter what language you use, your software will be shit.
Oisteink@lemmy.world · 6 pts · 267d
So any language is good as I can make great software using it?? IMO js is still a mess and NPM is really full of shit code to prove it.
hperrin@lemmy.ca · 5 pts · 267d
I didn’t say that. You can make great software in Brainfuck, but I don’t think anyone has ever said it is good because of that.
People do make good software in JavaScript. Knowing JavaScript is an exceptionally useful skill, and JavaScript is pretty easy to become decent at. The learning curve for JavaScript is relatively low. As such, there are tons of JS devs, many of which want to make cool things. JavaScript is undeniably an approachable language. Whether you personally think it’s a good language doesn’t have any bearing on that, but that means tons of people are going to use it to make cool software. To me, its approachability is one of the many things that make it good.
The_Decryptor@aussie.zone · 4 pts · 267d
Not true anymore unfortunately, some sites are using frameworks compiled to WASM instead.
e.g. X is apparently using Yew now.
Edit: Ok the "apparently" is doing heavy lifting, since now I can't find the original source I read about it. Turns out "X" is a garbage name with no searchability, only an idiot would use it.
MonkderVierte@lemmy.zip · 3 pts · 267d
Using only VSCodium in this llist. But not much, because i always have to close it on evening, or the casual game with 300 mods wouldn't run beside it and the webbrowser reserving about half of my 32 GB RAM.
hperrin@lemmy.ca · 2 pts · 267d
Your VSCodium reserves ~8 GB of ram? You might want to check the extensions you’re using. I’ve got mine running with tons of open files and it’s using ~2 GB.
Also, you should definitely give Immich a try. It’s an awesome piece of software.
fushuan@lemmy.blahaj.zone · 1 pts · 267d
Technically typescript. I know it transpiles to J's but half the complaints I read are about the typo conversion and so on, which ts heavily alleviates.
racketlauncher831@lemmy.ml · 1 pts · 265d
VS Code is a good software? I beg to differ. It's slow. It's messy to look at. It's resource hungry.
If you think VS Code is a good editor, we can make an even better editor in another language.
hperrin@lemmy.ca · 1 pts · 265d
It is resource hungry. I’ll give you that. But it’s neither slow nor messy to look at. Have you ever used NetBeans or Eclipse?
racketlauncher831@lemmy.ml · 1 pts · 265d
You are comparing it to Eclipse. I also give you that.