[sadok]

You are missing the whole point. As a designer that dabbles a bit in code and servers, I literally have NO idea what most of the words you just used mean.

I know that S3 has nothing to do with FTP, but it's a nice analogy that I can relate to. Get off your high horse.

[lukev]

Here are some better names for S3 that aren't misleading:

- Binary Storage

- Blob Storge

- File Storage

- Reliable Storage

FTP is a specific protocol. Hard drives (as a sibling comment mentions) are a specific technology. Our discipline is confusing enough that names should be precise, not analogical.

[SilasX]

That still seems unnecessarily nitpicky and like it misses the point of the parallel. I'm reminded of the running joke on Californication:

"This is Santa Monica Cop. It's my innovative, original series about a hip, streetwise cop who brings his own brand of policing to a much wealthier area than he's used to."

'Oh, like ... Beverly Hills Cop, then?'

"Nah, you're not getting it! See, it's in Santa Monica!"

Yes, S3 doesn't natively allow retrieval/upload via the FTP protocol. But at the level of abstraction of "what does this service do for me, and why would I want to dig into the docs and incorporate it into my system?", the FTP analogy communicates the use case.

"This is S3. It's a way to map a bunch of keys -- which look like directories and naturally follow a kind of hierarchical structure -- to opaque blobs of data, allowing CRUD operations."

'Oh, like an FTP server, then?'

"Nah, you're not getting it! See, you talk to it with a different protocol."

[sam0x17]

"binary" and "blob" storage makes it even more confusing IMO. How about "file storage where you can only ever read, write or completely re-write (but never only partially modify) an existing file and there are no directories but the file names allow slashes so you can fake directories, and paths are called 'keys', where all the files you upload are publicly accessible via HTTP if you enable that and otherwise are accessible via a widely supported but annoying REST-based API and signed URLs, and where only download bandwidth and monthly storage (but not upload bandwidth) is billed, and is billed based on exact usage with no minimum recurring fee". I guess that's too long though.

[AlexB138]

"File Storage" is a bad idea for the same reasons comparing to FTP is. It might work for a near layman, but it can actually communicate misinformation to someone who knows slightly more about storage. Specifically, S3 is Object Storage, as opposed to File or Block Storage.

This is why "simple descriptions" are hard. Leaving nuance behind makes a lot of room for confusion.

[Aeolun]

Since S3 was more or less the first service to have the concept of Object storage, I think we would have been able to deal with ‘File’ storage.

Also, I think the difference is more between filesystem and object storage. You are still uploading files to both.

[sam0x17]

Yes, I'm still waiting for an "unlimited pay-as-you-go SFTP service" that uses something like S3 as a backend, but you connect with SFTP.

[hk__2]

> Get off your high horse.

Please keep the discussion respectful.

[thekelvinliu]

the original comment offers some constructive criticism because the article does have the potential to misinform novice users about what certain services do and the technologies they use. yours is more of a directed personal attack; keep in mind that this is hn. good on you for knowing a priori s3 is not ftp. but i wouldn't expect someone new to development to necessarily know this. as a result, they could have an even harder time figuring out how to do things if, for example, they search for advice on how to connect to the s3 ftp server.

[sam0x17]

That said, I would expect someone learning web development to start out the old way like we all did with static HTML and a simple apache server and work their way up to newer things from there. Not doing this runs the risk of completely missing the point of how everything works.

[eksemplar]

To what end? Would you also teach someone binary, assembly and C before you taught them JAVA?

I see your approach in a lot of fresh graduates. They’ve learned things from the ground up, which means a good chunk of what they’ve learned is useless historic knowledge that doesn’t actually teach you a lot about how the modern eco-system of the web works.

That’s time they could have spent learning docker and authentication security. I mean, it’s often the one guy/girl who’s spent their free time setting up ADFS authentication in AWS for the fun of it, who gets the job.

But why wouldn’t you teach them that instead of teaching then legacy shit they’ll never use that also isn’t really that handy for understanding how things work now?

We’re supposed to stand on the shoulders of giants, and having struggled with apache or better yet the IIS, is just so utterly useless.

[rpedela]

There is still a good reason to teach C and assembly even if they end up never using it in the real-world. Just having to manually manage memory teaches one how to be careful because the result is a hard-to-debug segmentation fault if one isn't. It is also teaches how the machine works at a low-level which is extremely helpful in writing performant code in any other language.

Should they learn older technologies like Apache or IIS? No, learning those technologies teach few, if any, transferable skills. Should they build a web server from scratch in C? Yes, that definitely teaches transferable skills even if they use Node or Go or whatever the latest web tech stack is later. Should they also learn the latest web tech stack? Absolutely.

[eksemplar]

Does C really teach you how to be careful with memory in JAVA?

