The Coder's Lounge

Yeah, saw that tweet and I loved it. Node is a blight on this world. I've had my share of fight with the developers where I work for because they insist not only on using Node, but also on giving the node package manager full access to the server's systems, overwriting or upgrading system libraries.

I had to end up making Backend agree to a waiver last year where I would no longer take any responsibility for maintaining or assisting a server after enabling npm modules globally. They (the devs) were not too happy about that and neither were they when I shared your tweet, but some aesops do need to be delivered, and "you are doing it wrong, you refuse to do it right despite my best offerings so I won't kill you but I also don't need to save you" is one of them.

wakachamo said:

Again, it's very easy to get caught up in comparisons of two very different tools. Python lacks the type safety of a proper systems language, yet it's very effective for quick prototyping. One tool is good for one type of job, and the other for a different kind. Python and Java can perfectly coexist, and neither is the be-all-end-all of the other.

Click to expand...

The original discussion was over comparing Java and Javascript. I was merely pointing out what the framework of the Python vs. Java crowd has looked like over the years, with special attention to more recent years.

When you say it does not have the safety of a proper language, do you mean that it has plenty of easily manipulated tiny bugs or that it has massive oversight that makes it grossly inefficient? If it is the latter, I do not understand why this type of thing would be getting heralded as the wave of the future.

If I need all of them in my coding belt, why would anybody be focused on being an expert in just one? Would it not just make more sense to splice them all together at this point? There are probably hundreds of different languages from Java, to Argus, to Python, to C++. If they all bring something to the table, then you would constantly need a team of programmers to get any work done.

AlolanRattata said:

When you say it does not have the safety of a proper language, do you mean that it has plenty of easily manipulated tiny bugs or that it has massive oversight that makes it grossly inefficient? If it is the latter, I do not understand why this type of thing would be getting heralded as the wave of the future.

Click to expand...

Neither, I was talking about type safety—glanced back at my original post to see if that word was there, and it is. :) One of the most common mistakes in my experience when dealing with large codebases in type-unsafe languages are errors that are a result of that lack of safety—mismatched types, unsupported method calls, etc.

Python can be heralded as the wave of the future for many things, but never as a Java replacement. That was my point.

AlolanRattata said:

If I need all of them in my coding belt, why would anybody be focused on being an expert in just one? Would it not just make more sense to splice them all together at this point? There are probably hundreds of different languages from Java, to Argus, to Python, to C++. If they all bring something to the table, then you would constantly need a team of programmers to get any work done.

Click to expand...

I'm not sure what your point is. That is exactly how it is today. One of the most common things I've seen people regurgitate when learning about programming is that your key skill as an engineer is not in knowing a specific language, it's how quickly you can learn the next.

If you want anything done today you absolutely do need either a wide-reaching set of skills or a team of people. Different tools for different jobs. :)

Okay, tone it down a notch. I was merely trying to get you to elaborate. Unsupported method calls, like String.format, seem like tiny bugs to me. Why would you say otherwise?

AlolanRattata said:

Okay, tone it down a notch. I was merely trying to get you to elaborate. Unsupported method calls, like String.format, seem like tiny bugs to me. Why would you say otherwise?

Click to expand...

Not sure where you're getting the idea that I'm worked up! :) All I see is a constructive discussion.

"Unsupported method calls", or really, "I don't know what type this object is" are an example of an easy mistake that a programmer can make that some tool, whether it's the compiler or something else, can help the programmer avoid entirely. My gripe with claims that Python is capable of being a versatile tool for any kind of task is that the more complex a system becomes, the more likely these mistakes are to happen. After a while, and especially after, say, inheriting a large codebase from someone else, not knowing what type a certain object is and having to trace back a number of paths just to find out what it is (and more importantly, what it isn't) gets really, really annoying.

Languages with strong type checks like Java, or C++, etc. completely eliminate that basic problem. They eliminate it at the expense of the ability to quickly prototype something, or being a good interpreted language, but that's simply a tradeoff that gets made.

Java isn't a universal tool because it can't be interpreted and makes prototyping hard. Python isn't a universal tool because it's not type-safe, and can lead to simple mistakes in very large codebases. If you need to be an expert on both of those tasks, then you might need to be an expert in both (kinds of) languages. :)

So "unsupported method calls" are just the code telling the programmer that it cannot find anything for the specific input? It is an easy mistake because the programmer should know to cover all of their tracks when designing the code? Or am I still not getting it? This would explain why a complex system would see more of these mistakes because the programmer could easily have forgotten to finish a pathway. Tracking back to find the type of object means finding the mistake in the code?

Thus, Java and C++ lack the ability to create a single path that works for all inputs for a given output?

What is the difference between compiling and translating code then? Would not compiling be building and translating be following pathways to their conclusions/outputs?

AlolanRattata said:

So "unsupported method calls" are just the code telling the programmer that it cannot find anything for the specific input? It is an easy mistake because the programmer should know to cover all of their tracks when designing the code? Or am I still not getting it? This would explain why a complex system would see more of these mistakes because the programmer could easily have forgotten to finish a pathway. Tracking back to find the type of object means finding the mistake in the code?

