It's obvious the written word and the spoken word are stored separately in the brain. I remember once following a sign at a zoo which said "Hippo ---> ", and when we got there someone said "Wow, look at dat potamus!"
1,814 karma · joined December 1, 2009
It's obvious the written word and the spoken word are stored separately in the brain. I remember once following a sign at a zoo which said "Hippo ---> ", and when we got there someone said "Wow, look at dat potamus!"
4 is a more common grouping than either 3 or 6. All of China and Japan and many places in between group their digits in fours.
And I always group the digits of hexadecimal numbers in fours.
Many of those numbers are fake. Groovy was #70 on the Tiobe index only 12 months ago, see [1], but is #16 now. How do you explain that? Groovy was last in Tiobe's top 20 about 2 years ago when the search numbers for "Groovy" from Baidu were hugely incorrect. Groovy later quickly dropped back out of the top 50.
Apache Groovy has inherited all of the syntax of Java. When Jeremy Rayner built the Antlr 2 based syntax for Groovy back in 2005, he began with the syntax for Java, then added the Groovy-specific grammar to it. The latest version of Groovy still uses that syntax, so if Java has syntactic baggage, then Groovy has it too.
I'm picking Groovy will still have that baggage-laden syntax for a while yet. 2 yrs ago, Daniel Sun built an Antlr 4 based replacement grammar, but the Groovy project managers at Apache are taking their sweet time in rolling it along. They even had its optional preview removed from the version 2.6 beta of Groovy.
Are these new uses of Apache Groovy really what we would call "using" a programming language?
Although many "use" Groovy in Gradle, it's mainly 20-liners without any procedural code, so really only the parsing functionality is being used. Jenkins goes further by transforming the AST after parsing to such an extent that none of the collections-based functions work, and the runtime behavior isn't really Groovy at all. The adoption of Groovy in these uses is so dependent on the nitty gritty behavior of its Antlr 2.x -based parser that the Apache Groovy PMC seem to be stalling on moving along the upgrade to Antlr 4 in Groovy 3, keeping it in alpha mode for as long as possible, and even removing the optional Antlr 4 preview feature from the Groovy 2.6 beta.
Most other uses of Groovy out there use it like "Bash for the JVM". For building actual systems, sites use Java (with lambdas), Kotlin or Scala rather than the static typing that was bolted on for Groovy 2. Even dynamically typed uses of Groovy are losing momentum, evidenced by how few Grails 2 websites and plugins have been upgraded to Grails 3, and how few new websites have been built in Grails 3. The official download numbers for Groovy are grossly manipulated, and Tiobe's ranking for Groovy has been gamed in the past by faulty search numbers, e.g. 2 yrs ago it was Baidu giving bad results.
I suggest your view of Groovy's momentum might be skewed by what you see immediately around you, and not by overall worldwide trends.
If you also count the Unihan variations registered in Unicode's ideographic variation database by various Japanese outfits, encoded using the VS16 to VS255 characters after the codepoint they modify, there's another 8k or 9k unique characters assigned.
You can insert stuff between "is" and "to-see" (and between "to" and "see", I hope you agree) because English mostly parses into left-branching trees, which is the only reason why you can't insert stuff between "see" and "-ing". Natural languages don't liberally mix left-branching structures and right-branching ones because they're hard for people to understand. E.g. Pinker's "The rapidity that the motion that the wing that the hummingbird has has has is remarkable" is grammatically correct but not easily understandable. The contiguity or lack of it operates on a different conceptual plane to whether a "word" can be inflected or not.
> loose analogy
To take some example language from your reply, some people speak this as two words, others (e.g. some Americans) as a compound word. Because the concept of a word is not well defined, the boundary between morphology and syntax is blurred. Putting "is" and "to" noncontiguously before a verb is the same as putting "-ed" after a verb. They are both "inflections".
Here you're defining syntax around your orthographic definition of what a word is.
> "Is he really, in your opinion, to see her tomorrow?"
The opinion words "really" and "in your opinion" added into that syntactic structure parallel the manner that opinion word "bloody" is added into a lexical structure to become "abso-bloody-lutely".
English has no inflected future tense because of the way words are usually defined. Verbs in English only have 4 types of inflections because words are defined as whatever is surrounded by spaces in writing. If we define words as the unit that carries a single beat in speaking, so "He is-to-see-it tomorrow" is 3 words, then verbs also have prefixed inflections. English then does have an inflected future tense.
The "is to" future form isn't mentioned in discussions on future tense very often but seems to have the most predetermination, whereas "is going to" and "will" indicate more volition by the doer.
Only trademarks registered with various legal jurisdictions are enforceable, such as the "Apache TinkerPop Gremlin" name you registered. Unregistered marks used by an Apache project are simply claims on the mark, which in many cases are not enforceable. One example is the Apache Groovy project, where its PMC members erroneously claim the exclusive use of "Groovy" for their programming language, when in fact their only valid claim is to "Apache Groovy" (and its previous monikers "org.codehaus.groovy" and "Codehaus Groovy").
type Users struct{
dict map[string]*User
list []*User
}
and attach methods to both access the data and coordinatedly update both forms, e.g. func (us *Users) byID(id string) *User { ... }
func (us *Users) sortedByID() []*User { ... }
func (us *Users) addUser(id string, nu *User) {
dict[id] = nu
list = append(list, nu)
...
}I started high school a few months after the last time anyone walked on the moon. If you'd told me then that no-one would ever again walk on the moon in the following fifty years, I'd have told you you were nuts. The general mood in the 1970's was that humankind would start to inhabit space over the following decades, and space colonies like these would be orbiting the Earth. Instead, the only humans publicly known to be in space right now are the 3 aboard the International Space Station.
Even when the language you speak doesn't have this requirement, you can still pick up this skill. When you live for a few years in a cold square-grid city like those of northern China, you learn to always know which way is north so you don't lose direction walking around connector overpasses and subway tunnels in the winter.
This causes the program to run in dynamically-typed mode, much sloooower, so why do it? You'd have to add @Static annotations everywhere to get anything approaching Java-like speeds. One of the Apache Groovy project managers has long since wanted to make Groovy statically compiled by default, but that's never going to happen because they're running an unofficial go-as-slow-as-possible in the official upcoming upgrade to Groovy 3.