Don't test...not even in production!

[Gribnit]

@Arantor well, all the DOM is is a decorated scene graph and all a scene graph is doing is dividing the problem of what to do each refresh, HTH GTG

[dkf]

@Gribnit said in Don't test...not even in production!:

@Arantor well, all the DOM is is a decorated scene graph and all a scene graph is doing is dividing the problem of what to do each refresh, HTH GTG

The only way that the DOM could be a worse experience is if it was made by @mikeTheLiar in Boston.

[Gribnit]

@Arantor said in Don't test...not even in production!:

@dkf I believe that was my original point on some level.

I don't. It was @dkf's. If it wasn't, it is now.

However, my decisions are not binding (in this matter) and a Point Ownership and Origin Tribunal must needs be assembled to even approach a real determination here.

[Gribnit]

@dkf said in Don't test...not even in production!:

Programming languages can't fix stupid... except by driving it away and becoming irrelevant because there aren't enough users at all.

Yay! Haskell fixes stupid!

[Gribnit]

@dkf said in Don't test...not even in production!:

@Gribnit said in Don't test...not even in production!:

@Arantor well, all the DOM is is a decorated scene graph and all a scene graph is doing is dividing the problem of what to do each refresh, HTH GTG

The only way that the DOM could be a worse experience is if it was made by @mikeTheLiar in Boston.

Well, I did say decorated...

[TheCPUWizard]

@Unperverted-Vixen said in Don't test...not even in production!:

The Electron "issue" is that you can't force users to download a new version of the desktop app.

