bash would be a scripting language, though to be fair, i also consider bash to be pseudo code as well.
If JS is a scripting language, than any other language is a scripting language. And technically, every language can be used to script, so therefore, is a scripting language. i’m referring to the aspect of a scripting language being generally constricted.
Pseudo code is literally fake code. Scripting is an actual type of code. Scripted languages while not strictly defined, usually refers to languages you don’t compile before running them. Bash is considered a scripting language because you don’t ship a binary compiled executable, but rather ship a file that is human readable and converted into machine code when it is run. Scripting languages are compared to compiled languages, like C or Rust. Where the file you run is already compiled, and executed directly.
What do you mean by this?
i’m referring to the aspect of a scripting language being generally constricted.
Any Turing complete system, or this case language, can do anything any other one can, depending on the level of suffering you are willing to endure to make it happen. Anything JS can do, Rust can do. Anything Rust can do, Bash can do. The differences between languages is the assumptions they make, and performance characteristics as a result of those assumptions. Functionality is not practically different from one another, though some absolutely make it easier for humans to do.
hence why i specified why i consider it to be as such. I just think pseudo code shouldn’t exist. Plain and simple. Bash scripting is close to a language in the same way that pseudo code is also technically code.
What do you mean by this?
i just mean the simple fact that you could technically probably run bash on windows, but really wouldn’t want to. I don’t consider bash to be a programming language, though it is technically a scripting language, because it’s primary existence is in the shell environment of a system. I.E. constricted, but that’s just my view of it.
Bash being on the same level as actually fake code is a pretty hot take to me. What are your opinions on Python, or Ruby, or any other interpreted language? You could very well use them as your login shell, just like Bash if you wanted. In your eyes, if Bash *isn’t * a programming language at all, how do you describe a programming language? Languages that express code are just the same as languages that write stories, and whether you do it in German or Vietnamese makes no difference on what story you can write.
When you describe a language as constricted what do you mean? Bash can do anything Python or Rust can do, each of them is just specialized to being better at specific aspects for human convenience in writing code. There is no inherit limitation on what can be done by the language you use to express it.
it’s definitely a hot take, you could theoretically use any other language as a shell, and i know you sort of can with stuff like node as well.
But those aren’t shell languages, and bash isn’t a true language, in the sense that it was explicitly designed to be used in the shell environment, i also consider it to be “pseudocode” because it’s not actually bash doing things a pretty significant amount of time you’ll stuff something into sed or awk, which are actually different interpreters all together.
bash is almost a sort of wrapper, between a bunch of different programs that all handle things differently, allowing you to glue them back together to make something usable. It’s close enough to being it’s own language, that you could make it one, but it’s not, because it’s not supposed to be one.
i suppose that’s pretty much what i mean when i say constricted.
Older techs remember when it was only browser-based and they thought of, and perhaps still think of, “scripting languages” as something that would run from some command-line or another. Starting a GUI browser to run a mere script was a ridiculous concept. (There was also that JavaScript had no filesystem access. At least initially. And then it became a gaping security hole, but I digress.)
Today, there exist command-line accessible versions of JavaScript but even there (I figure) most people wince and choose anything else instead. Maybe even Perl.
But another definition of “scripting language” is “(any) interpreted programming language” and where it runs is unimportant.
From that perspective, sure, JavaScript qualifies. And so does QBASIC.
Are you referring to AOT compilation specifically? JavaScript in V8 is JIT compiled if it’s “hot” (executed enough that the cost of JIT compilation is less than the cost of continuing to run it in interpreted mode).
What’s even wilder is if you look at the code of that package, all it does is include the is-odd package and then return !is-odd. And the is-odd package isn’t much better, it does some basic checks on the input and then returns n % 2 === 1.
I thought I was missing something. JS is one of my main languages and I always just write the is-odd function myself since it’s like 10 characters. It boggles the mind that is-even has 176k weekly downloads
To be fair having a name can make things easier to read. I get that i % 2 == 0 is a common pattern and most programmers will quickly recognize what is happening. But isEven(i) is just that much easier to grok and leaves that brainpower to work on something else.
But I would never import a package for it. I would just create a local helper for something this trivial.
Even if the code isn’t reused adding names to sub-expressions can be very valuable. Often times I introduce new functions or variables even if they are only used once so that I can give them a descriptive name which helps the reader more quickly understand what is happening.
Yeah, I do that with pretty much every separate operation in c# since our solutions are pretty big. Most of my JS scripts are just done in ServiceNow which are separated and named appropriately.
We have forced it, quite hamfistedly, to do anything. The organic hell-evolution of web browsers turned them into do-anything sandboxed mini-OS. It meant whatever hellish code you used to write your corporate mandated web app could now become a perfectly bloated standalone application. And the demonic language that would enable it was called Javascript. It does the backend and it does the frontend. You could consider those advantages over other devices, like toasters and those handheld electronic games from the 80s.
The part that always gets me is when people choose Js for the backend. Like I get that it’s the default thing that works on the frontend, so there’s some rationale why you might not want to transpile to it from another language. On the backend though, there are so many far better option, why would you willingly go with Js, especially given that you’re now forced to do all your IO async.
I moved from primarily ASP.Net Core backends, which is a hell of a great backend framework btw, to NestJS. Not my choice. I do what the people who sign my paychecks ask for.
I cannot begin to fathom why anyone would willingly choose JavaScript for backend. TypeScript helps a lot but there are still so many drawbacks and poor design decisions that make the developer experience incredibly frustrating. Features that are standard in ASP.Net Core, Django, or other common backend frameworks just don’t exist.
Also, don’t get me started on GraphQL. Sure, it has performance advantages for websites of a certain size and scale. But 99% of the websites out there don’t have the challenges that Facebook has. The added complexity and development cost over REST is just not worth it.
Yeah, gql in particular is a problem looking for a solution in most cases. It makes sense for facebook because they have people building frontend apps for their marketplace, and those apps need all kinds of weird combinations of data. However, this isn’t the situation for most apps where you have a fairly well defined set of calls you’re doing.
Server side rendering looks like it could be useful. I imagine SSR could be used for graceful degradation, so what would normally be a single page application could work without Javascript. Though, I’ve never tried SSR, and nobody seems to care about graceful degradation anymore.
Most pages tend be just documents and fairly simple forms. Making SPAs and then having to worry about SSR is just making a Rube Goldberg machine in most cases. I think something like HTMX is a much better approach in most cases. You keep all your business logic server side, send regular HTML to the client, and you just have a little bit of Js on the frontend that knows how to patch in chunks of HTML in the DOM as needed. Unless you have a highly interactive frontend, this is a much better approach than making a frontend with something like React and adding all the complexity that goes with it.
No one cares about graceful degradation anymore. But you can sell management on SEO. Page performance is a key aspect of search engine rankings and server-side rendered pages will almost always have a much faster initial load than client-side rendered.
No I meant having to do async as opposed to having threads like you would in Java for example. In vast majority of cases a thread pool will work just fine, and it makes your code far simpler. Typically, Java web servers will have a single thread that receives the request and then dispatches it to the pool of workers. The JVM is then responsible for doing the scheduling between the threads and ensuring each one gets to do work. You can do async too, but I’ve found threads scale to huge loads in practice.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
hmm, let’s see.
It’s not java.
It’s also not a scripting language.
also to the repeat grammar nazi in the comments here, hi, “its”
It’s not a scripting language?
bash would be a scripting language, though to be fair, i also consider bash to be pseudo code as well.
If JS is a scripting language, than any other language is a scripting language. And technically, every language can be used to script, so therefore, is a scripting language. i’m referring to the aspect of a scripting language being generally constricted.
Pseudo code is literally fake code. Scripting is an actual type of code. Scripted languages while not strictly defined, usually refers to languages you don’t compile before running them. Bash is considered a scripting language because you don’t ship a binary compiled executable, but rather ship a file that is human readable and converted into machine code when it is run. Scripting languages are compared to compiled languages, like C or Rust. Where the file you run is already compiled, and executed directly.
What do you mean by this?
Any Turing complete system, or this case language, can do anything any other one can, depending on the level of suffering you are willing to endure to make it happen. Anything JS can do, Rust can do. Anything Rust can do, Bash can do. The differences between languages is the assumptions they make, and performance characteristics as a result of those assumptions. Functionality is not practically different from one another, though some absolutely make it easier for humans to do.
hence why i specified why i consider it to be as such. I just think pseudo code shouldn’t exist. Plain and simple. Bash scripting is close to a language in the same way that pseudo code is also technically code.
i just mean the simple fact that you could technically probably run bash on windows, but really wouldn’t want to. I don’t consider bash to be a programming language, though it is technically a scripting language, because it’s primary existence is in the shell environment of a system. I.E. constricted, but that’s just my view of it.
Bash being on the same level as actually fake code is a pretty hot take to me. What are your opinions on Python, or Ruby, or any other interpreted language? You could very well use them as your login shell, just like Bash if you wanted. In your eyes, if Bash *isn’t * a programming language at all, how do you describe a programming language? Languages that express code are just the same as languages that write stories, and whether you do it in German or Vietnamese makes no difference on what story you can write.
When you describe a language as constricted what do you mean? Bash can do anything Python or Rust can do, each of them is just specialized to being better at specific aspects for human convenience in writing code. There is no inherit limitation on what can be done by the language you use to express it.
it’s definitely a hot take, you could theoretically use any other language as a shell, and i know you sort of can with stuff like node as well.
But those aren’t shell languages, and bash isn’t a true language, in the sense that it was explicitly designed to be used in the shell environment, i also consider it to be “pseudocode” because it’s not actually bash doing things a pretty significant amount of time you’ll stuff something into sed or awk, which are actually different interpreters all together.
bash is almost a sort of wrapper, between a bunch of different programs that all handle things differently, allowing you to glue them back together to make something usable. It’s close enough to being it’s own language, that you could make it one, but it’s not, because it’s not supposed to be one.
i suppose that’s pretty much what i mean when i say constricted.
Depends on how you define “scripting language”.
Older techs remember when it was only browser-based and they thought of, and perhaps still think of, “scripting languages” as something that would run from some command-line or another. Starting a GUI browser to run a mere script was a ridiculous concept. (There was also that JavaScript had no filesystem access. At least initially. And then it became a gaping security hole, but I digress.)
Today, there exist command-line accessible versions of JavaScript but even there (I figure) most people wince and choose anything else instead. Maybe even Perl.
But another definition of “scripting language” is “(any) interpreted programming language” and where it runs is unimportant.
From that perspective, sure, JavaScript qualifies. And so does QBASIC.
A script is just a file that can execute a series of commands without the need to compile
Are you referring to AOT compilation specifically? JavaScript in V8 is JIT compiled if it’s “hot” (executed enough that the cost of JIT compilation is less than the cost of continuing to run it in interpreted mode).
They compile in some point of time because CPU don’t know shit about Javascript. But that is for some other discussion.
Edit: typo
Hot take: A scripting language is a programming language whose execution starts from the beginning of the file | stream.
It definitely is a scripting language.
hello-world.js:Your favorite command line tool:
You just need to install
npm, eg viaapt-get install npm.everything is a scripting language if you try hard enough.
Browsers love it!
Practically anything you write will execute without all that scope and well formed statements nonsense.
Mind you, number 2 is also its biggest flaw as well, but…
Ajax.
Uhhh…
JIT compilation
Over what?
Death by wasps
Can I please pick the wasps?
Totally understandable choice.
Did a robot just ask to die because of JavaScript hahaha
The bot toggle was on for my account for some reason but I am human… I think
It should be off now
It seems it doesn’t propagate to other servers immediately though.
ROFL it is not
You’ll find an npm package to help you count up to 2.
(I recently learned - maybe here - that the is-even package has over 170k weekly downloads)
This must be a “hold my beer” kind of joke and someone wanting to see how far they can take it.
Is-even continues to be the best joke in the industry
Oh boy, this actually made me laugh out loud
What’s even wilder is if you look at the code of that package, all it does is include the is-odd package and then return !is-odd. And the is-odd package isn’t much better, it does some basic checks on the input and then returns n % 2 === 1.
I thought I was missing something. JS is one of my main languages and I always just write the is-odd function myself since it’s like 10 characters. It boggles the mind that is-even has 176k weekly downloads
To be fair having a name can make things easier to read. I get that
i % 2 == 0is a common pattern and most programmers will quickly recognize what is happening. ButisEven(i)is just that much easier to grok and leaves that brainpower to work on something else.But I would never import a package for it. I would just create a local helper for something this trivial.
Exactly what I would do if I had to reuse it, especially now since I know that adding a package would actually add 2. It all just seems so…inefficient
Even if the code isn’t reused adding names to sub-expressions can be very valuable. Often times I introduce new functions or variables even if they are only used once so that I can give them a descriptive name which helps the reader more quickly understand what is happening.
Yeah, I do that with pretty much every separate operation in c# since our solutions are pretty big. Most of my JS scripts are just done in ServiceNow which are separated and named appropriately.
If youre lazy/busy enough, doing basic checks on the input is enough boilerplate to package out.
Also there are 40-something packages depending on it, so I guess it gets pulled automatically when they are used.
I’ve always looked at stuff like that as much more along the lines of performance art than anything else.
It has a cup of coffee as logo
I want to create a political party in India. I need you as a candidate for next elections.
That’s Java, not Javascript. Java is to javascript as ham is to hamster.
Or butter to butterfly
Or car to carpet
Or fun to funeral
Moon to moonshine
awaitandasyncYou can make your speakers go BRRRRRRRRR via Home Assistant with it
Elaborate?
We have forced it, quite hamfistedly, to do anything. The organic hell-evolution of web browsers turned them into do-anything sandboxed mini-OS. It meant whatever hellish code you used to write your corporate mandated web app could now become a perfectly bloated standalone application. And the demonic language that would enable it was called Javascript. It does the backend and it does the frontend. You could consider those advantages over other devices, like toasters and those handheld electronic games from the 80s.
It runs in browsers. It… isn’t poop? I don’t know. I’m all out of ideas.
Half marks
It runs on mobile also. Hell it runs everywhere nowadays
3 billion devices worldwide?
Java-Script
https://www.youtube.com/watch?v=BLikP6BDH5w
Well, there’s a link that’s staying blue.
The part that always gets me is when people choose Js for the backend. Like I get that it’s the default thing that works on the frontend, so there’s some rationale why you might not want to transpile to it from another language. On the backend though, there are so many far better option, why would you willingly go with Js, especially given that you’re now forced to do all your IO async.
Is there a non sexist/queerphobic word for soydevs? Because soydevs are the ones who do that shit.
is there a non sexist/queerphobic meaning for that term? i would assume the bigotry is the whole point.
I moved from primarily ASP.Net Core backends, which is a hell of a great backend framework btw, to NestJS. Not my choice. I do what the people who sign my paychecks ask for.
I cannot begin to fathom why anyone would willingly choose JavaScript for backend. TypeScript helps a lot but there are still so many drawbacks and poor design decisions that make the developer experience incredibly frustrating. Features that are standard in ASP.Net Core, Django, or other common backend frameworks just don’t exist.
Also, don’t get me started on GraphQL. Sure, it has performance advantages for websites of a certain size and scale. But 99% of the websites out there don’t have the challenges that Facebook has. The added complexity and development cost over REST is just not worth it.
Yeah, gql in particular is a problem looking for a solution in most cases. It makes sense for facebook because they have people building frontend apps for their marketplace, and those apps need all kinds of weird combinations of data. However, this isn’t the situation for most apps where you have a fairly well defined set of calls you’re doing.
Server side rendering looks like it could be useful. I imagine SSR could be used for graceful degradation, so what would normally be a single page application could work without Javascript. Though, I’ve never tried SSR, and nobody seems to care about graceful degradation anymore.
Most pages tend be just documents and fairly simple forms. Making SPAs and then having to worry about SSR is just making a Rube Goldberg machine in most cases. I think something like HTMX is a much better approach in most cases. You keep all your business logic server side, send regular HTML to the client, and you just have a little bit of Js on the frontend that knows how to patch in chunks of HTML in the DOM as needed. Unless you have a highly interactive frontend, this is a much better approach than making a frontend with something like React and adding all the complexity that goes with it.
No one cares about graceful degradation anymore. But you can sell management on SEO. Page performance is a key aspect of search engine rankings and server-side rendered pages will almost always have a much faster initial load than client-side rendered.
You really should be doing your IO async. Do you specifically mean callback hell?
No I meant having to do async as opposed to having threads like you would in Java for example. In vast majority of cases a thread pool will work just fine, and it makes your code far simpler. Typically, Java web servers will have a single thread that receives the request and then dispatches it to the pool of workers. The JVM is then responsible for doing the scheduling between the threads and ensuring each one gets to do work. You can do async too, but I’ve found threads scale to huge loads in practice.
Green threads are functionally the same, especially in languages that can preempt.
Sure, but the scheduler figures out the scheduling automatically so you don’t have to worry about stuff like blocking.