Julia is a smelly pile of steaming shit.
https://discourse.julialang.org/t/...

Jesus fucking christ would you look at that pile of pure utter shit. The dumbfuck dev somehow managed to break WHILE loops for devs coming from python, and I speak for myself and probably others when I write most of us python developers are functionally braindead. If you can somehow fuck it up for python devs, a significant portion of the people you're trying to attract (owing by the syntax), then you should probably just go head and delete your whole git repo now.

Julia is a prime example of why you don't listen to your users on fucking github about the direction of language development.

What a bunch of fucking booger eating retards.

for loops not being able to use variables declared outside the for loop is absolutely retarded.

@kescherRant

I just wanted to highlight this abortion of a language for some especially vitriolic scorn.

Edit: I took the liberty of following their example, and imagine my fucking surprise when their solution *didn't even fucking work*. Global is broken in the build I'm using.

Finally found someone who mentioned wrapping the entire thing in a *let* block and boom, it worked as it should have to begin with.

@kescherRant It is possible, you just have to do a global declaration, and for a damn good reason: if you don't declare to use a global variable inside an iterable block of code, that block can be safely executed in paralel, giving insane speedup on manycore processors out-of-the-box, while having minimal impact on code readability & compilation / execution time. Try to compare that with OpenMP...

@hitko Yes, that's cool and all, but what if I don't even want that for a particular piece of code? Why do I HAVE TO tell it to "use this particular global variable"? It's something that annoys me with Python as well, when literally any other language (ok not all of them but most) allows me to be thread-unsafe when I want to.

@kescherRant Because the other options are either using special comments and manually verifying code is side effect free (OpenMP style), or letting compiler figure out which loop can be executed in paralel and learning a whole bunch of hacks to force the desired behaviour.

@hitko I like the approach if OpenMP more then, I guess.

I was hoping this would be a reason to tell my boss that julia sucks but its not.

Let me explain, julia is somewhat functional. In fp, if you have a thing that you modify from a function, thats called a side effect and thats a big no-no ladies.

@tekashi

The problem with that theory is I tried declaring global outside. Declaring global inside. Declaring it before using the variable. Declaring it while using the variable.

It kept on giving me the same error. As bad and broken as the design decision to make fucking WHILE blocks lexically scoped is, even I, as incompetent as I am, can only conclude julia is fucky for no good reason.

@Wisecrack In 99% of the cases when you're having a side effect in FP, you either havn't been doing it correctly with regard to FP, or FP is unsuited to your problem.

For the remaining 1%, there are always ways to work around the paradigm. They're awkward, but it doesn't matter because it's rarely needed.

This is one of the reasons I dislike interpreted languages: an update to the language can easily break previously-working code. This is exacerbated by package managers that optimistically update dependencies with newer versions. After a bit of sitting, some projects are simply broken and require updating/rewriting before they'll function again.

Code shouldn't rot.

A language modeled after python is bad?? No way!

> I speak for myself and probably others when I write most of us python developers are functionally braindead

No... you're just speaking for yourself there. Cheers.

@Root "Code shouldn't rot"

Funny, I was thinking about that just recently. Code does rot, there's nothing you can do about it.

Libraries and frameworks become deprecated and then abandoned sooner or later. The language's standard library usually takes longer, but still it's going to rot. Heck, even the language itself will either change or get replaced.

When you drive your shiny new car from the car dealer's grounds it's already losing value. The brand new computer you're leaving the shop with is already outdated. The line of code you just wrote, well, it's already legacy code.

@VaderNT You are right, of course, but that's not quite what I meant.

Your code will eventually stop working, that's true. And there really isn't any way of stopping that short of keeping legacy systems around intact. but it should happen over years, not weeks or months. It should also be mostly because of hardware changes, not on someone's whim of a "new best practice." Some exceptions exist, of course, like security changes.

I suppose what I'm actually angry over is frontend, and how everything is an ever-changing mess of flaw-riddled bloatware.

@VaderNT You can still compile C code from 30 years ago just by using "-std=c89" even with an up to date GCC.

@Fast-Nop The standard libraries and compilers act as that needed wrapper. They can absolutely allow ancient code to be ported to new hardware (and even standards) without modification. As long as someone maintains their backwards-compatibility features, code won't rot.