Thus, Java and C++ lack the ability to create a single path that works for all inputs for a given output?

What is the difference between compiling and translating code then? Would not compiling be building and translating be following pathways to their conclusions/outputs?

Click to expand...

Are you familiar with object-oriented programming and what I mean by a method? I wasn't really able to make much sense of any of your post just now and I'm not sure if it's because we're just giving different names to the same things. :(

AlolanRattata said:

What is the difference between compiling and translating code then? Would not compiling be building and translating be following pathways to their conclusions/outputs?

Click to expand...

I was trying to figure out where "translating" code came up, but couldn't, do you mean "interpreting"?

In the most basic sense, a compiled language would be something where you have to run a compiler, which creates a separate executable file that you run. It's slower, but safer, because the compiler will pick up (syntax) errors before you run the program, and won't allow you to even make the executable if it's a serious enough error. An interpreted language (like Python) is "compiled" on the fly as the program is running - it's faster (and therefore good for prototyping) because you don't have to recompile the program every time you make a change, and you can even run very simple programs while writing them by typing the code into the command line rather than a text file if you, say, wanted to see if a handful of lines of code will work before adding them to your program - but it's not as safe because if you make a mistake you won't get a warning ahead of time and your program could crash (or, worse, it will appear to work and you won't know there's a syntax error until much later - which is why interpreted languages are often not good for very large amounts of code or production software).

ETA: realized I should maybe specify that "faster" in the above cases refers to development time, not running time. All else being equal, a compiled program will run faster than an interpreted program

I am not sure why, but whatever you choose to spend time on is none of my business.

You mean that is how an .exe file is created, right? And it is not only safer but it sounds more practical to use a compiler, it would be like using word without spell check. Python being unsafe is presumably why it is usually compiled into byte code first before it is uploaded because it just makes more sense to know ahead of time whether you have a syntax error or not. Most people do not sacrifice quality for a quick fix. Which will be more smooth when running, of course something that is built without checking for accuracy will be completed faster than something gets checked. Although, I suppose if you were a confident programmer, then you would be more likely to trust yourself and choose an interpreted program every time.

AlolanRattata said:

You mean that is how an .exe file is created, right?

Click to expand...

Basically, yeah, though it doesn't necessarily have to have the .exe extention

And it is not only safer but it sounds more practical to use a compiler, it would be like using word without spell check. Python being unsafe is presumably why it is usually compiled into byte code first before it is uploaded because it just makes more sense to know ahead of time whether you have a syntax error or not. Most people do not sacrifice quality for a quick fix. Which will be more smooth when running, of course something that is built without checking for accuracy will be completed faster than something gets checked.

Click to expand...

It's kind of like using Word without spellcheck yeah lol but again, you're generally choosing to use an interpreted language for different reasons than a compiled language, in a situation where it makes sense to sacrifice safety for a faster development time - to continue your analogy, if you're just writing a rough draft or a note to yourself, you might not care about spellcheck, and may not even care about formatting and opt to write it in a faster plain-text editor instead. As well as not needing to spend time compiling, a lot of interpreted languages have the philosophy of "get more done with fewer lines of code" which makes them great for prototyping or making a proof-of-concept e.g., to show a client what the finished product might look like without having to actually *make* the finished product. They're also often used to create front-end interfaces, where safety is less of a concern because all the interface is doing is getting input from the user, passing it to the back-end program written in a more secure compiled language, then getting output from the back-end and passing it to the user. And sometimes it's just the most practical option under the circumstances, especially if it's not going out into the world to be used by others (as an example: my sister is an astrophysics student and spent last summer as a research assistant. They used programs written in C to run simulations and analyze data because there's lots of open-source programs already available that can be easily modified, it's flexible, and it's relatively safe (C will let you do a lot of stupid things, but at least you generally have to explicitly tell it "I'm doing this stupid thing on purpose"), but used Python to actually take that data and put it in a readable/presentable form, because doing that in C is a huge pain, especially when you're not actually a programmer and C compilers tend to give very cryptic error messages)

Although, I suppose if you were a confident programmer, then you would be more likely to trust yourself and choose an interpreted program every time.

Click to expand...

Not necessarily - I know lots of experienced programmers that hate interpreted languages because it's too easy to make a mistake, and personally of the languages I've learned so far in school, I vastly prefer C and Java over the interpreted languages we've learned (Perl, Python, and JavaScript). And interpreted languages run more slowly because they have to be, well, interpreted *as* they're running, so as soon as you get past the prototype/demo stage or get into anything complicated, you're generally going to want to go with a compiled language, not just because it's safer, but because it will run much faster. (again, to go back to my sister's research, she switched to Python at one point for analyzing data because it's a much easier language, but switched back to C fairly quickly because it just took so long for the program to run. And in my own experience, reading in and analyzing several large csv file in Perl was super easy to code, but the run time was significantly longer than similar programs I've had to write in C - though much less frustrating because string handling in C is horrendous, and as much as I don't like Perl, I would definitely take the longer running time in Perl over fighting with segfaults in C any day if all we're talking about is a quick-and-dirty analysis of text/csv files and not a fully functioning program)

Definitely. It's the reason why I will always prefer a compiled language, because having the potential to have some kind of run-time error due to one small mistake is always something in the back of my mind, whereas a compiled language catches all that before the final executable file is generated. I've literally had a single missing semicolon in a PHP script make my website error out completely - it wasn't until I checked back in the source that I found the missing semicolon, and presto my website was working again as if by magic.

The only language that you don't compile is assembly - you're basically already doing half of the work that the compiler does, you just have to have the assembler assemble the final output as you've already brought it down to machine instructions. The only problem is that what you do in one language to go from A to B suddenly turns into A going to A₁ to A₂ to A₃ to A₄ to A₅ to B. You have to manually do all those small optimizations that a compiler will already do for you in your code like unrolling loops or optimizing out redundancies. I like my compiled programs for doing all this work for me and pointing out the obvious errors before I even get to runtime, and going down even lower gives me even more power to do as I need, as well as see the inner workings of what I'm doing and be able to manage the code in a more effective way.

Interpreted languages, on the other hand, don't do any of this. It'll run your code, line-for-line, until either it terminates successfully, or errors out. The problems is that with each line it comes across, it first has to make sure there's no errors on that line and that everything it's attempting to do is legal: Are the arguments valid? Are their syntaxes correct? Is there any casting that has to be done? Are we missing any important stuff like a semicolon or some kind of terminator? What is it that we're even trying to do - is what is typed even a valid opcode? Once it's done all that, it then runs the line, if possible, then continues and repeats the whole process. It becomes absurdly slow in that way. Like mentioned, it's best for prototyping, but I'll be damned if I have to write a full application using an interpreted language - the final product would be absurdly bloated and would be quite slow to use.

Speaking of unsafe languages: One of my professors accidentally redefined a keyword into a variable during a JavaScript demo today and it just... let him do that. Love it.

One thing I like about interpreted languages is that they can be used as tools to extend software. E.g. Gimp allows you to add new plugins via Python scripts, all the newer RPG-Maker versions since XP ship with Ruby, etc.

It's nice to play around with, but obviously also comes with some downsides. It can be a little annoying trying to trace back an error you may have made in one of your scripts. But it is still better than having to get the source code of the application (if accessible), find the location where you want to add something and then recompile the whole thing.

I personally like Python but when push comes to shove I still end up using Delphi or C++ (and I'm still looking for a way to make use of D).

echo (hello world)

Inkblots said:

Basically, yeah, though it doesn't necessarily have to have the .exe extention.

Click to expand...

What are the key differences between file extensions then?

AlolanRattata said:

What are the key differences between file extensions then?

Click to expand...

Windows can use .exe, but Python scripts are also executable, as are java JAR files. MacOS uses .dmg files, and on Linux it's just a binary file that's marked as executable and has no extension.

Are all malicious files executable?

AlolanRattata said:

Are all malicious files executable?

Click to expand...

In one form or another: yes

In order to do something malicious, they need to do something afterall.

However there's a distinction to be made between malicious files that are executables by themselves and those that introduce malicious behaviour into a perfectly fine executable.

Malicious executables are programs designed to work by themselves. They're written in a programming language and compiled before being send through the internet to their targets. If you run them, then you will have a problem.

On the other hand you can have some application like Python or Word who don't really do anything bad by themselves. Instead they require the user to tell them what to do. One way is by providing some form of script, a way how to act for the application. Those scripts are usually in plain text, so they're not malicious by themselves. In fact, checking them out in a text editor won't cause anything bad to happen. However, if you were to let such a script be run in the respective application, that will change. If you ever heard of the term "computer virus", that's pretty much what it is.

Looking for some recommendations/opinions:

I want to build an app for myself (may share it later, but for now just for me to make my life easier, and to get more experience outside of school projects) to manage a personal database using MySQL, but not sure what language would be easiest/most appropriate. Basically, I just want to be able to add rows to my tables (with dropdowns/checkboxes/etc. where appropriate to cut down on typos) and display the results of built-in queries.

I know how to do this already with HTML+JavaScript+Node, but wondering what other choices there might be out there that are easy to use with MySQL and create a simple GUI.

Inkblots said:

Looking for some recommendations/opinions:

I want to build an app for myself (may share it later, but for now just for me to make my life easier, and to get more experience outside of school projects) to manage a personal database using MySQL, but not sure what language would be easiest/most appropriate. Basically, I just want to be able to add rows to my tables (with dropdowns/checkboxes/etc. where appropriate to cut down on typos) and display the results of built-in queries.

I know how to do this already with HTML+JavaScript+Node, but wondering what other choices there might be out there that are easy to use with MySQL and create a simple GUI.

Click to expand...

I wouldn't quite use this as a solid recommendation (because gross php), but on a web server with PHP and MySQL, you could use phpMyAdmin which is a database manager packed into a GUI.

I apologize if this isn't what you are looking for, though