The spelling and grammar rules do not apply on the millennials... That's because millennials have created a new rulebook for a variant of written English unique to social media. A rulebook which states that deliberately misspelled words and misused grammar can convey tone, nuance, humour, and even annoyance.

Dr Lauren Fonteyn, English Linguistics lecturer at University of Manchester, told "something exciting" is happening with the way that millennials write, and it goes far, far beyond our proclivity to use acronyms and "like."

Fonteyn says millennials are "breaking the constraints" of written English to "be as expressive as you can be in spoken language."

This new variant of written English strives to convey what body language, and tone and volume of voice can achieve in spoken English. Fonteyn says that on a superficial level, we can see millennials stripping anything unnecessary from their writing, like the removal of abbreviation markers in "dont," "cant," "im" and in acronyms like tf, ur, bc, idk, and lol. In a world where most of our conversations take place online, millennials are using a number of written devices to convey things that could typically only be communicated by cadence, volume, or even body language. One such device is "atypical capitalisation," according to Fonteyn, a break from a rule prescribed by standard spelling, which states that capitalisation is "reserved for proper nouns, people, countries, brands, the first person pronoun, and the first word in a new sentence."

"What we see in millennial spelling is different, but not unruly," says Fonteyn. "Capitals are not necessarily used for people (we know who ed sheeran is, it’s Ed Sheeran), or initial words of a text or tweet."

Dr Ruth Page, senior lecturer in Applied Linguistics at Birmingham University, says that frequently the "personal pronoun ('I') is in the lower case ('i')" which is sometimes used to "play down the person's sense of self." While we're abandoning capitals for things that typically always required them, we're using them to add emphasis or humour to written sentences.

"Capitals ARE used, however, to make words stand out," says Fonteyn. "By capitalising something that is not typically capitalised, you can add subtle emphasis, or irony or mockery." Full capitals are used to denote strong emphasis, or "volume of laughter in lol vs. LOL," says Fonteyn.

Millennials' use—or rather, misuse—of punctuation is where things really start to get creative. Page says research shows how "non-standard use of punctuation can reflect ‘tone of voice’ or what linguists would call ‘paralinguistic’ meaning." She says that an example of this is using a period (a.k.a. a full stop) at the end of a sentence to "indicate that you are cross."

According to Fonteyn, the absence of a full stop at the end of a sentence is "neutral," but the addition of one adds the "sense of being pissed off," or that you're "done talking."

A two-dot ellipsis (..), in millennial English means "continue," or "please elaborate." And, a three-dot ellipsis denotes an "awkward or annoyed silence," or "are you serious?"

Using the comma-ellipsis to write ‘ok,,’ or ‘you sure,,,’ can convey "insecurity or uneasiness," according to Fonteyn. While a three-dot ellipsis might be employed to convey intense annoyance, the comma-ellipsis indicates a "different type of intensity," of annoyance or unsureness.

An utter absence of punctuation is most often used as a way of expressing sheer unadulterated excitement. "A complete lack of punctuation iconically mimics the way someone speaks when they are crazy excited about something," says Fonteyn. "In that case, you are adding excitement by taking away commas and full stops, which indicate pauses."

Attempting to bush the bounds of what written language can do in order to better express ourselves and our feelings is the chief use for these devices.

But, Dr Peredur Webb-Davies, senior lecturer in Welsh Linguistics at Bangor University, says it also has something to do with feeling part of a community. Webb-Davies says that internet users can "project an identity for themselves which is represented by the way they type their language." Crucially, "users who write in similar ways using a ‘code’ that might be mostly only intelligible to those in the know, can do this to feel part of a wider community."

For millennials who conduct so many of their conversations online, this creativity with written English allows us to express things that we would have previously only been conveyed through volume, cadence, tone, or body language. But, Fonteyn thinks it "goes beyond that as well," with things like the trademark symbol.

"When TM is added to a phrase, it ADDS something you can’t do in a regular conversation," says Fonteyn. "I don’t think this originates in speech, because I don’t think anyone actually says "the point TM."

"This emphatic method might actually originate in digital language: they’re not just indicating prosody from spoken language but they are adding a visual joke to it, TM in Hyperscript," Fonteyn adds.

What we're witnessing is the nascent beginnings of informal written English becoming even more expressive than spoken English.

Perhaps we should add "IRL conversations" to The Official List of Things Millennials Destroyed. LOL.

The Cython language is a superset of Python that compiles to C, yielding performance boosts that can range from a few percent to several orders of magnitude, depending on the task at hand. For work that is bound by Python’s native object types, the speedups won’t be large. But for numerical operations, or any operations not involving Python’s own internals, the gains can be massive. This way, many of Python’s native limitations can be routed around or transcended entirely.

