He thinks that just because an implementation could read from a counter variable to provide an O(1) answer that the counter existing makes it thread-safe to perform counted operations upon the container. Concurrency is a pretty difficult concept when you're first getting introduced to it.
I'm sorry but caching the size of the list is a cost you add to EACH add or delete operation on the list and it is not always appropriate to need to know the size of a list beforehand and so to spend the extra computational resources on maintaining size counters on linked lists as a default is quite silly. To expect it is equally silly. You don't need to pessimize most applications just to optimize some of them. It really is trivial to make sure each access to a linked list object is done through an object that handles the counting.
That's a very good point. I have gained a much greater appreciation of C++ over time for how well it supports many different programming methodologies, including even functional.
That's really just your lack of experience with object persistence frameworks. Yes, each framework has some boilerplate -- register your specialized type with the system so that it unmarshals into the specific object type you want, rather than just one that contains that JavaBean boilerplate. Then you can go ahead and implement any specialized, non-Bean methods that you like on those objects. Your only limitation is that, yes, you must use the JavaBean style setter-and-getter or direct-member-variable-access paradigms as part of the implementation.
The other situation is where you have complex algorithms, but simple data. Signal processing, control software, scientific programming, etc.. Take a radar as an example: the data is just a continuous stream of numbers coming in off the radar dish; but the algorithms that extract meaning from those numbers are very sophisticated. Using an OO language for problems like this is like trying to loosen a screw using a wrench - maybe you can make it work, but it's basically a really bad fit for the problem.
I currently work for an aerospace company doing (satellite) ground systems. Object Oriented Programming is nothing but a boon for implementing every facet of this kind of software. Legacy C software not using objects for pure DATA alone causes tons of problems, because you really don't need to care about the implementation details except C forces you to. If I don't want to create a number of new object types for a software project, I don't. In fact, if you are talking C++ specifically, having access to the STL mostly eliminates having to write your own fundamental data structures for any type of data, so I spend even less time and space on boilerplate and more on implementing specific algorithms that work with my data types.
You're truly not giving Java enough credit. It is never good to learn from only one example but it can be used to teach compiler theory and assembly, as it is a bytecode VM, and DOES expose very low-level language details: you can freely use native types, even though they are awkward compared to objects. One of the best features is all of the threading and synchronization primitives you need at a low level are part of the language itself. So what if it doesn't compile to machine code?
I know, I fell in love with Ruby many years ago and I still enjoy its expressiveness and ability to let me complete an entire project rapidly. I still use it when I can do something completely stand-alone that has no performance impact on anything, but it isn't something we've adopted at work or anything, officially, as we have Java and C++. There's also plenty of entrenched C, and fellow developers know most old C is a bear compared to something modern, streamlined and extensively-peer-reviewed like an open source OS... but that was my first experience with good code and so I am utterly comfortable with only C and no OO capabilities, as well, but there is zero impetus for doing straight C over C++ outside of OS kernels.
I do know what I enjoy working with the most. It's not all of the bizarre choices of syntax and convolution, but powerful and low-level language feature base of C++, and perhaps not Java's ultra-stringency (although not having to double-declare prototypes is wonderful, and Eclipse does make building the program scaffolding up from scratch a breeze). I can be productive writing essentially the same kind of software in C++, Java or Ruby but the last decade taught me that other than possible ridiculous amounts of boilerplate (*cough* headers for languages in the C lineage), the choice of platform is not going to end up altering the amount of time it takes to do the project other than that portion.
I look at these examples and I do appreciate the visible elegance of more compact and expressive languages. But I also don't see any reason to not use Java on the Java VM because it is extremely capable on its own and high-level enough that an IDE can truly handle ALL of the boilerplate connections for you. It's plenty readable, and plenty writable as long as you aren't sticking with old tools that don't do code-completion. I'm not going to become much more productive by having functional programming facilities, am I? I don't even have to create my interfaces ahead of time -- the IDE handles pushing method declarations out from the class to an ancestor interface with a few clicks.
It could be that while I do adore the Ruby syntax I don't see any particular reason to favor functional programming over procedural. Note that C++ actually supports functional programming perfectly well, however, most standard C++ APIs do not use that sort of convention, favoring only the procedural/class method system.
Are you kidding me by comparing C++ and Java? They're not even similar languages! VM versus machine code, GC versus low-level memory, single-inheritance and interfaces and supercalls and generics versus multiple-inheritance and templates and explicit ancestor calls.
I am still happy with Clear's service compared to other similar broadband offerings in my area, especially on the price. My phone lines are too old for DSL to be much faster than 1mbit/s and fiber is still not in my neighborhood. Comcast is expensive and has the worst customer service I ever dealt with, along with the least overall stability. I remember downtime EVERY month for many years of Comcast service in several places.
Clear gives me typical speeds of around 100kbyte/s upload and 300-1100kbyte/s peak download depending mostly on load from other users. Median is probably somewhere around 500kbyte/s. I use easily dozens and dozens of gigabytes of traffic each month, so much of the time I spend throttled at their 60kbyte/s download limit. That sucks, but I'm still spending much less on service than DSL and usually getting significantly faster speeds. I still don't think the throttling is necessary. It's more a sign of bad system/network administrators that can't handle setting up proper traffic shaping flow control.
Do you mean not drawing the story to completion in a small number of books, or leaving a series unfinished by PASSING AWAY? I don't know in what sense you meant that phrase but that's kind of offensive, isn't it?
and in the case of the "real world" you don't know if any of those are the actual case, or if in fact the poster does not understand how GPL tools work. Bundling the GPL software tools unmodified is certainly allowed, as long as you retain the original source code associated with those binaries to satisfy the GPL's requirements for being able to provide that on demand (in the case where the ORIGINAL source code for the GPL project used is no longer available, that is)
Slashdot Mirror
Then you should use the modern CRT -- the plasma screen.
Hey, the 1990s called! They wanted to ask you if they could have their views on the overwhelming expenses of implicit stream encryption back or not.
Less than 1/2 the bandwidth usage.
This made me laugh SO hard! Please buy a book on cryptosystems.
JavaScript isn't a threaded execution model.
He thinks that just because an implementation could read from a counter variable to provide an O(1) answer that the counter existing makes it thread-safe to perform counted operations upon the container. Concurrency is a pretty difficult concept when you're first getting introduced to it.
I'm sorry but caching the size of the list is a cost you add to EACH add or delete operation on the list and it is not always appropriate to need to know the size of a list beforehand and so to spend the extra computational resources on maintaining size counters on linked lists as a default is quite silly. To expect it is equally silly. You don't need to pessimize most applications just to optimize some of them. It really is trivial to make sure each access to a linked list object is done through an object that handles the counting.
If you don't think that developers do engineering, then you truly do not know what software is, young one.
That's a very good point. I have gained a much greater appreciation of C++ over time for how well it supports many different programming methodologies, including even functional.
That's really just your lack of experience with object persistence frameworks. Yes, each framework has some boilerplate -- register your specialized type with the system so that it unmarshals into the specific object type you want, rather than just one that contains that JavaBean boilerplate. Then you can go ahead and implement any specialized, non-Bean methods that you like on those objects. Your only limitation is that, yes, you must use the JavaBean style setter-and-getter or direct-member-variable-access paradigms as part of the implementation.
You're talking about time-sharing systems.
The other situation is where you have complex algorithms, but simple data. Signal processing, control software, scientific programming, etc.. Take a radar as an example: the data is just a continuous stream of numbers coming in off the radar dish; but the algorithms that extract meaning from those numbers are very sophisticated. Using an OO language for problems like this is like trying to loosen a screw using a wrench - maybe you can make it work, but it's basically a really bad fit for the problem.
I currently work for an aerospace company doing (satellite) ground systems. Object Oriented Programming is nothing but a boon for implementing every facet of this kind of software. Legacy C software not using objects for pure DATA alone causes tons of problems, because you really don't need to care about the implementation details except C forces you to. If I don't want to create a number of new object types for a software project, I don't. In fact, if you are talking C++ specifically, having access to the STL mostly eliminates having to write your own fundamental data structures for any type of data, so I spend even less time and space on boilerplate and more on implementing specific algorithms that work with my data types.
You're truly not giving Java enough credit. It is never good to learn from only one example but it can be used to teach compiler theory and assembly, as it is a bytecode VM, and DOES expose very low-level language details: you can freely use native types, even though they are awkward compared to objects. One of the best features is all of the threading and synchronization primitives you need at a low level are part of the language itself. So what if it doesn't compile to machine code?
Of course no one "needs" OO. It merely produces superior software by permitting more powerful methodologies.
I'd go with an unlocked Samsung Nexus S.
You should upgrade your video driver to something moderately recent, probably, or Deal With It.
[citation needed]
Why traverse the stars, improve food resources, discover better sources of energy?
Yeah, the human race is clearly showing itself capable of doing that.
Or, no, wait, we're suffering food crises because we spend our lives (not money, that's just a side effect) on wars instead of global welfare.
Simp.
I know, I fell in love with Ruby many years ago and I still enjoy its expressiveness and ability to let me complete an entire project rapidly. I still use it when I can do something completely stand-alone that has no performance impact on anything, but it isn't something we've adopted at work or anything, officially, as we have Java and C++. There's also plenty of entrenched C, and fellow developers know most old C is a bear compared to something modern, streamlined and extensively-peer-reviewed like an open source OS... but that was my first experience with good code and so I am utterly comfortable with only C and no OO capabilities, as well, but there is zero impetus for doing straight C over C++ outside of OS kernels.
I do know what I enjoy working with the most. It's not all of the bizarre choices of syntax and convolution, but powerful and low-level language feature base of C++, and perhaps not Java's ultra-stringency (although not having to double-declare prototypes is wonderful, and Eclipse does make building the program scaffolding up from scratch a breeze). I can be productive writing essentially the same kind of software in C++, Java or Ruby but the last decade taught me that other than possible ridiculous amounts of boilerplate (*cough* headers for languages in the C lineage), the choice of platform is not going to end up altering the amount of time it takes to do the project other than that portion.
I look at these examples and I do appreciate the visible elegance of more compact and expressive languages. But I also don't see any reason to not use Java on the Java VM because it is extremely capable on its own and high-level enough that an IDE can truly handle ALL of the boilerplate connections for you. It's plenty readable, and plenty writable as long as you aren't sticking with old tools that don't do code-completion. I'm not going to become much more productive by having functional programming facilities, am I? I don't even have to create my interfaces ahead of time -- the IDE handles pushing method declarations out from the class to an ancestor interface with a few clicks.
It could be that while I do adore the Ruby syntax I don't see any particular reason to favor functional programming over procedural. Note that C++ actually supports functional programming perfectly well, however, most standard C++ APIs do not use that sort of convention, favoring only the procedural/class method system.
Are you kidding me by comparing C++ and Java? They're not even similar languages! VM versus machine code, GC versus low-level memory, single-inheritance and interfaces and supercalls and generics versus multiple-inheritance and templates and explicit ancestor calls.
Yes, the syntax is also not the same. Poignant.
Awesome post. That makes perfect sense to me as a (presumably) fellow developer.
I read your idle speculation and left a more informed individual. Thank you.
I am still happy with Clear's service compared to other similar broadband offerings in my area, especially on the price. My phone lines are too old for DSL to be much faster than 1mbit/s and fiber is still not in my neighborhood. Comcast is expensive and has the worst customer service I ever dealt with, along with the least overall stability. I remember downtime EVERY month for many years of Comcast service in several places.
Clear gives me typical speeds of around 100kbyte/s upload and 300-1100kbyte/s peak download depending mostly on load from other users. Median is probably somewhere around 500kbyte/s. I use easily dozens and dozens of gigabytes of traffic each month, so much of the time I spend throttled at their 60kbyte/s download limit. That sucks, but I'm still spending much less on service than DSL and usually getting significantly faster speeds. I still don't think the throttling is necessary. It's more a sign of bad system/network administrators that can't handle setting up proper traffic shaping flow control.
Do you mean not drawing the story to completion in a small number of books, or leaving a series unfinished by PASSING AWAY? I don't know in what sense you meant that phrase but that's kind of offensive, isn't it?
That's a much more complex solution than "don't buffer so much damn stuff for no good reason."
You hopped, skipped and jumped over the "requiring".
A thousand times, this.
and in the case of the "real world" you don't know if any of those are the actual case, or if in fact the poster does not understand how GPL tools work. Bundling the GPL software tools unmodified is certainly allowed, as long as you retain the original source code associated with those binaries to satisfy the GPL's requirements for being able to provide that on demand (in the case where the ORIGINAL source code for the GPL project used is no longer available, that is)