I think any grown up, and specially a techie, will understand that this is most likely related to a poorly written automatic content-verification system rather than an actual intent to shut down the site.
If you actually take time to read the letter, you'll see the matter can most likely be solved in a civilized manner. But no... someone had to make an issue out of this and... post it as news on Slashdot? Oh please... c'mon. Please please don't become just another sensationalist media, ok?:)
IMHO, it really seems obvious that it's a misunderstanding. If it's not, then it's just a stupidity, and should be ignored as such, not brought into the limelight as "news". Geesh, there's no need for/. to sink deep below water level.:p
As/. reader, I could really do well w/o having to read this kind of stupid stuff. At least post it elsewhere other than on the mainpage.
Just my opinion, for what it's worth - no harm intended.
Well, one thing with Borland that needs saying is that even if they discontinue the product (BC++), you do not necessarily get stuck - the code for the VCL is available, so one can move its project to another development enviroment (like MSVS) with little effort. It's not an instant move but at least it's feasible.
I'm trying to investigate all possible avenues, weighting the cost of having to backtrack later. Funny that while we were having this discussion, someone posted a newspiece about Gambas, a VB like language and IDE. While it's not a choice (maturity, language), it's still interesting to see new stuff turning up. As in many other things, it's also a matter of what the target audience is, for whatever you're developing.
As for having a degree of latitude, it also means that if we do get locked into a corner I'll bear the weight of a bad decision. The last time I was in a situation like yours... I ended up working in VB for 3 months. Served me a lesson on what NOT to do in the future.:) Funny how 6 months ago I'd have laughed at these concerns and would have kept typing C++/OpenGL in the beloved screen/VI combo (with the occasional cross-compile to windows). While that hasn't changed, a lot more was added to the batch.;)
At the moment, I'll probably bite the bullet and go with C# - it's a pretty elegant language. Mono seems quite able to run the simple stuff I've thrown at it, so we get cross-platform for free, and while the target audience is Windows, we hope to eventually be able to convince them to move.:p
Feel free to reach me via email at this same username over at users.sf.net, I'd be glad to continue conversation.
I wouldn't go as far as saying "MS only". Actually, Borland was the first to come up with a product that had that concept (Deplhi). It's not a coincidence that the lead architect for Delphi is behind C#/.NET.:) As for alternatives to MS, all Borland tools still have that concept, which gives you Delphi, BC++ (back to the original topic) and even JBuilder. Each one has its perks (MS too).
As for data-aware controls... I sense an idea forming. I must admit I never did an extensive search to see if the idea exists past those Borland/MS tools, but now that I think of it...:) To be honest, I only recently started feeling a need for powerful RAD enviroments, (I'm a screen/vi/gcc person). I'll take those leads and see what shows up. Maybe that's a spot for improvement in opensource toolkits...
Thank you for your comment, I really appreciate an alternative vision.:)
I'm not picky when it comes to languages, as long as they allow for some degree of expressiveness (read sintactic sugar) and don't force the programmer to write too much "dumb"/pointless code (which is why I'm not fond of Java).
I've done a bit of work in Python, in an
UO server emulator, and although it's used as a scripting language there, I did notice that most of the recent work tended to be less on the "core" (C) and more in python itself. So, outside a RAD context, I have no problem with it, on the contrary, as it enforces some good practices like propper indentation.;)
But in a RAD context, besides a "form designer", I also really require some degree of "database access/integration". I'm talking about data-aware controls, where you just point a textfield to a (dataset,field) and it automagically shows the current record value. Or a datagrid. It's not that I wouldn't develop without those features on my own work. But I also need to setup teams to develop "braindead" software fast, and those features equal productivity (speed of development and less bugs). Many argue "that's for wimps", but I'll discard those comments as being from people who never had to write boring software for a living.:)
At the moment I'm looking at SharpDevelop/MonoDevelop, and although I'm naturally resistant to MS, they did get ir right this time on several levels, so for productive enviroments, I might get people going with Mono/.NET/P.NET. But I'd be more than willing to try alternatives. Do you (or anyone else) have any ideas for an IDE that allows form designing and a toolkit with data-aware controls implemented?
You're totally missing the point. I'm talking about doing something like a.label = "123"
And having the setter for the "label" property executed (eg, updating some display), instead of doing a.setLabel( "123" )
Some people argue that languages like C# only add sintactic sugar. And you know what? They might be right, but sintactic sugar helps readability and expressiveness. Wasn't for sintactic sugar we'de all still be programming assembly, and from an evolutionary perspective, we'de still have about 14 words, one of which would be "ugh".:)
I'm sorry to inform you that you've totally misguided your anger.:)
I believe in the concept, but the sole fact that I'm seeking information should have spared you some typing.
And why am I answering this? Dunno... it's amusing how people really take time to post comments like yours, so I'll amuse the readers even more by answering.
I know how you feel. Personally I feel there's a distinction between trying to spare the programmer from writing boring code and thinking the programmer is a moron.
Java *limits* what you can do and ultimately, the structuring of your code. It forces you to write long sentences and code that doesn't really add anything to the program.
I've mentioned this article before, but I really believe it to show some very valid points and the way they approached things on C#.
Bear in mind that I am mostly a C and C++ person (well, among other 10), and I also believe there are different languages for different jobs. But for RAD and solid structuring, I am desperatly in need to find an alternative to C++, if only because it's getting harder to recruit talented people.
This isn't directly related to BC++, but it's in line with my other post slightly above. It's related to looking for alternatives, in the current age of Java,.NET and Mono.
For the last 8 hours after my other post on this thread, I've been searching the net for information regarding C#, CIL, Mono, comparisons to Java (with usability in mind, not zealotism), etc. And one thing is for sure:.NET and CIL is good technology - I hate to admit it, but MS has something good there. It is not a surprise, as it comes a LOT from the same person that designed TorboPascal, Delphi and now C#. I recommend those interested to read an interview here and pay attention to the ideas he puts forth. It offers a lot of insight into a few things that are wrong with Java, and that most people will probably have felt.
I've also tryed to learn as much as I could from the state of Mono, its legal status... and I felt important to share that my view has changed slightly, it MIGHT become a player, and it might offer a cross-platform alternative to.NET. I also recommend the GoMono FAQ . There's a lot FUD regarding possible patent threats from Microsoft over Mono, but I believe that to be mostly out of misinformation and lack of knowledge at how it works. The idea of a common VM isn't new, Parrot for instance is just another one.
I'd be most interested in whatever other people might have to say about Java vs.NET/Mono, that comes from careful study and consideration not just hype. Approaches like CIL and Parrot make a lot of sense... where do you see them going?
I stumbled upon a very interesting article, which I'd recommend most people interested in modern languages to read. You'll recognize the author as the person behind Turbo Pascal and Delphi, and now C#:
This whole problem has recently become incredibly relevant for me. We are starting a project, and I am in charge of deciding which development enviroment to use.
I started by trying JBuilder. I gave up. It's not that I don't like Java - but it ends up being too ecletic in its stubborness for not supporting things like properties and operator overloading - I know how to develop, I don't need a language that imposes limits, I want a language that is easy to write and read, and I'd rather type C++ than the whole verbosity of Java.
I tried Delphi, but again, it's syntax is aging. Don't get me wrong, it's not just about syntax, but if given the chance to develop in C++ or in Delphi, I'll pick the former.
Lastly, we decided to go with BC6. We didn't adhere to using CLX and decided to go with VCL, confident that at any time it would not be a hard issue to port it over, if need ever arised. I'm not so sure right now.
And it's not all about visuals. It's about things that Borland was innovative in, like BDE/dbExpress and the whole concept of linking databases to datasets and then to data-aware controls. It's the whole atmosphere of using a Borland product and having freedom of choice.
I do NOT want to use C#, even though I like the language. I simply refuse to step back 10 years and go back at programming for a single-platform enviroment. Some people say.NET is the future, but I can only assume that's out of ignorance, or a real commitment to MS platforms. And don't talk about Mono, it's an interesting project, but it's far from being a drop-in replacement for.NET at the moment, and we need solutions now.
So, real world choices for RAD enterprise-grade applications involving database access, complex forms, multi-platform, etc? Delphi, C++ or Java.
Java isn't really slow anymore, but the syntax is a disgrace. Why on earth would I want to write a.setCounter( a.getCounter() + 3 ) when Delphi has had for ages a mechanism of properties that allows me to write "a.counter += 3" - even C++ allows for similar freedom, with operator overloading (although not the same) (and no, JavaBeans aren't the answer).
I know, this post comes out as a collection of assorted gripes, mostly in an attempt to justify why I chose to commit to using Borland C++Builder 6. I believe in it, and Kylix. Where's that going? We have a very tight deadline (don't we all) and using Delphi or BC6 is the only viable chance to beat it. Syntax-wise Delphi feels like using VB (ergh) so to keep some sanity intact, BC comes out as the obvious choice. Uncertainity is deadly when it comes to starting projects and preparing for the future... and it's causing me a great deal of concern wether I'm digging myself, the team and the project into a hole in choosing BC6.
It's possible that you thought wrong.:) You should be aware that most commercial languages do have an academic background. Of course there is a lot of academia that ends in dead ends, but afterall, that's what researching is.
And we're most definitly NOT talking to binary gates - abstraction is one of the 1st things thought in good programming courses, and while it is crucial to have a good understanding of the underlying processes, it is a key factor in good software development.
That's like saying that "to speak" is simply to get air to pass through the throat. Yes, that's the process allright - but "to speak" is also to convey meaning, to express thoughts, etc.
Of course, all this matters little when talking to yetis, or any of their less-furry and more stone-like brethen.
Erm... excuse me, but switch/case DOES make it easier to read, for the following reasons:
- it implies that all tests are on the same variable
- you can do it on a non-pure function, because it will only evaluate once
- it "looks" better than a chain of nested IFs and reads better.
I could go on... apparently you've missed the point, let me try and put it this way:
a) Programming is (mainly) a means for expressing logic and behaviour. b) Language puts barriers on what you can express. c) Therefore, a limited language, limits programming.
If you doubt this, think of human languages. Now think of "snow". Now ponder why is it that esquimoes have about 20 different terms for it. They can capture and express nuances in their speech that for us would seem irrelevant. If you think none of this matters, then the metaphore was lost, and maybe you should worry yourself with issues other than these.:)
The bottomline is, a more expressive language allows you to do more, better, and in a more detailed manner with little extra work. After you learn your 10th language, you reach a point where syntax doesn't make a shed of a difference in your understanding of any code. At that point, only the logic is at question, not the medium. But if the medium is restricted, then the logic is also restricted. Allowing for people to use subtle nuances of the syntax also allows different people to express like they prefer, thus broadening the use for a language. For a programmer worth his salt, syntax becomes nearly irrelevant when reading - although it has impact for matter of style and brevity.
Funny too how most people only know imperative languages and completly overlook the functional (Haskell, LISP, derivatives) and logical (Prolog,eCLiPse) implementations. SQL is fully imperative, if you ever tried querying a database using a Prolog layer you'd FEEL the difference, and the need for something that can convey meaning and information out of data (oh yes, they're different things). But I'm starting to ramble, so I'll just shut up and hit the bed.:)
You do have a point in that NULLs are an easy solution to some problems problem. But sometimes, people ask the wrong questions, and NULL comes out as an answer.
As with many other things in programming, NULLs are there for those who know how they should be used, but sometimes they also lure people to an "easy way out" when there are better methods.
Many a time when designing a database one thinks "hmm, there could be no value for this field", so you'll proceed to putting it to NULL, w/o bearing in mind that all the way up the abstraction layer you will have to support that NULL. Simple example s are empty strings and empty arrays (PgSQL).
As for the Date_Payed field, most people would say that you should place that on a side-table that would contain only those invoices that have been paid (and the Date_Payed field). I would probably consider using a PgSQL's INHERITS feature to turn "already paid invoices" into a subclass of the more general table "invoices", adding a field there. That makes nulls pointless, because if you select from the upper table you get all invoices, wether if you select from the child table you get only those that have been paid. Just an alternative of course, but that's what I think people should consider: better practices.
It's a bit like some practices in programming that although not "deadly" end up detracting from the whole quality, robustness and readability of a program. Compare that to reusing one-character variable names or monolithic functions of hundreds of lines - it works - but it is... bad form? Bad practice?:)
That's how I see NULLs - sometimes they are a necessity (because we lack better alternatives), and they are used too often (because people don't look for alternatives). That obviously someone else's problem - but when it turns out that the fact that "everybody" does it is creating such an inertia that alternate solutions aren't researched - then we have a problem. And I think that's what's happening to SQL (and NULLs) - stagnation.
Actually, I should say that I found that the article provided LOTS of links to foreign resources (that would answer whatever doubts someone could face when reading it). It is also well-presented in terms of visuals and well worded.
I've seen MANY an article on slashdot without such a degree of atention to form, contents and references, and I definitly haven't seen many this good, so I REALLY don't understand the comments on the above posts.
Maybe it's one of those personal-vendettas that I'll always be ignorant as to why people make a point in pursuing.
The fact that I did enjoy the article and that I think it's well written would probably not be enough for me to post something like $this post, but the fact that someone actually chose to pick on an article that I find of high-quality is worth putting up with the likely flames that will follow for actually supporting "someone in power" (read - an editor) - not that he needs it.
>> this is a perfect example of why you should NOT use a boolean for a tristate variable
Precisely, totally agree! That's what nulls entail in this case: you end up representing something with a boolean that is NOT a true/false variable.
In most cases that you'd use a NULL, you can use similar approaches. There might be situations where NULLs are handy, but in most cases, those automatic handlings aren't worth the possible trouble.
As for NULLs in foreign keys, just add a value in the other table that represents a no-value.
Re:I was about to ask the same thing.
on
An Alternative to SQL?
·
· Score: 2, Interesting
A couple valid points here and in the other few posts.
I'm not an academic, and I do write SQL a lot. Actually, I end up trying to write as little SQL as possible, by insulating it into small functions, but I'm sure many do the same for portability and plain old good form.
As for NULLs, the example of an empty street address is best represented by ''. Because the upper layer (the client used to fill in the values) won't make a distinction between '' and NULL.
In most cases, I simply ignore NULLs, and force propper default values - I'm sure most do the same.
The question we should be placing is "is there a better way"? Is there room for improvement? And please don't bring XQuery to the equation, that's something driven by need, not by carefully designing a solution.
At least fostering discussion and looking for alternatives, we might be able to achieve something.;)
Re:I was about to ask the same thing.
on
An Alternative to SQL?
·
· Score: 2, Insightful
I think you kinda misunderstood the problem.
The fact that there CAN be nulls is a showstopper when attempting to think in terms of relational algebra. It's so much simpler when you have a sound foundation of maths underneath - SQL has been so distorted over time that there is AMPLE room for improvement.
By not allowing nulls you are in fact working in a simpler world, as you do not have "undefined" operations in your query.
You are right though, in that it's the designers fault if NULLs get there, that's true. But just the fact that it exists forces a whole pletora of mechanisms and distorted concepts to deal with it. It's a poor man's attempt for an "incomplete-data" solution. A real incomplete-data solution must allow for the 3 boolean tests:
Known - true
Known - false
Unknown
Seeing as all comparisons in SQL are just boolean, they "trick" the third state into behaving within boolean parameters. And that's a source for trouble that could be avoided and made a hell of a lot simpler.
Just "blind" could come out (or go in) as an insult. "Visually deaf" will probably make the reader stop for a split of a second, maybe even smirk. And that's a bit more like I'd want it, as it (hopefully) promotes thought and not resent (of course this IS slashdot, but...). *winks*
I'm always surprised at how people manage to interpret things the way they want, despite obvious proof on the contrary.
First, I don't see how anyone can look at that map and claim Europe has more pollution than the US. C'mon, are you... visually deaf? Use a ruler if it needs be, but please take a close look. I understand that the 1st map being zoomed in can play a role in there, but please, just put it in perspective. The blob just above Italy is about 1/6 size of the one above the US, while the other large blob in Europe is about 1/5th that of the north american one. I mean... c'mon...:)
Second, bear in mind that NO2 is by far not the only polluting agent that human activity sends into the atmosphere - and it's not the only one that is nocious. It does cause O3 to build up, which would be a good thing in the upper layers of the atmosphere but deadly and poisonous at human-reachable levels (ever noticed there are pool-cleaning systems that use O3 (ozone) instead of clorum?;)
I urge the 1st poster to really go and revisit that link and read the whole article, and actually examine the map in comparable zoom factors. And yes, that's China and not Russia, like another not-so-geographically-challenged reader pointed out.:)
I did like that comment about industry from more advanced countries fleeing to China where regulations are not as harsh - food for thought. I suppose it's ok if we go and poison other countries to protect our way of life.:) Perfectly sound reasoning. *grin*
You've GOT to be kidding (either that, or I completly missed the sarcasm).
Do you really believe they are "playing"? The NK regime is incredibly belly centered. Do you have any idea of how shielded from the world those people are? They are SO shielded, that RADIO is forbidden. It reminds me of how Portugal was during its dictatorship program over 40 years ago. Average people in NK cannot even own a radio device. Those who do are considered "resistence" and taken to prison (or worse).
The reason? Delusion. As an example, you probably know NK receives some help from the outside, namedly, rice. Well, the people are told (and they have no reason to think otherwise), that the shipments of rice they see comming in are a form of tribute paid from other nations to the great, great Kim. Think a bit about that. They are lied to everyday, a bit like in the US, only those lies don't have to be credible.
Is it me or are we again close to Sep/11? Maybe they'll claim this was a terrorist act. Hei... it worked with Bush, maybe Kim will be able to convince the world he had nothing to do with it! Or maybe they just want to hitchike the (in)famous date, thus working as a gentle reminder that the world SHOULD well be paying more attention to NK.
I mean... c'mon... this is ridiculous. You wage a war in Iraq over nothing, and now the guy you simply ignored is wielding nukes? It'd be funny wasn't it outrageous!
Slashdot Mirror
Well, I did get part of it... but then I wasn't so sure, so... I (t)rolled away. :)
>> I think it happened the same day that the war in Iraq ended
:)
Erm... the war ended? Says who?
What you probably mean is your tv networks stopped broadcasting news about the war in Iraq, because you can be sure as hell the war hasn't ended.
All it takes is getting a bit off the USistheworld-shell.
It does depend on how you look at it, and you have a good alternate pespective there. Nice reply, thanks.
cheers
I think any grown up, and specially a techie, will understand that this is most likely related to a poorly written automatic content-verification system rather than an actual intent to shut down the site. :)
/. to sink deep below water level. :p
/. reader, I could really do well w/o having to read this kind of stupid stuff. At least post it elsewhere other than on the mainpage.
If you actually take time to read the letter, you'll see the matter can most likely be solved in a civilized manner. But no... someone had to make an issue out of this and... post it as news on Slashdot? Oh please... c'mon. Please please don't become just another sensationalist media, ok?
IMHO, it really seems obvious that it's a misunderstanding. If it's not, then it's just a stupidity, and should be ignored as such, not brought into the limelight as "news". Geesh, there's no need for
As
Just my opinion, for what it's worth - no harm intended.
Well, one thing with Borland that needs saying is that even if they discontinue the product (BC++), you do not necessarily get stuck - the code for the VCL is available, so one can move its project to another development enviroment (like MSVS) with little effort. It's not an instant move but at least it's feasible.
:) Funny how 6 months ago I'd have laughed at these concerns and would have kept typing C++ /OpenGL in the beloved screen/VI combo (with the occasional cross-compile to windows). While that hasn't changed, a lot more was added to the batch. ;)
:p
I'm trying to investigate all possible avenues, weighting the cost of having to backtrack later. Funny that while we were having this discussion, someone posted a newspiece about Gambas, a VB like language and IDE. While it's not a choice (maturity, language), it's still interesting to see new stuff turning up. As in many other things, it's also a matter of what the target audience is, for whatever you're developing.
As for having a degree of latitude, it also means that if we do get locked into a corner I'll bear the weight of a bad decision. The last time I was in a situation like yours... I ended up working in VB for 3 months. Served me a lesson on what NOT to do in the future.
At the moment, I'll probably bite the bullet and go with C# - it's a pretty elegant language. Mono seems quite able to run the simple stuff I've thrown at it, so we get cross-platform for free, and while the target audience is Windows, we hope to eventually be able to convince them to move.
Feel free to reach me via email at this same username over at users.sf.net, I'd be glad to continue conversation.
Cheers.
I wouldn't go as far as saying "MS only". Actually, Borland was the first to come up with a product that had that concept (Deplhi). It's not a coincidence that the lead architect for Delphi is behind C#/.NET. :) As for alternatives to MS, all Borland tools still have that concept, which gives you Delphi, BC++ (back to the original topic) and even JBuilder. Each one has its perks (MS too).
:) To be honest, I only recently started feeling a need for powerful RAD enviroments, (I'm a screen/vi/gcc person). I'll take those leads and see what shows up. Maybe that's a spot for improvement in opensource toolkits...
As for data-aware controls... I sense an idea forming. I must admit I never did an extensive search to see if the idea exists past those Borland/MS tools, but now that I think of it...
Thank you for your comment, I really appreciate an alternative vision. :)
;)
:)
I'm not picky when it comes to languages, as long as they allow for some degree of expressiveness (read sintactic sugar) and don't force the programmer to write too much "dumb"/pointless code (which is why I'm not fond of Java).
I've done a bit of work in Python, in an UO server emulator, and although it's used as a scripting language there, I did notice that most of the recent work tended to be less on the "core" (C) and more in python itself. So, outside a RAD context, I have no problem with it, on the contrary, as it enforces some good practices like propper indentation.
But in a RAD context, besides a "form designer", I also really require some degree of "database access/integration". I'm talking about data-aware controls, where you just point a textfield to a (dataset,field) and it automagically shows the current record value. Or a datagrid. It's not that I wouldn't develop without those features on my own work. But I also need to setup teams to develop "braindead" software fast, and those features equal productivity (speed of development and less bugs). Many argue "that's for wimps", but I'll discard those comments as being from people who never had to write boring software for a living.
At the moment I'm looking at SharpDevelop/MonoDevelop, and although I'm naturally resistant to MS, they did get ir right this time on several levels, so for productive enviroments, I might get people going with Mono/.NET/P.NET. But I'd be more than willing to try alternatives. Do you (or anyone else) have any ideas for an IDE that allows form designing and a toolkit with data-aware controls implemented?
You're totally missing the point. I'm talking about doing something like a.label = "123"
:)
And having the setter for the "label" property executed (eg, updating some display), instead of doing a.setLabel( "123" )
Some people argue that languages like C# only add sintactic sugar. And you know what? They might be right, but sintactic sugar helps readability and expressiveness. Wasn't for sintactic sugar we'de all still be programming assembly, and from an evolutionary perspective, we'de still have about 14 words, one of which would be "ugh".
I'm sorry to inform you that you've totally misguided your anger. :)
I believe in the concept, but the sole fact that I'm seeking information should have spared you some typing.
And why am I answering this? Dunno... it's amusing how people really take time to post comments like yours, so I'll amuse the readers even more by answering.
I know how you feel. Personally I feel there's a distinction between trying to spare the programmer from writing boring code and thinking the programmer is a moron.
Java *limits* what you can do and ultimately, the structuring of your code. It forces you to write long sentences and code that doesn't really add anything to the program.
I've mentioned this article before, but I really believe it to show some very valid points and the way they approached things on C#.
Bear in mind that I am mostly a C and C++ person (well, among other 10), and I also believe there are different languages for different jobs. But for RAD and solid structuring, I am desperatly in need to find an alternative to C++, if only because it's getting harder to recruit talented people.
This isn't directly related to BC++, but it's in line with my other post slightly above. It's related to looking for alternatives, in the current age of Java, .NET and Mono.
.NET and CIL is good technology - I hate to admit it, but MS has something good there. It is not a surprise, as it comes a LOT from the same person that designed TorboPascal, Delphi and now C#. I recommend those interested to read an interview here and pay attention to the ideas he puts forth. It offers a lot of insight into a few things that are wrong with Java, and that most people will probably have felt.
.
.NET. I also recommend the GoMono FAQ . There's a lot FUD regarding possible patent threats from Microsoft over Mono, but I believe that to be mostly out of misinformation and lack of knowledge at how it works. The idea of a common VM isn't new, Parrot for instance is just another one.
.NET/Mono, that comes from careful study and consideration not just hype. Approaches like CIL and Parrot make a lot of sense... where do you see them going?
For the last 8 hours after my other post on this thread, I've been searching the net for information regarding C#, CIL, Mono, comparisons to Java (with usability in mind, not zealotism), etc. And one thing is for sure:
Also, one interesting RAD project is here.
I've also tryed to learn as much as I could from the state of Mono, its legal status... and I felt important to share that my view has changed slightly, it MIGHT become a player, and it might offer a cross-platform alternative to
I'd be most interested in whatever other people might have to say about Java vs
I stumbled upon a very interesting article, which I'd recommend most people interested in modern languages to read. You'll recognize the author as the person behind Turbo Pascal and Delphi, and now C#:
e s/hejlsberg/default.aspx
http://msdn.microsoft.com/vcsharp/homepageheadlin
It hurts reading this on a MS site and nearly nowhere else... but that guy has it right. And Borland was right on path following those ideals.
This whole problem has recently become incredibly relevant for me. We are starting a project, and I am in charge of deciding which development enviroment to use.
.NET is the future, but I can only assume that's out of ignorance, or a real commitment to MS platforms. And don't talk about Mono, it's an interesting project, but it's far from being a drop-in replacement for .NET at the moment, and we need solutions now.
I started by trying JBuilder. I gave up. It's not that I don't like Java - but it ends up being too ecletic in its stubborness for not supporting things like properties and operator overloading - I know how to develop, I don't need a language that imposes limits, I want a language that is easy to write and read, and I'd rather type C++ than the whole verbosity of Java.
I tried Delphi, but again, it's syntax is aging. Don't get me wrong, it's not just about syntax, but if given the chance to develop in C++ or in Delphi, I'll pick the former.
Lastly, we decided to go with BC6. We didn't adhere to using CLX and decided to go with VCL, confident that at any time it would not be a hard issue to port it over, if need ever arised. I'm not so sure right now.
And it's not all about visuals. It's about things that Borland was innovative in, like BDE/dbExpress and the whole concept of linking databases to datasets and then to data-aware controls. It's the whole atmosphere of using a Borland product and having freedom of choice.
I do NOT want to use C#, even though I like the language. I simply refuse to step back 10 years and go back at programming for a single-platform enviroment. Some people say
So, real world choices for RAD enterprise-grade applications involving database access, complex forms, multi-platform, etc? Delphi, C++ or Java.
Java isn't really slow anymore, but the syntax is a disgrace. Why on earth would I want to write a.setCounter( a.getCounter() + 3 ) when Delphi has had for ages a mechanism of properties that allows me to write "a.counter += 3" - even C++ allows for similar freedom, with operator overloading (although not the same) (and no, JavaBeans aren't the answer).
I know, this post comes out as a collection of assorted gripes, mostly in an attempt to justify why I chose to commit to using Borland C++Builder 6. I believe in it, and Kylix. Where's that going? We have a very tight deadline (don't we all) and using Delphi or BC6 is the only viable chance to beat it. Syntax-wise Delphi feels like using VB (ergh) so to keep some sanity intact, BC comes out as the obvious choice. Uncertainity is deadly when it comes to starting projects and preparing for the future... and it's causing me a great deal of concern wether I'm digging myself, the team and the project into a hole in choosing BC6.
It's possible that you thought wrong. :) You should be aware that most commercial languages do have an academic background. Of course there is a lot of academia that ends in dead ends, but afterall, that's what researching is.
And we're most definitly NOT talking to binary gates - abstraction is one of the 1st things thought in good programming courses, and while it is crucial to have a good understanding of the underlying processes, it is a key factor in good software development.
That's like saying that "to speak" is simply to get air to pass through the throat. Yes, that's the process allright - but "to speak" is also to convey meaning, to express thoughts, etc.
Of course, all this matters little when talking to yetis, or any of their less-furry and more stone-like brethen.
Erm... excuse me, but switch/case DOES make it easier to read, for the following reasons:
:)
:)
- it implies that all tests are on the same variable
- you can do it on a non-pure function, because it will only evaluate once
- it "looks" better than a chain of nested IFs and reads better.
I could go on... apparently you've missed the point, let me try and put it this way:
a) Programming is (mainly) a means for expressing logic and behaviour. b) Language puts barriers on what you can express. c) Therefore, a limited language, limits programming.
If you doubt this, think of human languages. Now think of "snow". Now ponder why is it that esquimoes have about 20 different terms for it. They can capture and express nuances in their speech that for us would seem irrelevant. If you think none of this matters, then the metaphore was lost, and maybe you should worry yourself with issues other than these.
The bottomline is, a more expressive language allows you to do more, better, and in a more detailed manner with little extra work. After you learn your 10th language, you reach a point where syntax doesn't make a shed of a difference in your understanding of any code. At that point, only the logic is at question, not the medium. But if the medium is restricted, then the logic is also restricted. Allowing for people to use subtle nuances of the syntax also allows different people to express like they prefer, thus broadening the use for a language. For a programmer worth his salt, syntax becomes nearly irrelevant when reading - although it has impact for matter of style and brevity.
Funny too how most people only know imperative languages and completly overlook the functional (Haskell, LISP, derivatives) and logical (Prolog,eCLiPse) implementations. SQL is fully imperative, if you ever tried querying a database using a Prolog layer you'd FEEL the difference, and the need for something that can convey meaning and information out of data (oh yes, they're different things). But I'm starting to ramble, so I'll just shut up and hit the bed.
You do have a point in that NULLs are an easy solution to some problems problem. But sometimes, people ask the wrong questions, and NULL comes out as an answer.
:)
As with many other things in programming, NULLs are there for those who know how they should be used, but sometimes they also lure people to an "easy way out" when there are better methods.
Many a time when designing a database one thinks "hmm, there could be no value for this field", so you'll proceed to putting it to NULL, w/o bearing in mind that all the way up the abstraction layer you will have to support that NULL. Simple example s are empty strings and empty arrays (PgSQL).
As for the Date_Payed field, most people would say that you should place that on a side-table that would contain only those invoices that have been paid (and the Date_Payed field). I would probably consider using a PgSQL's INHERITS feature to turn "already paid invoices" into a subclass of the more general table "invoices", adding a field there. That makes nulls pointless, because if you select from the upper table you get all invoices, wether if you select from the child table you get only those that have been paid. Just an alternative of course, but that's what I think people should consider: better practices.
It's a bit like some practices in programming that although not "deadly" end up detracting from the whole quality, robustness and readability of a program. Compare that to reusing one-character variable names or monolithic functions of hundreds of lines - it works - but it is... bad form? Bad practice?
That's how I see NULLs - sometimes they are a necessity (because we lack better alternatives), and they are used too often (because people don't look for alternatives). That obviously someone else's problem - but when it turns out that the fact that "everybody" does it is creating such an inertia that alternate solutions aren't researched - then we have a problem. And I think that's what's happening to SQL (and NULLs) - stagnation.
Cheers.
Actually, I should say that I found that the article provided LOTS of links to foreign resources (that would answer whatever doubts someone could face when reading it). It is also well-presented in terms of visuals and well worded.
I've seen MANY an article on slashdot without such a degree of atention to form, contents and references, and I definitly haven't seen many this good, so I REALLY don't understand the comments on the above posts.
Maybe it's one of those personal-vendettas that I'll always be ignorant as to why people make a point in pursuing.
The fact that I did enjoy the article and that I think it's well written would probably not be enough for me to post something like $this post, but the fact that someone actually chose to pick on an article that I find of high-quality is worth putting up with the likely flames that will follow for actually supporting "someone in power" (read - an editor) - not that he needs it.
Cheers.
>> this is a perfect example of why you should NOT use a boolean for a tristate variable
Precisely, totally agree! That's what nulls entail in this case: you end up representing something with a boolean that is NOT a true/false variable.
In most cases that you'd use a NULL, you can use similar approaches. There might be situations where NULLs are handy, but in most cases, those automatic handlings aren't worth the possible trouble.
As for NULLs in foreign keys, just add a value in the other table that represents a no-value.
A couple valid points here and in the other few posts.
;)
I'm not an academic, and I do write SQL a lot. Actually, I end up trying to write as little SQL as possible, by insulating it into small functions, but I'm sure many do the same for portability and plain old good form.
As for NULLs, the example of an empty street address is best represented by ''. Because the upper layer (the client used to fill in the values) won't make a distinction between '' and NULL.
In most cases, I simply ignore NULLs, and force propper default values - I'm sure most do the same.
The question we should be placing is "is there a better way"? Is there room for improvement? And please don't bring XQuery to the equation, that's something driven by need, not by carefully designing a solution.
At least fostering discussion and looking for alternatives, we might be able to achieve something.
I think you kinda misunderstood the problem.
The fact that there CAN be nulls is a showstopper when attempting to think in terms of relational algebra. It's so much simpler when you have a sound foundation of maths underneath - SQL has been so distorted over time that there is AMPLE room for improvement.
By not allowing nulls you are in fact working in a simpler world, as you do not have "undefined" operations in your query.
You are right though, in that it's the designers fault if NULLs get there, that's true. But just the fact that it exists forces a whole pletora of mechanisms and distorted concepts to deal with it. It's a poor man's attempt for an "incomplete-data" solution. A real incomplete-data solution must allow for the 3 boolean tests:
Known - true Known - false Unknown
Seeing as all comparisons in SQL are just boolean, they "trick" the third state into behaving within boolean parameters. And that's a source for trouble that could be avoided and made a hell of a lot simpler.
Just "blind" could come out (or go in) as an insult. "Visually deaf" will probably make the reader stop for a split of a second, maybe even smirk. And that's a bit more like I'd want it, as it (hopefully) promotes thought and not resent (of course this IS slashdot, but...). *winks*
I'm always surprised at how people manage to interpret things the way they want, despite obvious proof on the contrary.
:)
;)
:)
:) Perfectly sound reasoning. *grin*
First, I don't see how anyone can look at that map and claim Europe has more pollution than the US. C'mon, are you... visually deaf? Use a ruler if it needs be, but please take a close look. I understand that the 1st map being zoomed in can play a role in there, but please, just put it in perspective. The blob just above Italy is about 1/6 size of the one above the US, while the other large blob in Europe is about 1/5th that of the north american one. I mean... c'mon...
Second, bear in mind that NO2 is by far not the only polluting agent that human activity sends into the atmosphere - and it's not the only one that is nocious. It does cause O3 to build up, which would be a good thing in the upper layers of the atmosphere but deadly and poisonous at human-reachable levels (ever noticed there are pool-cleaning systems that use O3 (ozone) instead of clorum?
I urge the 1st poster to really go and revisit that link and read the whole article, and actually examine the map in comparable zoom factors. And yes, that's China and not Russia, like another not-so-geographically-challenged reader pointed out.
I did like that comment about industry from more advanced countries fleeing to China where regulations are not as harsh - food for thought. I suppose it's ok if we go and poison other countries to protect our way of life.
I must say no willing gorilla would allow its body to be used in such a photography. It's an outrage!
You've GOT to be kidding (either that, or I completly missed the sarcasm).
Do you really believe they are "playing"? The NK regime is incredibly belly centered. Do you have any idea of how shielded from the world those people are? They are SO shielded, that RADIO is forbidden. It reminds me of how Portugal was during its dictatorship program over 40 years ago. Average people in NK cannot even own a radio device. Those who do are considered "resistence" and taken to prison (or worse).
The reason? Delusion. As an example, you probably know NK receives some help from the outside, namedly, rice. Well, the people are told (and they have no reason to think otherwise), that the shipments of rice they see comming in are a form of tribute paid from other nations to the great, great Kim. Think a bit about that. They are lied to everyday, a bit like in the US, only those lies don't have to be credible.
Is it me or are we again close to Sep/11? Maybe they'll claim this was a terrorist act. Hei... it worked with Bush, maybe Kim will be able to convince the world he had nothing to do with it! Or maybe they just want to hitchike the (in)famous date, thus working as a gentle reminder that the world SHOULD well be paying more attention to NK.
I mean... c'mon... this is ridiculous. You wage a war in Iraq over nothing, and now the guy you simply ignored is wielding nukes? It'd be funny wasn't it outrageous!