Python code can make calls directly into C modules. Those C modules can be either generic C libraries or libraries built specifically to work with Python. Cython generates the second kind of module: C libraries that talk to Python’s internals, and that can be bundled with existing Python code.

Cython code looks a lot like Python code, by design. If you feed the Cython compiler a Python program, it will accept it as-is, but none of Cython’s native accelerations will come into play. But if you decorate the Python code with type annotations in Cython’s special syntax, Cython will be able to substitute fast C equivalents for slow Python objects.

Note that Cython’s approach is incremental. That means a developer can begin with an existing Python application, and speed it up by making spot changes to the code, rather than rewriting the whole application from the ground up.

This approach dovetails with the nature of software performance issues generally. In most programs, the vast majority of CPU-intensive code is concentrated in a few hot spots—a version of the Pareto principle, also known as the “80/20” rule. Thus most of the code in a Python application doesn’t need to be performance-optimized, just a few critical pieces. You can incrementally translate those hot spots into Cython, and so get the performance gains you need where it matters most. The rest of the program can remain in Python for the convenience of the developers.

Consider the following code, taken from Cython’s documentation:

def f(x):
      return x**2-x

def integrate_f(a, b, N):
      s = 0
      dx = (b-a)/N
      for i in range(N):
           s += f(a+i*dx)
      return s * dx

Now consider the Cython version of the same code, with Cython’s additions bolded:

cdef double f(double x):
       return x**2-x

def integrate_f(double a, double b, int N):
      cdef int i
      cdef double s, x, dx
       s = 0
       dx = (b-a)/N
       for i in range(N):
            s += f(a+i*dx)
       return s * dx

If we explicitly declare the variable types, both for the function parameters and the variables used in the body of the function (double, int, etc.), Cython will translate all of this into C. We can also use the cdef keyword to define functions that are implemented primarily in C for additional speed, although those functions can only be called by other Cython functions and not by Python scripts.

Aside from being able to speed up the code you’ve already written, Cython grants several other advantages:

1. Python packages like NumPy wrap C libraries in Python interfaces to make them easy to work with. However, going back and forth between Python and C through those wrappers can slow things down. Cython lets you talk to the underlying libraries directly, without Python in the way. (C++ libraries are also supported.)

2. If you use Python objects, they’re memory-managed and garbage-collected the same as in regular Python. But if you want to create and manage your own C-level structures, and use malloc/free to work with them, you can do so. Just remember to clean up after yourself.

3. Cython automatically performs runtime checks for common problems that pop up in C, such as out-of-bounds access on an array, by way of decorators and compiler directives (e.g., @boundscheck(False)). Consequently, C code generated by Cython is much safer by default than hand-rolled C code. If you’re confident you won’t need those checks at runtime, you can disable them for additional speed gains, either across an entire module or only on select functions. Cython also allows you to natively access Python structures that use the “buffer protocol” for direct access to data stored in memory (without intermediate copying). Cython’s “memoryviews” let you work with those structures at high speed, and with the level of safety appropriate to the task.

4. Python’s Global Interpreter Lock, or GIL, synchronizes threads within the interpreter, protecting access to Python objects and managing contention for resources. But the GIL has been widely criticized as a stumbling block to a better-performing Python, especially on multicore systems. If you have a section of code that makes no references to Python objects and performs a long-running operation, you can mark it with the with nogil: directive to allow it to run without the GIL. This frees up the Python interpeter to do other things, and allows Cython code to make use of multiple cores (with additional work).

5. Python has a type-hinting syntax that is used mainly by linters and code checkers, rather than the CPython interpreter. Cython has its own custom syntax for code decorations, but with recent revisions of Cython you can use Python type-hinting syntax to provide type hints to Cython as well.

Keep in mind that Cython isn’t a magic wand. It doesn’t automatically turn every instance of poky Python code into sizzling-fast C code. Here are the following Cython limitations:

1. When Cython encounteres Python code it can’t translate completely into C, it transforms that code into a series of C calls to Python’s internals. This amounts to taking Python’s interpreter out of the execution loop, which gives code a modest 15 to 20 percent speedup by default. Note that this is a best-case scenario; in some situations, you might see no performance improvement, or even a performance degradation.

