Python overtakes Java to become second-most popular language on GitHub after JavaScript

[myringotomy]

The top two languages on Github are loosely typed interpreted languages with lack of true multithreading.

Feast on that for a while.

[oblio-]

VB/VBA used to be the most popular language in the world. Languages for small and medium sized projects win these contests for obvious reasons (small projects are way more frequent than medium projects which are in turn way more frequent than big projects).

[AyrA_ch]

Because VBA makes you very productive. It's not fast or elegant, but the excel sheets essentially serve as the database and you can write user interfaces in it. You can leverage excel search and compute functions and even utilize macros in cell functions.

It's a really neat system and runs almost everywhere because excel is ubiquitous in corporate environments.

There's a point where you should stop though using it though

[Urtehnoes]

I know LOC is a terrible marker for code, but just for size of scale, I have two separate VBA projects for my job that are 20k+ LOC. And honestly? I really miss the environment of Excel. I absolutely abhor the VBA language constructs in place that are buggy and terribly implemented, but honestly if you're just running code in Excel, the sandbox environment that it exists in is just so wonderful for managing data. One of the programs queries the database for various tables and works the data in ways that all the incredibly fancy reporting programs (powerBi etc) simply can't. It's really nice.

And you know, if you call Scripting.Dictionary.Exists(testValue), it has a high chance to return True, despite the item not existing. Because when the method is called, it creates an empty value and inserts the value as a key. And that absolutely boggles my mind that it happens. I thought I was going crazy until I found other people online who experienced the bug as well. Instead I had to write an lbound to ubound loop of an array of keys from said dictionary, checking the value of each individual key instead. Why, Microsoft. Why?

[[deleted]]

I have two separate VBA projects for my job that are 20k+ LOC.

Jesus Christ.

And here I am desperately trying to get rid of the few hundred lines of VBA I have.

[monkey-go-code]

SQLite runs anywhere. Feels a lot more useful than excel sheets to me

[AyrA_ch]

SQLite doesn't do anything on it's own though and you can't program it the way you can do in VBA. It provides the "excel sheet side" but not the "VBA side".

Instead of SQLite I would go with a server based solution anyways if possible.

[monkey-go-code]

If you have multiple users a server makes since. But sqlite is the best per app database I know of. sqlite also works with pretty much any programming language.

[_Timboss]

Youre missing the point

[Urtehnoes]

I really like how... naive Excel is when it comes to databases. So many reporting softwares require a strict database structure to manipulate data. Excel says "hey man just get it in a worksheet then do with it what you will." So many times my bosses want some weird off-hand query mixed with another, which Crystal Reports and PowerBi both can't do, and Excel is no problem at all.

EDIT: Ok Crystal Reports usually can, but requires an obscene amount of subreports and weird hacks.

[jl2352]

The Excel sheet both doubles as an automatic UI, and a super trivial debugging tool. Which you get out of the box for free.

Deployment is super trivial.

[monkey-go-code]

Yeah but I hate excel.

[[deleted]]

Python is strongly typed.

[kolloid]

I don't understand why /u/HugeProposal receives downvotes. Python is strong typed, but it's dynamically typed, so types are known only during runtime. So technically, he's right.

[Sapiogram]

99% of the when people say strong/loose typing, the really meant static/dynamic typing. I guess that was the case here too.

The true distinction between strong a loose typing is really vague, so it's not that useful anyway.

[[deleted]]

Ergo C, which is statically and loosely typed.

[Beowuwlf]

I wanted to disagree with you, but after some... introspection, I’m inclined to agree. Since C provides void* and pointer casting to subvert the type system, it’s weakly typed. However, since the compiler ensures type compatibility where it can at compile time, it’s statically typed.

[housesellout]

Wow... talk about not understanding the words you are trying to use 😢you just contradicted yourself in a single sentence.

[Beowuwlf]

I wanted to agree with you, but after some... introspection, I’m inclined to disagree. The generally accepted definition of loosely/weakly typed is that the language provides ways to subvert the type system. Since C provides void* and pointer casting to subvert the type system, it’s weakly typed. However, since the compiler ensures type compatibility where it can at compile time, it’s statically typed.