@Root That's the thing - there ARE standards. Actual standards, I mean, not just someone letting out a fart and declaring it as standard. One consequence is that you have multiple vendors implementing these standards.

I have C code from the mid-90s that I used with Borland-C under DOS, and it works today with GCC under Linux.

@VaderNT the difference between python devs who think they are braindead and python devs who think they arent is that the ones who think they are braindead usually arent

@Root I don't really see many examples of code rot like you're describing. The major interpreted languages like python and JavaScript are very careful of their backwards compatibility. Python supported Py2 forever. Maybe the smaller, more "hipster" languages rot pretty badly. But the issue there is your choice of interpreted language, not the nature of all interpreted languages.

@tekashi I thought you were going to say "the difference between python devs who think they are braindead and the python devs who think they arent is that the ones who think they are braindead are right"

@AlgoRythm PHP introduces breaking changes even in minor releases. But then again, PHP has a track record of being a good example for, uh, bad examples.

@Fast-Nop Have they? I am not familiar enough with PHP or it's history.

@AlgoRythm Well I guess that's more historic than current reality because they have improved a lot. But back when it started, it was not really meant as language (more as quick & dirty toolset), and its creator Lerdorf had no experience in language design.

So here my all-time fav: they had a hashing function which was strlen (yes, string length!), and PHP command names were chosen so that they had better distribution in the dictionary. In other words, the naming was partly a result of fudging around with the command string lengths. Hard to beat on the WTF scale.

But still, even nowadays, version 7.3 does list stuff that is incompatible to version 7.2, which is not what you would expect.

@Fast-Nop Yeah, I wouldn't really count stuff from early days but it's a bit ridiculous that they would break backwards compat on minor versions.

Like you said, PHP has never had a shiny reputation. Though today I think it's a rather valid tool with poor users.

@AlgoRythm I've had several javascript projects break while idle. I didn't even cd into the directory for months at a time, then start the project and get dependency errors. I blame NPM for that shit, but NPM is kind of the centerpiece of frontend development.

Also, best practices change by the month, and things can start getting deprecated after several months. Frontend changes so blazingly fast, it's basically impossible to keep up to date unless it's your passion or part of your job.

@Root NPM is a different story, it's got nothing to do with Node or JS. Everyone knows NPM is a shitshow. JS itself hasn't broken backwards compat as long as I can remember, and I don't think there has been any major example of Node doing so either.

@AlgoRythm I haven't seen anything from JS either. Node somewhat, as there's e.g. a new means of seeing if a file exists or not seemingly every freaking version. but NPM is indeed a shitshow.

@Root Lol yeah the olde file.exists file.existsSync file.stat debacle. They keep changing it because that's not how you're supposed to check anyways.

@Fast-Nop

Yeah but if I write a post on PHP thats just milking the hate bandwagon, that would be like playing on easy mode.

Now I'm tempted.

@12bitfloat

Damn, Guido needs to go to the burn clinic. Wish I had thought of that one!

@Root Frontend is riddled with bad practice, and it has become so bad that you can safely assume that the established practice is automatically crap.

After all, the sad state of the average website leaves only the conclusion that the average frontend dev is a completely incompetent idiot even BEFORE the marketing wankers come into play.

The advantage is that you don't need to jump the bandwagon because it's invariably a manure lorry anyway.

@Fast-Nop "You can still compile C code from 30 years ago (...) with an up to date GCC"

That's good. I'm not too familiar with C, but similarly you can still compile old Java code with current compilers or run old Java bytecode on current JVMs. So your code rots a little slower.

OTOH that's not the only way it does. I was briefly working on an ancient Java 1.4 project. A language version without generics, enums, catching multiple exceptions in one branch, etc. Deprecated libraries you couldn't find documentation for. That kind of legacy project.

Everything did compile, sure. But working on it was a mess and I was gone ASAP. "Nobody wants to touch this code" is another way I consider it rotten.

@Root
>You are right, of course, but that's not quite what I meant
Understood. We're actually in agreement. 👍

>I suppose what I'm actually angry over is frontend, and how everything is an ever-changing mess of flaw-riddled bloatware
Yeah, basically I view everything through my middleware/backend tinted glasses. I subconsciously dismiss frontend development completely most of the time. I just can't bring myself to take it seriously - it's such a mess beyond words.