2. Python provides a slew of data structures—strings, lists, tuples, dictionaries, and so on. They’re hugely convenient for developers, and they come with their own automatic memory management. But they’re slower than pure C. Cython lets you continue to use all of the Python data structures, although without much speedup. This is, again, because Cython simply calls the C APIs in the Python runtime that create and manipulate those objects. Thus Python data structures behave much like Cython-optimized Python code generally: You sometimes get a boost, but only a little.

3. If you have a function in C labeled with the cdef keyword, with all of its variables and inline function calls to other things that are pure C, it will run as fast as C can go. But if that function references any Python-native code, like a Python data structure or a call to an internal Python API, that call will be a performance bottleneck. Fortunately, Cython provides a way to spot these bottlenecks: a source code report that shows at a glance which parts of your Cython app are pure C and which parts interact with Python. The better optimized the app, the less interaction there will be with Python.

Cython improves the use of C-based third-party number-crunching libraries like NumPy. Because Cython code compiles to C, it can interact with those libraries directly, and take Python’s bottlenecks out of the loop. But NumPy, in particular, works well with Cython. Cython has native support for specific constructions in NumPy and provides fast access to NumPy arrays. And the same familiar NumPy syntax you’d use in a conventional Python script can be used in Cython as-is. However, if you want to create the closest possible bindings between Cython and NumPy, you need to further decorate the code with Cython’s custom syntax. The cimport statement, for instance, allows Cython code to see C-level constructs in libraries at compile time for the fastest possible bindings. Since NumPy is so widely used, Cython supports NumPy “out of the box.” If you have NumPy installed, you can just state cimport numpy in your code, then add further decoration to use the exposed functions.

You get the best performance from any piece of code by profiling it and seeing firsthand where the bottlenecks are. Cython provides hooks for Python’s cProfile module, so you can use Python’s own profiling tools to see how your Cython code performs. No need to switch between toolsets; you can continue working in the Python world you know and love. It helps to remember in all cases that Cython isn’t magic—that sensible real-world performance practices still apply. The less you shuttle back and forth between Python and Cython, the faster your app will run. For instance, if you have a collection of objects you want to process in Cython, don’t iterate over it in Python and invoke a Cython function at each step. Pass the entire collection to your Cython module and iterate there. This technique is used often in libraries that manage data, so it’s a good model to emulate in your own code.

Bottom line is we use Python because it provides programmer convenience and enables fast development. Sometimes that programmer productivity comes at the cost of performance. With Cython, just a little extra effort can give you the best of both worlds.

If you'll try today find out by analyzing the hundreds of thousands of job postings that contained the name of a programming language on job search then you'll know that Java is the most in-demand followed by Python and JavaScript. This analysis is based on the number of job postings(on Indeed.com) for each language. Some languages, such as Swift and Ruby, didn’t make the top seven because they have lower job demand, even though developers love them. Here’s list, with languages named in order of demand:

No. 1: Java

Java decreased in popularity by about 6,000 job postings in 2018 compared to 2017, but is still extremely well-established. Java is over 20 years old, used by millions of developers and billions of devices worldwide, and able to run on any hardware and operating system through the Java Virtual Machine. All Android apps are based on Java and 90 percent of Fortune 500 companies use Java as a server-side language for backend development. Java Enterprise Edition 8 and Java 9 both launched in September 2017 as the Eclipse Foundation took over managing Java EE from Oracle.

No. 2: Python

Python grew in popularity by about 5,000 job postings over 2017. It is a general-purpose programming language used for web development and as a support language for software developers. It’s also widely used in scientific computing, data mining and machine learning. The continued growth and demand for machine learning developers may be driving the popularity of Python.

No. 3: JavaScript

JavaScript, the grandfather of programming languages, is roughly as popular today as it was in my last post about programming languages. That’s no surprise to us – JavaScript is used by more than 80% of developers and by 95% of all websites for any dynamic logic on their pages. Several front-end frameworks for JavaScript such as React and AngularJS have huge future potential as IoT and mobile devices become more popular, so we doubt we’ll see JavaScript drop in popularity anytime soon.

No. 4: C++

C++ changed very little in popularity from early 2017 to now. An extension of the old-school “C” programming language, C++ is usually used for system/application software, game development, drivers, client-server applications and embedded firmware. Many programmers find C++ complex and more difficult to learn and use than languages like Python or JavaScript, but it remains in use in many legacy systems at large enterprises.

No. 5: C#

C# (pronounced “C sharp”) went down slightly in demand this year. C# is an object-oriented programming language from Microsoft designed to run on Microsoft’s .NET platform and to make development quicker and easier than Microsoft’s previous languages. C# 7.2 came out in November, adding several new features geared toward avoiding unnecessary copying. C#, like C++, is heavily used in video game development, so aspiring video game developers would do well to learn both of them.

