You are an individual. Your rights are irrelevant if a corporation might lose money when your rights an enforced. Well, only those corporations that have friends in high places, like movie studios. Actually, it's just turtles all the way down, by which I mean corrupt major party politicians all the way up.
Not just for that copy, but also for every subsequent copy of that copy. For example, the copy Netflix sends me when I stream a movie (yes, it is a copy, in a technical sense). Or the copy Comcast sends when I watch cable.
The real answer is, "The government's argument only applies to real, individual people. Fake persons who are really groups of wealthy people (some called these organizations corporations) will have their rights enforced at the expensive of the citizens of the US or any other country."
After all, this will clearly be a deterrent. Or he clearly caused millions of dollars in damage while he was playing with himself. Or something like that. Logic is not actually relevant when it comes to copyrights.
I understand how a hand count works. I have no idea how most voting machines work, because their designs are secret. We can talk about standards after we get access to source code and design documents.
C++ lacking in expressiveness? You have got to be joking,
Well, how might you add "operator#" to C++? Adding new language features to C++ basically requires a new C++ compiler; lexical closures, for example, only became possible with C++11 (previously, Boost's lambda expressions library got you halfway there). That is a result of a lack of expressive power.
your right there are a lot of poorly defined areas in C++, but many of them stem from the fact that there are 100 different ways syntactically to solve any given problem.
It is mostly due to the standard being written for compiler writers and language implementors, rather than for programmers.
Of course some ways tend to be better than others, hence I'm confused about your problems with constructor error handling. You handle errors in constructors with "throw", combined with good RAII style, you get the benefit of fast code, that is robust to memory errors
Except when your objects are global, in which case throwing the exception means your program aborts, since there is no standard way to write a global catch (set_terminate won't work if the exception is thrown before the entry to main -- which is what will happen if the constructor of a global object throws the exception).
Destructors aren't as clear cut, but the easy answer is not to have fatal errors in the destructor
In other words, destructors should have trivial bodies. Why even have destructors if that is how things have to be done?
One of C++'s strong points (vs C) is that you can create a domain specific environment by careful class design and operator overloading
Unless you want to add a new kind of operator or a new kind of syntax.
As far as debug-ability, or a programmers ability to focus on the problem at had rather than the language, I suspect that is all just a matter of experience.
Experienced C++ gurus make mistakes with pointer mechanics sometimes.
In the real world, your team will have people with varying levels of experience; the least experienced person will be the bottleneck when it comes to things like undefined behavior, dangling pointers, etc.
In a lot of languages you learn how to do things, in C++ you tend to learn how _NOT_ to do things
Which is precisely the problem here. In C++, you need to know what valid C++ expressions, statements, or programs should simply not be written. Rather than rule such things out in C++11, the standards committee just added more things that you are supposed to know not to do.
Those results have re2, and it beats all the normal regular expression parsers only loosing to a lisp specific parsing/matching system. I don't call that a win for LISP, if you move the goal posts (we were comparing regex) then its not apples to apples. Its not hard to imaging a dozen ways of creating a searching sorting system faster than regex if your willing to wiggle the requirements.
Like I said, this is not a good benchmark; on the other hand, RE2 is not average twice the speed of libpcre (unless you count an outlier):
I would not draw too many conclusions from the benchmarks alone (there is no direct comparison between CL-PPCRE and RE2), but CL-PPCRE does do something that neither libpcre nor RE2 do: it compiles your regex into a callable function that does not traverse a pointer structure. With a good compiler (n
Namely because no matter what language you use, you'll end up with those kinds of issues in some form
Except that in some languages, those issues are rare. The only time I have seen a Lisp program corrupt its heap (through the equivalent of a dangling pointer) was when I explicitly disabled safety features. In C and C++, on the other hand, dangling pointers are a common and routine source of problems; in C++ especially, dangling pointers tend to creep up in all sorts of unexpected ways.
That is why I said programmers will not get bogged down with these problems -- these sorts of things are sufficiently rare in high level languages that many programmers will not see them.
You can interface any language to any OS regardless of the API and documentation
Only if your language has a suitable FFI or if interfacing with an OS is actually a language feature. Some high level languages do not have such an FFI, and in many high level languages the FFI is cumbersome to use. OS documentation usually assumes the programmer will be using the same language that the API is written for (nothing else would make sense), which adds yet another hurdle for programmers using another language.
I am not saying that it is impossible, I am saying that it is harder to do and that there is an advantage to using the same language that the OS was written in. OSes have been written in Lisp in the past -- and unsurprisingly, most of the applications for those OSes was also written in Lisp (as opposed to some ML, Ada, or C++).
The reason that C and C++ continue to be popular - even in the face of C# and Java - is that they enable the programmer to actually get their tasks done because of how flexible the language is. What language fix-its call ambiguities are actually strengths for C and C++.
Except that C++ doesn't limit undefined behavior to situations that make sense -- for example, converting from a numeric type to a pointer type (this may not make sense on all architectures, but it does make sense on some). In C++, you have undefined behavior that could not possibly make sense no matter what architecture you are using. In what system does it make sense to allow control flow to reach the of a non-void function? In what system does it make sense to allow a reference (which cannot be reassigned) to a local variable to be returned from a function? These are things that could have been forbidden by the language definition; instead, it is up to compiler writers to decide what to do, and the fact that pretty much every compiler has had non-standard features for detecting / rejecting such things had no impact on the C++11 standard.
These are not features that add to the flexibility of C++; they are just traps waiting to ensnare novice programmers.
It is hard to argue that C++ is a flexible language when you need a new compiler just to add a feature like lexical closures. If you want metaobject protocol, continuations, or other language features, you are either stuck with some clunky, brittle, and inefficient version using templates and operator overloading or else you are going to need a new compiler (and then you can forget portability).
C, and its extentions C++ and object-C, have withstood history because they have met and exceeded their target goals.
First of all, C and C++ have both been updated several times in order to remain relevant. Second, saying that C exceeded the goals that its designers had in mind is not saying much -- the original Unix is not very impressive, even by the standard of the 1970s. Neither is saying that C++ exceeded its designer's goal: C with objected oriented features (that goal was expanded to "a language that is relevant" -- and C++ has not exceeded that goal, it has only met it adequately for most programmers).
As for objective C, it was hardly a blip on the radar until Apple gave it a boost. Hardly
I think you fail to understand how adaptable C and C++ is
I don't. My first programming language was C++, and I programmed in C++ professionally. C++ is severely lacking in expressiveness, and there is an abundance of undefined behavior in C++. Debugging a C++ program is as much about low-level program mechanics as it is about high-level logic (even when you are writing a high level application). Dealing with errors in C++ is a giant ball of confusion -- there isn't even a good way to deal with errors that occur in constructors or destructors.
C++ is surviving because of its history -- a lot of C++ code was written in the 90s, and nobody has the time to rewrite any of it (not even to get it up to date with modern C++ standards -- I was once on a project that had to use a subset of C++ in order to maintain compatibility with old compilers from the early 90s). Schools keep teaching C++ because they believe their job is to prepare students for jobs in industry where they will be writing C++ code, which helps to keep C++ afloat by training programmers to think in C++. There is no real technical advantage that C++ has -- none of its features are unique, nor is the combination of its features -- and it carries plenty of technical disadvantages compared to other languages.
The strong point isn't how great it is at any given benchmark, but rather how good it is for solving a whole range of different problems
There are other languages that are good at solving problems in that range, which do not have C++'s deficiencies. If you are writing low-level code, do you really want to be dealing with implicit function calls? If you are writing high-level code, do you really want to spend your time deciding between shared_ptr and weak_ptr? If lives depend on your code, do you really want to have no idea about the order in which functions will be called?
If your OS provides mmap and its 10x faster than doing read/write style ops then you have that choice
What makes C/C++ special here? A typical FFI in a high level language let's you call functions in shared libraries (and by extension, functions that your OS provides), and many implementations of high-level languages have (non-portable) extensions for a particular target OS.
If you want to interface to lua, opencl, or even inline assembly, then you can do it with ease
OK, but what if I want to embed Lua in my C++ program, so that I can provide my users with an extension language? What if I want to write Lua code, have it translated to C++ and then compiled by my C++ compiler?
For what it's worth, it is possible to write inline assembly using non-standard extensions in some high-level languages. As for opencl, note that parallel computing in high level languages is not exactly novel -- side-effect free programs have a long history of automatic parallelization.
Just try doing GPGPU programming in a those languages you list
Really, there is nothing special about C or C++ that makes it better suited for parallel programming than any other general-purpose language. CUDA being written in C++ has nothing to do with any sort of technical advantage C++ has; C++ is well known among Nvidia's target market and the OSes that Nvidia targeted have C or C++ APIs. If we still had Lisp machines and Nvidia was targeting those, Cuda would have been written in Lisp. If the API for Linux were in ocaml, Cuda would have been written in ocaml.
If speed is an issue your application is going to fail, when your competitor figures out how to use a GPU to solve a problem at 10x the rate of a CPU
Well, we've seen that situation before. Orbitz was competing against hand-optimized and tuned code running on mainframes, which have lots
Most High Level Languages don't like it when a pointer is set to ZERO (aka NULL), yet there are some situations where that is a valid pointer, typically in the kernel
Like I said, there are better low-level languages than C, but that aside, where did you get the idea that there is no way to deal with such a thing in a high-level language? There have been kernels written in Ada and Lisp. The only difference is that in a high-level language, you need to be very explicit about the fact that you want to use a numeric value as a pointer to be dereferenced. The Lisp compiler I use, for example, would allow an address "0" to be specified like this:
(sb-sys:int-sap 0) ; Specifies address 0
; Here, we copy the value of the variable "interrupt-assignment" to address 0 (setf (sb-sys:sap-ref-32 (sb-sys:int-sap 0) 0) interrupt-assignment)
...and there is no reason why a similar facility could not be added to any other high-level language. It looks ugly, but that is OK -- Lisp lets you write macros to change the syntax of the language, so in theory, a set of macros for dealing with low-level pointers could be created. There is no reason that such a facility could not be created in any other language that lacks pointers.
This is not to say that you are going to start writing Linux kernel modules in Lisp. I doubt that you'll see many Lisp OSes going forward, but the facility mentioned above is not very hard to write for a high-level language. The advantage is in dependability -- there are fewer ways for this code to do something unexpected than there are in C, especially as the size of the codebase increases (since you would not be using such low level pointers everywhere, there would be fewer ways for a bug to corrupt things). As for speed, here is how SBCL compiles a function that uses this facility (with type hinting):
; disassembly for SAP-TEST ; 0ABECB9A: C1FA02 SAR EDX, 2 ; no-arg-parsing entry point ; 9D: 8B12 MOV EDX, [EDX] ; 9F: C1E202 SHL EDX, 2 ; A2: 8BE5 MOV ESP, EBP ; A4: F8 CLC ; A5: 5D POP EBP ; A6: C3 RET
Not so slow. In fact, most of what that disassembly is doing is converting from/to "fixnum" types (which use low-order bits as flags); this could be further improved by using the facility exclusively, rather than using fixnum types, and thus avoiding the conversions entirely.
Language developers have tried to lock down languages, eliminating ambiguities only to have those language relegated to small niches in the market since they are not flexible enough for most application development
What are you talking about? Do you think SPARK, the well-defined subset of Ada developed by Praxis HIS, is limited to any particular market? Do you think Lisp is? Haskell? ML?
Yes, there are high-level languages that are limited in scope. Prolog, for example, is limited to a particular subset of problems. Yet for the most part, high level languages can either do everything C/C++ can do, or else can do everything C/C++ can do if there is some small extension similar to the one I mentioned above (and really, that extension involves three special forms: one to create a pointer, one to dereference a pointer, and one to compare pointers for equality).
On the other hand, C and C++ are limited by their own inflexibility and lack of high-level features. Try writing a REPL for C++, and see how well that works for you. Try writing something like CL-PPCRE -- a library which reads a regular expression, then compiles a function that matches that expression without having to traverse an expensive pointer structure (the way the C implementation
The complexity of a program should be proportional to the scale of the problem that it solves. Take a look at how complex the "Hello world" program is in Java -- there is no excuse for that mess.
some type of design pattern to elegantly solve a problem
Except that OO design patterns do not elegantly solve problems. OO design problems make up for the inelegance of OO solutions to certain problems, or deficiencies that are common in OO languages. Examples:
"Iterator pattern" -- meant to make iterating over an OO data structure simpler, but iteration is inelegant on its own. If you need to traverse a list, use tail recursion. If you are applying iterators to arrays, you need your head checked. If you need an iterator to examine all key/value pairs in a map, you are using a language for which maps are not a built-in type, and so your iterators are just a way to cover up for a deficient language.
"Command pattern" -- meant to encapsulate a function in an object, so that it can be called later. Of course, this is nothing more than a lexical closure, and unsurprisingly, C++ and Java now have lexical closures (but closures in C++ are just as ugly as the command pattern itself, so I have to wonder why the standards committee even bothered).
"Visitor pattern" -- meant to allow new operations to be added to a class hierarchy without forcing the hierarchy to be changed. Except that this is nothing more than an obscure way to implement multiple dispatch, and so the visitor pattern is worthless in languages that support multiple dispatch. The visitor pattern also makes your life harder if you need to change the hierarchy that your operations are being applied to.
What clicks off in my head is that when you're copying and pasting so much, someone probably already wrote a library for what you were trying to do
Or you are doing something that your language doesn't properly capture. There is lots of duplicated code in a visitor pattern.
OO is a byproduct of merging human conceptualization and computer language
Not any better than procedural or functional programming does (and functional programming may even do a little better here). Now, constraint programming does a great job of merging human conceptualization with computer programming -- you give the system facts and rules, then ask it a question.
It becomes more "natural", arguably, for a developer to understand
Only if the developer has received lots of training in how to think about OO designs and what the good OO design patterns are. Language oriented programming does a much better job of making the interface to a system "natural" for the programmer -- the interface is a DSL (which is embedded in the general purpose language that the system is written in; think Lisp macros). If you needed to perform some numeric computations, would you rather learn the interfaces for a bunch of classes, or just a small language for numeric computations (hopefully one which "looks like" the syntax in a typical math textbook)? Which do you think would be less effort?
OO is useful as a programming paradigm in the same way that LOC is useful for measuring programmer work. Sure, you can point out cases where LOC is an accurate metric of programmer performance; yet in reality, LOC is only one dimension, and sometimes LOC is utterly worthless as a metric. So it is with OO -- it is sometimes very useful on its own, sometimes completely worthless, and usually it is applied as just one technique in a large codebase.
Ironically, though, the programming language he developed gets nothing but ridicule from the majority of programmers (what is even more ironic is that a large number of those programmers rely on language features that were first implement in Lisp).
Languages like C and C++ will never go the way of the Dodo as they fill an area of computing that no other language has been capable of achieving nearly as well
What would that niche be, exactly? Time and time again I hear people say that C or C++ is the best language for some situation, but I am not really sure what that situation is. There are low-level languages that do not have so many kinds of undefined behavior and which are easier to formally analyze. There are certainly high-level languages that beat C and C++. CL-PPCRE is twice as fast as libpcre, and high level languages are being used in demanding environments where speed, reliability, and optimal solutions are required (Orbitz, Galois inc., various banking and investment companies' analysis tools, DART, etc.).
So what is that compelling reason to keep writing C and C++ code? Legacy code is all that comes to mind, and all it will take is a major shift in how computers are used to wipe away most of that legacy code. There is a reason that most software is not written in assembly language (and outside of a few very specific cases, hand-rolled assembly tends to be slower than what a compiler produces). That is the same reason that C and C++ will be in the same bucket as COBOL in the future. It is going to be far too difficult to use C, C++, Java, etc. express solutions to the big software problems we'll be solving over the next decade, and it is going to be even harder to express efficient solutions to those problems (in both the running time and optimal solution sense).
What you are saying, then, is that beginners should use a language that supports a REPL? Great! Now if we would just stop teaching Java to CS101 students...
I did not grow up as a geek spending all my free time pouring over computer stuff. I have never found Java difficult and I have never understood complaints to that end.
Try writing a Java program that solves this problem:
And finally, consider what else you might be able to do quickly and with less effort if you could embed Prolog in the general purpose language you are using (not easy to do in Java, given the lack of a useful macro system):
As to refactoring, I really don't see it makes refactoring any easier
Sometimes refactoring means changing what sort of values are returned by a function. This can lead to type bugs pretty quickly if the new type is not compatible with the old type (and sometimes, it really isn't). Type declarations can help you catch this sort of problem before it gets out of hand.
It is the lazy programmer that uses dynamic typing so he can write less source code.
Nonsense. Programmers who are prototyping a high-level algorithm (which would be most programming work in this day and age) use dynamically typed languages so that they can focus on the high level logic of what they are working on. That is a good thing, as it makes programmers overwhelmingly more productive.
Now, prototypes often wind up becoming finished products, and so what is really needed is an optional static type declaration that programmers can use to increase robustness once their are satisfied with the high level logic. That is what I personally do (in Lisp, which has less than type declarations), and I do it for the very reason you mention:
help keep your code base sane even after it has grown large and you realize some of your design decisions were wrong
I have found that that usually happens after functions and data structures have been prototyped. Of course, too many type declarations can get in the way here -- if I am refactoring something, that means I have to prototype some new function or data structure, which means I want dynamic typing there until I am done refactoring (but static typing elsewhere, so that I know what else will need to change). This is one of those cases where "best of both worlds" would be great (but I am not familiar with languages that actually allow it -- Common Lisp comes close with type hints, but something that is better enforced would be nice).
I can't see how a better language would deal with not having to put in a particular pattern.
Actually, there are a number of design patterns that exist solely to deal with deficiencies in languages. The pattern to comes to mind for me is the Visitor pattern -- it is basically pointless in a language that has multiple dispatch.
Exceptions are intended to be used when a program hits unexpected or fatal issues which cannot be handled locally
According to whom? I see exceptions being used for correctable errors all the time; here, for example, is an exception that is thrown for a correctable error, in Java:
Yes, this is a correctable error: if you can ask the user to fix this problem, you can continue from some point defined by the thrower of the exception (perhaps retrying the sync operation). Of course, Java does not support such a thing; however, this is a thread about language deficiencies!
If I'm just copying a large directory structure then I can reasonably expect to not be able to open a few files due to permissions and, while I'll likely want to log these and display them, treating it as an exception wouldn't be suitable
Why is that not suitable? I'll have my exception handler log the exception, then I will try to open the next file in the list. You do not even require restarts here; in Java, this amounts to placing a try...catch in the body of a loop.
Ultimately though for this type of 'It could be serious, it could be nothing' then the decision should be left to the client code rather than the library.
You forgot, "This is serious, but it can be corrected." Running out of space on a hard drive, a thumb drive being removed while it is being read, etc. Without a good exception/restart system (or continuations if you want to be more functional), your client code winds up being far more complex (think about how you would deal with a thumb drive being removed while some records are being written if you do not have a restart mechanism -- now imagine if your catch block could say, "Retry the operation" and if the exception is not thrown again, your code continues as if no exception was ever thrown).
The problem with exceptions in most of today's popular languages is that they do not merely signal an error; they also destroy the entire call stack from where the exception was thrown to where it is caught. A better approach, at least in my opinion, is for the exception propagation to leave the stack intact until the end of the exception handler. This would allow the exception handler to invoke a restart, which can be viewed as a "dual" of an exception: a restart would cause control flow to switch to some point defined by the thrower, and would invalidate the stack of the exception handler (and the program can then continue as if there had never been an exception, except for whatever side effects the exception handler has).
I would argue needing a debugger is also a sign of language flaws.
I agree, but for a different reason. A good language is one in which debugging means finding logical flaws in the design of a program; no language can truly achieve this ideal, but some languages come closer than others. I do not think we will ever get rid of debuggers; I think debugging will change, though, when languages like C and C++ go the way of the dodo.
Here, for example, is a tool that helps with debugging high level logic:
Give it a try some time; you'd be surprised by how effectively it can find bugs in designs, and by how effectively it can convey what those bugs are. This is the sort of debugging we will need going forward -- not debugging mechanics, but debugging high level logic. Knight Capital didn't go bankrupt because of a null pointer.
How on earth are you supposed to keep track of the several thousand files?
With a directory hierarchy?
When I work on projects I like to keep the entire architecture and structure in my head
If you can do this, then what is your IDE doing for you?
I use the intellisense system to find for me the proper class. I am not talking about documentation as that goes without saying. I am talking about using a naming convention so that you can easily find functionality.
You use a system to find the proper class, but you also have a naming convention to make that easy? Why not just use grep -rl "class SomeUsefulClassName {" (or whatever your preferred curly brace placement is)?
If I have to keep track of every method name, and its parameters then I am definitely wasting time on stuff that does not need thinking about.
See, now you are finally talking about something that an IDE can help with. Why even bother with the other stuff? You need a system that shows you the interface of a class and what parameters the methods take, and most IDEs will have that in one form or another.
My own take on IDEs is this: their utility is inversely proportional to the power of the language. Thus a C++ or Java IDE is absolutely necessary, whereas a Lisp IDE is just nice to have available. In a language where you are able to redefine methods or classes at runtime, where getting a REPL is easy, where you have the ability to change the way method calls are dispatched, and so forth, the number of useful things an IDE does is dramatically reduced. Sure, I use SLIME in my day-to-day work, but if for some reason I couldn't use SLIME I would still be OK.
You cannot separate the technical details from the economic details. Imagine, for example, a technical specification that separates nodes into "consumer" and "service" systems; it is almost certain that ISPs would enforce the distinction between clients and servers, charging large amounts of money for connecting a "service" node to the network.
Now, would ITU actually do such a thing? Probably. In fact, almost certainly. That sort of distinction can be seen in numerous other ITU standards and proposals. Take a look at NGN some time...
I suspect this system will see more subtle use. I suspect that this system will be deployed within corporations, and used to detect employees who are not satisfied with their treatment. Those employees will either be fired or promoted (to divide them from their peers and prevent them from organizing people). The purpose of a system like this is to enforce the social order, to prevent change, and to ensure those who are in power will remain in power.
Slashdot Mirror
You are an individual. Your rights are irrelevant if a corporation might lose money when your rights an enforced. Well, only those corporations that have friends in high places, like movie studios. Actually, it's just turtles all the way down, by which I mean corrupt major party politicians all the way up.
Not just for that copy, but also for every subsequent copy of that copy. For example, the copy Netflix sends me when I stream a movie (yes, it is a copy, in a technical sense). Or the copy Comcast sends when I watch cable.
The real answer is, "The government's argument only applies to real, individual people. Fake persons who are really groups of wealthy people (some called these organizations corporations) will have their rights enforced at the expensive of the citizens of the US or any other country."
The MPAA's members upload movies to "the cloud" all the time, so I guess their "property" rights are forfeited! Hooray!
After all, this will clearly be a deterrent. Or he clearly caused millions of dollars in damage while he was playing with himself. Or something like that. Logic is not actually relevant when it comes to copyrights.
I understand how a hand count works. I have no idea how most voting machines work, because their designs are secret. We can talk about standards after we get access to source code and design documents.
C++ lacking in expressiveness? You have got to be joking,
Well, how might you add "operator#" to C++? Adding new language features to C++ basically requires a new C++ compiler; lexical closures, for example, only became possible with C++11 (previously, Boost's lambda expressions library got you halfway there). That is a result of a lack of expressive power.
your right there are a lot of poorly defined areas in C++, but many of them stem from the fact that there are 100 different ways syntactically to solve any given problem.
It is mostly due to the standard being written for compiler writers and language implementors, rather than for programmers.
Of course some ways tend to be better than others, hence I'm confused about your problems with constructor error handling. You handle errors in constructors with "throw", combined with good RAII style, you get the benefit of fast code, that is robust to memory errors
Except when your objects are global, in which case throwing the exception means your program aborts, since there is no standard way to write a global catch (set_terminate won't work if the exception is thrown before the entry to main -- which is what will happen if the constructor of a global object throws the exception).
Destructors aren't as clear cut, but the easy answer is not to have fatal errors in the destructor
In other words, destructors should have trivial bodies. Why even have destructors if that is how things have to be done?
One of C++'s strong points (vs C) is that you can create a domain specific environment by careful class design and operator overloading
Unless you want to add a new kind of operator or a new kind of syntax.
As far as debug-ability, or a programmers ability to focus on the problem at had rather than the language, I suspect that is all just a matter of experience.
In a lot of languages you learn how to do things, in C++ you tend to learn how _NOT_ to do things
Which is precisely the problem here. In C++, you need to know what valid C++ expressions, statements, or programs should simply not be written. Rather than rule such things out in C++11, the standards committee just added more things that you are supposed to know not to do.
Those results have re2, and it beats all the normal regular expression parsers only loosing to a lisp specific parsing/matching system. I don't call that a win for LISP, if you move the goal posts (we were comparing regex) then its not apples to apples. Its not hard to imaging a dozen ways of creating a searching sorting system faster than regex if your willing to wiggle the requirements.
Like I said, this is not a good benchmark; on the other hand, RE2 is not average twice the speed of libpcre (unless you count an outlier):
http://lh3lh3.users.sourceforge.net/reb.shtml
CL-PPCRE does average twice the speed of libpcre/Perl (unless you pick examples that libpcre can handle well):
http://cl-debian.alioth.debian.org/repository/rvb/cl-ppcre-sarge/doc/#bench
I would not draw too many conclusions from the benchmarks alone (there is no direct comparison between CL-PPCRE and RE2), but CL-PPCRE does do something that neither libpcre nor RE2 do: it compiles your regex into a callable function that does not traverse a pointer structure. With a good compiler (n
Namely because no matter what language you use, you'll end up with those kinds of issues in some form
Except that in some languages, those issues are rare. The only time I have seen a Lisp program corrupt its heap (through the equivalent of a dangling pointer) was when I explicitly disabled safety features. In C and C++, on the other hand, dangling pointers are a common and routine source of problems; in C++ especially, dangling pointers tend to creep up in all sorts of unexpected ways.
That is why I said programmers will not get bogged down with these problems -- these sorts of things are sufficiently rare in high level languages that many programmers will not see them.
You can interface any language to any OS regardless of the API and documentation
Only if your language has a suitable FFI or if interfacing with an OS is actually a language feature. Some high level languages do not have such an FFI, and in many high level languages the FFI is cumbersome to use. OS documentation usually assumes the programmer will be using the same language that the API is written for (nothing else would make sense), which adds yet another hurdle for programmers using another language.
I am not saying that it is impossible, I am saying that it is harder to do and that there is an advantage to using the same language that the OS was written in. OSes have been written in Lisp in the past -- and unsurprisingly, most of the applications for those OSes was also written in Lisp (as opposed to some ML, Ada, or C++).
The reason that C and C++ continue to be popular - even in the face of C# and Java - is that they enable the programmer to actually get their tasks done because of how flexible the language is. What language fix-its call ambiguities are actually strengths for C and C++.
Except that C++ doesn't limit undefined behavior to situations that make sense -- for example, converting from a numeric type to a pointer type (this may not make sense on all architectures, but it does make sense on some). In C++, you have undefined behavior that could not possibly make sense no matter what architecture you are using. In what system does it make sense to allow control flow to reach the of a non-void function? In what system does it make sense to allow a reference (which cannot be reassigned) to a local variable to be returned from a function? These are things that could have been forbidden by the language definition; instead, it is up to compiler writers to decide what to do, and the fact that pretty much every compiler has had non-standard features for detecting / rejecting such things had no impact on the C++11 standard.
These are not features that add to the flexibility of C++; they are just traps waiting to ensnare novice programmers.
It is hard to argue that C++ is a flexible language when you need a new compiler just to add a feature like lexical closures. If you want metaobject protocol, continuations, or other language features, you are either stuck with some clunky, brittle, and inefficient version using templates and operator overloading or else you are going to need a new compiler (and then you can forget portability).
C, and its extentions C++ and object-C, have withstood history because they have met and exceeded their target goals.
First of all, C and C++ have both been updated several times in order to remain relevant. Second, saying that C exceeded the goals that its designers had in mind is not saying much -- the original Unix is not very impressive, even by the standard of the 1970s. Neither is saying that C++ exceeded its designer's goal: C with objected oriented features (that goal was expanded to "a language that is relevant" -- and C++ has not exceeded that goal, it has only met it adequately for most programmers).
As for objective C, it was hardly a blip on the radar until Apple gave it a boost. Hardly
I think you fail to understand how adaptable C and C++ is
I don't. My first programming language was C++, and I programmed in C++ professionally. C++ is severely lacking in expressiveness, and there is an abundance of undefined behavior in C++. Debugging a C++ program is as much about low-level program mechanics as it is about high-level logic (even when you are writing a high level application). Dealing with errors in C++ is a giant ball of confusion -- there isn't even a good way to deal with errors that occur in constructors or destructors.
C++ is surviving because of its history -- a lot of C++ code was written in the 90s, and nobody has the time to rewrite any of it (not even to get it up to date with modern C++ standards -- I was once on a project that had to use a subset of C++ in order to maintain compatibility with old compilers from the early 90s). Schools keep teaching C++ because they believe their job is to prepare students for jobs in industry where they will be writing C++ code, which helps to keep C++ afloat by training programmers to think in C++. There is no real technical advantage that C++ has -- none of its features are unique, nor is the combination of its features -- and it carries plenty of technical disadvantages compared to other languages.
The strong point isn't how great it is at any given benchmark, but rather how good it is for solving a whole range of different problems
There are other languages that are good at solving problems in that range, which do not have C++'s deficiencies. If you are writing low-level code, do you really want to be dealing with implicit function calls? If you are writing high-level code, do you really want to spend your time deciding between shared_ptr and weak_ptr? If lives depend on your code, do you really want to have no idea about the order in which functions will be called?
If your OS provides mmap and its 10x faster than doing read/write style ops then you have that choice
What makes C/C++ special here? A typical FFI in a high level language let's you call functions in shared libraries (and by extension, functions that your OS provides), and many implementations of high-level languages have (non-portable) extensions for a particular target OS.
If you want to interface to lua, opencl, or even inline assembly, then you can do it with ease
OK, but what if I want to embed Lua in my C++ program, so that I can provide my users with an extension language? What if I want to write Lua code, have it translated to C++ and then compiled by my C++ compiler?
For what it's worth, it is possible to write inline assembly using non-standard extensions in some high-level languages. As for opencl, note that parallel computing in high level languages is not exactly novel -- side-effect free programs have a long history of automatic parallelization.
Just try doing GPGPU programming in a those languages you list
Sure:
http://www.cliki.net/cl-gpu
Really, there is nothing special about C or C++ that makes it better suited for parallel programming than any other general-purpose language. CUDA being written in C++ has nothing to do with any sort of technical advantage C++ has; C++ is well known among Nvidia's target market and the OSes that Nvidia targeted have C or C++ APIs. If we still had Lisp machines and Nvidia was targeting those, Cuda would have been written in Lisp. If the API for Linux were in ocaml, Cuda would have been written in ocaml.
If speed is an issue your application is going to fail, when your competitor figures out how to use a GPU to solve a problem at 10x the rate of a CPU
Well, we've seen that situation before. Orbitz was competing against hand-optimized and tuned code running on mainframes, which have lots
Most High Level Languages don't like it when a pointer is set to ZERO (aka NULL), yet there are some situations where that is a valid pointer, typically in the kernel
Like I said, there are better low-level languages than C, but that aside, where did you get the idea that there is no way to deal with such a thing in a high-level language? There have been kernels written in Ada and Lisp. The only difference is that in a high-level language, you need to be very explicit about the fact that you want to use a numeric value as a pointer to be dereferenced. The Lisp compiler I use, for example, would allow an address "0" to be specified like this:
This is not to say that you are going to start writing Linux kernel modules in Lisp. I doubt that you'll see many Lisp OSes going forward, but the facility mentioned above is not very hard to write for a high-level language. The advantage is in dependability -- there are fewer ways for this code to do something unexpected than there are in C, especially as the size of the codebase increases (since you would not be using such low level pointers everywhere, there would be fewer ways for a bug to corrupt things). As for speed, here is how SBCL compiles a function that uses this facility (with type hinting):
Not so slow. In fact, most of what that disassembly is doing is converting from/to "fixnum" types (which use low-order bits as flags); this could be further improved by using the facility exclusively, rather than using fixnum types, and thus avoiding the conversions entirely.
Language developers have tried to lock down languages, eliminating ambiguities only to have those language relegated to small niches in the market since they are not flexible enough for most application development
What are you talking about? Do you think SPARK, the well-defined subset of Ada developed by Praxis HIS, is limited to any particular market? Do you think Lisp is? Haskell? ML?
Yes, there are high-level languages that are limited in scope. Prolog, for example, is limited to a particular subset of problems. Yet for the most part, high level languages can either do everything C/C++ can do, or else can do everything C/C++ can do if there is some small extension similar to the one I mentioned above (and really, that extension involves three special forms: one to create a pointer, one to dereference a pointer, and one to compare pointers for equality).
On the other hand, C and C++ are limited by their own inflexibility and lack of high-level features. Try writing a REPL for C++, and see how well that works for you. Try writing something like CL-PPCRE -- a library which reads a regular expression, then compiles a function that matches that expression without having to traverse an expensive pointer structure (the way the C implementation
There's reasons for the complexity
The complexity of a program should be proportional to the scale of the problem that it solves. Take a look at how complex the "Hello world" program is in Java -- there is no excuse for that mess.
some type of design pattern to elegantly solve a problem
Except that OO design patterns do not elegantly solve problems. OO design problems make up for the inelegance of OO solutions to certain problems, or deficiencies that are common in OO languages. Examples:
What clicks off in my head is that when you're copying and pasting so much, someone probably already wrote a library for what you were trying to do
Or you are doing something that your language doesn't properly capture. There is lots of duplicated code in a visitor pattern.
OO is a byproduct of merging human conceptualization and computer language
Not any better than procedural or functional programming does (and functional programming may even do a little better here). Now, constraint programming does a great job of merging human conceptualization with computer programming -- you give the system facts and rules, then ask it a question.
It becomes more "natural", arguably, for a developer to understand
Only if the developer has received lots of training in how to think about OO designs and what the good OO design patterns are. Language oriented programming does a much better job of making the interface to a system "natural" for the programmer -- the interface is a DSL (which is embedded in the general purpose language that the system is written in; think Lisp macros). If you needed to perform some numeric computations, would you rather learn the interfaces for a bunch of classes, or just a small language for numeric computations (hopefully one which "looks like" the syntax in a typical math textbook)? Which do you think would be less effort?
OO is useful as a programming paradigm in the same way that LOC is useful for measuring programmer work. Sure, you can point out cases where LOC is an accurate metric of programmer performance; yet in reality, LOC is only one dimension, and sometimes LOC is utterly worthless as a metric. So it is with OO -- it is sometimes very useful on its own, sometimes completely worthless, and usually it is applied as just one technique in a large codebase.
Ironically, though, the programming language he developed gets nothing but ridicule from the majority of programmers (what is even more ironic is that a large number of those programmers rely on language features that were first implement in Lisp).
Languages like C and C++ will never go the way of the Dodo as they fill an area of computing that no other language has been capable of achieving nearly as well
What would that niche be, exactly? Time and time again I hear people say that C or C++ is the best language for some situation, but I am not really sure what that situation is. There are low-level languages that do not have so many kinds of undefined behavior and which are easier to formally analyze. There are certainly high-level languages that beat C and C++. CL-PPCRE is twice as fast as libpcre, and high level languages are being used in demanding environments where speed, reliability, and optimal solutions are required (Orbitz, Galois inc., various banking and investment companies' analysis tools, DART, etc.).
So what is that compelling reason to keep writing C and C++ code? Legacy code is all that comes to mind, and all it will take is a major shift in how computers are used to wipe away most of that legacy code. There is a reason that most software is not written in assembly language (and outside of a few very specific cases, hand-rolled assembly tends to be slower than what a compiler produces). That is the same reason that C and C++ will be in the same bucket as COBOL in the future. It is going to be far too difficult to use C, C++, Java, etc. express solutions to the big software problems we'll be solving over the next decade, and it is going to be even harder to express efficient solutions to those problems (in both the running time and optimal solution sense).
Ignore all the morons who think we should all still be digging holes with spoons instead of power equipment.
OK, OK, fine, if you write your Java code in an IDE, you are digging with a bunch of spoons that you welded onto a backhoe.
Instant feedback for programming errors is great
What you are saying, then, is that beginners should use a language that supports a REPL? Great! Now if we would just stop teaching Java to CS101 students...
I did not grow up as a geek spending all my free time pouring over computer stuff. I have never found Java difficult and I have never understood complaints to that end.
Try writing a Java program that solves this problem:
https://en.wikipedia.org/wiki/Nurse_scheduling_problem
Then, compare that to the effort needed to solve that problem using Prolog:
http://www.ncbi.nlm.nih.gov/pubmed/3345653
And finally, consider what else you might be able to do quickly and with less effort if you could embed Prolog in the general purpose language you are using (not easy to do in Java, given the lack of a useful macro system):
http://pseudofish.com/blog/2011/08/05/prolog-in-clojure/
As to refactoring, I really don't see it makes refactoring any easier
Sometimes refactoring means changing what sort of values are returned by a function. This can lead to type bugs pretty quickly if the new type is not compatible with the old type (and sometimes, it really isn't). Type declarations can help you catch this sort of problem before it gets out of hand.
It is the lazy programmer that uses dynamic typing so he can write less source code.
Nonsense. Programmers who are prototyping a high-level algorithm (which would be most programming work in this day and age) use dynamically typed languages so that they can focus on the high level logic of what they are working on. That is a good thing, as it makes programmers overwhelmingly more productive.
Now, prototypes often wind up becoming finished products, and so what is really needed is an optional static type declaration that programmers can use to increase robustness once their are satisfied with the high level logic. That is what I personally do (in Lisp, which has less than type declarations), and I do it for the very reason you mention:
help keep your code base sane even after it has grown large and you realize some of your design decisions were wrong
I have found that that usually happens after functions and data structures have been prototyped. Of course, too many type declarations can get in the way here -- if I am refactoring something, that means I have to prototype some new function or data structure, which means I want dynamic typing there until I am done refactoring (but static typing elsewhere, so that I know what else will need to change). This is one of those cases where "best of both worlds" would be great (but I am not familiar with languages that actually allow it -- Common Lisp comes close with type hints, but something that is better enforced would be nice).
Sure, but some of the things that would make Java a better language, the lack of which necessitates an IDE, are already available in other languages.
I can't see how a better language would deal with not having to put in a particular pattern.
Actually, there are a number of design patterns that exist solely to deal with deficiencies in languages. The pattern to comes to mind for me is the Visitor pattern -- it is basically pointless in a language that has multiple dispatch.
Exceptions are intended to be used when a program hits unexpected or fatal issues which cannot be handled locally
According to whom? I see exceptions being used for correctable errors all the time; here, for example, is an exception that is thrown for a correctable error, in Java:
http://docs.oracle.com/javase/7/docs/api/java/io/SyncFailedException.html
Yes, this is a correctable error: if you can ask the user to fix this problem, you can continue from some point defined by the thrower of the exception (perhaps retrying the sync operation). Of course, Java does not support such a thing; however, this is a thread about language deficiencies!
If I'm just copying a large directory structure then I can reasonably expect to not be able to open a few files due to permissions and, while I'll likely want to log these and display them, treating it as an exception wouldn't be suitable
Why is that not suitable? I'll have my exception handler log the exception, then I will try to open the next file in the list. You do not even require restarts here; in Java, this amounts to placing a try...catch in the body of a loop.
Ultimately though for this type of 'It could be serious, it could be nothing' then the decision should be left to the client code rather than the library.
You forgot, "This is serious, but it can be corrected." Running out of space on a hard drive, a thumb drive being removed while it is being read, etc. Without a good exception/restart system (or continuations if you want to be more functional), your client code winds up being far more complex (think about how you would deal with a thumb drive being removed while some records are being written if you do not have a restart mechanism -- now imagine if your catch block could say, "Retry the operation" and if the exception is not thrown again, your code continues as if no exception was ever thrown).
The problem with exceptions in most of today's popular languages is that they do not merely signal an error; they also destroy the entire call stack from where the exception was thrown to where it is caught. A better approach, at least in my opinion, is for the exception propagation to leave the stack intact until the end of the exception handler. This would allow the exception handler to invoke a restart, which can be viewed as a "dual" of an exception: a restart would cause control flow to switch to some point defined by the thrower, and would invalidate the stack of the exception handler (and the program can then continue as if there had never been an exception, except for whatever side effects the exception handler has).
I would argue needing a debugger is also a sign of language flaws.
I agree, but for a different reason. A good language is one in which debugging means finding logical flaws in the design of a program; no language can truly achieve this ideal, but some languages come closer than others. I do not think we will ever get rid of debuggers; I think debugging will change, though, when languages like C and C++ go the way of the dodo.
Here, for example, is a tool that helps with debugging high level logic:
http://alloy.mit.edu/alloy/
Give it a try some time; you'd be surprised by how effectively it can find bugs in designs, and by how effectively it can convey what those bugs are. This is the sort of debugging we will need going forward -- not debugging mechanics, but debugging high level logic. Knight Capital didn't go bankrupt because of a null pointer.
How on earth are you supposed to keep track of the several thousand files?
With a directory hierarchy?
When I work on projects I like to keep the entire architecture and structure in my head
If you can do this, then what is your IDE doing for you?
I use the intellisense system to find for me the proper class. I am not talking about documentation as that goes without saying. I am talking about using a naming convention so that you can easily find functionality.
You use a system to find the proper class, but you also have a naming convention to make that easy? Why not just use grep -rl "class SomeUsefulClassName {" (or whatever your preferred curly brace placement is)?
If I have to keep track of every method name, and its parameters then I am definitely wasting time on stuff that does not need thinking about.
See, now you are finally talking about something that an IDE can help with. Why even bother with the other stuff? You need a system that shows you the interface of a class and what parameters the methods take, and most IDEs will have that in one form or another.
My own take on IDEs is this: their utility is inversely proportional to the power of the language. Thus a C++ or Java IDE is absolutely necessary, whereas a Lisp IDE is just nice to have available. In a language where you are able to redefine methods or classes at runtime, where getting a REPL is easy, where you have the ability to change the way method calls are dispatched, and so forth, the number of useful things an IDE does is dramatically reduced. Sure, I use SLIME in my day-to-day work, but if for some reason I couldn't use SLIME I would still be OK.
You cannot separate the technical details from the economic details. Imagine, for example, a technical specification that separates nodes into "consumer" and "service" systems; it is almost certain that ISPs would enforce the distinction between clients and servers, charging large amounts of money for connecting a "service" node to the network.
Now, would ITU actually do such a thing? Probably. In fact, almost certainly. That sort of distinction can be seen in numerous other ITU standards and proposals. Take a look at NGN some time...
You need not look any further than X.25 to see what sort of provisions the ITU would try to work into future Internet protocols.
I suspect this system will see more subtle use. I suspect that this system will be deployed within corporations, and used to detect employees who are not satisfied with their treatment. Those employees will either be fired or promoted (to divide them from their peers and prevent them from organizing people). The purpose of a system like this is to enforce the social order, to prevent change, and to ensure those who are in power will remain in power.