Everybody calls it this, but it's not a good name. What are some examples?
For further actions, you may consider blocking this person and/or reporting abuse
Read next
How to Flirt with a Developer: Learn to Debug Your Love Life
Sukhpinder Singh -
Why You Should (Probably) Use TypeScript?
Shafayet Hossain -
Performing Backups in Linux: Tools and the 3-2-1 Strategy
ispmanager.com -
Get Ready for Black Friday 2024: Share Your Wishlist! ποΈ
Vinish Bhaskar -
Top comments (144)
JavaScript has nothing to do with Java.
I blew the designers' minds a few weeks ago with the "car and carnation" analogy π
I prefer Java is to JavaScript as car is to carpet. Just like there is some carpet in a car, there is some minor overlap, but they're totally different things.
There's also grape and grapefruit, they both are fruits but totally different ones.
taken from the r/learnprogramming faq
This is perfect because they're more similar to each other than either one is to, say, Haskell, so they're not totally unrelated.
I generally just tell people plainly that it was a marketing ploy and that they have nothing to do with each other aside from the fact that they are both programming languages.
That would explain why I don't want to touch it with a 50-foot pole lol
Not directly programming, but relevant.
In asymmetric cryptography, we have the terms "private key" and "public key". But the term "private key" is actually wrong.
Since what academics call a "private key" is something that you don't reveal to anyone else, the term "private" is wrong.
It should be, therefore, "secret key" and "public key".
The "private key" should, instead, be what you agree on with e.g. Diffie-Hellman. It makes more sense than "shared secret".
It also allows you to use
skandpkas variable names in cryptography APIs, instead of having to spell outpubKeyandprivKeysince they both abbreviate topk.This is my weird hill okay?
Secret key is most used for simmetric schemas. I get your point, but I think using private-key is right.
The real epic-fail in cryptography is about the misused "certificate" term:
A certificate is just the public-key plus the proven subject (owner) of the certificate signed by a Certification Authority. The certificate has not the private key but we can find things like
"install the certificate in the web server to configure the TLS...." or "sign with a certificate"
From A Cipherpunk's Manifesto by Eric Hughes (1993):
Yes but... I can be wrong, I am not english native,... but I think privacy and private are not related , they seem to be but are indeed different and unrelated concepts, this is, a private key is not "something for keeping privacy" but "something for keeping confidentiality or secrets"...
Not sure at all about these...
Private is an adjective, privacy is a noun, but they refer to the same thing.
A private matter is one that requires privacy.
A secret matter is one that requires secrecy.
Shared key and private key achieve the same goal, without stepping on the historical meaning of secret key.
There are two hard problems in computing...
Itβs not a fully βprogrammingβ concept but pull request on Github sounds weird for me
I 100% agree, GitLab calls them Merge Requests which is more accurate
Exactly! and you aren't really requesting to pull anything, if anything you are requesting to push something. Merge request sounds better but at the same time I've gotten so used to pull request even though it makes no sense
I guess itβs a request that the other person pull, right? But either way, merge request 100% better.
Oh truue, I didn't think about that. It's like a "hey i did a thing, can you please pull this into master?"
Still totally weird. I had the same confusion when first introduced.
I asked myself the same thing a while ago, and I found a good explanation on SO which links to a GitLab's article that debates about this topic.
Think GitHub's feature name comes from
git request-pull. Both are completed by the receiver rather than the author, so it's kind of pulling, even though it's a merge still...But
git pullis alsogit fetch && git merge FETCH_HEAD, so who knows...?I guess GitLab's name for it does make more sense for the resulting action though.
One should always remember, Github created this workflow idea for mainstream. I'm curious if request-pull actually came after github.
I don't have a memory of the early days, but I expect the merge feature was not in the initial UI, meaning you literally asked the person to run git pull on your branch i.e. fetch and merge.
From my estimation, pull-request came from the author imposing his viewpoint on others. He assumed that he would be in control of the upstream repository and named it as a hybrid of what it was to him and what he had to do with it.
A better approach is to consider the user's point of view.
Git is a mess of badly structured commands, but a useful tool. Look at mercurial of you want an example of git workflows with a better command line interface.
You'll need to help me on this one. What does hg call it?
mercurial-scm.org/wiki/ReviewWorkf...
"Create a "Pull request" on data in the repo"
Don't bother looking at Mercurial if you're a BitBucket user though:
bitbucket.org/blog/sunsetting-merc...
You're requesting somebody to pull in a branch from your fork of the repo. The exact operation when using Git in the command line that merging the request equates to is
git pullnotgit merge, so Pull Request is technically correct.ha haaa ... Form the beginning this sounds wired for me also
so true, i couldn't agree more
Serverless is the most obvious. π€¦ββοΈ
Also Object-Oriented Programming, it's inventor (Dr. Alan Kay) even said later in life that it should have been called message-oriented programming.
Scrolling through this list, I'm surprised "serverless" is like three-quarters of the way down. It's clearly the most glaring misnomer in recent programming memory.
Can you think of a better name for it? I think re: developer experience it's pretty fitting, since in practical terms it means not needing to set up, manage, maintain, or pay for a server (or even write any back-end code, depending on the implementation). It's not really accurate in technical terms of what's going on behind the curtain but I don't really think that's the point.
Infrastructure as a Service.
On-demand Computing.
idk, not serverless. :)
Doesn't have quite the same marketable ring to it, but not bad!
It's server-less (i.e. you have less than 100% of the server, and even less than you'd have with a VM) ;-)
you mean it should've been called MOP ooooooooo
Yes! And "calling a method on an instance of a class" instead of just "send an object a message"
darkgreyApparently, "compiled language". Nearly all languages are compiled in many situations to something, so it's a meaningless phrase.
"Interpreted language" (final result executed via some form of a software interpreter) vs. "assembled language" (final result executed directly by the CPU as machine code) is more useful. Python and Java are examples of interpreted languages, although both are compiled in some fashion. C++ and FORTRAN are examples of assembled languages.
And yes, the designations are murky. Interpreters exist for typically assembled languages, and (generally impractical) means exist to assemble typically interpreted languages to machine code.
EDIT: Based on this thread, I'll add one more: an interactive language is one that is primarily run through a REPL (interactive shell).
This should not be confused with an interpreted language, which simply has a software layer between the shipped files (sometimes, bytecode that was compiled to) and direct execution.
Also, dependencies don't even enter into this discussion; any language has to resolve them somehow on the target machine.
EDIT 2: This thread (and related conversations) led to this...
Compiled! An Unobfuscated Glossary
Jason C. McDonald γ» Sep 6 γ» 13 min read
But Java is assembled to machine code at runtime, and it's extremely practical. I'd say interpreting Java is impractically slow!
No, Java is not assembled to machine code at any point, except in extraordinary implementations. It is compiled to bytecode, which is what is run through the interpreter, often the JVM.
EDIT: I omitted two words by mistake: at any point before shipping. JIT-compiling is pretty typical for interpreted languages; it doesn't make it an assembled language. So, yes, runtime still counts (towards interpreted.) My bad.
This was discussed and rehashed in some detail here:
What Is An "Interpreted" Language?
Jason C. McDonald γ» Sep 1 γ» 3 min read
No, common implementations do it. Run Java with
-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssemblyto see it assemble your Java code to machine code.Here's the assembler in HotSpot for example github.com/AdoptOpenJDK/openjdk-jd....
And see this blog post about how another Java compiler compiles and assembles Java to machine code chrisseaton.com/truffleruby/jokerc....
I used to work at Oracle on compilers and assemblers for Java and other languages.
I'm sorry, but this is just plainly incorrect. Even an interpreter compiles down to machine code before execution, it just does so line by line as it executes instead of before execution starts and all at once. Do you think a CPU can understand bytecode?
That's a misinterpretation of "compiles". The interpreter executes the bytecode, but it is not producing an actual standalone executable binary of assembly code. If it did, why on earth would Java deployment always involve the added trouble of ensuring the Java interpreter were installed on target machines, and then have the interpreter execute the .JAR?
"Runtime 'compiling'" is called "interpreting," and it really shouldn't be confused with compiling.
Definition of compile:
That's its quite literal definition, so any language which eventually is executed by a CPU (so all of them), are compiled at some stage. The topic of "Compiled VS Interpreted" languages is really about how they are compiled, generally "compiled" languages are compiled before execution and "interpreted" as they are executed.
This doesn't take away from the fact that saying "Java is never assembled to machine code" is wrong because Java wouldn't be able to be executed by the CPU at all if it wasn't. I don't mean for this to come across as combative (if that's how its been ahem interpreted), I think healthy and reasoned debate on such topics is good.
I'll end by quoting a blog post already posted in this thread where former Oracle compiler dev Chris Seaton explains how Java compiles bytecode to machine code:
Curious for your source. Here's the one most people work off now.
I chose to specifically use the term assemble for compiling to machine code, since "compiling to bytecode is still compiling!" is a favorite distraction technique employed in the Java debate.
EDIT: Okay, some confusion may have resulted from an unintentional omission on my part: earlier, I meant to type Java is not compiled to machine code at any point before shipping, which if you look at context, is what I've been saying all along. Just correcting that here.
All an interpreter ever does is to covert to machine instructions in some fashion or another, either just before execution (AOT-compiler), as it executes (JIT-compiler or traditional interpreter, depending on implementation). It's still relying on that software layer. That's all I've been claiming.
If you read my posts again, I've been repeatedly making the point that an assembled language ships a binary of machine code. If it has to be AOT/JIT-compiled (interpreted) on the end-user's machine, it's an interpreted language.
Also, to requote Chris Seaton...
Ergo, interpreted. Thanks for providing an official source to prove my point all along.
No wonder so many people are confused by "interpreted," "compiled," "assembled," "machine code," et al. The terms keep getting changed (esp. by various Java devs I've spoken to over the years) to dodge the obvious. :(
Update: So, reading over the thread again, I had to put in a couple of edits to my posts. I missed a couple of words in reading, and also in writing. My mistake. So, apologies to @chrisgseaton for missing his point.
Java is (sometimes/often) compiled to machine code on the end-user computer. This is referred to as Ahead-Of-Time (AOT) Compiled. Under other circumstances, it may be Just-In-Time (JIT) Compiled. This technically contrasts with a "traditional" interpreter, which will execute the bytecode directly; however, the difference between a JIT Compiler and a "traditional" interpreter often come down to implementation; it may be hard to distinguish without knowing implementation details.
In any case, as I said originally, an interpreted language still places a software layer between the shipped end result and the machine code; an AOT-compiler, JIT-compiler, and "traditional" interpreter all fulfill this requirement, which clearly marks Java as an interpreted (granted, interpreted-compiled) language.
This is still in contrast to assembled languages, say, C and C++, in which the executable machine code file is the shipped end result.
The difference all comes down to what is shipped to the end-user.
(Reminder: runtime dependency resolution is irrelevant to this topic.)
Interpreted (or interpreted-compiled) languages are not implicitly inferior nor superior to assembled languages. They are merely different.
Here's my source
I'd be curious as to where you got the data that "most people" use the first sentence of the wikipedia page for compiler as the definition. Also, the second sentence on that very same page is almost verbatim the definition I gave anyway:
So I think arguing about that is a bit silly. From the tone of your response it seems as though you think that I'm some kind of Java fanboy trying to obfuscate the truth using technicalities, far from it. In fact, my favourite language to use day-to-day is Python. It is however an unavoidable fact that Java is almost always faster than Python at runtime, due in big part to the way that it is compiled.
Saying "HAH! The quote you gave me has the word interpreter in it, I win!" is not really a productive way of having a sensible discussion. I was only ever trying to correct you on the omission that you have since edited into the last response, Java is in fact compiled/assembled to machine code before execution.
It feels like you have misinterpreted my intentions greatly, I'd rather not have this discussion devolve into petty "my language is better than your language" mudslinging, in which I have no interest in partaking.
From mass usage of the term. Ironically some of them are well-meaning Java devs who assert that compiling to bytecode implicitly makes the language "compiled" in the same way that assembling to machine code makes the language "compiled". Thus why I avoid the term "compiled language".
Compiled has come to mean many things. Typescript is compiled to Javascript. Python is compiled to Python bytecode. Java is compiled to Java bytecode, which is compiled (assembled) to machine code later. C++ is compiled to object code, which is compiled (assembled) to machine code. You see where this gets confusing? That's why I took the care to use "assembled," from the C and C++ term for the part of the compilation toolchain that converts object code to machine code.
You can compile to anything, but you can only assemble to machine code. I'm using "assembled" to unobfuscate the difference, instead of trying to unring the bell wherein the old definition of "compiled" became wholly antiquated.
I'm just rather worn out by the sheer mass of Java developers who have a knee-jerk "but but but" to the obvious point that Java is an interpreted language by my initial definition (JIT-compiled still qualifies). There seems to be an insecurity many Java devs have, that somehow their language is "terrible", so they have to find ways to defend its validity to themselves. (Which is unnecessary - it was already valid, and not terrible.)
You may well have been correcting the mis-point I produced with my omission, and I mistook it for the usual "but but but." It read the same to me, but if that's not your goal, I concede as such.
Happily, as I've said all along, interpreted is not inherently inferior to anything. I'm a Python and C++ developer. I never even implied that Java is inferior, merely that it is not assembled. (I'm not even a fan of Java, as it were, but I feel no need to decry it; it serves its purpose well, regardless of my personal preferences.)
Unrelatedly, I'd be curious what the benchmark between AOT-compiled Java and pre-compiled (to bytecode) Pypy would be. CPython usually loses benchmarks.
Put simply, do you ship machine code?
Yes: it's compiled
No: it's interpreted
I'd say,
Yes: it's assembled.Compiled is really, really confusing, because of the varying usage. As I said, you can compile to another language, to bytecode, to object code, to machine code...but you can only assemble to machine code.
I'm getting this distinction from the conventional compilation toolchain, btw. We compile first to some form of intermediary code, and then we assemble to the machine code.
Just bear in mind the most in academia use the term Compiled, as the term assembled, means to assemble assembly to machine code.
Oh, I'm well aware. I've historically used it the same...in fact, I'd prefer if that's all it meant.
Unfortunately, that distinction is lost on most...and sadly, part of that is from communities surrounding some interpreted languages misusing the term "compiled" for so long to dodge the fact their language is interpreted.
That, in turn, is because "interpreted" has been used in an almost derogatory manner for so long.
Language evolves, and not always for the better. Trying to cram the linguistic refrigerator biscuit dough back in the tube is a losing fight.
Which is true and why they created the JIT Compiler in Java 2.
Now days in a standard JVM process a lot of byte code is assembled to machine code. And a large part will be heavily optimized and recompiled to better machine code at runtime. That's why a JVM program quite often outperforms "native" languages, unless they are optimized by hand. (or after gathering enough trace information).
But calling Java an interpreted language is wrong. A common characteristic of interpreted languages is executing part of the code before running into a compile error.
Sigh
I've been in this conversation about a dozen plus times now. Every person tries to make the same claim, "Java isn't interpreted," but then they have to move the targets and shuffle the definitions around to prove it.
If Java were an assembled language, the end result of your compilation would be a standalone executable binary consisting purely of machine code, which could be run by itself on any machine of the matching architecture. Java doesn't do this; end users have to have some sort of runtime on their machine which executes the .JAR file they shipped. Either the process was made arbitrarily more complex than it needs to be, or Java is not an assembled language. (Please pick one.)
It's a compiled-interpreted, purely on merit that it isn't an assembled language. Just because its compile/interpret process is so complicated that practically every Java developer has their own unique understanding, doesn't mean that it isn't compiled-interpreted.
And, it's worth mentioning, interpreted does NOT mean slow, bad, or unprofessional! I think a lot of people are afraid if they admit that Java is compiled-interpreted, they'd be admitting it's somehow "bad," but that is most assuredly not the case.
Nope. That's an interactive language...so, I guess that's another entry to this list?
If your claim was that an assembled language has as shippable artefact hardware machine code, then I would not make a big point out of it. But...
C and C++ programs also depend on a common runtime. They do not work without it.
You can include the Java runtime with Java application if you want.
The runtime for .Net applications is included with Windows these days, so can ship your compiled C# program without users needing to get a runtime. By your definition is it then an assembled language or an interpreted language.
Sun made hardware which natively runs Java bytecode. It was nog a big success, but it could run your .jar directly on the CPU. So it's an assembled language after all.
C#, C++, and C are three different languages, btw.
As to C++ and C, they often rely on dynamically linked libraries, but dependencies are an unrelated issue for any language. You'll note I never brought it into the Java discussion; going into dependencies is another moving-the-target distraction tactic (don't worry, I won't blame you for inventing it...it's been in use for a while.)
C++ and C can produce binaries which require no dependencies, simply by avoiding the standard library.
That said, I will admit to using the wrong term a moment ago; runtime is a dependency library, whereas what I'm referring to with Java is the software responsible for executing the bytecode on the target machine.
Dependencies shouldn't enter into this discussion, all languages (practically speaking) have to be able to resolve dependencies.
Also a case of moving-the-target. I already stated earlier that there were impractical means by which virtually any assembled languages can be interpreted, and virtually any interpreted/interpreted-compiled languages can be assembled. This does not count because it has no bearing on standard deployment.
The inescapable point: Java is, for all practical intents and purposes, never assembled to a machine code binary file, such that it can be shipped to an end-user (w/ or w/o dependency libraries compiled to the same), and executed directly on a standard Intel, AMD, or ARM processor without needing an additional program to interpret (or, if you want to get pedantic, AOT/JIT-compile) the (byte)code.
An interpreted language has a software layer between the final, shipped result of compilation and its ultimate execution on the target machine.
Ergo, Java is compiled-interpreted. It is NOT assembled. It is also NOT interactive. (But, yes, it's still a real language.)
Even machine code is interpreted by the processor's microcode, which is exchangeable on some processors and FPGAs. The machine executes nano-code on most processors these days, even RISC ones.
Extreme Programming. It is about valuing the people on your team, and working effectively together, that is far from Extreme.
haha, I guess "extreme" is a commentary on historical common practices. We even pay extra hours here!, and no whips!, even water to drink!, extreeme!
Extreme is a reference to taking a best practice and applying it to the extreme. Extreme code reviews become pair programming. Extreme testing becomes TDD, with comprehensive coverage. Etc.
Map.
Literally every single different definition. I can think of three that programmers run into, off the top of my head.
I personally don't think Map is a wrong name.
macmillandictionary.com/dictionary...
The problem is, "which map?" If I'm talking about Maps, am I talking about:
map()The problem is that
mapis so unspecific in our field, there's a lot of ambiguity and that can lead to confusion.Map: Pooh Bear
Cartography: i.kym-cdn.com/entries/icons/origin...
There's a server in serverless.
Correct!
I always felt like "polymorphism" was an unnecessarily complex word for what it really is π€£
I guess it's not inaccurate - just overly confusing.
Maybe we should simply call it "likeness"? It might make the discussion around the whole term easier, because you can more easily explain why "likeness" leads to more reusability and less complexity.
It could also make the term more general and maybe even lead to other "likeness" patterns.
I feel like this whenever I learn anything about category theory. The words are so much fancier and more complicated sounding than the concepts, but...I guess we need to call 'em something.