No. 6: PHP

PHP, a scripting language used on the server side, moved up to No. 6 in our ranking from No. 9 last year. Most developers use PHP for web development, either to add functions that HTML can’t handle or to interact with MySQL databases.

No. 7: Perl

Perl dropped by about 3,000 job postings and stayed in seventh place in our analysis. Perl 5 and Perl 6 are both chugging along; Perl continues to be popular for system and network administrators and as a glue language.

These are the languages that haven’t made it onto the top seven yet but have been growing in use and popularity and we need to keep an eye out for them in the future:

Swift: Swift, the programming language for iOS and macOS that Apple release in 2014, came in at No. 14 on the list. This may be partially because many job posting ask for “iOS” experience without naming specific languages. Swift has been growing steadily in popularity since it launched, according to IEEE Spectrum and Stackify.

R: R came in at No. 11 on the list, but we expect to see it climb in our ranking in the next few years. It’s rising in popularity in both international and U.S. search rankings and was the “least-disliked” language on a Stack Overflow survey this year. Its growth may be due to the growth of big data analysis jobs.

Rust: Although Rust ranks low on the list, it has been steadily growing in popularity according to Google Trends data.

Below software frameworks or technologies aren’t technically programming languages but are still important for developers to know it and are commonly advertised technical skills for developers found on Indeed.

SQL: SQL is the standard query language for storing, retrieving and manipulating data in databases. It’s not technically a programming language since it lacks looping and other basic functions, but extensions like PL/SQL have added some of these. SQL is in extremely high job demand, with more than 30,000 more job postings mentioning it than our top programing language, Java. If you only have time to learn one new technology, this is the one to pick.

.NET: .NET is Microsoft’s platform for desktop, web, mobile, gaming and IoT app development. It was released to the open source community in 2016 and is used by the C#, Visual Basic and F# programming languages. .NET Core, a cross-platform .NET implementation, extends .NET to iOS, Linux, and Android. Many Windows applications run on .NET, making it extremely prevalent in the business world and it to become more popular now that it’s become open source.
Node.js: Node.js is an open source runtime environment that allows JavaScript code to be run on the server side, allowing web developers to use one language for an entire web application. Node.js was the 12th most-popular technology in our analysis, not good enough to make the list but enough to show a solid demand for these skills. So, I suggest that any JavaScript developers spend some time with Node.js to make themselves more well-rounded, even if they focus on the client side.

MEAN: The MEAN stack (MongoDB, ExpressJS, AngularJS and Node.js) ranked 18th in analysis. Using the MEAN stack allows you to create an entire application using JavaScript, which is simple, quick and highly versatile. Learning MEAN will give any developer a strong background in one of the most common and active programming languages in the world.

1. JavaScript

2. SQL

3. Java

4. C#

5. Python

6. PHP

7. C++

8. C

More details: https://insights.stackoverflow.com/survey/2017#technology-programming-languages

In September 20, 1954 John W. Backus team: Richard Goldberg, Sheldon F. Best, Harlan Herrick, Peter Sheridan, Roy Nutt, Robert Nelson, Irving Ziller, Lois Haibt, and David Sayre first time executed FORTRAN and with the first FORTRAN compiler delivered in April 1957.

Q&A with Ken Thompson, creator of UNIX.

Q: At what point in Unix's development did it become clear it was going to be something much bigger than you'd anticipated?

A: The actual magnitude, that no one could have guessed. I gather it's still growing now. I thought it would be useful to essentially anybody like me, because it wasn't built for someone else or some third party. That was a pejorative term then. It was written for Dennis and me, and our group to do its work, and I through it would be useful to anybody who did the kind of work that we did. And therefore, I always thought it was something really good that was going to take off. Especially the language [C]. The language grew up with one of the rewritings of the system and, as such, it became perfect for writing systems. We would change it daily as we ran into trouble building Unix out of the language, and we'd modify it for our needs.

Q: A symbiosis of sort.

A: Yeah. It became the perfect language for what it was designed to do. I always thought the language and the system were widely applicable.

Q: The presentation for the Japan Prize mentioned that Unix was open source. Was Unix open source from the beginning?

A: Well there was no such term as "open source" then.

Q: I was under the impression that Unix really became open source with the Berkeley distribution..

A: No, we charged $100, which was essentially the reproduction cost of the tape, and then sent it out. And we distributed, oh, probably close to 100 copies to universities and others.

