The Artima Developer Community
Sponsored Link

Weblogs Forum
JavaScript Redux (and Closures)

29 replies on 2 pages. Most recent reply: Jul 15, 2011 4:12 PM by Bruce Eckel

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 29 replies on 2 pages [ « | 1 2 ]
Sok Ann Yap

Posts: 1
Nickname: sayap
Registered: Jul, 2011

Re: JavaScript Redux (and Closures) Posted: Jul 18, 2011 9:00 PM
Reply to this message Reply
Advertisement
It is too harsh to call JavaScript an abomination. I would call it the ManBearPig of programming language:

- "appear to be an ordinary procedural language" (half man)
- "has more in common with functional languages like Lisp or Scheme than with C or Java" (half bear)
- "is now a complete object-oriented programming language" (half pig)

Quotes stolen from http://www.crockford.com/javascript/javascript.html

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: JavaScript Redux (and Closures) Posted: Jul 19, 2011 5:32 AM
Reply to this message Reply
> My two cents regarding "bad" languages:
> I've written lots of code in more languages than I care to
> remember and over more years than I care to admit, and
> have to say that I never understood the bashing of any
> language. It's not that I'm oblivious to a specific
> language's faults- its just that they are never relevant.
> If I choose to implement something in a specific language
> (including JavaScript), it is because it is the best tool
> for the specific job I wish to perform. It doesn't mean it
> has no faults. What it does mean is that I just need
> adjust my programming to avoid those faults and to
> leverage the good parts. In time, as the language evolves,
> the good parts overweigh the bad anyway.
>
> Hopeless optimist here... :-)

In each team I worked so far there was one colleague who showed an almost perfect equanimity towards tools. He was content with what his team leader has given to him and if the tools changed he was content with them as well. The "right tool for the job" was the tool the team was using.

I wonder if most of us would accept that those people have sound instincts. We are permanently producing our individuality, our tastes and strong opinions and intellectual differences and progress as if this was a good odor and find those irritating that see no good reason or even madness in all of this. They don't even actively liberate themselves from those opinions as if this was a spiritual exercise. They just don't get affected by them.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: JavaScript Redux (and Closures) Posted: Jul 19, 2011 7:12 AM
Reply to this message Reply
> Well, in my experience, the language chosen is most often
> the result of FOTM considerations of The Suits. If "best
> tool" were the criteria, far more SQL would be used. As
> it is, client code (in various source) is used far more
> than is warranted.

I've yet to come across a case where the language or tools were chosen by "The Suits" (whoever they are). In reality, unless the project is a long term one, they are usually chosen by the software developers on the basis of whatever's fashionable at the time. I agree with you about SQL. Too many programmers know a lot less SQL than they think they do.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: JavaScript Redux (and Closures) Posted: Jul 19, 2011 3:49 PM
Reply to this message Reply
> I agree with you
> about SQL. Too many programmers know a lot less SQL than
> they think they do.

Sorry, Artima, but I couldn't resist:


