But isn't that precisely what object orientation was invented to solve? To find a way of unifying data transfer between absolutely everything, everywhere, by sending not raw data but objects which could then be queried to ask things like 'what kind of thing are you?' and 'give me your data in Format X, Y or Z which I can read'.
C'mon dude, you gotta be kidding me.
Object-orientation is not by itself the answer to that problem. After all, you can have perfect OO models that exist in parallel, and which are incompatible. Object-oriented models for disparate systems mean squat for interoperability without a common, well-defined domain model. Notice that I say domain model as opposed to object model. There is a very important distinction here.
In this particular case, the domain model is in respect to data communication between potentially co-located systems and the visual rendering of that communication. OO models for those systems need to be based on a universal, coherent communication domain model (OO or not). Try to pull that out with disparate teams of developers, where each band works mostly in a distributed fashion, on disparate goals, with different agendas and priorities, with no unifying time line or list of deliverable for all these teams. Furthermore, with time and effort being on a volunteering basis, individual and team drive is based in large part by ego and ideology, and all of that without having a well-defined set of stake holders.
Object orientation is not intended to solve this. You can't have that in such a largely distributed, volunteer/ego driven environment without establishing rigid communication protocols, time lines and set of deliverables. In the private sector we sometimes (in fact, many times) see failures of implementing functionally sound object models because of a lack of communication between competing groups of stake holders (developers, users, et al.) The F/OSS development model is prone to exacerbate this.
You are trying to explain the absence of something from the point of view of conceptual models, an object model in this case. But in reality, those models can only come to fruition with the establishment of communication and enforcement models. You can't put the wagon ahead of the oxen bro.
Actually it's quite the opposite. For any complex task, writing a script for MongoDB, CouchDB or TC/TT is way easier and faster than an unbearable 100-lines SQL statement, that even you are unable to understand the day after. Plus it's able to get things that just can't be written as an SQL query.
Can you provide concrete proof of this? "For any complex task" pretty much uses universal quantification over all problems dealing with data representation. Considering that some (not all) data (with its associated meaning and function) is best represented using relations, while others are better represented using network models (think cyclical graphs), and others are best represented as simple key-value mappings, I would find it hard to believe that truly and verily any complex data manipulation task is best represented writing a MongoDB/CouchDB/TC/TT script.
Now, if you decide to reply by saying "well, not all, but most", please provide proof, or at least some logical demonstration that this is indeed true. For, if it is, holy crap, you need to write a dissertation on this.
And your "we'll have to run it over the weekend because it'll kill the server" is also why when you need to extract stuff out of a large dataset, you write a script to process data in chunks, not a single SQL statement.
Who told you that for that type of task you would use a single SQL statement?
If SQL is so wonderful and the answer to everything, why do stored procedures exist?
Encapsulation. Reuse. You know, all the nice things associated to modules and procedures. Stored procedures are the same. In any non-trivial system, data might change its structure over time. Say, I have a SQL statement A that goes over one or more inter-related but heterogeneous database structures X, Y, Z, producing a set of values with structure or interface B. And imagine that SQL statement A is used at different locations in my code.
Due to business changes, to obtain set of structure B, now I have to operate with structures X, Y, Z". So the newly adapted SQL is A'. Say, I'm intelligent. So I put my SQL in a stored procedure P which is called throughout my code. Changes from A to A' are encapsulated inside the store procedure. I can unit test that store procedure and have a level of assurance (but not a certainty) that it will work throughout my code.
Or maybe I'm not intelligent; I'm an idiot that doesn't know SQL and much less stored procedures (what are stored procedures for anyways?). Then I have to go through the code replacing every instance of A into A', and unit test every changed piece of code. Man, I can understand someone not knowing SQL and stored procedures, but for f* sake, these are just CompSci 101 concepts man. Please get your basic principles right before trying to lecture on what's good or not in software.
Another good reason for using stored procedures if for fine-grained execution control. You don't want just any schmuck that is clueless about SQL to execute random SQL producing cartesian joints or a long-ass query that doesn't use an index. You test and fine tune not only your SQL and server-calling SQL code, but also the underlying data structures, partitions and indexes in your integration/UAT environment prior to deployment on production. This review and Q&A is assured by forcing every SQL statement into its own procedure.
Alas then, you simply enforce the same principles of modularity and encapsulation on SQL that you also find universally in any other modern programming language. That you cannot even come to that conclusion on your own (even if you don't know SQL) is completely unacceptable for anyone that does coding for a living.
You don't need to use a SQL database when you don't functionally need that. I'd be the first to say a lot of
Actually it's quite the opposite. For any complex task, writing a script for MongoDB, CouchDB or TC/TT is way easier and faster than an unbearable 100-lines SQL statement, that even you are unable to understand the day after. Plus it's able to get things that just can't be written as an SQL query.
Can you provide concrete proof of this? "For any complex task" pretty much uses universal quantification over all problems dealing with data representation. Considering that some (not all) data (with its associated meaning and function) is best represented using relations, while others are better represented using network models (think cyclical graphs), and others are best represented as simple key-value mappings, I would find it hard to believe that truly and verily any complex data manipulation task is best represented writing a MongoDB/CouchDB/TC/TT script.
Now, if you decide to reply by saying "well, not all, but most", please provide proof, or at least some logical demonstration that this is indeed true. For, if it is, holy crap, you need to write a dissertation on this.
And your "we'll have to run it over the weekend because it'll kill the server" is also why when you need to extract stuff out of a large dataset, you write a script to process data in chunks, not a single SQL statement. If SQL is so wonderful and the answer to everything, why do stored procedures exist?
Looks like you never dealt with denormalized and sharded data.
Denormalized data (except in certain cases) is usually a sign of bad design, not an intrinsic RDBMs attribute.
As for sharded data (assuming that it's properly normalized, otherwise see previous paragraph), and assuming that it's properly sharded among functionally-sound partitions, what's the trouble in implementing the hypothetical request? Badly partitioned data is just as denormalized data; signs of someone who didn't know what he/she was doing.
One could also imagine a hypothetical scenario where data has been entered in a non-sql, key-value store in such a way that makes it near impossible to make any sense out of it. But just as in your hypothetical counter-example, this counter-example would be an attribute of bad design and not necessarily a sign on the limitations of non-sql key-value stores.
Are you not using DHCP? I ask cause if you aren't....uh...why not?
How do DHCP for dedicated servers, switches and stuff like that?
That was a rhetorical question mind you. Sometimes even for workstations you don't use dynamic IP address (or at least leave the lease timeout set to forever) so that power users can remote connect to them from home.
Just because you have DHCP, that doesn't mean the IP addresses change with every boot. And you might be able to get the current IP-to-MAC mappings from a DHCP server, but from there you have to tie up the MAC address to a specific logical identifier to a PC and all its attributes of interest (current location within a building complex, currently assigned user, lease expiration date, associated inventory, and yada yada yada ad infinitum.)
To be fair, I almost never found it useful to maintain an IP-to-host mapping and keep it up to date (except for dedicated hardware.) But an org might ask you to do so (justifiably or not) and one has to suck it up and find a way to do it well.
These could be text files in XML for your object-relational mapping tool.
That, mate, represent much of what is broken in the current state of this industry.
The fact that so many developers waste most of their time dealing with the object/relational impedance mismatch is one the biggest mistery of our IT time.
I *think* it's because said developers need the guarantees made by top notch SQL DBs.
But why live and do plumbing between OO and RDB ? Either use an OO DB, or don't use an OO languages.
That doesn't make any sense. When it comes to modeling systems, it isn't a black-n-white thing. Some things are better represented as objects, others as procedures and others (specially data) as relations.
The greatest problem with people trying to tackle the object/relational impedance mismatch is that they don't fully understand object modeling or relational database theory at best... or as is very common, they don't understand either at all!!!
Some applications and the data they operate with lend themselves to be modeled as objects (or !gasp! procedures) operating on data rows; ergo no OO/relational mapping is needed. Batch systems and high-volume financial/manufacturing transactions come to mind.
In others, you are better off using a OR mapper; a composition/inheritance hierarchy of entities best model the system under construction, with a database being a way to persist them while providing a mean to analysis on the data itself. Monitoring systems are an example of this. Financial/manufacturing subsystems that interact with batch and high volume transaction systems, but that themselves are not part of, are also examples of this.
Other systems don't even need a relational database system, and are better off using a key/store or document-oriented database instead.
Now, to the meat of your question:
But why live and do plumbing between OO and RDB ? Either use an OO DB, or don't use an OO languages
Uhhhh, why live and do the plumbing? Well, you are at a company with large numbers of relational database systems, containing gazillionbytes of data, some 4, 7, 10 years old (depending on their business/legal obligations to retain that data.) Then, either by careful design, or pure wanton randomness, maybe you have also have a bunch of store procedures running high-volume transactions on some sort of db batch system. In essence, that data is the business' heartbeat and pulse.
Then you are set to use a OO language as a standard for in-house development... and assuming you know how to code well (as opposed to be a junior code monkey), you reap the benefits of using a OO language to tackle ever-changing business problems. You use it to rewrite and improve existing systems. You use it to add new functionality, and if you are lucky, you use it to build new subsystems that are vital to the business functioning.
It's also very likely, that the enterprise system is heterogeneous, with high running maintenance costs. Thus, adding yet another component, say, a OO database is not the way to go. Are you gonna migrate all that mass of data to it? Are you going to regression test it? Any roll-back plans in case of fubar? How will it integrate with all the other database systems? Will it be fed by one application or many? Will it be fed by relational databases in place (and viceversa)? If so, how? What's the ROI on this?
Not use a OO language because you have a relational database? Excuse for pointing out the multitude of development shops that have actually pull this out, OR mapping or not. So let's everybody throw all the existing development investment using a OO language and let's go back procedural. Oh, but we still need to maintain the existing OO systems. No problem, rewrite them procedurally. Who's gonna pay for that? The men in suits, that's who! ROI? We don't need no ROI!
That people fail at OR mapping is not an indictment of OR mapping or working to solve imp
Hey, you know there's this guy Zed who wrote the software I'm using, why don't we hire him as a consultant?' You don't. None of you. You take the software, and use it like Excalibur to slay your dragon and then take the credit for it. You don't give out any credit, and in fact, I've ran into a vast majority of you who constantly try to say that I can't code as a way of covering your ass."
I don't know in what kind of planet this tard lives, but c'mon. Does he actually believe very few developers tell their bosses they use FOSS? Does he actually believe there are no bosses out there that know?
Seriously, do your contribution because you like it, not because you expect some praise or some high chair. Nowhere in GPL or likewise licenses reads that someone cannot take FOSS code, built something with it, sell it and take credit for it without giving credit to the FOSS that he/she used. Why should it? These type of licenses are about giving some type of free choice in how to use things and how to preserve those choices as alterations get made to the code.
I don't need to give praise to the creators of proprietary systems such as Java, or Linus Torvald or the Apache folks for FOSS tools for creating a solution for someone's very specific problem. My solution is my own. It took skills that are mine and mine along, both technical and business-like to come with that solution. The only time I would ever give such credit is if my solution is legally bound to making a contribution back to the tools used.
Seriously, nothing screams "[(sour grapes+attention whore) * vaginal silicosis]^loser" more than a dude who makes FOSS contributions and cries momma because he isn't getting a cookie in return.
There are no laws preventing trained fighters from using their hands, at least in the three countries I've been, and certainly not in the state of Florida. Maybe where you live that's true. But I'd suggest you put your assumptions to the test and quote the legal passage, the one and actual ZOMG!11 legal passage that makes that stipulation.
Not exactly, but a trained fighter is not allowed to use their training against a normal slob as it is deemed "unreasonable force". Like bringing a gun to a knife fight. So the definition is close.
Where the hell did you get this stupidity from? Quote me one legal line, one article that says so. I've lived in three different countries, in each I've heard the same crap, and in each I've it's proven to be just that, bull, a urban legend. I'll take that back, I'm currently in Florida, where I know that's not the case. Who knows, there might be another wacky state in the Union that might have such a law. But until then, quote me one single legal passage that says so.
I've known a couple of amateur boxers, one retired kickboxer, three MMA fighters and quite a few BJJers. Each of them had said exactly what I'm telling you now: That the legal restriction you are talking about regarding trained fighters is complete unsubstantiated bullshit.
And most pure CS programs would do well to focus on a tool or two so that students can standardize on the tool and stop focusing on it. Unfortunately, many CS degrees are actually software engineering degrees and give a broad introduction to many languages. So many, in fact, that the students stop learning algorithms and computation because they are so focused on making the particular piece of technology work.
What's wrong with many of these schools being software engineering schools? That's what the industry need.
Besides, a good software engineering school is also a good computer science school. If it fails to teach what you claim to be teaching for pursuing programming language practice, then they are not only bad computer science schools, but bad software engineering schools as well. You can't be a good software engineer without being a good computer scientist. Besides, this alleged problem that you describe (which does exist btw) belongs to a different category of problems to be discussed.
You are simply creating a false dichotomy just for the purpose of fostering your weak line of argument.
But timothy didn't ask about a software engineering degree. He asked about a computer science degree. Computer science is the study of the topics of mathematics that relate to computation. CS programs should teach theory, algorithms, data structures, complexity, computability, logic, and the like. I disagree with themeparkphoto, though, because I think that programming languages are a very useful tool to teach these concepts. But they aren't the goal, they are only the means.
You don't know what you are talking about. The mathematical models of computation without physical boundaries (think Turing machines and their infinite tapes) provide an upper limit (or lower limit in many cases) for what can be done. Then you have mathematical models that take physical limits into consideration. Enter programming languages. You could mathematically model what you can or cannot do once you have physical limits imposed on you.
There is also type theory, compiler theory, programming language theory, theories of usability, issues regarding extensibility, maintainability, entropy of source code over time, requirement analysis, program verification, etc, etc, etc. Programming languages is where problems and solutions expressed in pure mathematical models meet their physical-bound representations.
Software engineering is an offshoot of computer science, and neither can you have the former without a background in the later, nor have the later being taught as a facilitator of the former. Furthermore, software engineering is the refinement of one of the main questions in computer science: how do code?.
To presume you can have a computer science degree without a solid foundation in programming or the basics of software engineering is utterly ridiculous. Programming languages themselves are focus of study in computer science, and they provide constrains on how fundamental concepts get implemented. There are costs and ROI factors in implementing something with a given language or technology, and that is also another focus in computer science.
Computer science is not some blindly seeking pursuit of mathematical models of computation. Computer science is about those mathematical models and the EFFICIENT models of transforming those into solutions to REAL WORLD problems. You can't have that without a solid programming/software engineering background.
I won't deny that I've seen the same type of clueless professors, but that has been the exception rather than the norm. Your personal anecdotes are not representative of academia or the IT/software industry as a whole.
The technology we are using right now to exchange posts, that's been the work (for the most part) of those PhD people you like to generalize about. Let me know when you find the next guy with a 2-year tech degree who invents a new algorithm or networking/programming paradigm;)
Well, when I see people who's majors never apply to their real life jobs, then I can start to apply it out. Why spend 4+ years learning psychology or accounting to work a high level customer service job? English majors that start doing low end accounting. Really, other than doctors and lawyers, I haven't known too many people who have worked in the field that they studied for years.
It can be argued that they got a well rounded education, but since I'm fairly sure that English and math were required at some point during their 4 years of "higher learning", I should assume that they can write something resembling a grammatically correct document, or not completely fail at making their formal presentation to executives or business partners actually add up.
That doesn't apply to everyone, but it seems to always apply more to those who's claim to fame is "I graduated, I deserve a job." It's more like, "I spent a lot of money on my degree, the world owes me now."
I'm not talking down about people who go to school. There are plenty of smart people who did, but it's not because they spent years at a university, it's because they were already smart. We have been lead to believe that to be successful you must get a degree. It's simply not true. Generally, it's a money making scheme. Universities make an absolute fortune, and the return for the customer (student) is much less than it should be. The best thing I've heard from any university graduate is "I'm proud of myself." Good. Too bad you didn't find a better way to boost your ego than either spending tens of thousands of your families money, or putting yourself so in debt that you'll be paying for years to come.
Don't assume that IT work is the same as software engineering, systems engineering, computer science or simply coding. I've done them all, including Tier III support (SysAdmin, App Container Admin, dude-who-tweaks-shit-to-make-production-run etc) as well as software engineering and just plain-dumb coding. No fucking way that I could have done the last two, to the level that I've done them, for the projects that I was involved with, without a college degree, including algorithm analysis or automata theory.
But for IT work, yeah, I can see a 2-year technical degree being more than sufficient for it.
Obviously for IT work, I would do the same as you - hire people who tinkers with stuff over someone with a MS degree in CS who has never assembled a small home network with linux using his home-made twisted cable. But for software engineering or simply foot-soldier coding, forget it. I would prefer someone that has a degree and experienced, followed by someone with a degree and who demonstrate good knowledge when faced with a good set of questoins, followed by someone that does not have a degree, but has a shitload of experience in software engineering or coding (you know, the old-timer type of coder who has been at it for 2 decades).
Summary: IT work =/= software development. Background requirements are different for both.
If the teacher needs the answer handed to them they shouldn't be teaching the class.
You don't know what you are talking about. Teachers don't use answer sheets because they need the answers, but because of time management issues. Have you ever taught a class before? Or several classes on the same semester? Having to come up with non-trivial exercises, with answers already printed for discussion in a class?
You can't force teachers not just to read the book, but to proof read it, not unless you actually pay them for. And I know what you are going to say: no, that's not part of their jobs, nor they get paid for that.
This would be akin of me doing comprehensive regression and unit testing on 3rd party software libraries every time I use them in a software project. Obviously one does research to know what library to use, but that's research in terms of expected gains. You take a library or piece of code or whatever on reasonable premises that it is production quality. Same with books.
I know you want to paint this as a simple case that can be solved with the silver bullet that is open source. But it isn't. Know the subject of teaching (or any subject) before trying to find a solution for its problems. Try it sometime.
I don't think this guy was necessarily stupid or foolish - I think he was careless after being so used to the routine of publish or perish that he forgot who his collaborators were, and that was his mistake.
After being warned on the subject, and knowing full well the stakes (no one lives under a rock long enough to not know), a sheer amount of stupidity and lack of judgment is required to commit such a mistake.
And this is how ITAR is damaging to our national security. As the DOE and DOD are major funding agencies at universities and national labs, we are now creating a research system that prevents foreign nationals from participating. And since they are a large percentage of our grad students, that's a major problem. It subsequently makes the US a less enticing place for the skilled students we'd like to immigrate here.
This is stupid. You might have an argument if the majority of science research in the US were subject to these regulations. Newsflash: they are not.
Only a very small amount of research in academia is subject to these type of regulations. Ergo, these regulations do not prevent foreign students from conducting research in the many, many, but really, many more areas of studies that are not tied to classified material.
If we were to follow your line of logic, we could then argue that hiring restrictions in DOE projects hurt IT/science in the US since they prevent non-US citizens from getting hired. Obviously, that has not been the case.
So, how does somebody who works a minimum of 60 hours over 4 days, often adding another 12 another day, and sometimes working 7-10 days straight like this, stay in shape? I can't hold a workout schedule, (which every person I've talked to in my history says is necessary to stay in shape) and I can't 'wake up early' or 'work out before bed' because I need sleep. Any thoughts/opinions/suggestions?"
Any thoughts/opinions/suggestions?"
Yeah, don't be such a "oh it's so hard" EMO dude.
Seriously. You can't hold onto a workout schedule? How about when you drive back home, you immediately put some shorts and a pair of tennis shoes and go for a 10 minute jog?
You don't have energy for a 10-minute jog? How about a 10-minute brisk walk then? And how about setting a timer at work that rings every 30-60 minutes as a reminder to get off the chair and stretch (flexibility is part of being healthy, perhaps more so than being lean.)
And on your free days, whichever free days you get, regardless of the the frequency, go jog some more, do some push ups. Even if it's only one day every two weeks, you sign up for a gym and you go.
Better yet, find a gym close to work (and not close to your home). That way you forced yourself to work out even by a little after work (as opposed to drive 1.5 hours and be too tired as shit to work out when you get home.)
Get a Billy Blank's Tae Bo DVD and do, say 15 minutes of it on your free day, then little by little increase that. Wake up 10 minutes early and do some jumping jacks and push ups.
Yeah, yeah, I know, it's nowhere near to be an ideal workout schedule, but then again, there are people out there who can't study full time, but take one class at a time, and after twice or trice the amount of time, they get a master's degree. Which brings me to the following: how bad do you want it?
Educate yourself about your eating habits, and work out whenever you can, even if it means just one set of push ups and 50 jumping jacks every time you wake up. At the very least it will provide you with the mental boost that you DID something.
In general, long hours, commutes from hell, and a fucked up schedule is not a barrier to work out. Having children usually is. I KNOW BOTH. So, from the bottom of my heart I'm telling you to change your mentality - a mentality where you feel there is so much going on in your professional life that you cannot work out...
... because it's bull. Sorry, but it's true.
Also, I'd say that you need to re-evaluate your working conditions at some point. I used to work like a fucking drone, and in the end, it's not fucking worth it. So you gotta do whatever it takes to get to a professional and financial point where you indeed, really and truly do not need to work like that. 50 hours top per week, anything else is just hamster-running-in-circle bullshit.
People who work like that ALL THE TIME, specially those who do it on purpose to get some retarded executive career objective are just retarded slaves to the grind.
Unless you have your own company which is struggling, or are a single parent or are a recent immigrant with a bunch of kids to support, you don't need to work like that. You should not. Get some balance in your professional life so that you can better take care of your self, physically, educationally, socially and emotionally.
The problem: when I am home I don't want to carry my phone on my person, AND I don't want to have to run (possibly up or down stairs) to answer a call.
No wonder we are nation of fucking fatsoes and pencilnecks. I don't carry my cell phone with me at home, but that doesn't stop me from running, what, 20-30 feet, to get it when it rings.
Seriously, this was a lame excuse to throw some money @ technology for the hell of it while moving one step closer to be one of those Wall-e space fatties on floating platforms. Amazing that you even call that "a problem".
He isn't out-of-date. I have to suffer Java 1.6 at my college. The VM is still slow to start, and the GUI libraries still suck.
I'm looking forward to see you implementing large-scale enterprise integration solutions for heterogeneous environments in C or assembly, cuz, you know, the VM is still slow.
Reality check dude:
1. Speed comparisons in pet/schoolwork projects don't count.
2. Speed is context-sensitive. You don't compare speed of application programming languages versus speed of system programming languages.
3. Performance is a factor that needs to be weighted out against other concerns such as deployability, extensibility, interoperability, and even the business requirements that drive an implementation's effort.
4. Real-life applications that matter run for weeks, months, even years... so cares if the VM is still slow to start.
5. GUI libraries might suck, but they are certainly easier to use than *nix widgets or MSVC stuff. Use the right tool for the specific task at hand, and for some tasks (but not all) Java GUI libraries work just fine.
6. Who cares if Java GUI libraries suck. Most java apps are web-based or run on the back-end anyways.
Slashdot Mirror
Move away to what, exactly?
RH.
But isn't that precisely what object orientation was invented to solve? To find a way of unifying data transfer between absolutely everything, everywhere, by sending not raw data but objects which could then be queried to ask things like 'what kind of thing are you?' and 'give me your data in Format X, Y or Z which I can read'.
C'mon dude, you gotta be kidding me.
Object-orientation is not by itself the answer to that problem. After all, you can have perfect OO models that exist in parallel, and which are incompatible. Object-oriented models for disparate systems mean squat for interoperability without a common, well-defined domain model. Notice that I say domain model as opposed to object model. There is a very important distinction here. In this particular case, the domain model is in respect to data communication between potentially co-located systems and the visual rendering of that communication. OO models for those systems need to be based on a universal, coherent communication domain model (OO or not). Try to pull that out with disparate teams of developers, where each band works mostly in a distributed fashion, on disparate goals, with different agendas and priorities, with no unifying time line or list of deliverable for all these teams. Furthermore, with time and effort being on a volunteering basis, individual and team drive is based in large part by ego and ideology, and all of that without having a well-defined set of stake holders.
Object orientation is not intended to solve this. You can't have that in such a largely distributed, volunteer/ego driven environment without establishing rigid communication protocols, time lines and set of deliverables. In the private sector we sometimes (in fact, many times) see failures of implementing functionally sound object models because of a lack of communication between competing groups of stake holders (developers, users, et al.) The F/OSS development model is prone to exacerbate this.
You are trying to explain the absence of something from the point of view of conceptual models, an object model in this case. But in reality, those models can only come to fruition with the establishment of communication and enforcement models. You can't put the wagon ahead of the oxen bro.
Actually it's quite the opposite. For any complex task, writing a script for MongoDB, CouchDB or TC/TT is way easier and faster than an unbearable 100-lines SQL statement, that even you are unable to understand the day after. Plus it's able to get things that just can't be written as an SQL query.
Can you provide concrete proof of this? "For any complex task" pretty much uses universal quantification over all problems dealing with data representation. Considering that some (not all) data (with its associated meaning and function) is best represented using relations, while others are better represented using network models (think cyclical graphs), and others are best represented as simple key-value mappings, I would find it hard to believe that truly and verily any complex data manipulation task is best represented writing a MongoDB/CouchDB/TC/TT script.
Now, if you decide to reply by saying "well, not all, but most", please provide proof, or at least some logical demonstration that this is indeed true. For, if it is, holy crap, you need to write a dissertation on this.
And your "we'll have to run it over the weekend because it'll kill the server" is also why when you need to extract stuff out of a large dataset, you write a script to process data in chunks, not a single SQL statement.
Who told you that for that type of task you would use a single SQL statement?
If SQL is so wonderful and the answer to everything, why do stored procedures exist?
Encapsulation. Reuse. You know, all the nice things associated to modules and procedures. Stored procedures are the same. In any non-trivial system, data might change its structure over time. Say, I have a SQL statement A that goes over one or more inter-related but heterogeneous database structures X, Y, Z, producing a set of values with structure or interface B. And imagine that SQL statement A is used at different locations in my code.
Due to business changes, to obtain set of structure B, now I have to operate with structures X, Y, Z". So the newly adapted SQL is A'. Say, I'm intelligent. So I put my SQL in a stored procedure P which is called throughout my code. Changes from A to A' are encapsulated inside the store procedure. I can unit test that store procedure and have a level of assurance (but not a certainty) that it will work throughout my code.
Or maybe I'm not intelligent; I'm an idiot that doesn't know SQL and much less stored procedures (what are stored procedures for anyways?). Then I have to go through the code replacing every instance of A into A', and unit test every changed piece of code. Man, I can understand someone not knowing SQL and stored procedures, but for f* sake, these are just CompSci 101 concepts man. Please get your basic principles right before trying to lecture on what's good or not in software.
Another good reason for using stored procedures if for fine-grained execution control. You don't want just any schmuck that is clueless about SQL to execute random SQL producing cartesian joints or a long-ass query that doesn't use an index. You test and fine tune not only your SQL and server-calling SQL code, but also the underlying data structures, partitions and indexes in your integration/UAT environment prior to deployment on production. This review and Q&A is assured by forcing every SQL statement into its own procedure.
Alas then, you simply enforce the same principles of modularity and encapsulation on SQL that you also find universally in any other modern programming language. That you cannot even come to that conclusion on your own (even if you don't know SQL) is completely unacceptable for anyone that does coding for a living.
You don't need to use a SQL database when you don't functionally need that. I'd be the first to say a lot of
Actually it's quite the opposite. For any complex task, writing a script for MongoDB, CouchDB or TC/TT is way easier and faster than an unbearable 100-lines SQL statement, that even you are unable to understand the day after. Plus it's able to get things that just can't be written as an SQL query.
Can you provide concrete proof of this? "For any complex task" pretty much uses universal quantification over all problems dealing with data representation. Considering that some (not all) data (with its associated meaning and function) is best represented using relations, while others are better represented using network models (think cyclical graphs), and others are best represented as simple key-value mappings, I would find it hard to believe that truly and verily any complex data manipulation task is best represented writing a MongoDB/CouchDB/TC/TT script.
Now, if you decide to reply by saying "well, not all, but most", please provide proof, or at least some logical demonstration that this is indeed true. For, if it is, holy crap, you need to write a dissertation on this.
And your "we'll have to run it over the weekend because it'll kill the server" is also why when you need to extract stuff out of a large dataset, you write a script to process data in chunks, not a single SQL statement. If SQL is so wonderful and the answer to everything, why do stored procedures exist?
Looks like you never dealt with denormalized and sharded data.
Denormalized data (except in certain cases) is usually a sign of bad design, not an intrinsic RDBMs attribute.
As for sharded data (assuming that it's properly normalized, otherwise see previous paragraph), and assuming that it's properly sharded among functionally-sound partitions, what's the trouble in implementing the hypothetical request? Badly partitioned data is just as denormalized data; signs of someone who didn't know what he/she was doing.
One could also imagine a hypothetical scenario where data has been entered in a non-sql, key-value store in such a way that makes it near impossible to make any sense out of it. But just as in your hypothetical counter-example, this counter-example would be an attribute of bad design and not necessarily a sign on the limitations of non-sql key-value stores.
Some people are able to grasp new concepts and others cant???
I'll get off your lawn now.
And the later types are the ones that write shitty code on a regular basis? /sarcasm-gone-amock :-/
Are you not using DHCP? I ask cause if you aren't....uh...why not?
How do DHCP for dedicated servers, switches and stuff like that?
That was a rhetorical question mind you. Sometimes even for workstations you don't use dynamic IP address (or at least leave the lease timeout set to forever) so that power users can remote connect to them from home.
Just because you have DHCP, that doesn't mean the IP addresses change with every boot. And you might be able to get the current IP-to-MAC mappings from a DHCP server, but from there you have to tie up the MAC address to a specific logical identifier to a PC and all its attributes of interest (current location within a building complex, currently assigned user, lease expiration date, associated inventory, and yada yada yada ad infinitum.)
To be fair, I almost never found it useful to maintain an IP-to-host mapping and keep it up to date (except for dedicated hardware.) But an org might ask you to do so (justifiably or not) and one has to suck it up and find a way to do it well.
These could be text files in XML for your object-relational mapping tool.
That, mate, represent much of what is broken in the current state of this industry.
The fact that so many developers waste most of their time dealing with the object/relational impedance mismatch is one the biggest mistery of our IT time.
I *think* it's because said developers need the guarantees made by top notch SQL DBs.
But why live and do plumbing between OO and RDB ? Either use an OO DB, or don't use an OO languages.
That doesn't make any sense. When it comes to modeling systems, it isn't a black-n-white thing. Some things are better represented as objects, others as procedures and others (specially data) as relations.
The greatest problem with people trying to tackle the object/relational impedance mismatch is that they don't fully understand object modeling or relational database theory at best... or as is very common, they don't understand either at all!!!
Some applications and the data they operate with lend themselves to be modeled as objects (or !gasp! procedures) operating on data rows; ergo no OO/relational mapping is needed. Batch systems and high-volume financial/manufacturing transactions come to mind.
In others, you are better off using a OR mapper; a composition/inheritance hierarchy of entities best model the system under construction, with a database being a way to persist them while providing a mean to analysis on the data itself. Monitoring systems are an example of this. Financial/manufacturing subsystems that interact with batch and high volume transaction systems, but that themselves are not part of, are also examples of this.
Other systems don't even need a relational database system, and are better off using a key/store or document-oriented database instead.
Now, to the meat of your question:
But why live and do plumbing between OO and RDB ? Either use an OO DB, or don't use an OO languages
Uhhhh, why live and do the plumbing? Well, you are at a company with large numbers of relational database systems, containing gazillionbytes of data, some 4, 7, 10 years old (depending on their business/legal obligations to retain that data.) Then, either by careful design, or pure wanton randomness, maybe you have also have a bunch of store procedures running high-volume transactions on some sort of db batch system. In essence, that data is the business' heartbeat and pulse.
Then you are set to use a OO language as a standard for in-house development... and assuming you know how to code well (as opposed to be a junior code monkey), you reap the benefits of using a OO language to tackle ever-changing business problems. You use it to rewrite and improve existing systems. You use it to add new functionality, and if you are lucky, you use it to build new subsystems that are vital to the business functioning.
It's also very likely, that the enterprise system is heterogeneous, with high running maintenance costs. Thus, adding yet another component, say, a OO database is not the way to go. Are you gonna migrate all that mass of data to it? Are you going to regression test it? Any roll-back plans in case of fubar? How will it integrate with all the other database systems? Will it be fed by one application or many? Will it be fed by relational databases in place (and viceversa)? If so, how? What's the ROI on this?
Not use a OO language because you have a relational database? Excuse for pointing out the multitude of development shops that have actually pull this out, OR mapping or not. So let's everybody throw all the existing development investment using a OO language and let's go back procedural. Oh, but we still need to maintain the existing OO systems. No problem, rewrite them procedurally. Who's gonna pay for that? The men in suits, that's who! ROI? We don't need no ROI!
That people fail at OR mapping is not an indictment of OR mapping or working to solve imp
Hey, you know there's this guy Zed who wrote the software I'm using, why don't we hire him as a consultant?' You don't. None of you. You take the software, and use it like Excalibur to slay your dragon and then take the credit for it. You don't give out any credit, and in fact, I've ran into a vast majority of you who constantly try to say that I can't code as a way of covering your ass."
I don't know in what kind of planet this tard lives, but c'mon. Does he actually believe very few developers tell their bosses they use FOSS? Does he actually believe there are no bosses out there that know?
Seriously, do your contribution because you like it, not because you expect some praise or some high chair. Nowhere in GPL or likewise licenses reads that someone cannot take FOSS code, built something with it, sell it and take credit for it without giving credit to the FOSS that he/she used. Why should it? These type of licenses are about giving some type of free choice in how to use things and how to preserve those choices as alterations get made to the code.
I don't need to give praise to the creators of proprietary systems such as Java, or Linus Torvald or the Apache folks for FOSS tools for creating a solution for someone's very specific problem. My solution is my own. It took skills that are mine and mine along, both technical and business-like to come with that solution. The only time I would ever give such credit is if my solution is legally bound to making a contribution back to the tools used.
Seriously, nothing screams "[(sour grapes+attention whore) * vaginal silicosis]^loser" more than a dude who makes FOSS contributions and cries momma because he isn't getting a cookie in return.
There are no laws preventing trained fighters from using their hands, at least in the three countries I've been, and certainly not in the state of Florida. Maybe where you live that's true. But I'd suggest you put your assumptions to the test and quote the legal passage, the one and actual ZOMG!11 legal passage that makes that stipulation.
Not exactly, but a trained fighter is not allowed to use their training against a normal slob as it is deemed "unreasonable force". Like bringing a gun to a knife fight. So the definition is close.
Where the hell did you get this stupidity from? Quote me one legal line, one article that says so. I've lived in three different countries, in each I've heard the same crap, and in each I've it's proven to be just that, bull, a urban legend. I'll take that back, I'm currently in Florida, where I know that's not the case. Who knows, there might be another wacky state in the Union that might have such a law. But until then, quote me one single legal passage that says so.
I've known a couple of amateur boxers, one retired kickboxer, three MMA fighters and quite a few BJJers. Each of them had said exactly what I'm telling you now: That the legal restriction you are talking about regarding trained fighters is complete unsubstantiated bullshit.
And most pure CS programs would do well to focus on a tool or two so that students can standardize on the tool and stop focusing on it. Unfortunately, many CS degrees are actually software engineering degrees and give a broad introduction to many languages. So many, in fact, that the students stop learning algorithms and computation because they are so focused on making the particular piece of technology work.
What's wrong with many of these schools being software engineering schools? That's what the industry need.
Besides, a good software engineering school is also a good computer science school. If it fails to teach what you claim to be teaching for pursuing programming language practice, then they are not only bad computer science schools, but bad software engineering schools as well. You can't be a good software engineer without being a good computer scientist. Besides, this alleged problem that you describe (which does exist btw) belongs to a different category of problems to be discussed.
You are simply creating a false dichotomy just for the purpose of fostering your weak line of argument.
But timothy didn't ask about a software engineering degree. He asked about a computer science degree. Computer science is the study of the topics of mathematics that relate to computation. CS programs should teach theory, algorithms, data structures, complexity, computability, logic, and the like. I disagree with themeparkphoto, though, because I think that programming languages are a very useful tool to teach these concepts. But they aren't the goal, they are only the means.
You don't know what you are talking about. The mathematical models of computation without physical boundaries (think Turing machines and their infinite tapes) provide an upper limit (or lower limit in many cases) for what can be done. Then you have mathematical models that take physical limits into consideration. Enter programming languages. You could mathematically model what you can or cannot do once you have physical limits imposed on you.
There is also type theory, compiler theory, programming language theory, theories of usability, issues regarding extensibility, maintainability, entropy of source code over time, requirement analysis, program verification, etc, etc, etc. Programming languages is where problems and solutions expressed in pure mathematical models meet their physical-bound representations.
Software engineering is an offshoot of computer science, and neither can you have the former without a background in the later, nor have the later being taught as a facilitator of the former. Furthermore, software engineering is the refinement of one of the main questions in computer science: how do code?.
To presume you can have a computer science degree without a solid foundation in programming or the basics of software engineering is utterly ridiculous. Programming languages themselves are focus of study in computer science, and they provide constrains on how fundamental concepts get implemented. There are costs and ROI factors in implementing something with a given language or technology, and that is also another focus in computer science.
Computer science is not some blindly seeking pursuit of mathematical models of computation. Computer science is about those mathematical models and the EFFICIENT models of transforming those into solutions to REAL WORLD problems. You can't have that without a solid programming/software engineering background.
No one is saying that GOOD managers aren't skilled, just that they've never even heard of a good one.
Probably because "they" have very limited work experiences (in terms of years, # of companies or domains.)
The technology we are using right now to exchange posts, that's been the work (for the most part) of those PhD people you like to generalize about. Let me know when you find the next guy with a 2-year tech degree who invents a new algorithm or networking/programming paradigm ;)
Well, when I see people who's majors never apply to their real life jobs, then I can start to apply it out. Why spend 4+ years learning psychology or accounting to work a high level customer service job? English majors that start doing low end accounting. Really, other than doctors and lawyers, I haven't known too many people who have worked in the field that they studied for years.
It can be argued that they got a well rounded education, but since I'm fairly sure that English and math were required at some point during their 4 years of "higher learning", I should assume that they can write something resembling a grammatically correct document, or not completely fail at making their formal presentation to executives or business partners actually add up.
That doesn't apply to everyone, but it seems to always apply more to those who's claim to fame is "I graduated, I deserve a job." It's more like, "I spent a lot of money on my degree, the world owes me now."
I'm not talking down about people who go to school. There are plenty of smart people who did, but it's not because they spent years at a university, it's because they were already smart. We have been lead to believe that to be successful you must get a degree. It's simply not true. Generally, it's a money making scheme. Universities make an absolute fortune, and the return for the customer (student) is much less than it should be. The best thing I've heard from any university graduate is "I'm proud of myself." Good. Too bad you didn't find a better way to boost your ego than either spending tens of thousands of your families money, or putting yourself so in debt that you'll be paying for years to come.
Don't assume that IT work is the same as software engineering, systems engineering, computer science or simply coding. I've done them all, including Tier III support (SysAdmin, App Container Admin, dude-who-tweaks-shit-to-make-production-run etc) as well as software engineering and just plain-dumb coding. No fucking way that I could have done the last two, to the level that I've done them, for the projects that I was involved with, without a college degree, including algorithm analysis or automata theory.
But for IT work, yeah, I can see a 2-year technical degree being more than sufficient for it.
Obviously for IT work, I would do the same as you - hire people who tinkers with stuff over someone with a MS degree in CS who has never assembled a small home network with linux using his home-made twisted cable. But for software engineering or simply foot-soldier coding, forget it. I would prefer someone that has a degree and experienced, followed by someone with a degree and who demonstrate good knowledge when faced with a good set of questoins, followed by someone that does not have a degree, but has a shitload of experience in software engineering or coding (you know, the old-timer type of coder who has been at it for 2 decades).
Summary: IT work =/= software development. Background requirements are different for both.
If the teacher needs the answer handed to them they shouldn't be teaching the class.
You don't know what you are talking about. Teachers don't use answer sheets because they need the answers, but because of time management issues. Have you ever taught a class before? Or several classes on the same semester? Having to come up with non-trivial exercises, with answers already printed for discussion in a class?
You can't force teachers not just to read the book, but to proof read it, not unless you actually pay them for. And I know what you are going to say: no, that's not part of their jobs, nor they get paid for that.
This would be akin of me doing comprehensive regression and unit testing on 3rd party software libraries every time I use them in a software project. Obviously one does research to know what library to use, but that's research in terms of expected gains. You take a library or piece of code or whatever on reasonable premises that it is production quality. Same with books.
I know you want to paint this as a simple case that can be solved with the silver bullet that is open source. But it isn't. Know the subject of teaching (or any subject) before trying to find a solution for its problems. Try it sometime.
I don't think this guy was necessarily stupid or foolish - I think he was careless after being so used to the routine of publish or perish that he forgot who his collaborators were, and that was his mistake.
After being warned on the subject, and knowing full well the stakes (no one lives under a rock long enough to not know), a sheer amount of stupidity and lack of judgment is required to commit such a mistake.
And this is how ITAR is damaging to our national security. As the DOE and DOD are major funding agencies at universities and national labs, we are now creating a research system that prevents foreign nationals from participating. And since they are a large percentage of our grad students, that's a major problem. It subsequently makes the US a less enticing place for the skilled students we'd like to immigrate here.
This is stupid. You might have an argument if the majority of science research in the US were subject to these regulations. Newsflash: they are not.
Only a very small amount of research in academia is subject to these type of regulations. Ergo, these regulations do not prevent foreign students from conducting research in the many, many, but really, many more areas of studies that are not tied to classified material.
If we were to follow your line of logic, we could then argue that hiring restrictions in DOE projects hurt IT/science in the US since they prevent non-US citizens from getting hired. Obviously, that has not been the case.
So, how does somebody who works a minimum of 60 hours over 4 days, often adding another 12 another day, and sometimes working 7-10 days straight like this, stay in shape? I can't hold a workout schedule, (which every person I've talked to in my history says is necessary to stay in shape) and I can't 'wake up early' or 'work out before bed' because I need sleep. Any thoughts/opinions/suggestions?"
Any thoughts/opinions/suggestions?"
Yeah, don't be such a "oh it's so hard" EMO dude.
Seriously. You can't hold onto a workout schedule? How about when you drive back home, you immediately put some shorts and a pair of tennis shoes and go for a 10 minute jog?
You don't have energy for a 10-minute jog? How about a 10-minute brisk walk then? And how about setting a timer at work that rings every 30-60 minutes as a reminder to get off the chair and stretch (flexibility is part of being healthy, perhaps more so than being lean.)
And on your free days, whichever free days you get, regardless of the the frequency, go jog some more, do some push ups. Even if it's only one day every two weeks, you sign up for a gym and you go.
Better yet, find a gym close to work (and not close to your home). That way you forced yourself to work out even by a little after work (as opposed to drive 1.5 hours and be too tired as shit to work out when you get home.)
Get a Billy Blank's Tae Bo DVD and do, say 15 minutes of it on your free day, then little by little increase that. Wake up 10 minutes early and do some jumping jacks and push ups.
Yeah, yeah, I know, it's nowhere near to be an ideal workout schedule, but then again, there are people out there who can't study full time, but take one class at a time, and after twice or trice the amount of time, they get a master's degree. Which brings me to the following: how bad do you want it?
Educate yourself about your eating habits, and work out whenever you can, even if it means just one set of push ups and 50 jumping jacks every time you wake up. At the very least it will provide you with the mental boost that you DID something.
In general, long hours, commutes from hell, and a fucked up schedule is not a barrier to work out. Having children usually is. I KNOW BOTH. So, from the bottom of my heart I'm telling you to change your mentality - a mentality where you feel there is so much going on in your professional life that you cannot work out...
Also, I'd say that you need to re-evaluate your working conditions at some point. I used to work like a fucking drone, and in the end, it's not fucking worth it. So you gotta do whatever it takes to get to a professional and financial point where you indeed, really and truly do not need to work like that. 50 hours top per week, anything else is just hamster-running-in-circle bullshit.
People who work like that ALL THE TIME, specially those who do it on purpose to get some retarded executive career objective are just retarded slaves to the grind.
Unless you have your own company which is struggling, or are a single parent or are a recent immigrant with a bunch of kids to support, you don't need to work like that. You should not. Get some balance in your professional life so that you can better take care of your self, physically, educationally, socially and emotionally.
Good luck brother.
The problem: when I am home I don't want to carry my phone on my person, AND I don't want to have to run (possibly up or down stairs) to answer a call.
No wonder we are nation of fucking fatsoes and pencilnecks. I don't carry my cell phone with me at home, but that doesn't stop me from running, what, 20-30 feet, to get it when it rings.
Seriously, this was a lame excuse to throw some money @ technology for the hell of it while moving one step closer to be one of those Wall-e space fatties on floating platforms. Amazing that you even call that "a problem" .
He isn't out-of-date. I have to suffer Java 1.6 at my college. The VM is still slow to start, and the GUI libraries still suck.
I'm looking forward to see you implementing large-scale enterprise integration solutions for heterogeneous environments in C or assembly, cuz, you know, the VM is still slow.
Reality check dude:
1. Speed comparisons in pet/schoolwork projects don't count.
2. Speed is context-sensitive. You don't compare speed of application programming languages versus speed of system programming languages.
3. Performance is a factor that needs to be weighted out against other concerns such as deployability, extensibility, interoperability, and even the business requirements that drive an implementation's effort.
4. Real-life applications that matter run for weeks, months, even years... so cares if the VM is still slow to start.
5. GUI libraries might suck, but they are certainly easier to use than *nix widgets or MSVC stuff. Use the right tool for the specific task at hand, and for some tasks (but not all) Java GUI libraries work just fine.
6. Who cares if Java GUI libraries suck. Most java apps are web-based or run on the back-end anyways.
As Emperor Palpatine said - let the hate flow through you.
My condolences to Mr. Ligesh's family.
Do you have an idea what "functional programming" really means?