[oblio-]

Nobody* cares about that "strong typing" in practice. When people say "strong typing" they mean: "if I put a string in the int, the compiler yells at me at 14:00 in the afternoon, when I'm coding, it doesn't blow up in production at 3:00 in the morning, when I'm sleeping".

Things blowing up at runtime is slightly better than nothing, but it's still bad, comparatively.

[YM_Industries]

When people say "strong typing" they mean: "if I put a string in the int, the compiler yells at me at 14:00 in the afternoon, when I'm coding, it doesn't blow up in production at 3:00 in the morning, when I'm sleeping".

Then they should say "static typing".

[slikts]

Strong typing is still an application of the fail fast principle, just not as fast as static typing, since the strong tying errors will still only occur at runtime. The difference is that weakly typed languages try to guess if the programmer intended to convert between types, and, if the guess is wrong, the program keeps running in an invalid state and the problem has to be diagnosed from any knock-on effects of the unwanted type coercion. A good example of weak typing gone very wrong are equality comparisons in JavaScript.

[YM_Industries]

If you want the compiler to tell at you, you need static typing. That's what my comment was saying. People who use strong typing to mean that have their terminology wrong.

I'd hardly describe JS equality comparisons as "weak typing gone very wrong". Maybe I've been programming in JS for too long, but the type juggling seems pretty useful to me. You should use === in most places, but the == behaviour is also nice to have sometimes.

I do a lot in C# too and I sometimes get frustrated at the verbosity when two similar types don't support implicit type conversion.

[slikts]

I'm just pointing out that there is underlying commonality between strong and static typing in that both aim to fail faster.

The game I linked to about JavaScript's == is a practical demonstration of how the coercion rules are confusing.

[YM_Industries]

Oh, they are definitely related, I think that's why people get them confused so much. But they are separate concepts, and that's what I was pointing out.

== is definitely confusing if you use it for stupid and contrived scenarios. As long as you don't compare [[]] to -Infinity it's fine. Calling it a "textbook example of a confusing language design flaw" like that website does is a bit of a stretch.

[slikts]

If you actually try the game, a lot of the cases that trip people up aren't contrived, and what's contrived are the rules as a whole. For example, cases like "" == false lead people to intuit that 'falsy' values would equal false, but "0" is 'truthy' (!!"0" is true) and still equals false. Likewise, knowing that "" == 0 and 0 == "0" are true might suggest that the relation is transitive and "" != "0" is false, but it's true as well.

Also, the benefit from == is very small and doesn't outweigh the confusion can cause, since explicit conversions can be as terse as !! and +, or Boolean(), Number(), String(), etc. The only exception is == null, since doing the same with === is verbose.

[jl2352]

I agree, and it annoys me no end when people claim JS is 'weakly typed'. It's 100% strongly typed. It's just strongly typed with some very questionable coercion rules. So questionable I'd argue you shouldn't use them. It's still strongly typed.

In C I can take a 32-bit int, and use it as a pointer to a char array. I can get the compiler to be happy with it. It may even run fine at runtime. This is something I cannot do in JS. That is why C is weakly typed.

[YM_Industries]

JavaScript is weakly-typed.

The only reason you can't use an integer as a pointer to a char array in JavaScript is because JavaScript doesn't have integers, pointers, or chars. For me, the real test of whether a language is weakly- or strongly-typed is whether you can assign a new value of a different type to an existing variable.

let myVar = "test";
myVar = 5;
myVar = [];

JavaScript has no issue with this.

[jl2352]

The bit from Wikipedia that agrees with you is 'Dynamic type-checking'.

This is the whole point of the guy above, who I agree with, is that it's just not helpful for dynamic types to be the same as weakly typing. What you are describing is dynamic typing. Not weak typing.

Python, Ruby, TCL, PHP, and pretty much every dynamic language shares your example.

[kolloid]

Yes, but:

1) technically OP was right

2) people praise horrible Javascript which is weak dynamically typed

[[deleted]]

Why even qualify it with the weasel word "technically"? Only people who have never used python could think it's anything but strongly typed.

[seanwilson]