reserved_word :
ADD
| ALL
| ALLOCATE
| ALTER
| AND
| ANY
| ARE
| ARRAY
| AS
| ASENSITIVE
| ASYMMETRIC
| AT
| ATOMIC
| AUTHORIZATION
| BEGIN
| BETWEEN
| BIGINT
| BINARY
| BLOB
| BOOLEAN
| BOTH
| BY
| CALL
| CALLED
| CASCADED
| CASE
| CAST
| CHAR
| CHARACTER
| CHECK
| CLOB
| CLOSE
| COLLATE
| COLUMN
| COMMIT
| CONNECTION
| CONNECT
| CONSTRAINT
| CONSTRUCTOR
| CONTINUE
| CORRESPONDING
| CREATE
| CROSS
| CUBE
| CURRENT
| CURRENT_DATE
| CURRENT_DEFAULT_TRANSFORM_GROUP
| CURRENT_PATH
| CURRENT_ROLE
| CURRENT_TIME
| CURRENT_TIMESTAMP
| CURRENT_TRANSFORM_GROUP_FOR_TYPE
| CURRENT_USER
| CURSOR
| CYCLE
| DATE
| DAY
| DEALLOCATE
| DEC
| DECIMAL
| DECLARE
| DEFAULT
| DELETE
| DEREF
| DESCRIBE
| DETERMINISTIC
| DISCONNECT
| DISTINCT
| DOUBLE
| DROP
| DYNAMIC
| EACH
| ELEMENT
| ELSE
| END
| END_EXEC
| ESCAPE
| EXCEPT
| EXEC
| EXECUTE
| EXISTS
| EXIT
| EXTERNAL
| FALSE
| FETCH
| FILTER
| FOR
| FOREIGN
| FREE
| FROM
| FULL
| FUNCTION
| GENERATED
| GET
| GLOBAL
| GRANT
| GROUP
| GROUPING
| HAVING
| HOLD
| HOUR
| IDENTITY
| IMMEDIATE
| IN
| INDICATOR
| INNER
| INOUT
| INPUT
| INSENSITIVE
| INSERT
| INT
| INTEGER
| INTERSECT
| INTERVAL
| INTO
| IS
| ISOLATION
| JOIN
| LANGUAGE
| LARGE
| LATERAL
| LEADING
| LEFT
| LIKE
| LOCAL
| LOCALTIME
| LOCALTIMESTAMP
| MATCH
| MEMBER
| MERGE
| METHOD
| MINUTE
| MODIFIES
| MODULE
| MONTH
| MULTISET
| NATIONAL
| NATURAL
| NCHAR
| NCLOB
| NEW
| NO
| NONE
| NOTFOUND
| NOT
| NULL
| NUMERIC
| OF
| OLD
| ON
| ONLY
| OPEN
| OR
| ORDER
| OUT
| OUTER
| OUTPUT
| OVER
| OVERLAPS
| PARAMETER
| PARTITION
| PRECISION
| PREPARE
| PRIMARY
| PROCEDURE
| RANGE
| READS
| REAL
| RECURSIVE
| REF
| REFERENCES
| REFERENCING
| RELEASE
| RETURN
| RETURNS
| REVOKE
| RIGHT
| ROLLBACK
| ROLLUP
| ROW
| ROWS
| SAVEPOINT
| SCOPE
| SCROLL
| SEARCH
| SECOND
| SELECT
| SENSITIVE
| SESSION_USER
| SET
| SIMILAR
| SMALLINT
| SOME
| SPECIFIC
| SPECIFICTYPE
| SQL
| SQLEXCEPTION
| SQLSTATE
| SQLWARNING
| START
| STATIC
| SUBMULTISET
| SYMMETRIC
| SYSTEM
| SYSTEM_USER
| TABLE
| THEN
| TIME
| TIMESTAMP
| TIMEZONE_HOUR
| TIMEZONE_MINUTE
| TO
| TRAILING
| TRANSLATION
| TREAT
| TRIGGER
| TRUE
| UNDO
| UNION
| UNIQUE
| UNKNOWN
| UNNEST
| UPDATE
| USER
| USING
| VALUE
| VALUES
| VARCHAR
| VARYING
| WHEN
| WHENEVER
| WHERE
| WINDOW
| WITH
| WITHIN
| WITHOUT
| YEAR
;
*/

