Slashdot Mirror
Why New Programming Languages Succeed Or Fail
snydeq writes "Fatal Exception's Neil McAllister discusses the proliferation of programming languages and what separates the successful ones from obscurity. 'Some people say we don't need any more programming languages at all. I disagree. But it seems clear that the mainstream won't accept just any language. To be successful, a new language has to be both familiar and innovative — and it shouldn't try to bite off more than it can chew. ... At least part of the formula for success seems to be pure luck, like a band getting its big break. But it also seems much easier for a language to shoot itself in the foot than to skyrocket to stardom.'"
Everyone knows it's the Amount of Facial hair
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
Hmm, let's see...New programming languages succeed or fail because programmers either adopt them or they don't.
Don't expect me to port existing code to your new language. Either make it compatible - i.e. an old language with new features - or provide me with an automated conversion tool.
c++ would have died within months if it didn't accept existing c code.
What you say is utter bupkis and bullshit. There are many relatively modern languages that have become very popular without having any sort of real compatibility with C, C++, or any other programming language.
Just look at Perl, Python, Ruby, Java and C# for some examples. Those have all arisen in the last 20 to 25 years, well after C was extremely well established. While they can call out to external C code with varying degrees of difficulty, they aren't code-compatible with C in any way. SO HOW IN THE FUCK DID THEY MANAGE TO SUCCEED AND BECOME WILDLY POPULAR IF COMPATIBILITY WITH C IS SO DAMN "MANDATORY"?
There comes a point also when a new language does something an existing language already does, and does well. I dont need another language to learn that has no innovative and useful features.
What you can also do, is promise great riches, as in the case of Apple/iOS/Objective-C.
8 of 13 people found this answer helpful. Did you?
There is no magic formula. But there are some simple things that I find help me that have NOTHING to do with the language itself, or it's technical advantages/disadvantages. Strangely, they correlate in no way to popularity of the languages
You need a single document to sell me your new language. If you can't explain the concepts, basically, to a programmer in a page or two (enough that if you try to sell EVERYTHING I get bored reading the document as a whole), then it won't wash. If I can't understand why I should use your language, I won't. (Spreading it across a Wiki doesn't count, unless that Wiki has a complete copy available as a PDF or something readable.)
Your documentation should also help when I have a "how the hell do I do X?" question.
You shouldn't just assume that your way is the best. Ever. Just don't. It'll annoy me.
You shouldn't just assume that I'm happy to spend a year learning the quirks of your language.
I should be able to knock up a quick sample program, that uses one of your new features, and understand it in a matter of minutes. Literally. Minutes. Including downloading and installing your compiler / interpreter and getting it running.
Google sort of understood this with Go: http://golang.org/ They have all of the above, and even an online "compiler". They fail a tiny bit with "what's new" and selling the language, really, which is a bit of a shame, but they do a good job.
Ruby does okay too.
But PHP, one of the most popular languages, has a web-site that doubles as a bomb-site. It's hideous and has always put me off, even if they do have some of this information hidden away. It's not selling the language at all(presumably because they're "big enough" for everyone to just know about it). It's like reading a security/release-mailing blog sometimes.
C# doesn't sell the language at all, anywhere, online as far as I can tell. The first hit is Wikipedia. The next few are resource sites.
As far as I can see, C# succeeded because it was backed by a big company. By contrast, Go is still pretty obscure (which shows you there is no magic formula - Go aces a lot of the checklists but still lingers in the background). PHP succeeded because it was quick, simple, powerful and "came first" in terms of web scripting. It also created one of the web's largest security nightmares, which was something it was supposed to replace (Perl CGI).
C was popular because it was unique at the time, and powerful. C++ was popular basically because C was (that doesn't mean it didn't have advantages too, but it got popular by riding along - not by it's own merit at first, but that's what HAS kept it in place ever since).
There's no way to predict a success. Ruby / Rails came out of nowhere as far as I'm concerned and Ruby's been around since the 90's (Has it? Really? Bloody hell! Where was that hiding?). But things like Haskell were around too in that time and have never really caught on.
It seems the criteria are "ready - while being in the right place and right time", and almost the inverse of what you'd expect given a look at how much they want to ease programmers in. It seems that if you want to stand a good chance of being the next-big-thing, make an awful website, don't put up examples, make the simplest thing complicated or impossible, make an horrendous security mess, and then put it online. Then find the next fad, say your language is perfect for it, and push it everywhere you can.
Whether or not a programming language succeeds has a lot to do with how available the tools are. The language must have a good IDE, quality debugger and profilers. If it doesn't have these tools, it's not much use to serious projects. Nobody wants to write a serious application without the use of a modern debugger. If the tools aren't available, are difficult to set up, or cost too much, people won't start using your language. There's plenty of free and really good languages with great tooling out there that you'd have to come up with something pretty extraordinary to succeed without a proper toolset around you language to succeed. Oh that and a big API that does a lot of the work for you. Nobody wants to write all their own libraries for doing things that should be included in the API.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
At some point in the very near future, Neil McAllister will be able to craft a post entirely from links to his own posts. There will still be an advertisment on each page with links to 3-5 of his own posts. Fans of Neil's opinion will rejoice.
People posting hypothesis of what makes a language successful: if it predicts that Modula is extremely popular and PHP is essentially unknown, maybe you should revise it instead of blindingly post it just because you'd like that to be true.
Dilbert RSS feed
A language will succeed if it is pragmatic, scratches an itch, is more productive than what exists already, is well supported preferably by multiple vendors, is cross platform, is simple to learn and offers familiarity with what has gone before. The further away from these ideals a language is the less likely it will be to succeed.
I love to mess around with wacky new programming languages in my spare time, but when it comes to business there are only two things that matter:
1) Documentation
2) IDE quality
Lopes observes that few successful modern languages have roots in academia. An academic herself, she's naturally dismayed....Successful languages have a niche
That's really the heart of it. No matter how "good" a language might be from an academic's perspective, it has to be actually useful to be used.
C was (and still is) a great alternative to Assembly
Java succeeded mostly because it was Not Microsoft, but in part because C++ is a miserable language and the world was ready to replace COBOL, ALGOL/JOVIAL, and FORTRAN.
Ada failed for many reasons, but mostly because it was just glorified Pascal and had all the limitations that made Pascal a good student language but lousy for real work.
Lisp, Perl, Javascript, Python, etc. all fill niches; some niches bigger than others.
C++.
There is no need for anything else.
No debugging/syntax checking IDE for dynamic languages? Not if you count Smalltalk as dynamic. Smalltalk works arguably better for debugging, syntax checking, and more than static languages because of the VM concept.There can be a slight delay, especially if connecting to a VM remotely (Gemstone for instance), but Smalltalk's IDE even lets you program in the debugger. You haven't seen real TDD unless you've seen someone writing an entire app in the Smalltalk of choice's debugger. It also supports things like real-time unit tests that run as you type, direct debugging from web pages, runtime code changes, etc. The idea is that is always runtime.
Unfortunately, Smalltalk is too "weird" for some people, while others don't get it (example: power via simplicity). And then of course there was the vendor greed factor, incompatible dialects, etc.
I for one love working in Smalltalk and think files are a stupid concept, particularly for software development. OO source control? Yes please. People are just too set in their ways, and that's why many things that were good middle grounds have picked up momentum. I think a lot of people really do want something like Smalltalk and do not realize it.
I work with C, C++, Objective-C F#, C#, Java, Scala, Ruby, Python, Smalltalk, and a few others. I find it really funny that people are so excited over Ruby for example when it just feels like a crippled, inconsistent, buggy Smalltalk. I do like Ruby, but it feels like a toy in so many ways and I just end up using Scala or gasp, Java, Objective-C, or C# instead for anything real. I am happy to see newer projects like Pharo, but without a large war chest backing it, I am sure Smalltalk will remain a dirty secret and unheralded language. At least overall the ideas from Smalltalk have made computing as a whole so much better. It took too long though and we're still not caught up.
Because for instance, Perl can interface with C libraries? (just write the right lib.xs for your C lib.)
It must have a big standard library which covers most common needs. In Java you can develop almost any kind of application without the need for third-party libraries.
Ada did not fail at all. It is used for exactly what it was designed for: mission critical defense applications.
Ada was not designed for intranet or web or mobile or desktop applications, although it can do those things really well.
Popularity is all about making it EASIER.....and FASTER, to produce stable, fast, and reasonable footprint applications.
If a new language doesn't do that on its own, then it needs a platform or set of tools to make that happen.
If a new language just lets you do the same things, but in a different way, with maybe 1 or 2 things being better then there is no motivation to learn it, use it or make things for it.
Seriously tho' - python, for example, is successful without having a good IDE. There are some IDEs that some people would argue are good - but most of the people writing python are using emacs or vi.
I'm also rather sceptical about the need for a good debugger. Most of the time I find writing a couple of simple unit tests and a putting in a couple of diagnostic prints is fine for figuring out what's going on (and you have the tests forever, which means that changes are less likely to introduce bugs in existing functionality).
I HATE language selling sites. Many a new language or framework has a VERY nice presentation site telling you that THIS is the answer to your problems, this language will screw your gf, kill your dog and set your house on fire, letting you concentrate on the essentials of life. Coding.
PHP is totally different, it doesn't sell itself, it has no slick presentation, just every function described in clear plain English (and many heathen tongues like Dutch for those who were not blessed by god to be born in the US of A) with informative user comments with zero SPAM!!! That is what a not so good developer like me needs. Not so good? No. Really good programmers can pull a six figure income with ease, wallstreet pays the top close to a million, top game developers drive in Ferrari's. If you are coding web pages for less then 100k per year and have a bus pass, you are just not at the top. Accept it, the world needs average people too. You don't have to be the fastest runner in the world to escape the lion of unemployment, you just have to be faster then the guy next to you. Or have a gun... and shoot the guy next to you.
What I have noticed is that there are a LOT of elitist among coders who fail at being lazy. A good coder writes NOW what he needs NOW. Coding for the future is nice but you even end writing for the past instead because by the time you have written your future proof code, the future has become the past and you missed the present. Sure for some projects, the best is needed and that is great for those who operate at such lofty levels us mere degenerate mud dwellers can not even dream off. But down in the mud, a lot of code gets written that solves a problem NOW and makes money NOW.
ID spent a fortune on the Rage engine and the Angry Birds team did not. Which game was the greater success? Not that I think ID was wrong... but I know my limitations. Do you?
Ubuntu, PHP etc are typically vilified for their common populalatiry. Meanwhile the Debian and Ruby people never quite understand why their own products just don't get to be as popular. They rail about lack of structure or security problems (note that Rails had a far bigger security hole at its core greater then PHP ever had and no Rail fans ever apologized for their slurs against PHP) and don't understand that real users simply need clear documentation.
Sometimes a coder thinks that HE has the next framework... sometimes they even ask for advice on it. My advice? Forget the code. I believe you it is good. SHOW ME THE GODDAMNS DOCS to use your new baby. And in those docs. NEVER assume that I can read your mind. I need EVERYTHING explained because what seems obvious to you is not going to be obvious to anyone else.
It is part of the reason Javascript is such a dog. The language is pretty damn good in my opinion. But there is no documentation for the average coders. php.net is the gold standard for functional documentation of a programming language. Learn from it or die in obscurity. Unless your audience enjoys coding in the dark. Some do... but I don't.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Because excluded middle.
What's the point of using a new language then? I found it liberating to get rid of the (function(){...})() cruft with the switch from Javascript to Coffeescript. According to TFA's philosophy, Coffee does it wrong because it alienates Javascript users. What would be the point of using it if it only offered "baby step" enhancements, at the expense of needing a Javascript interpreter/crosscompiler?
Or to say it with Alan Perlis:
There are only 2 different types of programming languages: those everybody continuously bitch about, and those nobody uses.
Yeah, him saying "call out to external C code with varying degrees of difficulty" is purely disingenuous. There is NO difficulty; it may be slightly tedious, but really, no, it's not a big deal. It's quite easy to get a Java/Ruby/v8 (node.js) application bound to an existing C/C++ code-base.
Brian Fundakowski Feldman
What makes a language successful, is people using it. Again, also not what you think.
What it takes is for a 'killer-app' to be written in the language first. People want to use and improve that app, so they learn the language.
Sometimes these apps are business apps, and wanting to use and improve means getting a job.
Sometimes these apps are hobby apps, and wanting to use and improve means personal satisfaction.
I've never learned a language for the sake of learning the language. I've always learned a language so I can work with projects already using it.
Scala and Clojure (on the JVM side) are very new and Haskell (relatively new) are showing that there are many things to be learned by creating new languages. And there are lots of other cases.
I find Clojure particularly interesting because adding vectors and maps (in addition to lists) to a "Lisp one dialect" is nothing short amazing. Of course it's not "the one ultimate Lisp". But it shows that even in the Lisp world there are still interesting things that can be done.
We're not anywhere near what we should aim for: software and languages are decades behind hardware.
Anyone who thinks is current language is "good" is a knee-jerking fool with a myopic vision. Modern languages aren't good. Modern VMs aren't good. They do s*ck.
Linus Thorvalds (you know, he made that little thing that powers hundreds of millions of cellphones, routers, servers, etc.) recently said in a filmed interview that Java s*cked and that the JVM was lame.
And I think he's right on spot. Yet for a lot of "Real-World" [TM] application it's the "best" we have today. But it doesn't make the JVM great at all. It simply makes it "the best VM so far"... And there's still a long way to go.
In my own stupidity I used to think that "Java the language" sucked (don't get me started on the non-portable C#) but that "Java the virtual machine" was good. Now I realize they're both gigantic kludges.
At least the JVM offers a good starting point for someone wanting to create a new language: Rich Hickey who created Clojure nicely explains that.
But still: the JVM is certainly not the be-all end-all of VMs (tail call optimization for a start ; )
I both pitty and envy the comfort of those thinking that their language is a good language...
All the languages that have succeeded, did so for just one simple reason:
they solved a problem many people had.
That's it. Marketing does help, yes. Documentation too, of course. But the key is helping people solve their problems.
COBOL, Fortran, LISP and C where among the first. COBOL appealed to the business people, Fortran made it easy for scientists, LISP for early AI and list heavy processing, and C for the performance savvy (just anybody else).
C++ was there when C people wanted to grow, and go into the business niche. Then came Java, just when a COBOL was overdue.
Visual Basic helped stuff enterprises with kids coming from 8 bit computers, very little formation and low income expectations. C# is just the replacement of Visual Basic.
PHP was there when people started crafting complex web sites. It was simple and got the job done.
Perl was the choice for many years when a Unix Shell hack starts to do a little too much. Currently Python is taking this place.
And so on, and so forth. No great mystery, really.
Are you confusing sarcasm with ignorance? For the OP's sake, I hope so.
At least Brainfuck never caught on!
It's not really just the language. It's the entire programming environment: the language, the library, what system features it allows you to get your hands into and failing that last one, how much the language has "build in" and with how much quality, how much trouble-less it is to run in your target system, how much easy is to build a program around it
The major PITA's I have found with "alternative" languages is when building beyond hello-world/clickety demos. Many languages with their respective build environments fail to provide a good desktop infrastructure to build rich apps. Some fail at the web side of it. Some ain't much good at any of it. For windows desktop apps, if you don't provide support for system widgets, you better have a alternative to the build in rich editor with printing support that can just copy/paste to/from office-like software without much trouble. Many focus too much into the "programming" side of it and relegate the integration with everything else to second plan.
sign(c14n(envelop(this)), x509)
Because they let programmer do whatever they want. Coding style - anything goes. Documentation - not needed. Unit Tests - huh, why? Patterns - Never heard of that? It is this cherished freedom that is killing reusability and security and causing folks to reinvent the bugs over and over again. So unless we get a language that is a like a code nazi from the dark side of the moon, no progress will be made.
Eh... java has JNI and Python has fairly trivial native bindings.
In fact an awful lot of the power of Python comes from the ease in which you can string together a bunch of stuff that uses the sophisticated underlying C libs in a RAD style. It's part of the beauty of the whole thing, and part of the major appeal of python.
So your rant is totally off target.
Carnegie-Mellon has dropped OOP from their CS requirements because they felt that the OOP model was not appropriate for modern needs. Linus Torvalds says "C++ is a horrible language." In the January issue of IEEE Computer there is an article "The Java Tree Withers - The java report card: infrastructure gets a D, code reuse gets an F".
Programming languages drive devices. I'm doing heterogenous parallel processing in C and CUDA. Multicore and massivelly parallel concurrency is absolutely the future and if you think it's easy, you haven't done it. There is a new compiler that will mix x86 and Fermi but it is definitely suboptimal. Only a human can do the cost/benefit analysis required for parallelization and only a human is creative. At this point anyway. Multicore consurrency is here to stay. I see no reason why heterogeneous processing (multiple architecture machines)should go away either.
Also, while Cray dropped the use of FPGAs, the are getting easier and easier to program, they are lightning fast, they can be reprogrammed in a millisecond and... and... while software patents are a can of of worms, an FPGA program/algorithm can be patented as a circuit. And there is massive legal precedence in enforcing circuit patents.
I find that the most important feature of a language is modularity. Have a big standard library, make it easy to use third-party libraries, including foreign ones and make it easy to create libraries.
I personally think that programming languages are a lot like medicine.
Your new language doesn't just have to solve a problem or two that you see with programming language, it has to do it better than existing languages while having less "side-effects" (quirks, difficulty, weaknesses).
If the advantages it provides aren't big enough to cover the costs (like learning a new language, using a new compiler, writing plugins to syntax-highlighting, etc. etc.) then they simply don't matter.
Assorted stuff I do sometimes: Lemuria.org
Originally the "popular" languages were forced down programmers' throats from the companies that built the servers they ran on:
Mainframe era (1960s - 1980s): In a time when the mainframe was king, Cobol was the be-all-end-all. you couldn't go wrong learning it.
Midrange era (1980s): As mid-size companies began to afford computing power, midrange servers started filling in. Languages like RPG and such became popular. The midrange era in business didn't last long, though, so most people don't know these languages.
Server era (1990s - present): Now smaller companies could afford computing power. Also, the merger of business and acedemic programming cultures started happening since businesses didn't really have a major player to go through when x86-based programming started.
In summary, many languages (in business) over the years suceeded mainly because they had major backing from an established vendor at the time. The main exceptions to this are C/C++ (the biggest supported languages in the academic community at a time when x86-based servers started taking off), and the current crop of languages which are successful in business because they fill the need, have great tools and support from the community at large.
To be honest, since mobile applications have become prevalent, I'm surprised we have not seen more languages that support those platforms become more popular. For example, Objective C would be still in relative obscurity if it wasn't for iOS. Mobile is the next platform that is going to be targeted for the "next big thing" (tm) in programming languages.
Guy Steele said it all : http://video.google.com/videoplay?docid=-8860158196198824415
AT&T's C language tromped the competition being nearly free at universities int he 1970s and 1980s. The just charged distribution costs. Ditto C++ over ObjectiveC. ObjectiveC had the advantage of commercial support and more Smalltalk-like roots than C++. But only Apple uses it.
In mos operating systems Java is free.
Python is a glorified C wrapper.. and is dreadfully slow.
It came out nearly the same time as C++ which. You had to buy Objective from its vendor or Apple which C++ was was free. ObjectC was ahead of C++ in quality for many years, but languished due to its price. I used ObjectIveC as a NeXT computer developer.
http://www.swig.org/
Let me introduce you to a commonly used tool called SWIG, or the Simple Wrapper and Interface Generator.
-1 angry, uninformed kid.
Make a programming language that's readable by humans, and have the language map concepts to code in the way humans think about things and it will be wildly popular (PHP, VB-anything, C#, Javascript/DOM). Make the programming language terse, efficient and mathematically consistent and it will be wildly popular - among mathematicians and gradually abandoned by most of the rest of humanity (e.g. Fortran, Powershell, C).
In the former cases, the machine does the heavy cognitive lifting. In the latter, you're expected to do it all. Guess why PHP is more popular than C++? Yes, PHP is sloppy, inconsistent and as random as the people who use it. That's the majority of folks who have to get some work done. As awful as the language is, it rules the web along with vb/asp and javascript.
Getting the picture?
Please do not read this sig. Thank you.
A lot of Perl's syntax is based on sed, awk, and Unix shells, with C-ness thrown on top. C wasn't the first and only language, ya know. And C wasn't "extemely well established" until about 1990 or so. Now get off my lawn.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Java succeeded because Sun 1) gave it away, and 2) threw money at giving it away. Remember "applets"? Java was supposed to be the programming language of the Web. That didn't work out. It ended up being the new COBOL, which was not Sun's intent.
Some languages fail, or get stuck, because the designer is in love with their own implementation. That happened to Pascal and Python. Wirth's own Pascal implementation was a cute little recursive-descent compiler that generated RPN byte codes, like a Java compiler. Wirth resisted changes to the language that would allow programming in the large. ISO Pascal reflects his biases. So Pascal became stuck in an educational niche. The original Macintosh software was all written in an extended Pascal, as was much '80s software. But everybody had a different dialect - there was Turbo Pascal, Clascal, and a few others. They never merged.
Modula, Wirth's second try, was also crippled in certain ways. Modula 2 was better. Modula 3 was good enough to be used to write an operating system kernel. Unfortunately, Modula 3 was only used with DEC, which died after being acquired by Compaq.
Python has some of the same problems. The feature set of Python reflects what it's easy to implement in a naive interpreter, like von Rossum's CPython. Internally, everything is an object, even integers and floats, and object access involves dictionary lookups. This makes CPython slow. Every attempt to speed up Python substantially has hit a wall, including Google's "Unladen Swallow" effort. (PyPy is making progress, but it's taken a decade and requires an incredibly complex internal combination of interpreters and compilers.)
The biggest disappointment to me has been that we're still stuck with C. C has two killer bad design decisions - the language doesn't know how big arrays are, and the "pointer=array" thing lies to the language. Both reflect how things are done in assembler, and the fact that the original compiler had to fit in a 128K PDP-11. Most of the millions of buffer overflows and crashes that occur daily can be traced to those two design decisions. (C++, as I point out occasional, tries to paper over these problems with collection classes. But the mold usually seeps through the wallpaper, since most operating system and library calls want raw C pointers.)
Just look at Perl, Python, Ruby, Java and C# for some examples
You do realize all of those languages have a way to call into C code, right? In fact, it's a good idea to do so, because then you can take advantage of all the pre-existing libraries that are written in C. You don't have to write OpenGL from scratch if you want to use it in Perl (or your new language), you can just write a wrapper around the existing library.
"First they came for the slanderers and i said nothing."
This proves my point, some people care about getting things done, about being able to find out how to get things done... and others about the font used for the logo.
Who cares about the function names? I can hit a dozen developers from my desk and every single one of them will have a different idea about the best naming schematic and formatting rules. I often use 3rd party libraries, I just adjust. Go ahead and work with something else if you want but don't complain when thousands who work in less exalted positions choose functionality over elegance in something nobody but a programmer will ever see.
What is amusing is that you care so much about some silly naming scheme. Buit tell me, what did you think of the recent massive security flaw in Rails. Did it have pretty names in the gigantic security hole? What value does a naming scheme really have beyond pleasing elegance?
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Oooh, a language discussion! Have I missed all the folks who put down functional programming (and LISP), when their experience is limited to the Wikipedia article, or a week or two of exposure in their CS101 class?
Don't start without me!
https://www.accountkiller.com/removal-requested
What, no mention of Ruby? I admit Ruby has it's issue but it has been adopted enough to get a mention.
It's not about the language, it's about the framework, the tools, the platform. Objective C is a confusing language, most should agree. But you don't mind because the platform (iOS fex) is attractive and cool, the tools (xCode fex) are awesome and the framework (Core*, Cocoa, etc) is very very good. Nobody would care about C if it wasn't for the fact that it interfaces best with the Linux kernel and base libraries, and maps very well to hardware. Ruby, Java, C#, they are just languages. We learn them, and if we learn them really well, we learn to love them and hate them. The point is really what you can _do_ with the framework that is made available through the language.
Who really knows what paradigms are coming along. The point is that we are at a turning point in computer (and device) design. We are leaving the von Neumann and Harvard architectures behind. The existing languages are generally unsuitable for the direction we are headed. Remember: The purpose of a program is to control devices. The language must generally be suited for that purpose. If I've got a machine with 12 Intel cores, 1024 Nvidia cores and lightning fast data storage, I can rip through data looking for patterns using a dozen different algorithms.
Bjorne Stroustrup: "A single-threaded, nonvectorized, non-GPU-utilizing application has access to roughly 0.4% of the compute power available on the device."
Back in the day, when a "small" project, suitable to be given to a young designer as a first solo flight, was anything less than six man months of effort, and was scheduled for use sometime next year, and a "big" project was at least 60 man years and needed next year and for the following 10 years, the budget allocation would be roughly 40% design, 40% testing and documentation, and 20% coding. The systems analysis and design tasks included choosing the right tools for the project. Sometimes the chosen strategy would be a mixture of languages (especially when the project needed different sub-systems on different platforms), sometimes the choice of documentation tool would be much more important than the code language. If user documentation was going to be extensive, then a full typesetting tool would be used, if not a simple text editor with hand drawn diagrams might be sufficient for IT staff.
In any case, the final design stage would be to produce pseudo code for every module/function and a dictionary of every variable to be used (including a methodology for naming local temporary variables). Only then would coding begin, sometimes done by the same people who had done the design, sometimes not.
In that environment, FORTRAN, COBOL,Algol had one important advantage - they were available. In fact we used a language called RTL/2 for many programs on DEC minis, because it had good access to assembler for time critical functions and special I/O to some of our exotic peripherals. We used COBOL on VAXen and ICL and IBM mainframes, for database access and fancy output, and FORTRAN where engineers from non IT departments needed to specify and/or understand a function. Assembly level code was still needed on most jobs, simply to get run times within acceptable limits.
So what makes a language popular? Who with? I hate writing COBOL, but doing the SAME JOB in C++ would be even worse. I love C++ but making the source readable to a user is a non starter for anything more complicated than Hello World, and that has to be explained.
I think the whole thread is confused over popular, widely used, and readily available. A language might be popular with coders for reasons such as "coolness", future employment prospects, and dare I say it laziness, while the same language might be detested by the IT manager who has to squeeze more mips out of the same hardware. As for the users, they just shouldn't be allowed to have an opinion!
The very idea of interactive coding fills me with horror, how the hell do you test it. Is this where all of the security holes and resource leaks are coming from?
Measure twice, cut once. and get off my lawn.
nec sorte nec fato
A lot of languages I've reviewed are just a bundle of library calls and references to binaries that do things which can't be written or expressed in the language itself. I personally won't use a language unless whatever API's it depends on can be written in that language. I know that technically even those scripting languages have grammars and definitions, but I just don't think library calls that aren't language tokens in the grammar should be "standardized" as part of the "language" itself.
G and C#, you've got to be frigging kidding, more of the same crap; faster JavaScript, same old crap. How about something innovative? How about a new paradigm where the language, it's syntax are irrelevant? How about a system without a language? How about a language that is designed to disappear? How about accessing the full power of hardware tossing out the ridiculous language virtual machines?
Having used a plethora of languages over many decades every language sucks the big one big time except for assembly language and the new language I'm developing of course. When developing a new language you pretty much need an attitude like that to get over the morass that everyone - including more likely than not, you, although I'm willing to give you the benefit of the doubt - throw at language and system developers.
Assembly just sucks because it's so focused on the pesky details but it does so elegantly since it's the real hardware level so it doesn't suck big time. Assembly is the most powerful language after all as it is what is really happening (baring bugs in the processor). Now you might claim that micro-code is the real hardware but who ever programs in THAT today? Oh right the CPU, GPU, ASIC and FPGA guys. Ah whatever that's hardware not a general purpose programming language.
This new language - more than a language, it's a system - has new features that will knock your socks off. Like the core ideas of Lisp, Smalltalk, Erlang, Clojure but without all the horrifying warts that make your mind do crazy mental gymnastics just to solve problems and write awesome and fast compiled safe parallel native code.
If you're like most programmers then you'll love this new language. It's got it all, the homoiconic aspects of Lisp where programs are data and data are programs; it's got the uniform message passing paradigm of Smalltalk but improved so that every operation is a message including all meta operations, thus it also has all the distributed message passing capabilities of Erlang without the cryptic functional goo that lacks even basic notions of objects; it's got Clojure beat hands down which is easy since to know Clojure is to know the nine gates of hell, it thumps Clojure by providing a different paradigm where the user doesn't have to become a cryptozologist digging through the bizarre Clojure primitives just to get on with their work; all in all, it's a huge advance. Oh, and with it's improved Full Block Closures it can do things and meta things that functional languages and Smalltalk never dreamed of.
One of the biggest benefits is that it provides a means of doing multi-core multi-node native threading in a safe parallel programming environment for the bulk of common parallel operations within one program, across multiple programs and even across distributed nodes with many programs running. It can even do so efficiently.
Every aspect of the language and it's system is written in itself including all of the execution engine which provides not only homoiconic aspects but also Mobius Loop aspects when the language and it's system evolve via generational rewriting to the next level - which is really where the message passing meta operations on all parts of the language/system come into play and shine. You can't have a language/system that evolves itself if it can't rewrite all of it's parts and just about all languages fail at that.
Oh, it's not a virtual machine since it actually uses the full power of the computer hardware it's running on with it's intimate direct native code connection to the CPU and GPU and other hardware it's running on. Virtual Machines suck big time, in part because their machinery is hidden in inaccessible primitives providing a locked in frozen in time binary; in part because byte codes are pathetic primitives. This new language provides the interactive feel of Dynamic Languages with Full Interactive Development Environments (e.g. Smalltalk like Integrated Development Environment but without the VM). Naturally it's a fully dynamic language.
The
How about "A language succeeds/is adopted because of what it makes easier vs. the current state"?
C simplifies Assembly
Object-oriented (supposedly) simplifies procedural
Functional simplifies procedural
perl simplified text processing
php simplified web development
java simplified platform-specificity and direct memory management
python and ruby simplify type management
erlang simplifies concurrency
hadoop/pig simplify distributed processing
I may be oversimplifying (har,har), but it seems that more or equivalent power with greater simplicity is a common pattern. Subsequent generations criticize what initially appeared to be simplification (perl, php) but I think within the context of when they were developed this axiom holds true.
Are you completely illiterate? Why didn't you actually read the GP's comment before replying to it? The GP addressed exactly what you just mentioned.
Since you obviously have a pretty difficult time with basic reading comprehension, let me point out exactly where it says that (emphasis added):
Just look at Perl, Python, Ruby, Java and C# for some examples. Those have all arisen in the last 20 to 25 years, well after C was extremely well established. While they can call out to external C code with varying degrees of difficulty, they aren't code-compatible with C in any way.
I sure hope you feel embarrassed about this. You've made yourself look rather stupid. I hope you take this as a lesson for the future; read a comment fully before replying to it.
You don't know what disingenuous means.
...have been greatly exaggerated.
It always amuses me to hear people who know no better talking about COBOL as if it's dead and gone, when it's very much not. Sure, it's not a language that you'd use to program in for a PC or a smartphone - that's not where its strengths lie. But COBOL still very much rules the roost in its natural environment, namely high-volume, high-throughput commercial programming. If you look at any of the largest companies out there, you'll find three things: Mainframes, CICS and COBOL . Mainframes have massive throughput with a reliability that's, simply, in a different league to other platforms. CICS is IBM's flagship transaction processing manager, used - according to Wikipedia - by over 90% of the Fortune 500 companies, with features that complement the mainframe need for long up-times and data/transaction reliability, throughput and integrity. And COBOL (THE main programming language on CICS installations, as well as others). Frankly, it's all around you, even if you don't notice it (if you used an ATM yesterday, your request was almost certainly handled by a CICS transaction running a COBOL program, for example).
The fact is that it may not be sexy and it may be venerable (and far too few new programmers have any experience of it or the environment in which it excels), but COBOL is very much alive and well in its niches - and, there, there's a LOT of it. Why? Because, ultimately, a language is only a means to an end - and in the case of COBOL, that's delivering high throughput with high integrity in a massively reliable environment. Simply, COBOL delivers what the BUSINESS needs; and, academic and peer scorn notwithstanding, I have no doubt it will comfortably outlive most of the people reading this.
Your thoughts on J++?
it may be slightly tedious, but really, no, it's not a big deal
Yeah today it isn't, but things weren't always that way.
"had all the limitations that made Pascal a good student language but lousy for real work." -
What "limitations" are those (that are of practical import which affect Pascal dialects like Borland Delphi from being used on large professional projects), hmmm?
I'd like to hear them from you!
I mean, because as is, right now from you??
Heck, I KNOW you're talking out your ass regarding Object-Pascal/Borland Delphi!
(Becaue not only imo, but also professional programming experience since 1994? Well, you're just another 'sheeple' that follows the 'party line' but hasn't done any work in said language to speak of - but, yet "sees fit" to shoot his inexperienced mouth off on it... which is, to be blunt about it, pitiful!).
APK
P.S.=> Clue/New News/NEWSFLASH: Have you ever heard of Borland Delphi/Object-Pascal?? Obviously not, and your statement only reaffirms mine, once more... apk
Coming from the author of the language most prone to exploits? I'd take Anders Hejlsberg (creator of Turbo Pascal, Object Pascal, Borland Delphi, and .NET for MS) over him, any day of the week. "BWK" was just 'big shit' when there were no real competitors is all. That's no big accomplishment.
I keep coming back to it, because often there is no better alternative.
This sums it up.
Yeah, that's a checkmate.
There are only 2 different types of programming languages: those everybody continuously bitch about (yet are forced to use anyway), and those nobody uses (for good reason).
FTFY
Maybe if we build a big enough AST tree out of these logical (yet empty and meaningless) statements, we will finally get down to the root of and understand why programming languages suck.
We are now at step 2 of 17,392 in this chain of reasoning.
Your move.
Python does type checking at run-time. It prevents you from destroying the run-time infrastructure, and alerts you when you try that. That's what's missing in C ans C++, and a rather involved debugger ends up being needed to assess the damage after the fact.
"There is still 1 thing that i hate in Python: It is not easy to use my 4 core processor to the max" - by Chatterton (228704) on Friday March 16, @10:19AM (#39376945) Homepage
Use threads: It's possible in Python... & because of today's modern Operating Systems kernel mode process scheduler subsystems? There's no REAL need to actually even go as far as EXPLICITLY doing processor specific affinity api work either... not really!
APK
P.S.=> Of course, I use threads in Delphi, & C++ with ease also (generally faster languages for most things vs. Python, but, like was said here many times? Python's "piping" abilities along with regex (which libs like BOOST give Delphi & C++ too, along with their own native regex also) make it create things fast). Still - I like python for string processing work actually! ... apk