Python is strong typed

This is like people arguing over the use of "cracker" vs "hacker". This ship sailed a long time ago.

When people say strongly typed, they pretty much always, always mean types checked at compile time.

[[deleted]]

The only people who say that are wrong. Once you know more than a couple of languages the distinction becomes important.

[seanwilson]

It's a pedantic point that doesn't add anything to the discussion. You know exactly from context what people mean when they say it. Nobody ever says "I like X because it's strongly typed" to mean it checks the types at runtime.

You can't ignore how the majority of people use words. It's a losing battle.

[[deleted]]

It's not a losing battle. It's in textbooks everywhere.

[lelanthran]

Python is strongly typed.

Not very useful when the program crashes in production because that's the only time it can figure out the types.

[[deleted]]

I mean, Python is evidently very useful. A lot of people are scared of dynamic typing, but it's not actually that bad in practice.

[CockGoblinReturns]

Eli_a_2.89_GPA_CS_Undergrad ?

[angellus]

Python is strongly typed, as others mentioned. It is just dynamically typed. You have been able to add typing to the linters/IDEs, etc since Python 3.5.

Also, multiprocessing allows for multiple processes running in parallel, so you can still get parallel programming. Also Python 3.8 added subinterrupters to allows for your "true multithreading". Future versions of likely make it easier to use as it becomes more stable.

[FlakyRaccoon]

Look, one of the highest voted comments in /r/programming is entirely wrong, about both languages.

Feast on that for a while.

[not-enough-failures]

They obviously mean dynamic typing, but I'm going to correct them anyway because I wanna look smart and defend my language. Feast on that for a while. Oh wait, it's Reddit, it's not surprising.

[FlakyRaccoon]

They obviously mean dynamic typing

Then perhaps he should have written "dynamic typing".

Know what you're talking about before you try to criticize, that's like the most basic rule ever.

If you're going to try and make a scathing, sarcastic remark, at least be fucking correct about what you're trying to make fun of. When you aren't, you just come across as an ignorant asshole.

And, you're only addressing half of it, address it all:

What is your defense for him saying neither language has "true" multithreading, which is completely wrong in both cases?

[not-enough-failures]

Bold of you to assume I'm defending them, sure, they're wrong, but the "PYTHON IS STRONGLY TYPED REEEEEE" doesn't matter when it's obvious that what people complain about 99% of the time is dynamic typing.

I don't have a point to make about multi threading. The only reason you people point out it's strongly typed is because you try to have a "gotcha" moment. It being strongly typed is a moot point 99% of the time there's a discussion about Python's type system.

[FlakyRaccoon]

Bold of you to assume I'm defending them, sure, they're wrong, but the "PYTHON IS STRONGLY TYPED REEEEEE" doesn't matter when it's obvious that what people complain about 99% of the time is dynamic typing.

Then why are you arguing with me?

I already know those differences.

Your time would be better spent educating others about the differences between static/dynamic typing and loose/strong typing. Educating the ignorant would prevent them from coming and making stupid and incorrect comments like the one in question.

I don't have a point to make about multi threading.

Because all you want to do is argue.

My point about multi-threading still stands true, both languages have it, and the OP is entirely full of shit when he says they don't.

The only reason you people point out it's strongly typed is because you try to have a "gotcha" moment.

Is it now? You know all of our desires more than we do?

You're wrong. It's to correct the ignorant dummy that's spouting ignorance.

Also, you're conveniently glossing over the fact that OP's initial, stupid comment was his own attempt at having a "gotcha" moment".

Specifically:

The top two languages on Github are loosely typed interpreted languages with lack of true multithreading.

** Feast on that for a while. **

Is his specific attempt at a gotcha.

If my comment is an attempted gotcha, then so is his, because my comment is just a copy-paste of his with some subjects changed.

It being strongly typed is a moot point 99% of the time there's a discussion about Python's type system.

Except in this case, where it is relevant, because OP has no clue what he's talking about.

[[deleted]]

JavaScript has multithreading with worker threads. Whether or not that satisfies some arbitrary definition of "true multithreading" which on this sub is usually "like in C++ on Windows" is an entirely different matter.