non_reserved_word :
ABS
| ABSOLUTE
| ACTION
| ADA
| ADMIN
| AFTER
| ALWAYS
| ASC
| ASSERTION
| ASSIGNMENT
| ATTRIBUTE
| ATTRIBUTES
| AUTO
| AVG
| BEFORE
| BERNOULLI
| BIN
| BREADTH
| CARDINALITY
| CASCADE
| CATALOG
| CATALOG_NAME
| CEIL
| CEILING
| CHAIN
| CHARACTERISTICS
| CHARACTERS
| CHARACTER_LENGTH
| CHARACTER_SET_CATALOG
| CHARACTER_SET_NAME
| CHARACTER_SET_SCHEMA
| CHAR_LENGTH
| CHAR
| CHECKED
| CLASS_ORIGIN
| COALESCE
| COBOL
| CODE_UNITS
| COLLATION
| COLLATION_CATALOG
| COLLATION_NAME
| COLLATION_SCHEMA
| COLLECT
| COLUMN_NAME
| COMMAND_FUNCTION
| COMMAND_FUNCTION_CODE
| COMMITTED
| CONDITION
| CONDITION_NUMBER
| CONNECTION_NAME
| CONSTRAINTS
| CONSTRAINT_CATALOG
| CONSTRAINT_NAME
| CONSTRAINT_SCHEMA
| CONSTRUCTORS
| CONST
| CONTAINS
| CONVERT
| CORR
| COUNT
| COVAR_POP
| COVAR_SAMP
| CUME_DIST
| CURRENT_COLLATION
| CURSOR_NAME
| DATA
| DATETIME_INTERVAL_CODE
| DATETIME_INTERVAL_PRECISION
| DCL
| DEFAULTS
| DEFERRABLE
| DEFERRED
| DEFINED
| DEFINER
| DEGREE
| DENSE_RANK
| DEPTH
| DERIVED
| DESC
| DESCRIPTOR
| DIAGNOSTICS
| DISPATCH
| DISPLAY
| DOMAIN
| DOUBLE_PRECISION
| DYNAMIC_FUNCTION
| DYNAMIC_FUNCTION_CODE
| EQUALS
| EVERY
| EXCEPTION
| EXCLUDE
| EXCLUDING
| EXP
| EXTERN
| EXTRACT
| FINAL
| FIRST
| FIXED
| FLOAT
| FLOOR
| FOLLOWING
| FORTRAN
| FOUND
| FUSION
| GENERAL
| GO
| GOTO
| GRANTED
| HIERARCHY
| IMPLEMENTATION
| INCLUDING
| INCREMENT
| INDICATOR_TYPE
| INITIALLY
| INSTANCE
| INSTANTIABLE
| INTERFACES
| INTERSECTION
| INVOKER
| ISOLATION
| KEY
| KEY_MEMBER
| KEY_TYPE
| KIND
| LAST
| LENGTH
| LEN
| LEVEL
| LN
| LOGICAL
| LOCATOR
| LONG
| LOWER
| MAP
| MATCHED
| MAX
| MAXVALUE
| MESSAGE_LENGTH
| MESSAGE_OCTET_LENGTH
| MESSAGE_TEXT
| MIN
| MINVALUE
| MOD
| MORE
| MUMPS
| NAME
| NAMES
| NESTING
| NEXT
| NORMALIZE
| NORMALIZED
| NULLABLE
| NULLIF
| NULLS
| NUMBER
| OBJECT
| OCTETS
| OCTET_LENGTH
| OPTION
| OPTIONS
| ORDERING
| ORDINALITY
| OTHERS
| OVERLAY
| OVERRIDING
| PAD
| PACKED
| PARAMETER_MODE
| PARAMETER_NAME
| PARAMETER_ORDINAL_POSITION
| PARAMETER_SPECIFIC_CATALOG
| PARAMETER_SPECIFIC_NAME
| PARAMETER_SPECIFIC_SCHEMA
| PARTIAL
| PASCAL
| PATH
| PERCENTILE_CONT
| PERCENTILE_DISC
| PERCENT_RANK
| PICTURE
| PIC
| PLACING
| PLI
| POSITION
| POWER
| PRECEDING
| PRESERVE
| PRIOR
| PRIVILEGES
| PUBLIC
| RANK
| READ
| REGR_AVGX
| REGR_AVGY
| REGR_COUNT
| REGR_INTERCEPT
| REGR_R2
| REGR_SLOPE
| REGR_SXX
| REGR_SXY
| REGR_SYY
| RELATIVE
| REPEATABLE
| RESTART
| RESTRICT
| RESULT
| RETURNED_CARDINALITY
| RETURNED_LENGTH
| RETURNED_OCTET_LENGTH
| RETURNED_SQLSTATE
| ROLE
| ROUTINE
| ROUTINE_CATALOG
| ROUTINE_NAME
| ROUTINE_SCHEMA
| ROW_COUNT
| ROW_NUMBER
| SCALE
| SCHEMA
| SCHEMA_NAME
| SCOPE_CATALOG
| SCOPE_NAME
| SCOPE_SCHEMA
| SECTION
| SECURITY
| SELF
| SEPARATE
| SEQUENCE
| SERIALIZABLE
| SERVER_NAME
| SESSION
| SETS
| SHORT
| SIGNED
| SIGN
| SIMPLE
| SIZE
| SOURCE
| SPACE
| SPECIFIC_NAME
| SQLSTATE_TYPE
| SQRT
| STATE
| STATEMENT
| STDDEV_POP
| STDDEV_SAMP
| STRUCTURE
| STYLE
| SUBCLASS_ORIGIN
| SUBSTRING
| SUM
| TABLESAMPLE
| TABLE_NAME
| TEMPORARY
| TIES
| TOP_LEVEL_COUNT
| TRANSACTION
| TRANSACTIONS_COMMITTED
| TRANSACTIONS_ROLLED_BACK
| TRANSACTION_ACTIVE
| TRANSFORM
| TRANSFORMS
| TRANSLATE
| TRIGGER_CATALOG
| TRIGGER_NAME
| TRIGGER_SCHEMA
| TRIM
| TYPE
| UNBOUNDED
| UNCOMMITTED
| UNDER
| UNNAMED
| UNSIGNED
| UPPER
| USAGE
| USER_DEFINED_TYPE_CATALOG
| USER_DEFINED_TYPE_CODE
| USER_DEFINED_TYPE_NAME
| USER_DEFINED_TYPE_SCHEMA
| VAR_POP
| VAR_SAMP
| VIEW
| VOLATILE
| WIDTH_BUCKET
| WORK
| WRITE
| ZONE
;


