Ah, thanks for the link to that part of the CoffeeScript docs. I hadn't see the class syntax before and it does look quite nice. Also, I agree with many of your points about abstraction. I think I am being more practical about my comparisons rather than thinking at that level.
Something I do quite like about JS and something that Douglas Crockford has talked about is the need for abstraction of threads/ processes and multi-core programming. I believe he quite likes JS and Node for the event-loop and non-blocking I/O with JS providing a fine mechanism for callbacks. Syntax wise I think you do not gain much from JS over already established languages (python, ruby) except for maybe the security benefits of closures... but I think there is much more innovation ahead in abstracting multi-core programming and JS fits quite nicely in that space. On Feb 5, 2:10 pm, "Dmitry A. Soshnikov" <[email protected]> wrote: > On 05.02.2011 21:28, mcot wrote: > > > > > > > > > > > > > On Feb 5, 6:33 am, "Dmitry A. Soshnikov"<[email protected]> > > wrote: > >> On 05.02.2011 13:29, mcot wrote: > >> The thing is, if a new programmer is involved into our profession on > >> some _exact level of abstraction_, he has complete rights not even > >> _think_ about in abstractions of _previous level_. > > >> For example, CoffeeScript. It's a new language. The fact that it's > >> compiled into JS is just a concrete case. With the same success it could > >> be written e.g. in C. Or even in Assembler. Does it mean that you should > >> learn Assembler first, before programming in Coffee? Of course not. > > >> I.e. the programmer which attached into the programming on Coffee's > >> level of abstraction (and its syntactic rules and sugar) may learn > >> already only by docs of this level. > > I kind of think that is a bad argument. Sure you can come into > > programming and know one language and get quite a lot done just > > thinking in that language. I've never really programed in assembly > > but I've studied it and understand its concepts and by doing that it's > > helped me see things differently in higher level languages. Just > > because you are provided with nice features in a language does not > > mean you should be totally blind about how things really work. > > Right. And I didn't say you shouldn't learning something if you have the > interest. It's great that a programmer understands the full cycle of a > program interpretation/compilation and how it works on lower level > (including an architecture of a concrete machine). But actually, it's a > normal course in every computer science related university. > > What I said is that if you program (on practical applicable level) in > some language, and the _techniques_ and the _abilities_ of the language > are _good enough_ for your current level of complexity -- you may easily > use just it. When they will be not enough -- you go either into higher > abstraction or vice-versa -- to lower (e.g. programming some controllers > or drivers on lower languages, such as Asm). > > > Python and Rub both have a very clear syntax that is easy to follow > > and allows for sufficient modularity. Case in point: > > > class Student(Person):<-- Here I know the Student and Person > > relationship and I know the code for this class will follow in a > > single block. > > As I said, Python's classes are just a syntactic sugar of the > prototype-based system used in ECMAScript. If for your task it's > convenient to program with classes (that is, you have found a technique > which helps to beat your "complexity" easier) -- yes, you may either use > Python, or to write a sugar wrapper in JS (actually JS has classes as > "constructor + prototype" pair). > > > JavaScript does not have this level of clarity. I have to do a > > significant amount of work just to figure out what an objects > > capabilities are. Also the code could be scattered all around and it > > is not contained within a single block. > > This is exactly the case of this or that abstraction (level). In this > particular case (to classify objects), you need some more abstracted > (syntactically) system with classes. You may take JS and write another > language with classes (e.g. Coffee). Or you may just write a > class-library which also will manage your case. > > > Coffeescript does nothing for > > me here. > > How that? Coffee provides _complete_ first-class dynamic classes. The > same as in Python. If > interested:http://jashkenas.github.com/coffee-script/#classesWhat is wrong > there? > What big is difference from Python's classes do you see there? > > > JS is a step backwards in terms of having a platform to > > create large programs with well structured, easy to read and > > modularized code. It is tolerated in browsers because its all you > > get. > > > Building languages on top of JS may be a popular thing in the future > > who knows? I think it has minimal syntax and the JIT compilers are > > quite fast. That makes it similar to C in the same way the JVM and > > CLI are similar to C... (not very). > > Yeah, I think the same. And actually the title of the article is just > reflects the fact that JS can be used (and we all know that and saw) for > writing other languages. But -- actually the same can be said about > every other language. > > Anyway, and JS and C are highly-abstracted languages with powerful > constructions (especially e.g. C++0x which has many/all modern > abstractions), so the phrase of the article "JS is the next C" doesn't > mean that JS or C are gone (or something). I see what was the main > reason -- the author just saw that JS is used for writing other > languages (just like JS was written in C). But it's a normal practice as > I said for every language. > > Moreover, if the language can be used for writing/implementing another > language, it doesn't mean that the former is required to be > lower-abstracted and old. Recently I wrote e.g. toy Scheme interpreter > on CoffeeScript. Does it mean that Coffee is less abstracted than > Scheme? Of course not. > > So, I wouldn't worry about the article (as about something disturbing). > Repeat, the main reason as I see -- the author just saw that JS is used > as a "building material". But -- it relates to every language. The > reasons of building the new language -- that what is essential. And > usually the main reason -- is to achieve more and more convenient > technique to control the needed level of complexity. > > Dmitry. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