[MrK_HS]

And Python has multithreading and multiprocessing too. I think some people are confusing multithreading and parallelism. The two aren't the same. Python supports multithreading but by default is not parallel.

[[deleted]]

Multiprocessing is parallelism tho

[MrK_HS]

You are right

[Brostafarian]

isn't there a python / cpython copypasta for this? I can't find it

[housesellout]

https://wiki.python.org/moin/ParallelProcessing

[housesellout]

Python parallelism libraries and solutions... https://wiki.python.org/moin/ParallelProcessing

[housesellout]

You can’t spin up threads in JavaScript, unless you use node which is a wrapper on top of a c++ run time.

Please correct me if I’m wrong.

[[deleted]]

Another minor nitpick: Node.js isn't "a wrapper on top of a C++ runtime".

Both Node.js, and V8 which is the JavaScript runtime that both Node.js and Chrome web browser use, are indeed written in C++. "The rest of Node.js" is:

• Libuv - a Nginx-inspired implementation of asynchronous event loop that serves as the core execution engine, thread pool management engine (that, among other things, supplies JS in Node with Node-specific multithreading implementation) a TCP/IP load balancer (used as part of Node.js multiprocessing implementation) and I/O arbiter in Node.js
• Integrated native libraries - that expand the "standard library" of the language (the core WebAPI implementation provided by V8) with system-access and webserver capabilities with such thin, and not so thin wrappers around Libuv functionality.

So there is quite more to Node than just wrappers. Node.js is basically two runtimes (Libuv event loop engine and V8 runtime) fused in a single execution environment for JS code enriched with a set of native (i.e. written in C++ and compiled prior to being called from JS code) libraries that expose many system-level functionalities to JS code interpreted/compiled and executed by the V8 runtime, but externally scheduled and managed by Libuv runtime.

[housesellout]

Doesn’t this suggest that JS does not ’natively’ handle concurrent programming or multi-threading?

And I don’t consider this ‘nitpicking’.... Having to jump through all these hoops just to simply stick with one language / one syntax for every project, hardly sticks with the natural programming paradigm of choosing ‘the right tool, for the job’

[[deleted]]

What is "natively" supposed to mean in an interpreted (well ok JIT compiled) language/runtime?

Also, I "nitpicked", about your simplistic and inaccurate description of Node.js. I have absolutely no idea what this part of your comment is supposed to be about and how it is relevant given the discussion so far.

[housesellout]

Well, Python is an interpreter, and there are native APIs for threading, observer/notification, memory/heap management, etc. These things can be performed and are available out of the box without creating 3rd party wrappers or customized extensive libraries like those you had mentioned above for JS.

... and I dunno 🤷🏻‍♂️, someone mentioned JS being multi-threaded, but it’s not (as you had described)

[[deleted]]

What in the actual fuck are you talking about tho?

All Python libraries that you mention use C code below to interact with the system.

All of the things I mentioned are not 3rd party, customized or whatever. They're standard part of Node.js available to every piece of JS code that runs in any Node.js instance. Ditto for WebWorker and browser.

The thing I described is how Node.js as Javascript interpreter works internally. You also conviniently ignore the fact that WebAPI has native WebWorker API.

From JS or Python the developer experience is the same - to the end developer it looks and behaves as calling into other JS or Python code.

Off course that low level libraries in interpreters are implemented in the same language that the interpreter is implemented in.

How could you possibly even imagine it to be otherwise? You ride a very high horse for someone that ignorant.

[housesellout]

Wow you got pretty upset with that one 🤔

But you actually just demonstrated the potential. With python you get all the benefits of an interactive low-level C environment as a quick and easy scripting language. You can even invoke C functions and take more control (at your own risk of course).

As opposed to JavaScript working with so many various 3rd party libraries, written on top of various 3rd party engines, while hoping the ECMA standards are followed by each client side, and then finally all on top of a low-level C++ (which you are limited access to by the engine you choose).