I think teaching big O is and focusing on efficiency is much better than teaching someone C. Especially in the modern world where garbage collection isn’t bad and memory is abundant.

I mean, we use a lot of Python and a lot of JS, both are fairly inefficient. On the tech side, but it’s very productive on the human end, and Human Resources are a lot more expensive than memory.

If you spent 1 week writing something that was half as efficient as if you’d spent two weeks on it, that extra week of pay, will still be paying for for the additional hardware after you die of old age.

Not the best CS lesson of course, but having hired people who learned C before X, they really don’t seem to have learned the memory lesson anyway.

[rpedela]

I have definitely run into memory bugs in managed languages that someone without my experience would have no clue how to debug since the managed language hides that information. Having said that, learning to be "careful" is much more than just avoiding memory bugs. It is about learning to avoid mistakes by really thinking about the code you are writing so that you don't end up screwing yourself or the team later. That can be applied to memory management, class design, API design, complex algorithm development, etc. There are many ways to learn to be careful but manual memory management is one of the best because the consequences are so severe, in terms of debug time, if you aren't careful.

Big O is useful but I think its usefulness is overblown. There are cases where understanding how the kernel allocates memory or how CPU caching works or how networking works, you can develop an algorithm that is inefficient in terms of Big O but is still performant. Sometimes you can even beat the best theoretical algorithm. The reason is that k is extremely important. If I can make k extremely small using my knowledge of the computer and n is within reason, then Big O often doesn't matter. So I don't have to waste time implementing fancy algorithms as a result. But I also have a better feel when Big O does matter. If I can't make k small or n is a huge number or both, then I spend the time on algorithm optimization and then understanding Big O is helpful.

I will give you a real example with GPUs. Let's say you want to do some GPGPU and you have data that is too big to fit in RAM. How do you process this data efficiently? Knowing how the GPU works is very important to solving this problem. You could spend days, weeks, years optimizing the crap out of Big O in your code, but it won't really move the needle in a lot of cases because that isn't the bottleneck. The primary bottleneck in this case is the PCIe bus and a high-level understanding of how it works is needed to keep it full of data as the GPU is processing it. Once that is solved, the next bottleneck will likely be the data format. The GPU is most efficient when each data sample is independent which is related to how the GPU cores work, caching works, etc. So putting the data in GPU-friendly format (not always possible) will make everything go faster even before worrying about Big O.

What C does is it forces you to learn how the computer really works because it is hard to be productive in C without that knowledge. And that knowledge is largely transferable.

I certainly agree with learning and using Python or JS when it makes sense because they are very productive languages. But from an education perspective, people who only learn JS are less likely to be able to solve the really hard problems because they lack that foundation of how the computer works. And there are plenty jobs where that doesn't matter too much but you should probably have at least one person around that really understands how the computer works for the times when it does.

[sam0x17]

I wouldn't teach binary, assembly and C before teaching Java. That's a bad analogy. It's different with the web. You have to understand what clients and servers are, and it's much more clear with a basic apache setup than it is with, say, the node.js ecosystem which blurs that line between client and server to a confusing degree.

[sam0x17]

So you would advocate for, say, learning JSX and react before learning how to use vanilla JS, and maybe a little bit of JQuery to manipulate the DOM, or learning HAML before learning HTML? No wonder the current generation of junior devs is so damn confused.

[eksemplar]

I think you should learn the foundations of JS before you use a JS library, but I see no value in teaching people JQuery before you teach them react.

[sam0x17]

I politely disagree. JQuery is (largely) syntactic sugar over the built in node selection engine and various CSS properties, animations, etc, that are built in and very much a part of normal everyday browser javascript. React is something else entirely, and creates a system parallel to the DOM rather than simply using the DOM the way it was intended. You have to understand the DOM and how it is typically used before you jump to something like React, and a great way to do that is vanilla js with a little JQuery sprinkled in. There is less friction this way, and it demonstrates the impetus for separating javascript from HTML and not using selectors for everything. Otherwise you miss the point of why React is good, and you run the risk of misusing (or in the very least under-appreciating) it. People with all this background still often make terrible React apps, so imagine how bad the people who don't even understand what or why React is will do.

[scarface74]

Why is he that is on his high horse? It would take watching one or two videos on YouTube or Pluralsight to know on a high level what these services are.

If I came to you not knowing anything about the vocabulary used in your field of expertise is that your field’s fault or mine?

[Aeolun]

It might be descriptive, but it’s still a terrible name for a product that doesn’t have anything to do with FTP.

“Simple Storage Service” is one of those products that they actually named sensibly.

I guess the article just had to make up an alternative.

[mr_toad]

Dropbox would be a better analogy.

[marpstar]

To me, "Dropbox" means "a folder that syncs across your devices"