A small lexical syntax excerpt from an ANTLR implementation of the SQL 2003 grammar. I was surprised it was bigger even than that of C++, probably because I also only ever dealt with tiny subset covered by most introductory texts.

Maksim Lin

Posts: 1
Nickname: maks11
Registered: Jul, 2011

Re: JavaScript Redux (and Closures) Posted: Jul 19, 2011 8:04 PM
Reply to this message Reply
Bruce your TIJ was the seminal Java programming book for me for many years and I highly recommended it to everyone who asked me about learning Java.

So it makes me very sad to read such informed tripe in this post. At first I thought you must be having a laugh, but your follow-up comments seem to indicate you're actually serious.

Others have already pointed out how inaccurate most of your arguments against JS are rather than of being directed at the DOM, poor browser implementations (older IE's) and a general wild rant against Web dev technologies in general.

I mainly want to point out how you seem to have an implied agenda that vendor controlled technologies are somehow superior to the open standards that make up the current web triumberate (html/css/js) is also complete rubbish and constant comparison to Flash (I guess you mean AS3 lang) as some kind of worthy alternative to ES3 (now ES5 in all "modern" browsers) is just plain bizarre.

I think your references to Crockfords supposed dislike of JS are also off the mark, heres just one ercent quote from him:

"There are certainly a lot of people who refuse to consider the possibility that JavaScript got anything right. I used to be one of those guys. But now I continue to be amazed by the brilliance that is in there"
(http://t.co/bawSe7f)

I also find strange your criticism of using AJAX libraries (sic) as using another language. I assume you are referring to libraries such as the widely used jQuery. But from what I've read of opinion pieces out of the Ruby community, DSLs are supposed to be a highly valued design pattern. In fact quote *you*:

"Although Domain-Specific Languages (DSLs) have gotten a lot of press lately, creating little languages to solve specific problems has always been one of the more powerful weapons in a programmer's toolbox"
(http://www.artima.com/forums/flat.jsp?forum=106&thread=214112)

If you want to critique JS as a language rather than specific browser implementations of it, try using server-side frameworks like RingoJS or NodeJS. That might give you a bt more perspective and education on the wider world of JS. For instance they both implement the CommonJS "require()" sepc which has essentially provided a solution to the global namespace issue that you and many other JS detractors seem to focus on. NodeJS is particular interesting in its transfer of the browsers async programming model into the server-side space, though its hardly a new idea (python, ruby async servers have been around for a while) JS seems to be much better suited to this than those languages.

That article that you wrote critiquing python 3 (back in 2009) that I quoted you from is a far, far better and reasoned piece. I assume that it stemmed from a fair bit of use and study of Python by yourself. I would hope that you give JS and (html/css) for that matter the same respect and courtesy of use and learning before you take it upon yourself to write another critique for their short comings.

Marc Wensauer

Posts: 1
Nickname: daslicht
Registered: Jul, 2011

Re: JavaScript Redux (and Closures) Posted: Jul 21, 2011 5:12 AM
Reply to this message Reply
>But the virtual machine would allow the addition of many >other options -- initially, as downloads but eventually as >standard browser distributions.

Funny, its already available today ! Its called AVM :)
The AVM should just be included in all browsers by default,, issue *solve*

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: JavaScript Redux (and Closures) Posted: Jul 21, 2011 10:47 PM
Reply to this message Reply
> I've yet to come across a case where the language or tools
> were chosen by "The Suits" (whoever they are). In
> reality, unless the project is a long term one, they are
> usually chosen by the software developers on the basis of
> whatever's fashionable at the time. I agree with you
> about SQL. Too many programmers know a lot less SQL than
> they think they do.

I just got back from an interview. RoR is the chosen platform. The Suits are much enamored of it. The devs I talked to weren't all that keen, for obvious reasons. But RoR it is.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: JavaScript Redux (and Closures) Posted: Jul 22, 2011 3:54 AM
Reply to this message Reply
That's excellent. With that list you have actually increased the ammount of ignorance that I have of SQL.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: JavaScript Redux (and Closures) Posted: Jul 25, 2011 9:37 AM
Reply to this message Reply
> > I agree with you
> > about SQL. Too many programmers know a lot less SQL
> than
> > they think they do.
>
> Sorry, Artima, but I couldn't resist:
>
>

> reserved_word :
> ADD
...
>
> non_reserved_word :
> ABS
...
>

>
> A small lexical syntax excerpt from an ANTLR
> implementation of the SQL 2003 grammar. I was surprised it
> was bigger even than that of C++, probably because I also
> only ever dealt with tiny subset covered by most
> introductory texts.

IIRC, the syntax of "bare C" is 20 operators, nothing more. Which is why it used to be called (Meyer, in particular) The Portable Assembler. The rest comes from the libraries.

I gather that the reason for this msg. is that SQL is "bad" due to the high keyword count. Not the first time I've heard that more keywords === more bugs. So I went looking.

Found this:
Halstead Metric gives birth to a bug prediction formula:
B = (N1 + N2) log(n1 + n2) / 3000

where:
N1 = actual number of operators
N2= actual number of operands
n1 = the number of distinct operators in the program (e.g. keywords).
n2 = the number of distinct operands in the program (e.g. data objects)

Here:
http://www.cs.technion.ac.il/Courses/OOP/slides/export/236804-Fall-1997/metrics/part1.html

Note: the N/n's are the numbers for a *particular* program, not the language. Thus, higher level languages should have fewer bugs, although more defined keywords. Is this not the motivation for DSLs?

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: JavaScript Redux (and Closures) Posted: Jul 26, 2011 3:34 AM
Reply to this message Reply
> I gather that the reason for this msg. is that SQL is
> "bad" due to the high keyword count. Not the first time
> I've heard that more keywords === more bugs.

I didn't get that impression at all. I thought Kay was demonstrating that there was a lot more to SQL than the SELECT statement. Other than what you wrote above, I didn't see anyone mention that SQL was bad or that it was buggy.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: JavaScript Redux (and Closures) Posted: Jul 27, 2011 10:24 AM
Reply to this message Reply
> > I gather that the reason for this msg. is that SQL is
> > "bad" due to the high keyword count. Not the first
> time
> > I've heard that more keywords === more bugs.
>
> I didn't get that impression at all. I thought Kay was
> demonstrating that there was a lot more to SQL than the
> SELECT statement. Other than what you wrote above, I
> didn't see anyone mention that SQL was bad or that it was
> buggy.

I leapt to the conclusion, given that C++ is widely condemned for its syntactic complexity, and was being mentioned along with SQL. But you're correct, the direct statement wasn't made.

Marko Loparic

Posts: 3
Nickname: markolopa
Registered: Jul, 2011

Re: JavaScript Redux (and Closures) Posted: Jul 31, 2011 5:38 AM
Reply to this message Reply
Besides CoffeeScript there is also pyjamas and gwt. I wonder what you think about them. In more generally I wonder if you agree that compilers are the best solution to this issue in the long term.

The rationale is simple. If our code has to run on something which is an abomination to write code with, the best think to do is to invent a new language and use a compiler.

This is precisely what was done in the sixties. Machine language was an abomination, but our code had to run on it. Isn't our today problem exactly the same?

I believe that compilers are a much better solution than virtual machines, since we have total freedom to do what we want without depending on corporations, committees, etc.

Creating a new language and compiling code written on it to javascript is what CoffeScript does if I understand correctly. IMO Pyjamas/Gwt do better than this, they reuse languages that already exist.

Marko

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: JavaScript Redux (and Closures) Posted: Aug 1, 2011 6:21 AM
Reply to this message Reply
> > we need a virtual machine for languages as part of
> > the foundation for all browsers.
>
> Brilliant idea. So how do you go about making that happen?

We can go further and eliminate the browser. We can replace it with a mechanism that downloads versioned software components when they are needed.

The mechanism could be embedded into executables.

The components would be locally cached in a central place in each computer.

When an executable is launched, the program tries to download a newer version of the main component. It then runs the main component.

The main component could be a virtual machine.

As the program runs, more components are either downloaded or loaded from the local cache, as they are used.

This mechanism will eliminate the need for a browser, it will offer all the advantages of the browser and none of its disadvantages.

Why Force Me To Sign Up

Posts: 1
Nickname: user
Registered: Sep, 2011

Re: JavaScript Redux (and Closures) Posted: Sep 9, 2011 10:33 AM
Reply to this message Reply
Bravo Tim!

What a load of tripe. "Javascript is different on different browsers" my foot. The DOM may have been many years ago, but to blame JS for it is frankly ridiculous.

Matej Cepl

Posts: 6
Nickname: mcepl
Registered: Jun, 2007

Re: JavaScript Redux (and Closures) Posted: Oct 20, 2011 12:55 PM
Reply to this message Reply
Bruce, I like you for your highly opinionated posts (even though you are sometimes wrong), but here I believe you were mislead on the wrong path by Mr. Crockford. Although he is mostly right in his particular opinions, his "Good parts" made in my opinion more harm than good. All those people who don't understand Javascript and who are prepared to hate it, read it just as an evidence for their disgust.

If we are into reading, then I would strongly suggest three articles by Mr. Crockford which are better for opening new (and positive) vistas on Javascript: http://javascript.crockford.com/javascript.html, http://javascript.crockford.com/prototypal.html, and (quite enlightening for me) http://javascript.crockford.com/little.html. In case of books, he suggests http://www.amazon.com/JavaScript-Definitive-Guide-Activate-Guides/dp/0596805527/ref=ntt_at_ep_dpt_1 (particularly 5th and 6th edition, which are very up-to-date). Mr. Flanagan's book is not head and shoulders about anything else written about Javascript, it is in my opinion class for itself. Highly recommended.

Flat View: This topic has 29 replies on 2 pages [ « | 1  2 ]
Topic: Big Python Previous Topic   Next Topic Topic: Fractal Duality and the Nature of the Universe


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us