The fermi paradox isn't even a real paradox.
We don't have enough information on how likely or unlikely life is to occur because we haven't even been able to replicated it yet.
It could be that life is so unlikely that it we're lucky to be here.
10 karma · joined September 25, 2020
We don't have enough information on how likely or unlikely life is to occur because we haven't even been able to replicated it yet.
It could be that life is so unlikely that it we're lucky to be here.
Also the migration from python 2 to 3 is actually the best migration ever. Breaking changes on a code that has a massive library around it. All code is migrated along with the libraries. I haven't heard of any migration done as successfully as python. It required movement of the language and the entire community to make it happen.
Most migrations refrain from breaking changes and instead they take the less risky route and make the language backwards compatible at the cost of being more bloated. See C++ 17 and C++ 20.
But despite this, yeah these are complaints that I've heard, but this is totally unrelated to the hate I see. Like parentheses in lisp is something to complain about but not something to hate lisp for.
The hate I believe is more egotistical than anything. One interviewer told me I could code in any language other than python because python makes things too simple. The hate is because they believe python programmers are stupider than normal programmers.
That being said my favorite language is not python. It's my least favorite language out of all the languages I know well but not a language I hate.
But yes more important then just composition is to use combinators and segregate your combinators from IO.
I had an interviewer tell me that I couldn't code up the solution in python. I think it might be because python is so easy that people look down on it.
What are you doing? Speed reading? Even 2xing the reading time with verbosity is not a factor if lack of verbosity forces the reader to switch context multiple times in order to elucidate meaning.
>Sure, we do that for software also - we document things outside of the code. For example in a wiki, a README.md or sometimes even just above the code as comment/docs. But that's not what I was talking about, right?
Major difference. In math it's required. In programming it's recommended and rarely done. When it is done, it's rarely done in a form that's as complete or as detailed as math. YOu get an outline at best. Programmers are expected to read code without documentation because program writers are too lazy to write documentation.
SO what I'm saying is put your documentation into the code itself. Self documenting code with readable names as opposed to elegant.
>So you are fine if a developer does e.g. `c := (some super complex expression) // find relevant customer` and then goes on to use just `c` everywhere in their code instead of `relevantCustomerBlaBlaBla`?
relevantCustomerMetric is way better than c everywhere. Autocomplete should alleviate the pain of typing. Not every programmer arrives at the variable where it was incepted so they can't see the comment.
>Also, mathematicians don't always do that. Sometimes they just say "let x be [insert complex equation]". See for yourself in https://en.wikipedia.org/wiki/Conformal_geometry or https://en.wikipedia.org/wiki/Riemann_surface
Isn't "let x be" english? What's the purpose of those words? Clarity.
You took shakespeare and upgraded it to be more verbose than normal. That example does not disprove my point because you misunderstood.
Let's start with a normal example. My original Box example. Step by step. It is in your opinion that the Box example I created is waaay to verbose. My claim is that IF I translated my Box example into the English language it will not be considered Verbose by the average english speaker. Take this english phrase:
The measurement of the left bottom side of the box is 26 centimeters. The right upper side of the box is 10 centimeters.
Box: x is 26, y is 10.
struct Box {
x = 26,
y = 10
}
I'm not advocating insane levels of obvious of detail here. I'm obviously not saying we do this:
variableThatCanBeAddedToOtherNumbers = 22
I'm saying fill in the variable name with necessary details that the reader would need to know. Fill in details in your variable name that you would put in documentation to help the reader understand. This is what they call self-documenting code. Additionally there is no need to cut details for elegance, it is pointless to use an abbreviation if that abbreviation has a probability to be misinterpreted or confusing.
UpperLeftSideInCentimeters is infinitely better than x as x can lead to a ton of confusion. Either way nobody will call something "x" in english they'd choose the more verbose and informative way despite the "exhaustion" in reading. On average nobody complains about English so the same can be said if we did it in programming.
Additionally programming will never approach the verbosity of English. I'm just saying programming needs to be a bit more verbose and not excessively more verbose than English itself.
You're not a stupid person so you being not stupid knows that I and pretty much everyone on the face of this earth knows that we all are aware that no one understands ALL of learning. So if you're not stupid, and you already know this, why did you take the time to point out some pointless flaw in my wording?
I'll tell you why. Because you liked this analogy. You thought it was profound to compare learning to DFS and BFS and fractals and you were sort of offended when someone like me didn't find it profound. Not only do I not find it profound, I find it obvious and trivial. Comparing learning to fractals is like some offhand thought I can have for like 5 seconds than forget about because it's so trivial.
Too each his own man. If this article blew your mind great. It didn't do anything for me.
Here's another analogy for you.
Learning is like traveling down a path and encountering a several forks in the road. You can BFS the paths or you can DFS the paths
Replace Learning with "Life" and remove BFS. In life you can only choose one path every time you encounter a fork and the decision is permanent. No popping the stack like in BFS to try the other paths. It's just DFS all the way to the last final leaf node. You have one life so live it right.
Did that analogy blow your mind? Because I made it up 3 seconds ago. That's how trivial these analogies are.
decoAB = True
decoherenceOfTwoParticlesAandB = True
The decoherence of two particles, particle A and particle B.
The deco of A B.
Two languages where different levels of verbosity are considered to be normal. For programming be less explicit, use shorter names that are prettier but less clear, for English be absolutely clear, use correct grammar.... Why? Why do we feel programming languages need to less verbose and the english language needs to have a higher level of verbosity to be normal?
Regardless of the why behind our biases, what is clear is that it is a bias because two conflicting levels of verbosity indicates irrationality.
When you analyze it logically, it's by far easier to read english than it is to read a programming language even by a programming expert. Therefore the verbosity level of english must be the level of verbosity that is baseline for humans to have the most clarity in a single read.
This means that in general variable names are not verbose enough in programming.
No. If my program only modifies the left bottom side of the box it doesn't need the whole box defined. In this case and many cases similar to this, it's totally fine encoding more verbosity into the naming of the integer.
The "smell" your sensing here is only called a smell because you can't logically explain it. Your brain is firing off a false alarm.
I can easily make a variable name that can trigger the false alarm but you won't be able to come up with a reasonable nested structure to contain it.
theColorOfTheSkyOnAThursdayAt6PM = "ReddishOrange"
>I have in my day job some code we got from Korea. I'm told by those who have spent the time to understand it that it is good code. But since it was written in Korean it is a level harder to figure out.
Exactly this is my point. Abbreviations, lack of verbosity in naming and shortcuts might as well be Korean for the reader. It really doesn't matter how good the code is.... the understandability of your naming is by far more important.
Totally agreed.
struct BoxDimensions {
topLeft, topRight, bottomLeft, bottomRight
}
Not every concept can fit into a beautiful name as you did here. What if the box was a very specific box out of many boxes and I needed to specify the details?
DimensionsOfBlueBoxFromRoom253 = { ... }
That's only because you already know what Dim means. Many many times I see abbreviations that are unknown. For example:
TranBox.Dow
>Code with longer names are harder to scan.
Same with english. It's a small price to pay but people tend to enjoy reading english more than programming abbreviations and shortcuts. You spend an extra second reading a line, but you gain much more clarity about the intention of the programmer. Where with an abbreviated name you can often be unsure of what the programmer meant and you'd have to dig into the surrounding context.
trueBox.bottomLeft - measuredBox.bottomLeft
BoxWithEstimatedDimensions
BoxWithActualDimensions
Box_with_Estimated_dimensionS
>The second one is just exhausting to me at least.
Exhausting like the english language is exhausting? Exhausting like commenting your code is exhausting? People don't complain about the verbosity of English and all I'm suggesting is bringing the verbosity of programming a bit closer to English so that the understandability of your code is ALSO closer to english.
Except I don't see how a quotation proves anything or how this is relevant. First off is Lutwid correct? Can you think of things outside of language? Can you think in pictures? If so than I would say he's wrong.
Second off, what does this have to do with bad naming in a programming language? Nothing.
>No need for that, because history has shown that people like English keywords, but that's about it.
I'm not arguing for english or english keywords. I'm arguing for phrasing in naming things, this is exactly what literate programming is arguing for. I may have used the word "English" because HN is an english forum but you can easily replace that with "Any relevant language"
>Check discussion here: https://news.ycombinator.com/item?id=24730713
Check out my response to it here: https://news.ycombinator.com/item?id=24733487
The article is talking about composability not readability which is a separate problem. SQL is in fact quite a readable language. Many people can read a query and instantly derive meaning. Either way I am not talking about programming language syntax. I am talking about naming within the bounds of the syntax.
>let's look at one of these: COBOL. It is literally what you want: programs look like text, which comes from trying to make it read like English "for business people" (who don't use it anyways). And guess what? No one who actually uses it really likes the syntax.
It's not about whether or not the writer likes the syntax. Clearly program writers have a bias for elegance over readability. It's about whether someone can read your program and completely understand it in one pass. Clearly COBOL was first off, not guaranteed to be readable and second off had many many other issues outside of readability. Readability was definitely not the main issue with COBOL.
>Maybe you should start with Mathematicians and ask them to stop naming their variables "x" or "f" and use English instead of symbols. How about that? :)
All mathematicians are expected to write paragraphs in "English" or some other relevant language outside of equations. Many math papers and math books have more written english than equations.
Whenever a mathematician uses the letter "x" or "f" they define the meaning with an english phrase or paragraph. This is expected for clarity in math and in english but for some odd reason not expected for programmers. The mathematician can only get away with an "x" or an "f" because he has an accompanying english explanation defining those variables right next to the equations.
Programmers are like mathematicians writing conceptual papers using only equations and math symbols without the english explanations. We have the luxury to insert some english into the naming of primitives so we should take advantage of that lest all our programs devolve into primitives with single letter names.
Sure we can comment our code. But people tend not to do that to the degree that it's done to explain things in a mathematical research paper.
A better phrase is "Learning isn't coming up with new analogies for concepts you already more or less understand over and over again."
Happy? does that satisfy your overly pedantic mind?
This problem you describe occurs in the english language. In formal documentation of code written in English tends to be by far more verbose in their explanation of code than the code itself.
Yet we don't complain about english? Why?
What if I take all the crazy shortcuts we use in programming names and use that in documentation and daily communication. Would it make my communication seem less like rambling and seem more clear? Would it help lessen the obscurity of the macro level structure of my point? Will removing the continuous use of grammatical repetition with words like "the" or "and" lessen the large cognitive load on your brain so you can understand my english?
No it likely won't. In fact it will make me LESS understandable.
The dichotomy here illustrates a bias within human nature. For some reason people perceive a certain level of verbosity in code to be bad but not so in english. Given the fact that even among programmers English is much more readable than code I would say that there is definitely a huge unrealized mass delusion going on here.
Have you heard of literate programming by donald knuth? It's literally about taking every line of code and upping the verbosity by 10x by replacing it with a macro of an english paragraph. Literally an extreme version of the verbose variable naming I'm describing.
If you can see validity in literate programming than basically my variable naming is a tiny tiny step in that direction.
That's just your bias kicking in. I didn't define the requirements of the program. If I defined the requirements of the program to be ONLY printing out a number that represents the left edge of a box when the measurement is inputted into the console than defining an entire box struct is in itself a code "architecture" problem.
Maybe another name wouldn't trigger any "Smell".
speedOfLightInVacuumMetersPerSecond = 99999999999....
Vacuum.light.speed = 9999999999
You see it is not the grammar of the phrase that is making you want to restructure the code but the contextual meaning. This is one of those optical illusion like triggers in our brain, you want to organize something in a certain way but my post didn't give you a logical reason to do so. I never defined that an entire Box was provided as input.
The only reason you would want to structure your data like that is if you want to think about the Box as a whole from a more abstract level.
But there's nothing wrong with writing an entire app that focuses on the measurement of the left bottom side of a box. If that's the requirement, than there's no need to define the measurement as part of a higher order type "Box" if you're not doing anything with the other measurements.
First off this "clutter" exists in the English language itself yet I hear no one complaining. I don't communicate with other people using shortcuts and context aware abbreviations like your suggesting. I literally say "here are the measurements of the box" both in written documentation and by sound, what black magic says that this is so wrong to do in code?
Anyway here it is:
struct measurementsOfBox = {
measurementOfLeftBottomSideOfBox
measurementOfRightBottomSideOfBox
measurementOfLeftTopSideOfBox
measurementOfRightTopSideOfBox
}
Now you could argue that the clutter itself can hurt reading efficiency. But honestly think about it. That's like 5 seconds of extra reading out of your life. It's not a big deal.
Most programmers just have this version of OCD. I get it the struct looks really ugly, but there is nothing logically wrong with it.
I mean you could make it more elegant like this:
struct Box {
x
y
z
t
}
You made a common mistake here in your naming in assuming that "measurement" was a useless prefix. It's not... but that's besides the point because every program writer can make that mistake. That's why when you add a bit more clarity to your naming you have a larger chance to avoid this mistake at a small cost of adding some ugliness to your code.
>1) It's overly verbose. More than 3 words is a warning sign to me.
Warning sign of what? It's a similar warning sign that your brain fires off when you're alone in the dark in the woods. There's nothing to fear logically but your brain kicks off warnings regardless. Same with this, your brain kicks off some sort of warning but when you work it out logically there's Nothing. Verbose code is not bad just like verbose documentation is not bad.
>2) It's specific rather than generic. For instance if I name a function "sortSheepByHoofSize", it implies the reader know what hoofs are, cares about them and knows how to measure them. Whereas when naming it "sortSheep" or perhaps even just "sort", it's immediately understandable on a surface level to practically everyone.
Data referring to a specific concept or a generic concept is a structural decision made by you. I chose data referring to a specific concept. This happens in code. Not everything is generic and for specific things there's nothing wrong with using very specific names.
>3) Following on from 2), this type of naming lacks context. We should leverage the context of surrounding code and abstractions to make naming understandable, instead of trying to pack all the meaning into one name. Oftentimes there's repeated information in names that could be inferred from context instead.
>>We should leverage the context of surrounding code and abstractions to make naming understandable, instead of trying to pack all the meaning into one name.
There's no downside into packing more info into a name. Sure it can get to a point where it's unreasonable but in general there's nothing wrong with me calling something a measurement when that's what it is... This is an aesthetic issue that programmers react due to human bias, but there's nothing intrinsically wrong with prefixing measurement onto box. There's nothing wrong with repeated information either.
By prefixing measurement onto the Box struct I let everyone know that these are measurements on the box and not the position of the box. It's ugly but ugliness has nothing to do with readability or structure.
This is the bias programmers need to get rid of.
Find beauty in the structure of your code and find readability in the naming. Don't make the mistake of trying to find beauty in naming. Nobody wants to decipher code with poetic naming.
Have you guys heard of literate programming by donald knuth? He's taking what I'm talking about to extreme heights.
You're thinking about it the wrong way, an analogy to english doesn't prove your point when the analogy is irrelevant.
Sure there's advanced vocabulary in English. But within that domain the english is still understandable. If the reader understands the domain he understands what is written and does not need to decipher or decode what is written. The domain expert just reads it and gets it, no deciphering needed.
This is not what happens with domain specific code and this is not how domain experts read code therefore your analogy does not apply.
Reading code tends to be very very different from reading english and much much slower. Reading is actually an inaccurate term. The reader for code spends much of his time deciphering code and any name that helps elucidate context and eliminate deciphering is a plus. This occurs EVEN for domain specific code.
What happens with domain specific code is that a programmer tends to make up abbreviations on the fly and ends up writing something that is not readable at first glance and the reader needs to decipher the code. For example let's say I'm a domain expert in robotics and I want to encode positioning of the robot. For elegance I use this:
xPosRelB = 23
which is short for x position relative to base.
meters_west_from_base = 23
The end result is that in order to figure out what xPosRelB is the reader always has to sort of dig a bit at the context. He has to see how it's used, where that variable comes from or in other words he needs to "decipher" it. This is super common in programming but not very common when reading English. Again your analogy does not apply. In short the second name in the example is just read and understood and is by far the better choice.
When you ask the average programmer why he wrote xPosRelB rather than meters_west_from_base, he'll tell you that meters_from_base is too long and too ugly. Programmers bitch and moan about stuff like this that doesn't even matter. I had one guy tell me that you shouldn't mix and match camel_case or snakeCase because it just looks bad (there's a real reason why people don't mix it, and it's not aesthetics).
If I go meta and bring this topic up and ask the programmer why again.... then he brings up reading efficiency, exactly what you're doing here.
Readability and structure is what's important not aesthetics. What matters is that someone can read your code rather than decipher it.
Length and prettiness contribute nothing to readability and barely dents reading efficiency.
Domain targeted programming is stuff like this:
gallonsOfCompoundV = 34
compVg = 34
Of course the team may have conventions. For example my team prefixes the letter k to all constants. This stuff is fine and doesn't harm readability, but this is not what I'm talking about.
Why does the responsibility Have to be solely on the reader? There's plenty of code out there that's unreadable because of the coder, how is this outside of the realm of possibility? Why is all the onus and bias on the reader?
For example, readable:
measurementOfLeftBottomSideOfBox = 200;
LBB = 200;
The best code is code written by a talented programmer who can make the code readable to All people of All skill levels.
One thing people get confused about is readability and elegance. Obviously "measurementOfLeftBottomSideOfBox" is readable but not elegant. While "LBB" is certainly elegant but not readable. My philosophy is readability over elegance, but you will find many programmers are unaware of this dichotomy and have a strict subconscious aversion to writing something ugly like "measurementOfLeftBottomSideOfBox."
This aversion leads to more unreadability than necessary. It's some subconscious thing in our minds that makes us code this way but when you think about it.... there's no logical point in it at all. Aim to encode as much context as possible into your code because it's completely irrelevant how ugly the variable appears.
It's an analogy on learning. Every other day there's some blog post on HN about some analogy on some self improvement topic like learning, project management or complexity or whatever...
I'll tell you what learning isn't. Learning isn't coming up with new analogies for concepts you already completely understand over and over again.
I and pretty much everyone on this planet already knows what learning is, and unless you have a new learning technique, what is the point of comparing learning to a fractal? There's nothing new here.
I'm not trying to reprimand what this person wrote this but when you see some flavor of this on HN all the time it gets old.
People aren't designed to be programming either. People aren't designed to be working for startups.
People are designed for a hunter and gather lifestyle.
There is no data mismatch if the data model is richer, than it can cover it. Unless you're saying SQL is not rich enough to cover the PL.
Well you can implement a database that does that, it just wouldn't be table based data storage anymore. Postgresql supports JSON and enums if you want it but the minute you use these types things become less predictable in terms of performance.
>ORMs are notorious for being a leaky abstraction. Largely because the object and relational data model dont entirely match.
Wrong ORMs are notoriously leaky because the query translation is extra indirection. You need to compile to SQL and the SQL needs to compile to a query plan. This is why ORMS are bad.
As for the data types, Objects easily mimic types in SQL. You basically rarely ever encounter problems with incompatible type systems.
>When was the last time you wrote a 500 line sql query? A thousand line? My point is that sql queries are short enough, that further abstraction is not really missed. That doesn't mean you should put 0 logic in your query.
When did you last write a 500 line function? When did you last write a 100 line function? You shouldn't be doing that if you are. Case in point, the total lines of SQL written in any source code usually well exceed over 500 and that is a case for composability. T
This is no different than regular source code. If you're writing 500 line functions in your source code than you're not even taking advantage of modularity in programming languages outside of SQL so of course for you it doesn't matter. Because composition doesn't matter for you period.
>This is a strawman.
No it's a statement written in the english language. A strawman is something that doesn't EXIST, because men are made out of flesh not straw.
It's sort of similar to the non-existence of what was suppose to be written in response to my statement: an actual counterpoint or an argument. But then how can you write such a thing if it doesn't exist?
>I disagree. At scale you have data that has mixed cardinality. The indirection allows the db to chose the best algorithm given the size of underlying data at runtime. Sometimes that doesn't work properly, but the vast majority of time it is a significant benefit. Its sort of like how sometimes compilers dont work properly and you need to hand optimize, but in practise that is rare and you wouldn't throw out the compiler because the other 95% of time its better and lower effort than if you had to always do it by hand.
Sure but when it comes time to hand optimize SQL is extremely bad and you need to hand optimize SQL all the time. Not necessarily most of the time, but enough times that it's a real problem. That is the point and that is what I said. It's basically the biggest headache with SQL. If you've ever done analytics you'd know this is a huge problem.
It's better to have a language that allows explicit decorators that allow the programmer to choose optimization procedures when needed. Instead in SQL often optimizations come in the form of hacks. Case in point: SELECT * FROM A is worse then SELECT A.column1 FROM A. The later optimization comes in the form of a language hack and not explicit syntax.
Not saying the alternative mentioned in the article would solve this problem nor am I saying a solution exists... but if there's any big problem with SQL today it's hand optimization for sure.
The full post is saying that the interpretation of what you see is NO DIFFERENT from an alternate universe. I am not saying this is actually what's going on.
All reflections on all surfaces can be interpreted this way.
The point of the example is to say that the language people use to refer to reflections is to refer to this alternate higher level interpretation and is still valid. Only the most pedantic person will say "nothing" has flipped and call it just bouncing photons.
> If what you see in the mirror would be another universe then it would have to me MIRRORED to look like we see things in a mirror.
This is exactly what I'm saying nothing precludes the alternate universe to be MIRRORED. The alternate universe is a mirrored universe, Get it?
>The wrong assumption is that your universe and the one you see in the mirror is identical.
This is your assumption. I never said this. I said ALTERNATE universe. <--- read the word ALTERNATE. I'm assuming here that you might be delusional and seeing the word IDENTICAL instead of alternate.
>No matter how you would flip the other universe it would never look like what you see in a mirror.
Again if the atoms in this universe and flip them across the Z-axis the light bouncing off those atoms would produce exactly what you see in the mirror.
>Just use 2 identical but non-simple objects place them next to each other for example 2 coins. No matter how you flip or rotate the coins it will never look like there is a mirror in between. You would need a mirrored coin for that.
When I say a z-axis flip I mean inside out. Imagine holding a glove, then turning that glove inside out. That is a z-axis flip. Your coin analogy is completely off.
>I did and I pointed out why your theory is garbage.
I never even made a theory I just used the alternate universe thing as an example of the vernacular people use... people refer to the reflection as a real object and not as bounced photons and this interpretation is valid because it can't be proven otherwise. You just didn't get it. Hopefully you reread my post and realized that it is not my "theory" that's garbage but your brain.
SELECTCLAUSE(WHERECLAUSE(relation)) = relation
WHERECLAUSE(SELECTCLAUSE(relation)) = relation
My example in the previous post has a flaw where it's not clear what:
SELECTCLAUSE * WHERECLAUSE = ????
Not even sure if stored procedures are part of the sql standard.... these seem to me to be just specific syntax additions added on by specific databases.
I mean it works so why not. I could code all my SQL this way.
The SQL data types consist of a few primitives like ints strings and chars placed in higher order data types that are tables. These types are easily isomorphic to data structures and primitive types in traditional programming languages. There is zero mismatch here, in fact the data structures in application programming languages tend to be much richer than SQL.
See orms for reference. ORMS have their own set of problems but data mismatches are not part of those problems. If the programming language enables the creation of sum types like rust or haskell than there can never be a mismatch as these languages can produce virtually any type.
>SQL queries are generally really short. Rarely more than a few lines (might be different for people doing ad-hoc analysis instead of making a db backed application). I don't need modularity for a program that is only a few lines long.
For complex applications this is not true. In general the classic model for web development is to place as much logic as possible into the SQL query and as little logic as possible into your heavy Python web app. The web app is suppose to serve as something that routes IO the bulk of your code/logic and heavy lifting should be shifted to the database. Simple apps can avoid this but in general complex apps cannot.
Case in point do you put your where clause in the application program than download the entire table? Or do you throw as much logic as possible into the query so the database outputs a result as close as possible to what you need? The later statement is the right answer.
>I don't really feel like composability/modularity is all that important in SQL.
You're not completely wrong. The bigger issue is SQL optimization. Because Databases form the backbone of computation for a standard web app SQL provides a layer of indirection that makes optimization harder. For C++ optimization is built into the syntax itself, you make choices while coding to optimize things. For SQL you open up the black box and look into the query planner to see what your High level code is compiling too. SQL is a really bad interface for doing optimizations but that's a topic for another day. The topic of this post is modularity and he's not wrong... SQL is not a composable language and there's no performance loss in making it more composeable.
So for example the union operator can take two different relations that have the same columns but different rows and create a new relation.
In this binary operation that takes two different relations.... the attributes of one relation (the columns) is indeed the attributes of the other relation.
See here: https://www.geeksforgeeks.org/basic-operators-in-relational-...
Look for "union" in the link above.
>Union on two relations R1 and R2 can only be computed if R1 and R2 are union compatible (These two relation should have same number of attributes and corresponding attributes in two relations have same domain)
It's the same thing for unary operations like select. A select expression can operate on different relations providing that the relations have the relevant attributes.