Ahh, but with some initial design you can (or at least can stop the "old" app from functioning.

[izzion]

@TheCPUWizard said in Don't test...not even in production!:

with some initial design

Found your fallacy

[konnichimade]

@Kamil-Podlesak node doesn't have native fetch? :(

[Arantor]

@konnichimade said in Don't test...not even in production!:

@Kamil-Podlesak node doesn't have native fetch? :(

Yes, but as mentioned people prefer axios for “reasons”.

[Kamil Podlesak]

@Arantor said in Don't test...not even in production!:

@konnichimade said in Don't test...not even in production!:

@Kamil-Podlesak node doesn't have native fetch? :(

Yes, but as mentioned people prefer axios for “reasons”.

Native fetch has been added in node 18, released on 2022-04-19

Yes, this year.
And it is, of course, marked as "Experimental" and otherwise left completely undocumented.

But yes, node now has native fetch.

[Arantor]

@Kamil-Podlesak there are people who aren’t me running Node that isn’t bleeding edge?

Also, the folks who evangelise the benefits of client/server code reuse never seem to talk about things like node-fetch in this situation, as a polyfill until native support and instead go for a bigger package that makes life “better”.

[Bulb]

@Arantor said in Don't test...not even in production!:

@Kamil-Podlesak there are people who aren’t me running Node that isn’t bleeding edge?

Yes. We still have the Dockerfiles set to 16 around here.

Also, the folks who evangelise the benefits of client/server code reuse never seem to talk about things like node-fetch in this situation, as a polyfill until native support and instead go for a bigger package that makes life “better”.

Client/server code reuse? Isn't it overrated? I mean, you only should do each thing at one place, shouldn't you? Which leaves basically data type definitions, which is what swagger is for.

[Zecc]

@Arantor said in Don't test...not even in production!:

@Kamil-Podlesak there are people who aren’t me running Node that isn’t bleeding edge?

I'm not telling you which version we run, because I'm not in the mood of being laughed at.

...

Fine, I'll give you this: it's under Windows.

[Gribnit]

@Bulb said in Don't test...not even in production!:

Client/server code reuse? Isn't it overrated?

Real client-server code reuse has never been tried.

ES0xFE is doing its best to obviate the case for custom control-structures by rolling every possible form of functional goo in as syntactic sugar, but higher-order function libraries, and maybe some image and string code, are still about the limit. The client and the server are YES, doing different things.

Now, if you want more ways to put things places they probably shouldn't, tho, you do need a common language between clients and services to really blow the doors off. Ideally have services generating code that clients are passing to other services to pass to other clients to run.

[Arantor]

@Bulb of course it is, that’s kind of my point. Node’s entire premise kinda hinges on “but you can reuse the code in the server as well as the client” which was never a stellar reason, but it’s a reason that’s still trotted out.

The async/event polling gig has other options on the backend so it’s not like it’s your only choice there.

Also I was being facetious, Node seems to attract the bleeding edge folk who feel the need to reinvent and update things a little too regularly.

(I have stuff on Node 12, 14 and 16 for the record.)

[Bulb]

@Arantor said in Don't test...not even in production!:

@Bulb of course it is, that’s kind of my point. Node’s entire premise kinda hinges on “but you can reuse the code in the server as well as the client” which was never a stellar reason, but it’s a reason that’s still trotted out.

I thought it was more about reusing the skills, as in have a team of developers who can work on any part of the system.

… which might have something for simple quick-hack applications worth of three man-months of effort, but in anything bigger the language will be the easy part and the hard part will be understanding the application and the frameworks used and the developers won't be easily able to jump to other parts any more either.

The async/event polling gig has other options on the backend so it’s not like it’s your only choice there.

The async/event polling gig is a virtue out of necessity because a dynamic language runtime has basically choice of being absurdly slow (python) or single threaded (javascript, but effectively python also).

Then it turned out that user-land scheduling of the small tasks is, surprisingly, quite a bit more efficient, so other languages joined in. Surprisingly, because the reason is not that it would save any system calls or task switches. There is still as many of those—Linux io_uring does save some, but that's not used in most of the runtimes yet. The reason turns out to be that the task scheduler, knowing how the tasks depend on each other, does a lot better job of maintaining CPU affinity than the kernel scheduler, without that knowledge, does, and doing that makes much better use of the CPU caches.

I've actually searched for that, and got to an article saying Windows fibres (which do the useland context switching, but otherwise behave like threads) are as bad as threads (and therefore deprecated), and a presentation (quite old, from 2013 or so) saying they made threads as fast as the event loops with addition of experimental system calls for controlling the scheduler.

But async/await also complicates the code quite a bit and has its own surprises. Stackful coroutines, that is normal threads, are easier to use. And Go shows that they can be made just as efficient by using similar scheduler underneath as the event loops use, and discontinuous stacks to avoid wasting address space.

It is harder though, so many other languages still went the easier async/await way.

Also I was being facetious, Node seems to attract the bleeding edge folk who feel the need to reinvent and update things a little too regularly.

(I have stuff on Node 12, 14 and 16 for the record.)

I should have said that the Dockerfile with 16 is one that I wrote a month or two ago to upgrade node from some antediluvial version that the build agent had because new Angular wasn't working with it any more.

[kazitor]

@Bulb said in Don't test...not even in production!:

Client/server code reuse? Isn't it overrated?

pssst! When they talk of using the same language, what they mean is “I don’t have to learn another.”

[topspin]

@kazitor said in Don't test...not even in production!:

@Bulb said in Don't test...not even in production!:

Client/server code reuse? Isn't it overrated?

pssst! When they talk of using the same language, what they mean is “I don’t have to learn another.”

Maybe it’d help if they started learning their first.

I’ll leave it open if I’m talking about JS devs or Americans.

[dkf]

@Bulb said in Don't test...not even in production!:

The async/event polling gig is a virtue out of necessity because a dynamic language runtime has basically choice of being absurdly slow (python) or single threaded (javascript, but effectively python also).

There are other options, such as apartment threading. That has good performance as you avoid most resource sharing, but limits inter-thread interactions mainly to messaging.

Python is horribly slow for many reasons, not least of which is just how many uncacheable dictionary lookups it needs to do just to run ordinary code. That it has a bad thread implementation is just par for the course. (The thread implementation is literally terrible. I've had CPU-intensive tasks block I/O-bound threads for minutes at a time, causing app failures when the server it was talking to timed out the session...)

Then it turned out that user-land scheduling of the small tasks is, surprisingly, quite a bit more efficient, so other languages joined in. Surprisingly, because the reason is not that it would save any system calls or task switches. There is still as many of those—Linux io_uring does save some, but that's not used in most of the runtimes yet. The reason turns out to be that the task scheduler, knowing how the tasks depend on each other, does a lot better job of maintaining CPU affinity than the kernel scheduler, without that knowledge, does, and doing that makes much better use of the CPU caches.

But async/await also complicates the code quite a bit and has its own surprises. Stackful coroutines, that is normal threads, are easier to use. And Go shows that they can be made just as efficient by using similar scheduler underneath as the event loops use, and discontinuous stacks to avoid wasting address space.

It is harder though, so many other languages still went the easier async/await way.

The thing with async/await is that it is easy to get going in the simple case where you don't want to suspend things in the middle of a called function. It is only when things get more complex (typically after a few releases) that you run into the horrible mess of function colouring cancer and realise you've made a ghastly infectious blunder.

Tcl has a mixture of stackful coroutines and apartment threading, and is one of the faster scripting languages as a consequence. (Compiling it beyond its bytecode remains deeply experimental. Advanced compilers are quite difficult to write, and not everyone has the resources that V9 had poured into it.)

[Bulb]

@dkf said in Don't test...not even in production!:

@Bulb said in Don't test...not even in production!:

The async/event polling gig is a virtue out of necessity because a dynamic language runtime has basically choice of being absurdly slow (python) or single threaded (javascript, but effectively python also).

There are other options,

Being referentially transparent, at least mostly. Though Erlang isn't a paragon of performance either.

such as apartment threading. That has good performance as you avoid most resource sharing, but limits inter-thread interactions mainly to messaging.

Perl provides threads where you explicitly opt in into sharing, but I don't think I've seen anybody actually use it.

Python is horribly slow for many reasons, not least of which is just how many uncacheable dictionary lookups it needs to do just to run ordinary code. That it has a bad thread implementation is just par for the course. (The thread implementation is literally terrible. I've had CPU-intensive tasks block I/O-bound threads for minutes at a time, causing app failures when the server it was talking to timed out the session...)

The Big Interpreter Lock means it effectively does not have threads. Yeah, saying it cannot usefully do threads and doing async from earlier on like JavaScript did (especially since most of the infrastructure was actually there in the form of generators) would have been better.

Then it turned out that user-land scheduling of the small tasks is, surprisingly, quite a bit more efficient, so other languages joined in. Surprisingly, because the reason is not that it would save any system calls or task switches. There is still as many of those—Linux io_uring does save some, but that's not used in most of the runtimes yet. The reason turns out to be that the task scheduler, knowing how the tasks depend on each other, does a lot better job of maintaining CPU affinity than the kernel scheduler, without that knowledge, does, and doing that makes much better use of the CPU caches.

But async/await also complicates the code quite a bit and has its own surprises. Stackful coroutines, that is normal threads, are easier to use. And Go shows that they can be made just as efficient by using similar scheduler underneath as the event loops use, and discontinuous stacks to avoid wasting address space.

It is harder though, so many other languages still went the easier async/await way.

The thing with async/await is that it is easy to get going in the simple case where you don't want to suspend things in the middle of a called function. It is only when things get more complex (typically after a few releases) that you run into the horrible mess of function colouring cancer and realise you've made a ghastly infectious blunder.

It also behaves differently in each language. For example in some languages the async tasks start running immediately, while in others they only run when they are awaited.

Tcl has a mixture of stackful coroutines and apartment threading, and is one of the faster scripting languages as a consequence. (Compiling it beyond its bytecode remains deeply experimental. Advanced compilers are quite difficult to write, and not everyone has the resources that V9 had poured into it.)

Unfortunately TCL is rarely used, which means it does not have as many libraries, which means it is rarely used. Possibly because it effectively missed the object oriented rage.

[Luhmann]

@Arantor said in Don't test...not even in production!:

go for a bigger package

[dkf]

@Bulb said in Don't test...not even in production!:

Possibly because it effectively missed the object oriented rage.

That was one thing it didn't miss out on. There were multiple OO systems for it. That were incompatible with each other in fundamental ways (e.g., different expectations in how you create objects for example, with most either being C++-like or Smalltalk-like). There are only three left in practice now, and one of those is implemented on top of another (which was internally inspired by the semantics of the third despite rejecting the syntax because Smalltalk's just too damn weird for a language with normally-variadic functions).

It's never gone for the make-the-primitive-values-objects approach, which has always meant that it was OO-light at best.

Unfortunately TCL is rarely used, which means it does not have as many libraries, which means it is rarely used.

That is very true. It reduces the churn of stupid too, but I miss having some things.

[Bulb]

@dkf said in Don't test...not even in production!:

@Bulb said in Don't test...not even in production!:

Possibly because it effectively missed the object oriented rage.

That was one thing it didn't miss out on. There were multiple OO systems for it. That were incompatible with each other in fundamental ways (e.g., different expectations in how you create objects for example, with most either being C++-like or Smalltalk-like). There are only three left in practice now, and one of those is implemented on top of another (which was internally inspired by the semantics of the third despite rejecting the syntax because Smalltalk's just too damn weird for a language with normally-variadic functions).

Without an official one being picked that's effectively the same thing.

Also, split community is really bad for a language. Take for example D. There was an alternative, incompatible standard library for it and that was really detrimental to its adoption in the period when it would have had a chance.

It's never gone for the make-the-primitive-values-objects approach, which has always meant that it was OO-light at best.

In TCL, everything is a string (even though it's not stored as one if it is used as something else), isn't it?

[stillwater]

I don't understand the "you can use the same language across the backend and frontend omg omg amazing" argument.

Let us take a step back and look at the languages we've been using. There used to be Java or C# or scala or whatnot and then JS on the frontend when required, SQL for the database. Python or Bash or Powershell for some scripts and it was all a mix and nobody had a single problem switching between them. Even context switching between languages when your'e working on an end-to-end feature was not a big deal.

I understand this is easy because we're used to it. And even then it was not a big fucking deal. Using JS everywhere is not fucking cool. some cunt once wrote JS on Azure functions and it had so many hard-to-trace issues because of fucking undefined here and there.

The solution to all this is - ADD TYPES TO JS TYPESCRIPTTTTTTTTTTT

Have some self respect and learn a couple languages maybe, how hard is it? I am tired of this JS everywhere BS fucking POS everyone can go die.

[Bulb]

@stillwater said in Don't test...not even in production!:

There used to be Java or C# or scala or whatnot and then JS on the frontend when required, SQL for the database. Python or Bash or Powershell for some scripts and it was all a mix and nobody had a single problem switching between them.

There is a lot of programmers who do have problems with that. Hell, a bunch of Java programmers around here get cooties when it's even suggested that they could use Kotlin (which is approximately just an alternative syntax for Java) on the project.

@stillwater said in Don't test...not even in production!:

Have some self respect and learn a couple languages maybe, how hard is it? I am tired of this JS everywhere BS fucking POS everyone can go die.

Having worked with a dozen or two languages in my life I wholeheartedly agree. Unfortunately there is a lot of programmers who, likely due to laziness, don't want to.

[Arantor]

I hazard the opinion that many people who vomit out JavaScript achieve such feats because you can keep hammering at it until it sorta works, but that other languages have “standards” and expect you to follow them more closely.

That and it feels like there’s npm packages for everything so building in JS is more like building in Lego these days.

[Gribnit]

@Arantor said in Don't test...not even in production!:

LegoDuplo

[Arantor]

@Gribnit yes.

[Bulb]

@Arantor said in Don't test...not even in production!:

I hazard the opinion that many people who vomit out JavaScript achieve such feats because you can keep hammering at it until it sorta works, but that other languages have “standards” and expect you to follow them more closely.

Most languages you can hammer until it sorta works. It is true that JS is particularly lenient, especially with type coercions, but that makes your hammer-check-rinse-repeat loop longer rather than shorter.

That and it feels like there’s npm packages for everything so building in JS is more like building in Lego these days.

That's just as true of Java, C#, Go, PHP, Ruby, Python etc., and Perl had a central package repository before JavaScript even existed.

[Gribnit]

@Bulb said in Don't test...not even in production!:

suggested that they could use Kotlin

Your post has given me cooties.

[dkf]

@Bulb said in Don't test...not even in production!:

In TCL, everything is a string (even though it's not stored as one if it is used as something else), isn't it?

Yes. The types of all values are considered to be subtypes of string. Of course, this isn't a "that means it's stored as one" kind of subtype notion; it's a well-founded type logic, but really very different in its implications to what most people are used to. So it's a qualified yes.

Commands, variables and I/O channels aren't strings, but their names are. There's a clear separation between the things and the names of the things. (And the lookup process is optimised so it is usually about as costly in practice as a pointer dereference. That's one of the bits that the Python implementations can't do because they have too naïve a notion of strings.)

[Gribnit]

@dkf said in Don't test...not even in production!:

That's one of the bits that the Python implementations can't do because they have too naïve a notion of strings.

Anything like symbol(String) even? In Macromedia Common Lingo (so, probably Smalltalk) that at least allowed for optimizing the lookups for names of things. If I remember my lineages correctly it'd be more likely in TCL than Python, but I'm not even sure you're not talking about Tandem Control Language.

[Arantor]

@Bulb not like npm though.

npm has apparently something like 1.3 million packages, vs the 209k in CPAN (Perl), the 354k for Packagist (PHP)… the Node numbers always worry me.

[dkf]

@Bulb said in Don't test...not even in production!:

Without an official one being picked that's effectively the same thing.

Yes. An official one was picked (and carefully optimised to be quite a bit faster than the competition while also being more powerful), but the others were not deliberately sabotaged because that would be really very hostile indeed.

Also, split community is really bad for a language. Take for example D. There was an alternative, incompatible standard library for it and that was really detrimental to its adoption in the period when it would have had a chance.

I know. What we've seen is that stuff has gradually cut over to the new base in order to get the better performance. There are two hold-outs, one of which has actually been reimplemented on top of the standard one (with about 99.5% compatibility with the old code). The other... is just too weird, and has a sufficiently large community of its own to keep going. The core differences there relate to how things should be used and the differences between method chaining and variadics; if you have one, then you can't safely have the other. (The consequences of that are a lot deeper than they appear at first; it's like someone pulling on a little thread and watching a whole garment unravel.)

Fortunately, it's not catastrophic. You can have both in the same program calling each other (the normal method calling interface is one of the things that is agreed upon as there's only one sensible way to do it) and it's no more a problem than calling any other library code. You just can't have them in the same class hierarchy, or use them in the same way. It's a split, but it's amicable and manageable.

[dkf]

@stillwater said in Don't test...not even in production!:

The solution to all this is - ADD TYPES TO JS TYPESCRIPTTTTTTTTTTT

I'm happy to say that Typescript is better than Javascript. I don't need to concede that it is even close to good to say that...

[Bulb]

@Arantor I think the Node numbers are due to two factors: One, JavaScript is a batteries excluded language, so there is a lot of leftpad-style utilities that the other languages simply don't have a need for, because they have enough facilities in the standard library to care for these needs. And two, where Perl or PHP packages tend to be comprehensive for some domain, Node packages tend to be split up to bambillion smaller modules.

[stillwater]

@dkf Again the problem here is not the language as much the people around it. A good chunk of the codebase devolves into just plain old JS at one point because adhering to type checks when writing JS gives these people the very kind of friction that prevented them from learning more than one language to use on the front end and back end in the first place

[stillwater]

@Bulb Laziness at learning other languages I understand. When that same laziness leaks onto not learning how to write JS properly, well that hurts everyone. Also debugging with some of the frameworks is such a pain that I use console.log liberally everywhere.

[dkf]

@Gribnit said in Don't test...not even in production!:

Anything like symbol(String) even? In Macromedia Common Lingo (so, probably Smalltalk) that at least allowed for optimizing the lookups for names of things. If I remember my lineages correctly it'd be more likely in TCL than Python, but I'm not even sure you're not talking about Tandem Control Language.

It's a bit tricky to describe without delving deep into the detail. Think of it like there's some provenance metadata on the string value itself, and the pointer to the thing it resolves to is attached to that metadata. It would be unsafe if the strings were mutable, and horrible if they were shared between threads. But they aren't and they aren't.

[Gribnit]

@dkf said in Don't test...not even in production!:

@Gribnit said in Don't test...not even in production!:

Anything like symbol(String) even? In Macromedia Common Lingo (so, probably Smalltalk) that at least allowed for optimizing the lookups for names of things. If I remember my lineages correctly it'd be more likely in TCL than Python, but I'm not even sure you're not talking about Tandem Control Language.

It's a bit tricky to describe without delving deep into the detail. Think of it like there's some provenance metadata on the string value itself, and the pointer to the thing it resolves to is attached to that metadata. It would be unsafe if the strings were mutable, and horrible if they were shared between threads. But they aren't and they aren't.

Sounds like what ObjectiveC could do (if it wanted) with typed strings. I'm wondering if Python even allows a degenerate approach based on a separate LUT.

[Bulb]

@stillwater said in Don't test...not even in production!:

@Bulb Laziness at learning other languages I understand. When that same laziness leaks onto not learning how to write JS properly, well that hurts everyone. Also debugging with some of the frameworks is such a pain that I use console.log liberally everywhere.

Throughout most of my career, no matter what I was programming in, I almost always concluded trying to step through the code is a futile effort and resorted to just logging heaps of stuff and then divining from the logs as if they were chicken entrails anyway. Sometimes because the language did not have a debugger that was any good, sometimes because the program was running on a target to which the debugger wasn't either willing to connect or capable of loading good enough debug information to be actually useful, and the rest of the time because debugging broke the chain of events e.g. by pausing the other threads so they didn't get around to breaking the thing.

[dkf]

@Gribnit said in Don't test...not even in production!:

I'm wondering if Python even allows a degenerate approach based on a separate LUT.

It would be a very large piece of work, because the fundamental APIs used at the Python bytecode engine implementation level would need to change so that it is possible to store the cached lookups somewhere. However, if I remember right they're passing C (or perhaps C++) strings at that point and there's just nowhere to do anything sophisticated at that point.

Another way to look at it is like this: in C++ and Python, strings are a class, whereas in Tcl's implementation they're more like an interface (with PIMPL trickery done under the covers). That gives room for doing complicated stuff.

[dkf]

@Bulb said in Don't test...not even in production!:

@stillwater said in Don't test...not even in production!:

@Bulb Laziness at learning other languages I understand. When that same laziness leaks onto not learning how to write JS properly, well that hurts everyone. Also debugging with some of the frameworks is such a pain that I use console.log liberally everywhere.

Throughout most of my career, no matter what I was programming in, I almost always concluded trying to step through the code is a futile effort and resorted to just logging heaps of stuff and then divining from the logs as if they were chicken entrails anyway. Sometimes because the language did not have a debugger that was any good, sometimes because the program was running on a target to which the debugger wasn't either willing to connect or capable of loading good enough debug information to be actually useful, and the rest of the time because debugging broke the chain of events e.g. by pausing the other threads so they didn't get around to breaking the thing.

Running a debugger when an application has parts running on multiple computers and in multiple security contexts can be a bit tricky.

[Kamil Podlesak]

@Bulb said in Don't test...not even in production!:

@stillwater said in Don't test...not even in production!:

There used to be Java or C# or scala or whatnot and then JS on the frontend when required, SQL for the database. Python or Bash or Powershell for some scripts and it was all a mix and nobody had a single problem switching between them.

There is a lot of programmers who do have problems with that.
Hell, a bunch of Java programmers around here get cooties when it's even suggested that they could use Kotlin (which is approximately just an alternative syntax for Java) on the project.

It's actually less about programmers; quite a lot of us are enthusiastic to and learn new things.
Problem is that from perspective, it's just a wasted time.

Especially in the area of "tailored enterprise solution", where the project ideally consist just of some configuration changes, pixel-perfect CSS (because marketing agency...) and some code tweak here and there. Project Manager can get budget for a JavaScript developer, because there is no way around it, but good luck trying to get a Java one (for Java prices).

Hell, a bunch of Java programmers around here get cooties when it's even suggested that they could use Kotlin (which is approximately just an alternative syntax for Java) on the project.

Try suggesting XSLT and you'll see the terror in their eyes
but wait for the last day of this month, so you can pass it as a "Halloween joke"

[Bulb]

@dkf I didn't even get to that level of tricky. Debugger starts to already be pretty useless when the application crashes on a value that is being set, to obviously invalid value, when handling some unrelated event earlier in a different thread, and you start with not even having idea which event.

Though sometimes that's where gdb's watchpoints may come in very handy. Together with its commands. Like

> p &something->member.whatever
$2 = 0x53fa3604
> watch *$2
> cmd
> p *something
> bt
> c
> end
> run

The trick with printing it and watching the address rather than the expression is to make it use a hardware watchpoint, because using a software one is uselessly slow (as in waiting days instead of seconds).

Gdb is the only debugger where this ever worked for me, and only on the right platforms. That is, I don't think I ever got it to work when connecting to an ARM target.

Edit: I forgot the most important bit, the c(ontinue).

[Kamil Podlesak]

@Kamil-Podlesak said in Don't test...not even in production!:

Hell, a bunch of Java programmers around here get cooties when it's even suggested that they could use Kotlin (which is approximately just an alternative syntax for Java) on the project.

Try suggesting XSLT and you'll see the terror in their eyes
but wait for the last day of this month, so you can pass it as a "Halloween joke"

Actually, that reminds me: trivia question

Everyone knows terms like claustrophobia (irrational fear of closed spaces), arachnophobia (irrational fear of spiders) and coulrophobia (irrational fear of clowns).
Do you know the term for irrational fear of XSLT?

Since I don't know how to make collapsing block, I put the answer in abbr

[Bulb]

@Kamil-Podlesak said in Don't test...not even in production!:

@Bulb said in Don't test...not even in production!:

@stillwater said in Don't test...not even in production!:

There used to be Java or C# or scala or whatnot and then JS on the frontend when required, SQL for the database. Python or Bash or Powershell for some scripts and it was all a mix and nobody had a single problem switching between them.

There is a lot of programmers who do have problems with that.
Hell, a bunch of Java programmers around here get cooties when it's even suggested that they could use Kotlin (which is approximately just an alternative syntax for Java) on the project.

It's actually less about programmers; quite a lot of us are enthusiastic to and learn new things.
Problem is that from perspective, it's just a wasted time.

Especially in the area of "tailored enterprise solution", where the project ideally consist just of some configuration changes, pixel-perfect CSS (because marketing agency...) and some code tweak here and there. Project Manager can get budget for a JavaScript developer, because there is no way around it, but good luck trying to get a Java one (for Java prices).

Depends on the environment. Around here the architect could often justify a better tool if the team was willing to learn it and team members not willing to learn it is the main obstacle.

Hell, a bunch of Java programmers around here get cooties when it's even suggested that they could use Kotlin (which is approximately just an alternative syntax for Java) on the project.

Try suggesting XSLT and you'll see the terror in their eyes
but wait for the last day of this month, so you can pass it as a "Halloween joke"

That was different projects, but I've seen some absolutely humongous XSLT files. Folks are fond of XML here.

I also wrote one back in the day that was compiling XML screen layout (produced by quick-hack C# tool via serializer) to C++.

[Gribnit]

@Kamil-Podlesak said in Don't test...not even in production!:

Try suggesting XSLT

XSLT is easy.

[Kamil Podlesak]

@Bulb said in Don't test...not even in production!:

@Kamil-Podlesak said in Don't test...not even in production!:

@Bulb said in Don't test...not even in production!:

@stillwater said in Don't test...not even in production!:

There used to be Java or C# or scala or whatnot and then JS on the frontend when required, SQL for the database. Python or Bash or Powershell for some scripts and it was all a mix and nobody had a single problem switching between them.

There is a lot of programmers who do have problems with that.
Hell, a bunch of Java programmers around here get cooties when it's even suggested that they could use Kotlin (which is approximately just an alternative syntax for Java) on the project.

It's actually less about programmers; quite a lot of us are enthusiastic to and learn new things.
Problem is that from perspective, it's just a wasted time.

Especially in the area of "tailored enterprise solution", where the project ideally consist just of some configuration changes, pixel-perfect CSS (because marketing agency...) and some code tweak here and there. Project Manager can get budget for a JavaScript developer, because there is no way around it, but good luck trying to get a Java one (for Java prices).

Depends on the environment. Around here the architect could often justify a better tool if the team was willing to learn it and team members not willing to learn it is the main obstacle.

I also wrote one back in the day that was compiling XML screen layout (produced by quick-hack C# tool via serializer) to C++.

Yes, of course, it's different in a company with many, many developers (or even outright software company). It's very different for a company that has basically no in-house developers (except the sysadmin and the guy in accounting with huge spreadsheet) and need to bodyshop some consultants.

[Bulb]

@Kamil-Podlesak said in Don't test...not even in production!:

It's a trick question - there is nothing irrational about fear of XSLT!

There is. Besides being somewhat verbose there is nothing wrong with XSLT.</>

Since I don't know how to make collapsing block, I put the answer in abbr

It's easy

<details><summary>It's easy</summary>

<?recurse?> *:up_arrow: that line break is important to get anything but plain text to render - bz]*
</details>