Q: Skipping several decades of work, let's speak about Go. I was just at the Google I/O Conference, where it was announced the Go will be supported on the Google  App Engine. Does that presage a wider adoption of Go within Google, or is it still experimental?

A: It's expanding every day and not being forced down anybody's throat. It's hard to adopt it to a project inside of Google because of the learning curve. It's brand new, and there aren't good manuals for it, except what's on the Web. And then, of cource, it's labeled as being experimental, so people are a little afraid. In spite of that, it's growing very fast inside of Google.

Q: In the presentation, you were quoted on the distinction between research and development. [Thompson said research is directionless, whereas development has a specific goal.] So in that context, is Go experimental?

A: Yes, When we [Thompson, Rob Pike and Robert Griesemer] got started, it was pure research. The three of us got toether and decided that we hated C++. [Laughs]

Q: I think there's a lot of people who are with you on that.

A: It's too complex. And going back, if we'd thought of it, we'd have done an object-oriented version of C back in the old days.

Q: You're saying you would have?

A: Yes, but we were not evangelists of object orientation. [In developing Go,] we started off with the idea that all three of us had to be talked into every feature in the language, so there was no extraneous garbage put into language fro any reason.

Q: It's a lean language, indeed. Returning to Unix, when you and Dennis worked together, how did that collaboration operate? Were you working side by side?

A: I did the first of two or three versions of Unix all alone. And Dennis became an evangelist. Then there was a rewrite in a higher-level language that would come to be called C. He worked mostly on the language and on the I/O system, and I worked on all the rest of operating system. That was for the PDP-11, which was serendipitous, because that was the computer that took aver academic community.

Q: Right.

A: We collaborated every day. There was a lunch that we went to. And we'd talk over lunch. Then, at night we each worked from our separate homes, but we were in constant communication. In those days, we had mail and writ [pronounced "write"], and writ would pop up on your screen and say there was a message from so-and-so.

Q: So, IM, essentially.

A: Yes, IM. There was no doubt about that! And we discussed things from home with writ. We worked very well together and didn't collaborate a lot except to decide who was going to do what. Then we'd run and very independently do separate things. Rarely did we ever work on the same thing.

Q: Was there any concept of looking at each others code or doing code reviews?

A: [Shaking head] We were all pretty good coders.

Q: I suspect you probably were. Did you use any kind of source code management product when working together?

A: No, those products really came latter; after Unix. We had something like it, which we called "the code motel", because you could check your code in, but you couldn't check it out! So, really, no we didn't.

Q: I bet you use source code management today, in your work on Go.

A: Oh, yes, Google makes us do that.

I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone.

Bjarne Stroustrup

For the D programming language, the compiler has a -cov command line switch to generate coverage information. Here's what the report looks like for the sieve program:


The numbers to the left of the | indicate how many times that line was executed. (If there is more than one statement on a line, the number is the sum of the execution counts of each of those statements.) The last line is the percent of the statements that were executed, in this case every executable statement was executed at least once.

What can this information be used for?

• to improve the program's performance, by finding ways to reduce the execution count of expensive operations.
• to find the most likely path of execution through a function, so the layout of the function can be optimized for that.
• to find dead code, which is code that can never be executed. Dead code tends to accumulate in older projects that have been successively maintained. Once dead code is identified, it can be removed or commented out, to streamline the source code.
• most importantly, it identifies code that isn't executed by the test suite. Test cases can then be crafted specifically to fill in those gaps.

For references: http://dobbscodetalk.com/index.php?option=com_myblog&show=Coverage-Analysis.html&Itemid=29

Question: Talking more broadly about software development methodologies, is SOA [service oriented architecture] simply old wine in a new bottle - I mean, there are lots of similarities with objects, and they have been around since the sixties.

James Gosling: Yes, there is a certain amount of old wine in new bottles. It's another one of these that is more about marketing: depending on your definition it means different things to different people. Structured systems as loosely coupled services has always been a good idea. That's what OOP [object-oriented programming] was all about. SOA is OOP in the large. Which networking technology you choose to use to link those services I deeply don't care.

Question: The difference between OOP and SOA, if you boil it down, is really just about the size of the chunks.

James Gosling: It is just about the size of the chunks.

Question: I am assuming you believe that Java plays well in a world moving towards SOA?

James Gosling: Yes, the nice thing is that Java and web services fit together perfectly. It's all about how two machines communicate and Java is good at implementing that. With its wide-spread adoption and standards support that makes it really powerful.

Notes: James Gosling, the father of Java, is vice president and Sun Fellow at Sun Microsystems, a distinguished software engineer most famous for doing the original design of the Java programming language, which Sun recently made fully open source.