It is NOT a super high barrier to entry in my opinion. Archive.org only has like 100TB or so of storage. I personally can afford 1-2TB of storage easily. You can put a *LOT* of web sites in a few TB of data. You can effectively develop search technology as long as you have the brains on any modern hardware. I think it is much more about the technology than the barrier to entry. Its not like building some factory or some geographically limited resources. It is a knowledge thing. The hardware can be had for very little money to do initial development.
You don't understand. Most players *WILL* figure out the system and the numbers anyway. They will quantify it and analyze it until they have the exact numbers. And then you have a bad situation where many of the players know the underlying stats and newcomers are at a great disadvantage because they don't know the game engine like the older players.
It is a novel idea.. but the players will turn it into stats collection and analysis if there is ANY type of true experience being collected. Someone will quantify it enough to extrpolate your basic economic system and take advantage of it. I tried systems like this in MUDs I ran. The players just want the numbers and it puts everyone on a level playing field. Its not that it is difficult, it is just that it gives an unfair advantage to those that will bother to work out the numbers underneath.
In the end I have never seen it be anything but unpopular. Even among players who enjoy RP and like a true atmosphere to their games.
Thats interesting. I brew beer once a month or so and I can tell you that everything I have done that has increased the complexity of my brewing process has had rather sound scientific principles to back them up. I don't know about making wine, but I do know that both processes use water and yeast. And the chemistry of water is quite complex. Home brewing is not an exact science and you can have a wide range of variation just depending on the freshness of something like your hops.
One of the most challenging aspects of advanced beer brewing is taking XYZ tap water and getting the water chemistry right for what you are doing. Certain chemicals in water can kill your beers head. Others can keep the yeast suspended in the beer longer than normal producing off tastes. The goal is to have a uniform brewing process that can take variations and produce the same tasting beer each and every time. Think of a macro brewer or wine producer. Their goal is to mostly be very consistent in reproducing a very similar taste so that budweiser beer or beringer white whines all have the same taste year after year. To the untrained eye it might seem silly that I used a dash of irish moss in my beer.. yet I have beer two batches of beer with and without a particular thing and it almost always has the effect everyone says it should. So there *IS* a lot of science behind the beer brewing world. I must imagine that for serious wine makers it must be the same. No two years of crops of wine or malt is the same from year to year.. yet the beer changes in taste very little at most macro brewerys. So I am not qualified to make any judgements directly on wine.. yet given the common elements of complexity: water chemistry, plant life, and yeast its sufficient to say that there is a lot you can do to be very methodical and scientific about wine/beer making. The things you want out of both are quite different. Yet they both have a lot in common. I know how much goes into beer brewing.. so I must assume wine is at least as complex. To someone who is not intimately familiar with the specific processes of a particular wine producers situation things may seem haphazard and random. And I would even go so far as to say that any particular wine maker that admits they are doing things without fully understanding the desired affect their actions will have on the fermantation process are making a bad decision in that they have not properly done their research.
Don't you think it is still possible for someone, somewhere, to hold enough in their head at a "full" level of understanding that they can make observations that no one else might make? It seems to me that you are arguing things are so complex now that no one person can visualize the pieces of the puzzle and how they interact. Yet if someone CAN do that they can theoretically manipulate the puzze at a level few others can. That is how you get breakthroughs that really change things. Can anyone do that now? Can things be simplified? Maybe, maybe not. Nothing leans me to much in one direction or another. Yet when you look at how far we have pushed things in the last 2,000 years it does not seem like the big leaps in our understanding of the universe are over with yet.
This is where I take exception. Religion does not have a virtual strangle hold on morals and ethics. Probably since the very existence of man we as a race have wrestled with ethics and morals.
You should not want to kill someone because the thought of someone killing you would prevent you. You should not steal because, logically, it isn't yours. Not because there is some punishment for doing it. The punishments are a way to enforce what you should already be doing. And that is that you don't take things from others unless they want you to have them. And then it is not taking it is giving or an exchange. So you shouldn't murder because if prison is all all that you fear for comitting a crime you are what we call a "socio-path". Someone that has no remose or real connection to their feelings when they take another persons life. That is the stuff serial killers are made from. Wouldn't you wonder about the life you had taken and what it meant to all those that it was associated with? Wouldn't the fact that you deprived someone else from everything be even a little off-putting?. And if you don't have a particular religion and you pretty much believe this life is all there is that should even more strongly encourage you to let others live their life to its fullest without unnaturally ending it.
When I don't do something that is illegal it is NOT because it is illegal the vast majority of the time. It is because I can see the logic behind the law and realize that we as a society are better off observing this particular rule. The big things like: stealing, killing, rape, molestation. Those all are quite obvious crimes that have a very tangible impact. I am willing to debate the value of traffic laws and their usage as revenue collection. When you start talking about "potential" to harm (IE: speeding potentially hurts someone). That is where there is more questioning the true potential for harm in present day society. BUt stealing something from someone produces an immediate and tangible effect on the person you take it from. They are deprived the benefit and or value of the item.
I am NOT Christian. I can still see that taking someone's life just because I can, even someone like the garbage man, is absolutely wrong. It is easy for me to see it is absolutely wrong because I think would I want the garbage man to come by and just randomly kill me because he could? And I am talking about a specific instance of just taking a life for the hell of it, because you can. Not self defense or anything other than a purely random act of violence. On a scale it is impossible to measure the value of human life. We can measure the position people hold (President, for example) and we afford the POSITION and what it represents extra protection. But a particular life can't truly be measured in value. I think its impossible. And thus by taking someones life you have performed an undefined action. Rather, you have done something that will throw an exception into the system of life. The only type of exception handling we as a society have come up with is prison. But exceptions should not happen. We only handle them in the case that they do occur, but we very rarely want them to happen.
I didn't mean to turn this into a Ruby vs. C++ discussion. I guess when I think of C++ and the reasons I don't like it or have always been averse to it I think of Java and Ruby as the two OO langauges I use. So in learning these languages you read about how they eliminate features that were so terrible in C++.
Like in Java where you are presented with Java as the savior to the problem of memory management. And I think to myself yeah.. I REALLY hated malloc at first. After time I came to only get along with malloc and managing my own memory. I never was happy with it. It always got in the way at some point. It introduced whole classes of bugs in my programs that GC eliminated. I was "sold". Java was the business language du jour so I learned that instead of C++. C++ was and is a commonly used language at the time but Java was more popular and seemed as good a place to go as any for a marketable skill. So that is where I went. I was so happy I had things that helped me avoid the pitfalls of C/C++ (as I thought of it then). I know C and C++ are different now, but that is my line of thinking.
I am also a web application architect. So I naturally look at tools that have good libraries for web development. Java and Ruby are very strong in this area. I look at C++ and I see very few web development frameworks. I mean practically no one uses C++ for web development. People would go cross eyed if you just mentioned using C++ for web development. It is not something I can change or rectify. I would have to stop developing web apps to really use C++ on my day job. So I just never get around to it. And compared to Java Ruby is much easier to work with and the rails (MVC for web apps) implementation is really good. I am still doing full OO modeling to express my applications but I am using a language that is dynamically typed. It seemed a lot easier to me. I don't even know of any C++ web dev frameworks. I also didn't look. That is probably just my lack of knowledge.
In my Java solutions I almost always use log4j and a singleton to do logging. So that I can agree with. I was just trying to come up with an example of a cross cutting service that you might want objects to have and that was a bad example.
And from the very onset the mixin facility is presented as Ruby's answer to multiple inheritance without the mess of multiple inheritance. I have never used C++ hugely. So I am always modeling things the Java way. That means interfaces and abstract classes, NOT multiple inheritance. Multiple inheritance was expressly taken from Java because developers screwed up using it to often. So having a facility like the mixin seems like a step up to me. More flexibility. ALMOST multiple inheritance. Not sure about mixing with a private scope. I don't think you can.
Presently I work with an application that is about 140kl of code written in a mix of Java and a language called ColdFusion.
The thing that has always struck me about C++ and Java is that the languages CAN be naturally expressive and short on the line count for code. Yet it seems like you have to know a lot more and work a lot harder to get the code line count down. It always seems like Java and C++ have far to much boiler plate. I am guessing that you would argue each and every line is important and there is nothing extraneous about it at all.
In Ruby when you mix a module in it holds a reference to that module. So if you change that module any class that has it mixed in is automatically updated. So not only can you change what mixins you refer to you can change the code while the program is running. So you can have self modifying code that changes itself while the program is running. I know.. happens pretty rarely. But for long running server process if you just needed to fix a bug in an attack module you could just fix the bug and then the problem is solved. In a C++ app you would have to reload the process.
The biggest program I have ever worked on is only like 250kloc. Not huge, but not really small either. Big enough that y
And I guess this is where we differ. To me it seems ok if my creature becomes something I did not define in any interface anywhere. Debugging him should not be hard if you have full capability to perform introspection on the object at runtime. So basically you take issue to features and paradigms Ruby people espouse? IE: that it is ok to take several well defined interfaces and then mix them creating an interface that is defined nowhere to acheive whatever capability you need.
Don't pity me to much. I have grown some of my Ruby code quite a bit. It has just never seemed all that difficult to debug when problems arise. The ways in which you mix interfaces and apply them to objects happen at very well defined points. It is possible to pretty easily determine whena nd where things are being mixed so you can determine: in code where the interfaces are being mixed. And at run time you can determine what interfaces are being mixed. So you know where, and at runtime you know exactly what. Using introspection you can quickly determine everything the creature has. I think the whole point is that you don't have to define in code what all you can attach to an object. You find this scary for maintenance and debugging. In practice this just hasn't been that much of an issue for me.
If I want to iterate over all of the attack capabilities my creature has I do have access to all of the modules (IE: capabilities) that have been mixed in. I can then determine which of those are attacks and do whatever I want. It is a bit coarse in that it is a list of all included capabilities. However I can just enumerate over the list and save a list of my attack capabilities. Then I could pick a random attack from the list of attacks and do it. So I think it should be possible to do that. I could then save that list of attacks and have the equivalent of a vector for all of my attack capabilities as an instance variable. Butnot until I need it! It is sort of funny you mention Martin Fowler: he really likes Ruby. Not that this in any way validates the langauge or anything, I just find it an interesting point.
One thing to be clear about... Mixins are NOT classes in Ruby. A module (the Ruby term for what you are mixing into classes) can carry state, but you really shouldn't put to much statefulness into them. They are good for giving capabilities, though. So you get a lot of benefits of aspect oriented programming where you can have cross cutting modules that you can then mix to a lot of different classes. A good example would be something like logging. Just mix in the logging module and then your object can log stuff. Again you think this is bad. How will others know that my foo object has the logging capability if I just attach it to the object at run time. I suppose you could have a logging interface or just go about using composition. But really what makes more sense: implementing a logging interface, giving an object logging capabilities (never specifying it specifically), or going the has-a route and just using composition to give the object a logger? Logging is an important service. Most of your objects are going to want to be able to log stuff, but not all of them. So why is it bad to avoid specifying which objects have logging until run time? It is a cross cutting service that almost any object can theoretically use. it seems silly to have to inherit that interface. With a mixin you avoid the need for multiple inheritance. let me guess, "Why avoid multiple inheritance it isn't nearly as bad as it has a reputation for being.".
And as I mentioned earlier. In my Java code I would probably just have a collection of attacks the creature could perform. Which is more or less what you suggested as an ideal solution. IE: my creature has-a colleciton that holds all of the attacks he has. So my creature has-a bunch of capabilities. They just aren't granted with object composition. But then modules are not really classes. They are really just collections of methods that *can* maintain state if they really need to. W
I don't know that I am purposefully trying to avoid specifying an interface. I have developed a few libraries and the first thing I did was wrote down everything I wanted the library to do. Then I sat down and mapped out the consumer's interface to the library. IE: The tip of the iceberg. I tried very hard to make sure that my API would not need to be changed even though I knew my library would grow so that all of my code using it would not need to change. Once you have all of that the code just falls in place. I get it. What if somewhere deep in your program and just on occasion you really want an instance of an object (just one instance) to have different capabilities?
Lets say you have a creature in an online game. A big bad creature. What if I don't know what capabilities I want this creature to ahve up front. What if the game needs to determine well into runtime that the creature can have different capabilities. Why should I have to specify, before runtime, all of the possible interfaces and places this creature gains its capabilities. Lets say the creature starts off with a swim capability and a jump capability. Then later in the game he gets a potion that gives him shoot laser beams from eyes capability. Should I really have to design an interface for the creature that specifically states the creature can possibly have this capability? Why not just attach it to him at runtime? What if in general the creature is just not going to have this capability save for special instances. I would have to provide some sort of interface in the code that specifies he could possibly have this capability at compile time. Or in say.. Ruby at run time I can just attach this capability (mix-in) to him. Then the creature can shoot laser beams. The creature can just have a little code that checks for a capability and uses it. I can see where there may bea little difficulty in, "How does the creature know what capabilities he has". Well we can check or when he takes a certain action if he DOES have that capability then the system lets him do whatever he was trying to do. So if heinvokes the shoot laser beam from eyes command and he does not have the capability he just can't do it. If he tries to swim and he does not have the capability something bad may happen. Why do I have to specify all of that. The shoot laser beam has a well defined interface. The creature himself is a well defined interface. All of the capabilities are well defined interface. I just think it is useful to reserve the right to dynamically mix and match these well defined interfaces. I know I could use base classes of capabilities that would give me the same benefit and clearly spell out that creature has an attack interface. Lser would then implement the attack interface along with all of the other interfaces he should have. And then by having a collection of objects that implement the attack interface. I can then dynamically configure my creatures attack capabilities. However, I had to spend time doing that (IE: specifying the interface). Whereas I can just attach it to him when he needs it instead of having to absolutely specify that he has a collection of attack objects that define his attack capabilities.
I just don't see it as an error in my thinking. The creature does not have a clean and stable interface about shooting lasers from his eyes. He has *NO* interface that tell him anything about laser beams OR attacking. Yet the laser can still be attached to him and he can still have that capability to attack with no specification of it. Why is that SO terrible. It is just what I would expect from a dynamic programming language. I am still clearly specifying what the attack interface is. And what special properties the shoot laser beams from eyes attack has. So if all of these things have good and stable interfaces why does it hurt to mix them from time to time. I mean.. an attack (shoot laser from eyes) that has the swim capability is silly. But a creature that has swim and and shoot laser from eyes makes perfect sense. I can just keep mixing in a
I just wanted to clarify a few things. Our discussion has had some tangential points about FP but has mostly cnetered around dynamic vs. static typing.
I think functional programming is really neat. However, for all of the time I spent using Lisp I still don't call it up as my programming language of choice in my head. I tend to think OO and Procedural in something akin to Java in my head. Java isn't such a terrible language. I have used it so much and like OO and procedural so much that it has just kind of became my default over the years.
Types are important. I just don't see how specifying the type in code is a requirement. I gain rapid prototyping and a more fluid programming environment which can be really handy when dealing with rapidly changing projects or clients that don't know what they want. This flexibility to bend and stretch and kind of organically grow the software really helps. The whole "I will know what I want when I see it" problem. Sure we start off with a pretty good spec on most projects, but clients and their ideas will always differ from what is written on the spec doc. I have had better experience in dealing with changes in the scope of a project with more dynamic languages.
Ok back to code for a minute. Lets say I have a line of code like this:
thingee = new FooBar();
I now have thingee holding onto a reference to a FooBar object. I know its type. It is of type FooBar. It is very difficult to miss the fact that I just made a FooBar object. So where does that leave me. Well I didn't specify the type thingee can hold. In the world of static typing if I tried to make thingee hold a reference to anything other than a FooBar object I would be really sad. That *CAN* be a good thing. But what if I really wanted thingee to be able to hold references to other objects of any type. In Java I can do this by just making thingee a reference to an Object. Voila now it can hold anything. I just eliminated type safety and gained a little dynamic fun. But you see the language does not like for you to do that. It complains when I do things to the Object that it doesn't think I should be doing. I can only do Object things to and with thingee because it is only an Object. So it does not let me do something like that. Thus it feels like the language is stopping me from doing things that occasionally I may really want to do. In dynamic language world we will just assume the programmer knows what he is doing when he asks the object referred to by thingee to do something. If not you get an error. But then you run into the same problem dealing with generic collections. Java bolted Generics on to deal with this so that you can Type your collections using some compiler syntax. I don't like it as I don't think it really does much to help. Yet you can now have compile time safety when using collections very similar to what you have in C++. I insist that my language let me do just absolutely CRAZY stuff like invoke ANY method on an object. Its my fault if I screwed up and the object referred to by thingee does not have that method. With type safety I don't have the flexibility. With type safety I do have a little extra comfort but I don't have quite as much flexibility about what my references point to.
To me this is great. I can break the rules in the eyes of a strongly typed programming language and it does not freak out. I like being able to do this. It has been immensely helpful. Combine that with things like mixins (Ruby's answer to multiple inheritance) and you can create objects that have different modules mixed in to dynamically tweak an object as it is going. So its less about its type and more about what the object can do at a given point in time. So in my experience so far I start thinking in terms of what a particular INSTANCE of an object can do at the current time. Not what the class can do as a whole. Check out this link on duck typing: Duck Typing(And yell at me if it is broken again) To me this just seems more in
However, if you are VERY fast at fitting square pegs to round holes can you tell the difference?
Ok ok.. so I do think about types. A LOT. I write classes all of the time (In Ruby and Java). A class is a type. Everything in Ruby is an object. IE: print 4.class will tell you the class of the integer object. My programs are nothing but big ole compositions of types, some I define, some I don't define. So I think about the type ALL the time. I know what types my objects are. The system knows what types my objects are (when it needs to know). So there is no need for me to litter my code with typing information when everyone interested in knowing the type knows it already. So why do you have to specify the type? Instantiating an object of a particular type tells you the type. I just think type safety is overrated. I just dont feel I am missing out when I don't have compile time type safety. I had it for years and it helped with some classes of problems, but those are pretty easy for any experienced programmer to avoid save the typo style errors.
Have you ever seen Photoshop in action? It uses several hundred megabytes on many images. Most of the overhead is purely in keeping track of big images, NOT some innate overhead of the language it is implemented in.
Most Ruby programs I have seen use LESS memory than a comparable Java program. There is a bit of constant overhead (literally just 3-4MB) on Windows and that is it. From there it grows as you allocate objects. Y! Instant Messenger takes up about 25MB of RAM on my system. A GUI I wrote to manage a few long running processes here in Ruby and Tk takes like 7 to 10 MB. Less than almost any program I have written. Even Calc takes up 2-3MB of RAM these days.
I did always think that Lisp's problem was an interesting one. I won't defend Lisp as hard as I might defend Ruby (which is a procedural OO language).
I have written a non blocking Ruby server that gracefully deals with at least a couple hundred connections PER second without breaking a sweat (HTTP). Files only. It ate about 15 MB and served a static HTML tree using intelligent caching rather well.
Also the one dead article was the most supportive of the case you are making. (I didn't do it like that on purpose). This C++ programmer took the example and implemented it using standard STL. It took him about 150ish lines compared to the 43 of the Lisp program. He rewrote bits and pieces of the STL to do a little more magic so that some of the iteration constructs were not so ugly and managed to get his program down to like 48 lines and it was semantically VERY similar to the Lisp program line for line. So I do think that it is possible that C++ can be made to have similar levels of abstraction, it just takes more work behind the scenes above and beyond basic C++.
I don't make mistakes like passing objects. I never mistype code. Praying regularly improves the quality of my code. All kneel before the fickle god Cx86RubyJavaLispCO+BOL+CFo+rtan or perish.
Seriously. You do get the benefit in a dynamic langauge of being able to rapidly prototype things and work through ideas. Compile time will catch some errors runtime may not. But then, that is life isn't it?
Heh nice story about debugging programs via assembly. The program I helped triem the memory usage down on mystified their programmers. They were exclaiming how it was garbage collected and they couldn't possibly be leaking memory and that my initial analysis was just wrong. When I found then hanging onto reference via certain globally scoped collections they were VERY sheepish. And it was blatantly obvious (took me a couple of hours to find). Oh well.
So if our two languages offer roughly the same level of abstraction (I will take is for granted you can make C++ relatively expressive) and there isn't all that much overhead to the Ruby interpreter, just a few MB. And we can also assume that for MOST problems it is algorithm and data structure choices that make the difference, not the underlying implementati
Meanwhile.. while the rest of the world has moved on from this thread we are still at it two days later. LOL. I will be away for the weekend and such. Feel free to email me and continue this. slashdotdrop (AT)yahoo.com. I will send the email I typically use from there. I dont like giving out my real address here.
P.S. Read your/. Journal as well. Good stuff there. Particularly liked the article on poverty.
>and I would argue that there are few things more important for a programmer to know. I would change that to *C/C++* programmers. As a Java programmer I very rarely have had to fall back on my assembly and lower level knowledge. And when I did it was to fix problems in a Java app. I was the fixer. And it turns out it *WAS* from lazy programming. But I used what I knew and found and fixed the problem. The program was still done and with a few minor changes was (for a Java program) not all that memory hungry.
And as far as changing math symbolics. I think if you did that you would end up with Math that looked like COBOL. Its interesting but you are like PGs antithesis He is pretty much loves math and favors languages that trend towards the symbolic (not as far as APL.. ICK!). I am in between. Yet.. when you know how all of that Math works you can look at one page of arcane symbols and comprehend it much more quickly than if you had to go through pages and pages of more verbose math.
>That is another big difference between us: I really hate functional >programming.
Well I guess to be honest I still have not bridged the gap over to purely functional way of thinking. And you do have to wonder. PG has a PhD in computer science and obviously likes thinking that way. But some serious programs *are* written in Lisp. Like the backend of Orbitz is done in Lisp and is pretty damn good at finding stuff. (A little slow at times, but never inconsistent).
I am still an OO thinker at heart. I alert my objects that I want them to do things and model programs in my head in terms of objects. I think that way easiest. I don't think it would be to difficult for me to get good with C++ given my C experience and my OO experience. Though I am sure I will have bad C habits that need eradicating I have quite a head start.
Dynamic typing. My first and cynical thought is that I am just lazy. There is just a LOT more to it. I don't like having to have an apparent compiler for my code. I don't think its needed to look at assembly to ensure my code is being compiled properly. I will put that burden on the compiler designers unless I see things are way off. Then I will get my hands dirty and figure out what is wrong. Otherwise I am willing to trade little overhead for less typing. I really don't think I will ever become a functional programmer, but maybe some day?
You are making the case for the average programmer when i tis obvious you are not. Anyone that can understand disassembled code and follow their code through it is *NOT* average anymore. You understand the cost of these things so that should make you even better in a language that gets it right almost all of the time and leaves you to focus on your problems instead of forcing you to compile code before you can check your results. I think a bit before I start writing my code, but some of the time getting in there and getting interactive with the code is great. You just can't do that with statically typed languages. You have to recompile.
So why dynamic: I know the cost overhead I am losing. I know how far from the silicon I am. (It has been guessed that each step away from the machine is an order of magnitude loss in performance). Thats ok processor speed has been increasing tremendously every year for a long time. Because we don't have to account for every last byte of data and a little excess is ok. Because an object can be *ANYTHING* I want it to be and other good programmers will understand what is happening in my code. I don't need to put a big huge sign on my identifier saying "LOOK AT ME, I AM A STRING!". The times I actually need to know the system can tell me what type the object is. Otherwise life is good. I spent 5 years in C and I got good enough that I didn't have pointer or memory related issues anymore. I thought in C at a time. But it always felt like the language was in my way of solving my problems some of the time. With Java that feeling lessened some. With Ruby that feeling almost goes away. My code is certainly no
> If you don't understand C++, you are only liable to reinvent it. Badly.
Isn't the saying that you will reinvent Lisp, badly? Greenspun's Rule/Law?;-)
This example is of an accumulator generator snagged from Paul Graham's website: http://www.paulgraham.com/accgen.html. Tailored to a problem that functional languages can solve more easily, but it is still interesting.
And for another programmers take on it where he tries the same thing: C++ hackers take
Also see another PG article: Succinctness is Power If you google for succinctness PGs article is the first result amusingly enough.
And here is a pretty famous study done on Erlang: Erlang Study
I hope we can at least agree that not all languages are created equal. I am honestly not interested in cloning or working in a langauge like C++. I am much more interested in languages like Lisp. I also freely admit that my OO experience leans heavily on Java, Lisp, and Ruby coding. And that I have little real C++ experience. I have done *basic* OO in my C++ programs. I used the STL for a couple of REALLY simple things in one of my later C++ programs but that is really about it. I try to use C++ in its more modern and usable context when I use it, but it is quite a time investment and I am really only after performance if I am using C++ so I keep it as lean and mean as possible and end up with C using objects with new and delete and a smattering of STL when it saves me time and I can easily do it without adversely affect the outcome of my program. So I base a lot of these assumptions on: a lot of C programming, a lot of OO programming, and a little C++ programming.
You might be onto something about the semantics of OO programming compared to the syntax of the language. It is relatively unimportant as long as the Syntax does not get in the way.
As for specific types of programs: Web development, simple and relatively complicated desktop applications. Pretty much anything that is not processor bound. I am being vague because I really do believe it in a very general sense. I do a lot of web development.. so in my world I am a little IO bound by network latency. You have to work around big warts like HTTP being stateless and generally you really want to maintain state. I also develop the occasional desktop application (Windows stuff...Sigh). For Windows programs you really do need to use as little memory as you want, but you can still get away with using.NET which runs in a VM and is GCd. I really do focus on web development and network programming, though. I have written all sorts of programs such as search and data indexing stuff. It is still fast enough with hundreds of megabytes of data and it isn't C++.
So in my IO bound world I use the most productive and powerful languages I can convince my team to use without secretly wanting to murder me. There is a bigger learning curve for C++. And to be honest I am not concerned about average programmers. I only want people working for/with me that can wrap their head around any programming language even assembly. So ideally I only want to work with people that can use C++ and be good at it. Only I don't want to use C++ because I think the learning curve is not needed. That said is there REALLY a reason for every programmer to understand pointers? Is it really required. We are coming to an age where entire generations of programmers are raised on Java and GCd languages. I wasn't, but I know quite a few programmers who were/are. Do you really have to know assembly on up? Is that important for every programmer to know? You can't even talk to modern x86 processors directly these
I think C++ is a fairly light weight language in Syntax. And in usage. STL syntax isn't to fun, but it is survivable. I know OO programming very well. I know C programming pretty good. I know the cost of memory and memory ownership from years and years of programming in C. I can understand and interpret x86 assembly. I can get down and dirty with the hardware and tune a C program well. What does not change is that you still have to know and use pointers and all of the syntax required to deal with them in C++. After a time it becomes second nature. And with a little experience in a debugger you can quickly track down most pointer related mischief. What you can't do is manage to write less code in C++. You can make a good run at it with STL and good architecture. However, you will still be writing more code in C++ or Java than you will in a more expressive and concise language. If you have to write less code to accomplish the same goal and you can still do it with performance that, relative to the task, is acceptable why not?
I admit a lot of Java/C# programmers, myself included on various occasions, can be a little wasteful. On the important stuff I try to keep the code tight and I try and ensure my objects are just as heavy as they need to be and no more. I try to ensure I don't hang on to a reference any longer than I need to. I strive for this because I know memory isn't free. And if you get to wasteful and you have an entire team that lets it slip you end up with a nasty and bloated program (regardless of the language, GC or no).
I have no problem writing OO code. I tend to prefer OO after writing so much of the stuff. The GoF pattern book was written using C++ and is still just as relevant as always. I know what the stack is too. Java has a stack too;-). It is still important. Not for memory allocation but if you don't know what the stack is and how it works you won't be as effective in Java either. I remember fixing a method that had way to much recursion. It was quite easy to determine the problem just peeking at the stack and seeing its recursion depth. Just fine for binary trees. Not so great to recurse one level deeper each time you want to spider a new website.
C++ just is not as productive as some of the languages out there. Lets compare it to say.. Lisp. Lisp for an experienced programmer is a productive language. With modern hardware the cost of Lisp is not so great. A team of experienced Lisp hackers are more productive than a team of experienced C++ hackers. If your language lets you write less lines of code to achieve the same work you will be more productive. If an entire team uses this language the team will be more productive. Good programmers will not abuse a garbage collector any more than a C++ programmer would not leak memory. And you have the luxury of writing good code. And I know.. you have already covered this, but GC does completely eliminate certain kinds of memory leak issues. I know C++ is not some terrible language that produced bloated code and binaries. C++ is where I turn when performance is an absolute. So rarely is performance an absolute with modern hardware. I am doing my clients a disservice to use a language like C++ when I can do the same job for them faster with easier to use tools that let me do my job faster.
So the argument isn't against C++ because it is a terrible language that can't be used well. The argument is that statically typed languages like C, C++, Java, and C# take more lines of code than a dynamic and expressive language like Ruby or Lisp. If your program meets all of your clients criteria and runs on modern hardware and you can write it twice as fast in a dynamic language why on earth would you spend more time doing it in a language like C++? I wrote code in C long enough to know that even if you are one of the best C or C++ programmers in the world you are still at a disadvantage when compared to a great programmer that knows their way around a language like Lisp or Ruby. It isn't the programmer, it is the language
Technically I use two monitors. So I have two screens worth of 1280x1024. I code on one monitor.. which basically is a maximized window of code at a pretty reasonable font size actually. I already have relatively bad vision. Many of my fonts are a size point or two bigger usually.
I do Java mostly. That is the language I "think" in and know inside and out. I have not done any serious C development in 4 years. I did a good 5 year stretch of hard C development. I am starting to use Ruby. I like Ruby because it takes less code to get things done so I can fit lots of Ruby code on the screen. So I have to agree about saving lines.
The biggest problem I have is that C++ is just not required for many types of programs. Not sure what sort of development you are doing, so it may be required. Even being one of the best few C++ coders you would be more efficient if you were as proficient in some more dynamic language. (I don't like Perl, either). There will always be a place on a development team for a "Language Expert", but generally you don't need but one of those on a pretty big team. Most programmers do tend to have one language they "think" in. Sadly mine is Java. I don't like it. I think Java is a mess. Ditto for C++. To much baggage in both (design by comittee anyone?).
For the record I still write C and or C++ in K&R style. It seems perverse not to. I guess I am used to being able to fit more lines of code on the screen. I presently can fit about 53 lines with 120 columns in my fancy GUI editor;-) So I can afford to use the other brace style and still probably fit roughly the same amount of code on the screen as you can without that style. With it I could probably fit 5-10 more lines of meaningful code pretty easily. Something to think about given that I do believe seeing more code directly translates to productivity.
Jeremy
Re:Question for all the coders out there..
on
How to Write Comments
·
· Score: 2, Insightful
I started coding doing K&R C style braces. I have used them for many many years. I have recently been trying the opening brace on a separate line. It isn't so bad. There are a LOT of languages out there other than C. You can make a bunch of logical arguments for both ways. It is almost like vi vs. emacs. I can spot blocks either way. I also do a lot of Ruby coding which doesn't even use braces and instead uses the end statement to denote the end of the block. So you actualyl *have* to know what statements can start a block to even begin to know if you should be looking for an end to the block.
As long as you are consistent with your style others will be able to read your code. Maintainability matters more than stylistic preference and both styles are maintainable. They are called STYLES after all.
And technically automatically interpreting a line without a brace as a terminated statement (IE: with the semicolon) can be just as bad as programmers that can't find a block of code. You should know the language well enough that you can interpret any common brace style. Ok.. no more nit picking.
I think one of the reasons it still dominates is it still gets used in book writing to condense lines of code. Almost all developers read code examples written here and there. I think this is big on continuing the tradition. When I was working on a my PHP book I know I used the brace on same line as the conditional method because it saved lines.
In the end being consistent trumps stylistic preference. The best argument I have seen is for condensing code. It does save a line or two here and there if you really need it. With 1280x1024 being a relatively common display resolution used by developers these days I don't think it is such a big deal to have an extra line for the braces:-)
A normal human looks at something. Thinks about it for a second and can detect sarcasm. A hacker reads it and immediately identifies the 10 million ways you are wrong before stopping to think you might not have been serious.
J/K. I do get a little carried away on the analysis without stopping to detect a more subtle point;-) So odd someone can get it and miss it in one stroke. Ahh well.
The thing that strikes me about all of this is that the test is obviously rigged towards bigger businesses. Integrating systems into a big corporate environment that will make CIOs happy is all fun and good. Yet.. things like upgrading glibc and all of this policy change control is just slanting things towards a company that aims to cater to these, sometimes senseless, business requirements.
Many of the points are good. Yet.. in a small to medium sized environment you have MANY luxuries and things you just don't worry about. Change control? If something is broke I fix it. I take every best effort to not have any downtime. I make sure I am not affecting my users. So operating from those constraints: minimal downtime, don't interrupt users I go. Life is generally good. XYZ startup set out to change the world (Google) really don't give a rats ass about blessed binaries. As long as it doesn't break anything and you can stably apply it to your environment without disrupting your users who cares? Often you have to recompile your critical applications with new options anyway such that you aren't running on a vendor supplied binary. I just don't see how this test reflects how Linux is really used. In other words I think there are variablies for Linux that simply can't be included in the test because Windows can't even do it (for better or worse). These,untestable, harder to quantify items are what keep me using Linux based operating systems.
For certain critical things it can be good to ensure that a fix doesn't break more than it solves. Yet the fix is out there and you can evaluate it then and there. That is something you just can't do in Windows. There is a total openness about the process of the patch. In MS who knows what dark magic happens between vulnerability and a "blessed" patch. In some ways they are different worlds. I can achieve my goals. Tens of thousands of other people believe in free operating systems to power their business. As long as all of this is the case the model sustains itself. So who really cares about these studies that are focusing on how Linux does with big business constraints. What does Linux really gain being inside of big business so deeply other than corporate dollars? Open software and your average american corporation have completely different ideologies. I don't know why people are so concerned about what a Microsoft study says about Linux playing in an environment rigged to favor MS.
That is pretty much stretching it. If you want to build a GUI based program I find it a little silly to pack your widgets completely by hand. It is just tedious. Learn how it all works.. but for the love of god don't make me build a complex GUI without a GUI designer. I have done it and can do it but I just find it tedious. Constnatly visualizing how the GUI is progressing as you throw more and more widgets/components into a particular layout format. I dare say it reduces the quality of the code because you have developers spending far to much time on tedious work and not focusing on the real problems. You do occasionally really need to create a widget or panel by hand.. so having the knowledge is still important.
And when you just plop components in place all you have made is a GUI that does nothing. The real work comes in putting code behind the widgets in a maintainable fashion. And let me tell you I have seen some really bad coding. It is encouraged because people get in this mentality that they must cram as much code into the desginer created classes/forms as possible. People use GUI forms for their model even. For their everything. That just makes the coders bad. The tools should not be blamed as heavily as the developers using them. Visual studio is the one that is bad for encouraging people to cram way to much code into the GUI classes.
The Java GUI designers out there tend to be a little better about making you glue everything together yourself. It really isn't the tools fault. It is the fact that 99.9% of people use GUIs so you need good tools to build GUIs and, generally, doing so with another GUI is easier than command line.
Tools that get abused frequently are really a problem of business culture not hacker culture. I blame lazy programmers who should be in another profession for giving GUI designers a bad rap.
I am not sure what to think about you Silverspur. You are either a pretty smart scientific mind with a bit of a superiority complex or a complete hoax. In either case calm down a bit!
Well.. I hope you can keep it up. When relatively big amounts of money get mixed into something and you have developers from these companies mixed in it can really fubar things. Maybe only for a short period of time, maybe forever. Keep your eyes open and do what you do for the users.. not for some business!
And the entire Eclipse project is eclipsed by the weight of all of these businesses signing on. Eclipse is a great tool. As more and more corporate entities become involved things will become more committee driven. This will ensure that nothing useful gets done very quickly. Design by committee tends to make things slower, more cumbersome, and less innovative. Just look at Java;-) (Ok.. that was a low blow). You don't get the vision of the creators of Java from Java. You get the vision the creators had based on Sun's need to scoop up all of the commercial developers languishing in C++ (yet another language designed by committee). It is all so much fun!
Slashdot Mirror
Lever is a noun as well.
You can have leveraged something or levered something.
Jeremy
It is NOT a super high barrier to entry in my opinion. Archive.org only has like 100TB or so of storage. I personally can afford 1-2TB of storage easily. You can put a *LOT* of web sites in a few TB of data. You can effectively develop search technology as long as you have the brains on any modern hardware. I think it is much more about the technology than the barrier to entry. Its not like building some factory or some geographically limited resources. It is a knowledge thing. The hardware can be had for very little money to do initial development.
Jeremy
You don't understand. Most players *WILL* figure out the system and the numbers anyway. They will quantify it and analyze it until they have the exact numbers. And then you have a bad situation where many of the players know the underlying stats and newcomers are at a great disadvantage because they don't know the game engine like the older players.
It is a novel idea.. but the players will turn it into stats collection and analysis if there is ANY type of true experience being collected. Someone will quantify it enough to extrpolate your basic economic system and take advantage of it. I tried systems like this in MUDs I ran. The players just want the numbers and it puts everyone on a level playing field. Its not that it is difficult, it is just that it gives an unfair advantage to those that will bother to work out the numbers underneath.
In the end I have never seen it be anything but unpopular. Even among players who enjoy RP and like a true atmosphere to their games.
Jeremy
Thats interesting. I brew beer once a month or so and I can tell you that everything I have done that has increased the complexity of my brewing process has had rather sound scientific principles to back them up. I don't know about making wine, but I do know that both processes use water and yeast. And the chemistry of water is quite complex. Home brewing is not an exact science and you can have a wide range of variation just depending on the freshness of something like your hops.
One of the most challenging aspects of advanced beer brewing is taking XYZ tap water and getting the water chemistry right for what you are doing. Certain chemicals in water can kill your beers head. Others can keep the yeast suspended in the beer longer than normal producing off tastes. The goal is to have a uniform brewing process that can take variations and produce the same tasting beer each and every time. Think of a macro brewer or wine producer. Their goal is to mostly be very consistent in reproducing a very similar taste so that budweiser beer or beringer white whines all have the same taste year after year. To the untrained eye it might seem silly that I used a dash of irish moss in my beer.. yet I have beer two batches of beer with and without a particular thing and it almost always has the effect everyone says it should. So there *IS* a lot of science behind the beer brewing world. I must imagine that for serious wine makers it must be the same. No two years of crops of wine or malt is the same from year to year.. yet the beer changes in taste very little at most macro brewerys. So I am not qualified to make any judgements directly on wine.. yet given the common elements of complexity: water chemistry, plant life, and yeast its sufficient to say that there is a lot you can do to be very methodical and scientific about wine/beer making. The things you want out of both are quite different. Yet they both have a lot in common. I know how much goes into beer brewing.. so I must assume wine is at least as complex. To someone who is not intimately familiar with the specific processes of a particular wine producers situation things may seem haphazard and random. And I would even go so far as to say that any particular wine maker that admits they are doing things without fully understanding the desired affect their actions will have on the fermantation process are making a bad decision in that they have not properly done their research.
Jeremy
Don't you think it is still possible for someone, somewhere, to hold enough in their head at a "full" level of understanding that they can make observations that no one else might make? It seems to me that you are arguing things are so complex now that no one person can visualize the pieces of the puzzle and how they interact. Yet if someone CAN do that they can theoretically manipulate the puzze at a level few others can. That is how you get breakthroughs that really change things. Can anyone do that now? Can things be simplified? Maybe, maybe not. Nothing leans me to much in one direction or another. Yet when you look at how far we have pushed things in the last 2,000 years it does not seem like the big leaps in our understanding of the universe are over with yet.
Jeremy
This is where I take exception. Religion does not have a virtual strangle hold on morals and ethics. Probably since the very existence of man we as a race have wrestled with ethics and morals.
You should not want to kill someone because the thought of someone killing you would prevent you. You should not steal because, logically, it isn't yours. Not because there is some punishment for doing it. The punishments are a way to enforce what you should already be doing. And that is that you don't take things from others unless they want you to have them. And then it is not taking it is giving or an exchange. So you shouldn't murder because if prison is all all that you fear for comitting a crime you are what we call a "socio-path". Someone that has no remose or real connection to their feelings when they take another persons life. That is the stuff serial killers are made from. Wouldn't you wonder about the life you had taken and what it meant to all those that it was associated with? Wouldn't the fact that you deprived someone else from everything be even a little off-putting?. And if you don't have a particular religion and you pretty much believe this life is all there is that should even more strongly encourage you to let others live their life to its fullest without unnaturally ending it.
When I don't do something that is illegal it is NOT because it is illegal the vast majority of the time. It is because I can see the logic behind the law and realize that we as a society are better off observing this particular rule. The big things like: stealing, killing, rape, molestation. Those all are quite obvious crimes that have a very tangible impact. I am willing to debate the value of traffic laws and their usage as revenue collection. When you start talking about "potential" to harm (IE: speeding potentially hurts someone). That is where there is more questioning the true potential for harm in present day society. BUt stealing something from someone produces an immediate and tangible effect on the person you take it from. They are deprived the benefit and or value of the item.
I am NOT Christian. I can still see that taking someone's life just because I can, even someone like the garbage man, is absolutely wrong. It is easy for me to see it is absolutely wrong because I think would I want the garbage man to come by and just randomly kill me because he could? And I am talking about a specific instance of just taking a life for the hell of it, because you can. Not self defense or anything other than a purely random act of violence. On a scale it is impossible to measure the value of human life. We can measure the position people hold (President, for example) and we afford the POSITION and what it represents extra protection. But a particular life can't truly be measured in value. I think its impossible. And thus by taking someones life you have performed an undefined action. Rather, you have done something that will throw an exception into the system of life. The only type of exception handling we as a society have come up with is prison. But exceptions should not happen. We only handle them in the case that they do occur, but we very rarely want them to happen.
Jeremy
I didn't mean to turn this into a Ruby vs. C++ discussion. I guess when I think of C++ and the reasons I don't like it or have always been averse to it I think of Java and Ruby as the two OO langauges I use. So in learning these languages you read about how they eliminate features that were so terrible in C++.
Like in Java where you are presented with Java as the savior to the problem of memory management. And I think to myself yeah.. I REALLY hated malloc at first. After time I came to only get along with malloc and managing my own memory. I never was happy with it. It always got in the way at some point. It introduced whole classes of bugs in my programs that GC eliminated. I was "sold". Java was the business language du jour so I learned that instead of C++. C++ was and is a commonly used language at the time but Java was more popular and seemed as good a place to go as any for a marketable skill. So that is where I went. I was so happy I had things that helped me avoid the pitfalls of C/C++ (as I thought of it then). I know C and C++ are different now, but that is my line of thinking.
I am also a web application architect. So I naturally look at tools that have good libraries for web development. Java and Ruby are very strong in this area. I look at C++ and I see very few web development frameworks. I mean practically no one uses C++ for web development. People would go cross eyed if you just mentioned using C++ for web development. It is not something I can change or rectify. I would have to stop developing web apps to really use C++ on my day job. So I just never get around to it. And compared to Java Ruby is much easier to work with and the rails (MVC for web apps) implementation is really good. I am still doing full OO modeling to express my applications but I am using a language that is dynamically typed. It seemed a lot easier to me. I don't even know of any C++ web dev frameworks. I also didn't look. That is probably just my lack of knowledge.
In my Java solutions I almost always use log4j and a singleton to do logging. So that I can agree with. I was just trying to come up with an example of a cross cutting service that you might want objects to have and that was a bad example.
And from the very onset the mixin facility is presented as Ruby's answer to multiple inheritance without the mess of multiple inheritance. I have never used C++ hugely. So I am always modeling things the Java way. That means interfaces and abstract classes, NOT multiple inheritance. Multiple inheritance was expressly taken from Java because developers screwed up using it to often. So having a facility like the mixin seems like a step up to me. More flexibility. ALMOST multiple inheritance. Not sure about mixing with a private scope. I don't think you can.
Presently I work with an application that is about 140kl of code written in a mix of Java and a language called ColdFusion.
The thing that has always struck me about C++ and Java is that the languages CAN be naturally expressive and short on the line count for code. Yet it seems like you have to know a lot more and work a lot harder to get the code line count down. It always seems like Java and C++ have far to much boiler plate. I am guessing that you would argue each and every line is important and there is nothing extraneous about it at all.
In Ruby when you mix a module in it holds a reference to that module. So if you change that module any class that has it mixed in is automatically updated. So not only can you change what mixins you refer to you can change the code while the program is running. So you can have self modifying code that changes itself while the program is running. I know.. happens pretty rarely. But for long running server process if you just needed to fix a bug in an attack module you could just fix the bug and then the problem is solved. In a C++ app you would have to reload the process.
The biggest program I have ever worked on is only like 250kloc. Not huge, but not really small either. Big enough that y
And I guess this is where we differ. To me it seems ok if my creature becomes something I did not define in any interface anywhere. Debugging him should not be hard if you have full capability to perform introspection on the object at runtime. So basically you take issue to features and paradigms Ruby people espouse? IE: that it is ok to take several well defined interfaces and then mix them creating an interface that is defined nowhere to acheive whatever capability you need.
Don't pity me to much. I have grown some of my Ruby code quite a bit. It has just never seemed all that difficult to debug when problems arise. The ways in which you mix interfaces and apply them to objects happen at very well defined points. It is possible to pretty easily determine whena nd where things are being mixed so you can determine: in code where the interfaces are being mixed. And at run time you can determine what interfaces are being mixed. So you know where, and at runtime you know exactly what. Using introspection you can quickly determine everything the creature has. I think the whole point is that you don't have to define in code what all you can attach to an object. You find this scary for maintenance and debugging. In practice this just hasn't been that much of an issue for me.
If I want to iterate over all of the attack capabilities my creature has I do have access to all of the modules (IE: capabilities) that have been mixed in. I can then determine which of those are attacks and do whatever I want. It is a bit coarse in that it is a list of all included capabilities. However I can just enumerate over the list and save a list of my attack capabilities. Then I could pick a random attack from the list of attacks and do it. So I think it should be possible to do that. I could then save that list of attacks and have the equivalent of a vector for all of my attack capabilities as an instance variable. Butnot until I need it! It is sort of funny you mention Martin Fowler: he really likes Ruby. Not that this in any way validates the langauge or anything, I just find it an interesting point.
One thing to be clear about... Mixins are NOT classes in Ruby. A module (the Ruby term for what you are mixing into classes) can carry state, but you really shouldn't put to much statefulness into them. They are good for giving capabilities, though. So you get a lot of benefits of aspect oriented programming where you can have cross cutting modules that you can then mix to a lot of different classes. A good example would be something like logging. Just mix in the logging module and then your object can log stuff. Again you think this is bad. How will others know that my foo object has the logging capability if I just attach it to the object at run time. I suppose you could have a logging interface or just go about using composition. But really what makes more sense: implementing a logging interface, giving an object logging capabilities (never specifying it specifically), or going the has-a route and just using composition to give the object a logger? Logging is an important service. Most of your objects are going to want to be able to log stuff, but not all of them. So why is it bad to avoid specifying which objects have logging until run time? It is a cross cutting service that almost any object can theoretically use. it seems silly to have to inherit that interface. With a mixin you avoid the need for multiple inheritance. let me guess, "Why avoid multiple inheritance it isn't nearly as bad as it has a reputation for being.".
And as I mentioned earlier. In my Java code I would probably just have a collection of attacks the creature could perform. Which is more or less what you suggested as an ideal solution. IE: my creature has-a colleciton that holds all of the attacks he has. So my creature has-a bunch of capabilities. They just aren't granted with object composition. But then modules are not really classes. They are really just collections of methods that *can* maintain state if they really need to. W
I don't know that I am purposefully trying to avoid specifying an interface. I have developed a few libraries and the first thing I did was wrote down everything I wanted the library to do. Then I sat down and mapped out the consumer's interface to the library. IE: The tip of the iceberg. I tried very hard to make sure that my API would not need to be changed even though I knew my library would grow so that all of my code using it would not need to change. Once you have all of that the code just falls in place. I get it. What if somewhere deep in your program and just on occasion you really want an instance of an object (just one instance) to have different capabilities?
Lets say you have a creature in an online game. A big bad creature. What if I don't know what capabilities I want this creature to ahve up front. What if the game needs to determine well into runtime that the creature can have different capabilities. Why should I have to specify, before runtime, all of the possible interfaces and places this creature gains its capabilities. Lets say the creature starts off with a swim capability and a jump capability. Then later in the game he gets a potion that gives him shoot laser beams from eyes capability. Should I really have to design an interface for the creature that specifically states the creature can possibly have this capability? Why not just attach it to him at runtime? What if in general the creature is just not going to have this capability save for special instances. I would have to provide some sort of interface in the code that specifies he could possibly have this capability at compile time. Or in say.. Ruby at run time I can just attach this capability (mix-in) to him. Then the creature can shoot laser beams. The creature can just have a little code that checks for a capability and uses it. I can see where there may bea little difficulty in, "How does the creature know what capabilities he has". Well we can check or when he takes a certain action if he DOES have that capability then the system lets him do whatever he was trying to do. So if heinvokes the shoot laser beam from eyes command and he does not have the capability he just can't do it. If he tries to swim and he does not have the capability something bad may happen. Why do I have to specify all of that. The shoot laser beam has a well defined interface. The creature himself is a well defined interface. All of the capabilities are well defined interface. I just think it is useful to reserve the right to dynamically mix and match these well defined interfaces. I know I could use base classes of capabilities that would give me the same benefit and clearly spell out that creature has an attack interface. Lser would then implement the attack interface along with all of the other interfaces he should have. And then by having a collection of objects that implement the attack interface. I can then dynamically configure my creatures attack capabilities. However, I had to spend time doing that (IE: specifying the interface). Whereas I can just attach it to him when he needs it instead of having to absolutely specify that he has a collection of attack objects that define his attack capabilities.
I just don't see it as an error in my thinking. The creature does not have a clean and stable interface about shooting lasers from his eyes. He has *NO* interface that tell him anything about laser beams OR attacking. Yet the laser can still be attached to him and he can still have that capability to attack with no specification of it. Why is that SO terrible. It is just what I would expect from a dynamic programming language. I am still clearly specifying what the attack interface is. And what special properties the shoot laser beams from eyes attack has. So if all of these things have good and stable interfaces why does it hurt to mix them from time to time. I mean.. an attack (shoot laser from eyes) that has the swim capability is silly. But a creature that has swim and and shoot laser from eyes makes perfect sense. I can just keep mixing in a
I just wanted to clarify a few things. Our discussion has had some tangential points about FP but has mostly cnetered around dynamic vs. static typing.
I think functional programming is really neat. However, for all of the time I spent using Lisp I still don't call it up as my programming language of choice in my head. I tend to think OO and Procedural in something akin to Java in my head. Java isn't such a terrible language. I have used it so much and like OO and procedural so much that it has just kind of became my default over the years.
Types are important. I just don't see how specifying the type in code is a requirement. I gain rapid prototyping and a more fluid programming environment which can be really handy when dealing with rapidly changing projects or clients that don't know what they want. This flexibility to bend and stretch and kind of organically grow the software really helps. The whole "I will know what I want when I see it" problem. Sure we start off with a pretty good spec on most projects, but clients and their ideas will always differ from what is written on the spec doc. I have had better experience in dealing with changes in the scope of a project with more dynamic languages.
Ok back to code for a minute. Lets say I have a line of code like this:
thingee = new FooBar();
I now have thingee holding onto a reference to a FooBar object. I know its type. It is of type FooBar. It is very difficult to miss the fact that I just made a FooBar object. So where does that leave me. Well I didn't specify the type thingee can hold. In the world of static typing if I tried to make thingee hold a reference to anything other than a FooBar object I would be really sad. That *CAN* be a good thing. But what if I really wanted thingee to be able to hold references to other objects of any type. In Java I can do this by just making thingee a reference to an Object. Voila now it can hold anything. I just eliminated type safety and gained a little dynamic fun. But you see the language does not like for you to do that. It complains when I do things to the Object that it doesn't think I should be doing. I can only do Object things to and with thingee because it is only an Object. So it does not let me do something like that. Thus it feels like the language is stopping me from doing things that occasionally I may really want to do. In dynamic language world we will just assume the programmer knows what he is doing when he asks the object referred to by thingee to do something. If not you get an error. But then you run into the same problem dealing with generic collections. Java bolted Generics on to deal with this so that you can Type your collections using some compiler syntax. I don't like it as I don't think it really does much to help. Yet you can now have compile time safety when using collections very similar to what you have in C++. I insist that my language let me do just absolutely CRAZY stuff like invoke ANY method on an object. Its my fault if I screwed up and the object referred to by thingee does not have that method. With type safety I don't have the flexibility. With type safety I do have a little extra comfort but I don't have quite as much flexibility about what my references point to.
To me this is great. I can break the rules in the eyes of a strongly typed programming language and it does not freak out. I like being able to do this. It has been immensely helpful. Combine that with things like mixins (Ruby's answer to multiple inheritance) and you can create objects that have different modules mixed in to dynamically tweak an object as it is going. So its less about its type and more about what the object can do at a given point in time. So in my experience so far I start thinking in terms of what a particular INSTANCE of an object can do at the current time. Not what the class can do as a whole. Check out this link on duck typing: Duck Typing(And yell at me if it is broken again) To me this just seems more in
However, if you are VERY fast at fitting square pegs to round holes can you tell the difference?
Ok ok.. so I do think about types. A LOT. I write classes all of the time (In Ruby and Java). A class is a type. Everything in Ruby is an object. IE: print 4.class will tell you the class of the integer object. My programs are nothing but big ole compositions of types, some I define, some I don't define. So I think about the type ALL the time. I know what types my objects are. The system knows what types my objects are (when it needs to know). So there is no need for me to litter my code with typing information when everyone interested in knowing the type knows it already. So why do you have to specify the type? Instantiating an object of a particular type tells you the type. I just think type safety is overrated. I just dont feel I am missing out when I don't have compile time type safety. I had it for years and it helped with some classes of problems, but those are pretty easy for any experienced programmer to avoid save the typo style errors.
Have you ever seen Photoshop in action? It uses several hundred megabytes on many images. Most of the overhead is purely in keeping track of big images, NOT some innate overhead of the language it is implemented in.
Most Ruby programs I have seen use LESS memory than a comparable Java program. There is a bit of constant overhead (literally just 3-4MB) on Windows and that is it. From there it grows as you allocate objects. Y! Instant Messenger takes up about 25MB of RAM on my system. A GUI I wrote to manage a few long running processes here in Ruby and Tk takes like 7 to 10 MB. Less than almost any program I have written. Even Calc takes up 2-3MB of RAM these days.
I did always think that Lisp's problem was an interesting one. I won't defend Lisp as hard as I might defend Ruby (which is a procedural OO language).
I have written a non blocking Ruby server that gracefully deals with at least a couple hundred connections PER second without breaking a sweat (HTTP). Files only. It ate about 15 MB and served a static HTML tree using intelligent caching rather well.
Also the one dead article was the most supportive of the case you are making. (I didn't do it like that on purpose). This C++ programmer took the example and implemented it using standard STL. It took him about 150ish lines compared to the 43 of the Lisp program. He rewrote bits and pieces of the STL to do a little more magic so that some of the iteration constructs were not so ugly and managed to get his program down to like 48 lines and it was semantically VERY similar to the Lisp program line for line. So I do think that it is possible that C++ can be made to have similar levels of abstraction, it just takes more work behind the scenes above and beyond basic C++.
I don't make mistakes like passing objects. I never mistype code. Praying regularly improves the quality of my code. All kneel before the fickle god Cx86RubyJavaLispCO+BOL+CFo+rtan or perish.
Seriously. You do get the benefit in a dynamic langauge of being able to rapidly prototype things and work through ideas. Compile time will catch some errors runtime may not. But then, that is life isn't it?
Heh nice story about debugging programs via assembly. The program I helped triem the memory usage down on mystified their programmers. They were exclaiming how it was garbage collected and they couldn't possibly be leaking memory and that my initial analysis was just wrong. When I found then hanging onto reference via certain globally scoped collections they were VERY sheepish. And it was blatantly obvious (took me a couple of hours to find). Oh well.
So if our two languages offer roughly the same level of abstraction (I will take is for granted you can make C++ relatively expressive) and there isn't all that much overhead to the Ruby interpreter, just a few MB. And we can also assume that for MOST problems it is algorithm and data structure choices that make the difference, not the underlying implementati
Meanwhile.. while the rest of the world has moved on from this thread we are still at it two days later. LOL. I will be away for the weekend and such. Feel free to email me and continue this. slashdotdrop (AT)yahoo.com. I will send the email I typically use from there. I dont like giving out my real address here.
/. Journal as well. Good stuff there. Particularly liked the article on poverty.
P.S. Read your
Jeremy
>and I would argue that there are few things more important for a programmer to know.
I would change that to *C/C++* programmers. As a Java programmer I very rarely have had to fall back on my assembly and lower level knowledge. And when I did it was to fix problems in a Java app. I was the fixer. And it turns out it *WAS* from lazy programming. But I used what I knew and found and fixed the problem. The program was still done and with a few minor changes was (for a Java program) not all that memory hungry.
And as far as changing math symbolics. I think if you did that you would end up with Math that looked like COBOL. Its interesting but you are like PGs antithesis He is pretty much loves math and favors languages that trend towards the symbolic (not as far as APL.. ICK!). I am in between. Yet.. when you know how all of that Math works you can look at one page of arcane symbols and comprehend it much more quickly than if you had to go through pages and pages of more verbose math.
>That is another big difference between us: I really hate functional >programming.
Well I guess to be honest I still have not bridged the gap over to purely functional way of thinking. And you do have to wonder. PG has a PhD in computer science and obviously likes thinking that way. But some serious programs *are* written in Lisp. Like the backend of Orbitz is done in Lisp and is pretty damn good at finding stuff. (A little slow at times, but never inconsistent).
I am still an OO thinker at heart. I alert my objects that I want them to do things and model programs in my head in terms of objects. I think that way easiest. I don't think it would be to difficult for me to get good with C++ given my C experience and my OO experience. Though I am sure I will have bad C habits that need eradicating I have quite a head start.
Dynamic typing. My first and cynical thought is that I am just lazy. There is just a LOT more to it. I don't like having to have an apparent compiler for my code. I don't think its needed to look at assembly to ensure my code is being compiled properly. I will put that burden on the compiler designers unless I see things are way off. Then I will get my hands dirty and figure out what is wrong. Otherwise I am willing to trade little overhead for less typing. I really don't think I will ever become a functional programmer, but maybe some day?
You are making the case for the average programmer when i tis obvious you are not. Anyone that can understand disassembled code and follow their code through it is *NOT* average anymore. You understand the cost of these things so that should make you even better in a language that gets it right almost all of the time and leaves you to focus on your problems instead of forcing you to compile code before you can check your results. I think a bit before I start writing my code, but some of the time getting in there and getting interactive with the code is great. You just can't do that with statically typed languages. You have to recompile.
So why dynamic: I know the cost overhead I am losing. I know how far from the silicon I am. (It has been guessed that each step away from the machine is an order of magnitude loss in performance). Thats ok processor speed has been increasing tremendously every year for a long time. Because we don't have to account for every last byte of data and a little excess is ok. Because an object can be *ANYTHING* I want it to be and other good programmers will understand what is happening in my code. I don't need to put a big huge sign on my identifier saying "LOOK AT ME, I AM A STRING!". The times I actually need to know the system can tell me what type the object is. Otherwise life is good. I spent 5 years in C and I got good enough that I didn't have pointer or memory related issues anymore. I thought in C at a time. But it always felt like the language was in my way of solving my problems some of the time. With Java that feeling lessened some. With Ruby that feeling almost goes away. My code is certainly no
> If you don't understand C++, you are only liable to reinvent it. Badly.
;-)
...Sigh). For Windows programs you really do need to use as little memory as you want, but you can still get away with using .NET which runs in a VM and is GCd. I really do focus on web development and network programming, though. I have written all sorts of programs such as search and data indexing stuff. It is still fast enough with hundreds of megabytes of data and it isn't C++.
Isn't the saying that you will reinvent Lisp, badly? Greenspun's Rule/Law?
This example is of an accumulator generator snagged from Paul Graham's website: http://www.paulgraham.com/accgen.html. Tailored to a problem that functional languages can solve more easily, but it is still interesting.
I would also recommend: For a Java/C++vs. Lisp comparison.
And for another programmers take on it where he tries the same thing: C++ hackers take
Also see another PG article: Succinctness is Power If you google for succinctness PGs article is the first result amusingly enough.
And here is a pretty famous study done on Erlang: Erlang Study
I hope we can at least agree that not all languages are created equal. I am honestly not interested in cloning or working in a langauge like C++. I am much more interested in languages like Lisp. I also freely admit that my OO experience leans heavily on Java, Lisp, and Ruby coding. And that I have little real C++ experience. I have done *basic* OO in my C++ programs. I used the STL for a couple of REALLY simple things in one of my later C++ programs but that is really about it. I try to use C++ in its more modern and usable context when I use it, but it is quite a time investment and I am really only after performance if I am using C++ so I keep it as lean and mean as possible and end up with C using objects with new and delete and a smattering of STL when it saves me time and I can easily do it without adversely affect the outcome of my program. So I base a lot of these assumptions on: a lot of C programming, a lot of OO programming, and a little C++ programming.
You might be onto something about the semantics of OO programming compared to the syntax of the language. It is relatively unimportant as long as the Syntax does not get in the way.
As for specific types of programs: Web development, simple and relatively complicated desktop applications. Pretty much anything that is not processor bound. I am being vague because I really do believe it in a very general sense. I do a lot of web development.. so in my world I am a little IO bound by network latency. You have to work around big warts like HTTP being stateless and generally you really want to maintain state. I also develop the occasional desktop application (Windows stuff
So in my IO bound world I use the most productive and powerful languages I can convince my team to use without secretly wanting to murder me. There is a bigger learning curve for C++. And to be honest I am not concerned about average programmers. I only want people working for/with me that can wrap their head around any programming language even assembly. So ideally I only want to work with people that can use C++ and be good at it. Only I don't want to use C++ because I think the learning curve is not needed. That said is there REALLY a reason for every programmer to understand pointers? Is it really required. We are coming to an age where entire generations of programmers are raised on Java and GCd languages. I wasn't, but I know quite a few programmers who were/are. Do you really have to know assembly on up? Is that important for every programmer to know? You can't even talk to modern x86 processors directly these
I think C++ is a fairly light weight language in Syntax. And in usage. STL syntax isn't to fun, but it is survivable. I know OO programming very well. I know C programming pretty good. I know the cost of memory and memory ownership from years and years of programming in C. I can understand and interpret x86 assembly. I can get down and dirty with the hardware and tune a C program well. What does not change is that you still have to know and use pointers and all of the syntax required to deal with them in C++. After a time it becomes second nature. And with a little experience in a debugger you can quickly track down most pointer related mischief. What you can't do is manage to write less code in C++. You can make a good run at it with STL and good architecture. However, you will still be writing more code in C++ or Java than you will in a more expressive and concise language. If you have to write less code to accomplish the same goal and you can still do it with performance that, relative to the task, is acceptable why not?
;-). It is still important. Not for memory allocation but if you don't know what the stack is and how it works you won't be as effective in Java either. I remember fixing a method that had way to much recursion. It was quite easy to determine the problem just peeking at the stack and seeing its recursion depth. Just fine for binary trees. Not so great to recurse one level deeper each time you want to spider a new website.
I admit a lot of Java/C# programmers, myself included on various occasions, can be a little wasteful. On the important stuff I try to keep the code tight and I try and ensure my objects are just as heavy as they need to be and no more. I try to ensure I don't hang on to a reference any longer than I need to. I strive for this because I know memory isn't free. And if you get to wasteful and you have an entire team that lets it slip you end up with a nasty and bloated program (regardless of the language, GC or no).
I have no problem writing OO code. I tend to prefer OO after writing so much of the stuff. The GoF pattern book was written using C++ and is still just as relevant as always. I know what the stack is too. Java has a stack too
C++ just is not as productive as some of the languages out there. Lets compare it to say.. Lisp. Lisp for an experienced programmer is a productive language. With modern hardware the cost of Lisp is not so great. A team of experienced Lisp hackers are more productive than a team of experienced C++ hackers. If your language lets you write less lines of code to achieve the same work you will be more productive. If an entire team uses this language the team will be more productive. Good programmers will not abuse a garbage collector any more than a C++ programmer would not leak memory. And you have the luxury of writing good code. And I know.. you have already covered this, but GC does completely eliminate certain kinds of memory leak issues. I know C++ is not some terrible language that produced bloated code and binaries. C++ is where I turn when performance is an absolute. So rarely is performance an absolute with modern hardware. I am doing my clients a disservice to use a language like C++ when I can do the same job for them faster with easier to use tools that let me do my job faster.
So the argument isn't against C++ because it is a terrible language that can't be used well. The argument is that statically typed languages like C, C++, Java, and C# take more lines of code than a dynamic and expressive language like Ruby or Lisp. If your program meets all of your clients criteria and runs on modern hardware and you can write it twice as fast in a dynamic language why on earth would you spend more time doing it in a language like C++? I wrote code in C long enough to know that even if you are one of the best C or C++ programmers in the world you are still at a disadvantage when compared to a great programmer that knows their way around a language like Lisp or Ruby. It isn't the programmer, it is the language
Technically I use two monitors. So I have two screens worth of 1280x1024. I code on one monitor.. which basically is a maximized window of code at a pretty reasonable font size actually. I already have relatively bad vision. Many of my fonts are a size point or two bigger usually.
;-) So I can afford to use the other brace style and still probably fit roughly the same amount of code on the screen as you can without that style. With it I could probably fit 5-10 more lines of meaningful code pretty easily. Something to think about given that I do believe seeing more code directly translates to productivity.
I do Java mostly. That is the language I "think" in and know inside and out. I have not done any serious C development in 4 years. I did a good 5 year stretch of hard C development. I am starting to use Ruby. I like Ruby because it takes less code to get things done so I can fit lots of Ruby code on the screen. So I have to agree about saving lines.
The biggest problem I have is that C++ is just not required for many types of programs. Not sure what sort of development you are doing, so it may be required. Even being one of the best few C++ coders you would be more efficient if you were as proficient in some more dynamic language. (I don't like Perl, either). There will always be a place on a development team for a "Language Expert", but generally you don't need but one of those on a pretty big team. Most programmers do tend to have one language they "think" in. Sadly mine is Java. I don't like it. I think Java is a mess. Ditto for C++. To much baggage in both (design by comittee anyone?).
For the record I still write C and or C++ in K&R style. It seems perverse not to. I guess I am used to being able to fit more lines of code on the screen. I presently can fit about 53 lines with 120 columns in my fancy GUI editor
Jeremy
I started coding doing K&R C style braces. I have used them for many many years. I have recently been trying the opening brace on a separate line. It isn't so bad. There are a LOT of languages out there other than C. You can make a bunch of logical arguments for both ways. It is almost like vi vs. emacs. I can spot blocks either way. I also do a lot of Ruby coding which doesn't even use braces and instead uses the end statement to denote the end of the block. So you actualyl *have* to know what statements can start a block to even begin to know if you should be looking for an end to the block.
:-)
As long as you are consistent with your style others will be able to read your code. Maintainability matters more than stylistic preference and both styles are maintainable. They are called STYLES after all.
And technically automatically interpreting a line without a brace as a terminated statement (IE: with the semicolon) can be just as bad as programmers that can't find a block of code. You should know the language well enough that you can interpret any common brace style. Ok.. no more nit picking.
I think one of the reasons it still dominates is it still gets used in book writing to condense lines of code. Almost all developers read code examples written here and there. I think this is big on continuing the tradition. When I was working on a my PHP book I know I used the brace on same line as the conditional method because it saved lines.
In the end being consistent trumps stylistic preference. The best argument I have seen is for condensing code. It does save a line or two here and there if you really need it. With 1280x1024 being a relatively common display resolution used by developers these days I don't think it is such a big deal to have an extra line for the braces
Jeremy
This is /.
;-) So odd someone can get it and miss it in one stroke. Ahh well.
A normal human looks at something. Thinks about it for a second and can detect sarcasm. A hacker reads it and immediately identifies the 10 million ways you are wrong before stopping to think you might not have been serious.
J/K. I do get a little carried away on the analysis without stopping to detect a more subtle point
Jeremy
The thing that strikes me about all of this is that the test is obviously rigged towards bigger businesses. Integrating systems into a big corporate environment that will make CIOs happy is all fun and good. Yet.. things like upgrading glibc and all of this policy change control is just slanting things towards a company that aims to cater to these, sometimes senseless, business requirements.
,untestable, harder to quantify items are what keep me using Linux based operating systems.
Many of the points are good. Yet.. in a small to medium sized environment you have MANY luxuries and things you just don't worry about. Change control? If something is broke I fix it. I take every best effort to not have any downtime. I make sure I am not affecting my users. So operating from those constraints: minimal downtime, don't interrupt users I go. Life is generally good. XYZ startup set out to change the world (Google) really don't give a rats ass about blessed binaries. As long as it doesn't break anything and you can stably apply it to your environment without disrupting your users who cares? Often you have to recompile your critical applications with new options anyway such that you aren't running on a vendor supplied binary. I just don't see how this test reflects how Linux is really used. In other words I think there are variablies for Linux that simply can't be included in the test because Windows can't even do it (for better or worse). These
For certain critical things it can be good to ensure that a fix doesn't break more than it solves. Yet the fix is out there and you can evaluate it then and there. That is something you just can't do in Windows. There is a total openness about the process of the patch. In MS who knows what dark magic happens between vulnerability and a "blessed" patch. In some ways they are different worlds. I can achieve my goals. Tens of thousands of other people believe in free operating systems to power their business. As long as all of this is the case the model sustains itself. So who really cares about these studies that are focusing on how Linux does with big business constraints. What does Linux really gain being inside of big business so deeply other than corporate dollars? Open software and your average american corporation have completely different ideologies. I don't know why people are so concerned about what a Microsoft study says about Linux playing in an environment rigged to favor MS.
Jeremy
That is pretty much stretching it. If you want to build a GUI based program I find it a little silly to pack your widgets completely by hand. It is just tedious. Learn how it all works.. but for the love of god don't make me build a complex GUI without a GUI designer. I have done it and can do it but I just find it tedious. Constnatly visualizing how the GUI is progressing as you throw more and more widgets/components into a particular layout format. I dare say it reduces the quality of the code because you have developers spending far to much time on tedious work and not focusing on the real problems. You do occasionally really need to create a widget or panel by hand.. so having the knowledge is still important.
And when you just plop components in place all you have made is a GUI that does nothing. The real work comes in putting code behind the widgets in a maintainable fashion. And let me tell you I have seen some really bad coding. It is encouraged because people get in this mentality that they must cram as much code into the desginer created classes/forms as possible. People use GUI forms for their model even. For their everything. That just makes the coders bad. The tools should not be blamed as heavily as the developers using them. Visual studio is the one that is bad for encouraging people to cram way to much code into the GUI classes.
The Java GUI designers out there tend to be a little better about making you glue everything together yourself. It really isn't the tools fault. It is the fact that 99.9% of people use GUIs so you need good tools to build GUIs and, generally, doing so with another GUI is easier than command line.
Tools that get abused frequently are really a problem of business culture not hacker culture. I blame lazy programmers who should be in another profession for giving GUI designers a bad rap.
Jeremy
Sad, really.
Jeremy
Actually when I sent the shopping budy "fuck you" it said, "Good grief, I can't respond to talk like that".
Jeremy
I am not sure what to think about you Silverspur. You are either a pretty smart scientific mind with a bit of a superiority complex or a complete hoax. In either case calm down a bit!
Well.. I hope you can keep it up. When relatively big amounts of money get mixed into something and you have developers from these companies mixed in it can really fubar things. Maybe only for a short period of time, maybe forever. Keep your eyes open and do what you do for the users.. not for some business!
Jeremy
And the entire Eclipse project is eclipsed by the weight of all of these businesses signing on. Eclipse is a great tool. As more and more corporate entities become involved things will become more committee driven. This will ensure that nothing useful gets done very quickly. Design by committee tends to make things slower, more cumbersome, and less innovative. Just look at Java ;-) (Ok.. that was a low blow). You don't get the vision of the creators of Java from Java. You get the vision the creators had based on Sun's need to scoop up all of the commercial developers languishing in C++ (yet another language designed by committee). It is all so much fun!
Jeremy