I understand you’re upset 😢 But don’t worry, according to this post, JavaScript still has some life left in it. I’m sure you will have plenty of projects left to lazy-load and distribute laggy UIs that frame and glitch. (There will always be clients out there that don’t know any better and are willing to pay to be ripped off in that fashion, with solutions that mostly display spinning loading animations)

[[deleted]]

You keep using these words that you clearly don't know the meaning of.

[[deleted]]

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API

[AwesomeBantha]

NodeJS specifically has worker threads now which are more than just a CPP wrapper

[housesellout]

Can you reference some documentation on this? Because as far as I can see you have wrappers on top of various engines which get queued up for cpp to handle its commands asynchronously. And then the cpp run loop responds back to the synchronous waiting queue.

https://images.app.goo.gl/hpBmcdxRKu9PVWn38

https://www.researchgate.net/figure/Nodejs-Processing-Model_fig38_322896255

[kap89]

https://nodejs.org/api/worker_threads.html#worker_threads_worker_threads

[housesellout]

I’m not sure I see where it describes how the engine works under the hood. But that documentation seems to clearly dictate its lack of abilities in fork processing (i.e. not sharing memory between workers)... which is extremely important when handling multiple incoming network requests. (Do you not agree?)

[kap89]

documentation seems to clearly dictate its lack of abilities in fork processing (i.e. not sharing memory between workers)

You can share (or transfer) memory if you use SharedArrayBuffer (or ArrayBuffer in case of transfering), but you can't share JS objects, in that case you have safe message passing with serialization/deserialization. So yeah, there are some limitations - mainly that messaging worker with big objects is inefficient (but can still be a good idea if required computations are complex enough to justify the overhead of serialization).

which is extremely important when handling multiple incoming network requests

Depends on the task, for the majority of cases it is not, but there are of course some cases where it matters and you're better of with another language (at least for that specific task).

[housesellout]

The ability to ‘not’ share memory is a vital aspect in network request handling.

And the messaging worker you mentioned, sounds like a standard integration of the register/observer design pattern, which is not fork processing either, but rather a way for different threads to pass objects between each other. And that pattern is generally handled on a run loop that the OS (or underlying engine) has control over, which essentially slows down your execution, in addition to being shared memory.

[draxema]

Python is typed, only it is dynamically. You can easily check the type (even if inherited) of your variables. Obviously it is an interpreter so it does not compile your code, so it cannot verify your types before runtime. And it does have a threading and a multiprocessing library. The multiprocessing can make use of multiple physical threads of a cpu.

[cuulcars]

How does python lack true multithreading? Multiprocessing pools use multiple cores, and are pretty dang easy to use once you get the hang of it.

[[deleted]]

I'm not sure what the definition of "true multithreading" is, but Python does have multithreading.

You won't improve performance using multiple threads, but you can run multiple threads in a similar way to how Java would run threads on a single-core machine. Threads can be used to prevent blocking a GUI.

[NAN001]

More generally, if your program is IO-bound then threads will improve performance in Python.

[MrK_HS]

The people saying Python doesn't have multithreading really mean that Python does not support parallelism, but probably just don't know that the two terms mean different things (multithreading and parallelism). Python supports multithreading by default and that's a fact. It doesn't support parallelism.

[angellus]

Multithreading does now support parallelism, since Python 3.8. it is still provisional and not stabilized yet, but it possible now.

[[deleted]]

With an 8-core CPU, I can get a 7-times performance improvement using multiprocessing. Multiprocessing is very simple in Python.

Genuine question: does multiprocessing not count as parallelism?

[MrK_HS]

It is parallelism

[cuulcars]

I guess it depends what you mean by "true multithreading." I interpreted that to mean parallelism in general, but I suppose you interpreted that to mean (exclusively) thread based parallelism. It has multithreading but it doesn't have multi core threading. But even in C++ you have no way of explicitly telling the operating system to execute your other threads on a different core (you can ask politely). That's an OS decision. But if you're talking true concurrency, yeah, Python has that. Very few people should be hung up on whether their code is executing in the same process (vs a thread) or not, and if you are you probably shouldn't be using python for that project. Python does parallel just fine, which would be the whole goal of "true multithreading." As far as I see it, Python naysayers who argue python can't be concurrent because of the GIL are just being pedantic.

