The Next Big Language(steve-yegge.blogspot.com)
steve-yegge.blogspot.com
The Next Big Language
http://steve-yegge.blogspot.com/2007/02/next-big-language.html?
74 comments
I see no problem with this, the original submission is 3.5 years old. That's quite a long time to be complaining of reposts.
Yes I can see the value of reposting older submission, I think my main discomfort is having to add random characters to the urls in order to fool the dup detector so that people can post an old article again.
If the community agrees there is value in reposting old articles, maybe change the dupe detector to allow reposting old articles after N days. Since that would become part of the system (instead of working around it), it would become easier to link old and new submissions for example...
I just don't like it when one has to work against the system to do something if the community seems to feel that something is worth doing.
If the community agrees there is value in reposting old articles, maybe change the dupe detector to allow reposting old articles after N days. Since that would become part of the system (instead of working around it), it would become easier to link old and new submissions for example...
I just don't like it when one has to work against the system to do something if the community seems to feel that something is worth doing.
Ah, I see what you mean. It is rather inelegant, but not that big of a deal, in my opinion...
HN is about the articles, certainly, but also about the users and their comments. I would think that time having passed would justify seeing what new comments time may have brought.
Last time I checked, the de-dup filter only looks at article that are less than x days old. (Not sure what the specific "x" is.)
Oh good idea! (see my other reply), unfortunately 3.5 years seems to still be disallowed, that's why the submitter had to add '?' to the url.
Ahh... I think we all miss Big Stevey. He role was never replaced and it's a shame for our entire community.
I'm glad this was posted. It was written four years ago (Feb. 2007), and his quote is, "[The NBL] is going to arrive very soon (timeline: 18-24 months ...)" He later gave away that he was thinking the NBL was to be server-side Javascript. You have to hand it to him; that was a great guess, even if the timeline was off.
I'm glad this was posted. It was written four years ago (Feb. 2007), and his quote is, "[The NBL] is going to arrive very soon (timeline: 18-24 months ...)" He later gave away that he was thinking the NBL was to be server-side Javascript. You have to hand it to him; that was a great guess, even if the timeline was off.
Looking at Yegge's projects, I think NBL was just "javascript". The first big one was a rails clone on Rhino, which he talked about but never released (http://www.youtube.com/watch?v=1QD9XQm_Jd4).
After that, he started building a system for extending emacs with JS, named "ejacs". It never got fully baked, but the effort produced the very nice js2-mode. Details here: http://steve-yegge.blogspot.com/2008/11/ejacs-javascript-int...
So, I think NBL was just "Javascript". Awesome call. Despite the problems with the standards process, JS has exploded in popularity over the past three years.
After that, he started building a system for extending emacs with JS, named "ejacs". It never got fully baked, but the effort produced the very nice js2-mode. Details here: http://steve-yegge.blogspot.com/2008/11/ejacs-javascript-int...
So, I think NBL was just "Javascript". Awesome call. Despite the problems with the standards process, JS has exploded in popularity over the past three years.
Maybe you're already aware of this, but a few months ago he started occasionally posting again -- here's his "I'm back" post: http://steve-yegge.blogspot.com/2010/07/blogger-finger.html.
That said, I miss his longer-form and more frequent posts too.
That said, I miss his longer-form and more frequent posts too.
How was that a great guess? Certainly things could change, but very very very few people are doing server side JS right now. That could change, but I'm still pretty skeptical. Node.js (if that's what you're thinking of) is still very much in the experimental stage.
He doesn't say it will be ubiquitous in that timeframe. You'd have to be pretty crazy to think that. He means it will arrive. Which is correct. The thing is, javascript is what's available in all devices. And it's a pretty nice language.
it's also showing up in other things. I believe KDE is using it as the primary scripting language for their stuff. Apple has dipped it's toe in that water with the dashboard widgets. etc
Another good example is Google using it for their scripting project for Google Docs. Works using Rhino on the JVM.
I used to work on this project. It's pretty rad from a tech standpoint.
I used to work on this project. It's pretty rad from a tech standpoint.
A couple of IBM/Tivoli products (TDI and TAM ESSO) use it as the scripting language as well.
Incidentally, i actually am doing server side javascript, but on Rhino, instead of node. I'm certain that Stevey meant Rhino, rather than node when he wrote that particular blog post.
Rhino makes sense given "Rule #5: The Kitchen Sink" and "Rule #6: Multi-Platform."
he definitely meant Rhino, as in Rhino on Rails http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html
This coming from the guy who used to work on Google Apps Script.
He was off on one item for sure: good tools for Javascript OUTSIDE web development.
I am currently in the middle of a 100k(not all mine) LOC embbeded Javascript project consisting of multiple files and it is rough going.
Eclipse IDE for JavaScript Web Developers is the crutch I am currently using, it feels better than most commercial packages I tried(Aptana, Komodo, etc.), but that is not saying much.
What I want most is the ability to reliably zoom in and out of functions, but the indexing over multiple files is quite shoddy.
The bad habits Javascript encourages make for frustrating reading of code (like where did that foo.bar just come from, if bar was not a property in the initial declaration of foo). Not everybody reads Crockford...
Until Javascript is feasible on larger projects, it will not be general purpose NBL.
I am currently in the middle of a 100k(not all mine) LOC embbeded Javascript project consisting of multiple files and it is rough going.
Eclipse IDE for JavaScript Web Developers is the crutch I am currently using, it feels better than most commercial packages I tried(Aptana, Komodo, etc.), but that is not saying much.
What I want most is the ability to reliably zoom in and out of functions, but the indexing over multiple files is quite shoddy.
The bad habits Javascript encourages make for frustrating reading of code (like where did that foo.bar just come from, if bar was not a property in the initial declaration of foo). Not everybody reads Crockford...
Until Javascript is feasible on larger projects, it will not be general purpose NBL.
Perhaps there won't really be a Next Big Language. One thing that's become clear to me in the last few years since 2007 is that it's a hell of a lot easier to make an awesome programming language now than it was then. LLVM, CLR, Mono, JVM (specifically how it's changed to allow for dynamics and now it's changing to allow for traits and so on): all of these things let mere mortals make potentially awesome programming languages and immediately workable for production environments. All in a tiny fraction of the time that it would have taken a few years ago. The explosion of seriously awesome languages onto the scene in the last few years is evidence.
Will there ever again be a single language that captures as much of the mindshare as any of the other big languages have in they heyday? C, C++, Java, even Visual Basic occupied a huge fraction of the developer community at their peak. Some of those may be rising still in eyeball hours per month, but definitely not rising in terms of total fraction of all programmer hours being spent.
Perhaps the future is really more about consolidation for virtual machines and compiler middleware, and proliferation of end user languages? Different strokes for different folks?
Today it's not unusual at all for a larger system to use a a mixture of Scala, Java, and Python, plus some Erlang via RabbitMQ or eJabberd or CouchDB, not to mention pulling in data sources from REST or RPC type sources. Do we see that kind of mixed bag of choices getting smaller in the future, or larger?
Maybe the future is diverging on technology choices at the end points, where applications are written, and converging under the covers, where the applications are compiled and executed.
Will there ever again be a single language that captures as much of the mindshare as any of the other big languages have in they heyday? C, C++, Java, even Visual Basic occupied a huge fraction of the developer community at their peak. Some of those may be rising still in eyeball hours per month, but definitely not rising in terms of total fraction of all programmer hours being spent.
Perhaps the future is really more about consolidation for virtual machines and compiler middleware, and proliferation of end user languages? Different strokes for different folks?
Today it's not unusual at all for a larger system to use a a mixture of Scala, Java, and Python, plus some Erlang via RabbitMQ or eJabberd or CouchDB, not to mention pulling in data sources from REST or RPC type sources. Do we see that kind of mixed bag of choices getting smaller in the future, or larger?
Maybe the future is diverging on technology choices at the end points, where applications are written, and converging under the covers, where the applications are compiled and executed.
I keep thinking that the Next Big Language will be a thing of re-evolution, e.g. someone going back to C and retracing steps of C++ but in a more sensible way.
Also, on a tangential note -- the garbage collection is a huge deal if an adoption of the NBL among C/++ programmers is considered. The only way is to have the garbage collection optional. Similarly to how D has it, but much much simpler. Something like adding new_gc operator (or a malloc_gc function) and to have two kinds of memory blocks - manually managed and garbage collected...
Anyway, it's just a thought from an old fart camp :)
Also, on a tangential note -- the garbage collection is a huge deal if an adoption of the NBL among C/++ programmers is considered. The only way is to have the garbage collection optional. Similarly to how D has it, but much much simpler. Something like adding new_gc operator (or a malloc_gc function) and to have two kinds of memory blocks - manually managed and garbage collected...
Anyway, it's just a thought from an old fart camp :)
That sounds like Objective-C. One of the reasons I first liked working with Objective-C (before the iPhone made it trendy) was that it seemed like a much better-executed version of what C++ was aiming to be. It has optional garbage collection now, but only on the Mac. Its type system is even close to what Steve described in this article.
just curious, do you allow malloc_gc'ed items to reference malloc'd ones?
Sure.
malloc'ed item could be the same as malloc_gc'd, but with its reference count artificially bumped up by 1. free() would decrement the count and the item will be picked up by the GC later on. If there's a provision for an immediate disposal of unreferenced items, then we are back to the standard malloc/free behaviour in case when malloc and malloc_gc items are not mixed.
malloc'ed item could be the same as malloc_gc'd, but with its reference count artificially bumped up by 1. free() would decrement the count and the item will be picked up by the GC later on. If there's a provision for an immediate disposal of unreferenced items, then we are back to the standard malloc/free behaviour in case when malloc and malloc_gc items are not mixed.
Reference counting is a bad C++ substitute for a real GC.
Sure, absolutely. Just as C++ is a bad substitute for a real language.
(edit) </sarcasm>
(edit) </sarcasm>
The D gc is not more a problem than C++ new is for real-time... RAII is possible and you can avoid allocations, also make custom allocators.
I'm really asking myself when ECMA Script will take over the world. Everyone is talking about that it will be the NBL. It's not that I don't like ECMA Script but there is a shit lot to do to implement all those language features into ECMA Script.
All those stuff and sure much more have to be done:
- performance of eval() (yes, I even don't know if this is ever possible)
- tools (great-eclipse-visual-studio-like IDE)
- Destructuring bind (e.g. x, y = returnTwoValues())
- Standard OOP with classes, instances, interfaces, polymorphism, etc.
- Visibility quantifiers (public/private/protected)
- Iterators and generators
- Namespaces and packages
- Operator overloading
- Static typing and duck typing
- Solid string and collection libraries
Does anyone know if ECMA Script is going to implement half of the stuff?
All those stuff and sure much more have to be done:
- performance of eval() (yes, I even don't know if this is ever possible)
- tools (great-eclipse-visual-studio-like IDE)
- Destructuring bind (e.g. x, y = returnTwoValues())
- Standard OOP with classes, instances, interfaces, polymorphism, etc.
- Visibility quantifiers (public/private/protected)
- Iterators and generators
- Namespaces and packages
- Operator overloading
- Static typing and duck typing
- Solid string and collection libraries
Does anyone know if ECMA Script is going to implement half of the stuff?
performance of eval()
This will probably not happen, the general consensus is that eval is basically considered harmful and you should use new Fuction(argname, argname, argname, code) to do the same thing. ES5 strict mode places a number of restrictions on what eval can do.
tools (great-eclipse-visual-studio-like IDE)
This is tricky and less necessary for non-C/Java/C# languages but I assume you mostly mean code completion and minor refactorings. The mozilla JS team has a type inferencer for JS, which is the first step, but it's not particularly useful. I've been poking at this, so we'll see if I come up with anything. Someone will get to this at some point even if I don't actually manage to make anything useful. For integrated debugging, I know the cloud9 IDE (web based) has been messing with node.js/Chrome debugger integration but I haven't messed with it.
Destructuring bind (e.g. x, y = returnTwoValues())
http://wiki.ecmascript.org/doku.php?id=harmony:destructuring
Standard OOP with classes, instances, interfaces, polymorphism
http://wiki.ecmascript.org/doku.php?id=strawman:classes
Visibility quantifiers
access control via proxies: http://wiki.ecmascript.org/doku.php?id=harmony:proxies
Iterators and generators
Support available in Mozilla's implementation with the correct mime type. Brendan Eich wants to add them, but I can't find a harmony strawman for it (maybe it was accepted?). I do know yield is a reserved keyword in ES5 strict.
Namespaces and packages
Called modules: https://docs.google.com/Doc?id=dfgxb7gk_34gpk37z9v
Operator overloading
Not aware of anything.
Static typing and duck typing
Static typing is available in ActionScript3. Not aware of any efforts beyond this. I know there were proposals for type annotations in ES4 but I haven't heard much from ES5/Harmony in this area. I think most JS developers aren't particularly interested.
Solid string and collection libraries
Unlikely to be in the standard, look to implementations/userland libraries.
This will probably not happen, the general consensus is that eval is basically considered harmful and you should use new Fuction(argname, argname, argname, code) to do the same thing. ES5 strict mode places a number of restrictions on what eval can do.
tools (great-eclipse-visual-studio-like IDE)
This is tricky and less necessary for non-C/Java/C# languages but I assume you mostly mean code completion and minor refactorings. The mozilla JS team has a type inferencer for JS, which is the first step, but it's not particularly useful. I've been poking at this, so we'll see if I come up with anything. Someone will get to this at some point even if I don't actually manage to make anything useful. For integrated debugging, I know the cloud9 IDE (web based) has been messing with node.js/Chrome debugger integration but I haven't messed with it.
Destructuring bind (e.g. x, y = returnTwoValues())
http://wiki.ecmascript.org/doku.php?id=harmony:destructuring
Standard OOP with classes, instances, interfaces, polymorphism
http://wiki.ecmascript.org/doku.php?id=strawman:classes
Visibility quantifiers
access control via proxies: http://wiki.ecmascript.org/doku.php?id=harmony:proxies
Iterators and generators
Support available in Mozilla's implementation with the correct mime type. Brendan Eich wants to add them, but I can't find a harmony strawman for it (maybe it was accepted?). I do know yield is a reserved keyword in ES5 strict.
Namespaces and packages
Called modules: https://docs.google.com/Doc?id=dfgxb7gk_34gpk37z9v
Operator overloading
Not aware of anything.
Static typing and duck typing
Static typing is available in ActionScript3. Not aware of any efforts beyond this. I know there were proposals for type annotations in ES4 but I haven't heard much from ES5/Harmony in this area. I think most JS developers aren't particularly interested.
Solid string and collection libraries
Unlikely to be in the standard, look to implementations/userland libraries.
All that stuff would be nice to have, but I don't think they're required for it to be a widely useful language. What I think the minimal required set is:
- Fix "this". Even people who know what they're doing screw it up.
- Make keywords not reserved unless the language actually uses them. I mean seriously.
- Namespaces / packages / something.
- A package manager, like CPAN / Rubygems / whatever.
- A good IDE (even a half-assed attempt at code completion) and a debugger. I happen to really like Dashcode, I think it would be good if it were more generic.
Everything else on your list is great, but I think it can wait until later, or it's really just a feature of the language (not all languages have Smalltalk-style OO and That's Okay). Iterators and generators it actually has; operator overloading is widely reviled so I don't think that'll be a barrier to adoption.
- Fix "this". Even people who know what they're doing screw it up.
- Make keywords not reserved unless the language actually uses them. I mean seriously.
- Namespaces / packages / something.
- A package manager, like CPAN / Rubygems / whatever.
- A good IDE (even a half-assed attempt at code completion) and a debugger. I happen to really like Dashcode, I think it would be good if it were more generic.
Everything else on your list is great, but I think it can wait until later, or it's really just a feature of the language (not all languages have Smalltalk-style OO and That's Okay). Iterators and generators it actually has; operator overloading is widely reviled so I don't think that'll be a barrier to adoption.
On keywords: "ES4 allows the use of keywords in contexts where they were prohibited in ES3, e.g., as field names in
objects: {function:37}, o.try, and ns::catch are all legal."
(http://www.ecmascript.org/es4/spec/overview.pdf, p35)
if you accept ecma script ~= Javascript then it has already taken over. pretty much everything connected to web except embeded and even some of those runs javascript. with crossbrowser fixer libs and to lesser extent standards it is closer than anything else to write once run anywhere. more people have access to js dev tools than any other language. js is the new entry drug for new ddevs.
Yeah, I was reading that going "Scala, Scala, Scala, dynamic typing? #$(^(*@)#$" I'm pretty sure that the NBL will continue to be whatever large and influential organization wants it to be.
While I'm not sure Scala is the Language of the Future™, it's relevant to this discussion to point out that the method_missing hacks that make ruby's dynamic typing so attractive are being actively prototyped in Scala.
An example snippet: https://gist.github.com/783394
The implementation: http://lampsvn.epfl.ch/trac/scala/changeset/23993
An example snippet: https://gist.github.com/783394
The implementation: http://lampsvn.epfl.ch/trac/scala/changeset/23993
For what it's worth, and a bit OT, I find method_missing to be the least appealing part of Ruby's runtime dynamism. What _is_ helpful is to be able to add methods on the fly (e.g., through define_method); on the other hand, being able to handle arbitrary messages (which is what method_missing does) is occasionally interesting (as with Rails' dynamic finders) but generally considered bad form given that there are clearer and more performant alternatives.
I only mention the method_missing because most modern languages have fairly good answers to the "safely extend a type" problem, without succumbing to the problems that languages like Ruby suffer.
Scala would be a fucking awesome mainstream language.
And it actually has a chance of achieving that, unlike Haskell/Erlang/Ocaml/whatever, because Blub developers can just use it as a better Java.
I think you would see JRuby used as an industry de facto before you would see Scala.
Why?
Nobody talked about F# here but it's clearly the CLR Next Language, and reasonably f&(*ing awesome; i.e. combines the Next Languageness of clojure, jruby, and scala from the JVM world. Invitably, people will raise the same "broad and deep syntax" complaints they level against scala
Clojure much bigger then Scala and F#.
http://www.indeed.com/jobtrends?q=F%23%2Cclojure%2Cscala&...
http://www.indeed.com/jobtrends?q=F%23%2Cclojure%2Cscala&...
Holy shit,according to your chart it is even bigger than C and Java! How did this happen without anybody noticing?
http://www.indeed.com/jobtrends?q=F%23,clojure,scala,+C,+Jav...
But maybe this is just a result of comparing relative growth rates of job postings. If you take the time to a look at the percentage of matching job positions, then Scala is pretty dominant (compared to Clojure and F#) :D
http://www.indeed.com/jobtrends?q=F%23,clojure,scala,+C,+Jav...
But maybe this is just a result of comparing relative growth rates of job postings. If you take the time to a look at the percentage of matching job positions, then Scala is pretty dominant (compared to Clojure and F#) :D
For sure clojure's a nice language with a lot of great lib creators , and the community will continue to grow strongly
The (+), (+'), "=" and "==" thing has started to bother peeps
http://groups.google.com/group/clojure/browse_frm/thread/59a...
http://groups.google.com/group/clojure/browse_frm/thread/506...
http://clojure-log.n01se.net/date/2011-01-25.html#09:58a
The (+), (+'), "=" and "==" thing has started to bother peeps
http://groups.google.com/group/clojure/browse_frm/thread/59a...
http://groups.google.com/group/clojure/browse_frm/thread/506...
http://clojure-log.n01se.net/date/2011-01-25.html#09:58a
I've looked at it and thought it looked like a very clean and (for a functional language) quite readable. But the ties to MS's VM dooms it IMO. If they made it cross platform (JVM and / or native compilation) and put it in third party hands, then it might stand a chance.
BUT, I can't see Joe Public programmer adopting a functional language, even one as nice as F#
BUT, I can't see Joe Public programmer adopting a functional language, even one as nice as F#
I'm surprised no one here has mentioned the Cobra language (http://cobra-language.com/). It's basically identical Python syntax that wraps C# and has almost all the features Steve pointed out. It works on Linux, Windows, and Mac OS X using Mono (.NET environment emulation for various platforms).
Similar to JVM languages, it can import C# libraries directly and allows you to effortlessly use all that's gravy about C# but in a much more Pythonic manner. It has static and dynamic binding, which you can turn on and off, and since it's on Mono, does not have a GIL.
I think it's definitely a language to consider in the future. It certainly has potential to become the NBL.
Similar to JVM languages, it can import C# libraries directly and allows you to effortlessly use all that's gravy about C# but in a much more Pythonic manner. It has static and dynamic binding, which you can turn on and off, and since it's on Mono, does not have a GIL.
I think it's definitely a language to consider in the future. It certainly has potential to become the NBL.
I didn't realize how old this was, which tells you something about how prescient Yegge's writing can be. I would have added "pattern matching", though. At a minimum, keyword arguments or syntactic sugar for them.
He mentions "Perl 5 compatible regular expression literals" under "kitchen sink"
Pretty sure the GP is referring to pattern matching as it exists in ML or Scala. Or, somewhat less elegantly (given the constraints of the language) something like what https://github.com/jfd/match-js does.
Yup. IIRC the R language includes really cool features of both pattern matching and keyword arguments in its function signatures.
Sounds a lot like Mirah http://en.wikipedia.org/wiki/Mirah_(programming_language)
Honestly i don't know, nor does it matter. The language doesn't matter until the kill app gets built with it. Once that happens switch, i switched to Ruby in July 2004, because Rails was released.
Honestly i don't know, nor does it matter. The language doesn't matter until the kill app gets built with it. Once that happens switch, i switched to Ruby in July 2004, because Rails was released.
>>"If you want to spare yourself a lot of angst in deciding which programming language to use, then I recommend this simple rule: Go ugly early. C++ will go out with you in a heartbeat."
What's Perl to do, then?
What's Perl to do, then?
Perl was beautiful once, but could never raise the funds to keep up with the numerous plastic surgeries required to maintain her grotesque attractiveness. Over time, the suitors who weren't afraid of change just got bored, and while there are still a few people who believe Perl's renaissance is just around the corner, the rest of us just hope she can afford a nice condo in Florida to take it easy in her old age.
What Perl has always done: allow novices to program effectively without forcing undue ceremony while enabling adepts to write great programs in the fashion they deem most appropriate.
Seems odd to me to criticize a language for allowing people who haven't learned it to get things done, but there you go.
Seems odd to me to criticize a language for allowing people who haven't learned it to get things done, but there you go.
The NBL is not going to be Javascript but Lua. It's got some of the same architectural strengths as Javascript (functions are first class citizens, closures, good scoping), it's very fast (LuaJIT), integrates well in any environment and is highly customizable. See http://stackoverflow.com/questions/1022560/subtle-difference... for some differences....
but LUA does not have any STATIC features.
This is really essential for writing large
apps.
I seem to recall an interview he gave in which he stated that NBL was Javascript 2.
I think this is the interview you're looking for:
http://almaer.com/blog/my-interview-with-steve-yegge-on-rhin...
As an aside, RingoJS (successor to Helma) is a nice server-side Rhino JavaScript framework.
As an aside, RingoJS (successor to Helma) is a nice server-side Rhino JavaScript framework.
Really an interesting article. One thing I don't agree with: ""one of the biggest reasons people haven't adopted Ruby or Python is the lack of IDE support""
I use PyCharm and RubyMine a lot and they do a very good job of dealing with two dynamic languages. They are commercial products but fairly inexpensive.
Also, disappointing that the NBL will not have a Lisp-like syntax :-)
EDIT: I didn't notice this was a 4 year old article
I use PyCharm and RubyMine a lot and they do a very good job of dealing with two dynamic languages. They are commercial products but fairly inexpensive.
Also, disappointing that the NBL will not have a Lisp-like syntax :-)
EDIT: I didn't notice this was a 4 year old article
What is Steve Yegge doing nowadays? Is he still at Google?
This is a recent talk by him about scalable programming language analysis. And yes, he's still at google.
http://vimeo.com/16069687
http://vimeo.com/16069687
My thoughts exactly. Where's Steve? I love reading his stuff and am interested in how he's been changing the world (or not).
This is exactly why I killed my own PL. My language was amazing for the class of problems I was solving until a new problem came in and I had to solve it down in the lower tier like a dog with my tail between my legs.
I wish I'd seen this four years ago. I'd have written a language called "NBL".
[deleted]
> You won't be deported to Columbia
You certainly wouldn't want that to happen - I hear they still program in Pearl there.
You certainly wouldn't want that to happen - I hear they still program in Pearl there.
The submitter clearly pasted the correct URL and got a link to the original submission (1311 days ago) but went ahead and added "?" to the end of the url to fool the dup filter and submitted again. It is not even a case of two different urls to the same dynamically generated page!
I don't want to rush to accusation of karma whoring because maybe there is a value in reposting old article that some people might have not seen ... But something feels sub-optimal!
Maybe an automatic "best of this week in HN" page that shows the highest rated stories from a few years back that people can casually check for older interesting articles?