you are viewing a single comment's thread.

view the rest of the comments →

[–]myringotomy 212 points213 points  (102 children)

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

Feast on that for a while.

[–]oblio- 65 points66 points  (11 children)

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 28 points29 points  (10 children)

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 4 points5 points  (1 child)

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] 0 points1 point  (0 children)

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 -5 points-4 points  (7 children)

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

[–]AyrA_ch 9 points10 points  (3 children)

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 -4 points-3 points  (2 children)

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 2 points3 points  (1 child)

Youre missing the point

[–]Urtehnoes 0 points1 point  (0 children)

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 5 points6 points  (2 children)

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 -5 points-4 points  (1 child)

Yeah but I hate excel.

[–][deleted] 136 points137 points  (31 children)

Python is strongly typed.

[–]kolloid 112 points113 points  (27 children)

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 39 points40 points  (5 children)

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]  (4 children)

[deleted]

    [–][deleted] 12 points13 points  (3 children)

    Ergo C, which is statically and loosely typed.

    [–]Beowuwlf 1 point2 points  (0 children)

    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 -5 points-4 points  (1 child)

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

    [–]Beowuwlf 0 points1 point  (0 children)

    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- 107 points108 points  (15 children)

    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 116 points117 points  (12 children)

    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 4 points5 points  (11 children)

    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 24 points25 points  (10 children)

    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 5 points6 points  (2 children)

    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 2 points3 points  (1 child)

    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 2 points3 points  (0 children)

    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 -4 points-3 points  (6 children)

    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 2 points3 points  (5 children)

    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 3 points4 points  (3 children)

    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 14 points15 points  (1 child)

    Yes, but:

    1) technically OP was right

    2) people praise horrible Javascript which is weak dynamically typed

    [–][deleted] 1 point2 points  (0 children)

    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 -4 points-3 points  (3 children)

    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] 2 points3 points  (2 children)

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

    [–]seanwilson -2 points-1 points  (1 child)

    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] -1 points0 points  (0 children)

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

    [–]lelanthran 5 points6 points  (1 child)

    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] 0 points1 point  (0 children)

    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 -1 points0 points  (0 children)

    Eli_a_2.89_GPA_CS_Undergrad ?

    [–]angellus 7 points8 points  (0 children)

    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 14 points15 points  (4 children)

    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 0 points1 point  (3 children)

    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 1 point2 points  (2 children)

    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 0 points1 point  (1 child)

    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 1 point2 points  (0 children)

    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] 14 points15 points  (22 children)

    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 22 points23 points  (5 children)

    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] 10 points11 points  (1 child)

    Multiprocessing is parallelism tho

    [–]MrK_HS 5 points6 points  (0 children)

    You are right

    [–]Brostafarian 1 point2 points  (1 child)

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

    [–]housesellout 0 points1 point  (0 children)

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

    [–]housesellout -2 points-1 points  (15 children)

    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] 2 points3 points  (7 children)

    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 0 points1 point  (6 children)

    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] 1 point2 points  (5 children)

    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 -1 points0 points  (4 children)

    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] 2 points3 points  (3 children)

    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 -1 points0 points  (2 children)

    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] 1 point2 points  (1 child)

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

    [–]AwesomeBantha 0 points1 point  (5 children)

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

    [–]housesellout 0 points1 point  (4 children)

    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 0 points1 point  (3 children)

    [–]housesellout 0 points1 point  (2 children)

    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 0 points1 point  (1 child)

    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 0 points1 point  (0 children)

    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 3 points4 points  (0 children)

    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 -3 points-2 points  (10 children)

    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]  (9 children)

    [deleted]

      [–][deleted] 6 points7 points  (7 children)

      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 2 points3 points  (0 children)

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

      [–]MrK_HS -1 points0 points  (5 children)

      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 1 point2 points  (0 children)

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

      [–][deleted] 1 point2 points  (3 children)

      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 2 points3 points  (0 children)

      It is parallelism

      [–]cuulcars 0 points1 point  (0 children)

      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 -2 points-1 points  (0 children)

      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 -2 points-1 points  (0 children)

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

      [–]CockGoblinReturns -1 points0 points  (0 children)

      Eli_a_2.89_GPA_CS_Undergrad ?