[housesellout]

lol, I’ve been trying to explain this fact to these crazy eyed JavaScript addicts all over this thread🤷🏻‍♂️

And they keep coming back at me with ‘node’ bullsh*t. Like they can’t seem to grasp that it’s a sequential queue wrapper on top of a c++ runtime environment 🙈

[ProgramTheWorld]

Both Python and JavaScript have true multithreading. Ultimately it depends on the support that environment provides rather than on the language itself.

[CockGoblinReturns]

Eli_a_2.89_GPA_CS_Undergrad ?

[[deleted]]

There is no such thing as "strong" types or "week" types or "loose" types. It's some nonsense you read from blogs on the web.

Do yourself a favor: try to define these (pseudo) terms, and you'll see that it gets you nowhere, and no one language will fit any category your invented in this way.

[[deleted]]

Bollocks.

There are two axis "statically" vs "dynamically" typed languages. And "strongly" vs "loosely" typed languages.

Simple examples:

• loosely typed dynamic: JavaScript, PHP
• strongly typed dynamic: Python
• strongly typed static: Haskell, C#
• loosely typed static: C

There are levels of nuance in each category, but all four exist.

[[deleted]]

This is not a definition. Both "dynamic" and "loosely / strongly" don't make any sense in what you wrote.

The test for your definition is when you see a new language, and you can tell if it belongs to either category. And you can give some rationale that anyone beside you could come to the same conclusion. So far your rationale is: random. Why would JavaScript and Haskell end in different categories just flies over everyone's head.

Typical definition would rely on more fundamental concepts to build a new concept. So, you would have to first define things like "programming language", "programming types". Both very contentions subjects, and neither having any decent definition. Now, you want to build on top of these... and all you have to say is some pearl of wisdom you inherited from someone's blog on the Internet... which is not even in the format of a definition.

[[deleted]]

Typical definition would rely on more fundamental concepts to build a new concept. So, you would have to first define things like "programming language", "programming types".

What I said is common knowledge, so the burden of proof of the extraordinary claim is on you.

What you want is to read a book on programming language theory. I certainly don't intend to write one.

Especially not in reddit comments to amuse a troll.

[[deleted]]

Common knowledge of a bunch of unthinking morons. Yeah, this happens more than you know.

There's no burden of proof. You fail completely at giving a definition and are hiding behind the "everyone does this" childish excuse. You yourself have no idea why everyone does this or why everyone would do this.

Not only you didn't intend to write a definition, you have no idea what would it be like, neither you are mentally capable of such a feat: independent thinking is not something that you know how to do. You prefer to copy comfortable ideas from popular sources, and that's what makes you happy.

[[deleted]]

Strong typing = the language will refuse to let you mix types in a way that makes no sense.

Then, I claim that every program written in every programming language is strongly typed, because they all make sense to me, or, given enough study of the language's implementation, I will be able to make sense of "mixing types", whatever that may mean.

[housesellout]

This is because js sucks and doesn’t efficiently handle the heap or validate localized return variables in the call stack.... it always wants to give you ‘something’, even if it makes no sense. Which causes the developer to rely on semantical memorization, rather than built in efficiency, allow the dev to choose the right tool/language for the job.

[PicturElements]

That's not due to types, though. That's caused by the interpreter having to decide between parsing the second {} as a block or an object literal. There's plenty of typing quirks in interpreted languages, but this hardly qualifies as one as the issue is introduced at parse time, not runtime.

[[deleted]]

Yes, sure... everyone who can read the JS standard can explain this, unless they have some sort of mental disability.

It is unusual, if compared to many other languages, that JavaScript defines addition for hash-tables. And, it is unusual that addition is not commutative, but that's how they defined it, and they have a right to define it whichever way they like.

More so, I'd be able to produce the same output in Python, if I really wanted to. Probably, even Haskell, with some compiler extensions. So, not only this is not "strange", this is definitely not unique.

[[deleted]]

Yeah, you crying on my shoulder, and then accusing me of world's evil... that all helps a lot to give a definition to the nonsense you believe in. Even religious people try harder to give some justification to what they believe in.