re: VB6, R.I.P. - Frans Bouma's blog

# re: I'm alive!@ Monday, May 05, 2003 11:04 PM

welcome!

Greg Robinson

# re: I'm alive!@ Monday, May 05, 2003 11:06 PM

Thanks, buddy. :) I'll add your blog to my list of links. :)

Frans Bouma

# re: I'm alive!@ Monday, May 05, 2003 11:55 PM

Howdy, noticed your sig on GoT, welcome on board :)

Paul

# re: I'm alive!@ Tuesday, May 06, 2003 12:05 AM

Heya Paul :D. I was looking for your blog but couldn't find it. Will add a link as well :)

Frans Bouma

# re: T-SQL Tip of the day@ Tuesday, May 06, 2003 6:48 AM

This would be a nice LLBLGen 1 addition!

Paul Gielens

# re: T-SQL Tip of the day@ Tuesday, May 06, 2003 7:12 AM

Yeah :) I was investigating some techniques to implement variable filtersets on resultsets (i.e. joined columns from one or more tables/views), for the O/R layer for LLBLGen v2. One of them was this technique, the other was a dynamic build query using parameters and build using a stringbuilder and then fed to a command. The stored procedure as shown above was slower than the dynamicly created query. I tested it with random input parameters, and the stored procedure couldn't keep up. That was an eyeopener though, so I'll include a dynamic query engine.

But LLBLGen v1.x can indeed win a lot with this, because the sole thing lacking in it is the ability to write custom selects on a combination of fields. With this technique that would be possible.

Frans Bouma

# Frans Bouma's blog@ Tuesday, May 06, 2003 7:59 AM

Frans Bouma's blog

TrackBack

# re: T-SQL Tip of the day@ Tuesday, May 06, 2003 11:37 PM

Any movent in the LLBLGen workspace?

Paul

# re: T-SQL Tip of the day@ Tuesday, May 06, 2003 11:44 PM

Not that I'm aware of. some people joined lately but I haven't checked if they were very active. it goes as with most OSS projects: big plans by a lot of people, but a few really execute these plans.

Frans Bouma

# re: I'm alive!@ Wednesday, May 07, 2003 1:59 AM

Hey Frans! Welcome!

Eric J. Smith

# re: I'm alive!@ Wednesday, May 07, 2003 3:19 AM

Thanks Eric! You got a blog yourself I can link to?

Frans Bouma

# Emitter@ Wednesday, May 07, 2003 4:03 AM

Emitter

TrackBack

# ShowUsYour-Blog!@ Wednesday, May 07, 2003 4:28 AM

ShowUsYour-Blog!

TrackBack

# re: It's not all bizznizz apps@ Wednesday, May 07, 2003 11:11 PM

Just a little FYI, CsGL is not just for c#. One of the reason the new library's called something different is this reason. The new library being worked on is CLS-compliant as well as cross-runtime/platform. We've got some cool stuff coming down the pike. As always, as listed on my (sad) page, which is hosting the new library, I could really use some non-Windows testers.

Ridge

# ISerializable@ Thursday, May 08, 2003 3:54 AM

ISerializable

TrackBack

# re: Borland's prices are too high?@ Thursday, May 08, 2003 6:31 AM

I'd like to do perform a feature comparison before I made a judgement, but on its face I don't think $999 seems too high if the product features are that compelling.

Think of it this way- if you're a carpenter, how much do you pay for your tools over time? I know that the tools are extremely expensive, and that they are maintained and replaced over time as needed. What's the value of what you produce with those tools? For those of us working in software development, these are the tools we use as part of the trade, and the work that we produce with them justifies their cost to a large extent.

randy

# re: Borland's prices are too high?@ Thursday, May 08, 2003 11:40 AM

I just appreciate you addressing the HTML reformatting issue with MS. Be sure to post their response when it comes forth.

Ron Green

# re: Relationships@ Friday, May 09, 2003 3:32 AM

That's a big post Frans! :-)

Eric J. Smith

# re: Relationships@ Friday, May 09, 2003 3:40 AM

heh :) yeah, it turned out much larger than expected because I thought I had to explain some stuff before diving into what I wanted to say. :)

Frans Bouma

# ISerializable@ Friday, May 09, 2003 6:30 AM

ISerializable

TrackBack

# re: XPath in T-SQL?@ Saturday, May 10, 2003 4:43 AM

I have to disagree - while I'm very worried about CLR code showing up in SP's, I think pattern matching is a natural extension of SQL and a welcome extension. Like SQL, XPath is used to define "what" I want (declarative), rather than "how" to do what I want (procedural). The WHERE clause is used to filter records, and becomes much more powerful if it can match on addresses with apartment numbers, text fields containing URL's, etc. I very much agree that procedural constructs in SP's is a bad paradigm mix, but SQL has long needed some improved pattern matching abilities.

Jon Galloway

# re: Relationships@ Saturday, May 10, 2003 5:36 AM

There is a solution to your first woe: denormalize for performance.

What is the difference between maintaining an OrderCount property in a Customers object (or OrderExists, or whatever it is you want to record about the relationship), and providing a field in a Customers table with OrderCount?

If you don't like the performance hit of traversing Orders, then don't. Denormalize for performance.

Your complaint about using intermediate tables: "which entity is this intermediate table representing? None..." shows either a basic misunderstanding of abstraction, or a double-standard, as you don't seem to have a problem with the concept when OO-methods do it.

Yes, a relationship is an entity -- an abstract entity. (Note, "abstract" is used with its common English definition here, not the OO definition.) Not every table which defines a many-to-many relationship entity contains additional fields describing the relationship, and this does not make the relationship's abstract reality a "bad thing" in any way.

Hiding the reality of the relationship entity, or giving it less "value" as a real thing to be considered in design is a mistake.

Then, happily your CMS example discusses the real differences between object and relational data models. For a given situation, one will provide a more efficient representation than the other. And once you commit to one or the other, translating back and forth is a rough boundary to cross, best avoided if possible. These are the points that need to be blogged and taught until everyone knows 'em.

Since your point was not to write about the merits of the relational model, it is understandable that you did not include an example where the storage and retrieval inefficiences of the object model make it a worse choice than the relational model.

The real solution is to understand both approaches well enou

Eli Robillard

# re: XPath in T-SQL?@ Saturday, May 10, 2003 12:31 PM

I have to disagree as well. XPath comes because of the XML support in Yukon. Apart from that it doesn't make a ton of sense, however, you definately don't want to query xml data with T-SQL... because T-SQL is designed for RDBMS systems, not xml.

Jesse Ezell

# re: XPath in T-SQL?@ Saturday, May 10, 2003 8:51 PM

If they use it solely to add new predicate clauses to the WHERE clause, indeed to filter out rows matching the single XPath clause, it is ok to me, however the usage of XML as a storage form, requires the existence of XSL and XPath to work with the XML, and I do not see how these two can be mixed with T-SQL.

Frans Bouma

# re: Relationships@ Saturday, May 10, 2003 8:58 PM

The problem I have is about the very different ways of how relations are physically stored in the database: via foreign key constraints, via combinations of constraints, via check-constraints, via instead of triggers etc. While you can store relations ALWAYS via a separate object which holds the complete information about the relationship, which entities are involved, which attributes participate in the relationship etc. You then eliminate the necessitiy of intermediate tables plus f.e. the necessity of needing f.e. combinations of constraints or the addition of attributes which serve no meaning. Intermediate tables which formulate the m:n relations (like non-obvious intermediate tables like 'Orders' in Northwind which defines the m:n relation between Employees and Customers) can be entities, but are necessary to formulate a relation between two OTHER entities. That's weird. You'd like to define that relationship with only the two entities involved, since these entities have the relationship.

Frans Bouma

# re: XPath in T-SQL?@ Monday, May 12, 2003 2:44 AM

As you say, XPath is a pattern matching language, so it is a natural fit for using in the where clause. It is not functional at all. XSLT is (although some disagree), but XPath isn't.

What the MS plans are for merging OO code with XML and RDBMS paradigms is still unclear to me as well, but this article might shed some light: http://www.research.microsoft.com/~emeijer/Papers/oopsla.pdf

I do not expect this kind of technology in the Yukon release though.

Teun Duynstee

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 13, 2003 2:15 AM

Even with a data reader, you will end up caching data in memory at some point along the line (whether it is in your own objects, the UI, etc.). Not using the DataSet does little to solve this problem. What it all boils down to is that there isn't any really easy way to get around the concurency issue in a disconnected environment.

DataSets are very cool. ObjectSpaces, which are built on top of the DataSet (at least at the time of the last preview), will let you do the same types of things (and much more) with objects and show just how cool the DataSet is. Still, I do agree that the DataSet is not suitable for a complex domain model. Custom objects always win out there (but again, they must cache state in the same way that the dataset does...it is just a pain to write all the extram code).

Jesse Ezell

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 13, 2003 2:42 AM

Jesse is right. The only way to prevent having an inconsistent state in your copy of the data is to lock it after you read it, let the user change it, and then commit it. If not, you'll always have to deal with an optimistic concurrency conflict in your application, regardless if you are using DataSets or any other persistence layer.

The persistence layers you mention can solve the issue if they are the only AppDomain accessing the database. If you have two AppDomains accessing the same database, you have the same problem. If you have two processes, or a server farm, you'll have the same problem. If you are using only one AppDomain to access your database, then you could tell that to the persistence layer so it caches it more agressively, but it will be a deployment-time optimization. You will still have to deal with optimistic concurrency issues in you code, because you'll will want it to scale to multiple appdomains...

Andres Aguiar

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 13, 2003 2:53 AM

Caching in ANY form is an issue, and you always have to take into account that when you read data on a given time T, the microsecond after that it can be changed by another thread. Indeed, if you do not want that, you should lock the row, not helping performance.

DataSets however give you the feeling they take care of this, which they don't (in full). The problem is that they make it easier for the developer to work in a stateful way with data cached in memory than f.e. the DataReader approach does. If you need to update a userrow f.e. you can simply execute an Update statement on the database, or update a cached userrow in a dataset, then persist it. THe latter will probably not work well in an environment with heavy changing data.

Andres: your example of the webfarm and the multiple appdomains is a good one.

I'm not against the usage of a dataset as a datacontainer between tiers, however if you use it as an equivalent of Fowlers UnitOfWork, it gets a little tricky.

Frans Bouma

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 13, 2003 6:23 AM

I found working with a timestamp column very helpful. See "Distributed Concepts and Design, Addison Wesley". A must have book for enterprise developers.

Good post Frans, to bad lots of people (even on dotnetweblogs) seem to be indoctrinated by MS's marketing strategy and refuse to dig in on this issue.

Paul Gielens

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 13, 2003 8:05 AM

If you are trying to use DataSets as a global caching mechanism then you are right, they are not good for it.

If you use them as a container for Business Entities instances, for example an Order, when you retrieve one, change it offline, and then persist it, then they work great.

I don't want to just execute an update statement to persist the data because I won't have optimistic concurrency, I'll have to build it myself.

They are also good when you want to cache mostly read-only data. If you have an ASP.NET app that uses DataReaders for filling grids, you'll have better performance than using a DataSet. If you then want to cache that data in a middle tier, or in the asp.net tier itself, then you'll have to change your app.

If you bind to a dataset, you'll have worse performance in the web server (the same in the database server), but you can add caching for read only data very easily, and that will imply a great improvement in the overall performance/scalability of the application.

Andres Aguiar

# re: Stored Procedures vs. Dynamic Queries.@ Tuesday, May 13, 2003 9:56 PM

Nice research. I guess now I'm still wondering my I shouldn't make the next leap and go with an O/R mapper all the way? A few months ago I would have said no way, but then again I was convinced that sprocs were the way too. So please more enlightening posts like this last one instead of the endless debate on the forums. Thanks.

Paul Wilson

# re: Stored Procedures vs. Dynamic Queries.@ Tuesday, May 13, 2003 10:17 PM

Paul, a MONTH ago I would have said: "Stored procedures are the way to go". However, there are times in life when you face the results of choices you've made, you don't like what you see, you suddenly know you made the wrong decisions. I've to admit I've spend 2 months developing a visual stored procedure designer for my generator just to meet the requirement to first generate stored procedures, and then generate call classes for these stored procedures. These 2 months were a total waste of time, because it is a) undoable to write a decent visual stored procedure designer without forcing the user to write SQL statements, and b) it will result in time-consuming work because the use has to design EVERY SINGLE action he wants to perform on the database in a stored procedure. For CRUD operations, that's easy. But what do you do when you have 3 foreign keys in your table and you want to have several delete stored procedures based on any combination of these foreign keys? That's 6 stored procedures if I do the math correctly :) Not a pleasant sight with a lot of tables.

I think the debates on the forums did help me find another way out of this by going the other way around, which ended up in tiny pieces of code which produce on the fly what is needed. If you set it up in a way that the small statements use factories which produce agnostic objects with db specific code INSIDE them, you have very portable code (just change the factory).

So I won't say the 'endless' debates on the forums are not worth it, I think they are. Every developer thinks on a given point in time they know what's best in a given situation. During debates on forums you learn other peoples views, and they will probably not enlighten you on the spot, but will work through in your work in some way, I'm sure of it (either by strengthen you in your believe you're right, or in a realisation you're wrong so you can change your way of doing things).

If you wa

Frans Bouma

# re: Stored Procedures vs. Dynamic Queries.@ Tuesday, May 13, 2003 10:20 PM

(the comment got clipped)
If you want to write all the logic by hand, there is NO WAY an O/R mapper can help you. O/R mappers, and related generators, are ment to generate common code based on a database scheme / input parameters and using a set of choices which might be the ove rall best. But NO O/R mapper will ever beat a handwritten, handoptimized DAL with stored procedures for every single possible query with a combined calling mechanism which is smart enough not to get data when it shouldn't. Like John Carmack will never b e able to deliver a generic 3D engine which will perform top notch in every single 3D game possible.
 

 
So, if you are aware of the compromises taken, you can then start looking at the advantages of using a ready-to-roll framework over writing it all by hand and check if the advantages are outweighting the disadvantages related to the compromises taken. W ith a solid O/R mapper or related generator, I'm pretty sure the ready-to-roll framework is well worth it.

Frans Bouma

# re: Stored Procedures vs. Dynamic Queries.@ Tuesday, May 13, 2003 11:36 PM

So are you basically saying your next version will be an O/R mapper instead of a code generator? If not, then my question is still why your code generation approach (but without the sprocs) vs. something like EntityBroker?

Thanks for your time.

Paul Wilson

# re: Stored Procedures vs. Dynamic Queries.@ Tuesday, May 13, 2003 11:47 PM

It will be both. It will generate code which utilizes a common framework, the code generated will be focussed to work with entities and collections of entities (Like 'Customer' and all code to handle the entity customer).

It will also allow you to generate lists, like order + orderdetails, some people like to use. These lists are pre-generated (the code to deliver you the list), can have filters, are typed (its a typed datatable) and can originate from an existing stored procedure (or not). It will also allow you to generate dumb datatable lists, if you want these. This last category can also be generated on the fly, using code and the same dynamic query engine, by the developer.

I generate code, but not all code necessary is generated. A lot is precompiled in an assembly, like all O/R mappers use. The reason I generate code is that I wanted to make life easy for the developer: thus in a gui he designs the usage of the O/R mapper, the O/R mapper is then created for the developer. The developer doesn't have to add a single attribute to work with the code. Also the generator does an extensive analysis of the database schema, so m:n relations are embedded directly into the Entity classes. (So for northwind, you'll get Customer.GetEmployees(), which in fact is an m:n relation via Orders. ).

EntityBroker requires you to write a lot in attributes, I generate this out in code. THere is not that much difference.

Frans Bouma

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 12:13 AM

Hi Frans,

Just out of curiosity, did you run the test with specific stored procedures too, instead of the generic one?

I understand that that wasn't a realistic option in your opinion, but I'm still curious regarding the result.
:-)

Best Regards,
Jimmy
###

Jimmy

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 12:21 AM

:) No I haven't. I did however profile the difference in speed between a stored procedure with optional parameters and a stored procedure tailored to one single filterset and the optional parameter one was much slower, since the optimizer can't optimize away a filter on a column even when the parameter is optional.

I have to test it extensively to say anything about the speed between dedicated stored procedures and dynamic queries (thus in the case of 3 foreign keys which are a possible filter, you have to write 6 stored procedures and then select one of them to run the query of that moment), but I don't think they'll be much faster than the dynamic queries (the dynamic queries have to be build up each time which takes some time, network speed can be a factor when a high amount of queries is executed), based on f.e. the books online documentation of SqlServer 2000.

Hand-optimized stuff is always the prefered way of doing things when performance is absolutely a matter of life and death. So is assembler. Neither one of them is recommeded in day to day applications due to the hard way of maintain such code.

Frans Bouma

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 12:27 AM

I got an error so I try again...

It would also be interesting to see how dynamic SQL in a stored procedure would perform compared to the other options.

Best Regards,
Jimmy
###

Jimmy

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 1:27 AM

Frans,

If I understand correctly, your dynamic query generator will run against JET -- which is used a lot in shared hosting environments. (Not everyone wants to pay for SQL Server.)

That would be very nice indeed...

Paul Schaeflein

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 1:53 AM

Paul Schaeflein,

I do understand that shared hosting environments sometimes offer access database support as the only support for databases, however I firmly believe that access is not the way to go for n-tier applications. Access is a single-user toolkit for applications which need a (small)database. Other applications can better target databases which are ment to perform in a multi-user environment. If they do not want to pay for a database, MSDE is there to the rescue.

The generator works with database drivers and database specific generators. In theory it's possible to write a driver for JET and thus a query generator for JET, however that's not planned. (It will not be that much work however).

Frans Bouma

# Frans Bouma's blog@ Wednesday, May 14, 2003 4:24 AM

Frans Bouma's blog

TrackBack

# Andres Aguiar's Weblog@ Wednesday, May 14, 2003 4:24 AM

Andres Aguiar's Weblog

TrackBack

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 8:55 AM

Also, what are the trade-offs in a large system. For example, one with 200+ tables (or how about one with 1000+ tables), 3 Sprocs (INSERT, UPDATE, DELETE) per table plus 1 more Sproc for each type of search per table. At this point, with at lesat 1000 Sprocs, even in the optimized world of specialized sprocs, how many would actually be kept in memory, as compared to how many would be dropped out and require a recompile each time they are used? Just some food for thought...

JimS

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 7:39 PM

I'm not proposing to agree or disagree with your premise (I rather suspect that I'd have a foot in both camps, in fact) but I did wonder about the validity of the benchmarks.

Firstly, did you try using the "WITH RECOMPILE" option when you created your stored proc? As you'll probably know already, this gets round (at a cost per execution) the inappropriate query plan problem. In fact, with optional search criteria that might influence the query plan I'd say it was essential.

Secondly, to echo a previous comment, did you try building the specific SQL string required in the stored proc and using "exec"? I would expect similar response times to dynamic SQL since the query plan must now be generated fo each execution.

A third option might be to use a 'master' stored proc to accept the optional parameters and then pass control to 'sub' procedures that contain queries that are not hampered by the optionality. Of course, we're starting to run the risk of substantial duplication at that point, with increased maintenance costs becoming a potential downstream problem.

I think I might be inclined towards the dynamic route in order to be able to exercise better control over the duplication issues.

Assuming execution times can be equalised, the remaining issue may be in the area of access control. There may be benefits to be had from restricting table access to stored procedures, perhaps because of referential integrity concerns.

Mike Woodhouse

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 7:50 PM

Mike:
The execution plan is the same with every input, this is because the stored procedure uses the same code. Check the stored procedure in the linked blog. Specifying 'With Recompile' would slow down the execution without any benefit.

Building strings INSIDE a stored procedure is even slower and not an option. T-SQL is not ment to be doing string contatenations, and it also kills the caching of execution plans, because you can't re-use execution plans based on parameters (allthough sqlserver tries to replace hardcoded values with parameters).

The Dynamic queries ARE parameterized. Therefor the queries will re-use execution plans (there are 6 execution plans possible with the test done: 3 foreign keys, 6 combinations). The dynamic queries were not created using the concatenation of the values in the query, but using parameters.

Delegating the call to other stored procedures inside a stored procedure wouldn't have helped either, I can do that selection in C# too, avoiding slower T-SQL execution code. The point was: is it worth it to do this:

1) create 6 stored procedures (which are fast)
2) create 1 stored procedure with optional parameters (which is slow(er)
3) create dynamic queries with parameters (thus in the end 6 of them).

1) is probably one of the fastest, but requires 6 stored procs in our situation for that particular table. Not that nice. 2) is slower than 3) so 3) is IMHO the best choice.

About access control: I read that more and more, but it's hot air. I'll try to explain why later on.

Frans Bouma

# re: Serious ASP.NET Editor flaw lives on in VS.NET 2003@ Thursday, May 15, 2003 12:06 AM

Maybe as an interim solution they could fix the problem in the upcoming release of the Web Matrix.

Ron Green

# re: Stored Procedures vs. Dynamic Queries.@ Thursday, May 15, 2003 1:47 AM

Good work! I just posted my thoughts to my blog (linked to my name above) rather than spilling them here...

Richard Tallent

# Frans Bouma's blog@ Thursday, May 15, 2003 5:19 AM

Frans Bouma's blog

TrackBack

# Frans Bouma's blog@ Thursday, May 15, 2003 6:01 AM

Frans Bouma's blog

TrackBack

# re: VS.NET 2003 isn't all that bad (sort of)@ Saturday, May 17, 2003 9:33 PM

But still no refactorings? No "extract method", "rename method", "move method", Renaming a variable in one place and renaming them everywhere in it's scope automatically? Those are things I can't hardly live without since I've been using Eclipse for Java developement. And *might* even be a reason why I keep using Java although I'd prefer C# as a language.

Zef Hemel

# re: VS.NET 2003 isn't all that bad (sort of)@ Saturday, May 17, 2003 9:40 PM

No refactoring functionality. I heared C# builder of Borland (to be released this summer) will have refactoring-functionality. Refactoring is something that is not considered 'useful' in the MS community, since it is a tool necessary by people who think while they write code (like in the eXtreme Programming world). So "if you design your software well enough, you don't need refactoring". I agreed with that for a lot of years. At the moment I'm doing a lot of designing while I write the code, and refactoring would help a lot in this case.

Frans Bouma

# re: #define debugging testing@ Sunday, May 18, 2003 12:42 AM

http://dotnetweblogs.com/sbchatterjee/posts/7189.aspx

SBC

# re: #define debugging testing@ Sunday, May 18, 2003 1:14 AM

I do agree with what you write, and I maybe confusing bugs (they are all bugs after all!), but I think I can solve 99% of all bugs just tracing things. That's for my personal case.

I also wanted to point that in real world (at least the world I live in ;-) scenario, average developers spend way too much time in the debugger than they should, and this just costs a whole lot of money to projects, in terms of productivity.

Simon Mourier

# re: #define debugging testing@ Sunday, May 18, 2003 1:21 AM

Tracing can be a tool to find code error bugs, why not? It shows you the state on a given line and you can do that with printf's or looking at a locals window in a debugger ;)

I agree that way too many developers simply do not know what debugging is really about. If a method deep down the call chain is probably not good, they do not know that because they never tested the methods calling the code either on pre-/post conditions, fire up a debugger, break at the start of the call chain and step ahead till doomsday not knowing where to look for because they do not use their head.

Frans Bouma

# SBC DotNet Weblog@ Sunday, May 18, 2003 7:29 AM

SBC DotNet Weblog

TrackBack

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 1:18 AM

Very bad advice IMO. Use VS.NET 2003. The amount of time you save will be more than enough to deal with any of these issues.

Here is the classic Early Adopters article about framework versioning:

http://www.3leaf.com/default/articles/ea/SBS.aspx

.NET was designed to support versioning, the solution is not ignoring versioning, but learning how to properly use it.

Jesse Ezell

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 1:24 AM

Then please help me in this situation, since I can't think of any real solution. How am I going to FORCE versioning onto developers using visual studio.net 2002? I can only tell them to use the assemblyBinding tags in their own config files otherwise it WILL NOT WORK.

If this visualstudio.net 2002 user is not developing an executable but also a library (based on your library), he TOO has to tell HIS customers to include the assemblyBinding tags otherwise the code will NOT WORK.

All versioning is focussed on UPWARDS compatibility. However no-one is talking about .NET 1.1 assemblies which are used in .NET 1.0 environments.

Frans Bouma

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 1:47 AM

*dang* wrong quote :)
[quote]
Adopter:

This works both ways. If you’ve built a v1.1 component, there’s nothing to prevent a developer from referencing it from a v1.0 application. In this case, your v1.1 component finds itself running on the v1.0 Framework. This situation is more dangerous than the reverse, as there’s the potential that your component uses something that doesn’t even exist in v1.0. If this is the case, expect a “missing method” exception.
[/quote]
I tested this and this is not true (see error listed in the blog). My 1.1 assembly is not run against the .NET 1.0 install on the machine even though the .exe file is compiled on that same machine using csc v1.0.3705.288, thus .NET 1.0.

Frans Bouma

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 1:57 AM

If you have both frameworks installed, can you compile using the command line in the 1.0 environment?

Paul Schaeflein

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 2:04 AM

Yes you can, you can manually compile against whatever framework you want. An ISV can opt for that route as well, however this can be cumbersome also when the set of assemblies have dependencies etc so you have to write NAnt files to build manually. It's not an easy situation, and I think not a lot of ISV's have thought about this, I for one hadn't until I tested it this morning and discovered I made a mistake upgrading to VS.NET 2003, even if the editor is much better and very helpful.

Frans Bouma

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 2:21 AM

At CodeProject there's a tool converting projects and solutions from VS.NET 7.0 to VS.NET 7.1 and vice versa:

http://www.codeproject.com/useritems/vsconvert.asp

Thomas Freudenberg

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 2:24 AM

In VS.NET 2003 IDE, you can choose which framework to compile against.

Project Properties -> Build -> Supported Runtimes -> Change

Jack

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 2:29 AM

[quote]
In VS.NET 2003 IDE, you can choose which framework to compile against.

Project Properties -> Build -> Supported Runtimes -> Change
[/quote]
Only for .exe projects, and also this adds assemblyBinding tags to the .config file of the .exe project. You can't set this information on f.e. C# class library projects. VS.NET is also not compiling with .NET 1.0 if you select it in that dialog, it will compile using .NET 1.1, it will only change your app.config file so the compiled .exe uses .NET 1.0 because all referenced system assemblies are redirected to .NET 1.0 versions. This works ok.

THomas: thanks, can be a life saver in supporting multi-platform applications.

Frans Bouma

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 20, 2003 3:29 AM

Great article! Thank you! And thank you for your answer on the newsgroup.

Sasha

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 4:33 AM

again, I'm missing something here. .NET 1.0 is to DirectX 8.0 as .NET 1.1 is to DirectX 9.0. Get the drift? Just make the change and people will follow and soon enough no one will care about .NET 1.0, as they will all WANT to have 1.1 installed and running (and this includes those developers 'stuck' in VS.NET 2002 land)...

JimS

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 5:17 AM

Oh yeah, great selling argument: "You can use this software only with visual studio.net 2003. If you have still visual studio.net 2002, please upgrade.". :) I don't think that's gonna work.

Frans Bouma

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 6:19 AM

Frans: What about using a third-party IDE, such as SharpDevelop or C# Builder, to compile your release build?

Phil Weber

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 8:01 AM

This is horendous advice. .NET fully supports Sxs versioning and assemblies. You need to figure out how to use it properly. See the Early & Adopter article, read about publisher policy files, etc but *don't* write riduclous stuff like "ISV'sL do NOT upgrate to Visual Studio .NET 2003!" Not only does it look bad for you but it looks bad for this site (of which many .NET people have been pointing out how much totally incorrect and bad advice is given out daily).

Sam Gentile

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 8:08 AM

You can’t **compile** against either framework version, but that you can use the <supportedRuntime> and/or <bindingRedirect> elements to run in either environment, assuming you don’t have dependencies. When we say compile against X, what we are really saying is that the compiler stamps the X version in the assembly metadata for the referenced version, which is the one the CLR tries to load unless redirected in the config files. Any code compiled in 2003 will target by default 1.1, but can be redirected using the configuration files. If you want to redirect to 1.1 from 1.0, you use the <supportedRuntime> element. And, if you want to go from 1.1 to 1.0, you use a slew of <bindingRedirect> elements. All of the VS.NET 2003 UI (C# and VB) to target runtimes creates the config files, but still stamps 1.1 versions in the assembly metadata. So, if you want to target 1.0 with code you wrote in 1.1, just add a section to the app config file. If you're an ISV, you probably have a setup process. Why can't you write this into your setup? Seems to be no big deal to me. What other software platform let's you upgrade without recompiling in a cleaner way?

Stephen Fulcher

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 8:11 AM

Sam: the early & adopter article is not mentioning class libraries. If you are selling class libraries, you are falling into this pitfall. It is NOT ridiculus advice, since I *AM* now in this situation and I *CANT* fix it, unless I go back to visual studio.net 2002 or compile the sourcecode by hand for 1.0, or supply the assemblyBinding tags and *HOPE* my customers are going to include it in their config files.

Do you know a solution then? I don't. You can say "It's horendous advice", but what are my options? I'm delivering a set of class assemblies to customers, who can (and probably will) use Visual Studio.NET 2002. I *CANT* compile these with .NET 1.1 because these will give them serious errors, unless they include the assemblyBinding tags in their config files. I've tested this today. I lost a complete day to test what I can do, and didn't find a solution. Therefor I posted this article.

If people are OFFENDED by this, I'm sorry, but it's the clear hard reality for SOME ISV's.

I also do not see why it would look bad for me. I warn other people to think twice before they move to vs.net 2003.

So Sam, as an invitation, please offer me a solution so I can fix this properly. I don't see one. Requiring customers to buy visual studio.NET 2003 is ridiculus in itself, and I can't do much more. A customer with solely visual studio.net 2002 is not focussed to include redirects for .net 1.0, because he never had to. *THATS* the issue. Who is paying the bill for all the supporthours my people have to give customers because they can't run the code they bought? Should I do something to my code to make this easier? If I can, please tell me. I don't know what.

Frans Bouma

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 8:12 AM

when I said "this site", I meant "dotnetweblogs as exhibited by the main feed" fyi

Sam Gentile

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 8:18 AM

Stephen: if I was selling solely a .exe, it wouldn't have been a problem. The problem is with the class libraries. I can't supply them with a .config file (I wish I could).

It would have been really great if a class library compiled with vs.net 2003 and run by an application build with .net 1.0 would immediately use .net 1.0 assemblies. That would solve the problem. However this is NOT the case. Of course a customer can add the assemblyBinding tags, it's the solution that worked, however a customer has to add them. I didn't KNOW that. It's not mentioned anywhere that you have to add these tags to a .net 1.0 (!) application's .config file to make its class libraries (which are probably compiled with 1.1) use .NET 1.0 assemblies.

Because this is extra support trouble, extra trouble in codebases, it's wiser to keep the code in vs.net 2002, because this will keep you out of the trouble. I predict this issue will cause trouble for some ISV's. Now everyone is selling 1.0 versions, but this will change.

Frans Bouma

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 8:19 AM

I am not going to do this with you. While I appreciate your fustration, bloggers here need to learn *not* to make grand denouncements of something. You didn't say "some". You said "ISVS: do NOT upgrade." So all ISVs should not upgrade? Surely *most* ISVs are not exhibiting this problem. Having a blog that is public conveys a responsibility for being accurate as well as posting content free of rants or grand pro/denoucnements. You get the lecture today because there is just so much of this going on in general on this site, and prominent .NET people and bloggers are starting to complain. 'Nuff Said.

Sam Gentile

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 8:31 AM

If some 'prominent' .NET people have complaints about my blog let them contact me. I think that's the obvious way to do it. I haven't received *one* complaint besides some in these reactions here.

It's not just frustration, Sam. It's cold hard cash I'm loosing here, and no-one is paying it back because I made the decision to move to visual studio.net 2003 and I didn't know any better. If I can help others with a warning it would be great so others won't loose money over an obvious upgrade.

If I re-read the reactions on this blog, I see some good tips and some "this is bad advice"-replies. What's the problem? Is it BAD to tell the world Microsoft scr*ws developers over with their hardwiring platform targets in their IDE's? Apparantly. Good to know, so I can keep the blogs down to cheerio's for Microsoft's good deeds while keeping my mouth shut about their not so good deeds.

Yes, I'm offended now. I sincerely tried to fix this myself this day, I can't. Microsoft doesn't help me, I hope I helped some ISV's out there today so they make the right decision. If that's against the will of some 'prominent' .NET people, please let them contact me and perhaps they can HELP me with this.

I'm more than willing to type a long essay about every detail how to fix this, so I can say: "ISV's: it's safe to upgrade to visual studio.net 2003, read how".

Frans Bouma

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 8:59 AM

Last post from me on this. Apparently, you still don't get the difference on "some" versus "all" and "giving good advice" versus saysing "ISVS: Do NOT." Do I have to spell this out any more clearer? I checked every word of what I wrote with Scott, and spoke to him and he was fine with it. Complaints is refering to not just *this* site but the high number of incorrect .NET information that shows up on the *dotnetweblogs main* feed from a number of blogs on dotnetwegblogs. Scott and I recieve complaints on it. I gave you good advice on how you could have blogged it and how to make a blog successful. You chose to ignore everything I wrote. It's your choice. This is all I am going to say on this.

Sam Gentile

# Loosely Coupled@ Tuesday, May 20, 2003 9:25 AM

Loosely Coupled

TrackBack

# Frans Bouma's blog@ Tuesday, May 20, 2003 9:25 AM

Frans Bouma's blog

TrackBack

# Frans Bouma's blog@ Tuesday, May 20, 2003 9:25 AM

Frans Bouma's blog

TrackBack

# Robert McLaws@ Tuesday, May 20, 2003 9:25 AM

Robert McLaws

TrackBack

# Robert McLaws@ Tuesday, May 20, 2003 9:25 AM

Robert McLaws

TrackBack

# Robert McLaws@ Tuesday, May 20, 2003 9:25 AM

Robert McLaws

TrackBack

# Robert McLaws - BoyWonder.NET@ Tuesday, May 20, 2003 9:25 AM

Robert McLaws - BoyWonder.NET

TrackBack

# Robert McLaws - BoyWonder.NET@ Tuesday, May 20, 2003 9:25 AM

Robert McLaws - BoyWonder.NET

TrackBack

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 11:52 AM

I have been stuck having to compile my NUnitAddin project with VS.NET 2002 to ensure compatablilty with both. Yes I might be able to add redirects to devenv.exe.config but I don't think users would be very impressed. I have heard it is possible to compile against the 1.0 assemblies in VS.NET 2003. It would just take a while to manually change them all. I've just written a snippit of code to change all assemblies in a solution to be the 1.0 versions. If you've got NUnitAddin installed you can use 'Test With... VS.NET' on the following method. Put this code in the solution you wish to convert...

using System;
using System.IO;
using System.Reflection;
using System.Diagnostics;
using EnvDTE;
using Microsoft.Office.Core;
using VSLangProj;

public class SolutionConvert
{
public static _DTE DTE
{
get { return (_DTE)AppDomain.CurrentDomain.GetData("DTE"); }
}

public void BuildWith_v1_0_3705()
{
foreach(Project project in DTE.Solution)
{
VSProject proj = project.Object as VSProject;
foreach(Reference reference in proj.References)
{
string assemblyPath = reference.Path;
string assemblyFileName = Path.GetFileName(assemblyPath);
string frameworkDirectory = Path.GetDirectoryName(assemblyPath);
string frameworkVersion = Path.GetFileName(frameworkDirectory);

string newFrameworkVersion = "v1.0.3705";
string newFrameworkDirectory = Path.Combine(Path.GetDirectoryName(frameworkDirectory), newFrameworkVersion);
string newAssemblyPath = Path.Combine(newFrameworkDirectory, assemblyFileName);

if(frameworkVersion != newFrameworkVersion && File.Exists(newAssemblyPath))
{
Debug.WriteLine(assemblyPath + " -> " + newAssemblyPath);
reference.Remove();
proj.

Jamie Cansdale

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 11:53 AM

.References.Add(newAssemblyPath);
}
else
{
Debug.WriteLine(assemblyPath);
}
}
}
}
}

Jamie Cansdale

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 4:22 PM

First, it's pretty easy to create separate VS 2002 and VS 2003 project files that point at the same source. Then you can work in VS 2003, and do your final build in 2002 (or you can set up a batch/makefile to do a command line compile).

Also, if you build an assembly from VS 2003, you can reference that assembly from a VS 2002 application just fine. You do not need binding redirects or policy files in this case. These come into play if you have a strong named component, and you want to replace it with a newer version (and you want everything redirected to the newer one).

Scott Swigart

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 5:38 PM

Or, you can maintain 2 downloads and EDUCATE your developers on which one to use.....

Robert McLaws

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 6:32 PM

Scott Swigart: did you try it? Of course you can reference it from vs.net 2002. It even compiles ok. It starts up even, but when you call a method in a class library build with vs.net 2003 from a .NET 1.0 application, AND that class library uses an assembly of .NET to do something (in short: something useful), it will crash with an exception that it can't load the right assembly (the 1.1 version) so your call will not succeed. I tried it, it fails.

Robert: maintaining 2 versions is nice, but what if I upgrade my own class library? Then I have to maintain 4 versions. Perhaps even 6 after another upgrade. I'll look into this, it might be the only solution which will not be a burden for my customers, if I implement it right in my generator.

Frans Bouma

# Frans Bouma's blog@ Wednesday, May 21, 2003 4:27 PM

Frans Bouma's blog

TrackBack

# Loosely Coupled@ Wednesday, May 21, 2003 4:27 PM

Loosely Coupled

TrackBack

# re: Microsoft gets Database Performance crown back!@ Thursday, May 22, 2003 8:17 AM

I used to work for a software vendor as an evangelist and we were primarily a microsoft shop. I can't tell you how many times I had to deal with anti-microsoft/pro-oracle battles. after a while i got pretty good at quoting statistics that dispelled a great deal of it. i think most of it has to do with good marketing on oracle's part.

slowly the myth is getting displaced.

-Mathew

Mathew Nolton

# re: "Framework-Hell"-solution is here: ISV's can upgrade to VS.NET 2003 without pain.@ Thursday, May 22, 2003 7:29 PM

Thanks for the explanation. Would it be possible/easy to write a VS add-in that raises warnings at compile time of usage of a framework assembly of a higher version than x (x being configurable in the add-in). Even if it is indirect (your project referencing a third party assembly which references etc...)?

This would be really usefull.

Teun Duynstee

# re: "Framework-Hell"-solution is here: ISV's can upgrade to VS.NET 2003 without pain.@ Thursday, May 22, 2003 7:34 PM

It definitly would be possible, you have to walk reference chains using reflection, but how to implement it as a pre-compile add-in... I really wouldn't know :)

Frans Bouma

# re: "Framework-Hell"-solution is here: ISV's can upgrade to VS.NET 2003 without pain.@ Thursday, May 22, 2003 9:32 PM

Why not just set the supported runtimes in the project properties dialog.

Also once you have changed the references manually to 1.0 and then manually back to 1.1, the projects will revert to 1.0 on compile. You are stuck with 1.0!

Victor Lindesay

# re: "Framework-Hell"-solution is here: ISV's can upgrade to VS.NET 2003 without pain.@ Thursday, May 22, 2003 9:36 PM

Victor: you can't set that setting in class library projects. Try it, the setting is not there. (The setting is only available on .exe projects which will generate redirect tags to 1.0 in the .config file, no compile against 1.0 is done in VS.NET 2003 unless you hard-reference to 1.0 assemblies.

Frans Bouma

# re: Concurrency Control Methods. Is there a silver bullet?@ Friday, May 23, 2003 11:35 PM

Interesting...! I have to admit I usually say "Don't use functionality locking (your words) except when you really have too!" and that because of runtime efficiency. But this was a refreshing viewpoint!

To see it your way, how do you tune the solution so that the second user isn't kept from doing what he wants too, for longer time than absolutely necessary? I usually use a custom lock table for this and I use a time interval for when the lock isn't valid anymore and that way I deal with ctrl-alt-del, for example. Do you have a better solution to this?

Best Regards,
Jimmy
###

Jimmy Nilsson

# re: Concurrency Control Methods. Is there a silver bullet?@ Friday, May 23, 2003 11:50 PM

Interesting concept Frans. I see two places you need to detail out before this is realistically feasable.

The first thing you need to detail out is the 'lazy' user who will simply lock out others for long periods of time.

For example, say Joe selects the row that Jack wishes to modify first, but now Joe either goes for a cup of coffee or out to lunch, or gets called away for a dire emergency or just plain forgets to release the row for Jack to be able to use. Do we simply lock out Jack until somebody gives Joe a much needed kick in the butt? While software which tosses away a fraction of the work done is not a good thing, an even worse thing is software which slowly grinds work to a halt.

The second is scaling. Webservices are not needed in small scale systems. You can accomplish the exact same functionality in a simple two tier setup, avoiding all the inefficiency webservices would introduce. But in large scale systems, don't lose sight of reality. Yes, webservices work great, but now you also introduce physical distance also.

Sure, Joe could do the work Jack is and avoid duplication. Except Joe works in the corporate HQ in NYC. Joe is employed in HR and wants to alter John's home address so his next paycheck reaches him on time. Jack however, is John's manager and wishes to add change John's work extension ASAP because he's in sales and the website needs to pick up this change for new customers to reach him.

Now the question becomes who do we piss off first? Do we lose potential sales because a new customer can't reach our sales rep? Do we piss off John because his paycheck arrives late? Maybe we piss off Joe because we've now doubled his workload. Or maybe Jack because Joe left John's row locked while he left for lunch at noon - except it is 9am where Jack is.

And all because our 'more efficient' system won't allow two users to update two separate fields from the same row in our empl

Dave

# re: Concurrency Control Methods. Is there a silver bullet?@ Friday, May 23, 2003 11:51 PM

It depends on your application. If you are using a webapplication frontend, you're stuck in the request-response paradigm, so there is no other way then to lock using the mechanism you describe (which is commonly used, f.e. in CMS-es).

Another scheme can be where you still have the lock-table where you store locks on functionality, but a service which manages the locks and communicates with clients bi-directionally. Clients will notify the service that they're freeing a lock and the service can then notify another client waiting in line to enable the functionality.

But indeed, wmost of the time you are forced to implement a time-period to the lock on the functionality as well. However, if the organization is organized well and the software streamlined as well, it shouldn't be very common that a user tries to start functionality that's locked by another user.

Frans Bouma

# re: Concurrency Control Methods. Is there a silver bullet?@ Friday, May 23, 2003 11:53 PM

Damn... gotta learn to be more to the point! :-)

I wanted to end by asking if my concerns were legit because I do agree.... optimistic/pessimistic locking really doesn't cut it 100% of the time.

Interesting post Frans!

Dave

# re: Concurrency Control Methods. Is there a silver bullet?@ Friday, May 23, 2003 11:54 PM

(My previous comment was targeted to Jimmy)

Interesting thoughts, Dave! How functionality locking is implemented can change from organisation to organisation. I can imagine a boss can overrule a lock on a given set of functionality or an admin can unlock a set of functionality at any given time, making the workflow continue. It is all about keeping the workflow going. If someone stalls it, it has to be tuned, both on the organisational side and on the software side.

Frans Bouma

# re: Concurrency Control Methods. Is there a silver bullet?@ Saturday, May 24, 2003 1:10 AM

Frans, yet again... study the Fitch and Mathers sample. For what I can remember it provides a nice, solid, clean way to stop people from bashing the broker.

public enum Blah {
Pending = 0;
etc

Nice post... the writing style reminded me of your friend Fowler, to the core of the problem in mummy_understandable communicative language ;)

Paul Gielens

# re: Concurrency Control Methods. Is there a silver bullet?@ Saturday, May 24, 2003 2:26 AM

Fitch & Mathers? hmm. Well like I said, it can be done on a lot of ways. I haven't looked into F&M a lot, but if they build in functionality locking, it's a nice real life example. :)

Frans Bouma

# Frans Bouma's blog@ Saturday, May 24, 2003 6:53 AM

Frans Bouma's blog

TrackBack

# mads studentblog@ Saturday, May 24, 2003 6:53 AM

mads studentblog

TrackBack

# Concurrency and Other Data Topics from Frans : IDunno@ Saturday, May 24, 2003 6:53 AM

Concurrency and Other Data Topics from Frans : IDunno

TrackBack

# re: Concurrency Control Methods. Is there a silver bullet?@ Saturday, May 24, 2003 10:24 AM

Great article, Frans! Reminds me of a Bill Vaughn quote - debating concurency resolution strategies is like arguing about where to stack the bodies after the accident, instead of putting up the traffic signals to prevent the accident in the first place.
 
Handling concurrency on the front end allows for some big optimization gains at update time, such as batch updates (in the case of editable datagrids, for instance, a user can be editing several rows at a time). My favorite strategy for that is to pass in all the update rows in XML, use OPENXML in a SP to dump them into a temp table, delete the old rows and add the new ones (all in a transaction). The same procedure can just as easily free the row locks when it's done.

Jon Galloway

# re: Why I think some people shouldn't use VSNET 2003.@ Saturday, May 24, 2003 10:47 AM

Frans, I think what you are saying essentially true, but only for Component vendors. If someone is writing a general app, then Visual Studio 2003 is preferable. I've posted some more details on my blog.

Mike Sax

# re: Why I think some people shouldn't use VSNET 2003.@ Saturday, May 24, 2003 7:46 PM

Mike: that's why I'm talking about libraries :). General app developers are also able to target 1.0 in vs.net 2003 by the .config generator in vs.net 2003 which adds redirect tags in the .config file, for .exe projects. :)

Frans Bouma

# re: Farewell, beloved Hungarian Coding.@ Sunday, May 25, 2003 8:42 PM

Don't throw it all away ;-)

While I love to use (more VB-style than hardcore C++) hungarian notation, I completely agree with Microsoft's view on how public stuff should be named. So all my public interfaces look the "Microsoft way", internally I use HN. Nice feature: Parameters are easy to spot inside the code of a method because it doesn't use HN unlike the other local variables.

Roland

Roland Weigelt

# re: Farewell, beloved Hungarian Coding.@ Sunday, May 25, 2003 8:45 PM

That's what I did for an hour of converting interface code (I have already thousands of lines of code of this library with HN, waiting any longer would only be stupid) but it doesn't look right to me. I see your point, however for myself it was harder to get rid of the habit to write HN code when I kept local variables HN style. It's a matter of getting used to I guess. after another hour of refactoring it doesn't hurt my eyes that much anymore. :)

Frans Bouma

# re: Farewell, beloved Hungarian Coding.@ Monday, May 26, 2003 12:35 AM

In the devteam I work in, everybody uses the mixed HN/non-HN approach. Comparing source code of other team members (with HN used internally) with sample code from the Web (no HN at all), I must clearly say that the code without HN is harder to understand (note that this is also valid for code that is not related to our everyday work, otherwise the comparison would be biased). The worst problem is finding the difference between local variables and private data members (if people don't use the "_thisIsPrivate" notation).

There is one huge advantage of HN that I don't see mentioned often in discussions: Intellisense. Typing the first characters and then invoking Intellisense will filter the entries shown in the drop down list very nicely (e.g. "m_" for all private members, "str" for all local strings, or "m_str" for all private string members). I even add a specific prefix for controls on a winform: "c_" (followed by a VB-style lvw for listview, lbl for label etc.).

Roland Weigelt

# re: Farewell, beloved Hungarian Coding.@ Monday, May 26, 2003 12:49 AM

If you want to do it totally correct, you should use this.memberVariable instead of just 'memberVariable'. It's a bit of extra typing, but makes it more readable IMHO (but because I'm now in HN-Rehab I'm not in that phase yet ;))

The intellisense argument is definitely true, in VB and C++ it's a real timesaver, however with the mixed api naming schemes in .NET it gets a bit messy IMHO, also with VS.NET 2003 the most used name is picked first, which saves you even more time.

Your point about the control prefix is a good one, if you look closely at MS' own contradicting documents they mention a prefix for a textbox or button control here and there. I'm not sure what I'll do about that, btnOK is very logical. Just having 'ok' as variable isn't telling me anything.

Also the different typed variables which are very closely related to a single item are now harder to formulate: sometimes you have 2 variables of different types holding the same semantic value in different type formats. You can do that easily with HN, you can't with this caMel/PasCal casing. I do get the feeling though you are forced to think deeper about a name for a variable, which is a good thing IMHO.

Frans Bouma

# re: Farewell, beloved Hungarian Coding.@ Monday, May 26, 2003 2:27 AM

> I had an input parameter 'iOperator'. You can't change that to 'operator' because that's a reserved keyword.

In C# you can escape reserved names with an '@', so you can define your parameter as @operator, and users of your library will see it as operator.

Fernando Tubio

Fernando Tubio

# re: Farewell, beloved Hungarian Coding.@ Monday, May 26, 2003 2:33 AM

hmm ok, didn't knew that, thanks. I think I stick with my new name for operator though. :)

Frans Bouma

# Frans Bouma's blog@ Monday, May 26, 2003 5:14 AM

Frans Bouma's blog

TrackBack

# Chad Osgood's Blog@ Monday, May 26, 2003 5:14 AM

Chad Osgood's Blog

TrackBack

# re: Concurrency Control Methods. Is there a silver bullet?@ Monday, May 26, 2003 7:23 AM

Are you suggesting to have something like pesimistic locking but without really locking the database? Like storing a row in a table that says 'I'm updating Customer #1'?

Andres Aguiar

# re: Concurrency Control Methods. Is there a silver bullet?@ Monday, May 26, 2003 7:33 AM

Yes, you use logic in your application to unlock / lock functionality in your application to perform operations. You can do this in a number of ways, f.e. in a table where you store 'locks on functionality' with a serialized transaction.

It takes some effort, but it pays off, the application will force you to focus on the organisational part of rolling out a software application which is where teh real benefits of software are found.

(similar problem: some developers complain about source control systems that they work against you when more than one developer wants to check out the same file. They forget why 2 or more (!) developers try to work on the same file, why isn't there 1 developer doing that work and they others doing other work so they prevent clashes/merge conflicts and other nasties)

Frans Bouma

# re: Concurrency Control Methods. Is there a silver bullet?@ Monday, May 26, 2003 6:33 PM

Mmm... I don't like it, it's a double edge sword....

What happens if a programmer 'forgets' to check the table? What happens if there is a totally different application that you cannot control that is using the same database?

The only way to implement it safely would be to use database locks, and we all know it won't scale.

I have some ideas, I'll blog on them as soon as I can find some time ;)

Andres Aguiar

# re: Concurrency Control Methods. Is there a silver bullet?@ Monday, May 26, 2003 6:43 PM

If you take into account what can happen when a programmer 'forgets' something he should do, any given example of good technology will fail. I don't see that as an argument. Locking parts of an application's gui or inner works because the current user is not allowed to work with it is not an easy way out, I admit. It's far easier to just let the database figure it out, which will lead to systems which are not that efficient (as I wrote). You don't need database locks. You can write a singleton which manages the 'locks'. RDBMS-es are not using different systems for managing their locks.

Using optimistic locking or similar to prevent concurrency problems is fighting the symptoms of badly designed software. It's better to design it RIGHT so concurrency problems are not an issue. If I might add: every major CMS vendor implements functionality locking, they lock in their guis editable items so other editors can't work on them while an editor is editing these items.

Frans Bouma

# re: Firebird .NET data provider v1.0 released@ Monday, May 26, 2003 10:51 PM

have you had a chance to work with firebird? With ms sqlserver becoming expensive ( 20K/cpu in a production environment? ), it provides an opportunity for a strong but much less expensive rdbms ( e.g. stronger than access and mysql ) to gain popularity.

i read the comments on the firebird site about the small footprint and fast transactions. i think i will have to download it and see what this new version is all about.

-Mathew Nolton

Mathew Nolton

# re: Firebird .NET data provider v1.0 released@ Monday, May 26, 2003 10:57 PM

Not with a recent version, I used Interbase a few years back but I don't think it's wise to compare that with todays firebird version. Like PostgreSQL, Firebird packs all the features you want (and more, it has iirc MVCC, which SqlServer lacks) from a database. I don't have the time at the moment, perhaps this weekend, to give it a testdrive. :(

If you've given it a testdrive, can you post/blog some thoughts about your experiences with Firebird? Thanks :) (so I can see if I should plan some time to dive into Firebird for my next generator toolkit or shouldn't)

Frans Bouma

# re: Firebird .NET data provider v1.0 released@ Tuesday, May 27, 2003 2:13 AM

Hello:

>so I can see if I should plan some time to dive >into Firebird for my next generator toolkit or >shouldn't

Oh!! if you mean to add Firebird support to LLBLGen this could be great!!!

For me Firebird is great, it's really stable and fast, and it has all features i need ( referential integrity, triggers, stored procs, transactions, ... ), really good admin tools, and it's multiplatform and .......... :D

Best regards
Carlos Guzmán Álvarez
Vigo-Spain

Carlos Guzmán Álvarez

# re: Firebird .NET data provider v1.0 released@ Tuesday, May 27, 2003 2:21 AM

Yes I mean support for Firebird in the next release, the O/R mapper variant LLBLGen Pro. I can't assure support via the initial shipment of the first version, but I can add support easily after that via a template/driver-addon update. Consider it on the 'essential items todo' list :)

Frans Bouma

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 3:07 AM

Did you see my blog on Serialized UIs? http://dotnetweblogs.com/donxml/posts/7441.aspx Have you read up on Avalon in Longhorn? Sure sounds like your vision is the same as mine, except the definition of a 'browser'. The line between WinForms and WebForms is being blurred by advancements in Longhorn.

DonXML

DonXML

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 3:18 AM

The 'browser' as an application should go away, iexplorer.exe should not live anymore. That's the idea I was talking about. This will not be possible with a flip of a switch (unfortunately ;) ), but if you ask me, I really do not see the relevance in the future for 2 'forms' namespaces, there is one gui: the desktop (or handheld or whatever).

I hadn't read your blog about serialized guis nor read about avalon (I only saw some screenshots on the windows supersite). What triggered me to write this blog was your remarks on how it should be rendering XML using namespace engines and the like. All neat, but that's not the problem, because with another rendercontrol it can be embedded in IE now. The concept should change, not which rendering engine should be used. (because to me XML is not about visualization, but about datastorage following a structured definition). But perhaps I'm missing something essential which will cause that what I think should be done will never happen :)

Frans Bouma

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 3:32 AM

We are on the same page, but our definitions aren't exactly the same. This is a new world, and until we get a standard definitions behind the ideas, that's bound to happen.

DonXML

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 3:35 AM

Hmm I think you're right.

I hope that the W3C isn't involved in next-gen webapplication gui definition standards though.

Frans Bouma

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 3:56 AM

What the hell are you talking about? WinForms and HTML share something in common - developers must control the positioning of various UI elements, i.e. controls. IE *does* have them - the HTML Common Controls. You can even use them in your own apps...including WinForms. IE6 on XP with Visual Styles enabled does, however, bind to CC6, in which case the controls are actually the Windows Common Controls.

Why did GUIs starting hosting in web browsers like IE and Mozilla - because graphics representation has long-since evolved and the methodologies to do them really hasn't. IE already takes care of all the rendering with very little work by a developer to re-invent the wheel to display nice-looking GUIs. Comparing the easy layout capabilities of HTML to Curses is a joke! Sure there are problems when using HTML for your only GUI (InstallShield Developer and Microsoft Money come to mind) but those are overcome by writing simple ActiveX components and implementing your own hosting interfaces, which is still a *lot* easier than rewriting everything like that yourself.

The web is an evolving thing and if browsers don't evolve with it, then *we'll* be the ones re-inventing technologies. Isn't it better than a single organization does it, tests it, supports it, and basically implements a "standard" that everyone uses?

Heath

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 4:00 AM

This sounds eerily similar to the Java-applet view of the future we heard in the mid-90's.

BTJ

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 4:04 AM

Heath: yeah yeah, but I'm not talking about the LOOKS, I'm talking about functionality known for years in f.e. win32 and now winforms which are not possible (or better: are much harder to develop) in HTML if ever possible. I'm not talking about Foo Inc. and their 2 page website with a mailform, I'm talking about webapplications with sophisticated GUI's which are hard to develop in HTML using IE and easy to do in winforms. The main reasons: HTML is markup, not a gui definition language and HTML works disconnected, while it shouldn't.

BTJ: I'm aware of that it sounds familiar :) Java had the disadvantage that the internet was not as connected as it is today: people dialed in via modems, today they have cable or ADSL and are always online, which blurs the separation between apps running elsewhere and locally.

Frans Bouma

# re: Firebird .NET data provider v1.0 released@ Tuesday, May 27, 2003 6:05 AM

Hello:

> Yes I mean support for Firebird in the next > release

:D There any expected date for the release of the next version ??

Best regards
Carlos Guzmán Álvarez
Vigo-Spain

Carlos Guzmán Álvarez

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 7:21 AM

Until Microsoft supports or makes an official statement regarding its position on projects like Mono, I would not count on the CLR and .NET to be a viable cross-platform development environment. Remember, the CLR may be an open standard, but the .NET framework is not. There is nothing stopping Microsoft from suing projects like Mono and DotGNU and that is enough to keep me away from thinking about .NET as a solid cross platform solution.

Joshua Hoover

# re: Firebird .NET data provider v1.0 released@ Tuesday, May 27, 2003 7:29 AM

"soon" :) I hope before august.

Frans Bouma

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 7:40 AM

See my url, we are on the case!

Kingsley Idehen

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 7:46 AM

Kingsley, cool :) I read somewhere the HWND issue is/was a bit of a problem with mono winforms, but if that's been fixed, I think mono will have a decent winforms implementation, which opens up a whole new ballgame :) Good stuff, Kingsley, keep up the good work :)

Frans Bouma

# re: Firebird .NET data provider v1.0 released@ Tuesday, May 27, 2003 8:34 AM

Hello:

Thanks and keep up good work :D

Best regards
Carlos Guzmán Álvarez
Vigo-Spain

Carlos Guzmán Álvarez

# DonXML Blog@ Tuesday, May 27, 2003 11:34 AM

DonXML Blog

TrackBack

# DonXML Blog@ Tuesday, May 27, 2003 11:34 AM

DonXML Blog

TrackBack

# Read/Write Web@ Tuesday, May 27, 2003 11:34 AM

Read/Write Web

TrackBack

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 5:57 PM

You got some points but I don't think you could expect to see Winform support "all over" in some time.

If you only target Windows user with the latest Microsoft OS then Winforms is great. If you plan to target other users then web might be the way to go.

Also...the web is no longer meant for stateless applications. You got many ways for implementing persistence in most web application frameworks. However, the applications are much harder to develop on the web.

Viking

# Tim Berners-Lee@ Tuesday, May 27, 2003 9:40 PM

Just for the record, Tim Berners-Lee made the first web browser... not Andreessen!

bruce

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 9:49 PM

hmm, in that context, what *is* a browser then? since with gopher you also could traverse hyperlinks (sort of). Berners-lee did indeed invent a tool/format to hyperlink texts, however the concept of the browser as we know it today is not made by Berners-lee afaik, but by Andreessen and his team at NCSA.

Frans Bouma

# About the indenting...@ Tuesday, May 27, 2003 11:01 PM

I think it removes the tabs if you choose to <enter> another line down because a lot of people (me included) dislike lots of whitespace on otherwise empty lines. If you want it to redo them when you move upward that could cause some really funky stuff when you're just cruising the sourcefile looking for something to copy and you see the cursor jumping around to each line's "next logical place to insert stuff" :)

I agree with the rest though, especially the compilation issues.

Jeroen

# re: My wish-list for the next Visual Studio.NET release@ Tuesday, May 27, 2003 11:08 PM

Yeah, the whitespace is indeed a burden. However, the editor knows it should indent when hitting enter, the editor could simply look at the indentation of the line ABOVE the current line (if the current is empty). Ah well... :)

Frans Bouma

# JonGalloway.ToString()@ Wednesday, May 28, 2003 5:51 AM

JonGalloway.ToString()

TrackBack

# re: Don't try to re-invent the browser, please.@ Wednesday, May 28, 2003 5:53 AM

Nope, TBL definitely bulit the first web browser as we think of it today. The team at NCSA just built a better one.

The reason people like myself are crying out for an update to IE is that it still doesn't support the current batch of standards to an acceptable level. It doesn't even support all of HTML yet (the <abbr> tag springs to mind), it's CSS2 support has a distance to go and the sooner they support alpha transparency in PNGs (which was standardised in 1996) the better.

I'm interested in the rendering engine, not the browser. As it is, I use Gecko engine browsers (currently Firebird) and can't really see myself moving back to IE even if its end user functionality (tabs, popup blocking, typeahead find and so on) caught up. It's just too convenient having a browser that I can install on any operating system I care to use.

Simon Willison

# re: My wish-list for the next Visual Studio.NET release@ Wednesday, May 28, 2003 7:28 AM

Your list is great! I'd like to add one minor thing:

Give us an option to either: remove the "Add Task" line from the task list or possibly move the "Add Task" line to the bottom of the task list.

Visual Studio takes up so much screen real estate - the add task line takes up so much room for something that I never use.

DM

# re: My wish-list for the next Visual Studio.NET release@ Wednesday, May 28, 2003 10:24 AM

Re Error harvesting. Long ago I worked on with a PL/1 compiler that attempted to continue after errors. It had to assume what you meant to say instead of the error, and one wrong assumption generated a mass of meaningless errors.

Be careful what you wish for!

David

# re: My wish-list for the next Visual Studio.NET release@ Wednesday, May 28, 2003 8:29 PM

David: heh yeah, I remember those days with the Sun 'CC' compiler when you forgot a ';' all hell broke loose. Fixing that ';' and all errors went away. :) However, what I ment was clearly repetitive errors which can be found but are now skipped. But indeed, we should be careful what to wish for :)

Frans Bouma

# re: Farewell, beloved Hungarian Coding.@ Thursday, May 29, 2003 4:15 AM

I was a strong proponent of using the "this->" convention for C++, but with C#, I don't see the point. There are no free functions, so you are either referencing a member function or a function in another object. So saying this.DoSomething() no longer adds a lot of extra readability/information for me.

I am torn on the notation subject. I don't, and never have, liked Hungarian to annotate the type of variable referenced. But I do like it to indicate purpose. m for member, a for local, in for input parameters, out for output parameters, k for constant, s for static. These add meaning and context to me. Dropping the a for local is not a big deal to me, but when I loose the context of input, output, and members. Then I start to have more of an issue.

I try to work both ways to get myself used to no prefix context. But it does hurt.

Jim Argeropoulos

# re: A quick update on LLBLGen Pro@ Friday, May 30, 2003 5:10 AM

Hi Frans,

I used your previous version on one or two projects and really liked it. One question though....what type of price range was you thinking for your next release?

Or is it too soon to say?

Thanks

John

John

# re: A quick update on LLBLGen Pro@ Friday, May 30, 2003 8:40 AM

Bindable entities by implenting a binding interface upon a business entity... hmm looks farmilair ;)

Frans you thought about entity v.s. value objects? When is an object considered to have an identity and presumable be and entity? Or an object with no identy presumable a value object(depending on the object context?).

Paul Gielens

# re: My wish-list for the next Visual Studio.NET release@ Friday, May 30, 2003 8:49 AM

About the help tab: I find it much easier to use external help. Then I can use Ctrl+Tab to switch between editors and Alt+Tab to switch to the help window and back.

Dan

# re: A quick update on LLBLGen Pro@ Friday, May 30, 2003 8:56 AM

John: around 175 euros incl. VAT for a site license, thus unlimited number of developers can use that license in your company.

Paul: Entities are the elements you focus on when you design an ORM/NIAM model, thus f.e. the tables in your database. The entity classes talk about the same entities as the entities found in the database, they should be the same.

Besides these entities you have views defined over a number of attributes of a collection of entities. These are also supported (typed datatables).

Frans Bouma

# Emitter@ Friday, May 30, 2003 9:03 AM

Emitter

TrackBack

# re: Entity: why do some people who write IT books re-invent definitions?@ Saturday, May 31, 2003 2:06 AM

Evans, Domain Driven Design
@ http://www.domaindrivendesign.org/book/

This is NOT Fowler... I added Fowler as a ref because of his thinking about identity maps. I'm just telling there's a difference between objects that have an identity (entities) and objects that don't (value objects). This makes a BIG difference within domain models and because LLBLGen Pro seems to generate large parts of the domain model as well... Read a few lines in Evans's manuscript and perhaps we'll conclude we are thinking 1:1 but blogging the other way around.

Paul Gielens

# re: Entity: why do some people who write IT books re-invent definitions?@ Saturday, May 31, 2003 2:15 AM

I don't see why people have to be focussed on a difference, of course they are different: one is defined in the persistent storage as an entity and the other one isn't. Value objects are views, collections of attributes which do not have a semantic meaning, entities do. The definition is over 25 years old, but in the definition you quoted, an entity embeds logic: they encapsulate operations. Which is wrong, the logic is embedded in code outside the entity, the entity using code.

Frans Bouma

# Frans Bouma's blog@ Saturday, May 31, 2003 7:25 AM

Frans Bouma's blog

TrackBack

# XUL is the future - The Desktop War is Heating Up @ Sunday, June 01, 2003 10:29 AM

Wonna see the future today? Check out XUL (XML UI Language) @ http://xul.sourceforge.net

HTML was the markup for the browser. XUL is the markup for the desktop. The browser war is over, but the desktop war is just getting started.

Gerald Bauer

# re: About sharing Intellectual Property, USP's and Patents@ Tuesday, June 03, 2003 1:43 AM

Lol, my girlfriend is studying commercial economics (marketing), so this basically means we’re in the same boat.

Is your wife participating in the marketing offensive for LLBLGen Pro?

Paul Gielens

# re: About sharing Intellectual Property, USP's and Patents@ Tuesday, June 03, 2003 1:55 AM

hehe same thing indeed! :D

She helps with the positioning of the product, the formulation of the USP's, basicly to make it a product that appeals to a wide range of people instead of just die hard nerds who live in a code-editor all day. :) Research of target audiences, analysis of what they really want is very important, because no-one wants to develop a tool that is perhaps kick-ass but is not used by a lot of people because the target audience wants other things than you deliver :)

It's very funny how developers always try to avoid others messing with the specs of what they have to write but at the same time developers are also very busy to convince marketing people that the developer knows everything about USP's, what's really important to the user etc. :) The best software is still written by developers who have convinced themselves that stuff like "It just works (tm)", "it does what people want it to do" and similar phrases, are the true sellers of software and not feature number 10987342 which is used by 0.001% of the user-base :)

Frans Bouma

# The Bleeding Edge@ Tuesday, June 03, 2003 6:33 AM

The Bleeding Edge

TrackBack

# re: Microsoft, developer editions should be free.@ Wednesday, June 04, 2003 10:09 PM

I agree Frans, but at least it's much better than the original tag price, and it will certainly appeal some new database developers.

Paschal

# re: Microsoft, developer editions should be free.@ Wednesday, June 04, 2003 10:25 PM

I didn't even know the original price tag was that huge :) (a MSDN subscription makes you lazy I guess ;) ). There are a lot of developers in the world who do not have a lot of money but do know how to code (and are now working with free tools to write their .NET code). If MS truely wants to win the 'war' against Open Source and free tools, they should act better. But ok, it's a start, that $49.- .. :)

Frans Bouma

# re: Microsoft, developer editions should be free.@ Thursday, June 05, 2003 1:59 AM

I seem to recall that the shipping on that free Oracle copy is pretty pricey, though - wasn't it in the neighborhood of $35 for a full set of CDs?

Mike Gunderloy

# re: Don't try to re-invent the browser, please.@ Thursday, June 05, 2003 11:17 PM

Maybe we do not all have the same use of HTML. Said simply: If you think I'm going to develop my web site using web forms, then you are dreaming. I think, you are talking about different things, different needs.

jonx

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 12:04 AM

thats still not on the desktop dude.
and quite frankly i dont think the bulk of the mono effort is centered towards desktop applications.

Tq

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 12:36 AM

Frans, the problem is more on the user experience. And believe me, I tried with non developers people, it's a nightmare.

Installing Linux properly with 10 people sharing the same network is not really there.

And I like Linux, but as a developer and for some specific applications. ;-)

Paschal

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 12:42 AM

It can be tough to setup, I know :) I've worked with Unix for a few years so I could manage, but indeed, if you're used to 'C:' and nicely layed out folders, you get confused rather fast. However, if the boxes are setup ok, like: the user sees a desktop with open office on it, it can browse corporate folders shared on a server (which are mounted as a folder, great system), work with the files and read/write email, there is not a lot they can screw up. Most people in offices spend their day in office applications, so if you can make the box to be good at doing that, a LOT of businesses can use linux at the desktop today.

Mind you: even today a lot of businesses are on win9x/winME, and that's no picknick either ;)

Frans Bouma

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 1:21 AM

Frans, one term says it all: TCO.

So Linux can read/write MS Office docs. Problem is, you STILL have to retrain every single user to use some very separate apps there.

Virtually every shop out there with predominantly MS desktops will have to retrain their support too. Nowadays the help desk is a decent percentage of TCO for a company.

Seems the EXACT same argument was being made back in 1998-1999. You know, the old "we have apps" and "we have better security" and "bug fix releases come quickly" and "the purchase price is next to nothing". And Linuz since then has what? Moved from 2% market share to 3% on the desktop?

TCO, bud.

Dave

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 1:32 AM

Retraining is an issue indeed, however is there a clear view on this, how much the impact is? I think it greatly relates to the level of computer savvyness of the user. A word processor isn't that hard to work with, type, select font, save, print. However, support has to be retrained and that's costly, but even then: when your organisation is on NT4 + win98 and now moves to win2k3 server + winXP, it's day and night for both support and end user. THere, too, support personel has to be retrained to get the most out of the platform. I don't know if that retraining will be that much different from the retraining of the sysadmins to work with /etc files :)

(after all, linux or FreeBSD for that matter, isn't anymore at the level of 1998, 1999, where it was a mess. A lot of the configuration files have now gui applets, are better documented and there is overall better documentation. It still takes some effort, but I still believe its ready for the desktop and it can be worth it. With Mono on linux, (if everything pans out correctly), applications written for windows (desktop apps) can work on mono on linux as well, which makes the switch worth it.

Frans Bouma

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 2:21 AM

The problem is not technical. Even if Linux was easier to install and had everything an end-user would need, they will need:

- A worldwide distribution model. MS has it, and is very difficult to build.
- Make the internal help desks and support center to support Linux. This is _very_ hard to acomplish. The companies invested _a lot_ of money in training people with Windows technologies
- Books, training courses.
- Partners that can make money on it. There are much more ISVs in the Microsoft arena than in Linux's
- Probably more reasons ;)

Andres Aguiar

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 2:52 AM

Interesting article in the last InformationWeek: http://www.informationweek.com/story/showArticle.jhtml?articleID=10100565

"More than a third--38%--say Linux's greatest weakness is the limited availability of business applications for the operating system, up from 32% a year ago. Nineteen percent say the proliferation of different flavors of Linux is a problem, up from 12% a year ago, raising the fear of incompatibility among the various versions, as happened with variants of Unix."

And not to mention the pending legal action from SCO, which undoubtedly is going to have some impact. Already, there are analysts (I think Gartner but I may be wrong) that have cautioned against using Linux at all right now in the face of that action.

Tim Marman

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 2:55 AM

Duh. If I read Randy's original post, I would have realized that it was Giga and not Gartner who said that :)

Tim Marman

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 4:36 AM

I don't know how many of you have used Lindows, but Lindows is VERY usable. My mom -- which is not quite techno-phobic, but definitely a hard sell -- would be comfortable with Lindows.

However, I disagree that Mono will make the shift. The only way that could happen is if they had a 100% solid Windows Forms implementation, so there could be desktop app compatiblity. Not only is Ximian not interested in doing it (someone else is), I have grave doubts that anybody short of a team of dozens, maybe hundreds, of Windows _experts_ could ever pull it off. Windows is a moving target, as Wine has showed, and Windows Forms is so leaky an abstraction that it's impossible to forget that there's Windows underneath.

Brad Wilson, The .NET Guy

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 4:41 AM

Brad: windows forms is such a pain because it is based in HWND's and messages when you want to do tricks (and who doesn't). If you can create an api that has the same interface as system.windows.forms, but calls into the gnome/kde libs, it will work. If mono isn't gonna do winforms, it will indeed be something else that needs to make the shift. I also don't see why a winforms implementation should use wine or a win32 imitating layer, everything that's needed is already there, in X.

Frans Bouma

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 7:03 AM

Maybe everyone knows the basic functionality of a word processor or a spreadsheet, but it's the power users who know the shortcuts. Where MS flat out beats the competition is standardization of everything.... toolbars, menu shortcuts, ... even a unified scripting language.

These power users do alot for a company. They heavily influence perceptions. They are the most highly productive employees. They deal with the brunt of questions that the help desk would otherwise have to.

Compare your arguments for Linux to those elitists who insist on tableless layouts in websites. In a sheltered corner... weblogs made by us geeks and read by us geeks who generally have standards-compliant browsers... this sort of stance works fine. In the real world... businesses strapped in bad economic times seeking every dollar of revenue from other companies whose lack the support to upgrade their browsers or connections... is it any wonder CSS still hasn't caught on?

Dave

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 8:31 AM

Anyone else notice that the linux guys only halfway decent products are the ones they clone from MS or some other commercial company? Then, they say they hate MS, because they just steal stuff from everyone. Some people have a bad case of Robin Hood syndrome. I would hate to see the day when commercial commercial software companies cease to exist... there wouldn't be any cool products to clone anymore. :-)

Jesse Ezell

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 9:06 AM

errr, doesn't every software company clone aspects of others? I don't know, but 'Excel' isnt a microsoft invention, nor is 'wordprocessor' or even wysiwyg wordprocessor :)

Frans Bouma

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 9:21 AM

Mono is far, far... far from ready. Besides Mono is claiming an independant framework and not a 1:1 copy for .NET. And what'll happen with Mono once MS releases .NET 5.0 concerning compatibility? I can't imagin commercial companies taking such a risk for serious apps.

Paul Gielens

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 11:45 AM

I don't think Mono will be enough. I think it will increase Linux's viability as a server platform, but not for desktops. The availability of good applications and good support for end users is the key there.

randy

# re: Optimization the right way: optimize your algorithms@ Sunday, June 08, 2003 4:38 AM

Interesting article, I like your approach. At the end of the day we use dotnet for speed of development, who has the time to think about the msil and low level optimisations ?

Gotta respect the demo programmers anyway, if you could get such amazing effects out of an amiga or an st we should trust you when it comes to dotnet :D

OmegaSupreme

# RE: Windows.Forms on Mono@ Monday, June 09, 2003 7:56 AM

I'll be very happy if we can get to a point where most .NET desktop applications will run on Mono , but it's not going to be easy. The problem is indeed Windows.Forms, as Brad Wilson said.

The mono WinForms implementation IS based on Wine, and is thus is limited by the extent of Wine's Win32 coverage. As Brad said this is always going to lag by a certain amount, although I hear it's currently good enough to run MS Office and StarCraft (GTA 3 soon, apparently)

Frans: I watched the mono WinForms mailing list go over and over the question of whether their implementation should be based on Wine or not. What it came down to was that anyone who had *really* looked into it found out that WinForms is *such* a leaky abstraction that you couldn't do it without emulating at the *very least* all the message pumping behaviour of Windows.

The other problem is that (in the main) the only ppl who really know how WinForms works are old Win32 developers, who understand what is going on beneath the abstarction. These ppl are the only ppl who are going to be able to write a reasonably compatible implementation of WinForms in a reasonable amount of time. Unfortunately, they don' t (as a rule) know GTK/QT/X, and generally are used to programming on Windows. I think the wine-based WinForms implementation is going to flesh out a lot quicker than any non-wine one could.

So, as it stands, to run WinForms apps, you'll need Wine. For all non-WinForms apps, though, mono should be great.

In the end, I think this is a shame. When I first heard about Mono, I was thinking about how great it would be to just be able to run Windows apps on Linux. I've since seen that this probably won't happen (seamlessly). What you CAN do, however, is write a cross platform non-gui app, or even a cross-platform gui app by using GTK# or QT# (& I think there is now a SWT port as well).

Wow, I've written too much. I'll shut up, now!

Swythan

# re: A quick update on LLBLGen Pro@ Tuesday, June 10, 2003 9:26 AM

So, Frans, when are you going to add the SQL CE option? That would be really sweet!

Darren Pruitt

# re: The 'benchmark' code@ Thursday, June 12, 2003 6:32 PM

Frans,
Here is my test on a Celeron 1.8 running XP Pro. I can run more tests against separate servers later.

The dynamic query wins by 17 seconds.
Dynamic - Total time: 00:01:33.5845680.
StoredProc - Total time: 00:01:50.7292208.

This is good news, since I am building a routine to copy data between tables on different servers using DB2/400. The class uses a select statement to retrieve the source data, then creates an insert statement from the source dataset for the target.

I wanted to handle this for many tables and potential libraries and did not want to create and manage all the stored procedures. I don't care if the table structures change and have a generic copy routine.

I will wrap this in a web service and use it to copy policies between our production and test libraries that reside on separate servers.

I enjoy reading your common sense and practical articles and comments.

Ron

Dynamic query benchmark
Benchmark started on: 6/13/2003 12:14:45 AM.

Benchmark ended on: 6/13/2003 12:16:19 AM.
Total time: 00:01:33.5845680.
Amount of runs: 10000. Max. amount of rows retrieved: 830
Stored procedure benchmark
Benchmark started on: 6/13/2003 12:16:19 AM.

Benchmark ended on: 6/13/2003 12:18:09 AM.
Total time: 00:01:50.7292208.
Amount of runs: 10000. Max. amount of rows retrieved: 830

Ron Steiger

# re: Feeding the trolls@ Friday, June 13, 2003 8:32 AM

Please don't take my post as an attack on anyone. It was just a satirical take on Scott's bloodbath of rage.

Marc

# re: Feeding the trolls@ Friday, June 13, 2003 9:12 AM

Oh, come on Frans. Lighten up a little. Scott's post was funny, and given how frequently self-styled "industry authorities" hold forth about things about which they clearly know nothing, such responses are a harmless bit of venting.

I would agree with you that responding with ad-hominem insults to every ignorant opinion column you read would be excessive, but a choice response to the particularly egregious can be healthy, IMO. No harm in letting off a little steam occasionally.

G. Andrew Duthie

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 12:23 AM

Good story Frans! If it makes you feel better, I have also wanted to gather a couple of static functions under a contract and realized that it wasn't possible. I also felt somewhat "ashamed" afterwards, but what the heck, it's not the end of the world.
:-)

So, what solution did you choose? Skipping the interface or skipping static?

Best Regards,
Jimmy
###

Jimmy Nilsson

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 12:24 AM

lol, this really sounds Familiar to me....

Jonne Kats

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 12:30 AM

Frans, you seriously disappointed me ;) No clue what methodology you use, but eXtreme Programming (XP) would have trapped that issue probably in the first iteration. Start prototyping dude!

Paul Gielens

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 12:30 AM

:)
I skipped the interface. The static methods are really handy, since they're one shot calls, so having an object for just 1 call is not that handy. :)

Frans Bouma

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 12:31 AM

Paul hehe I'm not gonna bite! am NOT! :D :)

Frans Bouma

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 12:33 AM

Hehe, wasn’t my intention… just a little teaser ;)

Paul Gielens

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 12:37 AM

I know ;)

Frans Bouma

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 12:50 AM

Your implementation SCREAMS Factory Pattern. It's what I use in GenX.NET when I deal with my OutputProviders without needing to know which provider I am using. I'm going to be writing a Factory Pattern tutorial sometime early next week, after I RTM GenX.NET 3.0. Until then, don't scrap your code.... you're just missing one more piece to the puzzle.

Any BTW, you didn't make a fool out of yourself. It can be done.

Robert McLaws

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 12:53 AM

Also, I know this method would be perfect because GenX.NET uses it for the exact same reason... specific implementations for specific databases. Believe me, understanding this method will take your coding to a whole new level.

Robert McLaws

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 12:56 AM

Robert, I do use a lot of factories, I have the GoF book. :) In my DAO objects (using the DAO pattern) I simply want to call IActionQuery query = DynamicQueryEngine.CreateInsertQuery(//...);

Which one is based on the using directive at the top. This is generated code, so I only have to change 1 line to make it work with Oracle f.e. and the generator generates Oracle code. I understand that when I create the DAO in the DAO factory I can also create the right DQE object and pass it to the DAO, but that's not that efficient because these DAO objects are not living very long. A static method is then more appropriate. Admitted, it can be done using a factory, but a static method in this case is more efficient I think. It's not a big deal, the templates used for the code are closely related to the DQE and the database driver used, so it's a complete package, but I was just wondering if I could create an interface for this, but I couldn't. :)

Frans Bouma

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 1:03 AM

Robert: I don't have a central cache system where I can store generic objects, so I can't cache these kind of objects like the DQE. If I could, I definitely would have used the factory route. But now I can't. Image that when I load 2000 customer objects in memory. Then I have 2000 times created the DQE. That's pretty amazingly inefficient :)

But I appreciate your thoughts. You definitely understand what's required for good OO software :)

Frans Bouma

# re: Finally my own skin@ Saturday, June 14, 2003 4:17 AM

The menu and title aren't visible .. Change the color of the text also ;)

Best regards
Marcus

Marcus

# re: Finally my own skin@ Saturday, June 14, 2003 4:22 AM

hehe I know :D I had a margine defined somewhere that bugs the crap out of it. I've almost fixed it :D (famous last words)

Frans Bouma

# Mozilla@ Saturday, June 14, 2003 4:27 AM

Don't forget to test on Mozilla. I'm almost positive what I'm seeing is not correct, using Mozilla Firebird 0.6. :-D

Brad Wilson, The .NET Guy

# re: Finally my own skin@ Saturday, June 14, 2003 4:31 AM

good tip, thanks :)

Frans Bouma

# re: Finally my own skin@ Saturday, June 14, 2003 5:38 AM

I second the Firebird problem. The horizontal lines in the left column extend out of the left column and into the content area a bit.

sirshannon

# Emitter@ Saturday, June 14, 2003 6:05 AM

Emitter

TrackBack

# re: Finally my own skin@ Saturday, June 14, 2003 6:09 AM

phoenix/firebird's lines are fixed. Now I only have to battle with the borders below and at the right which seem to appear in firebird but are not there in IE (MyIE2).

Opera doesn't eat the javascript btw. Not that I care, but perhaps there is a solution. It doesn't understand the createElement statement.

Frans Bouma using Firebird

# re: Move away from stored procedures or not?@ Monday, June 16, 2003 12:41 AM

Very interesting points. In most of the corporate systems, if code is considered to be the the crown-jewels (assets) then *stored-procedures are surely the diamonds. I think there'll be conversion utilities (*SPs into embedded code) to help transition (if any) but it will still rest with the performance of the system. In addition to security, most of the *SPs are valued for performance while handling high volume transactions - if it can shave off a few millisecs then it'll certainly get serious consideration. Good post Frans.

SBC

# re: Move away from stored procedures or not?@ Monday, June 16, 2003 10:33 AM

Views are great. Indexed views are even better. Too bad SQL Server 2000 Enterprise is so damn expensive!

Travis

# mads studentblog@ Monday, June 16, 2003 10:39 AM

mads studentblog

TrackBack

# Andres Aguiar's Weblog@ Monday, June 16, 2003 10:39 AM

Andres Aguiar's Weblog

TrackBack

# re: A quick update on LLBLGen Pro@ Tuesday, June 17, 2003 4:35 AM

Any plans for two-way tools a la DeKlarit? If not, what is the process for updating the DAL as the database changes across releases of software?

--Bruce

Bruce Onder

# re: A quick update on LLBLGen Pro@ Tuesday, June 17, 2003 4:39 AM

No, there are no plans for two way tools, since these can be pretty problematic. When the database changes, you simply refresh the catalog view, LLBLGen Pro will enlist the classes, typed lists and other elements which are changed because of the changed database and you can apply these changes then, regenerate the code, and are set.

Frans Bouma

# re: A quick update on LLBLGen Pro@ Tuesday, June 17, 2003 11:47 AM

Okay. I like some of the features DeKlarit has, but I agree with you that these can be problematic.

I ran 1.2 on Northwind with no problems. I am next going to run it on the database created by my current DeKlarit project and see how the code looks there. :)

--Bruce

Bruce Onder

# re: A quick update on LLBLGen Pro@ Tuesday, June 17, 2003 8:50 PM

Which features do you like of DeKlarit? Can you describe them a bit? Perhaps LLBLGen Pro already will support them :)

LLBLGen Pro is in every word a successor of LLBLGen v1.0 so it is not a simple upgrade, it is a new tool with a broader functionality spectrum, which means that the functionality of v1.0 is extended and re-implemented and new functionality is added. The concept of what the generator will generate is moved upwards, from the DAL to the DAL + BL Facade, which is now integrated. :) (hmm, I'm starting to sound like a person from marketing ;))

Frans Bouma

# re: A quick update on LLBLGen Pro@ Wednesday, June 18, 2003 1:44 PM

In theory I like the fact that Deklarit lets me focus on the object model and builds the data model behind the scenes for me. In practice the tool is a bit hard to use, but this is IMO user experience.

For example, in DeKlarit I can create the following entity:

Client
ClientID (PK)
ClientName
TransactionID
TransactionDateTime
TransactionAmount
ClientBalance (sum(TransactionAmount))

This will produce two tables for me, Client and Client1. It would produce a Transaction table only if I created a separate entity (what they call a business component, which i feel is a misnomer) called Transaction and had those same property names in it (Deklarit uses name/identity equivalance on properties).

Bruce Onder

# re: A quick update on LLBLGen Pro@ Wednesday, June 18, 2003 1:48 PM

oops, the transaction* properties should be indented a few spaces to show they are a level inside of the Client entity.

Bruce Onder

# re: A quick update on LLBLGen Pro@ Wednesday, June 18, 2003 2:39 PM

Will there be strongly typed tables in 2.0?

Bruce Onder

# re: A quick update on LLBLGen Pro@ Thursday, June 19, 2003 6:53 AM

There will be strongly typed tables, so called typed lists. These can be designed in the tool (the columns and the list of entities to retrieve them from) and contain filters in code, so you can filter on the list at runtime. These are typed datatables.

I'm a strong believer of abstract modelling of datamodels, by using NIAM or ORM (see http://www.orm.net). Therefor modifying a database in LLBLGen Pro is not necessary since the database is created using an E/R model that is derived from a NIAM / ORM model created by a software architect.

LLBLGen detects automatically relations between entities (1:1, 1:n and m:n) and adds properties to retrieve related data automatically. So you can walk these relations by simply pressing the '.' :) -> CustomerEntity c = new Customer("ABC");
string ProductName = c.Orders[0].OrderDetails[1].Product.Name;

All lazy loaded. Also available in a datagrid, you can bind c.Orders to a datagrid and walk the complete model from there, in your grid :)

Frans Bouma

# re: Harry Potter reloaded@ Saturday, June 21, 2003 9:10 PM

You're joking right ;)

Paul Gielens

# re: Harry Potter reloaded@ Saturday, June 21, 2003 11:10 PM

No :) Harry Potter rocks. At first I thought "but... that's a kids book", but that's not true, the books are very funny, you should read one :)

Frans Bouma

# re: Harry Potter reloaded@ Sunday, June 22, 2003 1:00 AM

Never read "one" myself so I better not comment directly related to the book. Although in a twisted way it's quit funny, just imagine reading a book of Harry P. lol Get your sorry ass on the beach in Scheveningen Frans and enjoy the weather reading some serious garbage like the Panorama or even more worse, the Privé ;)

Paul Gielens

# re: Harry Potter reloaded@ Sunday, June 22, 2003 1:06 AM

hehe :) We have all 5 books of HP, and when you start reading one, you can't stop. It's not written like a kids book, it's readable :) and the beach? Are you nuts? It's raining here :)

Frans Bouma

# Emitter@ Sunday, June 22, 2003 7:26 AM

Emitter

TrackBack

# re: A quick update on LLBLGen Pro@ Sunday, June 22, 2003 9:38 AM

Nice! Hurry up, summer! :)

--Bruce

Bruce Onder

# re: LLBLGen Pro screenshot@ Monday, June 23, 2003 10:33 AM

Nice work Frans!

Chad Osgood

# re: LLBLGen Pro screenshot@ Monday, June 23, 2003 10:36 AM

Thanks :) Most of the work done is behind the scenes, this is the first time I can actually show something that is visually attractive and somewhat interesting. :)

Frans Bouma

# re: LLBLGen Pro screenshot@ Monday, June 23, 2003 10:38 AM

Very nice UI. Is that the Magic library from Cronwood?

Patrick Steele

# re: LLBLGen Pro screenshot@ Monday, June 23, 2003 10:42 AM

Yes, that's the magic library. I haven't used all of its power though, but it is a very handy library for dynamic gui building, you can create powerful gui's in no time. :)

Frans Bouma

# re: LLBLGen Pro screenshot@ Monday, June 23, 2003 11:13 AM

Yeah, I've done some prototyping with it and it's a very nice package for the price (free!).

Patrick Steele

# re: Create #region macro for C#@ Monday, June 23, 2003 4:38 PM

If you are looking for a tool to quickly place templated code such as regions or properties take a look at QuickCode.Net I have been using it for a while and I like it.

Wes Haggard

# re: LLBLGen Pro screenshot@ Monday, June 23, 2003 9:03 PM

It is looking great..
Will we see any beta's or opportunities to test :-)

Keep up the good work

Michael Hensen

# re: LLBLGen Pro screenshot@ Monday, June 23, 2003 9:09 PM

There will be a short beta cycle of course :) I haven't decided yet if that will be a closed beta or an open beta. Of course there will be a trial version when it's released :)

Frans Bouma

# re: LLBLGen Pro screenshot@ Monday, June 23, 2003 9:09 PM

I use LLBLGen alot, a great time saver. Looking at that screenshot and feature list though, guess I'm gonna have to scrape together a few bucks this time. Go easy on us here in Africa though ;-)

Senkwe Chanda

# re: LLBLGen Pro screenshot@ Monday, June 23, 2003 9:18 PM

Senkwe Chanda: :) I'll do everything I can to make the price as low as possible. It will already have a site license instead of a per-seat license, so you pay 1 price and all the developers in your department can use the tool. It will be around 150-170 euro.

Frans Bouma

# re: LLBLGen Pro screenshot@ Tuesday, June 24, 2003 7:26 AM

Exciting, "generates a complete O/R mapper framework" is just what I wanted to know! I hope that our discussions about OR Mapping will be expressed in tool supremacy!

Heads up!

ps: What happens with heavily normalised models? Is your tool "smart enough" to let the end user be the director of what to do with what in contradiction to many, many commercial tools out there?

Paul Gielens

# re: LLBLGen Pro screenshot@ Tuesday, June 24, 2003 8:30 AM

"What happens with heavily normalised models? Is your tool "smart enough" to let the end user be the director of what to do with what in contradiction to many, many commercial tools out there?"
I know what you are refering to :) but I kept the 1 table per entity restriction. However, it shouldn't be a problem, here is why: at the left you see f.e. a relation between employee and customer, over the entity order, a m:n relation. The tool finds these relations which are not obvious to the user. ('orders' is not an intermediate table between the employee-customer relation, the relation is created using 2 1:n relations).

It is possible to navigate from one entity to any other entity in the system, using the relations. The code generated will embed as much logic as possible to make you navigate/retrieve related entities from any entity you currently have an instance of. So heavily normalized databasemodels are not a problem, you can navigate to any related object without a problem.

Not in the screenshot, because I have to create the designers yet, are the typed lists. These are read-only typed datatables based on entity definitions, which can span more than 1 table/entity, f.e. all orders with the customer fields joined with every row. So for data-retrieval, where bulk data has to be retrieved which spans more than 1 table, you can define typed lists, and the typed list code embeds rich logic for filtering and clever instantiation.

Every entity definition has also a typed collection (hi mr. Fowler!) which embeds logic to work on groups of entities directly in the persistent storage or in the collection itself (and is bindable too :))

I'm pretty sure that on the DML front, you can work easy with the entities and the relations between the entities (plus the dynamic query engine and the filters you can define to retrieve groups of objects also f.e via filters on related objects.), and on the data retrieval front, you can work with indivitual entities, the entity collections or with the typed lists.

I also implemented stored proc execution as a bonus for people who have stored procs they want to embed (select sp's only).

Frans Bouma

# re: LLBLGen Pro screenshot@ Tuesday, June 24, 2003 8:33 AM

(oh, the typed lists use the dynamic query engine and you can f.e. define a dynamic query using the same logic in your own code if you like. Yuo then can retrieve the data in a normal datatable, but the overall flexibility is there. ).

Frans Bouma

# re: My wish-list for the next Visual Studio.NET / .NET api release, part II@ Wednesday, June 25, 2003 1:43 AM

Hi Frans

I recently created tool to generate NAnt build files based on VS.NET project files. If you're intrested check out my post: http://weblogs.asp.net/jan/posts/9255.aspx

Greetz
Jan

Jan Tielens

# re: My wish-list for the next Visual Studio.NET / .NET api release, part II@ Wednesday, June 25, 2003 1:46 AM

I've read that posting, thanks for the heads up :) I haven't tried it yet, I already made nmake files for the project I'm currently working on, but for the next time I'll consider it.

Frans Bouma

# re: My wish-list for the next Visual Studio.NET / .NET api release, part II@ Wednesday, June 25, 2003 2:27 AM

A great wish list - unloading an assembly has always been at the top of my list.

Alex Hoffman

# re: My wish-list for the next Visual Studio.NET / .NET api release, part II@ Wednesday, June 25, 2003 3:28 AM

A great list, Frans. I'll add that for the documentation (MSDN Library), I would like to see the .NET Compact Framework documentation as a separate collection rather than mixed in with the full .NET Framework documentation.

-Nino

Nino Benvenuti

# re: My wish-list for the next Visual Studio.NET / .NET api release, part II@ Wednesday, June 25, 2003 4:35 AM

Darn, I forgot one:
Make the EventArgs object be able to hold an object reference. Now you have to create new eventhandlers every time you want to pass simple event data, you have to define an EventArgs derived class plus eventhandler.

Frans Bouma

# re: LLBLGen Pro screenshot@ Wednesday, June 25, 2003 10:19 AM

Looking good! I can't wait. Just a reminder to take special care for making the dev model of this work well for multiple developers using source control and such.

a

# re: LLBLGen Pro screenshot@ Wednesday, June 25, 2003 10:23 AM

It will generate sourcecode in a directory, not overwriting readonly files. Therefor, ideally you'll do this: check out the files, generate new code, overwriting the files, check in the files again. There are a number of sourcecontrol systems and I can't support them all.

The whole idea is that the generated code is an assembly you work with, thus the code should be compiled as a single assembly, and be referenced from own code, you also don't edit generated code, you derive from the generated code. Therefore, source control misery is limited to a bare minimum.

Frans Bouma

# re: My wish-list for the next Visual Studio.NET / .NET api release, part II@ Wednesday, June 25, 2003 11:37 AM

Here's a couple I'd like to add to the .NET API:

1. More interfaces. Not enough classes derive from interfaces, which makes interface-based testing (read test-driven development) almost impossible. (Think HttpContext.)

2. Better abstraction in ADO.NET. You can't really write clean generic data access code because you can't create a DataAdapter without knowing whether you're doing SQL or OLEDB.

Those two have bugged me for a while.

Peter Provost

# re: My wish-list for the next Visual Studio.NET / .NET api release, part II@ Friday, June 27, 2003 2:25 AM

::Better abstraction in ADO.NET.

Worse - when you use visual deisgn (drag drop them onto a form) you get all the stuff hardcoded. Terrible.

I know you should never code this way, but they DO support it - and they do so wrong.

Thomas Tomiczek

# re: About code generators / generating code@ Sunday, June 29, 2003 12:17 AM

We used a slightly modified version of LLBLGen 1 for a project at the Fontys University. This saved us roughly 70% of the development time...not only because of the generation features, but also the iterative development made possible with LLBLGen. It's fast and easy to do roundtrip engineering using Visio creating the E/R, let LLBLGen update the DAL accordingly and slapping business-logic on top.

About 90% of the generation tools out there aren't useful indeed.

Just to note: LLBLGen also has its weak points... I'm not pr'ing over here ;)

Paul Gielens

# re: About code generators / generating code@ Sunday, June 29, 2003 12:24 AM

:)

Code generators have disadvantages too, like when they are not able to generate the code for the functionality you define in them, or the generated code is not up to par with the functionality requirements you have. I don't think the percentage of useless generators is around 90%, but there are a couple which are not useful in a wide range of applications, however no tool is (try hammering a nail with a screwdriver ;)). That's why you have to make a choice which generator you'll use. That's the question you have to ask yourself, not if generation of code is useful, because it is.

The working-method you describe is the one I forsee also: modelling abstract database models in a high end tool, generate code to work with the physical result of that modeling and on top of that, if possible generate BL code, and if not, hand-develop it. With a form-designer to do the gui (which is also a code generator ;)) it's easy to cut down development time using generators. It's just weird not a lot of people understand that. Ah well, the Not Invented Here (NIH)-syndrome is still roaming I guess. ;)

Frans Bouma

# Datagrid Girl@ Sunday, June 29, 2003 5:48 AM

Datagrid Girl

TrackBack

# Jonne Kats@ Sunday, June 29, 2003 5:48 AM

Jonne Kats

TrackBack

# Eric J. Smith's Weblog@ Sunday, June 29, 2003 5:48 AM

Eric J. Smith's Weblog

TrackBack

# Patrick Steele's .NET Blog@ Sunday, June 29, 2003 5:48 AM

Patrick Steele's .NET Blog

TrackBack

# re: Don't try to re-invent the browser, please.@ Sunday, June 29, 2003 11:02 PM

You have to be kidding me. System.Windows.Forms is such a steaming pile of piss that Mono has to use Wine (windows emulation) in order to mimic it exactly. The "HWND issue" is most certainly not fixed, SWF exposes all the gory details of the underlying Win32 implementation to the world.

If you want a decent cross platform GUI system, use GTK# - entirely unicode, cross platform, containment based layout, sane language bindings etc. If you actually care about having nice GUIs on a webpage (though most webpages look and feel waaaay nicer than your average GUI to me) then you want to use a decent widget toolkit to do it.

MH

# re: Don't try to re-invent the browser, please.@ Sunday, June 29, 2003 11:07 PM

Tell me, why should the underlying implementation of a given method be the same on mono as on .net / win32, i.e.: using win32 functions? If a class 'button' mimics a button, no-one should care how that class does that, be it calling into GTK+ or win32 or other widget lib, the bottom line is that it should behave like a button.

The problems arise when .NET code starts to use HWND related functionality to create 'nice' effects, like vs.net style menus, or a treeview control which does more things than it currently can do.

However, 100% .net code should be runnable on a mono winforms implementation which simply implements the functionality using a native library like GTK.

Frans Bouma

# re: About code generators / generating code@ Monday, June 30, 2003 6:19 AM

I think an important point that should also be made is that programmers the use code generators should understand the code that is generated.

darren pruitt

# re: About code generators / generating code@ Monday, June 30, 2003 7:10 AM

I hope you mean: "understand the interface and functionality of the code generated". I really do not see why a developer who uses a code generator, should understand the source code generated, since he shouldn't modify that code anyway, only extend it, and then the developer should know the interface and functionality.

if class Foo has a method Bar, and all you should hve to do is call 'Bar', why do you want to know how Bar works? I never check the x86 assembler the JIT creates, nor do I decompile .NET library methods (unless they have unexpected behaviour, as in: it looks like a bug).

Frans Bouma

# re: A quick update on LLBLGen Pro@ Monday, June 30, 2003 4:01 PM

How are you handling nullable types in Pro? In 1.2 you use SQL Types.

nullable types

# re: A quick update on LLBLGen Pro@ Monday, June 30, 2003 10:01 PM

The classes are .NET classes and have .NET types for their properties. You can test when a value was NULL, but the properties exposed have .NET types. When you want to set a value to NULL, you simply specify null or nothing. When a field is nullable it will be ok, otherwise an exception is thrown. WHen you read a NULL value from the database, it gets converted to a default value, like "" for NULLs in string related types. These defaults are user definable in a special class. There is no SqlType nor equivalent used anywhere :)

Frans Bouma

# re: Serious SqlServer security problem: Microsoft's state of denial@ Tuesday, July 01, 2003 5:44 AM

Totally agree Frans, but you can also add the common scenario of hosting (like myself) where you have a firewall between the live server and the databse box.

I setup the two by letting access to nothing except the port to talk to SQL.

So the two cases you talked about are absolutly not working at all in this scenario.

Maybe the light will come from Yukon where apparently SQL will be closer to the Framework model.
BTW, nice stylesheet on your page ;-))

Paschal

# re: Serious SqlServer security problem: Microsoft's state of denial@ Tuesday, July 01, 2003 5:47 AM

Oh I forgot also a case I know well where for some specific reasons too long to explain, the live server can connect either to a SQL box or a MySQL box(on Unix).

Using some DAL to switch easily from one to another, how MS think about trusted connections with an ASP Net username.

No way ;-)

Paschal

# re: Serious SqlServer security problem: Microsoft's state of denial@ Tuesday, July 01, 2003 5:50 AM

The firewall solution is indeed a possible 'fix', but firewalls are not that cheap, plus you already run the box inside a DMZ of a firewall. :) What I really would like to see is the ability to use application trusted connections as they are defined in ADO/Sqlserver. You can then define the trusted connection with an application and be done with it, which is in fact what you want. At the moment it's a chewing-gum and iron wire solution: it will hold but for how long? :)

about the css: thanks :))

Frans Bouma

# re: Serious SqlServer security problem: Microsoft's state of denial@ Tuesday, July 01, 2003 9:15 AM

I have a comment, storing connection string in the compiled form it is "secure" as storing it in text file. The reason is simple if you run a dissembler available with .net framework on this assembly, connection string becomes fully visible. The only solution is encryption.

Michael

# Store Connection Strings in the Registry@ Tuesday, July 01, 2003 2:18 PM

It's possible to store connection strings in the registry, and apply decent DACLs to that. I believe you could also use a local LSA secret if you really wanted to. Writing Secure Code by Michael Howard and David LeBlank has some good info on this. Of course if the web server is 0wn3d that still leaves your SQL box vulnerable, but it certainly raises the bar.

JosephCooney

# re: Serious SqlServer security problem: Microsoft's state of denial@ Tuesday, July 01, 2003 9:08 PM

All the tricks of hiding / protecting the connection string are nice and clever, but they all show how bad the mechanism is. No-one thinks its ok to store your windows credentials in a string somewhere so you can log on; these credentials are stored in a userdatabase and you are granted access. What the text based connection string shows us is that the mechanism is flawed: it should be possible to define which application or which user has access to given objects inside a database, without having to specify a textbased string somewhere with a password.

The integrated security option is in theory a good replacement, in practise it needs some work though.

Btw, Joseph: the idea is neat, but the ASPNET user f.e. is not able to read from the registry... therefor you have to give up some security settings which are applied for you when the .NET runtime is installed by giving ASPNET access to the registry.

Frans Bouma

# re: Serious SqlServer security problem: Microsoft's state of denial@ Wednesday, July 02, 2003 2:43 PM

I can't confirm or deny whether the aspnet user can read the registry by default (it can on my machine, and I don't remember making any special changes), but you can easily configure it so that user CAN read the registry, or change the web.config so that a particular application runs as a different user (which you can give the required permissions to). Also registry access is not an all or nothing permission. Like the file system you can configure the permissions to a high granularity to give the access required. You could also encrypt the connection string (but then the probelm becomes where to store the key), or use DPAPI (which reduces the key management problem). Also if you make all your database access via stored procedures, and only give your SQL User account(s) access to these you can help mitigate the risk if your web server is compromised and your connection string is discovered. Maybe I just don't see the problem for what it is, but it seems to me that there are a number of options available for securing the connection between your SQL server and web server. Here is a useful link re: storing database connection strings securely.

http://msdn.microsoft.com/architecture/application/default.aspx?pull=/library/en-us/dnnetsec/html/SecNetch12.asp?FRAME=true#storingdatabaseconnectionstrings

Also, as I said in my previous comment Michael Howard and David LeBlank's book "Writing Secure Code" is really good for discussing this sort of thing.

JosephCooney

# re: We're a labeled group now!@ Wednesday, July 02, 2003 11:08 PM

:)

It's the religious nature of it all that I find amusing. I have no problem with code generation and the stuff I've read here about generating and regenerating database layers is great. I just don't think that it's going to take over entire application areas like Ian Wij's seems to in his "Writing Code is Stupid" piece. Evolutionary language improvements and tools to handle the mundane areas sure, but gather requirements and build from a requirements model? Nah.

Writing code is hard. Anything that makes it less hard is good; that includes code generators, testing, decent clients, etc, etc. But none of them are a silver bullet.

And I'm sorry but that quote of yours over on James' Avery's blog "People who do not understand that code generation is the future will be the first who will not be able to keep up with the rest who do." made me smile and kinda makes me feel that it's you guys that are the elitists - I'm glad it didn't end "will be the first against the wall when the revolution comes" ;)

And... How does questioning Ian's idea that code gen can replace "the "small army of generally not well skilled developers" that can be found in most organisations and who are "churning out a mass of ill-specified code through a poorly managed process" with some nirvana in which we "capture the requirements of the model" and have a code generator that can "consume the new model and generate appropriate code".
make me anything but a realist?

Keep up the good work, and prove us doubters wrong.

Len Holgate

# re: We're a labeled group now!@ Thursday, July 03, 2003 1:25 AM

Here I come with a lot of comments only to find that Len has already written such a good one! Typical.
:-)

There's no single way, of course. Code gen is great to improve productivity. But we have to understand what to generate (or what has been generated).

Jimmy Nilsson

# re: We're a labeled group now!@ Thursday, July 03, 2003 3:46 AM

This debate is almost an unrealistic as the "paperless society" debate.

What more can be said?

Ebenezer Ikonne

# re: We're a labeled group now!@ Thursday, July 03, 2003 3:53 AM

I absolutely agree with Len. People who think that writing code will go away are crazy. I also think that generating entire applications is rediculous and will never happen. What will happen is that things will continue to be abstracted to higher and higher levels, but at the same time requirements will become more and more complex. So there will always be programmers out there writing code in one form or another.

Eric J. Smith

# re: We're a labeled group now!@ Thursday, July 03, 2003 4:01 AM

Ebenezer Ikonne: what has a paperless office idea to do with generating executable code from models? A paperless office doesn't work because the people IN the office want everything on paper so they print and print and print. If everyone starts using email and not a fax, it might become a reality. But that's another story.

All: What most people seem to think is that code generators should generate sourcecode. NO. They should generate executable instructions. Do not stick with a 'programmer language', because those things are invented for humans. No true code generator should generate plain sourcecode but should generate MSIL or other directly executable instructions.

Programming and developing software have NOTHING to do with programming languages and typing texts in a text-editor. Programming languages and typing texts are related to the implementation of the programming RESULTS. If you pick ANOTHER way of implementing the results of programming, you end up with another method of implementing it, but the end result should be the same: runnable functionality.

Forget 'OO', C#, loops, if then else and other program language related elements. Think in what a program should DO, and image the formulation of those functional elements in readable diagrams which can be drawn easily. Imagine then that those diagrams are fed to a tool which produces an executable. Such a tool can exist (there are already several btw) of hundreds of smaller similar tools. No programming language, no if then else for next switch case while wend, just a model as input and executable code as output.

Diagram quicksort for yourself, not in terms of C or VB, but in terms of plain logic. It's very easy.

Frans Bouma

# re: We're a labeled group now!@ Thursday, July 03, 2003 4:12 AM

"I also think that generating entire applications is rediculous and will never happen. What will happen is that things will continue to be abstracted to higher and higher levels, but at the same time requirements will become more and more complex."
Two mistakes. One is that you can now think it is rediculous that generating a whole application is silly, but perhaps you should use MS Access for a change and build an application with it. 10 to 1 you don't need a single line of code. In the future this will only expand, because if you focus on FUNCTIONALITY and the end result, an executable program (or better: a set of logical components glued together with logic), you'll see that hammering in the code by hand is nothing more than a (often very bad) way of translating the functionality descriptions into a programming language which is transformed into another programming language and so on till executable instructions are produced. Now, the mistake is that you shouldn't follow the same route when you want to generate executable instructions from functional descriptions. You should follow to route which makes it possible in the most elegant, fast way.

The other mistake is that although applications tend to become more complex as a whole, this is not a delimiter for using code generators at all. The reason for this is that if application complexity was a delimiter for a computer, it certainly would for a human. People forget that you can build the most complex applications with the most simple logical building blocks. Once logical elements which contain ready to use functionality are available for generators, you have a layer of elements you can address from within your generator. If you can then generate new logic from your generator with those blocks, you get new blocks, new functionality you can re-use.

Nothing complex at all. Step aside from the programming language paradigm, generators shouldn't think in a language that is ment for humans.

Frans Bouma

# re: We're a labeled group now!@ Thursday, July 03, 2003 4:24 AM

In the late 80's, 4GL was so hot. But the problem all the time was that the last 20% of the apps were actually hindered by the 4GL tools so the total result was often not very good at all. (I know, evolution and development...<g>)

And talking about Access, that gives me several really bad flashbacks from old applications of mine... Brr...

Even so, I guess you have a good point. Just as everybody else writing comments here.
:-)

For now, code generation serves me really well when they spit out code too.
:-)

Best Regards,
Jimmy
###

Jimmy Nilsson

# Eric J. Smith's Weblog@ Thursday, July 03, 2003 4:26 AM

Eric J. Smith's Weblog

TrackBack

# re: We're a labeled group now!@ Thursday, July 03, 2003 5:11 AM

Does code generation add another tool to my arsenal? Most certainly. But will it ever replace the bulk of my work? Absolutely not.

First off, for my job, source code is an absolute must. This is not negotiable. I'm not some entry level grunt, I'm the go-to guy when nobody else around here knows how to accomplish something. Jimmy put it very well. Currently I'm wrestling with SAP.... let's see, can I declare a PARAMETER in my ABAP program and create a simple selection screen? Sure. But when I wish that selection screen to ONLY contain plants which are designated as shipping points for a portion of one division, AND this varies depending on authentication.... 4GL can't cut it.

Another point here. Ever see the monstrosity of code the ABAP table grid wizard gives you? Yeah right. Since this code generator has no clue what things I need to accomplish with this grid it has to create each and every hook possible - leaving me to wade through the various sections of code to whittle it down to something maintainable.

Which brings me to my final point. MS Access? ROFL. Forget about the murderous SQL it automatically creates for queries. Forget about the pain in the butt scalability and truely robust security are. Just look at this: what's the outcome of all this code generating?

Yes, it DOES simplify many things. (I began by saying there is a place for code generating.) But it also has a truely disasterous effect....

Ever try to maintain a website written by some secretary who took a FrontPage course and so now deems themself a website developer? MS Access is like that. These non-technical people tend to know just enough to make themself dangerous. TO me, that is the REAL cost of code generation.

Dave

# re: We're a labeled group now!@ Thursday, July 03, 2003 5:23 AM

Dave: Ah, so current implementations of 'generators' are an argument why it will never work? MS Access was an example, a metaphore.

I developed in a 4GL for 2 years, I know what it is like, and I also know that it is stupid to not use a 4GL or a generator when you are developing an application which is database driven (and... whoa, that's about a hell of a lot of applications)

Your example about frontpage illustrates enough: "These non-technical people tend to know just enough to make themself dangerous. TO me, that is the REAL cost of code generation.". Then you really do not understand what I'm talking about. The attitude illustrated in your remark is what I refered to with 'Elitism'. Programming should be possible for everyone who can think logical and can design software. Today it's only possible for people who know their way in a given IDE/Editor, a language, some API's etc. (in other words: stuff you can look up).

Why should a 'technical' person be necessary to create a webgui? I don't see that. Today it is necessary because of the crappy state of most tools, however in theory it shouldn't be. That's not because the concept of a generator sucks, but because the people who wrote the current crop of generators did not understand what a generator should do or they made it that way so the market would buy it, otherwise it was too far fetched.

Frans Bouma

# re: We're a labeled group now!@ Thursday, July 03, 2003 6:15 AM

That was my point, source code will never go away..just like the fax machine.

But then again time will tell, like it always does.

Ebenezer Ikonne

# re: We're a labeled group now!@ Thursday, July 03, 2003 6:20 AM

Sourcecode will go away, but when is a blur of course. I think the first places where it will be used less and less is in the average business apps which, excuse me, are most of the time structured the same. And then eventually the other parts. I don't see humans hammering code in 2100.

Frans Bouma

# re: We're a labeled group now!@ Thursday, July 03, 2003 1:43 PM

Frans, to be honest that is that first time in 25 years I've ever been accosed of elitism. :-)

Seriously, to be totally objective, code generator - and I already said this - have their place. But they most certainly are not the be all or end all. Exactly what high level concept is so dramatically new here? Nothing. Before .NET OO you had 4GL. Before 4GL you had MS Access. Before MS Access you had 3GL. SO on and so forth.

Truely eliminating the need for people to write programming code will simply never happen. Never.

So what does this mean? It means that the better a code generator becomes, the more dangerous someone who doesn't understand why a code generator works becomes. Right now I have to deal with people who have no clue why they shouldn't just import their 20 column spreadsheet into MS Access. I mean "it works", roght? Normalization? Fergitaboutit.

Can you optimize code generators to (a) make my job as the technical lead on a project easier and (b) eliminate costs of having someone fresh out of college who can't do anything but write simple SQL? Most definitely. But there ain't no free lunch. There are costs. And those costs sometimes pile up on guys like me.

Elitism? No way. Realistic. If code generators - and let's agree right now this concept has existed for decades now - were realistically as great as you claim, then why hasn't one come along now to eliminate my job?

Do I believe my job in it's current capacity will exist in 2100? Nope. But not because of some code generator, rather, something much more simpler.... evolution.

Dave

# re: Serious SqlServer security problem: Microsoft's state of denial@ Thursday, July 03, 2003 3:57 PM

I think discussion missses two important facts:
1. Problem with integrated security is the way challenge/response works, i.e. passing challenge from web server to SQL which is not a domain controller does not work. However, there is a way to pass credentials securily (including *nix boxes, mind you). It's called Kerberos and 2000/2003 servers do support it.
2. In large scale implementation where people are concerned with SQL administrator having access to web server and vice versa, I think the solution would be to move your data access to a separate box and use .NET remoting.
Just my 2c
Georged

George Doubinski

# re: We're a labeled group now!@ Friday, July 04, 2003 4:16 AM

May I ask, what will be used to "create" these code generators. Do you envision a time when there will be a generator for every problem domain that exists?

Ebenezer Ikonne

# re: We're a labeled group now!@ Friday, July 04, 2003 4:24 AM

What is used to create them? Normal programming languages. Like normal programming languages are used to create compiler generators which then generate themselves based in the input of an (E)BNF syntaxis specification.

I don't know when it will be that for every problem domain there will be a generator. If you look at the level of stubborness that is in the developer community at the moment for adapting even dumb generators, I think it will take a long time before the majority of developers is chosing a generator over the option to hammer it all in by hand.

Frans Bouma

# re: XBOX's 4th of july@ Friday, July 04, 2003 5:04 AM

I agree. Hardly a security hole, but an interesting trick. Linux on an Xbox - who'd have thought? :)

Doug Thews

# re: Serious SqlServer security problem: Microsoft's state of denial@ Friday, July 04, 2003 5:15 AM

What you're talking about is something like Passport, where the system (or SQL database) sends you off to a service to authenticate, and you either come back with a valid key to enter, or not.

So, you could develop your own "Give Me My Connection String" web service that handles connection strings per app (if that's the way you do it). You use HTTPS and your app's authentication credentials (which can be compiled as part of the code - they shouldn't need to be changed). Then, get back your connection string.

I agree that this is not integrated and what you're thinking about (because it introduces a 3rd party), but it eliminates the need to store connection strings as strings anywhere on the web server.

Doug Thews

# re: Whoa, 33 today!@ Sunday, July 06, 2003 9:50 PM

Happy birthday Frans !

Francois Verbeeck

# re: Whoa, 33 today!@ Sunday, July 06, 2003 10:35 PM

Congrats!

Damn, I remember when I was the youngest among all I met at work... :-)

Jimmy Nilsson

# re: Whoa, 33 today!@ Sunday, July 06, 2003 11:17 PM

Happy Birthday!

Roy Osherove

# re: Whoa, 33 today!@ Sunday, July 06, 2003 11:38 PM

Thanks all! :)

Frans Bouma

# re: Whoa, 33 today!@ Monday, July 07, 2003 12:09 AM

Happy birthday! Well, I turn 29 today ... but somehow feel like 33 ;-)

Christian Weyer

# re: Whoa, 33 today!@ Monday, July 07, 2003 12:52 AM

Happy Birthday! :)

P.S. Some portion of cake still there? :)

MM

# re: Whoa, 33 today!@ Monday, July 07, 2003 1:44 AM

Happy Birthday.

whoami

# re: Whoa, 33 today!@ Monday, July 07, 2003 1:57 AM

Happy Birthday! You're 5 days after me but much younger-)

Sam Gentile

# re: Whoa, 33 today!@ Monday, July 07, 2003 3:08 AM

Congratulations :)

Zef Hemel

# re: Whoa, 33 today!@ Monday, July 07, 2003 3:30 AM

Just started subscribing to your blog last week. Good stuff. Happy birthday.

Justin Bigelow

# re: Whoa, 33 today!@ Monday, July 07, 2003 7:15 AM

Happy B-day!

Is that cake chocolate? If it is, can I send you my (snail)address?<G>

Chris Frazier

# re: Whoa, 33 today!@ Monday, July 07, 2003 7:23 AM

Thanks again all :)

Oh, and about the cake, of cooouuuurse nothing is left. :D :)

Frans Bouma

# re: Whoa, 33 today!@ Monday, July 07, 2003 9:49 AM

Congrats!

Paul Gielens

# re: Re: Am I the stereotypical VB Programmer?@ Tuesday, July 08, 2003 5:16 AM

Well stated

Greg

# re: Re: Am I the stereotypical VB Programmer?@ Tuesday, July 08, 2003 6:49 AM

Only in terns of VB versus C# is your argument valid. But I say if J#, COBOL and others can write IL that runs against the CLR (and _that_ is the _only_ relevant thing in this discussion when you get down to it) than why not VB too?

So VB is verbose. So VB originally was to be the RAD tool. Since VB4 it has been much more than that. Do I understand the inner workings of the Win32 APIs, COM/IDL? Do I understand the higher level concepts of OO, relational database design, threading and scalability? Sure do - and they are the cornerstone of my career path.

So C++ can do things more easily codable than VB regarding some of those. That never made me wish to wade into it. While not the best language, VB did allow me to develop clean maintainable apps that did all this.

IMHO, MS did the right thing by allowing me to write to the System Class, use ADO.NET and design multi-threaded apps. It all comes down to one thing only.... does a programmer understand how to use all the tools his/her particular language has?

Dave

# re: Re: Am I the stereotypical VB Programmer?@ Tuesday, July 08, 2003 7:33 AM

Frans, Thanks for explaining. Your post was enlightening, and I'll be the first to admit I did not know (or did not think of) much of what you write. All but the part about VB.Net being redundant. I'll go with Dave on that one, but that's a different story :)

Roy Osherove

# re: Re: Am I the stereotypical VB Programmer?@ Tuesday, July 08, 2003 8:14 AM

I agree with you. I'm from the C side of the fence, but I've done some VB programming the last few years. I know some VB developers that felt threatened/afraid of the change from VB to VB.NET, and they were even more afraid of C#. I feel that MS created VB.NET so that they would not lose the large pool of VB (larger than C++) "developers" out there. I don't understand why VB developers are so tied into their language, when I bring up C# they get defensive. On one hand I think that VB developers can create products faster and on the other hand I feel that they are lazy and unmotivated to understand the "why" not just the "how" of software development.

Phil

# heLP .Net Blog@ Tuesday, July 08, 2003 10:24 AM

heLP .Net Blog

TrackBack

# ISerializable@ Tuesday, July 08, 2003 10:24 AM

ISerializable

TrackBack

# re: Re: Am I the stereotypical VB Programmer?@ Tuesday, July 08, 2003 12:03 PM

Now, to be straight about it, I dabble in C# and will continue to. I've never bee afraid to learn new ways or languages. I used to code in both Assembler and Fortran, but love the RAD-ness of VB. But I do know of many VBers who have a very hard time with the .NET 'evolutions'. LOL!

Dave

# re: Re: Am I the stereotypical VB Programmer?@ Tuesday, July 08, 2003 11:21 PM

Nice article, and I can add another reason why i don't like the With statement; because it encourages people to write things like:
With A.B.C.D
myVar = .SomeVarFarAwayThatShouldntBeAccessedDirectly
End With

In fact, that is what i dislike about VB.Net the most, the fact that it enables people to cut corners where they aren't supposed to (i.e. On Error Resume Next)

Peter Vervoorn

# re: Re: Am I the stereotypical VB Programmer?@ Wednesday, July 09, 2003 11:13 PM

Um, I hope it's not too cynical to suggest that a big reason for introducing VB.NET may have been the claimed 3 million VB programmers out there. That's an awful lot of potential upgrade license fees....

Mike Woodhouse

# re: "Framework-Hell"-solution is here: ISV's can upgrade to VS.NET 2003 without pain.@ Thursday, July 10, 2003 6:50 AM

Frans,
What if the problem doesn't occur on the when I run my program on my machine, but when I tranfer the .dll to my website, then I get the problem message?

kreuzmarket@bluebon.net

Leeman Schmidt

# re: LLBLGen v1.21 has been released! (Mostly bugfixes)@ Saturday, July 12, 2003 6:01 AM

Why no enhancements made by gotdotnet'ers? I'm sure where clauses on each field rather then FK's would be much appreciated.

Further, thnx for the ongoing support and fixes! Heads up...

Paul Gielens

# re: LLBLGen v1.21 has been released! (Mostly bugfixes)@ Saturday, July 12, 2003 6:06 AM

The reason is simple: my codebase wasn't in sync with the gotdotnet codebase. I never included Lewis' updates for the where clause on each field because I found that a little too much (consider 50 tables with each 10 fields... ouch :) ).

Frankly, the workspace effort is a bit of a dissapointment, since not a lot has come out of it, but alas, it's freeware written in spare time :)

Frans Bouma

# re: Don't try to re-invent the browser, please.@ Sunday, July 13, 2003 10:20 AM

Here, here, Frans. I posted on this topic today (see link), and I mostly agree, but I think there is a real syngery possible (God I hate that word, but it actually applies) combining the browser chrome and HTML/CSS with the CLR. If standalone forms would have been enough, Java would have won long ago, but HTML has a decided advantage in layout flexibility (and widget beauty, but I'll stay away from that). HTML forms and toolbars and really suck, but so does Java and WinForms when you need to design a long form with hierarchal datagrid-like properties. The best solution will be to run both in a seamless browser window (w/ or w/o the browser toolbar, just like pop-up windows now), which will overcome the web issues of limited form widgets, fixed positioning, ugly scripts, and server round-trips without sacrificing the things people *like* about browser interfaces.

Richard Tallent

# re: About code generators / generating code@ Tuesday, July 15, 2003 6:29 AM

I couldn't agree more here: "code generator is the future".

btw, when are you planing to release llblgen Pro. I can't wait for that!
Do you have an estimative month?
Will you give the sourcecode at the same price?

thanks,
Matias

Matias Woloski

# re: About code generators / generating code@ Tuesday, July 15, 2003 6:50 AM

Matias: I hope to be finished with it at the end of august 2003 :)

The system is extensible in a lot of ways: code is generated using templates plus the steps the generator takes are configurable using task definitions in an xml file which bind tasks (f.e. directory creation) to an assembly and class which performs hte task). You can then add whatever you like as custom task, using your own assemblies, f.e. get old sources first from a sourcecontrol system or whatever :). We haven't planned source control release for a price, but perhaps we open up the source of the runtime library for licensees.

Frans Bouma

# re: It's not Visual SourceSafe's v^Hfault@ Wednesday, July 16, 2003 12:52 AM

Good article.
We have a mantra here: The first place you need to install source control is in the developer's mindset.

Duncan

# re: It's not Visual SourceSafe's v^Hfault@ Wednesday, July 16, 2003 5:08 AM

That is a very interesting read...

For me, one of the most disappointing things about SourceSafe is that while the IDE was improved so much between VS6 and VS7, and SourceSafe was barely touched.

The last two (fairly large) projects I've been on have used SourceSafe and I've had similar experiences both times. When the project is in its early stages, SourceSafe works fine. When the project matures, and you start to need more complex functionality from your SCM, it seems that SourceSafe just can't cut it.

I think one of the biggest problems I have with SourceSafe is the lack of promotion groups, (ie. to support work on multiple releases at the same time.) Sure, you can hack something together with sharing and labeling, but its just too messy in my opinion.

As far as I know, MS doesn't use SourceSafe (nor should they for the size of their projects) -- so much for eating your own dog food.

I have not had a chance to check out Vault, but it sounds promising.

ps. If anyone is looking for ideas, I want a SCM that will reject a check-in if they don't compile/pass unit tests. That would be very nice.

Don McNamara

# re: Serious SqlServer security problem: Microsoft's state of denial@ Wednesday, July 16, 2003 5:39 AM

Isn't this where serviced components come in handy? Only the credentials of the COM+ application should be able to connect to the database.

The ASP.NET web application can run with less permissions on the system then the COM+ application.

Ramon Smits

# re: It's not Visual SourceSafe's v^Hfault@ Wednesday, July 16, 2003 6:16 AM

I just finished writing an article that should be appearing in September's issue of Pinnacle's Hardcore Visual Studio.NET on making the most of VSS and I agree that, when used for it's intended purpose, VSS works well. It does have some drawbacks not mentioned here.

1. It uses pretty outdated technology. (ex. INI configuration files when it could use something like XML)

2. It's performance over VPN and remote connections in general really sucks. I wouldn't tell anyone to use it over VPN...it slows to a crawl most of the time. If you ARE going to use it over VPN, disable some features you probably won't use like Shadow Folders, Journal Files, and Project Access Rights. The most important feature to enable for VPN users however isn't even configurable from the VSS client. You have to edit the srcsafe.ini file and set CP_OnSelection to False. Normally whenever you click on a folder (a project or project grouping level) VSS performs a selection operation, which can take a while over a slow remote connection. By setting CP_OnSelection to no, users can drill down in the project hierarchy and just double-click or hit Enter when they find the folder they want to actually select, not having to wait a while for each level they expand.

3. It's integration with IDE's is less than reliable. How many times have you got the "Failed to reload project" message or checked out a file only to be told you couldn't edit it seconds later? Stuff like that bothers developers and I'm guessing it would only take someone at MS a week or so at the most to fix.

4. The way it performs "diff" checking is just slow. Vault really spanks the pants off of VSS in this situation. Vault's use of delta's is much more efficient. Also, use of some sort of data compression technology would be nice to help speed things up.

Like you've touched on - I think most people use VSS withouth really knowing the tool that well at all which isn't VSS's v-Hfault at all. I've talked to some of the VSS team at MS and like Don said, a good share of people at Microsoft don't use VSS. They use a command-line tool called "Source Depot" which I believe is a variant of CVS. I still use VSS for some things but have tried Vault and just find it easier to work with as a SCM. Why Microsoft hasn't tried to buy SourceGear yet or at least offer their SourceOffSite product for free with VSS makes me wonder how much MS really cares about what people think of VSS.

Ok, I'm done ranting.

Jason Mauss

# Darrell Norton's Blog@ Wednesday, July 16, 2003 6:33 AM

Darrell Norton's Blog

TrackBack

# re: It's not Visual SourceSafe's v^Hfault@ Wednesday, July 16, 2003 9:21 AM

Sorry Frans, but VSS is crap. The single most important thing that a SCC system MUST do is keep source code (and all past revisions) safe. VSS's very architecture precludes this. It is a client that writes directly to a proprietary database with non-atomic commits. If a client fails in the middle of a commit, you are almost assured database corruption. I've seen it several times over the course of several years. If you only work with the 'head' revision, you are unlikely to notice, but it becomes apparent when you work with past file revisions.

It also has very poor branching and merging capabilities, both of which are important as your product matures.

You also tak about lock vs concurrent editing. Your locking model fails in a number of use-cases:

1. Disconnected editing. This is the largest area where a locking type SCC model fails. File locking does not work well in a disconnected mode, while concurrent models (Such as Perforce, CVS, Subversion, etc) work very well. Indeed, with VS.NET and VSS, it attempts to imitate a concurrent versioning system in the disconnected mode.

2. Highly contested, frequently changed files. Depending on the toolset or project, some files are 'volatile', and must change frequently, are shared accross projects or libraries, and must be changed by more than one user. A locking model does not work well here, as this will act as a block against other users performing work. The suggestion that you delegate work is often impracticle, as there is often one person who is best qualified to perform a specific type of change.

3. The suggestion that user A tells user B what changes to make is yet another form of merge, although verbal instead of toolset based. Why not let the technology handle the merge? That's what concurrent editing was designed for.

As far as scheduling work and shared resources to avoid locking problems, you may be sacrificing development speed for diminished lock contention.

I could write several thousand words on why VSS is a poor solution, but I think I'll leave it at that for now.

Jerry Dennany

# re: Get rid of the 'file' concept for sourcecode!@ Friday, July 18, 2003 10:37 AM

How would you script the builds on a machine without the IDE? Would the "elements" be pulled out of the repository to recreate the local "files"?

Robert Hurlbut

# re: Get rid of the 'file' concept for sourcecode!@ Friday, July 18, 2003 10:39 AM

No, the tools are not working on the filesystem but with code elements retrieved from the repository, f.e. by calling the repository webservice. The concept of 'file' is not used when building the software.

Frans Bouma

# re: Get rid of the 'file' concept for sourcecode!@ Friday, July 18, 2003 11:00 AM

Nice idea that would probably work well in some situations but I'm not sure how practical it would be for web applications.

andy

# re: Get rid of the 'file' concept for sourcecode!@ Friday, July 18, 2003 12:25 PM

I would have thought we'd have moved to the document repository scheme by now. I was hoping that was what's now SharePoint was going to give us.

Doug Thews

# re: Get rid of the 'file' concept for sourcecode!@ Friday, July 18, 2003 1:58 PM

SharePoint Portal Server can serve as a document repository; however, were you thinking of document == source file, Doug ?

Nino Benvenuti

# re: Get rid of the 'file' concept for sourcecode!@ Friday, July 18, 2003 2:39 PM

Have a look at some of the interactive source and intentional programming stuff at http://aisto.com/roeder/paper.

Pete

# Roland Weigelt@ Friday, July 18, 2003 3:53 PM

Roland Weigelt

TrackBack

# CVSNT will have SQL Server support soon@ Sunday, July 20, 2003 6:52 AM

I stopped using VSS a long, long time ago, not only because it corrupted my files one too many times, but because it supports file locking and CVS's free tools like TortoiseCVS and ViewCVS are much, much better. Does VSS have shared locks now? If VSS still exclusively locks files by default via VS.NET, it doesn't matter.

Money and time spent on VSS and Vault is a waste.

http://www.cvsnt.org

Tom

# And Intelligently Understood Names@ Sunday, July 20, 2003 4:33 PM

When you change a function name in "refactor" mode, all uses of that function name should then change to the new function name. That is, when a function is called, it's automatically converted into a function# by the system, and just referred to by string name for the user.

Lion Kimbro

# re: Get rid of the 'file' concept for sourcecode!@ Sunday, July 20, 2003 10:16 PM

A lot of Smalltalk implementations already work in this way - you save an image of the project, and work, class view like, with programming elements through the IDE. There is no notion of a file. I have not seen and source control systems for Smalltalk though that allow you to track back through changes to elements in the image.

Ian Cooper

# That's nothing new@ Sunday, July 20, 2003 10:28 PM

There are IDEs that work this way. Check out the Smalltalk environments, e.g. IBM VisualAge for Smalltalk or even VisualAge for Java. Working in such an Environment indeed provides many benefits when searching or following references. It's nice. I worked several years with VisualAge for Java and found it very comfortable. Much better than what JBuilder or Netbeans had to offer 5 years ago. Very sad that VA couldn't keep up with the JDK updates ( it was a closed environment hardwired to a specific JDK version). Because of that we had to move on to inferior IDEs.

Stefan Haubold

# re: Get rid of the 'file' concept for sourcecode!@ Sunday, July 20, 2003 10:33 PM

Very good feedback! I didn't know it was already common knowledge in the smalltalk world, I never used smalltalk myself...

Knowing that smalltalk IDE's have had this feature for years already, makes it even more weird why current IDE's for other languages still use the file concept.

Frans Bouma

# re: Get rid of the 'file' concept for sourcecode!@ Monday, July 21, 2003 3:15 AM

The file concept remains because so many of our existing tools assume it. To switch, you have to provide the world with a *complete* toolset that works as well as the set we've got now.

Oh, and before that, you have to somehow create widespread dissatisfaction with the status quo.

Eric Sink

# re: Get rid of the 'file' concept for sourcecode!@ Monday, July 21, 2003 3:22 AM

Eric: the current concept of a 'file' is already a view of sectors on a harddisk. With the plugin system of the filesystem stack you can create a FS driver for the repository if you truly want backwards compatibility.

It's true that if it ain't broke, don't fix it is written all over it, but I also think that when a major IDE vendor (like MS) introduces it, plus with all the benefits that come with the concept, I think there will be a market for this. But it's a long road, admitted.

I wonder though how MS will set up WinFS in longhorn: after all it's a database which provides views ('files') of the objects inside the database, which can (IMHO) be compatible with the concept of the code element of my blog.

Frans Bouma

# re: CLS Compliance testing is useless@ Monday, July 21, 2003 6:53 AM

unsigned integers are NOT CLS compliant. The C# compiler is correct.

"Most of the members defined by types in the .NET Framework class library are CLS-compliant. However, some types in the class library have one or more members that are not CLS-compliant. These members enable support for language features that are not in the CLS. The types and members that are not CLS-compliant are identified as such in the reference documentation, and in all cases a CLS-compliant alternative is available. For more information about the types in the .NET Framework class library, see the .NET Framework Reference."

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconwhatiscommonlanguagespecification.asp

Jesse Ezell

# re: CLS Compliance testing is useless@ Monday, July 21, 2003 7:01 AM

Well, the UInt32 structure exposes an uint member. All fine, but why isn't an Int64 used internally and externally?

When you have these kind of types in your core library, you define more than 1 library and not one: the CLS compliant one and the non-CLS compliant one.

It's also bogus testing. You test for type compliance, but what does that mean? Several types in the .NET library expose overloaded operators. These are PART OF the type. However, not usable in f.e. VB.NET.

Frans Bouma

# re: CLS Compliance testing is useless@ Monday, July 21, 2003 7:15 AM

It is fine to have non-cls compliant members, you just need to make sure that everything can be accomplished without them, just in case a language does not support one of your method signatures.

IMO, VB does to much in the background and doesn't give enough control over this type of stuff. I would be wary of using it for such projects. Apparently, the MS guys didn't think VB should be used for creating CLS compliant programs either, or they would have supported the CLS compliant attribute... So, moral of the story, use C# if you are working projects where you are concerned about Types. VB.NET is very loose with them (I guess some people do actually consider that a "feature," but I'm not one of them :-) ).

Jesse Ezell

# re: CLS Compliance testing is useless@ Monday, July 21, 2003 7:23 AM

'a' language... I think that definition is too vague. 'a MS language' is better. After all, if I define a new language for .NET, and it doesn't support 64bit integers, it can't use a lot of code since Int64 is CLS compliant but not according to my new language. :)

So, VB.NET apparently forced this uint != CLS Compliance crap to exist. How thoughtful.

Frans Bouma

# re: CLS Compliance testing is useless@ Monday, July 21, 2003 7:32 AM

Jesse,

To be clear, yes, you can use non-CLS types in your application. However, if you want to be CLS compliant, you can't publically expose any of those types.

Patrick Steele

# re: CLS Compliance testing is useless@ Monday, July 21, 2003 7:34 AM

Then your language isn't CLS compliant :-). However, just because it didn't have a "long int" or some language specific version of int 64 doesn't mean it wouldn't work. It should be able to use Int64 directly if it supports even the most basic type stuff from the CLI.

Jesse Ezell

# re: CLS Compliance testing is useless@ Monday, July 21, 2003 7:34 AM

Frans,

VB.NET really can't use unsigned ints. Sure, you can define vars of type UInt32, but once you try and do any operations with them (adds, substracts, even assignement) VB.NET complains because it doesn't know how to convert 'ints' to 'uints'.

Patrick Steele

# re: CLS Compliance testing is useless@ Monday, July 21, 2003 7:38 AM

Patrick, as long as you have CLS compliant ways to do everything, it doesn't matter much whether the rest is fully compliant (IMO). CLS compliance is a good test to make sure you won't run into any hairy situations, but I don't see any reason to force yourself to ONLY use CLS specific stuff if you run into a situtation where it makes sense to do otherwise.

Jesse Ezell

# re: CLS Compliance testing is useless@ Monday, July 21, 2003 7:43 AM

Jesse, I think we're in agreement on this stuff.

I think CLS-compliance really only needs to be achieved by component/tool authors. If you're just coding an internal application or something simple for yourself, who cares about CLS-compliance? It's only an issue if you want to make a library or utility that will want to integrate with another .NET language.

Patrick Steele

# re: Get rid of the 'file' concept for sourcecode!@ Monday, July 21, 2003 12:02 PM

I've used VisualAge for Java, got to say, it really sucks when you actually want to get at the files - web applications are the most obvious example. It becomes very tricky when you have to work with lots of files - like images, stylesheets etc...

Scott Galloway

# re: The Blob!@ Tuesday, July 22, 2003 8:49 AM

Hahahaha...

I wasn't drinking, but why didn't you say I had to print this out and read it on the toilet? No I've shitted my pants from laughing!!! :)

Dennis v/d Stelt

# re: Get rid of the 'file' concept for sourcecode!@ Tuesday, July 22, 2003 9:04 AM

When using Eclipse with Java, mostly you are dealing with projects, packages, classes, interfaces not folders and source files.

Yiyi

# re: Re: Am I the stereotypical VB Programmer?@ Wednesday, July 23, 2003 9:51 PM

<<an editor that helps you more than any other editor on the planet and with a compiler that is faster than any C or C++ compiler out there>>

I think you are talking about Delphi.

<<tortured for years with C, Pascal>>
when was the last time he tried Delphi. It is still the best dev tool for win32.

I am new to this blog but a long time programmer in vb that switched to delphi 3 or so years ago.
VB.net is just included to keep the .net learning curve down for the beginner Vb programmers . i am sure anyone with some real experiance will move to C# ,after all it was written by the same guy that wrote Delphi and is the best thing (along with the framework) that microsoft have done for years. c# is going to be huge.

Nice Guy Eddie

# re: So Microsoft, when is VS.NET 2002's service pack released?@ Wednesday, July 23, 2003 10:53 PM

What more do you REALLY need to see that MS is committed to their customers? Geez man. You sure do complain about MS a lot. Ever hear the phrase "biting the hand that feeds you?"

You could get a lot more done with MS if you had a more positive attitude. They're still figuring some of this stuff out, just like we are.

Robert McLaws

# re: So Microsoft, when is VS.NET 2002's service pack released?@ Wednesday, July 23, 2003 10:58 PM

What's wrong with critizism? I'm not biting the hand that feeds me. If I can't ask Microsoft why there isn't an SP for VS.NET 2002 released, the world really is in trouble.

Frans Bouma

# re: To Entity.Save() or not to Entity.Save()?@ Thursday, July 24, 2003 1:21 AM

YOu are right.

More crreclty. Jimmy is wrong.

He should have handled both forms with different transactions, diferent objects, different caches etc. Then he never would get the problem, and both things could be commited separatly.

Thomas Tomiczek

# re: To Entity.Save() or not to Entity.Save()?@ Thursday, July 24, 2003 1:24 AM

The problem with one cache per appDomain still exists though if you use separate caches. (or to be more precise: when a cache is used, it will fall apart when multiple appdomains are accessing the same shared repository)

Frans Bouma

# re: So Microsoft, when is VS.NET 2002's service pack released?@ Thursday, July 24, 2003 2:33 AM

Hey Robert, since when is being critic bad???
Do you eat everything your holy "hand that feeds you" decides to give you?

Fabrice

# re: So Microsoft, when is VS.NET 2002's service pack released?@ Thursday, July 24, 2003 2:44 AM

Frans,

Can you go into a little more detail about what you don't like about VS 2003? We are about to make the switch...

Thanks
Don

Don McNamara

# re: So Microsoft, when is VS.NET 2002's service pack released?@ Thursday, July 24, 2003 3:25 AM

Don: if you're developing in VB.NET, I'd recommend you read Greg Robinson's blog and his blogs about vs.net 2003 and VB.NET.

In C# (which I use) I have problems with intellisense and the debugger. The debugger is sometimes failing to show membervariables but shows empty rows. Debugging is then useless. This happens to me 2 a 3 times a week. I have to restart the machine and even then it is kind of random.

I discovered that I don't use the features that come with vs.net 2003 that often. The intellisense 'prefered entry' feature isn't always useful and the stubbers of interface code is useless, simply because it doesn't copy the comments you specify with the interface declaration.

Frans Bouma

# re: So Microsoft, when is VS.NET 2002's service pack released?@ Thursday, July 24, 2003 3:33 AM

Microsoft's support for current customers of the .NET Framework 1.0 and VS.NET 2002 is a complete load of *crap*!

First off, they don't even acknowledge a fraction of the bugs that are in the products. The only thing coming out of Redmond, as always, is upgrade! upgrade! upgrade! That will fix all your woes. Yeah, right. Give me a break M$.

Let me tell you something Microsoft. I'm a consultant who works for major companies who adopt .NET technologies. It's *amazing* in a lot of these shops that they adopted .NET in the first place. Those who have, for the most part, have adopted version 1.0 (and if I'm lucky, SP2 for the framework).

Most don't have any interest at all upgrading to the next version of VS.NET simply because they want to take the "wait and see" approach. You know, M$, the same one they want to take with your operating systems (and that's why Win2k and NT4 is so widely used, despite the all the new features of XP and Win2k3).

If we could get a fricking service pack with *real* fixes in it (what the hell was SP1 for the framework about, anyway? what a waste), then at least I could work hard to convince the management types to keep up-to-date with the latest fixes (usually because they do it out of habit to fix all the bugs in your other products).

If this is the way M$ intends to be, than I for one (and I know a lot of other developers feel this way), think it's a load of crap. C'mon M$ -- support your existing products and don't force people to upgrade to get the latest bug fixes.

M$, you've come a long way from what you used to be, but I'm afraid you're taking a step back with the (lack of) support you are giving your customers.

Load of crap

# re: So Microsoft, when is VS.NET 2002's service pack released?@ Sunday, July 27, 2003 10:56 AM

Robert,

Ever heard of the prase:
'Customer is king' ?

We don't get fed by Microsoft. MS is just one of the firms that deliver IDE's for .NET (Borland is another one).
If you want to use a good product, then critizism is a way to get things done.

If you buy a new car, wich has some production faults, but in a new edition, or a new version of that type of car, these glitches are fixed, what do you expect? You expect that they will fix your car. You don't expect that the manufacturer says: "Oh, we fixed that in our new version, if you want it fixed, buy the new version of that model".

whoami

# re: Don't try to re-invent the browser, please.@ Monday, July 28, 2003 1:30 AM

All pretty windows centric. I cannot see that the imitation of one particular proprietary form tool (that is what mono is intended to be) shall be the bright future. I rather see this as an argument for independant open source form languages. XUL could be it.

Another question is, how comes that it is often easy to convince use to use the so restricted browser GUI. Concepts like collecting favourites and sending links via e-mail to someone else would all needed to be reinvented by a GUI of the future.

Frank Nestel

# Getting rid of the 'File' Concept for Source Code?@ Tuesday, July 29, 2003 2:58 AM

TrackBack

# VSIP Corroboration@ Tuesday, July 29, 2003 7:11 PM

TrackBack

# Hear hear!@ Thursday, July 31, 2003 8:40 AM

Very much agreed. The (language)discussion is going loud around here these days. This is a point I'll definately use in the office wars:)

Mads Nissen

# re: Why Edit & Continue is a bad thing@ Thursday, July 31, 2003 9:07 AM

Completely disagree. If I'm testing my application and an exception fires because, say I'd used the wrong type of slash in XPath, then I want to fix it, then carry on. This results in a quick, trivial change, rather than the 30-40 seconds required to stop the debugger, let VS.Net rearrange all it's docked windows, make the change, fire up the debugger. Navigate through the application to the same spot the exception fired so that I can carry on testing from where I left off.

I would agree that pure logic should not be built on the fly - it should take a more formal approach, but stupid coding mistakes need to be squashed rapidly while testing your code.

Unit Testing (as in xUnit) doesn't help in most of these situations if the coding error was part of the presentation layer.

I've written parsers, web apps, win apps in C# all with NUnit during the last 3 years and regularly wish I had E&C.

RichB

# Why Edit and continue is a GOOD thing@ Thursday, July 31, 2003 9:25 AM

TrackBack

# re: Re: Am I the stereotypical VB Programmer?@ Thursday, July 31, 2003 3:26 PM

With is a bad construct because it discourages developers from refactoring their code. If the type expression the With statement refers to contains one or more periods, then the developer should really be thinking about pushing the With-block into the object that it operates on.

In other words, the method with the With-block has too much intimate knowledge of the other classes specified in the With statement type expression.

Having said that, I believe that refactoring should not be a prime concern for any VB developer - I believe that VB should become a much more RAD language used as very rapid glue code for components provided by other vendors. And because of this, I believe that With does indeed have a place in the VB arsenal.

BTW - I was a VB-dev before VB had the With statement...

RichB

# re: Why Edit & Continue is a bad thing@ Thursday, July 31, 2003 5:23 PM

Hehe VB crap... debug, change your program, serious hang, terminate the app and IDE shuts down as well.

BOOM, al changes are lost... what the hell did I just do?

Welcome in the world of crappy programming pratices. Please MS leave Edit & Continue out of C#. Disfunctional coding pratices should have their own disfunctional language (VB), let it not be C#.

My 2c

Paul Gielens

# re: Why Edit & Continue is a bad thing@ Thursday, July 31, 2003 6:20 PM

Blame the languages for good and bad all you want, but it still all depends on the person behind the keyboard! ;)

HumanCompiler

# Frans Bouma's says Edit and Continue is a bad thing@ Thursday, July 31, 2003 9:21 PM

TrackBack

# re: A pattern in patterned confusion.@ Friday, August 01, 2003 7:17 AM

I completely agree Frans. In fact, one of the requirements for being a design pattern is that it *must* be used by more than one group of people. You simply can't invent something new yourself and call it a pattern unless it's something other people have come up with as well.

Thong Nguyen

# More on the badness of E@ Friday, August 01, 2003 7:29 AM

TrackBack

# re: More on the badness of E&C and how to debug software.@ Friday, August 01, 2003 11:40 AM

Very good points and reasons for NOT using Edit and Continue. This is exactly what unit testing has helped us get away from.

Robert Hurlbut

# re: Why Edit & Continue is a bad thing@ Friday, August 01, 2003 2:09 PM

If you think it's bad, don't use it. But put it in there for the people who like it. I want freedom, not constraints imposed on me from the Best Practices Police.

Charlie Zimmerman

# re: Why Edit & Continue is a bad thing@ Friday, August 01, 2003 3:40 PM

I am kind of amazed at the negative reaction that people are showing for EnC. I don't understand it. How does fixing a stupid bug while debugging and without recompiling encourage bad programming practice? That kind of thing happens to everyone no matter how much forethought you put into your design.

Tosh Meston

# re: Why Edit & Continue is a bad thing@ Friday, August 01, 2003 3:42 PM

Tosh: read my other article about debugging I posted today. You'll understand why.

Frans Bouma

# re: More on the badness of E&C and how to debug software.@ Friday, August 01, 2003 7:44 PM

Frans, nice stuff!

My favourite "Plain old stupidity bug" used to be forgetting this line:

objRs.MoveNext()

:-)

Darren Neimke

# re: More on the badness of E&C and how to debug software.@ Friday, August 01, 2003 11:03 PM

This argument misses the main reason I use edit and continue. I'm an old Scheme programmer, and I just use it like a REPL. When I'm using systems that don't yet have any documentation and are just an API and a pile of messy source, it's an easy way to new up some objects, play around with them, and see how they work.

Edit and continue isn't just about bug fixing; for me, it's also about exploration.

But then, maybe I'm just an old Scheme programmer and don't know any better :-)

LarsBerg

# re: More on the badness of E&C and how to debug software.@ Saturday, August 02, 2003 11:36 AM

see:

http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3237275853

for my response

James Robertson

# re: More on the badness of E&C and how to debug software.@ Saturday, August 02, 2003 1:23 PM

Come on. What is edit and continue but an automation of the stop, edit and recompile under the covers. I like automation and abstraction, it saves me time. That's why I like code generators. And if you think about it, the same arguments could be applied to code genrators, so there is a bit of a contridiction here. E&C is just another tool to be used at the appropriate times. If you want to stop bad programming habbits in programmers that don't know what that appropriate time is, well then we need to attack some other features of the IDE as well. This spills over into a much bigger philisopical debate over associating ones value as a programmer with the tool that one uses - as in the statment "I am a VB programmer", or "I use code generators". If a language/IDE combination such as VB encourages the use of wizards, code generators, automation tricks, and other 'crutches' to progam without understanding what the end result is, it will get a bad reputation among more diciplined programmers that use another tool (in this case c#). Try on this statment for size "I program in notepad". What does that say? It is language agnostic - notice I didn't mention any language. It could be VB, C# or assembly. So lets assume I am programming VB in notepad. The edit, compile and debug process would be even more painful, requiring me to be even more diciplined. Why in the hell would I want to do that when I could use the IDE? Just for some macho bragging rights?

Doug King

# re: More on the badness of E&C and how to debug software.@ Sunday, August 03, 2003 5:55 AM

Doug: E&C isn't a tool you use for 'testing'. There you go wrong. If you miscoded a statement (used + instead of - f.e.) and you see that in the debugger, you fix that in the code and move on. Do you NEED the debugger to verify that the '-' you just inserted at the spot of the '+' is the correct operator? If you do, you do not understand what code SHOULD be there at that spot. That's the point. If you need E&C to verify if that fix (the '-') is correct, you are using trial and error to code you through an algorithm. That's the point I was trying to make: if you KNOW what you are doing, you can develop software WITHOUT a debugger, because you know which statements should be on which spots in which routines.

Consider this: do you think Windows kernel developers use E&C to fix bugs? Debugging OS kernels is hard (using 2 machines/virtual machines), left alone use E&C. Still people manage to create solid, working kernels. How do they do that? Solid software design.

It has nothing to do with bragging rights. If someone says he develops software in vi or notepad I'd say he's a fool. However, every developer should KNOW/realize why he is using a given tool. Only THEN the developer can truly unleash the power of that tool, because only then the developer knows WHEN to use the tool.

Frans Bouma

# xL8 - Grant Carpenter@ Sunday, August 03, 2003 10:14 PM

xL8 - Grant Carpenter

TrackBack

# re: So Microsoft, when is VS.NET 2002's service pack released?@ Monday, August 04, 2003 1:14 PM

yeah, im looking for a patch to vs2002 right now, but i guess there isnt one.

I like using MS's tools, but their customer service blows. im really sick and tired of it too. VS.net is full of bugs, but they dont seem to care. it really pisses me off.

how are we supposed to get work done on time when we spend all our time trying to work around the half-assed, piece-of-crap utility known as VS.NET?

shane

# This seems an overreaction@ Monday, August 04, 2003 10:38 PM

It is easy to dismiss the plain stupidity bugs, but when working on a mature product, a large amount of time spent debugging is spent on such bugs. If you add a new method and it gets halfway through a million steps of exiting code (some sort of an engine), it is a heck of a lot easier to fix and continue than to stop and get back to where you were. Granted, that is also a reflection of the tools available, but what if several human interaction steps are required to get to that point. Recreating them over and over to reproduce the situation rather than using Edit&Continue seems extreme.

Having said this, note that I don't have or use E&C in the compiler I have now, but I think the concept is well founded. The implementation is another question, and I do think it is a fair argument to say that there may be better walls for the developers to throw themselves at.

Ben Langhinrichs

# re: Why Edit & Continue is a bad thing@ Tuesday, August 05, 2003 10:24 AM

I've developed with tools that don't have E&C and I can tell you this, having it saved me more time than not having it. Particularly when it takes me 1/2 the time to locate and fix the problem using E&C as opposed to having to categorize and determine the cause of the bug. An application that I work on now is what's called an Allocation Engine. It's sole purpose is to perform extensive calcs against a database to provide Oil & Gas companies with the info they need to determine what was produced and what was sold. It has no user interface and hundreds of functions and objects. It is written in Powerbuilder. When a customer reports a bug to us, it can literally take an entire workday (sometimes more) to figure out where the bug is and what is causing it. In order to assist us in this, we generate trace files and insert message boxes. Powerbuilder has NO Edit and Continue. Under the same scenario, using VB6, it would have taken us roughly 1/2 the time to locate and fix the bug because some of these bugs don't pop up until after thousands of lines of code have executed and several minutes or an hour has gone by. By inserting a breakpoint (which PB does have) near the area where we believe the bug originates. We then begin stepping through the code and "watching" the values. Once we see what's happening, (using E&C) we can easily change that line, step into it, check the result and then continue on with the allocation.

The real beauty here is that "IF" you don't like E&C, then don't use it.

Keith Keller

# re: More on the badness of E&C and how to debug software.@ Tuesday, August 05, 2003 1:29 PM

Do the Windows kernel developers use RAD tools to create the kernel? :)

It's about productivity. When I see a bug, I have the ability to fix it, and continue debugging. There's no way to convince me that I didn't just save the time I spent getting to that place in the application.

Rather than reading through your algorithm in your head, why not let the computer help you? When I'm done writing some code, I spend time in the debugger stepping through it and examining what's going on. If you wrote the code and believe it was correct, chances are that if there IS an error, the "execution engine" in your head isn't going to catch it.

Stepping through the code and examining the state things is more reliable and more effective than trying to do it in your head. And it's when you're doing that that Edit and Continue is most useful.

Steve Tibbett

# re: More on the badness of E&C and how to debug software.@ Tuesday, August 05, 2003 2:46 PM

Like I said in my original comments, there is an appropriate time to use E&C as a proper time saving tool. In your scenario (kernal developers) I agree, use of E&C seems silly. But what about tweaking UI code or prototyping ideas, debugging someone else's code, refactoring, etc. E&C is just another tool that compresses the edit, compile, run-code-in-IDE cycle. If you have no need to do the last step, run-code-in-IDE, then E&C is not apporpriate. If there is a good argument to NEVER run-code-in-IDE, instead do unit tests, etc., then E&C could be seen as encouraging bad practices. I submit that this is the real crux of this debate.

Doug King

# re: We're a labeled group now!@ Friday, August 08, 2003 3:18 PM

Personally, I side with the CG’ers and buy into that vision, though I think it may take many decades--if not centuries--to get “there”. Where is “there”? To me, it is the point where over 90% of all programming is via specification rather than coding.

To those defending the need for a seasoned developer I say that they are 100% correct, but for the wrong reasons. Creating correct specifications for a code generator to generate any non-trivial application will remain a specialized skill for a long-long-time to come. This kind of executable specification becomes just another higher level of programming.

The point is NOT that code generators eliminate programming. Rather, the point of MDA, code generation, and executable-model initiatives is that (1) in the short-term they eliminate a lot of tedium (and errors) in writing with our current crop of relatively low-level programming languages (Java, C#, VB, XSLT, PL/SQL -- T-SQL, ABAP, etc.) and (2) in the longer-range vision, allow for developers to remain at a higher level of abstraction--much closer to the actual problem domain--rather than constantly dealing with the particulars of the implementation platform.

Will we always need lower-level systems programmers? Into the foreseeable future, yes, probably. However, our profession has already evolved from designing circuits and flipping switches (ENIAC), to bit twiddling in machine language (punch-cards anyone?), to assembly languages, to lower level procedural languages such as C and Forth, to OO such as C++, Java, and C# and now the massive frameworks/environments supporting business apps (J2EE App Servers/.Net). It seems only reasonable to observe that the bulk of programming will continue to evolve to higher-and-higher levels of abstraction as the tools and the basic building blocks become more refined.

Naim Ru

# re: We're a labeled group now!@ Friday, August 08, 2003 3:33 PM

One more point: remember that if you program in anything other than raw machine language, you are already using a code-generator -- the compiler or VM!

The "code generation crowd" is simply adding another layer of compilation/interpretation on top of the multiple layers which already exist. There is no reason for me to believe that this layering needs to stop at the current state-of-the-art.

Naim Ru

# Internet Explorer.NET@ Sunday, August 10, 2003 6:58 AM

In my recent articles I've explored the concept of the Universal Canvas, a term made popular by Microsoft when it launched .NET in 2000.

TrackBack

# re: Sorry for the lack of updates...@ Monday, August 11, 2003 3:02 PM

Thanks for the pointer Frans and good luck with your 'crunch-mode'! As you know, I'm very much behind with my blogging too. I have at least two blog posts that you have commented very well and which I have to write about again. In a week or two...
:-)

Best Regards,
Jimmy
###

Jimmy Nilsson

# re: Sorry for the lack of updates...@ Monday, August 11, 2003 4:47 PM

Thanks for the support, Jimmy! :) I hope the painting of the house is progressing as planned :)

Frans Bouma

# re: Sorry for the lack of updates...@ Monday, August 11, 2003 5:41 PM

Perhaps not progressing as planned, but at least progressing enough.

Ah, I found another area for applying Agile/XP. "What is the smallest amount of painting that would possibly work?"
:-)

Jimmy Nilsson

# re: Sorry for the lack of updates...@ Thursday, August 14, 2003 12:19 PM

Frans will this be a public beta?

Have you decided on a pricing structure yet?

Cheers

free4all

# re: Sorry for the lack of updates...@ Thursday, August 14, 2003 12:21 PM

The beta won't be public, but a select group of people will beta-test the betaversion. The estimated 'street' price is 170EUR excl. VAT. for a site/department license, thus 4 developers? 1 price :), and the runtime license is of course free.

Frans Bouma

# re: Stop ranting about the blaster worm@ Friday, August 15, 2003 4:52 AM

Well, +1 for you here, Frans.

I received a lot of e-mails the last few days from different Microsoft channels, providing some very useful information on the whole Blaster thing. And yes, it made me wonder why, in spite of the early availability of patches, the worm could do so much damage over the last few days.

So, I totally agree with this entry from you.

Admittedly, I always placed you more or less in the anti-Microsoft camp. I guess, that's because some of your first postings in the DOTNET-CLR discussion group of DevelopMentor, which were actually the first words I ever read from you. Back then, if I remember correctly, you'd just started developing for the .NET platform. Those first postings were quite critical and, I still think, far too agressive in their lack of nuances. So, now I'm kind of ashamed for hanging on to that first impression---and I apologize: you seem quite objective to me now.

And when MS screws up, I count on some serious ranting from you towards Redmond: just to illustrate your objectivity. ;)

Stefan Holdermans

# re: Stop ranting about the blaster worm@ Friday, August 15, 2003 4:59 AM

I started developing with .NET in march 2002 :P But I agree, sometimes ranting can be counterproductive when you want to make impressions, however even rants do get heard. I'm not in the anti-microsoft camp, however due to .NET I left the pro-microsoft camp which was a thing I never thought possible :)

It will be all right, when whidbey will be released.

I also think MS should have done more to protect users. I mean: WHY isn't there a free add-on for windows 2000 which simply acts as a firewall like in XP? They have the code already there, it's in XP, why do I have to buy an expensive firewall for windows 2000? Just to block some ports. That's the kind of thinking that's still not there in Redmond. It will be there, but not at the moment or at least too less :) Ah well.. nothing's perfect :)

Frans Bouma

# re: Sorry for the lack of updates...@ Friday, August 15, 2003 5:16 AM

I like the price Frans, I was hoping I wouldn't be priced out of the market and this sounds more than generous. I have looked at other products from thona and co but the cost is astronomical. For a small coding shop with an even smaller budget this is ideal.

Once the "select" group has finished beta testing will there be a try before you buy?

free4all

# re: Sorry for the lack of updates...@ Friday, August 15, 2003 5:25 AM

:) Yes there will be a 'demo' version available, so you can try it out. The competition costs a fortune especially when you are with 2 or more developers and they can't live up the price the ask.

Frans Bouma

# re: Sorry for the lack of updates...@ Friday, August 15, 2003 5:58 AM

Champion I have a project waiting to go but I'm holding out so I can try your software. I'm hoping this is a cure for all my DB headaches. Can't wait to try it out!

free4all@dootdoot.co.uk

# re: Sorry for the lack of updates...@ Friday, August 15, 2003 6:30 AM

I hope it won't dissapoint you :) If I won't make the sept 1 date, I'll mail you and you can get started with a preview version.

Frans Bouma

# Blaster worm blogging: whose fault is it?@ Friday, August 15, 2003 9:14 AM

TrackBack

# re: Sorry for the lack of updates...@ Friday, August 15, 2003 9:31 AM

Thanks Frans that would be great. I'm sure you'll not disappoint if your previous work is anything to go by!

free4all@dootdoot.co.uk

# re: Stop ranting about the blaster worm@ Friday, August 15, 2003 10:34 AM

"If you as a sysadmin did your job well" If MS did their job well, this would not have even been an issue in the first place. Do it right the first time, or not at all.

Travis

# re: Stop ranting about the blaster worm@ Friday, August 15, 2003 11:52 AM

"who needs a sysadmin with perfect software"

I'm sure a lot of sysadmins would resent that.

Without MS making the stupid and dangerous decision to have things like RPC enabled by default, sysadmins could concentrate on more important things like, well, administering the system.

Joe Grossberg

# no firewall in windows 2000?@ Monday, August 18, 2003 7:49 AM

Actually, Windows 2000 does have a free firewall. How to configure it can be read at http://support.microsoft.com/?id=309798

Stefan Mensink

# re: Sorry for the lack of updates...@ Wednesday, August 20, 2003 2:28 PM

I'm sort of in the same boat. I have a project that I would love to use llblgen pro on. If there's still room in your public beta, let me know! ;-)

bonder@digitalarcana.com

Bruce Onder

# re: Sorry for the lack of updates...@ Wednesday, August 20, 2003 2:35 PM

Bruce: it's a private beta, not a public beta, sorry :) At the moment the beta testing is going well, no need for extra hands, but thanks for the offer. :)

Frans Bouma

# re: Sorry for the lack of updates...@ Wednesday, August 20, 2003 3:37 PM

Oops, I meant to write "Private" not "public." :) Oh well! Do you imagine the beta taking much longer than two months or so?

Bruce Onder

# re: Sorry for the lack of updates...@ Wednesday, August 20, 2003 3:43 PM

Bruce: Naah we're currently very close to release candidate quality actually :) Most big bugs are ironed out in the last couple of days. What's left is documentation and the glitches that pop up in the next couple of days. :)

Frans Bouma

# re: Sorry for the lack of updates...@ Thursday, August 21, 2003 1:37 AM

Hi Frans,
I'm planning to buy it, but what do you mean with runtime license free?
You can develop and use it for free? only if you publish it on a webserver, you've got to pay?

Stijn Gysemans

# re: Sorry for the lack of updates...@ Thursday, August 21, 2003 2:28 AM

Stijn: You have to pay for a license to use the tool, and the tool generates code which targets the runtime library that comes with the tool (a set of base classes). Some competitors also ask a fee for usage of the runtime, I don't. If you have payed for a license, you can generate as much applications as you want and you don't have to pay for a runtime license.

Frans Bouma

# re: 'nGen' is NOT related to LLBLGen or me@ Thursday, August 21, 2003 5:41 AM

ventilate my experiences with this 'competitor'

I'll proof them wrong within a few weeks time

Goosebumps all over the place... good luck during the crunching period. Sounds exciting!

Paul Gielens

# re: 'nGen' is NOT related to LLBLGen or me@ Thursday, August 21, 2003 5:42 AM

Thanks Paul! :)

Frans Bouma

# re: 'nGen' is NOT related to LLBLGen or me@ Thursday, August 21, 2003 8:33 AM

Kinda odd to call such a tool just like a tool already included in .NET...

Zef Hemel

# re: 'nGen' is NOT related to LLBLGen or me@ Thursday, August 21, 2003 9:11 AM

Kick some a**, Frans! BTW, how much is LLBLGen pro (or 2.0) gonna cost? I gotta start greasing the wheels around here.

Darrell

# re: 'nGen' is NOT related to LLBLGen or me@ Thursday, August 21, 2003 9:34 AM

Darrell: 170 EURO excl. VAT for a site/department license, so one license per team. :)

Frans Bouma

# re: 'nGen' is NOT related to LLBLGen or me@ Thursday, August 21, 2003 10:45 AM

Frans, I know my team is excited about LLBLGen Pro. We hope to see it soon.

Emmet

# re: 'nGen' is NOT related to LLBLGen or me@ Thursday, August 21, 2003 7:19 PM

Like Zef I can't belieive someone would give something the same name as a tool already in the .NET framework. Maybe I should make a webcontrol called ILDASM or something.

JosephCooney

# re: 'nGen' is NOT related to LLBLGen or me@ Saturday, August 23, 2003 8:35 PM

Am I missing something here? how does the name ngen in any way resemble LLBLGen

Steve Johnson

# More on SQL Server Auto-Updates@ Sunday, August 24, 2003 11:35 AM

TrackBack

# Small Query Blog@ Monday, August 25, 2003 6:50 AM

Small Query Blog

TrackBack

# re: LLBLGen Pro release date set@ Tuesday, August 26, 2003 9:58 AM

Yee haw! :)

Bruce Onder

# re: LLBLGen Pro release date set@ Monday, September 01, 2003 10:55 AM

So, it's the 1:st.. Where is it?! ;)

Can't Wait

# re: LLBLGen Pro release date set@ Monday, September 01, 2003 10:58 AM

On my harddisk :) It will be later this week, probably friday. Stay tuned. We're in release candidate 2 now, pretty close to the final product. :)

Frans Bouma

# re: LLBLGen Pro release date set@ Tuesday, September 02, 2003 8:31 AM

I'm just curious about the remoting support that will be available for the LLBLGen Pro. Will the generated classes be accessible by remotable functions and methods?

Wondering

# re: Get rid of the 'file' concept for sourcecode!@ Thursday, September 04, 2003 8:39 AM

.NET gives everything we need for something better: System.CodeDom. We simply have to build an IDE that will handle the object graph directly instead of relying on those damn flat files.

Jérôme Tremblay

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Sunday, September 07, 2003 4:55 PM

Congratulations!

Stefan Holdermans

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Sunday, September 07, 2003 5:12 PM

Thanks! :)

Frans Bouma

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Sunday, September 07, 2003 5:44 PM

Just downloaded the demo :)

After executing the prog for the first time I get:
SetupMainGui::Could not load the file: 'guistate.xml' to de-serialize the previous window state back. Reason: this is the first time you run this application or you have manually deleted this file. LLBLGen Pro will use the default window state and window positions.
SetupMainGui::Complete exception: Could not find file "C:\Program Files\Solutions Design\LLBLGen Pro Demo\guistate.xml".

Kris

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Sunday, September 07, 2003 5:45 PM

Pushed the button too fast.

Just wanted to say that the eagle has landed.

Kris

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Sunday, September 07, 2003 5:50 PM

That's normal behaviour, Kris :) It informs you that it couldn't load the file, and created a new one for you :)

have fun with the demo :)

Frans Bouma

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Sunday, September 07, 2003 7:13 PM

Congradulations Frans!

LLBLGen has been great for many projects and now LLBLGen Pro looks great as well! You have been an asset to all of us. Your hard work and dedication is appreciated.

Now, I have some studying to do :)

Kim (Kman)

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Monday, September 08, 2003 3:12 AM

Thanks Frans! I've been waiting patiently for LLBLGen Pro, thanks for keeping the price reasonable. You have a surefire winner on your hands.

senkwe

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Monday, September 08, 2003 4:05 AM

Well, congratulations! As soon as I start to develop in .NET; i'll start to use it ;)

Nielsz

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Monday, September 08, 2003 4:16 AM

Heh Nielsz :) And you'll never know when that will be. PHP isn't everything you know ;)

Frans Bouma

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Monday, September 08, 2003 12:03 PM

Congratulations Frans! Been playing with the demo all day and have to say I'm impressed. Just waiting for confirmation from the boss now so I can buy the full version.

free4all@dootdoot.co.uk

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Monday, September 08, 2003 2:10 PM

Impressive, so easy to use and most helpful documentation.

Just a quick question... what about inheriting the generated entity classes? What are you thoughts about inheritance within the generated framework?

btw nice implementation regarding lazy loading and COM+!

Paul Gielens

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Monday, September 08, 2003 2:26 PM

thanks Paul!

Check out the two class scenario generator configurations, these will generate 2 classes (using different templates) per entity: one with the core logic (*EntityBase) and one for your code (*Entity). When you update your project, you just re-generate the base classes and keep the inherited classes. :)

Frans Bouma

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Monday, September 08, 2003 3:12 PM

Please add a demo aspx sample that uses the demo Northwind classes. Any product that forces me to read too much docs before I can have a good feeling about it will get me to lose interest pretty quick. Put a grid that does delete, insert, edit so that in 5 minutes, I can see results and know how the product works.

I am sure others are impatient like me :)
llgl open source is a good product. Congrats.

Abdu

Abdu

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Monday, September 08, 2003 3:27 PM

Abdu: I know :) a sample app will be up in a few days with a grid, some transactions etc. All the code snippets in the docs are from a test app that will be transformed in this example btw, so you can get started pretty quick, but an example app is definitely planned, however I ran out of time to write that before the deadline. However I'll add one in the next few days.

Frans Bouma

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Tuesday, September 09, 2003 5:45 AM

Congratulations Frans! If I ever get to developing using .NET I'll keep your tool in mind ;-)

Stefan Mensink

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Tuesday, September 09, 2003 5:53 PM

I use LLBLGen all the time and am anxious to try this out (hopefully within the next 2 weeks). If it is as awesome as I am assuming, I will definitely be purchasing this puppy!

Thanks!

Jason Bunting

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Tuesday, September 09, 2003 10:35 PM

How will you make money selling it so cheaply? I would think that support alone would kill you.

Billy

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Wednesday, September 10, 2003 3:16 AM

Billy: I don't have to pay a large amount of developers: I wrote the complete tool myself, we funded the development ourselves, and therefore we can offer the tool for a reasonable price and still make money. :)

Jason: I'm sure it won't be a dissapointment :)

Frans Bouma

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Wednesday, September 10, 2003 10:59 AM

I am looking forward for the sample. Please let us know here. Thanks!

Abdu

Abdu

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Wednesday, September 10, 2003 11:03 AM

Abdu: okidoki :) I'll update the blog as soon as it is ready. Currently the datagrids do not co-operate as I intented ;) so it will take another day or so to get it polished :)

Frans Bouma

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Thursday, September 11, 2003 12:08 PM

Frans,

I'm so excited about this application, but I'm having a hard time putting it to work. I have to do a quick 1-page site to demonstrate some problem with a proxy server, so I figured it would be a perfect time to play around with the demo version while I'm waiting for my boss to buy the full version for us (which we are definitely doing, btw).

I'm trying to create a Class Library, following the directions in your help file, and the thing won't compile. I swear I'm not a complete idiot about these sorts of things, but here's what happens:
--Create new Library project in VS.NET (2002). Called it cNorthwind
--Generate code. General Config/VB.NET
--Copy all code into new project folder. Select and include all folders/files in VS.NET, so they're part of the project. Add the references that you specify. (SQLServer, ORMSupportClasses, System.EnterpriseSErvices)
--Try to compile. Boom.

The problem is that all the errors are due to missing classes that are trying to be imported, i.e. "Imports SD.NorthwindDAL.FactoryClasses", etc.

It's the classic chicken-or-egg problem... The classes won't compile if they can't reference other classes that need to be compiled, which themselves won't compile because yadda yadda yadda.

I'm sorry if I sound like a complete idiot on this, but I was able to make the last (free) version work.
:-P

Matt

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Thursday, September 11, 2003 12:15 PM

Matt: It's a faq, it's a thing with VB.NET: if you define a namespace that is different from teh name of the vs.net project, visual studio (or the vb.net compiler) will prefix each namespace name defined with the name of the vb.net project. Here's the faq on the customers area, I'll also add this one to the general faq on the site. If this doesn't help, mail me directly. :)
---
When I compile the VB.NET code I generated with LLBLGen Pro, I get all kinds of errors about missing namespaces, what's wrong?

You have specified a different name as root namespace than the name of your Visual Studio.NET VB.NET project. When this is the case, Visual Studio.NET will prefix each namespace with the VS.NET project name. See the note in the LLBLGen Pro documentation: Using the designer / Generating Code, at the bottom.
----

Frans Bouma

# re: inheritence@ Sunday, September 14, 2003 3:41 PM

Nice tool!

Does it support inheritence (with multiple tables)? for example:
Article (table Article)
ArticleExtended (table ArticleExtended, 1-1 link to table Article)

The ArticleExtended class should also be returned as Article.

Regards,

Marco

Marco

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Sunday, September 14, 2003 3:52 PM

Not at the moment no. The reason for this is that inheritence is not a concept that is definable in a relational model. If you have a 1:1 relation between two tables, you can also merge them to one table in theory.

We decided we should stay close to the relational theory and have created a tool that is based on the theory that is also the base of the E/R model, the base of every relational database schema, in other words: a relational model should be definable with solely DDL. Inheritence is then almost impossible to define (you need values in columns to distinguish classes in the hierarchy). We can always extend it in the (near) future.

It does generate mappings for all relations automatically, so if you have an extended article, Article.Extended for example will give you the extended info in your schema, it will traverse the 1:1 relation for you.

Frans Bouma

# re: Get rid of the 'file' concept for sourcecode!@ Monday, September 15, 2003 8:49 AM

Being a smalltalk developer, I found your comment amusing :)

I've been developing with these new age features for more than 10 years. As far as I'm concerned, Visual Studio, Intellij, Eclipse, etc. They are all a major leap backwards for me.

The ability to write code anywhere in the "IDE", select it, run it, test it, debug it, reload it, modify it, without having to stop/restart is incredibly productive.

I can't understand why more people are ignorant to smalltalk.

Take my advice. Take it for a test run. Get over the syntax hurdle and embrace the past.

James

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Monday, September 15, 2003 6:21 PM

Very Nice!

Frans,
Could you explain a little how the Dynamic Query Engine works? Are you simply building a string and sending it as the text of a Command object - or is there more to it?

TIA,

DM

DM

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Tuesday, September 16, 2003 2:44 PM

DM: It builds a string with the SQL, using the filters, relations and fields it receives. It also builds a list of parameters to pass on to the command object for the values specified as values for the query. So the SQL is build using a stringbuilder, the values are passed in parameters :)

Frans Bouma

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Wednesday, September 17, 2003 12:11 PM

Excellent tool, Frans
I'll bet your wife is as happy it is finished as we are :-)

Just to keep nagging you with the same questions over and over again: I regularly develop websites for non profit orgs (in my spare time) that can't afford SQL server like my regular customers. Is there any chance you'll develop a MySql driver, using the excellent ByteFX driver for instance (http://sourceforge.net/projects/mysqlnet/)? -and if yes, is there some kind of a roadmap for future database support developments-

Dirk Devriendt

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Wednesday, September 17, 2003 1:13 PM

Dirk: she is :)

Currently, Oracle driver is in development, DB2 driver is halted for now, since IBM hasn't released a solid .NET driver yet. Further databases which will get support after Oracle are: Firebird/Interbase, Postgresql (both have a driver by Carlos, which works ok) and if I can get it running, MySql 4.x. Because an important part of a schema is the set of foreign keys, it is necessary that MySql supports that. I heared that newer versions do so, so it shouldn't be a problem. However I think that with the planned support of Firebird and Postgresql you won't need MySql :)

Frans Bouma

# re: Useless programming language constructs@ Friday, September 19, 2003 8:50 AM

This is a case where you wouldn't use a break after every case if statements 1 and 2 have the same output.

for(int i = 0; i < 10; i++)
{
switch(i)
{
case 1:
case 2:
case 7:
Console.WriteLine("Hello {0}!", i);
break;
}
}
Console.Read();

Jeff Julian

# re: Useless programming language constructs@ Friday, September 19, 2003 8:51 AM

But you also have to remember that there are more options than just break (as well as the ability to specify multiple cases:

int i = 3;
switch(i)
{
case 1:
Console.WriteLine("ONE");
break;
case 2:
Console.WriteLine("TWO");
break;
case 3:
Console.WriteLine("Three alone");
goto case 4;
case 4:
case 5:
Console.WriteLine("3,4,or 5");
break;

}

Scott Watermasysk

# re: Useless programming language constructs@ Friday, September 19, 2003 8:59 AM

Multiple cases are indeed without 'break' but they share the same code block, I was refering to case statements which do have a separate code block and thus have to have a break statement too

The necessity to specify goto is the sign that the limitation of 'not having fall through' is wrong. If they just remove that limitation, it would be much better: you should specify break when you do not want fall through (and you already do so now) and you don't have to mess with goto crap when you want fall through.

Frans Bouma

# re: Useless programming language constructs@ Friday, September 19, 2003 9:03 AM

You're not 100% correct on the second issue (WithEvents in VB.NET). When you said:

"when you leave out the 'WithEvents', you can't define an event-handler."

That's not totally correct. You can define an event-handler, you just can't automatically wire it up with the "handles" statement. Instead, you must use the AddHandler statement.

So your choices are:

private withevents x as Button
and
public sub eventhandler(...) Handles x.Click

-- OR --

private x as Button
AddHandler x.Click, AddressOf eventhandler

Patrick Steele

# re: Useless programming language constructs@ Friday, September 19, 2003 9:06 AM

Ah, thanks Patrick :) I should have said 'can't define an event handler with visual studio.net'.

Frans Bouma

# re: Useless programming language constructs@ Friday, September 19, 2003 9:47 AM

I atcually think the ReadOnly/WriteOnly thing for properties is a Good Thing. It lets the compiler tell you "You wrote a property with just a Get or just a Set. Are you really sure you want to do that, or did you just forget?"

Dave Rothgery

# Useless language constructs@ Friday, September 19, 2003 2:48 PM

Why things the way they are.

TrackBack

# re: Useless programming language constructs@ Friday, September 19, 2003 5:07 PM

One reason you have to eplixitly specify a break in c# is because _a lot_ subtle coding errors in C and C++ come from the fact that you forget to say "break". This way you have to clearly state your intentions.

Fredrik Tonn

# re: Useless programming language constructs@ Saturday, September 20, 2003 7:03 AM

The mandatory overrides is IMHO good. Imagine you subclass a class and define new virtual method on it. Vendor of the subclassed class would eventually distribute new version, which has this method defined too. Than the compiler would scream, that you're trying to define new virtual method (virtual keyword) when you maybe want to do override.
This way you know, that you're doing something, that you're maybe not supposed to do (new vs. override keyword)

Jakub Skopal

# re: Useless programming language constructs@ Saturday, September 20, 2003 8:06 AM

Jakub: it's not the overrides, it's the overLOADS which is bogus. :) Overrides automatically implicitely says there is another method THUS it also overloads.

Frans Bouma

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Sunday, September 21, 2003 7:53 PM

I'm impressed; bought the Pro version and got my existing framework working in no time with the generated code (I already used a similar setup, that however cost me a LOT of codewriting). Thanks a lot for a great tool!
MySql is just very widespread as a free database solution for cheap hosting solutions. The ByteFX driver I mentioned very closely follows the standard MS driver signature, so if you can build your catalog and map the datatypes, The runtimelibraries should be rather painless. It 's far superior to other non-GNU drivers, even when it's still in beta (since they're adding a PostgreSQL driver as well)

Dirk Devriendt

# re: Serious ASP.NET Editor flaw lives on in VS.NET 2003@ Sunday, September 21, 2003 9:57 PM

This bug was making me very upset and I could not understand why it was still happening, even though I had turned off all auto-formatting options in VS.NET. I just found out that is a well-known bug.

Not only the editor is having this irritating "I-will-do-it-for-you” behavior, but also the final "smart" formatting that is applied is (usually) completely messed up. A child programmer would have done better.

A workaround that I have been using, whenever the editor messes up the HTML code, is to copy and paste the HTML code to an blank XML file, apply the XML auto-formatting (with line breaks) and copy it back to the HTML. The XML auto-formatting feature is much more intelligent and neat than the HTML one and, usually, complies with my HTML indentation style.
I hope the hint helps someone else.

Marcos

Marcos Nowosad

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Monday, September 22, 2003 11:57 PM

LLBLGen Pro is GREAT! I just bought it and installer it and like Dirk was able to replace my Deklarit framework pretty easily.

Now if I only knew how to pronounce the name so I could sing its praises to the world! :)

--Bruce

Bruce Onder

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Tuesday, September 23, 2003 3:36 AM

Great feedback, Guys! :)

Frans Bouma

# re: Stop ranting about the blaster worm@ Wednesday, September 24, 2003 9:11 AM

>If MS did their job well, this would not have even been an issue in the first place.
>Do it right the first time, or not at all.

If you could start by copy-pasting other people's quotes correctly...
And Frans is talking about those coders, haven't you just read these next few lines as well or are just just plain st*@(*d?

Dennis v/d Stelt

# I don't understand the longhorn-hype@ Monday, September 29, 2003 5:29 AM

TrackBack

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 6:37 AM

Agreed!

I guess the reasoning behind this is they consider that the current versions work well enough. And they want to avoid touching it because changes may be break them in unpredictable ways.
Microsoft prefers to start a new beta program with a lot of bug to fix than introduce more bugs in a deployed release.

Fabrice

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 6:55 AM

Alot of it, I think, is that we just simply get used to the foibles and work around them. I have one major shell complaint: when you have a large number of files in a folder,say 500-3000, not only does the shell load way too slowly(especially if they are pictures), but if you switch from Tile to List, the list view doesn't paint properly and you end up with 2 or 3 files in each column off the screen. The result of this is that I automatically hit refresh after changing the view type, because I know I'm going to have to.

Another large part is, does anyone ever complain about such things? Has it occured to anyone to email microsoft to complain about where the taskbar properties shows up? Until reading this post I hadn't even considered an issue with it, it was simply "there", and I would automatically move my mouse there, To be perfectly honest, changing it now would confuse me more than it would help, I'm far too set into that pattern. I agree it is a little bit of a strange behaviour, but it is cleanly set into my mind now.

Another piece is maybe, just maybe, most people like things the way they are in situation A, or no one can agree on what behaviour situation B should exhibit, so they do something and let it be. In any system you work with, you are going to find things that you don't like, its just a fact of life. It applies to computers, cars, tv's(takes 3 buttons to set the sleep timer, I think it should only be one), microwaves(I have to press a cook button before I can put in the time to cook. why? Its a damn microwave, I obviously usually use it to cook.), and lawnmowers(one pull ignition takes 3-5 pulls). If you move on to Linux, MacOSX, FreeBSD, whatever, I'm sure you will find things you don't like about that system too. And I'd be willing to bet that some of the things you don't like the primary developers will not change because they or a majority do, or because its minor enough that its pretty far down the list. Sure, in some of them you can go down and change it yourself, but if you have time to hack into and recompile your system code everytime you think something should be different, then I'm jealous of the amount of time you have.

Now, I agree that Microsoft does a bad job on fixes. Having to contact product support services to get a QFE to something is really silly in my opinon. Especially since half the time you don't even know a patch exists until someone tells you on the newsgroups. A granular, automated, system wide update tool is needed. By this point it should be beyond easy to be well aware of every patch Microsoft has available for windows, office, or any other microsoft software, which patches you have installed, etc.

The open source community has the luxury of releasing bug fixes every step down the line, of course, they can also release 80 minor versions a year, or even nightly builds. It is simultaenously an advantage and disadvantage. While its easy to keep your products up to date with bug fixes, etc, it is impossible to ever really be caught up or maintain feature equivilence across the board. I imagine it can make support and training a nightmare, because person 1 has 1.1.1, person 2 1.1.2, person 3 1.1.2.1b, and so on, especially if 1.1.2b adds a menu entry or changes wording slightly.

The open source and small companys have that luxury; Microsoft needs to find a way to provide equivilant fixes and feature upgrades to its users. I just don't see how they can realistically do it. With the level of security scrutiny and testing they are expected to provide, how can they? If they were to make a quick fix for something not vital and it changed something distant, something no one expected(and stuff like that happens, you know that, no matter how rarely), it is a very straight forward fact that the media and the users would roast the company for it. If Redhat did it, no one would give a damn. There is politics in this too. It is unfortunate, but sometimes it is us, the users, that make it impossible for Microsoft to provide us with the services we demand.

If you expect perfection, the only thing you will probably ever get is perfect disappointment.

I dearly hope no one really expects Longhorn, or anything else for that matter, to be perfect, it will not be, it cannot be, nothing ever is.

Daniel O'Connell

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 7:41 AM

I hate to say it (I am not one of those anti everything Microsoft types), but my belief is that this is the result of the dominance Microsoft has in the marketplace. In comparsion to say, the car market where there's lots of competing players around - new cars are released around once a year, if the new model isn't as good as the competition, people simply buy the other model. Both cars essentially offer the same features for around the same price and you could say that they run on the same 'platform' (ok, bad pun...it's a road...). Bugs in cars are extremely costly for the manufacturer both in terms of repair costs and in terms of future sales (would you buy a car who's gas tank explodes? Would you buy another car from the same manufacturer?). Basically if you work in the buisiness world ,you have very limited choice in the software you run, one company in essence controls the roads AND the cars.
Bugs in the products they supply don't really affect future sales - there's no real competition so the spectre of potential lost sales is very minimal - Linux and OpenOffice are not percieved as real alternatives (ask around a normal office - who's even heard of OpenOffice?).
One thing in Microsoft's defence, bugs are in general just annoying (though in terms of Security, they can prove VERY annoying) - they probably won't kill anyone. Also, the products are pretty good (I have WAY more issues with OpenOffice / Star Office than MS Office 2003).
I also don't begin to imagine that Longhorn will be perfect - but I do believe that for the ordinary user it will be WAY ahead of the competition (umm...not counting Macs here...that's a fantastic OS...they just lost the war when it comes to user base)...

Scott Galloway

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 7:57 AM

There could be a few other reasons too.

First, fixing any kind of bug increases revenue by... zero? There simply is no finanacial impetus for MS to spend any more time than absolutely necessary on things like bug-fixing. Unfortunate but true.

Second, however much one may argue MS never truely innovates, one thing they have made a name on is working feverishly to stay ahead of the curve. Focus on the future - oddly enough, the antithesis of "Where do you want to go today?" - and pour money and resources into the next product, the next release.

I've questioned time and again recently a concern that this time they may actually get hurt. Literally hundreds of bloggers are posting delerious items about this year's PDC to the point that some are even begging for donations to attend now. In the meanitme MS is not only foregoing an XP service pack for another 3 quarters, they are not working on any new versions of some of their existing products - including IE. There _are_ competitors out there making good products and supporting them. Products that run _today_ on today's PC. In the meantime MS is focusing on a killer OS that won't see the light of day for at least 2 more years and virtually no machine out there right now could even run it!

Dave

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 8:50 AM

Daniel: good solid piece of writing. Your remark "If you expect perfection, the only thing you will probably ever get is perfect disappointment. " deserves to end up in a lot of signatures :) I agree that perfection can't be achieved easily, however I get the feeling Microsoft isn't even trying: after a release there will be errors and bugs but MS refuses to patch these.

The myth about 'it might break something' is IMHO totally bogus. When a piece of code isn't working as planned, you should make it work as planned. That doesn't have to require interface (code) changes, just reimplementations of current code.

Scott: I agree, however I think Linux will be an alternative for a lot of people within a year. KDE and Gnome are really on track to become solid platforms.

Dave: Exactly. I think it is revenue driven not to patch a lot or better: to spend a lot of resources on customer support. On the other hand, they have enough revenue to get customer support on a higher level and still make money.

Frans Bouma

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 10:24 AM

My shell restarts very infrequently and when it does i always assumed this was because of a 3rd party app hanging the system. I would rather have restart called and have the OS pull out of the nose-dive as opposed to having to give a 3 finger salute and start all over possibly losing work. I never attributed the restart to a known bug in the shell that they refused to fix (maybe im wrong?). As for the other issue of the properties dialog, I cannot reproduce this on my system nor have i ever seen it on anyone elses (even on dual monitor setups). That issue not withstanding, I havent obeserved many other bugs of this nature either.

But besides the fact that i dont agree with the specific issues you raise, the overall sentiment i can agree with.. especially the one about competition. I hope OSS gains more momentum and puts more pressure on MS to start delivering better products at more competitive prices.

Ray Jezek

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 12:40 PM

I agree with your sentiments regarding the lack of bug-fixes.

But regarding your post title "I don't understand the longhorn-hype":

I think you understand the hype very well - people are excited about a new OS, and XP is old news.

Frank Showalter

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 12:50 PM

"I think you understand the hype very well - people are excited about a new OS, and XP is old news."
Well, I understand that the hype is there and what's causing it, and at the same time do not understand why the hype is there, because XP might look old news, it will still be the reality for the next 2 years to come, without a big improvement in sight (perhaps a new moviemaker, oh the joy). People should realize that hyping the next-generation OS is not what we need, we need focus on today's problems with solutions available today, not tomorrow nor next year but today.

Frans Bouma

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 1:23 PM

Amen! I agree 100% with you Frans. This is something I've blogged about before, too:

http://dotnetjunkies.com/weblog/plaudeman/posts/1811.aspx

http://dotnetjunkies.com/weblog/plaudeman/posts/1540.aspx

http://dotnetjunkies.com/weblog/plaudeman/posts/1111.aspx

Keep it coming! The more voices that speak out together give us a greater chance that we'll be heard!

Paul Laudeman

# Frans doesn't understand the Longhorn hype@ Monday, September 29, 2003 2:09 PM

TrackBack

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 4:56 PM

Another thing, after sleeping on it, one of the things I'm looking foward to in longhorn is the hope that some of the major platform issues that cause programs to break (COM plugins, etc) may be resolved as .NET style designs are used....that may still be a dream however

Daniel O'Connell

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 6:47 PM

Let's face it: it was hype that got people to purchase Windows XP in the first place. Windows 2000 had been out for a good 2 years when it was released. The smart consumer would have purchased Windows 2000 back in '99, skipped the incremental Windows XP release and had a solid and financially smart 6 years between OS upgrades. That is unless of course you managed to justify spending $100-$200 on a brand new skin and a new login screen with pictures. People need to start making smarter choices as consumers. You don't complain to car companies when the release a new model each and every year, do you? No, you just don't buy it. Period.

Derek Stone

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 10:51 PM

"You don't complain to car companies when the release a new model each and every year, do you? No, you just don't buy it. Period."

True, but if said car company refused to maintain their products that were over eight years old, I would complain. And, look for another car company.

I beleive that Microsoft has some really innovative products, but that their biggest product, Office, is peaked and invation saturated. How much more can you change a word processor? How many more features can you add? I agree with Fran, if you want to keep the client, fix the bugs.

I see in corporate offices the decision makers are asking why they need to spend more money on technology. How can the CIO justifiy spending more money on a tool they just bought two years ago and probably haven't even fully amortized yet. A goat takes five years to amortize, why should a word processor be any less?

If your not part of or contributing to the bottom line, you are overhead. Overhead is dispensable.

Darren Pruitt

# re: I don't understand the longhorn-hype@ Tuesday, September 30, 2003 7:30 AM

Now Darren, I believe I must disagree. A year ago I'd stand alongside your comment about Office and new features and changing word processors. But have you checked out those exact things in Office 2003? InfoPath and native XML come to mind immediately.

Granted, at this moment those two things are completely meaningless to 'consumers', but given a year or two of developers creating their part and, well, I find Office 2003 to be the first version with significant improvements since Office 97.

Oddly enough, MS in many ways did get it right with Office 2003. First off, the new features I just mentioned are very good reason to purchase it - reasons that didn't exist for Office 98 through XP. I realize this also means MS gets the increased revenue too, but then again... during the development/beta cycles for 2003 they also released a slew of SRs too. Something they don't seem to be doing for Windows XP.

Dave

# re: I don't understand the longhorn-hype@ Tuesday, September 30, 2003 9:09 AM

1995
====
Bob: Boss! There's a great new Office product to go with that new OS!

Boss: Great! Email!?! This will help productivity! Get it for every one!

1997
====
Bob: Boss, there's a new Office product out, it fixes a lot of bugs!

Boss: Great! Bugs are bad! You computer guys sure are helping out the company!

2000
====
Bob: Boss, there's a new Office product out, it is Y2K compliant.

Boss: Well, this is getting a bit expensive but corporate did just make it the standard. Make sure everyone gets a new Anti-virus too, someone out doesn't Love Me.

2002
====
Bob: Boss, there's a new Office product!

Boss: No.

Bob: It has increased security!

Boss: No.

Bob: It looks cool!

Boss: No.

Bob: There's someone fromt eh BSA at the front desk.

Boss: What! Ok, we can upgrade, but we have to lay off half the IT staff. We can outsource the help desk.

2003
====
Bob: Boss! There's a new Office product!

When will it end?

Darren Pruitt

# re: I don't understand the longhorn-hype@ Tuesday, September 30, 2003 9:26 AM

Dave: XML functionality is part of open office since a long time. It's nothing new. Besides that, the point is: when I start word, I want to type some texts, save it, print it whatever, but I want the tool to HELP me with the processing of the words. Now, with Word XP I still have errors in headers, bullet lists, table crap etc. No offence, but Word XP is the 2002 version, why are these simple bugs still bugging me in the year 2002, in version 11 (!) of a wordprocessor ? And! why aren't these fixed but is a NEW version released for 400$ which seems to fix these bugs (I hope)? The functionality I want/need is already in word 2000, even in word 98. I just want it to work OK, without bugs. So instead of bringing out new releases for money which have new features, it would be great if the current version is bug free. Now, when that happens, no-one will upgrade, true, but when MS is following this path of 'Flaws == revenue', more and more people will understand that f.e. Open Office is as good as MS office, if not better and costs less (0$).

For MS, they have to realize that they're at the end of the line for office: there will be less reasons to buy new versions, because people get annoyed or alternatives are as good and cost less.

For me, I'll never go back to MS Office again, because the alternatives are IMHO of better quality and cost nothing. I'm willing to pay for quality, don't get me wrong, but I also judge on quality: if the tool is not worth the money, I won't buy it. MS office is IMHO a huge pile of badly maintained software, with a lot of weirdness that is not addressed in whatever version you purchase. (Word never had a good table editor, and it will surprise me if the 2003 table editor is of the quality of open office).

So, MS should focus more on quality to KEEP existing customers: make the customer feel that they are appreciated, serve these customers with frequent updates so the customer is helped. This will cost revenue, but if they are not doing this, they will lose customers to competitors who have a better product and it takes a huge pile of effort and money to get customers back.

Frans Bouma

# re: I don't understand the longhorn-hype@ Tuesday, September 30, 2003 11:04 AM

Derek-the difference with car companies is that they can be forced to recall vehicles to fix problems that are wide spread-at no cost to customer. They also have the warrenty itself to cover the vehicle. There are guidlines for safety set forth by the government that they must adhere to. Would you except it if your model's A/C system failed and the dealership said wait for the '04 model it should be fixed in those-for 16,000 dollars? Microsoft has no accountability-that's the problem. Mercedes-benz had a slew of issues in the last few years with the managment of all the new electronic systems and they were forced to buy back all the e-class models that were having issues. Oes microsoft buy back copies of office-no.

ethan estes

# re: I don't understand the longhorn-hype@ Tuesday, September 30, 2003 4:55 PM

Frans, sure XML functionality has been part of 'open office' or even MS Office (in case you meant StarOffice or whatever). But _native_ XML storage of Excel spreadsheets? XSL formatting? You might as well say do your webpage development in Word and use the utterly useless "Save as HTML" feature for comparison.

I never meant to say that Office was bug-free, onl.y to say that MS never stopped publishing coherent bugfixes while developing a new version. Which is something that they are with Longhorn.

Derrick, please note I did not say Office 2003 offered _immediate_ paybacks to the 'consumer'. Only that the development features I mentioned will in time be used by the consumers in ways that will IMHO make it considered the next 'true' version since Office 97, when Outlook became an official part of the product.

Dave

# re: I don't understand the longhorn-hype@ Wednesday, October 01, 2003 4:17 AM

I have to say the XML features of Office 2003 are of great value to me. Even if open office can handle xml, not a single one of my customers uses open office. Not to mention I don't really want to maintain two code bases to handle MS Word and OO Writer interop\document generation(assuming feature parity...I imagine most of the features exist in both), same goes for Excel, etc.
At one time, during a budget crunch, I suggested using OpenOffice to a local small company to save money. The owner asked me three questions which pretty much killed the subject: 1) How much would it cost to re-write everything to work with the new suite(they use 3 apps that interact with word and\or excel) and several smart tags, 2) how likely is it that they could find, say, a new secretary that was trained and able to use it immediatly, 3) how much was it going to cost to switch back if people lost interest in OpenOffice and stopped working on it.
After sitting down and thinking about it, buying office for the new pc's was _MUCH_ cheaper. Add onto that I was never able to verify if OpenOffice could handle smart tags, which they wanted(really cuts back on the work, as they interface with the customer, employee, etc database), and the decision for OpenOffice died on the floor, MS office was just cheaper and more productive.

Point is, $0 price tag doesn't always make things cheaper.

Daniel O'Connell

# re: I don't understand the longhorn-hype@ Thursday, October 02, 2003 12:07 PM

- If you look at the reliability of Windows starting from 3.1 to 2003, the OS has been improved alot and with many new productivity features. MS could have improved 3.1 for 13 years and give us a rock solid Windows 3.1 but MS is in the business of making money and companies would have moved to Novell, Unix or Mac if Windows 3.1 stayed with its current features. MS needs to fix its security and the updates feature. I read just today that MS admits that its security update strategy is flawed and will patch it using a new method.

I like MS products and they have increased my productivity as a user and as a developer many times. My only gripe is that every new version demands more computer resources. However I don't mind upgrading my computer every 2 years. Need to do this anyhow for games too :)

If there's anything you don't like about an MS product, you need to let them know. If enough people complain, they will notice and hopefully do something. It doesn't them any good if you complain quitely.

Every product I use has annoyances and you learn to live with them or use something else. For example, my inlaws' Blazer's cupholder is the most idiotic one. It doesn't have enough depth to hold a tall cup and has no grip. I have to take easy turns to avoid spilling the cup. Can I call this a design bug?
My alarm clock off button is in an obscure place. I have to be 60% awake to find it and turn it off. Time to buy a new one. .. and so many other annoyances.

Abdu

Abdu

# Can ASPNET read the registry or not?@ Thursday, October 02, 2003 3:34 PM

TrackBack

# re: Why Edit & Continue is a bad thing@ Sunday, October 05, 2003 1:12 PM

As a VB6 programmer by trade, I prefer C# as a language ; Whenever I try VB.NET, I start to unconsciously use VB6 syntax. And since I'm still working on active bodies of VB6 code all the time, I don't really need VB.NET syntax cluttering up my head and taking over.

But I really miss Edit & Continue when I write C# code ; particularly because I'm still learning C# and the .NET class libraries. While a lot of things will be caught by the compilers, and I agree that test-driven development is the way forward, E&C really helps you learn.

I came to software development with zero professional experience from the medical profession : I was pretty much thrown staight in at the deep end and had to learn VB6 in a matter of weeks (on the redoubtable foundation of BBC and Spectrum BASICs). E&C was a great help ; when you've put a couple of parameters round the wrong way because of inexperience, it's a great boon to be able to shift the run pointer back a line and swap them round.

The other thing I miss with .NET is the ability to execute code in the immediate window without being in break mode ; the VB6 immediate window has many uses, from looking up character codes without having to trudge through the help, performing large calculations that you don't trust the default calculator with, etc.

Convenience features don't make you less of a "man". And you don't always have the luxury of well-structured code with decent testing frameworks ; very often, you're working with code that others wrote, and of questionable quality. My time maintaining our huge, ancient VB3 app has made me very, very glad of E&C.

Dr_Barnowl

# re: I don't understand the longhorn-hype@ Monday, October 06, 2003 8:20 PM

Explorer loads lots of 3.party DLLs in its process space. In fact it can host IE, Thumbnailviewers (e.g. thumbnails of .eml-files) and lots of extensions to the menus of files.

I wonder whether such a thing can ever be stable!

But you can just replace the explorer.exe-shell with cmd.exe or Cygwin Bash if you want. Or progman.exe (in XP). Just do it!

Me

# re: Eric Sink's crabbyness@ Saturday, October 11, 2003 8:21 AM

Yep, this post is really funny and worth reading ;-)

Christophe Lauer

# re: Eric Sink's crabbyness@ Saturday, October 11, 2003 8:56 AM

Not only is a good writer but he has a terrific sense of humor as well - http://notalegend.com/notalegend.html

SBC

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Tuesday, October 14, 2003 11:38 AM

I hope you're working on the examples. It has been over a month since my request and I've heard nothing.

Abdu

Abdu

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Tuesday, October 14, 2003 12:01 PM

Abdu, erm...
http://www.llblgen.com/pages/demo.aspx

the current example (VB.NET or C#). It's released on the 19th, updated on the 30th.

The blog is also updated with this. :)

Frans Bouma

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Wednesday, October 15, 2003 3:50 PM

Ok thanks. I wasn't aware of the update.

Abdu

Abdu

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Wednesday, October 15, 2003 3:54 PM

No problem :)

Frans Bouma

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 7:17 AM

Interesting read. I never thought about .NET from this point of view.

Although you are probably right about .NET the lack of support for vendors other then MS, but I would think it’s fair to say “WE” could fill in the gaps ourselves with a strong open-source initiative.

Paul Gielens

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 7:18 AM

Is Scott McNealy blackmailing you? :)

But seriously, I agree with most of your points, although I think stuff like MVCC and synonyms will probably reach Yukon.

I'm not sure about the rest though. Also, I must admit I've never used UDTs, but I agree that for large-scale db applications, they're probably extremely important. Also, they tie in well with the whole schema approach, that basically encourages (or rather forces, but in a good way :)) to just make a single environment housing all your data and then creating schemas for individual applications. If you use UDTs there it can save you a lot of time if you create those custom types with generalized functionality in mind for all the different applications that might have a table in their schema containing one of those UDTs. In SQLServer people often don't bother because they'll have another database for "that other" application anyway. Which in turn encourages long-term chaos.

Jeroen

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 7:31 AM

Jeroen: Larry didn't need to, he just gave away a free version of Oracle 9i for developers to download :)

You are very correct about the UDTs and the chaos and the simplicity of maintenance. It really worries me why I haven't read anything about them in the Yukon hype that is available.

Paul: The limitation is in the DataColumn type in .NET, it doesn't support custom types. That pretty much kills UDT support, unless you are using an O/R mapper with custom classes. At the moment these tools are left in the cold by both Oracle and MS because both their providers are not supporting UDTs. (Don't know about the commercial providers though, but these are extremely expensive). Nevertheless, to unleach the true power of DB2 and Oracle in an OO fashion, you have to write code in Java inside the database and call that code from .NET. You then have to be a very very pro-.NET person to pick .NET for the logic outside the database. I'd then opt for Java / J2EE also.

Frans Bouma

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 8:19 AM

Nice review, i've some thoughts also...
1) UDT is not connected directly to Java but usable in it- through very similar to strongly
typed dataset realization but support in-
DB generation of "beans"="row mappings".

2) "native" UDT language is "PL/SQL"(4GL) language written on c++, not Java
(Java VM is optional component of DB and
most DB gurus use "PL/SQL" packages/procedures
architecture in real work).

3) True power of relational data is flexibility
in operations but when you try to "enforce" some kind of "schema" on it- you lose that.
I mean, did you try to use this "wonderful"
UDT functionality in big project?
I think not, because you'll see that it's
really hard to change UDT/object schema-
require mass recompilation,code adjustment
procedures.Can you garantee that you data
schema(structure/content relationships) will always be the same?Don't think so...
But if you can't you're in big trouble.
What if you want to add/drop/rename column
(field in OO world)of physical table-type definition get out of sync straight away.

Now we're using UDT in "object" views
(more concrete- XML xsd based views) for
structured layer on relational data but we're
always tring to adapt OO features in our projects on "physical"=table layer-
without luck so far...OO layer is not flexible enough.From relational data I can assembly
any object from object I can ...???
By the way XML data is more flexible by nature
than object graph and oracle support structured "xmltype"(xsd based)
in "native" mode but it's also useful only in
"view" mode for now(for complicated cases-
save/read not count ;-) because after selection from "xml" table
you lost any type information associated with
table's column and column data becomes opaque
"xmltype".
Maybe XQuery/XPath2 can help in some way ;-)
but for now...

Best wishes.
P.S.
Look at
(http://www.oracle.com/forums/forum.jsp?forum=34) XML DB forum you can find it interesting.

Andrew

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 8:25 AM

::Schema driven

I disagree on this one.

I mean, you get another product from someone. Having this product's stuff in a separate database is a great way to separate different "modules" (like complete applications systems) from each other.

What do you do if by chance you need to install two applications having a table with the same name? The message board on your website has a Table named "User", as well as the content management system?

These are two different systems. How does oracle handle this? I think I prefare the "separate database" way of thinking.

Thomas Tomiczek

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 8:28 AM

But anyway xml functions is very powerful
feature
(http://download-west.oracle.com/docs/cd/B10501_01/appdev.920/a96620/toc.htm),look at "Generate XML Data from Database" chapter xmlelement/xmlagg/xmlsequence -all is
xml costruction functions from flat relational
data.

Andrew

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 9:22 AM

Interesting that you claim to be a database purist and yet you like sequences and MVCC. I like those too, but they seem to be "impure" from the relational theory point of view. As to the other three features, I feel that those are misfeatures. They introduce a great deal of complexity into the design of the database without much in the way of compensating benefits. I suspect they belong to the class of features in Oracle that I like to call the "Oracle DBA Full Employment Protection Act". They exist primarily to protect the jobs of high-wage DBAs.

John Cavnar-Johnson

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 9:35 AM

"Interesting that you claim to be a database purist and yet you like sequences and MVCC. I like those too, but they seem to be "impure" from the relational theory point of view"
Based on what are these impure? Sequences are a way to use synthetic keys without having to add information to the model, as I described: they allow you to set field values without having to rely on DDL specifications, which doesn't seem to be impure to me at all. The same goes vor MVCC: as long as a transaction is not committed, the actions taken by the transaction should not affect other users in the system. This is exactly what MVCC realizes. Without MVCC, users will be blocked by an ongoing transaction even when that transaction can roll back. Enabling dirty reads to circumvent this will allow dirty data to end up in the other data, which can cause data inconsistency. MVCC therefore is very helpful in a relational model, and I definitely don't see why MVCC is impure at all, on the contrary.

Your other claim about 'complexity' is just that, a claim. Can you elaborate it a bit? Just claiming it adds complexity without benefits is not that useful. Synonyms for example reduce complexity for a great deal. UDTs do to, because you don't need to write check constraints or triggers anymore, two elements which are stored 'deep inside' a schema most of the time and are easily forgotten (especially on sqlserver)

Frans Bouma

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 9:38 AM

"because you don't need to write check constraints or triggers anymore"
I meant, triggers to check values set for fields. There are other areas where triggers can be helpful and these are of course not solved by UDTs

Frans Bouma

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 9:46 AM

Thomas: you can start different oracle instances if you really want to separate the schemas. However when you look at oracle as a set of schemas it's really not different from a set of 'databases' where you have just one schema per database: the dbo one: after all, you just 'see' what you are allowed to see, so if there are hundreds of other schemas with tables, you can't see them nor use them.

Andrew: No I haven't used UDTs in a large project and your concern about recompilation/modifications of schemas is similar to the disadvantages of stored procedures, however I still think when you design your UDTs with care, they can be a great benefit and will not be of such a disadvantage as it might seem. Nevertheless: the feature is there, but .NET can't use it. This is important: you can't use a table with a column of a UDT type in .NET, nor can you bind a REF CURSOR to a dataset when that REF CURSOR returns rows with UDT values. This can severily limit the usage of .NET on Oracle.

Frans Bouma

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 10:04 AM

Frans,
i've worked with both products for years, and even if your statements about SQL Server are correct, i don't consider these strategic in a real sense, but they're so important that MS will implement everything (but sequence) in SQL Server Yukon.
Honestly speaking, i think that Oracle has 2 real main advantages over SQL Server: it's multiplatform and it's less dependant from the O.S. for functionalities like I/O, for example. This let Oracle designers implement stuff like "per User" or "per Group" resource management.
SQL Server has a main drawback, and it's related to Windows I/O subsystem and operations priority.
But technically speaking, SQL Server's Query Processor and Optimizer are more advanced than Oracle's one, and the ease in management and operations is not a point of discussion between the two products.
Usually, i'm not a "taliban" comparing this two different approaches, and i recognize that they're leaders in this market, but please, use more important points to judge who's better.

Silvano Coriani

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 10:15 AM

Silvano: I used these points because they are important for developers. SqlServer's fiber option (it's an NT kernel option really) plus the careful placement of datafiles and logfiles on separate disks on separate controllers can eliminate a big chunk of the I/O bottleneck. Per 'user' resources can be implemented in SqlServer too, when you look at users in Oracle as 'databases' in SqlServer: in SqlServer too you can manage where which filegroups are stored, but of course not how many memory / cache that database is allowed to use.

The multi-platform feature of Oracle is perhaps important to some people, I don't think that it is an important feature to have, mostly because Oracle and also SqlServer are used as standalone servers in a lot of situations (especially Oracle), which eliminates the importance of a platform.

And seriously: what will come with Yukon is fine, but it is at least 1 year away. Today, I can only opt for SqlServer, which is still the database I know best and use most, but it is aged. The features I listed are important to me as a developer and are not available in .NET nor SqlServer for at least a year. I think people should be aware of what is available today instead of looking at f.e. Yukon and 'what will be'.

Frans Bouma

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 11:03 AM

http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=all&version=5

Microsoft has 5 of the top 10 in just performance. Oracle has 3.

http://www.tpc.org/tpcc/results/tpcc_price_perf_results.asp
If you go by price and performance...
Microsoft has the top 10 in all results

I guess personally, I do not view putting application or business logic inside the data layer as a cool feature. To me it seems like lazy programming. N Tier or SOA is more flexible imho. Putting application logic inside the application allows you to change business functionality without reworking stuff in the data layer. It also has a lower TCO. Developers typically make less than DBAs (warning: generalization). 2-3 developers might cost what 1 DBA would run. One of the points people have made is that Oracle is cross platform. And Sql Server being tied to the underlying OS functionality such as I/O and operations priority. Well guess what, you put Oracle on Windows, it is subject to the exact same things.

My 2 cents.

Jeff Gonzalez

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 11:10 AM

Having rolled out a complete .Net solution using Oracle's .Net Provider, I have to say when it comes to .Net development use SQLServer. At this point neither provider (Oracle/MS) offers the full breath of features even Ora8i has. Now I've recently come across a new provider from CoreLabs that looks promising. hit it up here http://crlab.com/oranet/. There is a demo version availible. I'm very interested in putting there OraclePackage through it's paces along with the promise of all Oracle 9i datatypes. I wished they had on-line docs that I could look through to get a feeling of what some of there examples are like.

Jason

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 1:20 PM

IMHO, the most important difference between SQL Server and Oracle is its clustering support.

In SQL, if you want to cluster, you need to partition your database, and perhaps change your application logic. Each cluster is a different database server. In Oracle, you can have any number of database servers accessing the same data. This implies that you can scale out the database very easily, so running business logic in the database is a good option. SQL developers are always looking for ways to remove processing from the database because is the single point of lack of scalability. Oracle developers don't need to be that worried about that.

BTW, Yukon supports UDTs.

Andres Aguiar

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 1:35 PM

Hmmm, how about using the best of both worlds? I work for a firm that up until very recently was exclusively Oracle. We have found the mix of using Oracle for data services and logic (business rules, etc.) mixed with .Net for presentation to be, in a couple of wors, brutally powerful.

Brad More

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 3:09 PM

SQL Server "database" = Oracle "tablespace". This would be a more effective segregation of data over creating a separate Oracel instance, as a completely separate instance would double the resource load on the machine. Creating an additional tablespace for new objects would essentially achieve the same end without the additional overhead.

Bob Yexley

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 4:06 PM

Personally, I think xml support (in all its facets) is much more important than any other technology (regardless who provides it).

But back to the topic at hand ...
UDTs provide a powerfull means to abstract away the traditional relational thinking (views, tables, columns, ...). However if I have portability (think "with a minimum amount of effort/changes") at the top of my priority list, I won't use it. But if it's not, don't overshoot architecture and go for it!
On the subject of synonyms: You're right, but a well designed data-accesslayer/O-R mapper will get you just as far. Ofcourse, the real benefit comes from using these synonyms in the database itself (so there's two ways of looking at this).

From another perspective: What did you expect? That MS would build a fully functional provider targetting all features of the latest Oracle DB. You seem to forget that MS has a database server of their own, and I don't think the data access team is gonna bite the hand that feeds them. If Oracle would consider .NET to be a serious platform, they would write their own fully fledged provider (and they have, it's called ODP.NET[http://otn.oracle.com/sample_code/tech/windows/odpnet/index.html], but I don't know about the feature-set). If anybody should bring all these features to the .NET masses, it should be Oracle.

Should all these features be implemented in MS their database product? MS has a tendency to listen to developers and customers, so it's up to us to make sure they (the features) make it into MS SQL Server!

Yves Reynhout

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 4:35 PM

Oracle 9i is certainly ahead of SQL 2000, and Oracle 10g broadens the gap even further. But as far as Runtime Hosting goes Oracle is Java Only while Yukon will ultimately be .NET only. OpenLink Virtuoso (a virtual database engine for SQL, XML, and Web Services) addressed many of the current and future features of Oracle, SQL Server, and DB2 in a single compact and cross platform package today (v3.0, and more so re. new Oracle XML functionality in the v3.2 release ETA this week). My blog (see url above) and this WIP Blog (http://www.openlinksw.com/weblogs/virtuoso) are all built using Virtuoso (leveraging SQL, XML, and Web Services), and they contain references to a plethora of live tutorials and demos (available as RSS, OPML feeds naturally).

Kingsley Idehen

# Funny thing ...@ Monday, October 20, 2003 5:47 PM

... you can have all of those features (except the "Synonyms") with <a href="http://www.postgresql.org/">PostgreSQL</a> for free.
Go and try it.
You can install it in windows via Cygwin , it is somewhat painfull to install, but if you follow the instructions in /$CYGWIN_HOME/usr/doc/Cygwin/postgresql-$VERSION.README you should be OK, see the "install as service" instructions (there are plans to make a native windows version, but it didn't happen yet).
There is work underway to make a <a href="http://gborg.postgresql.org/project/npgsql/projdisplay.php">.Net Data Provider </a>.

<a href="http://pgadmin.postgresql.org/pgadmin2/pgadmin2.php">PgAdmin</a> is a very decent management tool, I advise to use the 1.6 version, the latest multiplatform version has some warts.
You can easily migrate an existent SQL Server Database to PostgreSQL using the Database Migration Plugin.
Have fun :-)
Regards,
Jorge.

Jorge Chandra

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Tuesday, October 21, 2003 3:06 AM

As an Oracle specialist, I agree with most of the things you say, except for the documentation. I do not agree when you say that the documentation is not important, and when you say it is poor. I think that Oracle's documentation is an industry standard, given the complexity and the dynamics of the software it describes. Have you been through the "Concept Guides"? Too easy for you? It is a introduction class to database that very few books match. Most of the reference guides give you the detailed information you need to do your job. Most of the doc is available in html and PDF for priting. Of course, like in all software of that size, there are "doc bugs" but there are so many help resources out there...

Peter M

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Tuesday, October 21, 2003 5:18 PM

Hi,

It looks like Yukon will support UDT's, take a look:

http://blogs.gotdotnet.com/tims/commentview.aspx/d98b62ed-686b-485b-b82b-b9f2f32b3bf1

Duncan Godwin

# re: On Microsoft's new Security Bulletin release scheduling@ Wednesday, October 22, 2003 6:57 AM

Well, the suggestion of doing both, making individual patches available immediately and releasing monthly packages, is, in my humble opinion, not the path to take.

Figure: when an individual patch is announced a lot of people may find inspiration and go and find out which system administrators have installed the patch and which haven't. System administrators that don't immediately install the patch are quite vulnerable then.

By releasing monthly security packages one suggests that not taking action immediately is a reasonable option, which obviously it isn't.

Therefore, a combination of immediate and once-per-month release strategies is not better than any of two alternatives.

Stefan Holdermans

# re: On Microsoft's new Security Bulletin release scheduling@ Wednesday, October 22, 2003 6:57 AM

Actually, they said that if a flaw is particularly severe or there is a possible exploit available, then they'll release this info outside of the schedule. So I don't expect remotely exploitable bugs to remain unattended for a whole month.

Seems reasonable to me :-)

senkwe chanda

# re: On Microsoft's new Security Bulletin release scheduling@ Wednesday, October 22, 2003 7:02 AM

Stefan: you assume that when a security fix is released, the world doesn't know that there is a flaw. However this is not true in a lot of cases, see the securityfocus.com forums.

I saw MS will release a patch immediately when an exploit is in the open. How often do they check for this exploit? 24/7? It doesn't say, plus even if they do, they can't be sure the exploit isn't there.

I think the only real option is to keep it as it is: release the patch when it is done, thus allowing people who want to patch immediately, to patch immediately.

Frans Bouma

# re: On Microsoft's new Security Bulletin release scheduling@ Wednesday, October 22, 2003 12:18 PM

Microsoft did research and discovered that these vulnerabilities were almost never exploited before the patch was released. People were reverse-engineering the patches to determine the flaws and THEN exploiting them. Also, once a week patches were very hard on guys like me who deal very heavily with security (www.patchdayreview.com). Besides, a lot of IT people were screaming bloody murder that they had to patch every week, granted, patches weren't released EVERY week, but people are not making use of SUS like they should. Critical patches are still released as meeded.

Besides, weren't you just complaining a couple of months ago that you didn't like Microsoft's patching techniques? At least they are trying something different.

Robert McLaws

# re: On Microsoft's new Security Bulletin release scheduling@ Wednesday, October 22, 2003 12:31 PM

Robert, I complained some time ago that they didn't release patches when they were available. Now they do something different, but IN THAT DIRECTION.

Frankly, I don't care if a sysadmin is angry when he has to patch systems, its his job. I was not happy with all the patches in a continuous stream but not because they were released frequently, but because there were leaks in the first place, AFTER all those code seminars MS held with the developers and the code-reviews.

I as a customer am now handed over to Microsoft's decision if the flaw is critical enough to release a patch immediately. I don't think that's MS decision to make, since the systems I have to keep up running (we're small, so no sysadmin here) are not their responsibility but mine.

Frans Bouma

# re: On Microsoft's new Security Bulletin release scheduling@ Thursday, October 23, 2003 12:54 PM

The patch headache is related to how many servers you're administering. If you have only a few, applying the patches is not a big deal. For companies with 100's or 1000's of servers, it's a nightmare.

Microsoft does release many patches but they are for different applications. Some are for IE, some are for Outlook, some for Exchange, some for the OS and there's an importance level for each patch. I personally only apply critical patches for systems that are connected to the net, otherwise I don't bother. The likehood that a patch breaks something is higher than fxing a non important issue. If it aint broke, don't fix it. I mean if you're not experiencing the problem it's fixing, don't bother.

Abdu

Abdu

# re: Useless programming language constructs@ Friday, October 24, 2003 8:14 PM

The break is necessary because many people would be expecting the fall through. To ignore past languages is to ignore present assumptions. Also it has been a rich area for bugs that is solved by being more explicit. The goto's are more explicit as well, explicit enough that you can insert/reorder things without breaking your code. Logic based on order of appearance is pretty fragile imo.

So I'm happy with the break, the lack of fall throughs, and the resulting compiler errors you get when you don't specifically say what you want...

Robin Debreuil

# re: Short list of non-obvious things determined from the C# 2.0 draft@ Saturday, October 25, 2003 9:30 AM

Partial types are part of VB.NET also, so don't worry about that one.

Paul Wilson

# re: Short list of non-obvious things determined from the C# 2.0 draft@ Saturday, October 25, 2003 2:04 PM

What I didn't find (but hoped for) are different access levels for properties.

I.e. A public property set, but protected property get.

Or didn't I search to spec hard enough?

I sent a mail to "Ask a language designer" about this today... let's see what the response is.

Roland

Roland Weigelt

# re: Short list of non-obvious things determined from the C# 2.0 draft@ Saturday, October 25, 2003 5:08 PM

In regard to properties:
"Properties, events, indexers, and operators may not themselves have type parameters (although they can occur in generic classes, and use the type parameters from an enclosing class)."

By my reading, that means that:

public class Generic<T>
{
T Property{get{...}}
}
is correct while

public class Generic
{
T Property<T>{get{...}}
}
is not. Its not really a surprise considering that collection types would be specified in the class and that there is no mention of paramaterized properties(which really aren't needed, IMHO).

Another thing I like is Method group conversions(page 14, section 19.21.1) which basically allows the compiler to infer delegate types instead of requring the new DelegateName() syntax. So code like
btn1.Click += btn1_Click;
works instead of requireing
btn1.Click += new EventHandler(btn1_Click);
for example. It is simply easier and I suspect will be easier for new users and non-IDE users(as it stands, I just hit tab twice to build an event handler, so its not going to save me much typing).

I am also pleased that iterators aren't strictly restricted to GetEnumerator\foreach keyword like was mentioned early on, but can be defined as any method that returns IEnumerable\IEnumerator(or the generic counterparts), allowing for more creative uses of the feature.

One last gotcha, although its pretty obvious, the spec mentions that using aliases in partial types only apply to the scope they are defined in, meaning that in ClassPt1.cs and ClassPt2.cs the same type alias could refer to different types. Its not a feature so much as a potential problem if not carefully used(I don't like aliases anyway, hopefully this won't cause any extended confusion).

Beyond that, I wonder if this is a complete draft of what they are adding, or if it is simply a teaser spec for the 4 big features we are all expecting, while leaving out maybe some smaller things, like seperate property access levels(which no one knows if it will be there or not, form what I've read, the camp is pretty divided in MS). I wouldn't be surprised if there are other smaller enhancements that won't be announced until the PDC, or maybe not even noticed until someone reads the final spec, but I could also be wrong.

My favorite oversight so far, however, is the spec doesn't deal with default constructor constraint usage too clearly(only place I saw discussion on the inclass syntax was in the first section, not the whole spec) and the lack of non-default constructor constraints.

Daniel O'Connell

# re: DB2 will get .NET integration!@ Sunday, October 26, 2003 4:46 PM

No product p1mping in the comments please. Kingsley: your comment is deleted because of that.

Frans Bouma

# re: Short list of non-obvious things determined from the C# 2.0 draft@ Sunday, October 26, 2003 6:34 PM

There are something I cannot yet understand from Nullable<T> (I hope I'll put my hands on Whidbey very soon).

Implementing NullableTypes I've learned that every .NET built-in type have many differences from one other built-in type:
- String and Boolean types don't implement Operator< and Operator> for good reasons while other .NET built-in types do it
- Single and Double Operator== follow IEC 60559:1989 (IEEE 754) specifications while other .NET built-in types follow CLR specifications for Operator==
- Some .NET built-in type allow conversion that do not make sense for other operators (i.e. Int32 have a conversion operator to Double while DateTime don't)
- ...
- ...
- ...

Every type in NullableTypes (or in SqlTypes) implements specific feature to be very very similar to the corresponding .NET built-in type and to follow the Null Object pattern [1][2] avoiding conditional tests for null (if is-null then... else...) to spread like a disease in the source code.

What I cannot yet understand is how Nullable<T> can be full featured (as SqlTypes and NullableTypes) while C# generics don't implement 'user specializations' (i.e. enable implementation of Nullable<Double> from Nullable<T> adding specialized members and behaveour)?

ciao (luKa)
----

[1] Test-Driven Development - Kent Beck - Three Rivers Institute -
http://groups.yahoo.com/group/testdrivendevelopment/files/TDD17Jul2002.pdf
[2] Refactoring: Improving the Design of Existing Code - Martin Fowler, Kent Beck et al. - Addison Wesley Professional - 1999 - http://www.refactoring.com/catalog

(luKa)

# Without taking credit out of Youkon ORACLE is much better than Frans pouder-discovery text says@ Monday, October 27, 2003 12:17 PM

Frans: as a Oracle newbie at a already grown-up technology like Oracle RDBMS you should know better. I mean: Oracle is an ocean where you should have a nice boat to sail into before stating any decent comments. I'm Oracle certified and have 8 year experience at it, and I don't think the Oracle-Unix (or Linux) combination has anything comparable in the Industry (nor even DB2).

Dig a coupple of years more onto Oracle and you'll find yourself amazed a bit more, even with the tools you so dumbly classified as "Crap".

Cheers.

Luis Moreno Campos

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 27, 2003 12:37 PM

Luis: your way of stating things is like the way a lot of oracle supporters talk about their database of choice and it was the main reason I was not fond of Oracle. I say some nice things about the application, and the advocates still find ways to critisize me. :) It's like saying something nice about linux and get flamed by a bunch of advocates to start using linux for a few years before saying something nice about Linux... :)

Luis, I'm not a database newbie, far from it, to say the least. I've spend a lot of time reading Oracle's docs (which are hard to navigate and search, I compare them to SqlServer's BOL or MSDN, which are easy to search and navigate). When I compare the tools coming with Oracle with the tools coming with SqlServer, and the docs with the docs of Sqlserver, the oracle offerings fall flat on their face. Query Analyzer of SqlServer isn't the best sql tool there is, but it's miles ahead on any oracle tool that's shipped with oracle (toad is 3rd party).

SqlServer can keep up in a lot of areas with Oracle, its featureset is not that crippled that it is not able to run large databases succesfully. I just wanted to highlight some features that are in Oracle and not in SqlServer and which should be in sqlserver by now. However it seems that I may not comment on Oracle's features before I have worked with it for a long time? haha :) I'm sorry, but that's a little silly, isn't it? :)

But enough ramblings. The more I read your text, Luis, the more I regret I've ever posted this blog entry.

Frans Bouma

# re: DB2 will get .NET integration!@ Tuesday, October 28, 2003 3:21 PM

Oracle is already working on a data provider for .NET. No support for CLR integration in the management system though.

Paul Gielens

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Wednesday, October 29, 2003 12:32 AM

When will Oracle be available? I need it bad.

Lee

# re: DB2 will get .NET integration!@ Wednesday, October 29, 2003 5:48 AM

Paul: I use ODP.NET already for the oracle driver for LLBLGen Pro (which will be released next week). Its a good provider, but it comes in a 74MB download, which is way too much (the driver itself is just 4MB).

Frans Bouma

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Wednesday, October 29, 2003 5:49 AM

Lee: It's released on Monday November 3rd 2003, if no serious bugs show up :)

Frans Bouma

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Wednesday, October 29, 2003 3:55 PM

The two databases serve different markets. Oracle is for the enterprise while sql server is for departmental and small businesses and for that, SQL Server does a very good job.

You have to be a full time Oracle dba (cost is high) to administer Oracle databases while SQL Server has nice GUI administartion tools, we developers do not need dba's to use it.

SQL Server is eating into Oracle's market and moving into more into Enterprise level while Oracle is still up there.

How many web hosting companies support SQL Server and how many support Oracle? Why is that. Price? Easy of use? ..?

That features you mentioned I can live without. The MVCC and transaction stuff would be handy. No one wants to be in a deadlock.

What happens when you copy a table to another database and server and forgot to copy the sequence object?

A full fledged Oracle .NET provider is Oracle's job not MS. They know their product best. Microsoft doesn't like to support competing products.
I am GM and I built a car that runs. It's your job to "accessorize" it to make it do more than what it was intended to do.

SQL Server was built years after Oracle started. Sybase's market is about 4% even though SQL Server was initially built using Sybase's technology. I think SQL Server is doing pretty good. Oracle and SQL Server are not in the same league. You should compare Oracle with DB2.

When you're a Windows shop, you don't care about crossplatform support.

Abdu

Abdu

# re: Short list of non-obvious things determined from the C# 2.0 draft@ Friday, October 31, 2003 1:34 PM

To address Roland's post - you will be able to have a public get and a private set on properties in whidbey

Eric Gunnerson

# re: VB Developers should learn to take criticism@ Tuesday, November 04, 2003 8:29 AM

You are wrong!

heh, I said it first! :P

Mel Grubb

# re: VB Developers should learn to take criticism@ Tuesday, November 04, 2003 8:31 AM

hehehe :)

Frans Bouma

# re: VB Developers should learn to take criticism@ Tuesday, November 04, 2003 8:35 AM

Frans - I am not here to debate. I just wanted to point out that I was NOT saying anything about the language. Just about people saying vb programmers are idiots. That's quite different. I have never said anything about the merits (or lack thereof!!) of VB as a language.

julie lerman

# re: VB Developers should learn to take criticism@ Tuesday, November 04, 2003 9:08 AM

Julia, again, you miss the point. My blog was about the fact that you even get offended by a remark made about VB.NET developers. Today I wrote VB6 code. That makes me a VB developer too. Do you think I feel offended when a C++ developer says VB/VB.NET developers are idiots? Not at all, because there is no reason for it. I know that I'm not an idiot, you and I know you are not an idiot, so why feel offended?

I get the feeling some people get offended because they KNOW the remark has a certain matter of truth in it, however the remark is not true for them, but for other VB.NET developers, and instead of facing the reality, people feel offended. I think that's the wrong reaction. I've seen a lot of silly VB developers in my life I can tell you that. That doesn't make the remark "VB is a language for idiots" true, because that's a wrong generalization, however among the group of VB developers, there are a lot of very low skilled 'developers', much less than you'll find among C++ developers. Not very weird, because VB is much easier to use than C++.

So instead of projecting the remark on yourself, look at yourself and if you find yourself not the subject of the remark, ignore it! After all, the remark is true for a given group of vb developers and I'm pretty sure you know that too. (not that any weblogs.asp.net blogger is among them, but they are out there)

Frans Bouma

# re: VB Developers should learn to take criticism@ Tuesday, November 04, 2003 9:18 AM

As a professional programmer (regradless of the fact that I use VB), the only problems that I have are:

1) When the powers that be (i.e. Microsoft) comes across with a statement that seems to state that the current language of MY choice is second class

2) When someone (anyone) looks down on me for working in a particular language. Come on now, I have been a programmer for 23 years. I have been a Fortran programmer, an x86 ASM programmer, a COBOL programmer, a VB6 programmer, a C programmer and now a VB.NET programmer. I look back on this list and have to state that they all had there problems, but were almost all THE language of choice at one time or another. Does that mean that they are GOOD languages? In honesty, no. Not one of them. If I had the knowledge, I would design the langauge that I want - and it would be good. ;) However, they got the job that I was hired to do done. Do not look down on me for using a tool to get paid. It is that simple.

David

David Williams

# re: VB Developers should learn to take criticism@ Tuesday, November 04, 2003 9:19 AM

Frans,

First, the comments you refer to were perceived (incorrectly I think, but still this is an important point) as criticisms of VB developers, not the language. There is a huge difference between criticizing a language and criticizing the developers who use it. Your post continues a trend in your blog of conflating those activities.

I agree with your point about the touchiness of VB developers in general, but I also think that your criticisms of VB are delivered in a rude and disrespectful manner. Statements like "the most stupid construct ever created by man" are offensive and unhelpful. If you're really concerned about addressing the problem, make constructive suggestions, backed up with reasoning. It's hypocritical to decry the flame wars without contributing to a constructive conversation.

John Cavnar-Johnson

# re: VB Developers should learn to take criticism@ Tuesday, November 04, 2003 9:36 AM

John, exactly your remarks proof my point. I say something extra rude like "the most stupid construct ever created by man" and you find it offensive. It's a language construct which every language designer would declare "stupid" to begin with. I find it also very stupid.

Now, I can't find that and express that, (I even explain why though, but that aside) without reading remarks like "you express it in a rude and disrespectful manner". Disrespectful to whom? The VB.NET developers? I don't think so.

I used criticism on the language as my angle on the matter, because criticism on the language is the source for TWO problems:
1) people who love the language feel offended and feel the urge to offend/counter the remark. This is useless because that's not the point of the criticism.
2) the language looks weaker with more criticism and therefore people who still pick that language look (in general!) not informed that well.

I ran into 1) when I entered the debate about Refactoring and the renaming of it for VB.NET. Very odd. 2) is a main source for the prejudice (!) that VB.NET developers are less skilled than developers using other languages. That's why I picked that angle.

And I will keep on stepping on VB.NET developer's towes by expressing bad things in VB.NET in a more expressed way to make my point (but always argumented). The reason for that is that I'm pretty sick of it when I try to express a flaw in VB.NET nicely with arguments (like I've done in the past several times) I still get the mud thrown over me. People suddenly accuse me of starting language wars... Now, if I could avoid VB.NET for the rest of my life this wouldn't be a problem, but I can't. I have to use it from time to time.

And this blog was not about the flaws in VB.NET, but the fact that some VB.NET developers think they have to feel offended because Mr. Box finds them underrated developers (in general) while he perhaps was refering to the group of VB.NET developers who really doesn't have a clue what software development is all about (and sorry, but that's a reality).

Frans Bouma

# re: VB Developers should learn to take criticism@ Tuesday, November 04, 2003 9:54 AM

Frans - You are right about the fact that I (and some others) are being (wait - no - "was" - because I will no longer be!) overly sensitive. I did happen to write about that in my post last night saying "i'm not going to worry about that anymore because I know I'm good at what I do". So your point is completely taken in that regard. On a lighter note, understand that before .NET, I had never really had so much involvement with non-VB developers. So hearing all of this opinion so much in the past few years was new and it just seemed to pile on which is why I and maybe others felt so much pain all of a sudden. If you look at Carl Franklin's comments in one of those posts, he too, says "aw c'mon Julie get over it". He's been hobnobbing with non-VB developers for years and so he was used to it.

julie

# re: VB Developers should learn to take criticism@ Tuesday, November 04, 2003 10:05 AM

You want to talk about stupid language constructs? OK, here goes... the whole semi-colon 'thing' that every C based language uses (oh and don't forget pascal based). Why do I have to tell a language parser where the end of line is? Just because all of these languages do this doesn't mean it's correct. At least with VB, I only have to (on rare occasion), use the dreaded underscore character.

Now, on to another point, it's not about taking critisism for being one type of developer or another. When is the last time you heard "c# developers are idiots" or "c# sucks"? Lemme see... you probably haven't. VB.NET developers are usually respectful of not being critical of other languages. Now you might say that this is because VB.NET developers "know that other langauges are superior". I don't believe this is true. I think that VB.NET devepers have a completely different mindset... one that is focused on getting the job done. Not one of being some technically superior snob who has joined the latest fad (yes, I just called C# a fad).

I use every mainstream language I can get my hands on. VB.NET, C#, C++/ATL/MFC, Managed C++, Delphi (at one time), VB6, and Java. I can tell you that there are things I hate about every single one of these. There are things that I think are idiotic from my perspective, but I'm not going to blab this because I have enough respect for the language designers and their specific target audience not to do so. I'm just not that target audience for the whole pinky finger gymnastics associated with semi-colons and squirly braces. I also like seeing End If, Loop, End While, End Function, End Sub.

I don't consider myself thin skined concerning being bashed around for being a VB.NET developer. However, I will be more than happy to put on a pair of gloves and enter a ring for a good fight if something someone says is completly off base concerning VB.NET. For example, the underscore character... as stupid as it may look, I prefer it over the alternative. ;-) Also, your ignorance is showing about VB.NET when you point out the 'On Error *' language construct. This is partially in there for allowing a path to transition to VB.NET from VB6. No real VB.NET developer would choose to use On Error after learning about Try/Catch; unless for some very specific and rare instance. Do I like On Error... no... I've never liked it. However, I look at it in the same manner as those stupid short stubby screw drivers you probably have in your toolbox. There are those rare times when you actually need that stupid tool ;-)

Cory Smith

# re: VB Developers should learn to take criticism@ Tuesday, November 04, 2003 10:05 AM

Frans,

I'm starting to feel this is a hopeless conversation. If you can't see that phrases like "most stupid [insert anything here] ever created by man" are rude and offensive, then I don't how to get through to you. In this case, you're being rude to the designers of the language.

Think about this, many people are able to discuss the strengths and limitations of various languages without starting flame wars, but you say you "get mud thrown over" you. Perhaps, it's not just the oversensitivity of VB developers, but it's also your tone that invites the "mud".

As long as you engage in guilt by association, you will get a pretty strong reaction from people. If I were to go around complaining that people named Frans are rude, self-important, close-minded, and bad spellers, I wouldn't just be insulting you, I would be insulting people I've never met. Now, I wrote that sentence in an effort to help you see how your posts seem to others. I do not judge you or anyone else on the basis of a few comments on a blog. I don't think you are really any of those things, but you come across that way to me when I read your posts. If that's the impression you want to leave, then that's fine. However, if you want to leave a better impression with people, a little more civility might be called for.

John Cavnar-Johnson

# re: VB Developers should learn to take criticism@ Tuesday, November 04, 2003 10:08 AM

Julia, thanks for this comment :)

You got to believe me, that I once also got very offended when some C++ person told me VB was a language for dummies, while that person didn't even finish his CS study on a university...

But you get use to it, and it's not worth the trouble. It's like getting offended when some Linux Sysadmin tells you that windows sux and is used by stupid people. Who cares! It's an opinion like there are so many in this world.

Frans Bouma

# re: VB Developers should learn to take criticism@ Tuesday, November 04, 2003 10:16 AM

Cory:
"You want to talk about stupid language constructs? OK, here goes... the whole semi-colon 'thing' that every C based language uses (oh and don't forget pascal based). Why do I have to tell a language parser where the end of line is? Just because all of these languages do this doesn't mean it's correct."
True. In fact, when you forget the ';' it will tell you exactly where you forgot one. :) I'm all with you here :)

But moronic language constructs was NOT the point of the blog, it was a tool to illustrate something ;)

"I think that VB.NET devepers have a completely different mindset... one that is focused on getting the job done. "
This is generalization, the same kind as "VB.NET developers are less skilled". I don't know why a lot of VB.NEt developers are not that critical towards their own language, perhaps because a lot of them are also not critical towards Microsoft or the OS they're using. Being critical using arguments isn't bad.

"No real VB.NET developer would choose to use On Error after learning about Try/Catch; unless for some very specific and rare instance."
I fear that that isn't true, at least not in the situations I've been in with VB.NET and other developers...

However also you feel it disrespectful when you find something stupid about a language. You also think in a framework where criticism is something bad I get the feeling. Don't. Criticise what should be criticised, with arguments. Only THEN ISV's know what to change to improve their products.

Frans Bouma

# re: VB Developers should learn to take criticism@ Tuesday, November 04, 2003 10:23 AM

"If you can't see that phrases like "most stupid [insert anything here] ever created by man" are rude and offensive, then I don't how to get through to you. In this case, you're being rude to the designers of the language. "
Sorry? It's a free country, and I've placed an argument withthe statement why the "_" (the space required in front of it not mentioned) is stupid. If that's good design, I don't know what's bad design.

Besides that: YOU feel offended by it. Now, THAT's the whole point of it. Not the argument of that silly underscore, it's there, it will be there, get over it. The point is: YOU get offended by reading that comment on VB.NET.

Now, John, think about that for a change. WHY are you offended? Because I say something rude about a given piece of software you didn't design and which is rude for the designers which you aren't? Isn't that a little odd :)

I hope you now understand what the point of the blog was: NOT the vb.net flaws (or the C# stupidities for that matter) but the weird reactions some people show when they read criticism about their language of choice or a generalization remark about users of a piece of software they also apply to because they use it once in a while.

You may keep being offended by the 'rude' remarks I made, you keep proving what I ment.

Frans Bouma

# re: VB Developers should learn to take criticism@ Tuesday, November 04, 2003 11:24 AM

Firstly, I agree about "_". It drives me nuts. However, the alternative is to end every statement with a ";" which is not necessarily any better.

Secondly, I agree that the differences are just a matter of preference. The case sensitivity of C, C++ and C# has annoyed me for the last 15 years or so. On balance, I prefer VB.NET for this reason, but I admit it is not important.

Thirdly, even if VB died out, it would live on in C# and Windows Forms. The Windows Forms programming paradigm owes more to VB than, for example, to MFC or 'traditional' Win32 programming.

Fourthly, VB6 programmers have a right to be angry with MS, because they have been badly treated. For many big projects, migration from VB6 TO VB.NET is unrealistic, but VB6 has been discontinued. What other manufacturer would dare treat its users like this?

Lastly, this reminds me of people making fun of Bob Dylan 20 years ago. Bob had the staunchest of fans, but was easy poke fun at.

So basically, I agree. Loosen up VB.NET programmers.

Phil

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Tuesday, November 04, 2003 11:57 AM

anyone who he says that Oracle docs are better than Microsoft's is whacked. Everyone I know gripes about them. The other day I downloaded a Java sample which wouldn't even compile due to a host of syntax errors. This was on OTN. It's a joke. Every morning, the forums are down.

Mitch

# re: VB Developers should learn to take criticism@ Tuesday, November 04, 2003 2:35 PM

Frans,

I never said I was offended. Indeed, nothing you have done offends me. Freedom generally includes the right to make offensive, rude, and obnoxious remarks. I don't have a problem with that, but a wise man once spoke about freedom by saying that while all things are permissable, not all things are beneficial.

The way you expressed your opinion about the underscore says more about you than about whether or not the way VB uses the underscore is a good design. I believe the tone of your comments contributes to the problem you are blogging about. If you want to convince people that you are correct (and, honestly, I don't know that that is your aim), I'm suggesting that you should use different tactics.

John Cavnar-Johnson

# re: VB Developers should learn to take criticism@ Tuesday, November 04, 2003 2:44 PM

IMHO, here's the irony; I've come across many VB.NET programmers (even at the PDC) who hate critisism when something degrading is said about their core platform or their breed of developers, and then there are many C# developers (even at Microsoft) who brag about C# being light-years ahead of VB.NET when they havne't even progressed futher than a "Hello World" snippet in VB.NET. Cribbing about syntax by means of an underscore is no fun and makes no sense to me. On a broader note, (finally) ANY .NET language is as powerful and as resourceful as the other. Live with it!

English is by far the most widely used language in the world but it doesn't make the French or Chinese or Sanskrit dialect any inferior. My point is: guys stop thinking in parallel paradigm.

Alec Hurbert

# re: VB Developers should learn to take criticism@ Tuesday, November 04, 2003 3:09 PM

Beginers All-Purpose Symbolic Instruction Code.
C? It all flows from there.

VB.Net introduced a lot of new constructs, but they chose to give the VB style names instead of using standard terms.
Do the other .Net language rename everything (say J# ,Cobol.Net).

There are two seriously different groups who moved from Studio 6 to Studio.Net:
Those who wanted to stop using Basic and those who wanted to continue using Basic.

I've seen good developers who want to continue using basic and bad ones who were eager to move to c#. There is no fast rule for which will do which.

I think that "..VB.NET devepers have a completely different mindset... one that is focused on getting the job done" is not far off track, but where does that leave c#?

Personaly, I have a very strong preference for c#, its a question of style.

A semi-colon indicates the end of a line of code, of an instruction. I don't like long lines of code, so I really don't like using " _" to say this line does not end.

Have you seen the source code of programs not written in "English"?

Andrew

# re: VB Developers should learn to take criticism@ Tuesday, November 04, 2003 3:17 PM

"Have you seen the source code of programs not written in "English"?"

An analogy my friend .. offtrack but just an analogy :)

Alec Hurbert

# re: VB Developers should learn to take criticism@ Tuesday, November 04, 2003 3:30 PM

Reading all this, I wonder how C# coders will take the "healthy" critism when compared with SunONE/Java.... does C# support checked exceptions, inner classes, cross platform portability or the fact that a class is not the smallest unit of distribution of code? Java has - been there and done that!

Atleast with VB.NET you can deliver the final product quicker. What good is C# in between VB.NET and Java?

java_poet

# re: VB Developers should learn to take criticism@ Tuesday, November 04, 2003 3:44 PM

java_poet: We don't care just as long as you give valid arguments which these are btw. As soon as I personally feel any language or platform beats the one I'm currently working with I'll switch, switch jobs even just to make sure the technology first my personal needs. Yes Frans language, platform to some extends it's "a way of life" but people tend to overreact just to increase their post count.

Paul Gielens

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Wednesday, November 05, 2003 1:12 AM

Has Microsoft bothered to fix the feature/bug that you can only have one LONG per table, and that you must code your sql select statements (in ADO etc) in the correct order so that the LONG field is at the end of the query?

I was geniunely amazed when I ran into this bug myself, and after doing some research online, it turned out that a LOT of people had run into this bug, and that Microsoft even acknowledged it in a Knowledge Base article, but didn't feel it deserved a fix/patch. What a great attitude.

Oracle is a dream to work with vs SQL Server having used them both for 5+ years as developer and frequent Sysadmin/DBA on Windows, Linux & Solaris.

wayne

# re: (Dutch) Tot over een uur op de DotNed meeting!@ Wednesday, November 05, 2003 8:04 AM

Ohja, which reminds me dat ik onderweg moet :)

Jeroen

# re: VB Developers should learn to take criticism@ Wednesday, November 05, 2003 8:47 AM

"Atleast with VB.NET you can deliver the final product quicker. What good is C# in between VB.NET and Java?"

It's not VB.NET vs C# vs Java. It's .NET vs Java.

VB.NET and C# are, to all intents and purposes, the SAME THING. At least at the moment.

I don't think about language so much as about the technologies (ASP.NET, ADO.NET, BCL, XML, ...).

I choose to use C# because I prefer the syntax. My colleague prefers to use VB.NET, 'cos he's more comfortable with it. We can work together. I don't think any the less of his skills, because we're both .NET programmers.

Johnny Hall

# re: (Dutch) Tot over een uur op de DotNed meeting!@ Wednesday, November 05, 2003 9:27 AM

Ik sla vandaag over... s'me net iets te ver voor die paar uurtjes. Ga je trouwens ook naar Zweden eind Jan?

Paul Gielens

# re: VB Developers should learn to take criticism@ Wednesday, November 05, 2003 9:30 AM

Alec : I think the language analogy is good, but I don't think that languages are all the same underneath.
Each has hidden assumtions about "reality". A concept may be encapsulated in a single word in one language and yet require several words or even phrases in annother.

I work in a mixed language environment, where I spend more time speaking my second language than I do speaking English.

I have seen a lot of code written by people who's first language is my second, and for the most part, the quality of their code is tied to whether they try to write code in "English"
or not. They try to mix maps.

I've never worked in a non-English based programming language, and I pretty sure if I did, I would have the same quality issues if I tried to code in "English" in that prog. lang.

I'm not a linguist, but from what I hear, Esperanto is supposed to be "the best language"...

Andrew

# re: VB.NET developers, continued@ Wednesday, November 05, 2003 9:33 AM

Let me add my vote too.

MS fix it right...

WORSE case, make the menu optional and allow VB'ers to enable it via the options. Don't make it completely unavailable.

And don't make us have to hack a way to enable. You KNOW we will find a way to make it, or like functionality available. So instead of the standard, we'll have a bunch of custom written solutions (think XML comments in VB)...

MS PLEASE don't make us go through this...

Do it right, treat you VB.Net programmer like they are professionals...

Greg

# re: (Dutch) Tot over een uur op de DotNed meeting!@ Wednesday, November 05, 2003 11:02 AM

Delft is zo ver weg als je in Grun'n woont :(

Zef Hemel

# re: VB.NET developers, continued@ Wednesday, November 05, 2003 11:03 AM

I 100% agree. MS's job is to raise the lowest common denominator, not pander to it.

Robert McLaws

# re: (Dutch) Tot over een uur op de DotNed meeting!@ Wednesday, November 05, 2003 1:22 PM

Paul: Ja! :) Jij bent ook uitgenodigd door Jimmy? Lijkt me wel erg interessant :)

Zef: inderdaad :)

Het was overigens erg interessant. Dino's verhaal was erg indepth maar wel leuk. :)

Frans Bouma

# re: VB.NET developers, continued@ Wednesday, November 05, 2003 5:56 PM

If I can ask, how exactly is implying that VB.NET developers require their IDE to teach them a term treating them like professionals?

Daniel O'Connell

# re: VB.NET developers, continued@ Thursday, November 06, 2003 6:15 AM

Daniel:
Not all terms of an industry should be known by everybody. However when you use a given set of tools and you don't know the correct name for these tools, you don't really know that you use them when you see/hear/participate in discussions about these tools. Also: all C# developers will be confronted with the term, will learn what it means. All VB.NET developers will not, and will thus not be forced to learn what it means.

Frans Bouma

# re: VB Developers should learn to take criticism@ Thursday, November 06, 2003 12:32 PM

VB.NET developers are under rated. I mean they are paid less for the same project than C# developers. C# has a prestige associated with it. I am just talking based on real life.

abdu

Abdu

# re: VB.NET developers, continued@ Thursday, November 06, 2003 11:33 PM

> Not all terms of an industry should be known by everybody.

I would say will, not should. Should implies that there are things that people have not only no reason to know, that they shouldn't be told, excluded if you will. That is BS in my opinion, and isn't that what the whole argument is about, people suggesting that there is a term that VB developers shouldn't know?

However, I expect any decent VB.NET developer to be capable of learning on their own, just as I would any C++, Java or C# developer. Claiming that only via IDE support wil the VB developrs gain knowledge of refactoring or any other technique suggests that people(or you atleast) don't think VB coders actually try to learn and stick strictly to VB and its IDE. Any developer who would be involved in such a discussion should be well aware of what the general term means, even if it is not in the IDE. Implying otherwise, to me anyway, implies that the users of the IDE are not as dedicated as the rest of the industry.

Daniel O'Connell

# re: VB.NET developers, continued@ Friday, November 07, 2003 5:56 AM

I ment 'Will', typo. (I'm not a native English speaker).

I also expect any developer to do a fair amount of learning but that's not the point. The point is that when you use a feature X, you should know hte feature you use is named X and not Y. As you can't know everything (a lot of C# developers will learn about refactoring whenthey open the IDE I'm sure), and when you DO use X, it is not more than appropriate the IDE, the documentation and examples/tutorials show you that the feature X is called X and not Y. That's the point.

Frans Bouma

# re: VB.NET developers, continued@ Friday, November 07, 2003 1:14 PM

My own experience is that many .Net developers don't know what refactoring really is, unless they also know what unit testing and design patterns are. It's not a language thing as far as I can see -- I have a client who is a VB.NET shop that, because their coders to test-first development using nUnit, can refactor code to their heart's content because a good suite of unit tests will tell you if you messed anything up in your refactoring.

I also know tons of C# coders who don't write unit tests, so therefore any "refactoring" they do is essentially just mucking about with the code.

--Bruce

Bruce Onder

# re: (Dutch) Tot over een uur op de DotNed meeting!@ Saturday, November 08, 2003 4:33 AM

Ja, zeker wel interessant! Ben alleen nog aan't tobben (heb tegen die tijd een oplevering en verhuizing van kantoor) zelf rijden of vliegen, hmm. Zin om iets te organiseren? Wel zo gezellig.

Paul Gielens

# re: Here's a (big, bad) difference between VB.NET and C#@ Wednesday, November 12, 2003 5:30 PM

You don't have to look THAT far to find crippling differences - lack of C variable types (such as unsigned bytes, words etc) makes VB.NET totally unusable for many low level scenarios such as encyption, hashing, CRC algorithms, etc.

Addy Santo

# re: Here's a (big, bad) difference between VB.NET and C#@ Wednesday, November 12, 2003 6:53 PM

This might sound stupid, but how would you go about doing private implementation of an interface? Did you mean not declaring the interface name in the class declaration and just writing out the methods of the interface as regular methods?

Roy Osherove

# re: Here's a (big, bad) difference between VB.NET and C#@ Wednesday, November 12, 2003 9:03 PM

Well, my guess is that sort of thing would just make Mort's head hurt, so it has no place in VB.

As far ass private implementations:

interface IFoo { void Bar(); }

class X: IFoo
{
void IFoo.Bar() { }
}

elsewhere, you can't do this:
X x = new X();
x.Bar(); // not allowed

but you can do this:
IFoo f = x;
f.Bar();

Mickey Williams

# re: Here's a (big, bad) difference between VB.NET and C#@ Wednesday, November 12, 2003 9:05 PM

ROFL: make that as, not ass

Mickey Williams again

# re: Here's a (big, bad) difference between VB.NET and C#@ Wednesday, November 12, 2003 10:15 PM

Micky, Thanks. BTW, I'm a Mort :) My head isn't hurting one bit, but my pride is a little.

Roy Osherove

# re: Here's a (big, bad) difference between VB.NET and C#@ Thursday, November 13, 2003 2:57 AM

Can't you use shadowing to resolve this issue?
Use the Shadows keyword on the GetObjectData() method. From the Visual Basic Language Reference: "If the shadowing element is not accessible from the code referring to it, for example if it is Private, the reference is resolved to the shadowed element."

Sander

# re: Here's a (big, bad) difference between VB.NET and C#@ Thursday, November 13, 2003 3:03 AM

Sander: No, because you have to specify Implements ISerializable with the class, which is not allowed. :)

Mickey: indeed, that's they way you can do it in C#, and that's the way MS did implement ISerializable on DataTable. Of course that's a bad way to design a class, nevertheless, VB.NET can't 'fix' that, only C# can.

Frans Bouma

# re: Stored Procedures vs. Dynamic Queries.@ Thursday, November 13, 2003 5:39 PM

sql server blows
mysql rocks

jack

# Interface reimplementation@ Friday, November 14, 2003 6:57 AM

Will be supported soon.

TrackBack

# re: Serious ASP.NET Editor flaw lives on in VS.NET 2003@ Friday, November 14, 2003 9:10 AM

First, thanks for a good summary of the issue. Microsoft has had many major flaws in their systems, which is not unexpected considering the sheer volume and scope of them. Professional programmers understand that and can live with it. That's not the real problem. When a major flaw is found by the first person, Microsoft SHOULD be telling everyone about it in any way they can so every single programmer doesn't have to waste time finding it anew. As usual though, they take what can only be described as an immature approach and make a point of minimizing it to the point where you have to search and search just to get the REAL scoop from some user posting. "Flaw? What Flaw? Oh, you mean THAT flaw. Well, yeah, of course we knew about it and now that you mention it, let me tell you all about it..." Just to drive home the importance of this particular flaw, it isn't just that the text gets bunched together in an unreadable format. The formatter actually rearranges the tags within a control's specificatins. For me, I have a dropdownlist on a page used to edit a record, and set the datasource using a function in the codebehind page. I also set the current index value using another function. So I have a "datasource =" and a "selectedindex =" within the dropdownlist tags, so when the screen comes up, the dropdownlist contains all the available selections and is sitting on the one currently selected for that record. The reformatting actually moves the selectedindex IN FRONT OF the datasource specification. Since the entire point of a tagging system is that it is NON-POSITIONAL, what moron even considered altering the coding in this way? The interpreter is also flawed, because it takes in this new line of code and reconciles the tags from left to right! So basically, my "adjusted" code now tries to set the selectedindex of a datasource that doesn't exist yet, and the program crashes. As for Mike's statement, give me a break. This is ASP.NET, the entire foundation of which is that editor. It's obvious from the example I just mentioned that the reformatting is reading the controls in by tagset, analyzing them for "reformatting" and writing them back. It just happens to be totally screwing up the "writing back" part. Now we're being told that the integration is too deep? All I can say is, Mike, stop treating the experienced programmers of the world like idiots. It's more likely that Microsoft has done what they usually do, which is to put out a brand new product with version "1" before it is really ready, to beat the competition and coordinate with their other schedules. Then they move almost all the knowledgeable staff onto the Version 2 project and leave a support staff handling updates and bug-hunts and as Mike is doing, just plain stalling until Version 2 is ready. Here's a few things Mike could do in a quick service pack that are really easy: Since there are checkboxes that supposedly control the autoformatting in Tools/Options, but DON'T, take them out. It just means making them invisible and they must have somebody there who can handle that. When this service pack is installed, include a document that completely describes this problem and all of the other ones like it that I haven't personally found yet. Since that is just typing, they should be able to handle that as well. Unless of course, their keyboards are too deeply integrated into their editors....

FC

# Stored Procedures versus Dynamic SQL - the old debate...Frans Bouma's take...@ Tuesday, November 18, 2003 1:11 AM

TrackBack

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 6:57 AM

My words :-)

Thomas Tomiczek

# ASP.NET dynamic SQL vs. stored procedures - what's right?@ Tuesday, November 18, 2003 6:58 AM

TrackBack

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 7:42 AM

Sorry Frans - I have to respectfully disagree, life without Stored Procedures is silly.

Duane

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 7:49 AM

Duane: can you elaborate on that a bit? Just stating it's silly great but not a solid argument.

That said, I write a stored procedure sometimes, the last one I wrote was a sequence emulator stored procedure. However the occasions I have to are countable on one hand, while I do database development every day.

Frans Bouma

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 8:10 AM

All I can say is that I respectfully disagree 150%! Stored Procedures do provide a dramatic performance boost over dynamic SQL when needed. A generic DB access component is a disaster waiting to happen, as it depends on a properly designed database, which no one will ever create.

Wally

Wallym

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 8:17 AM

Taking a binary approach is silly, you can't sriously be saying that for every occasion dynamic Sql is better - a few instances where I disagree - Indexed Views, these are essentially SPs, and are invaluable in a scalable environment (Indexed views representing an essentially 'static' view on data, updated when the underlying data is). Using Table Variables in SQL Server 2000 from Stored Procedures lets me composite and filter my resultset before returning it to the client app thereby substantially reducing my network traffic, connection usage, memory footprint for the app and therefore vastly increasing my potential scalability. Your argument about using Views is pretty limited in my opinion, Views are not updatable, I can't get a resultset from one SP and based on that, update the data in my view then filter the data in my View to produce the desired resultset - even if I could, I would be storing a HUGE resultset for many operations where I only require a couple of items - Views cannot replace SPs in most circumstances.
Quite simply, I also do serious web application development every single day, 99% of requests to the DB are best served by stored procedures, I have worked a lot with Dynamic SQL in code previously (forced to when using MySQL with PHP / Java), the risk of introducing errors into really quite complex Dynamically built SQL statements is really pretty high - plus it's pretty tricky to debug every possible scrnario unde which the statement may be built.

Scott Galloway

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 8:20 AM

Wallym: the dramatic performance boost is not there, because the stored procs are threated as queries which arrive at the sql engine: they are compiled at runtime.

So they're not faster, they are sometimes even slower, because you have to code constructs in the stored proc to add some sort of flexibility (like a bit parameter which is used in an IF ELSE clause. That will force a recompile every time!).

Don't believe the myth, read the docs (Books Online). They're clear on this.

Frans Bouma

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 8:26 AM

::All I can say is that I respectfully
::disagree 150%!

Ah, kids playing.

Look, how can you disagree when the documentation says rob is wrong?

How can you disagree for arguments given when you basicaly have NO arguments.

::Stored Procedures do provide a dramatic
::performance boost over dynamic SQL when
::needed

Factually total bullshit.

Stored Prcedures CAN provide a significant performance boost in certain situations when you are able to move processing fom the application layer to the database. Not "when needed" as you say, but "when needed AND when the data processing fits into this condition".

Stored Procedures are NOT significantly faster than dynamic SQL if all the Stored Procedure does is a single INSERT/UPDATE/DELETE.

This is another fact that is well documented (in this little thing called documentation).

::A generic DB access component is a disaster
::waiting to happen, as it depends on a
::properly designed database, which no one
::will ever create.

Careless use of SP's are a desaster HAPPENED. Get this - the generic component may be a desaster waiting to happen, but having hundreds of objects that require some gpoor guy to create and maintain hundreds of methods that are nothing more than simple processing IS A DESASTER THAT HAPPENED.

By the time this poor sould is finished with his little task, other people have already finished the complete application.

SP's are VERY nice in a lot of situations, and every generic layer COULD utilize them actually (not a lot now, but definitly a lot more once YUKON is around). But stating "they are better. Period" is not a sign for maturity at all.

Counter the arguments Frans has put up, or realize that you dont have any good arguments at all.

Thomas Tomiczek

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 8:29 AM

Indexed views can be accessed as normal views, by normal SQL. Views are something else than a stored procedure, Scott. Also your argument about connection usage is odd: connection pools will serve you well.

True, it requires some work to get a dynamic query generator right, but once you have one, you don't have to recode it again.

"I can't get a resultset from one SP and based on that, update the data in my view then filter the data in my View to produce the desired resultset - even if I could, I would be storing a HUGE resultset for many operations where I only require a couple of items - Views cannot replace SPs in most circumstances. "
Views are used to control the security issues. SP's are code-statements, views can be seen as static tables, for SELECT statements, FROM clauses and WHERE predicates. you can for example update rows in a table using the FROM clause to filter on a view's data. Views aren't limited, they are as flexible as tables, because they are a view on tables, replacing those tables in logic which would otherwise be performed on the tables. Views don't replace update stored procedures, they can be used to control security where sp's are used to do that.

Frans Bouma

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 8:36 AM

sprocs performance increase isn't just due to the precompilation. It is also due to the reduction of round tripping to the client (which isn't cheap), and reduction of network traffic that comes with it (ahh, good times).

As for the security mechanisms, I do a lot of training with healthcare and government bodies, and regulations require them to not give developers access to the underlying tables. Period. I guess you could use views for everything, but you'll have to be writing after triggers to get that to work and at that point you might as well be writing stored procedures anyways.

And most people are doing security for more than two roles. If you are doing security on a column basis for even just five roles, may god have mercy on your soul. You will screw up, you will waste time and you will end up opening more data to people that don't need it. Just like security based on roles is easier to implement, security based on tasks is also easier to maintain and implement.

Of course, that's just my opinion, I could be wrong. It's interesting to see everyone else's opinion on the subject though.

Phil Scott

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 8:42 AM

Phil...the round trip argument is pretty much what I was trying to get to with the connection stuff...I also completely agree with your other arguments :-)

Scott Galloway

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 8:45 AM

Excellent post. We had a major project at my last employer that had a DBA writing (or at least approving) the stored procs for rather routine CRUD, a junior developer writing wrapper classes around all of those stored procs, and then the application developers only had to worry about consuming those data libraries. Looked great on paper, since this was an n-tier architecture with lots of separation, and we all know that's supposed to make our lives and maintenance easier. The problem was that it did not make anything easier, since nearly every change in the database required at least 2 people, if not 3. These changes also had to be coordinated very well, since anyone done out of sync, or too late, would break the build, and this did indeed happen. I think our DBA felt very threatened when I talked about O/R mappers, but I honestly think these tools would actually finally have given him the freedom to worry about the database design and performance optimization, instead of writing routine CRUD procs. The junior developer would also be freed up to actually become a real application developer, instead of just being another wasted body. So, down with stored procedures -- long live SQL!

Paul Wilson

# Does an OR Mapper need to use dynamic sql?@ Tuesday, November 18, 2003 8:46 AM

TrackBack

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 8:59 AM

@phil: 'It is also due to the reduction of round tripping...'

This is not the case, you can use a whole batch of T-SQL commands in a single call resulting in a single network roundtrip, so it is the same number of round trips as if you would call a SPROC: 1!

Marc Hoeppner

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 9:21 AM

Marc: Good call on saving the round tripping with multi-statement SQL.

But I would hate to run into this type of code personally. I mean, you are basically writing a stored procedure at that point and hard coding it into your app. Most of my development is in VB, but I would have to switch to C# just to be able to get away with not having to use the dreaded _ and & to build the string together to get that sucker to run, and be maintainable. Once again, my personal preference.

Now as Paul brings up, your opinion of stored procedures really depends on your environment too. I personally would I simply set fire to the building with the three person tag team on the CRUD development.

It might just be the relatively small nature of the projects I've been working on (15-30 tables), but I've managed to escape writing simple CRUD sprocs. Most of my sprocs look something like "AddOrder", "GetOrdersByCustomerID" and things like that. I have been given the power of writing my own sprocs, if I had to go to a DBA to get that done, well, if you've seen kill bill you know the type of violence that would ensue.

The only time I seem to not be using stored procedures is when I'm working with data adapters and datasets. I see no real reason to use stored procedures for the reasons outlined here by everyone else. But in my connected environment land, I'd rather use stored procedures instead of using the work arounds that people have presented here.

Phil Scott

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 9:25 AM

Paul: exactly my point.

Phil: giving developers access to stored procs is not helping you a lot. You have to insert/update data anyway, there ARE sp's in the API which do that. So the argument is pretty moot if you ask me, but nevertheless, if you are REQUIRED to do so (even when the arguments for those requirements are not that great) you don't have a choice. If you DO have a choice: think twice.

Frans Bouma

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 9:30 AM

@Phil Scott:
::But I would hate to run into this type of
::code personally. I mean, you are basically
::writing a stored procedure at that point and
::hard coding it into your app

Totally wrong.

If you do it right, you write a SQL generator that is able to take advantage of batching, as I do right now with the EntityBroker. Nothing else.

My programs will use batching, but I will never "code a SP into my app". Never.

Thomas Tomiczek

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 9:31 AM

@Phil: Is it really that different? - You are going to 'harcode' it anyway: You build your SQL either with Query Analyzer or another tool. When you are done, you type in your SQL code into an editor (=hardcode it) and run the program to get the results. Now, in one case your editor may be the SQL Enterprise Manager, creating a SPROC. In the other case this may be VS.NET and you enter the T-SQL in a VB.NET or C# script. In any case, you effectively 'hardcoded' it!

And I agree the @ really helps :)

Marc Hoeppner

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 9:31 AM

Simply wrong. There are things a Stored Procedure can do that would take many round trips for Dynamic SQL.

If you think sending a huge multi-statement query request across the wire is more efficient that a simple SP call - you haven't played with a slow connection much.

I don't know how many times I have found a bug in a Stored Proc, fixed it and did not have to redistribute client code.

Code reuse between applications is greatly enhanced. A list of active employees is made available without having to give rights to the Personnel DB to every Tom, Dick & Harry.

Mike Potter

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 9:37 AM

Marc:

How is:
myCustomer.Save();

or
DaoAdapter dao = new DaoAdapter();
dao.Save(myCustomer);

hardcoding sql?
It's not. You require logic to distinguish insert from update, when update, what to update, etc. Nothing is hardcoded. That's the point.

Filtering on entities in the database is dynamic: you formulate your filter right there where you need it. This for example requires 2 arguments. If you want that in a stored procedure, you would add 2 parameters. Another query in your app does the same filter, but with 3 arguments. You have to alter the stored proc or create a new one. Adding a new parameter will break the 2 parameter call. So you have to alter THAT CODE as well. Which is weird, because with the dynamic query you wouldn't have to alter that query.

Frans Bouma

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 9:52 AM

Right-on! I've been on the stored proc bandwagon long enough.

Eliminating stored procs is not silly. I'll take a nice and tight database layer over procs any day.

SteveL

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 9:56 AM

@Frans:

I was just replying to Phil as he said he feels that using SQL inside code is 'hardcoding' it (if I understood him correctly). So I was just comparing SPROCs to 'hardcoded' SQL inside a SqlCommand, for example :)

Now, if you enter the world of dynamic SQL for CRUD operations you are absolutely right. If you don't use such a ORM tool, you _will_ have to hardcode your CRUD SQL somewhere, either in a SPROC or inside a call to, say, SqlCommand()!!

Marc Hoeppner

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 10:01 AM

@Mike:

>Simply wrong. There are things a Stored Procedure can do that would take many round trips for Dynamic SQL.

Care to share an example?

>If you think sending a huge multi-statement query request across the wire is more efficient that a simple SP call...

Nobody says that. The point is that a multi-statement query will be _as fast_ as a simple SP call. Not faster, not slower :)

If you work across a 56k modem to your DB, you are indeed working on a different set of problems. In this case, I agree with you that even the few extra bytes like a few hundred bytes of T-SQL code may add up.

Marc Hoeppner

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 10:02 AM

Marc: hardcoding crud statements is not something you have to do. Using a dataset for example, you can create your insert/update statements on the fly. The data you have to use in an insert/update statement lives somewhere, you can use that to create the statement. Using a generic block of code you can reuse.

Frans Bouma

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 10:11 AM

So, when is your Database Object released? :P

Nielsz

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 10:13 AM

Marc, you understood me correctly. Just poor wording on my part. At 10am my brain has flipped it's "write coherent" bit on.

Of course it isn't that different, it is just a matter of preference for me. I'd much rather have that code as stored procedure on the server than on the client, that's all. And as Mike said, depending on the type of connection sending a 2000 byte sql statement vs a 20 byte stored procedure name might add up depending on the architecture and the clients needs.

O/R tools, and dynamic sql generators are always great tools to have, and if I have access to an easy to use and powerful one I'd take that any day of the week over writing sprocs by hand. But not everyone has the resources or even the need to have such a tool on hand.

I can't see how anyone in this case has been totally wrong or how one way of doing things would be the "right way" over another. Each method is going to have it's pros and cons. I think if you are using an O/R tool or the DataAdapters you aren't going to be seeing any benefits from using stored procedures. But for those who are (god forbid) using DataReaders and sending SqlCommands directly, I feel I'd rather use sprocs for that.

Phil Scott

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 10:14 AM

@Frans: Using CommandBuilder?? - This is definitely _not_ a good idea. It may work for simple tables, but as soon as you start to have more complex scenarios, it stops working. 'Complex' scenarios start with using JOINs and multiple PKs etc.

Marc Hoeppner

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 10:15 AM

At my company, we have 3 software products that work against SQL Server, Oracle, and DB2 with the flip of a switch. We have built it using dynamic SQL within our code and all 3 have been around for years. These are big apps and, in the end, they are very maintainable.

Imagine trying to sell your product to a company's IT group and saying that it relies on stored procedures. Guess what...the DBA is going to shoot it down because he knows that as new releases come out, it is going to be a huge pain in the ass for them to update and maintain changes to the SP's. Now tell them that they don't have to do anything. All the SQL is managed in the code itself. Well, you know their reaction.

Maybe an in-house application where I know the back-end will always be SQL Server or Oracle or whatever, I would use SP's and love them. That's just not the case for a product-based application. At least in my experience it isn't.

JW

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 10:19 AM

Marc: no not using commandbuilder:) Using a component you write yourself (or buy). You feed it the objects it should generate DML for and it generates that DML, including parameters. Execute that and you're set. Cache the result on the client if you will so you don't have to regenerate the statement. A dataset has the schema inside itself needed to generate the code you need. (I use the 'dataset' example, since Scott accused me of writing a blog to sell my O/R mapper LLBLGen Pro which is not the case at all :) ).

Frans Bouma

# Dynamisk SQL eller SP?@ Tuesday, November 18, 2003 10:20 AM

I det seneste d

TrackBack

# Ever heard of role-based security?@ Tuesday, November 18, 2003 10:20 AM

TrackBack

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 10:39 AM

As far as Paul's comment about breaking client code by making changes to the stored procedures: This is no different than changing the rows a view returns as far as breaking things, and as for parameter changes, the best way to handle this is to add a parameter with a default value that works for everyplace the SP is called except the place that needs the new parameter. A good DBA does not break client code. A bad DBA will mess up any architecture.

Douglas Reilly

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 10:45 AM

Pre-compilation of a query plan does not exist, but that is not to say that plan re-use is not a performance benefit. 2nd and future executions of a stored proc will run faster (how much faster depends on your hardware).

A stored proc which gets the last name of a customer by customerid should outperform a straight execution of "select lastname from customer where customerid = 12345". But an external component that dynamically builds *AND PARAMETERIZES* a query (basically runs it through sp_executesql properly) should perform on par with the stored proc. I think that's a point people are missing when arguing against dynamic SQL.

Over-the-network performance benefits of passing "sp_Crap" instead of "sp_executesql 'SELECT crap'" are usually negligible these days with the fat network pipes.

Mikey

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 10:45 AM

@Frans

Yepp, like I said, I was not trying to argue against the advantages of using something like ObjectSpaces ;) - But if you don't have that at hand, you are likely to hardcode your SQL code either into a SPROC or inside C# (or whatever) code. JW makes a good point though, that such a tool should be able to support both auto-generated SQL code as well as existing SPROCs as it simply is a requirement for some companies. Still, it doesn't change the general argument that we have here about the technical pros/cons of SPROCs. The business side is still something else to consider on top. On the other side, if you develop a product and deploy your own DB, I definitely want to make sure that the DBA _has no chance in hell_ to 'tweak'/'enhance'/ruin our SQL code ;)

Marc Hoeppner

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 11:37 AM

I think you need to address the comments about Round Trips. The biggest aspect of stored procs is that they live close to the data. So, if you are doing simple processing - sure. However, if you are doing complex processing, requiring multiphase transactions - interim result sets (changing logic and flow based on interim result sets) - I don't see why stored procs wouldn't be used. When you need to pass everything out of SQL - you are working on layer (the network layer) that is literally 1000's of times slower then memory. This isn't good. I don't know about apps that you write - but apps that I write tend to have very complex rule implementations - and data manipulation isn't confined to simple SQL statements. They may require many many many nexted transactions - sub-queries, multi-stage processing, etc.

I do agree, however, that sp's are misused for the wrong reasons with regard to performance, security, etc. But, in the real world (architecturally) they are a fact of life. If they didn't represent some level of goodness, why has Oracle been promiting Java in the db for years. Why are we so excited about having managed code live in Yukon? - its all about round trips and reducing network traffic as much as we can. Chatty apps are bad apps.

Joel

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 11:40 AM

::If they didn't represent some level of
::goodness, why has Oracle been promiting Java
::in the db for years. Why are we so excited

Because Oracle was always the worst of all databases, from a SQL point of view. Their query analyzer literally sucked - all performance out of the server by being too stupid to see the most obvious things.

So, Java in the database was the way they "solved" this.

::about having managed code live in Yukon? -

Are we? Really? I am not.

::its all about round trips and reducing
::network traffic as much as we can. Chatty
::apps are bad apps.

Not necessarily. You can neutralize - pretty often - most of the impact with a good application server. Not always, though - and then you start hitting the last percentage of gains.

Again on the "Chatty apps are bad apps".

Why d you think a company like Persistence (http://www.persistence.com) has proimoted to be times faster than a SQL database for years? Because it is not always true what you say.

Thomas Tomiczek

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 11:43 AM

Some stored procedures are pretty complex and big in size. Having them as sql queries being resent by hundreds of clients is a network bottleneck. They also eliminate round trips. You can encapsulate all your SQLs in one call.

Some SQL statements span different databases across different servers (linked servers). This means these clients need to to have access to these servers.

How come your first LLBLGen used SPs only?

Abdu

Abdu

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 11:48 AM

"How come your first LLBLGen used SPs only?"
I wrote that tool in a time when I was fully convinced stored procedures were much better, and way faster than dynamic sql. After I've hit the wall and learned that this is not the case, I gave up on stored procedures. That's why LLBLGen Pro generates all sql on the fly. It still can call sp's if you want to, but not for entity usage.

Frans Bouma

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 12:13 PM

@Joel

I don't think anyone is asking to drop SPROCs off the feature list. I totally agree that there are good reasons/cases when you should use SPROCs. The general argument started with Rob saying that you should use SPROCs always and everywhere. That's where many people including myself disagree. But that doens't mean that SPROCs are useless, quite the opposite.

Yukon solves many problems I/we have with SPROCs, for example versioning and multi-developer scenarios, let alone the whole deployment stuff. Still, I think that tools like ObjectSpaces, EntityBroker or the beloved LLBLGen have their merits even in the Yukon timeframe. Using parameterized queries still will keep the action where it should be (on the DB server using SQL) and the few extra bytes on the line surely don't make a real difference for most apps, at least IMHO.

Marc Hoeppner

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 12:39 PM

> you should use SPROCs always and everywhere

Please don't misquote me. I did not say this and I clarified it further here:
http://weblogs.asp.net/rhoward/posts/38298.aspx

The main point that I am making is that you should take advantage of the platform you are running on. If there are platform specific features that you can use to better your application than you should take advantage of those features.

Rob Howard

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 1:07 PM

@Rob

From your original post:
>At just about every talk I give I always try to make several consistent statements. One of which is: ‘Whenever possible use stored procedures to access your data’.

I think this statement is much to general in nature, so I don't feel I misquoted you saying 'with Rob saying that you should use SPROCs always and everywhere'.

Marc Hoeppner

# Stored Procedures vs. Dynamic SQL@ Tuesday, November 18, 2003 1:19 PM

TrackBack

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 1:21 PM

::>At just about every talk I give I always
::try to make several consistent statements.
::One of which is: ‘Whenever possible use
::stored procedures to access your data’.
::
::I think this statement is much to general in
::nature, so I don't feel I misquoted you
::saying 'with Rob saying that you should use
::SPROCs always and everywhere'.

I would say the original statement is cromoinally wrong.

See, "Whenever possible" means "also when it makes no sense". Even when you end up with a simple "select * from table where id = ?" in the SP, this would mean "use a SP, just because it is possible".

Basically, the statement means: use sp's for everything unless you use MS Access or another database which does not know SP's.

The quote from Frans (sorry, Rob) was right.

Thomas Tomiczek

# Stored Procedures vs. Dynamic SQL@ Tuesday, November 18, 2003 1:43 PM

TrackBack

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 2:19 PM

Use a stored procedure if the roundtrip savings are worth the decrease of maintainability, flexibility and compatibility. We tend to call this "the zone". "The zone" where business logic is factored tighter and tighter to your db scheme. Besides the people who wrote OR mapping tools probably compared execution plans (SQL server) and must have noticed dynamic SQL is way faster due to SQL server's crappy stored proc optimisation when precompiling.

Paul Gielens

# re: Stored procedures are bad, m'kay?@ Tuesday, November 18, 2003 3:11 PM

I Think that after eight years of keeping stored procedures you become tired of them and you'd rather prefer your comfort than a well designed application.

Rob's got a point on it

Harley Jácome

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 4:39 AM

I'm surprised that noone has mentioned the merits of using SProcs in a secure environment yet. For those DB's where complete access security defines the method of data access, SProcs are really the only way to go.

Say for example I have a DB using Windows Auth to restrict who can view what data. The DB is being accessed by three or four different apps. Now on that DB I have something like 100 tables, which I do NOT want the casual browser (using Query Analyser) to be able to view. I therefore need to lock down access to all tables. Access MUST then be made through SProcs. I know - I could just allow access to the tables through defined logins. But what if I need two different roles (Staff vs. Managers - defined by NT Domain groups) to be able to retrieve different sets of data from the same tables? And what if the access levels that particular users have are to changed? For example - a Manager can only view payslips for those employees that work directly for him instead of the whole department? That would require the code of three or four applications to be changed. I'd rather change one set of SProcs...

The point I'm trying to make is that if you are developing an application in which any kind of sensitive/personal data is involved, or where Role-based access to data is necessary, or you are required to ensure that this data is kept secure - Dynamic SQL will not be your best friend. In these instances only SProcs will help. In fact I'd go to say that if you are designing/developing with security in mind from the start, then you'd be daft not to use the in-built security that SProcs offer you.

Mike

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 4:49 AM

Mike: the time it takes to create all those stored procedures for each role can also be used to create the views you want. The advantage of that is that you can use views in queries (FROM clauses) you can't do that with sprocs.

People think that in a high-secure environment, stored procedures will be much more secure AND it will take way less effort. This is not true: for each byte you want to return as a select result, you have to write a procedure. That code can also be used to write a view.

Frans Bouma

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 5:15 AM

What about writing your business logic in a stored procedure?

Frederik Gheysels

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 5:59 AM

What about user defined function which return tables (sql 2000) (view with parametars).
Should we use it Frans,
or we should buy your LLBLGEN Pro.

Crazy Chess Player

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 6:02 AM

Depends on what you want to do with the user defined functions. afaik, you can't call them from outside the db.

Frans Bouma

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 6:03 AM

::What about writing your business logic in a
::stored procedure?

Perfectly valid approach.

Just dont tell people then that you follow object oriented programming - you are simply not.

Thomas Tomiczek

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 6:21 AM

> afaik, you can't call them from outside the db.
I don't think so.
http://msdn.microsoft.com/msdnmag/issues/03/11/datapoints/

Crazy Chess Player

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 6:34 AM

Chess Player: I meant calling them as a stored proc directly using a Command object, afaik, you can't do that, it always requires a T-SQL statement which references the function (calling it). Of course you can call them embedded in an SQL statement, like the article shows. (the article is not that correct though, it says stored procedures are compiled and views aren't. Well, the code of a view is placed at the spot where the view is referenced. This means that a stored proc using a view contains in its execution plan the compiled code of the view. At least that's what BOL tells me.)

Frans Bouma

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 6:34 AM

>Perfectly valid approach.

>Just dont tell people then that you follow object oriented programming - you are simply not.

Sometimes, you have to make trade-offs between perfectly valid OO and performance.

Frederik Gheysels

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 6:43 AM

::Sometimes, you have to make trade-offs
::between perfectly valid OO and performance.

Yes, but these are fwwer than you think.

Becaue the one thing totally ignored so far is that a good OO DAL would introduce a nice little cachin opportiunity, too :-)

AND: the performance tradeoff is only a valid argument when necessary. Otherwise you just blow out the maintainiability of the app for a performance gain you dont use. BAD decision.

But sometimes, for certain simple procedures, it really is good to put them into an SP.

Thomas Tomiczek

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 6:55 AM

:Frans Bouma
:Posted @ 11/18/2003 2:20 PM
:Wallym: the dramatic performance boost is not
:there, because the stored procs are threated
:as queries which arrive at the sql engine:
:they are compiled at runtime.

Frans, I respectfully disagree. My experience has been that sprocs do provide a dramatic performance increase. The issue is when is this performance boost needed vs. ease of programming.

Thomas Tomiczek, you sound like a ranting child. I stand by my statements and the standards that I use.

Wally

Wallym

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 7:01 AM

"Sometimes, you have to make trade-offs between perfectly valid OO and performance."
Placing BL in de stored procs has nothing to do with OO or not, it has everything to do with separation of functional tiers. Moving BL into the procs is colliding everything together. This was done in the old days too, where queries were executed in a button handler. Worked faster, but was unmaintainable.

Frans Bouma

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 7:04 AM

"My experience has been that sprocs do provide a dramatic performance increase. The issue is when is this performance boost needed vs. ease of programming. "
While I most of the time agree with your opinions, I have to say this opinion of yours is just what it is: your opinion, not based on fact, just on personal experience. When I look at the theory behind the sql compiler in sqlserver, I can't conclude anything other than that a dyn. parametrized query and a stored proc run as fast, because both will use a cached execution plan. (yes, dyn. query has to be compiled first, so does the proc, which also will have to be recompiled if you're not careful (and the more code you add to make them flexible the more risk you take to cause a recompile of a stored proc on every occasion)

Frans Bouma

# Stored Procs or Dymanic SQL@ Wednesday, November 19, 2003 7:06 AM

So yesterday a debate surfaced that seemed to have the entire online programming community all worked up. Rob Howard, Microsoft ASP.NET Program Manager, posted to his blog about using stored procedures in SQL server. Many comments both for and against Rob's arguments in his post ensued. Things got a little heated when Frans Bouma stepped into the debate. Frans took his ideas to his own blog, and then you see the entire blogging community step in (via their own respective blogs) to add their own take on things. What a day.

TrackBack

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 7:41 AM

::Thomas Tomiczek, you sound like a ranting
::child. I stand by my statements and the
::standards that I use.

This is ok. It does not make your stnadards any moe meningfull, though. And this is what you should care about more, you know. Especially given the number of arguments you give in here.

@Frans:
::yes, dyn. query has to be compiled first, so
::does the proc, which also will have to be
::recompiled if you're not careful (and the
::more code you add to make them flexible the
::more risk you take to cause a recompile of a
::stored proc on every occasion

Even worse. You end up ith having a "with recompile" option on the SP pretty fast. Because all these neat tricks for handling variable numbers of parameters end up killing your performance. The cached plan will be the one selected by the first set of parameters discovered. All other requests goind in will reuse the compiled execution plan, whether this makes sense or not. This can only be avoided when you dont work with "dynamic numbers of parameters".

What I mean are sp's like this:

getUserData (fitlerName, filterCountry)

where both could be null. Depending on the selection you end up with either one or two or zero where conditions.

In a SP you can:
* Make a series of IF statements and HAVE threee statements. Efficient, but ugly as hell.

* Make one statement that uses conditions. Way less code and pretty nice - but basically the cached execution plan is determined by the first set of parameters.

Rsult: With option Recompile, and there you say then "whow, I did reuse plans", becuase you basically had to kill your performance gains.

Alternatives: three different SP's - not better than avariant one, and ugly as hell.

With dynamic SQL the SQL generator can handle this on the client side.

The main problem ith SP's here is that I know a lot of occasions where this dynamic thing turns around and bites you faster than you can say "I was an idiot programming this", and this is basically whenever you show a powerfull query form to the user. One where the user may be able to select multiple conditions. One like, btw, the "Advanced Find" in Outlook (on the Advanced tab, btw.). I would basically say it is nearly impossible to code someting like this in an efficient set of SP's on the database - the most efficient way to do this IS dynamic SQL, as the query is dynamic.

So, as a summary: SP's bite you when you go dynamic in the application. Now, it is up to you to decide to write applications that empower the user big enough that you realize you just got killed by sp's. Naturlly we all do this, right? We all make configurable software, using command patterns etc. Right?

Thomas Tomiczek

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 7:58 AM

>>yes, dyn. query has to be compiled first, so does the proc

What's the use of the 'WITH RECOMPILE' clause then the 'CREATE PROCEDURE' in Sql Server ?
I also thought that you could recompile a SP in Sql Server explicitly, so why would the SP be recompiled every time it's called?

/me needs to do some investigation on that subject.

Frederik Gheysels

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 8:05 AM

Frederik: WITH RECOMPILE means the proc will be recompiled no matter what on each access: (From BOL) "Creating a stored procedure that specifies the WITH RECOMPILE option in its definition indicates that SQL Server does not cache a plan for this stored procedure; the stored procedure is recompiled each time it is executed"

It can be better to signal sqlserver to not bother to cache the plan and to lookup the cached plan only to find out it has to recompile the procedure anyway. There are situations where a stored procedure will be recompiled anyway because of different codeblocks being executed, temp table usage in IF statements etc.

Frans Bouma

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 8:16 AM

You may call this "Product Pimping" (which it isn't, I can only point you to relevant technology based on the content of your posts when such exists), but if you want to back up your observations with empirical data (there are a number of critical variables that affect the claims that you are making either way). Stored Procedures and Dynamic SQL aren't mutually exclusive, they can actually be combined in appropriate situations. simply obtain the Open Source ODBC Benchmark Utility for ODBC or JDBC that we provide from http://www.openlinksw.com/download that pretty much covers all the relevant scenarios. If ODBC or JDBC are in the picture and escape syntax is understood and appreciated, then post utilization of the ODBC and JDBC bench tools you will see that Stored Procedures are a network optimization (reducing RPC count) primarily.

Kingsley Idehen

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 8:23 AM

What's so interesting of benchmarking something over ODBC? What's reality for ODBC doesn't have to be reality for native ADO.NET providers. Example: ADO over ODBC doesn't call sp_executeSQL per se when you execute a dynamic statement, SqlServer's client for ADO.NET does.

Frans Bouma

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 8:25 AM

Frans ,
You are right about calling
but you can wrap it in sp
and call sp :).
Another usefull article.
http://www.fawcette.com/vsm/2003_09/magazine/columns/databasedesign/default_pf.aspx

What is important for me :
1.don't use concat for making sql on client
2.there is not perf diff in using SP
and sql with params for SQL 7 >>
(you can see that if you compare Pet Shop .NET
last one is done without sql proc )
3.May benfit from OR maping tools is developer productivity ?
(Prove it! for example you can make
Database Layer
Pet Shop .NET with your tool)
and compare number of lines and developer effort.Like M$ has done against Java$.
4.Visual studio .Net is great tool not only
for .NET language but also for working with
MS SQL SP.
5.In my oppinion you must know database
(PL-SQL ,Transact SQL) if you are making
database aplication against Oracle or SQL
6.I did not use OR maping because
I know SQL very well, but if it can save me some time why not?

Crazy Chess Player

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 8:38 AM

ChessPlayer:
"1.don't use concat for making sql on client"
Of course not :) I use string builder objects and in some occasions String.Format() (which is also very efficient). I also use AppendFormat() to add as much text as possible in one go.

"3.May benfit from OR maping tools is developer productivity ?
(Prove it! for example you can make
Database Layer Pet Shop .NET with your tool)
and compare number of lines and developer effort.Like M$ has done against Java$."
It took me some time to get the correct petshop database model :) (MS' one is not that great). It's the plan do write teh petshop example, I hope to finish it soon.
"4.Visual studio .Net is great tool not only
for .NET language but also for working with
MS SQL SP."
You gotta be kidding :) Did you ever wrote a SP in vs.net and had a typo? :) "Error", err... yes, but where? :D

"5.In my oppinion you must know database
(PL-SQL ,Transact SQL) if you are making
database aplication against Oracle or SQL"
No. With an O/R mapper this is totally abstracted away. The only think that is very handy to have is a relation graph, thus which entities are related to which entities. But you can print that using enterprise manager.

Frans Bouma

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 8:58 AM

"4.Visual studio .Net is great tool not only
for .NET language but also for working with
MS SQL SP."
I even debug it in Visual studio .Net
5. I think your answer is main reason why
lot of database app fail.
one more link from oracle database guru
author of
"Expert One on One Oracle "
by Thomas Kyte (Author)
http://www.databasejournal.com/features/oracle/article.php/10893_1403591_2
I will quote him
"If you do not understand what your particular database does or how it does it, your application will fail. If you assume that because your application ran fine on SQL Server, it will necessarily run fine on Oracle then, again, your application is likely to fail."

Crazy Chess Player

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 9:05 AM

That quote is based on the assumption Oracle supports as much SQL-92 standard statements as SqlServer does (and vice versa). Both have proprietry statements to do stuff (8i can't join ANSI style, 8i/9i don't have FROM clauses in delete/update etc. (delete has 1 from, not 2)...). This obviously will make an app fail.

However I generate SQL on the fly using components that are specialized to do so per database. Thus 1 for sqlserver, one for oracle etc. The code targeting these objects is the SAME (which is the code a developer would write), the sql generated at runtime differs, because the engine used to generate it is different for oracle than for sqlserver. Using the same engine is indeed not handy. :)

Frans Bouma

# re: Roundtrips and the real bottlenecks@ Wednesday, November 19, 2003 9:05 AM

round trips and sql and optimal design:
IMHO....

any design that has the "model" of a conversation (talker,listener and so on)
can have this design issue and should be examined with the same basic logic, adpated to the details of what is implimented.
you can swap sql "round trip" issues with HTTP exchanges, trips in a car and other cases of data exchange.

it all comes back to :
1) how much traffic (total bytes,people,cars etc)
2) over what time range (clock cycles, minutes, days etc)
3) what is the "Latency" induced per trip
( time taken to get there and back + time spent on avg at "there" )

an example is some of the talk about how a "chatty" web service is often a poor design when running over http, to many small messages
sucking up time and bandwidth.

so if you are going to need one data item say per hour then the "tound trip" time is small and not critical.

but if you need say 50 data points every say 1/10'th of a second then fetching them one-at-a-time means that the latency will start to be larger than the actual data you get ....
so then it's time to move to a model where you get back a number of data points in a batch.

based on that plus the 3 items above I think one can start to build a general model for when to look at trip time as the issue to optimize Vs. time spent waiting at one end or the other for the data
0. the client
1. send request
2. server processing time
3. send reply
4. the client has data
if 0 and 4 are not significant issues then 1-3 each should be tested for how much they add to the total trip time.
make them each small and as close to the same as you can when trip time is a problem.

thats my view anyway.

denny

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 9:25 AM

Sorry but I agree with him.
One more quote:
"These may seem like surprisingly obvious statements, but in my experience, I have found that too many people approach the database as if it were a 'black box' — something that they don't need to know about. Maybe they have a SQL generator that will save them from the hardship of having to learn SQL. Maybe they figure they will just use it like a flat file and do 'keyed reads'. Whatever they figure, I can tell you that thinking along these lines is most certainly misguided; you simply cannot get away with not understanding the database. This chapter will discuss why you need to know about the database, specifically why you need to understand:"

Remerber EJB and all that object mapping staff
(Top Link)
for java and database.
Good Luck!!
But I don't belive in that:
"No. With an O/R mapper this is totally abstracted away. The only think that is very handy to have is a relation graph, thus which entities are related to which entities. But you can print that using enterprise manager."

Crazy Chess Player

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 9:34 AM

You don't believe me? That's fine. I don't see the point in learning SQL when you are not using it at all. The definitions (very important) of what people want are the same for every database. the SQL generated is different.

It's like claiming knowledge of MSIL is a must have to be able to write C# succesfully, or to understand how NTFS works to be able to use the I/O subsystem via System.IO.

Frans Bouma

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 10:07 AM

Don't be angry ;).
Let say it this way: Set of SQL generated by your tool is probably subset of what I already generated manually in my stored procedures or sql statements with parameters.
I bet that your tool would not solve some practical problem that I solved with sql.
If the developer uses your tool and does not know SQL in my opinion he ( or she) will sooner or later has unsolvable problem that require SQL.
In my opinion everything you can do in IL you can do in C#, which is not true for OR mapping tools.
C# = IL
SQL > LLBLGen Pro

Crazy Chess Player

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 10:14 AM

Well, for DML, not really. For special selects, I agree, you can never mimic RDBMS native functions well enough, however dyn sql engines can get very close. It depends on what you need and besides aggregates, you don't need a lot of specific SQL statements a lot in a *LOT* of situations. for the rare situation that you do, you can fall back on creating a view or indeed a stored proc, but these situations are rare.

Frans Bouma

# re: Roundtrips and the real bottlenecks@ Wednesday, November 19, 2003 10:28 AM

Hi Frans,

Typical, I'm away at a conference for one day and you start such an interesting discussion which I now enter so late.
:-)

I have to confess that I haven't had time to read up on all the comments from yesterday, so with the risk of repeating what have already been said, here's a couple of comments.

Something I'm worried about is to have long transactions and one way of shorten them, is to reduce the number of roundtrips within them.

Another thing is that I like to use stored procedures for persistence logic, especially the CUD part of CRUD. An example of this is if one class is split over several tables.

I guess the only answer here is as usual that "it depends". Words like "always" or "never" always - I mean often<g> - triggers an alarm with me.
:-)

Best Regards,
Jimmy
###

Jimmy Nilsson

# re: Stored procedures are bad, m'kay?@ Wednesday, November 19, 2003 11:00 AM

Be sure and read my replies after researching with the SQL team and several outside SQL exeperts:
http://weblogs.asp.net/rhoward/posts/38446.aspx

Rob Howard

# re: Roundtrips and the real bottlenecks@ Wednesday, November 19, 2003 11:12 AM

Hey Jimmy! :) (totally forgot to reply your mail, will do that a.s.a.p, tomorrow I think)

the CUD procs should be written by hand then, to have full control over how they're working, and when the schema changes, how to update them. Not a great solution, IMHO :)

Frans Bouma

# re: Roundtrips and the real bottlenecks@ Wednesday, November 19, 2003 11:17 AM

Or you could re-generate the sprocs after having changed the mapping information in some metadata.

Best Regards,
Jimmy
###

Jimmy Nilsson

# re: Roundtrips and the real bottlenecks@ Wednesday, November 19, 2003 11:22 AM

I agree with you.

That said, using an O/R mapper with just lazy loading seems to be the worst possible case for roundtrips...

peter

# re: Roundtrips and the real bottlenecks@ Wednesday, November 19, 2003 2:54 PM

There are some other reasons you would want to definitely minimize round-trips. It has to do with CPU load on the database server. The DB server is a shared resource(and a very precious one) so you definitely want to minimize the number of calls. Chatty DA layers can be a big drain on DB CPU during heavy load. In our system we have 1000's of concurrent users. We had to do a lot of optimizations to reduce DB roundtrips. For example, when there is a shift change, hundreds of call center reps sign on at the same time. This code path had to be tuned heavily to not pound the database. Much of the tuning involved pushing the data access code into stored procedures and getting much of it in one hit. Even though we returned the same data, we were able to cut CPU utilization by over half.

-Scott

sprughattelutiondotcom

Scott Prugh

# re: Stored procedures are bad, m'kay?@ Thursday, November 20, 2003 6:24 AM

Being quite fond of stored procedures myself, it's been a real treat to read this blog-entry and the following discussion to get some input.

I don't believe there is only one correct way to do things, nothing is just black or white. Different problems require different solutions, and only the specific scenario decides which is better: dynamic sql or stored procedures or perhaps a mix.

That said, I'll provide you (all) with a little more input to shoot at :-)

Firstly, why hasn't anybody produced comparative benchmarks? How can you argue that dynamic sql should be just as fast as stored procedures with no data to back it up - or the other way around for that matter. Books online is a great source for information, but is it absolute truth? (I won't either, btw)

Regarding the use for sprocs, it's true that if you don't write your stored procedures correctly, you may as well use dynamic sql statements. But I think this is because of a common misconception. Procedures are not a place to put business logic and as such there should be no need for conditionals, behavioural bits and the like, and therefore no need for recompilation. If you can't manage without them, your design must be wrong somehow. (Yes, I'm sure there are tons of counter-examples, but in general...)

As for O/R-mappers, my experience is that they're not very good at handling complex relationships, and if you have to write the code that generate the SQL yourself, you may as well put the statements as procedures in the database and write a wrapper (or use someone else's - ie. Microsoft.ApplicationBlocks.Data for .net). Oh, and you can use dynamic discovery of sp-parameters the same way you dynamically discover changes to a table.

In my opinion, the best argument against stored procedures is the "maintainability"-issue. 4+ sp pr. table/object and corresponding wrappers can get hairy to maintain and is a huge source of errors. However, the strength of the approach is that you can test the persistence part of the application systematically - this is a little tricky with generated code. If you find an error, replacement is a matter of rewriting (and testing!) a few lines of code. I guess testability and maintainability have some sort of trade-off relationship, that need to be taken into account when planning the project.

There, my 2 cents
Mikkel

Mikkel R

# re: Roundtrips and the real bottlenecks@ Thursday, November 20, 2003 2:23 PM

For those people who worries about the GUI being tightly coupled with the DAL layer, you can design your system to talk to another layer (DataProvider), whose job is only to batch the dynamic SQL and provide interfaces to the controls in the GUI layer. GUI -> (BAL) -> DataProvider -> DAL -> DB.

Rolly Ferolino

# Now this really bugs me...@ Saturday, November 22, 2003 1:16 AM

TrackBack

# Frans - u r so wrong@ Saturday, November 22, 2003 3:45 AM

sprocs are the way to go.

1. It is a packaging issue - I do not want my
sql code to be buried in all C# source files
all over.

2. I can test them and sql optimize them as batches.

3. Read up on the 'compilation' stuff - you have it wrong.

Plug - My tool (www.dbcodegen.com ) generates
generates C# bindings for sprocs as well.

Ricky

Ricky Datta

# re: Stored procedures are bad, m'kay?@ Saturday, November 22, 2003 7:25 AM

::1. It is a packaging issue - I do not want
::my sql code to be buried in all C# source
::files all over.

With all respect: if you are too stupid tp keep your SQL - even if you use handcoded dynamic SQL - in one place, you should not program but sell fries at burger king. SP's or not have NOTHING to do about keeping SQL in one place. Even SP's need to be called, and when you scatter these calls all over your code, your architecture is as rotten as the sample you gave.

You can ALSWAYS centralize this. SP or not.

::2. I can test them and sql optimize them as
::batches.

Yes, and you can do so all over the place over and over and over and over again, for multiple databases if you want to support more than SQL Server.

Sometimes this is needed. Normally it is the typr of timewaster that makes you loose your job as your company is not competitive enough.

the vast majority of db operations are simple and extremely boring. Linear CRUD operations. The majority of the rest are complex queries. In both cases, SP's dont gain too much.

Unless you start moving business logic INTO the database. THEN you can gain tremendously in some scenarios, but this is an architecutral decision. Just say goodbye to OO.

::In my opinion, the best argument against
::stored procedures is the "maintainability"-
::issue. 4+ sp pr. table/object and
::corresponding wrappers can get hairy to
::maintain and is a huge source of errors.

Absolutly.

::However, the strength of the approach is
::that you can test the persistence part of
::the application systematically - this is a
::little tricky with generated code.

No, it is simply not necessary in generated code. The code generator will not emit buggy code. Period. A good one will even validate that the generated code is working (I work on something like this for our EntityBroker O/R mapper right now - it will go through the database and make sureit's metadata is correct).

So, there simply is way less need to validate anything.

Naturally this is only the case when you get this layer automated, not when you belong to the vast amount of people considering it smart to handlcode the same reetitive routine over and over and over again.

Thomas Tomiczek

# re: Stored procedures are bad, m'kay?@ Saturday, November 22, 2003 11:50 AM

The too-many-cooks argument against sprocs was valid at one time, but code generation now negates it for most cases.

I use CodeSmith to generate sprocs and DAL classes against tables and it not only makes the job cake, it makes coding against the tables (via the classes) trivial. I shaved at least a week worth of manual code on my last project this way. It took all of two minutes to adjust the templates on this page to suit my needs (to use the connection defined in web.config): http://www.ericjsmith.net/codesmith/forum/?f=9&m=402

The DBA needs to change the structure? Regenerate the sprocs and code, recompile the classes in the DAL namespace. Done. The only code that needs to be touched is code that needs to change anyway. But now all my DAL interfaces are consistent, easy to work with, and provide more functionality than if I had to hand-code each.

Code generation against individual tables means that I use additional queries to translate ID codes into English onscreen (or to do .resx lookups for other languages) -- usually these are the same datasets used for the dropdown lists themselves. And these can all be cached. So I get the advantage of both fewer and leaner queries hitting SQL Server for both my dynamic and static data. The translation happens at the UI layer where it belongs.

I still generate a few specialized relational queries on the fly for certain reports. There will always be exceptions, they can't be avoided. But this approach saves me time in all the usual cases, cutting the time I spend writing repetitive code down to nearly nil.

As for performance, sprocs are faster. I've done time trials. Have you?

Take care,
Eli.

Eli Robillard

# re: Roundtrips and the real bottlenecks@ Saturday, November 22, 2003 12:10 PM

> when for example a webform requests 3 or 4
> batches of data to build the webform's
> content, are these requests bundled into 1
> call?

No, but they should certainly be cached, preventing unnecessary roundtrips. Reasonable use of caches for lookup data seems to make the "Ah, you can't?" paragraph irrelevant.

I'm curious where you recommend lookup data be retrieved -- in chunkier queries or in multiple queries? You seem to be suggesting multiple queries (i.e. keep 'em separate from the DAL) but aren't you caching this data? Why suggest that people accept these round trips as a compromise?

Another question: How many BLObs do you store in databases? Perhaps your needs are different from mine, but whenever possible I (and I thought most folks) keep graphics and OLE-ish objects out of the db and instead store links to the file system; the FS is designed for variable-length data, databases do better with fixed-lengths. Just curious.

Thanks for stirring the pot, it's always healthy to question the standard answers.

Take care,
Eli.

Eli Robillard

# re: Roundtrips and the real bottlenecks@ Saturday, November 22, 2003 12:24 PM

I retrieve lookup data which is not changing a lot at application startup and cache it, in for example the Application object in ASP.NET

Blob retrieval from a db is not slower than from a FS, in fact, the FS in a database is perhaps faster, because it is optimized for data-retrieval. Having blobs in the database can be handy because they get backupped in one go with the database. Also, when you store links to a file instead of the file, the file can be removed/renamed, without violating a constraint. This can hurt your application.

Frans Bouma

# re: Stored procedures are bad, m'kay?@ Saturday, November 22, 2003 12:30 PM

"3. Read up on the 'compilation' stuff - you have it wrong."
Which part of "Quote" do you not understand? I quoted the part from the BOL. If you think that text is wrong, BOL is wrong, not me.

"As for performance, sprocs are faster. I've done time trials. Have you? "
Yes I have, see the links at the top. SProcs are slower in fact in my tests.

However 'in my tests, ABC is faster' is bogus to me when there is no explanation given. BOL tells me SProcs and dyn. queries are not treated differently. Therefore one should be as fast as the other. You may think sprocs are faster, if you can't give a theoretic explanation that is TRUE, don't bother claiming they're faster.

Code generation for stored procs is ok, but then also maintenance sucks: you end up with a lot of procs and when the schema changes, which one to remove? All of them? None? Trust me, with LLBLGen 1.x, which generates procs and classes way before Eric Smith thought it was a good idea, I've learned this the hard way: a hell of a lot of procs, all nice, but unmaintainable.

Frans Bouma

# re: VB.NET developers, continued@ Saturday, November 22, 2003 5:39 PM

Can't post to paul's site as it is broken, so I will post here ;-)

If C# has the menu why not VB - Consistency

Keep Refactoring - That is what it is and thats what we VB developers call it!

Why should "professional" VB developers get any less/different IDE features than C# (and visa-versa ;-)

Are we going to become/thought of as 2nd class citizens again.

Is this all related to the efforts to make VB easier for the "occupational programmer"
http://www.fawcette.com/vsm/2003_12/online/meader/default_pf.aspx
<snip>
Ari Bixhorn: People call these programmers different things, from hobbyist programmers to non-professional programmers, but I think
occupational programmer describes this class of person more accurately. For example, think of the accountant who needs to use a little bit of VB to build a front end to an Access database. We're doing a lot of work in this area in VS.NET, but particularly in VB.NET. What we want to do is put the magic back into the product, to satisfy the needs of all the different developer communities.
<snip>
One step forward, one step back

Check out http://www.xtreme-simplicity.net/
PS The VB message has been there for a lonnnng time ;-(

ChrisL

# Does an OR Mapper need to use dynamic sql? @ Sunday, November 23, 2003 8:20 PM

TrackBack

# Dynamic Queries vs. Stored Procedures@ Monday, November 24, 2003 9:58 AM

TrackBack

# re: Stored procedures are bad, m'kay?@ Tuesday, December 02, 2003 7:23 PM

Yet another religious war:( I'm sick of it!

Don't you guys get it? I'm sure you won't until you read a book like "The design and evolution of C++". You can't just say "Sprocs SUCK, long live SQL" (a guy actually said that:). You can't also just say "SQL sucks, long live sprocs!". It's all about using the one or the other when it is most suitable. If Bjarne had the "C sucks, long live Simula" mindset, C++ would NEVER be the MOST successful language! You want lean and mean near-the-iron code -- use the C subset of C++. Should you want to build an enormous higher level solution FASTER than using plain "old":) C, use the OO features of C++. You want to update 10 tables with one network trip -- use sprocs. You want to build a generic O/R mapper because you're reimplementing it ALWAYS anyway -- use dynamic SQL. What the @#$% is the problem with you guys, huh?

P.S. To calm you down a bit:
I like sprocs, and I like dynamic SQL. I hate sprocs and I hate dynamic SQL. In fact, I hate doing any DB-related work so don't sue me:)

P.S. to the O/R mappers guys here: Don't try to advertise your O/R mappers in such a stupid way:)

Cheers,
Stoyan

Stoyan Damov

# re: Stored procedures are bad, m'kay?@ Wednesday, December 03, 2003 1:45 AM

This one is for the sproc guys:

Are you ALWAYS the one deciding which database will be used? Isn't that again your company and your client's company politics? If the customer chooses MySQL (or Access) exactly what kind of sproc will you write?

This is for the O/R mapper guys:

Excuse me guys, but your O/R mappers can serve a maximum of 70% of the line-of-business applications that need to be build. I know it's OK for your companies and you could live with that, but the rest of us are building applications that are orders of magnitude more complex than Northwind & pubs, and more often than not, a generic solution is not a solution at all.

What happens if your O/R mapper should support Access, SQL Server and Oracle? I'd rather use/invent a pattern which allows me to write specific code for each DB (but to have the same code in the BL) than use a generic solution. For example, if I have to insert N rows in a single query, I'd use Oracle's arrays, SQL Server's XML support and a good old "for" loop for Access. What about that? What about if I have to cache data? What about if I have to perform virtual locks on the data (even with the disconnected ADO.NET)?

Cheers,
Stoyan

Stoyan Damov

# re: Stored procedures are bad, m'kay?@ Wednesday, December 03, 2003 2:43 PM

Wow, the more I read about this... the more I just want to use object serialization and keep my data with my object and forgo the db altogether... ;)

@Stoyan: Agreed, use of SPROCs or DynSQL really depends on the situation at hand.

Bill Priess

# re: Is it still allowed to have critisizm on Microsoft here?@ Saturday, December 06, 2003 9:40 AM

Hi Frans,

exactly my feelings and that is why I moved my blog (http://weblogs.asp.net/mspedding) to http://www.mjs-solutions.com/mjsthoughts

Also I wanted to have freedom to be able to express my thoughts and provide constructive criticism as well as to write about other subjects.

I think you will not be the last to move. Sadly it is possible that weblogs.asp.net will simply become blogs.gotdotnet.com

Martin

Martin Spedding

# re: Is it still allowed to have critisizm on Microsoft here?@ Saturday, December 06, 2003 9:49 AM

Company A, company B who cares...? Microsoft sux Linux rules or was it the other way around ;) I don’t see why (considering you have valid arguments) posting something anti-Microsoft wouldn’t get accepted in this community. The flipside is we receive good .NET related information from these guys and that is exactly the target Scott is aiming for.

Paul Gielens

# re: Is it still allowed to have critcism on Microsoft here?@ Saturday, December 06, 2003 9:59 AM

Paul, it's not that MS guys shouldn't be here, it's that with all the blog material expressed HERE, it looks like there are only positive things to blog about, when it comes to Microsoft's material. I don't think it is appropriate to babble about something that's not so good when the rest is just venting what corporate policies dictate them. (look at the recent new postings... sign up for Microsoft seminar bla etc..)

Frans Bouma

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 10:06 AM

I forgot to mention I normally skip the main feed to dis lead my eyes from the pro-Microsoft, Interscape Technologies etc writings.

Paul Gielens

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 10:08 AM

I will repeat what I said elsewhere. This was always a Microsoft site. If you don't like it, set up your own. I think it's good for Microsoft people to be here, as it increases the content and number of knowledgable people here.

And more good content means more people reading. And re the Microsoft criticism, even Scoble criticises Microsoft and he works there!

Just FYI

Registrant:
Microsoft Corporation (ASP67-DOM)
One Microsoft Way
Redmond, WA 98052-6399
US

Domain Name: ASP.NET

Administrative Contact:
Gudmundson, Carolyn (GPIIZCVTVI) domains@microsoft.com
One Microsoft Way
Redmond, WA 98052
US
(425) 882-8080 fax: (425) 936-7329
Technical Contact:
MICROSOFT CORPORATION (EPMKOEAUSO) msnhst@MICROSOFT.COM
One Microsoft Way
Redmond, WA 98052
US
425 882 8080 fax: 206 703 2641

What's new?

matthew

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 10:14 AM

Matthew, my blog was here when scott's site was elsewere. Then we migrated to asp.net, something that gave me mixed feelings, but alas.. Now this.

What scoble does, is his choice. I simply don't feel comfortable that I criticize the host of the criticism.

There is a lot of heat and tough debates ahead of us, especially in O/R mapper land related to Objectspaces and MS attempt to kill all O/R mapper vendors. It's sad that this cool blogspace is now also the heart of MS' own blogging: it's like preaching about some christian god in a synagoge.

Frans Bouma

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 10:14 AM

I see no censorship here. On the contrary, I see reasoned criticism all the time, just not obvious anti MS zealotry, although the only prohibition against that is that this sights charter is about .Net, so it might be off topic. If you decide that you want to blog on more personal topics, than you should probably move ... if you want to conduct educated discussion, including criticism, of .Net related topics (and endure occassional and annoying plugs for interscape) then stick around. THIS IS where that criticism will be seen and read by the right folks ....

Brad More

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 10:29 AM

I've never once seen any attempt by MS to censure criticism or debate -- if anything I've seen the exact opposite. I've had opportunities to take the "red pill" and join MS -- and I've clearly stated some anti-MS things in my interviews and dealings with MS. I would move my blog in a second if I wanted to be seen as a Linux/Java developer, but I am mostly a MS developer, so it makes perfect sense to be part of their community. But that doesn't mean I always agree with them, nor do I always state the party line. On the contrary, you're criticisms of MS will be even more read by the right people if you stay here, so please do NOT move.

Paul Wilson

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 10:34 AM

So you'd rather move of to a less popular location with less MSFT employees around to read your views on their products? To me that calls into question your motivation for writing as critically as you do. Do you complain because you want things to improve or do just complain for complaining's sake?

If you want things to improve you probably know as well as I do that proximity is a very important factor in being heard, which is the first step to things actually changing. By blogging on the same website as many MSFT employees you greatly increase your chances of being heard and things actually changing for the better, so why move?

Furthermore I'd expect most MSFT employees are used to be being critized by now and, in general, respond to it very well. I expect one of the main reasons you were let in to the Whidbey early-access program is because you were so very critical of VS.NET or am I mistaken?

Paul Looijmans

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 10:52 AM

(geezz, 3 Pauls ;))
Paul W.: I understand that criticism ventilated on a MS site will be read by more people than when I do that on say dotnetjunkies.com. The thing is: do the postings fit into what's said on the site? With 99% hail and praise postings on weblogs.asp.net, they won't.

Paul L.: I don't care if the site my blogs are on is 'the most popular', so having a blog here makes me part of some 'inner circle'. I also don't 'complain', there is a difference between complaining and having criticism.

I can tell you that within a few weeks I'll probably blog about MS' anticompetitive actions towards O/R mapper vendors. I'm talking about that kind of criticism, stuff that really hurts MS' product sales. Will that be tolerated here, or will that be appropriate? It's .NET related. But it's not that appropriate on a site where the vast majority of blogs are pro-microsoft, at least that's how I feel about it.

I don't think I was let into the whidbey early access program because I criticize, but because I have arguments for criticism. Valid arguments. That's a different thing. It's easy to say something sux. It's hard to tell another person why.

Frans Bouma

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 11:00 AM

Yep, this site should be Weblogs@Microsoft.Net. I don't think I like this feed much anymore. That's why I tend to read weblogs@DotNetJunkies.Com. It's not commercialized, and I find that if there is an article of interest over here, then someone at DotNetJunkies will link to it. I do respect, and like to hear what MS Employees have to say, but it is just covers to many spectrums from Outlook to Longhorn to...

Jim Martin

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 11:17 AM

"there is a difference between complaining and having criticism"

Very true! So what do you want to do: sit in a corner somewhere where nobody hears you and complain, or do you want to be in (what appears to be) the center of the Microsoft blogging universe and direct your critical remarks at the people that can actually change the things you're critical about?

It's not about being popular or being part of an 'inner circle', it about being heard, it's about not running away from a discussion!

Paul Looijmans aka the third Paul

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 11:24 AM

Jim, my thoughts exactly.

Paul III :) That's also a good point, that's why I'm not certain what to do: move or stay.

Frans Bouma

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 11:28 AM

I say criticize all you want.

Raymond Chen

# Moving?@ Saturday, December 06, 2003 11:39 AM

I have the same feeling, Frans. First we moved to http://weblogs.asp.net then it becomes the home for Microsoft employees. This is all justified, but...

It's not a problem about criticizing or not. It's a problem of image. I don't want to be assimilated to someone doing propaganda for Microsoft. From a visitor point of view, I guess weblogs.asp.net has just become too much Microsoft to be in sync with the image we had when it all started at dotnetweblogs.com. weblogs.asp.net is now too tied to Microsoft to sound free.

Maybe the community is shifting, and maybe the dotnetjunkies weblogs look more like what I want. I'll take a look at that.

Fabrice

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 11:40 AM

Frans,

I hope that you'll stay. I enjoy your posts. I you have something to say, say it. Maybe that is how we'll get some lively discussions going with the MS people. I like the idea of them being involved, and I have to believe that the opinions of others should interest them, otherwise whats the point?

Regards,
Paul Speranza

Paul Speranza

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 11:49 AM

Frans,

I agree with Paul. I hope you stay as well. I certainly have felt free to say things that do not follow the MS company line, though certainly the fact that I sgree with what MS says more than I disagree, but I have no concern about being censored in any way. I expect this main weblogs.asp.net feed is lots more popular with folks than any individual feed is likely to be, and I certainly agree you have things to say that I like to hear.

Douglas Reilly

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 11:50 AM

Why don't you like weblogs.asp.net?
This blog dedicated to asp.net and related
and if you have what to say negative on
THIS topic you're welcome...
How I can understand it's official microsoft
politic for now(Longhorn was released solely
for developer feedback for example) so
participate in discussion and blog in other
place about other themes no hesitate.
And of course I'm greatly apprecate MS developers attention on this subject without dubt.
What's the problem mate?

Andrew

# not ASP.NET@ Saturday, December 06, 2003 11:58 AM

Andrew just showed what's wrong. These weblogs were not revolving around ASP.NET and Microsoft only in the first place.

Fabrice

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 12:01 PM

Look at it another way - any criticisms, etc will get to MS real fast as they would be reading this directly! No sales & user support layers here.. :-)

SBC

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 12:02 PM

Exactly! Change the name, break it into categories, that way if a person wants to read the Microsoft Employee Blog then they can subscribe to the Microsoft Employee Blog feed.

Jim Martin

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 12:10 PM

My personal feeling is that you will not have a problem of content as the additions will raise the bar (in a good way) on productive discussions. I think the thing to worry about is content overload. That's why I think Frans' original idea of feed groupings is interesting. A group could be based on an entire blog being in one category (and I think the blogger could choose which one they fit into) or back to the oft-discussed idea of common post categories. Now defining those categories will be a challenge! "MS Bloggers" "ASP.NET Bloggers" "Jack of All Trade Bloggers" "Genius at Work Bloggers" ".NET Novice Bloggers" or even one for people like me "Bloghorrea Bloggers". :-)

julie lerman

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 12:30 PM

Please reread "How to Hate Microsoft."

We're very open to criticism. Now that Microsoft employees are here, I say it's even more open.

http://longhornblogs.com/scobleizer/posts/345.aspx

Robert Scoble

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 12:45 PM

I quote...

"If a tree falls in the woods and no-one is around to hear it, does it make a sound?"

If you run off to some corner of the web, and critisize where no one can see you..well then whats the point?

Stay here, yell and scream and you KNOW you will get some sort of response. Justify your critisizms and back it up with something intelligent and you just never know....

If the 20+ comments above, alone, didnt convince you that your thoughts are being heard every day (and are valued), then I guess you might as well just slink away. ;)

Rob Chartier

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 12:56 PM

I have a weblog here just to talk .NET, not about Microsoft.
However, if I have criticism towards Microsoft (which is healthy for any company), I think they should hear what I have to say.

And a note about the main feed - I never go there, it's just full of people talking about things that aren't really related to .NET. If I find a link to an interesting blog, I read it. If I want to read a blog, I subscribe to it.

Omer van Kloeten

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 1:02 PM

whoops - I was referring to Steve Eichert's suggestion (http://dotnetjunkies.com/WebLog/seichert/posts/4285.aspx) to which ScottW (over there) responded that categorized feeds are on their way...

julie lerman

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 2:30 PM

stop being a little baby!

criticize all you want

Nick Burns

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 2:55 PM

I don't have a blog here but am subscribed to many of the feeds and read the main feed often to see what I may be missing. I love the varying opinions from all of you and I'm not concerned that the MS crew is going to distort that. It's great to see the interaction between the people building the product and those using it.

Regarding MS taking over the O/R world, you should only be concerned if their product is better than yours. Sure, many people will use it as a default because they can easily find it, but others, like me, will do our research and pick a product that best fits our needs. Products like yours are certainly in need so I can understand why MS is building one. By the way, despite all the hype surrounding ObjectSpaces, I recently bought your product and it's working great for me.

Kevin McCallum

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 3:54 PM

::Regarding MS taking over the O/R world, you
::should only be concerned if their product is
::better than yours.

Ah, oignoring reality here?

When:
* MS comes out with a free sponsored O/R mapper (which, btw., CAN be seen as illegal in a lot of countries)
* Bundles this into the core .NET SDK installer

Then there is no reason to be concerned? You should make a reality check on how people think.

* Most people wont spend on a commercial O/R mapper even if it is better.
* There are certain disadvantages a commercial O/R mapper has to overcome (mostly when hunting for hosted environments) due to the fact of not being installed on the server.

::Products like yours are certainly in need so
::I can understand why MS is building one.

Me too. Well, I would understand if MS actually WOULD build a PRODUCT. You may want to look up the definition of "Product" in this regard. Simply extending functionality and givint all existing companies a competitive disadvantage is NOT "fair play".

I can definitly see where Frans is heading - being in the same situation. Our company is also looking into the situation right now, and some of the issues we are discussing here would not make MS happy.

Frans' concerns regarding the situation of this blog is actually very interesting - I have been (and am) daily here, but, I dont really read too many postings here in detail - there is way too much blatant advertising here now.

Thomas Tomiczek

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 4:15 PM

Frans, I don't understand why you would want to move. I've read what you posted but I don't buy it. You don't seem like the type to hide like that. Why would you want to move away from the target of your criticisms? If MS is your target, you should fire as close to them as possible. There is no better place to put your soapbox than right here where it has been for months.
If you are planning on lying about MS, then maybe you should move. If not, then you shouldn't have any worries. If you point out something bad someone did, it isn't your fault for saying it, it is their fault for doing it.
Also, the chances that you will gain insite on the facts is much higher here than whatever other corner you would move off to hide in.

Shannon J Hager

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 4:21 PM

I can't believe the FUD and general gross inaccuracies in Tomiczek's comment.

Since when is extending a product and giving the enhancements to customers illegal? When it's your product that the enhancement is replacing, right.

Extending functionality for a given product and giving it to customers *when they own a valid license for the same product* is not considered fair play? Let's drag out the "it's not fair!" argument, again only because it's our product that is losing market share. That's a weak argument that has been repeatedly thrown out in court, although if you asked an attorney to take your case he would tell you it was a great argument and then ask to be paid in advance (not on contingency of you winning).

Competitive advantages and disadvantages are the results of competing well in the marketplace. Don't cry just because Microsoft decided to move into what you claim is your product space. MS added CD-burning support to Windows XP, that's more of a new piece of software than an extension of the operating system, and it's totally legit and you don't even mind do you?

Darrell

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 4:32 PM

Darrell, it's no FUD, he's right.

Objectspaces is part of the problem. It's also the free tool MS gives to developers to create the mappings. This way, a lot of potential O/R mapper customers do not have to buy such a tool. This will make a lot of O/R mapper vendors go out of business.

When they do that, and they will because the market all those O/R mapper vendors are targeting is dramatically decreasing, MS has what it wants: people use Objectspaces, there are no real competing products, and they can sell MBF, which is the true cash cow for MS in the coming years.

If you want to know, Darrell, we're currently talking to lawyers because of this, simply because what MS will do with Objectspaces is illegal in Europe, plain and simple.

It would be a TOTAL different ballgame if MS would SELL a competing product, because then they would play fair. Now they will not, they will give away a tool that is on every developers harddisk when they install .NET sdk or visual studio.net. How are O/R vendors able to compete with that?

Frans Bouma

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 5:00 PM

http://weblogs.asp.net/tmarman/posts/41748.aspx

Tim Marman

# re: Is it still allowed to have criticism on Microsoft here?@ Saturday, December 06, 2003 5:06 PM

I see Frans' point here about the tool being part of VS. I understand that things like this do put developers out of work.

But isn't this the natural progression of anything? Once a concept gains popularity people starting asking companies to include it in their products.

Didn't Sheridan give us the first set of 3D widgets, then they became standard in VB. How about all of the tools Borland puts in their enterprise versions?

What about opensource? Look what they and Sun are doing with the Office products.

What I don't want is any government telling a vendor what they can give away for free with their products.

Now product developers can try to innovate all they want but like a previous poster said, if the MS version does most of what we need, will we be willing to shell out money for the extras?

That is the paradox.

Paul Speranza

# re: Is it still allowed to have criticism on Microsoft here?@ Sunday, December 07, 2003 3:36 AM

::That is the paradox.

It is not a paradox.

Destroying product markets is simply one thing: illegal. There are laws about it.

Open source is fine - when noone involved gets paid. But when a company puts up money to develop and then gives it away for free, there are laws for handling this.

Thomas Tomiczek

# re: Is it still allowed to have criticism on Microsoft here?@ Sunday, December 07, 2003 4:40 AM

> But isn't this the natural progression of anything? Once a concept gains popularity people starting asking companies to include it in their products.

Big chance this is MS's main line of defense in court. Personally I don't think the OR-mapper tool suppliers have a case here... MS is just filling up the gaps in a product (which isn't actually a product) they gave away for free from the start. Why would they change their business model, just because the world surrounding them is changing? That makes no sense at all. It's their technology, tool/product suppliers just hop along on the success trip exposing themselves to these vulnerabilities.

Paul Gielens

# re: Is it still allowed to have criticism on Microsoft here?@ Sunday, December 07, 2003 6:28 AM

That line of defense hasn't brought them anything in the Netscape case and will not bring them anything in the Mediaplayer case in Europe.

The problem is not that MS includes a given technology in a framework. The problem is that MS includes a TOOL into the framework and lacks to produce a foundation for these tools in the framework. MS should have build an EJB equivalent in .NET so each and every O/R mapper vendor could have build his tool on that foundation. Now that foundation isn't there, worse, a competing tool is delivered, and even worse: it's free.

Now, the free pricetag, the extremely large marketing power of MS (it's hyping the stuff already, 1 year before release), the availability of the tool on every harddisk of each .net developer... a situation you can't compete with.

Paul G.: you remember the KNP lawsuit with the free internet for schools and why they lost? They lost because they delivered something for free that costs them money. MS puts a lot of money in Objectspaces and the free tools. To win over developers for Objectspaces so they know it thouroughly and will look further towards MBF. A simple scam, yet very harmful for the .NET community, because MS has now shown they will change .NET to make it sell their own products, not just to bring a good foundation for developers.

Frans Bouma

# re: Is it still allowed to have criticism on Microsoft here?@ Sunday, December 07, 2003 7:26 AM

Frans,

Please stay. Sometimes your posts infuriate me. And therein lies their value. That which infuriates me makes me think, and your presence makes the feed more balanced and therefore more useful, IMO.

If the proprietor starts to censor you, by all means move, OTOH, please don't effectively censor yourself by removing yourself from a feed where people who aren't looking for you will find your thought-provoking posts, to a new location where only those already looking for you will find you.

Mike Blumenthal

# re: Is it still allowed to have criticism on Microsoft here?@ Sunday, December 07, 2003 9:41 AM

I see your point Frans, but one thing isn't clear to me.
You state that they haven't created a foundation for these tools in the framework, but isn't that the System.Data.ObjectSpaces assembly?

Greetz,
-- Rob.

Rob Tillie

# re: Is it still allowed to have criticism on Microsoft here?@ Sunday, December 07, 2003 9:48 AM

Rob: no, EJB is something complete different. EJB is a framework which can be used as a base for O/R mappers, and thus for objectspaces, a generic framework, not something just focussing on O/R mapping and inside that just focussing on Oracle. If they had done that, OTHER people could have added for example oracle support to that framework. Now this is not possible.

Frans Bouma

# re: Is it still allowed to have criticism on Microsoft here?@ Sunday, December 07, 2003 12:04 PM

Frans: I didn't know it was only focused on Sql Server. Then it's indeed a shame...
To come back on your original point, about leaving this blogscene: if you would have left, this large discussion wouldn't have occured, because the amount of people reading it wouldn't be so high, and I think this is a good place to have such a discussion.
I can imagine how you're feeling by being pushed out of the market, but I would advise you to let it sink in for a couple of weeks...

Greetz and good luck with it,
-- Rob.

Rob Tillie

# re: Is it still allowed to have criticism on Microsoft here?@ Sunday, December 07, 2003 12:25 PM

Am I the only one that reads blogs via an RSS reader?

Once I've subbed, I don't know or care where a blog is hosted, I'm just reading the content.

I think the only reason to move is if the site host censors you or gives you other difficulties, which doesn't seem to be the case.

Robert Brown

# re: Is it still allowed to have criticism on Microsoft here?@ Sunday, December 07, 2003 2:49 PM

http://weblogs.asp.net/tmeston/posts/41868.aspx

Tosh Meston

# re: Is it still allowed to have criticism on Microsoft here?@ Sunday, December 07, 2003 2:49 PM

Frans,

Remember what happened to Don Box. If you can't beat them, then join them.
Don said, he had to think about his pension. ;)

But I'm afraid that all big companies will keep on filling the gaps all the time. Yukon is another gap being filled, and I'm sure you can name some other already filled gaps.

Kris

# re: Summary of reactions on my blog yesterday@ Sunday, December 07, 2003 3:14 PM

Frans,

I'm glad to see that you are going to give this blog a chance for a while. Alot of us will be paying attention to your posts, so fire away. We'll soon see if its ok to tell the emperor he has no clothes.

Regards,
Paul Speranza

Paul Speranza

# re: Is it still allowed to have criticism on Microsoft here?@ Sunday, December 07, 2003 3:50 PM

Frans,

I don't think that ObjectSpaces is going to knock anyone out of any market. Crystal Reports, at least a 'lite' version, is bundled with Visual Studio and yet there is still a market for Reporting tools. Why? Crystal Reports doesn't quite cut the mustard in some ways. Same with the DataGrid. There is still a market for controls like the DataGrid simply because the DataGrid is kind of like the banjo playing boy on the porch in deliverance. It's just not quite right.

Given what I've seen of ObjectSpaces so far, as well as the Data Factory objects in .NET 2.0. I 'm 90% sure that there will still be a market for non-MS O/R mapping tools and DALs after .NET 2.0 comes out.

Scott

# re: Serious ASP.NET Editor flaw lives on in VS.NET 2003@ Sunday, December 07, 2003 4:32 PM

I've been doing web design in asp for nearly 3 years and I'm now migrating to asp.net. All I can say is that this bug shows how pathetic microsoft's visual studio design team is and its OBVIOUS none of them have ever done any real web dev in their careers. I also dont know how a bug like this could get past the testing level unless it was completely ignored for reasons stated by Mike Moore in his letter. This bug is seriously so annoying it makes me want to stab out my eyeballs with a rusty spoon. It makes the design view completely useless for everyone but newbies who create their high school web project from an oreilly asp.net book.

matt

# re: Summary of reactions on my blog yesterday@ Sunday, December 07, 2003 7:59 PM

Glad you're staying -- let those Microsofties be damned. :)

Paul Wilson

# re: Is it still allowed to have criticism on Microsoft here?@ Sunday, December 07, 2003 8:54 PM

"Objectspaces is illegal in Europe, plain and simple." It's not illegal until proved in court. You may think it is illegal, and that's fine. I may think it is legal, and that is fine as well. We'll all see what the court says.

I am not condoning anti-competitive practices. But I also do not want to see statements such as "Objectspaces is illegal" stated as truth when in fact nobody knows yet.

Darrell

# re: Is it still allowed to have criticism on Microsoft here?@ Monday, December 08, 2003 2:33 AM

How about WebMatrix, also a free tool which MS supplied? Do you think that's unfair as well?

Peter

# re: Is it still allowed to have criticism on Microsoft here?@ Monday, December 08, 2003 2:33 AM

FWIW: stay and write here. your posts make this place better.

Roy Osherove

# re: Is it still allowed to have criticism on Microsoft here?@ Monday, December 08, 2003 4:34 AM

Andrew says "How I can understand it's official microsoft politic for now(Longhorn was released solely
for developer feedback for example)"

Wrong. They make you feel you are part of the making of the product, and that's part of the marketing initiative. That's so obviously a way to monetize communities and make each of those members act as evangelists that I can hardly think you don't get it, do you?

Stephane Rodriguez

# re: Summary of reactions on my blog yesterday@ Monday, December 08, 2003 8:38 AM

Keep on blogging and expressing your mind freely, that's what the BLOG is. :)

SpiderMan

# re: Is it still allowed to have criticism on Microsoft here?@ Monday, December 08, 2003 9:52 AM

Regarding contributions to a MS-centric weblog, I wonder whether it makes sense at all anyway.

If you provide good remarks, feature wishes with a very customer-centric eye and anything else that helps them build and sell better products, then you are basically doing the job of an employee without getting paid.

In the real world, no one works for free. Since work must be paid, and it isn't what's currently being done through weblogs.asp.net, I don't see any point in contributing at all, anyway.

Alternatively, someone not from MS may wish to contribute a MS blog site to tease or impress. I think it's a valid scenario for a lot of people out there who would do that as a matter of getting a job. That being said, I don't think that's the best way to succeed. Quite the contrary, people spending their time on weblogs are people not designing products. Someone would impress them much more with well designed products.

My 0.5 cent

Stephane Rodriguez

# re: Is it still allowed to have criticism on Microsoft here?@ Monday, December 08, 2003 2:59 PM

Hi Stephane,

I see your point, but blogs aren't always about product feedback ;). I like to talk about software development in general, so I hope someone will learn something from my texts. I agree that giving excessive feedback about all kinds of products to MS is indeed non-payed testing. But people are greedy, so a free longhorn cd is seen as a gift, I don't think that will ever change ;)

Frans Bouma

# re: Is it still allowed to have criticism on Microsoft here?@ Tuesday, December 09, 2003 5:57 AM

Good. Leave. Goodbye!

Eric Hill

# re: Children...@ Tuesday, December 09, 2003 2:55 PM

Frans, you shouldn't censor yourself! You have a right to your opinion way better than many of the pro-MS / pro-Open Source sheep you see around the place. If you have an opinion and are prepared to defend it, more power to you!

Scott Galloway

# re: Children...@ Tuesday, December 09, 2003 3:02 PM

Yeah well, deleting some flame / troll every half hour or getting mail from people who ask me why I flamed them on their blog while I never ever read that blog in the first place gets annoying after a while.

It definitely beated the fun out of blogging for me for today and maybe also for a lot of days to come.

Frans Bouma

# re: Children...@ Tuesday, December 09, 2003 3:05 PM

Sorry about us children. :)

Frans Bouma

# re: Children...@ Tuesday, December 09, 2003 3:07 PM

Just for the record - that SUCKS! I work for Microsoft and I think you raised a valid concern on your part. I personally think you are incorrect in your assessment of the situation but your opinion is your opinion.

It is sad that people hanging out on thses sites can't participate with some respect for those who are willing to share their ideas, knowledge, and hard work with the world.

Alex Lowe

# re: Children...@ Tuesday, December 09, 2003 3:20 PM

I agree with Alex. Feel free to post away. The children are at issue, not your posts (again, not that I agree with you :)

This is why we will likely have to go to a registration format sooner than later for comments. :(

-Scott

Scott Watermasysk

# re: Children...@ Tuesday, December 09, 2003 3:21 PM

I think Frans that removing your posts works for the people who think this blog has no space for Microsoft critics.

I will maintainmy opinion if I was you, but hey I am not you !

Paschal

# re: Children...@ Tuesday, December 09, 2003 3:25 PM

Franz its a sad fact that a certain % of any group of people are a bunch of fools.

We shouldn't let them ruin our fun though, but what they are doing to you does suck I know.

I definately think that this community is richer for diverse opinions as it often gives us another dimension on what we do. Like some of the info posted about mono, or your own comments about Oracle a while back.

Please try to relax and ingnore the idiots, blog on dude :D

OmegaSupreme

# re: Children...@ Tuesday, December 09, 2003 3:29 PM

Scott, I think so too you need some kind of registration, or at least IP number logging or something.

You can't prevent everything but now it's not fun expressing some opinion...

Frans Bouma

# re: Children...@ Tuesday, December 09, 2003 3:38 PM

I find it somewhat troubling that I can sign with any name.

Its one thing to be anonymouse, but here I can pretend to be anyone.

-AndrewSeven

Bill Gates

# re: Children...@ Tuesday, December 09, 2003 3:53 PM

I'm just glad my aggregator caught your post so I could read what your opinions are.

I can't speak for anyone else, but yours is one of the feeds that I have subscribed in my aggregator for exactly this reason - you have always spoken your mind.

Anyways, post on, Frans!

Chris Frazier

# re: Children...@ Tuesday, December 09, 2003 4:09 PM

Don't take posts down because of a little heated debate. As I said before, everybody is entitled to their opinion and opinions should be treated with respect, not with "flame wars" and "identity theft". There's no excuse for what "the children" did, but "blog comments" still boil down to "trust".

Yves Reynhout

# re: Children...@ Tuesday, December 09, 2003 4:12 PM

Scott...hey what about Passport (umm...semi-joking :-)), seriously, some form of membership with the option to lock out comments to registered individuals (anonymous as the name otherwise) would be very useful.
Us 'independent' bloggers will probably be harder hit by this than the group bloggers (since you can have a single sign-in across all blogs) - but totally necessary.

Scott Galloway

# re: Children...@ Tuesday, December 09, 2003 4:17 PM

Yves: trust me, I can take a tough debate and the one today in the thread below the posting wasn't a tough debate per se. :) It's the crap that's posted in other threads in other blogs that's annoying. When I get mail from people asking why I replied rudely to their blog while I haven't read that blog in my entire life, it's getting out of hand.

If people don't agree with me, that's fine, you didn't agree with me today, perfectly ok. That's not the reason I did take the thread down, if you doubt about that, please check the reactions on my Oracle posts or Stored procedure posts :)

Frans Bouma

# re: Is it still allowed to have criticism on Microsoft here?@ Tuesday, December 09, 2003 4:36 PM

I don't know if someone mentioned this or not, but Microsoft has had package and deployment solutions built into their products for sometime. There still seems to be a market for things like Wise and InstallShield. Visual Studio has setup projects that directly compete with those directly. Why should an O/R mapper product be any different?

I don't think Microsoft is violating any laws, and or violating any code of ethics. They are exposing technology to people who might not have been aware of it to begin with. You state that it is harmful to the .NET community, how can it be? It is harmful to YOUR community and YOUR pockets. You can speak for your company, but you cannot assume to speak for the .NET community.

I think your effort should be concentrated on developing features and providing services that ObjectSpaces will not. Why waste all of this energy whining about it and do something productive instead?

Jeff Gonzalez

# re: Children...@ Tuesday, December 09, 2003 5:19 PM

I'm really sorry to hear that; I enjoy reading your opinions, even if I don't always agree with them.

Bruce

# re: Children...@ Tuesday, December 09, 2003 8:40 PM

if frans' comments didn't rock the old boat now and then - what would be the point of having him?

you're damn opinionated and you're sometimes wrong - but your clever and that's why, even after a major blogroll clean up that culled off scobleizer *and* dave winer, i choose to keep frans in my list.

leon bambrick

# re: Children...@ Wednesday, December 10, 2003 2:58 AM

Never ever change your "voice" because of others. If it's how you feel, if it's your truth, then don't change your voice.

Put the post back.

S Bradley

# re: Is it still allowed to have criticism on Microsoft here?@ Wednesday, December 10, 2003 3:26 AM

Perhaps we could do without whining babies blogging here?
Leave if you don't like it.
Fine by me.

Jason

# re: Children...@ Wednesday, December 10, 2003 8:47 AM

It's not often that I see anyone getting all riled up about something to the point where they start screwing with someone. Congrats on getting some people that excited, you can consider yourself a writer now that some people hate you. :)

Josh Baltzell

# re: Stored procedures are bad, m'kay?@ Thursday, December 11, 2003 1:46 AM

It's ironic that this flame on SP has been done using a blog engine that is powered by SP.

anonymous

# re: Here's a (big, bad) difference between VB.NET and C#@ Thursday, December 11, 2003 11:01 AM

C# lets you define a new GetObjectData method, but you still can't call the original method. So you still need to recode the base class implementation. e.g.:

public class MyTable : DataTable, ISerializable
{
void ISerializable.GetObjectData(SerializationInfo info, StreamingContext context)
{
((ISerializable)this).GetObjectData(info, context); // calls this method, not the base class
((ISerializable)base).GetObjectData(info, context); // compiler error
base.GetObjectData(info, context); // compiler error
}
}

Carlos

# re: Serious ASP.NET Editor flaw lives on in VS.NET 2003@ Thursday, December 11, 2003 2:48 PM

I am using Visual Studio 2003 and it looks like this problem is fixed. In old Visual Studio it used to strip "Style" in <td> tag, but it's no longer doing it.

Can someone verify this?

Thanks.

Jim

Jim Han

# re: Stored procedures are bad, m'kay?@ Thursday, December 11, 2003 6:37 PM

Frans,

"way before Eric Smith thought it was a good idea" Wow! You're turning into a regular thona.

What I do is run a script that drops all my standard CRUD procs and then re-generate them all when the schema changes. The same thing for my DAL classes. It's called active generation. I think you know a thing or two about this so I'm not sure why you would be slamming me or my tool over it. While CodeSmith does not have the full blown template set that LLBLGen Pro does, the two products are basically the same thing (except CodeSmith is free). Someone could just as easily generate their DAL using an XML O/R mapping file and use dynamic SQL or whatever they want. That's the beauty of a template based code generator. It doesn't dictate architecture to the end user. I don't know about you guys but I will never use a code generation tool that forces me to do things a certain way.

Eric J. Smith

# re: Roundtrips and the real bottlenecks@ Sunday, December 14, 2003 8:18 AM

Hi,

Your blog contains good info. Keep it up.

John

# Stored procedures vs. Ad-hoc queries@ Thursday, December 18, 2003 1:25 AM

TrackBack

# re: The SP Benchmark code@ Friday, December 19, 2003 7:39 AM

Would you happen to have the VB version of the
"The SP Benchmark code". I am new to VB.NET and I am trying to take your advice and go with the Parmeterized Dyanamic Query rather than Stored Procedures.
Regards,
Majid Haeri
majid_97@yahoo.com

Majid Haeri

# re: VB.NET developers, continued@ Friday, December 19, 2003 1:20 PM

Don't worry, C# programmers aren't considered highly skilled developers either.

asdf

# re: Why Edit & Continue is a bad thing@ Sunday, December 21, 2003 1:43 PM

Edit and continue save so much time when fixing trivial errors that it is a shame it hasn't been implemented yet - whenever I read the ENC comments form C# people, it's just typical of their "my way of the highway" mentality that keeps progress in the 19th century. Get over it C# people, there are some nice features in VB that put the IDE ahead of the C world you are accustomed to and it's time you opened your mind and stop acting like bunch of geeks. Just because you are C people doesn't really make you better programmers - it just proves you like to suffer more than the rest of us.

George

george

# re: ORM and O/R mapping@ Sunday, December 21, 2003 5:08 PM

I'd tend to disagree. I think that "ORM" is an overloaded acronym which - based on the context - either means "Object Role Modelling" or "Object Relational Mapping". I've seen it used in both meanings before ...

Ingo Rammer

# re: ORM and O/R mapping@ Sunday, December 21, 2003 7:50 PM

My pleasure ;-) I believe strongly in O/R Mappers as I'm sure you do too. Its nice to see so many people talking about them!

Steve

# re: ORM and O/R mapping@ Sunday, December 21, 2003 11:59 PM

tomato
tomato

scott

# re: ORM and O/R mapping@ Monday, December 22, 2003 1:35 AM

::I'd tend to disagree.

Without a reason, as I must say.

::I think that "ORM" is an overloaded acronym
::which - based on the context - either
::means "Object Role Modelling" or "Object
::Relational Mapping".

Why do I think "bullshit" hen I read this?

I will tell you.

This hyperlink:

http://www.acronymfinder.com/af-query.asp?String=exact&Acronym=ORM

points to Acronymfinder, which is about THE ressource for overloaded abbreviations :-) I mean - look up CMS, and you sill understand.

it lists a LOT of overloads for ORM, but NONE is "Object / Relational Mapper".

So, with all respect - what you THINK is totally irrelevant. It is no an acronym, whether you try to make it one or not.

If people would keep to use words in the right meaning, they would be understood better. Honor the language you speak, and dont pollute it with your thinking.

Thomas Tomiczek

# re: ORM and O/R mapping@ Monday, December 22, 2003 2:20 AM

Thomas, charming as always!
I'm lovin' it! ;)

Dennis v/d Stelt

# re: ORM and O/R mapping@ Monday, December 22, 2003 3:16 AM

Sorry, Thomas. I refuse to discuss at this level of language and attitude. If you are interested in a discussion of how language evolves, how acronyms are created, and how we should treat them, I'd be happy to respond if you re-post in sane language.

In the meantime:

http://www.google.com/search?q=orm%20%22object%20relational%20mapping%22 (1050 hits)

vs.

http://www.google.com/search?q=orm%20%22object%20role%20modelling%22 (363 hits)

-Ingo

Ingo Rammer

# re: ORM and O/R mapping@ Monday, December 22, 2003 3:23 AM

Ingo: heh :) ok, that means OR not a lot of people use ORM (the modelling) (wouldn't be surpised) OR a lot of people use the wrong acronym ;)

The point of my blogentry was that ORM (the modelling, geezz... because I have to say 'the modelling' proves my point ;)) is a term for Object Role Modelling, which doesn't have another name afaik. This means that to avoid confusion among developers, it's better to stick with the original terms.

Frans Bouma

# re: ORM and O/R mapping@ Monday, December 22, 2003 4:55 AM

Using google statistics is arguable.

http://www.google.com/search?q=%22object%20relational%20mapping%22 (17400 hits),
so one in about 16 pages with "object relational mapping" has the acronym ORM.

http://www.google.com/search?q=%22object%20role%20modelling%22 (636 hits), so more than half of the pages with "object role modelling" contains the acronym ORM.

Conclusion: ORM more used for object role modelling than for object relational mapping.

Vincent Snijders

# re: ORM and O/R mapping@ Monday, December 22, 2003 8:51 AM

Vincent & Frans: Agreed.

I just wanted to support my point that I've seen it used with both meanings (a point with which Thomas didn't agree too much). The google.com query shows this as well and - just as I did - without any notion of whether this is right or wrong. It's just a snapshot of what people actually said.

-Ingo

Ingo Rammer

# re: Stored procedures are bad, m'kay?@ Monday, December 22, 2003 1:29 PM

This started out being interesting, but once again Thona has appeared and ruined it. Seriously, the guy is the most violent drunk I've come across in this arena. I think I'll head elsewhere ...

Mac

# re: Tool: The complete idiot's add-in for signing your assemblies with a strong name@ Tuesday, December 23, 2003 3:21 AM

TrackBack

# Tool: The complete idiot's add-in for signing your assemblies with a strong name@ Tuesday, December 23, 2003 3:30 AM

TrackBack

# re: Bitter message@ Tuesday, December 23, 2003 3:53 AM

TrackBack

# re: Singing your assembly, newbie guide@ Tuesday, December 23, 2003 9:09 AM

This is groovy. I've been wanting to look this up for a while but I've been too lazy. "Signing your component for dummies."

Scott

# re: Singing your assembly, newbie guide@ Tuesday, December 23, 2003 9:12 AM

Excellent. I was thinking the same thing the other day when I read our infamous know-it-all saying how hard it was to do. :)

Paul Wilson

# re: Singing your assembly, newbie guide@ Tuesday, December 23, 2003 9:12 AM

Heh, I wouldn't expect anything else than lazyness from a person from lazycoder.com :D ;)

Frans Bouma

# re: Singing your assembly, newbie guide@ Tuesday, December 23, 2003 9:13 AM

You no longer have to register to download my tool. Thanks for the plug.

Robert McLaws

# re: Singing your assembly, newbie guide@ Tuesday, December 23, 2003 9:15 AM

Not every bad publicity is 'good', Robert. (and why is my comment removed from the commentslist under your tool? Tssk.. censorship... )

Frans Bouma

# re: Singing your assembly, newbie guide@ Tuesday, December 23, 2003 9:26 AM

Yes. It's easy, but why the heck not use a plugin? Why not make life easier? is that such a bad thing? Sure, I *could* write property getters and setters manually if I *wanted* to, but I use CodeSmart so make it fast and simple. Is that bad as well?

Roy Osherove

# re: Singing your assembly, newbie guide@ Tuesday, December 23, 2003 9:26 AM

LOL, I was thinking about the same when I read the huge announcement.

Nice job, do I have to register in the future to read your blog ;-) ?

Peter de Boer

# re: Singing your assembly, newbie guide@ Tuesday, December 23, 2003 9:28 AM

Thank you Frans!!!

Ugh. I really don't like that ( I do like this).

It had seemed so simple to sign my assembly, just like the steps above but with a key per project.

No thank you Robert.
There I was, left with this sinking feeling, that I had left out something, that this simple task was much larger than what I understood.

AndrewSeven

# re: Singing your assembly, newbie guide@ Tuesday, December 23, 2003 9:31 AM

Peter: just subscribe to the RSS feed in your RSS reader, no registration required ;)

Roy: plugins can be buggy, can mess up your code, can crash the IDE, can corrupt files and more. And that for just 1 line of code. :D

I don't use any plugins anymore, after I wrote some macros to create regions and properties. I know these will work without hassle. But thats choice. If you want to use a plugin for 1 line of code that is always the same in every project you create, go ahead, it's a free world (for some).

Frans Bouma

# re: Singing your assembly, newbie guide@ Tuesday, December 23, 2003 9:35 AM

Using plugin for adding key file name to AssemblyInfo class????
LOL!

btw, first two steps could be replaced by
1. Run Start/Programs/Microsoft Visual Studio .NET (2003)/Visual Stuio .NET Tools/Visual Studio .NET (2003) Command Prompt

Oleg Tkachenko

# re: Singing your assembly, newbie guide@ Tuesday, December 23, 2003 9:38 AM

Ah good one, Oleg :) The less steps, the better :)

Frans Bouma

# re: Singing your assembly, newbie guide@ Tuesday, December 23, 2003 9:39 AM

Just to play devil's advocate here, A macro is the same as a plugin for this discussion. It makes your life simpler. Regardless of the usefulness of Robert's plugin, You can't disregard "simple life mechanisms" so easily, can you? Sure, for one line of code it would seem a bit too much, but that's not usually the case.

Roy Osherove

# re: Singing your assembly, newbie guide@ Tuesday, December 23, 2003 9:46 AM

Roy,

it's not really the fact someone creates a plugin, it's more the fact there's made a *huge* announcement for a solution to a problem while there is no problem. It's really not a big deal to sign an assembly.

What would you say when I created a plugin that for example adds the statement "using system.data" to the top of my page? Basically that's what it does.

Peter de Boer

# re: Singing your assembly, newbie guide@ Tuesday, December 23, 2003 10:34 AM

It is all interesting but Carl Franklin created a tool to generate key file then the only thing you need to do is to make changes to your Assebly Attributes :)

http://www.franklins.net/dotnet/snutil.zip

www.ipattern.com (do you?)

Maxim V. Karpov

# re: Singing your assembly, newbie guide@ Tuesday, December 23, 2003 10:39 AM

Hi Frans,

This might work if you're the only developer on a project. But if your dev team has more than one developer, you *must* keep your secret key secret. This means that the developers shall not have the private key, but only the public key and use "Delay Sign" as described in this MSDN article. The GAC hassome special mode for skipping signature verification that has also to be used by developers during coding and testing. Then after, before burning the CDs, the assemblies have to be resigned by the "security officer", the only person in the company who should have access to the private key. Here's the link to the MSDN article:
http://msdn.microsoft.com/netframework/default.aspx?pull=/library/en-us/dnnetsec/html/strongNames.asp

Hope this Helps!

Christophe Lauer

# re: Singing your assembly, newbie guide@ Tuesday, December 23, 2003 10:45 AM

Maxim: you mean a wrapper around sn -k? :)

Christophe: good point. Although I think if you don't have a security officer it's not that big of a deal, but if you do, then indeed the developer should use delayed signing described in your article.

The fuzz here was more about a big announcement of a plugin to do something very simple :) The philosophy behind signing assemblies, (when to sign, when not to sign), installing in GAC or not, is a big subject, however if you've decided to do so (for example to be sure signed applications can use your assembly), the steps to sign the work are very easy :)

Frans Bouma

# re: Singing your assembly, newbie guide@ Tuesday, December 23, 2003 11:20 AM

I dont even see why this is a big deal, the process takes all of 30 seconds and is extremely simply...?

Joe Coder

# re: Singing your assembly, newbie guide@ Tuesday, December 23, 2003 12:43 PM

I agree with Frans and Joe Coder. For gosh sakes this is so frigging basic and it takes all of 30 seconds. This is chapter 1 of Richter for gosh sakes. How can anyone do aything in .NET if they don't know the most basic things like this? You don't need an add-in to do this as it is uncommenting two lines in AssemblyInfo.

Sam Gentile

# re: Here's a (big, bad) difference between VB.NET and C#@ Tuesday, December 23, 2003 1:15 PM

I don't know if this will work for DataTable, but take a look at the ISerialization details of extending ApplicationException in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol/html/csharp08162001.asp.

Chuck Eaker

# re: Singing your assembly, newbie guide@ Tuesday, December 23, 2003 4:28 PM

You guys are all primadonnas. The first part of my post said I had 30 e-mails in three days saying that people didn't know what it was. OBVIOUSLY there was a need for it SOMEWHERE, or I wouldn't have done it. Buy you guys are all so friggin brilliant... that's why it wasn't written for you, or the 2000-some-odd people that understand it. It was written for the 6 MILLION other .NET developers who are just getting started in .NET, and don't get it. Not everyone is as smart as you are.

And BTW, It's not Chapter 1 of Richter. The VB.NET Security Book does not cover it until Chapter 10. And the fact that you think the problem is as simple as one line of code, means you don't REALLY understand what's going on under the covers.

And in regards to the add-in not dealing with delay-signing... most shops can't even understand regular signing... to them, delay signing is next to impossible. You have to start somewhere.

Developers look up to you guys for advice, for leadership. Is this being a leader? Leaders don't tear people down. When you post blatantly negative attacks on someone, it makes other people not want to be a part of this community.

Speaking of starting somewhere, I think you all forgot where you started. There was a time once where you didn't know what strong-name signing was either (it wasn't that long ago, since it came around with the Framework). I doubt anyone derided you for being stupid and not knowing how you did it. Sam, you just single-handedly insulted 6 Million VB.NET developers who don't get the same signing comments that are in the AswsemblyInfo.vb file. Are you calling them stupid?

Robert McLaws

# re: Singing your assembly, newbie guide@ Tuesday, December 23, 2003 4:32 PM

Almost forgot. Singing your assembly, huh? I like singing songs, personally, but i can see how singing an assembly can be fun too.

Robert McLaws

# re: Singing your assembly, newbie guide@ Tuesday, December 23, 2003 4:42 PM

It is on Page 90 of Richter. I, unlike a lot of those programmers, started 3 years afo with just the framwork and an editor and figured it out. I also started with Richter. If people would just read the damn book and understand the basics before playing with things like ASP.NET they wouldn't have these issues over and over. I do understand signing fully, I don't know what you are doing with your controls that is different from hundreds of others that don't have the issues you have. And don't call me a prima donna. If its anyone who hasn't earned their place but touts their own horn every frigging second, its you. I have stayed out of this for far too long. I dind't post anything when all those people attacked you but you just don't listen to the advice that Frans and people gave you. You constantly come off as the gift to the world and making asine statements like "done more in 21 years than anyone has in 40." Its that kind of thing that pisses people off and does what Jim McCarthy calls "flipping the bozo bit" and having people stop listening to what you have to say. You can rant all you want. It is a matter of a command or uncommenting out 2 commented out lines in the AssemblyInfo. I have been doing this for 3 years and it takes 30 seconds. If you want to blow it up to epic scale like you do with all your "announcements" knock yourself out. I still maintain that its very basic and that anyone that does not know the basics of assemblies (ala Richter Chapters 1-3) will have a near impossible time programming .NET. VB can try to hide everything away from people but in the end you just have to know what you are doing. Fundamentals.
As to your last asertion that I single-handly insulted 6 million programmers, you are sounding more riducolous every time you post. You saying wild things like this just makes you look bad.

Sam Gentile

# re: Signing your assembly, newbie guide@ Tuesday, December 23, 2003 5:00 PM

The first thing I learned as well when I started .Net (and I started with notepad, MSDN, and Richter) was how to sign and delay-sign an assembly. The assembly, and how it works, how to use it, etc. is fundamental to understanding .Net.

I understand the reason you felt you needed to create the tool, but I disagree that it was necessary to create a tool when a simple explanation like Frans' would have sufficed. If the comments are not available in VB.Net (as it is in C#, which Sam and I use daily), then I would have answered those 30 emails you mentioned with a blog post explaining the issues. It helps produce better developers who understand why, rather than run another wizard and still have no idea what's going on.

Working with Sam day-in and day-out, I see that it is ingrained in him that developers understand "why" more than "what". He is not a "prima-donna", as he devotes hours of his time helping this client among many others in the .Net community to understand how .Net works. Sam was not trying to insult the 6 million developers -- instead, he was trying to help them understand why things work the way they do in .Net. Even the VB.Net Security book you mention (by Eric Lippert) goes through many details from the front-end to explain to the VB.Net developer why security is the way it is in .Net. He does all of that without running a single wizard. He mentions nothing about VB.Net because its immaterial to understanding the fundamental principles of .Net.

Robert Hurlbut

# re: Signing your assembly, newbie guide@ Tuesday, December 23, 2003 8:24 PM

Can I just skip to Step 9 and repeat it a few times?

Shannon J Hager

# re: Serious ASP.NET Editor flaw lives on in VS.NET 2003@ Tuesday, December 23, 2003 11:29 PM

Not only is this an annoying bug but I've got one worse. For some reason, the event wiring code that hooks buttons and other control's postback events to the code behind .cs file, dissapears, seemingly randomly, when a .aspx file is saved. Doesn't happen everytime but when the client calls up and says some button doesn't work anymore, it really sucks.

And that explanation for why the bug didn't get fixed is such BS. How many billions in cash does MS have in the bank? Hire consultants if your team is too la.. uh, uh, unable to rewrite the code.

Rip Ryness

# re: Signing your assembly, newbie guide@ Wednesday, December 24, 2003 2:26 AM

@Robert: come on man, pointing out a typo from someone who's native language is not English??

It just shows you can't beat him on arguments.

I'd like to see you post in Dutch, and I promise I won't point out any typo if I can just understand what it's about.

[offtopic]
LOL @ Shannon :)

Peter de Boer

# re: Signing your assembly, newbie guide@ Wednesday, December 24, 2003 4:19 AM

Shannon: hehehe :) You could of course do that, but my experiences are that, if you take step 9 too many times, it's adviced not to take any of the previous steps after that ;)

Frans Bouma

# re: Signing your assembly, newbie guide@ Wednesday, December 24, 2003 4:19 AM

WARNING to mr. McLaws: do not ever post a reply to my blogs again. EVER.

Frans Bouma

# re: Signing your assembly, newbie guide@ Wednesday, December 24, 2003 6:45 AM

Peter:

"What would you say when I created a plugin that for example adds the statement "using system.data" to the top of my page? Basically that's what it does. "

If I remember correctly there a a very cool plugin somewhere that allows you to automatically add missing import (using) statements to your file when you forget to add the. Something like, you time Thread, mark the work and make the shortcut keys, and the using System.Threading line appears automagically. simple, time saving, and yes, does not take a genius to figure out. Still, iot's a wonderfull time saving plugin. I would not call such as plugin useless.

Roy Osherove

# re: Signing your assembly, newbie guide@ Wednesday, December 24, 2003 8:28 AM

Ugh, my typos are only enhanced on a norwegian keyboard, as my last comment would show..
I meant to say that you highlight the word "thread" and activate the plugin, to automatically have a "using System.Threading" line added to your code.
Hope that's more understandable.

Roy Osherove

# re: Signing your assembly, newbie guide@ Wednesday, December 24, 2003 8:33 AM

I found my friend Keith Brown's article on strong names to be the *best* thing I have read in 3 years on the subject. Check it out http://msdn.microsoft.com/netframework/?pull=/library/en-us/dnnetsec/html/strongNames.asp

I blogged it http://samgentile.com/blog/archive/2003/12/12/10883.aspx

HTH

Sam Gentile

# Dewayne Mikkelson and his Radio WebDog, Shadow@ Wednesday, December 24, 2003 8:40 AM

Dewayne Mikkelson and his Radio WebDog, Shadow

TrackBack

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Wednesday, December 24, 2003 12:13 PM

Blah blah blah
SQL Server is better... No, Oracle is better, No...
Get over it. There're pros and cons for both products. But since you started arguing: I'll take easy integration over a couple of features anytime. While you're trying to figure out the docs and tools, I can do my work and move on, and don't have to shell out $90k for Oracle DBA.
To wayne: If you think this is the worst bug in SQL Server(with such an easy workaround) then you should dump Oracle and start using SQL Server right away.

Sergey

# re: Happy holidays!@ Wednesday, December 24, 2003 1:17 PM

Happy Holidays Frans :D

look forward to checking out LLBLGen Pro in the new year, I've had no time this year :(

Then again looking at my todo list it may be a few months yet ...

OmegaSupreme

# re: Happy holidays!@ Wednesday, December 24, 2003 1:23 PM

Happy Holidays Frans!

Sam Gentile

# re: Happy holidays!@ Wednesday, December 24, 2003 2:17 PM

Same to you. Happy Holidays!

Shane Bauer

# H4ppy H0L1d4ys!@ Thursday, December 25, 2003 1:59 PM

I'm glad to see I'm not the only one putting my day(s) off to good use.

My holiday so far has been spent playing with some toys/tools that I haven't previously had time to really sit down and give the effort needed. I have been able to finally check out the Frans' offerings: LLBLGen (the free, open source version and a demo of the Pro version). The Pro version is only a demo, so I couldn't really test it except for on the Northwind database, but it is

TrackBack

# re: Signing your assembly, newbie guide@ Thursday, December 25, 2003 3:12 PM

Damn, you nitwits!
Arguing about whether or not to write an add-in...
BE HAPPY that you're all .NET coders!
I still have to experience the terror of Java, ever tried to sign a JAR file?!? you need an entire tool for that! a plugin isn't even sufficient :P
We're gonna switch to .NET soon :D

But plz guys, don't argue about something so ignorant... both solutions are good :) surely a user can decide whether or not to use an add-in...

Greetz,
-- Rob.

En ja, hij had in inderdaad zijn bek moeten houden over spellingsfouten ;)

Rob Tillie

# Weblogs.asp.net / .Text screensaver!@ Friday, December 26, 2003 6:44 AM

TrackBack

# Weblogs.asp.net / .Text screensaver!@ Friday, December 26, 2003 6:51 AM

TrackBack

# Lovely@ Friday, December 26, 2003 2:11 PM

It looks great :p

Just like the dozer-one :)
Gonna try and learn a bit from your source, I'm amazed with what you can do with OpenGL

David Cumps

# re: Weblogs.asp.net / .Text screensaver!@ Friday, December 26, 2003 2:41 PM

thanks, David! :)

Frans Bouma

# re: Weblogs.asp.net / .Text screensaver!@ Friday, December 26, 2003 11:26 PM

Cool! Going to grab it tonight and take a look.

I fooled around with some OpenGL (mostly) and DirectX back in college for my graphics course. Been awhile, but I'd love to play around more with it. Maybe this will be the code that sparks the interest :)

Tim Marman

# re: Weblogs.asp.net / .Text screensaver!@ Saturday, December 27, 2003 12:08 PM

Superb :D

looks great on my geforcefx 5600

Great job.

OmegaSupreme

# re: Weblogs.asp.net / .Text screensaver!@ Monday, December 29, 2003 2:36 PM

Looks very nice buddy!! I've got a GeForce 3 card on WinXP.

Respect and keep up the good work :)

Johan Danforth

# re: Weblogs.asp.net / .Text screensaver!@ Monday, December 29, 2003 3:06 PM

Thanks all! :)

I noticed a small bug with the timings, if hte framerate drops because the time it takes to calculate and draw a frame is > the time it takes of a frame using the current framerate of the screen (75hz for example), the animation slows, because the angle changes of the x-y and z sines are not changed because of the less amount of frames drawn per second... ah well.. ;) It was fun developing this code (it even pulls 75fps on my GF4 / amd2600+ with 250 flares/bands on 1600x1200 :))

Frans Bouma

# re: Weblogs.asp.net / .Text screensaver!@ Monday, December 29, 2003 3:47 PM

I used to follow the demo scene back when I had an Amiga then a PC. I liked The Future Crew stuff. I was impressed by the effects and the fact many were coded in assembly. Pretty impressive because you have to be very good in programming plus calculus/math.

Abdu

# re: Weblogs.asp.net / .Text screensaver!@ Monday, December 29, 2003 4:11 PM

I typed a long reply, about the demoscene, but .Text's bug with the viewstate corruption vanished it. :(

Frans Bouma

# New and Notable 32@ Tuesday, December 30, 2003 4:48 AM

TrackBack

# re: Stored procedures are bad, m'kay?@ Tuesday, December 30, 2003 11:47 AM

Bit of a lack of thrill here. Rant, rave, and yell, but don't actually present any facts or figures. So we are all supposed to start creating a series of roles on the database and couple that with a series of views and tack into that a bullet proof hack proof dynamic sql method just to get past SPs? Not to actually get faster than SPs, or safer than SPs, or even less resource intensive than SPs..just to please an SP hater? Yeah, right, and I just saw a flock of pigs flting north.

Mr Ed

# re: Stored procedures are bad, m'kay?@ Tuesday, December 30, 2003 11:57 AM

Oh yes..has anyone here heard of 'pre-compilation' of Stored Procedures?

Also..Frans..if you quote from something to use it as a support for your arguement then you cannot then turn around and blame that source if it turns out to be wrong with no backlash on yourself. Its called 'checking your sources'. You quote it, you wear it.

And that guy how started up about 'Access' and its obvious lack of SPs....please, give us all a break. If you want to use Access then feel free...but don't pretend speed, scaleability or any thing else are considerations. Like driving a Ford Anglia into a SuperCar rally.

Mr Ed

# re: Stored procedures are bad, m'kay?@ Tuesday, December 30, 2003 12:00 PM

What's the problem, Ed? what did I quote but misused?

Also, tell me, how to precompile stored procs in SqlServer so that it would add something to the execution speed. You can't do that, claiming you can is bollocks.

If you want to keep using SP's, go ahead. However if you want to defend yout decision WHY you want to keep doing that, use facts, instead of stories about flying pigs :)

Frans Bouma

# re: Serious ASP.NET Editor flaw lives on in VS.NET 2003@ Tuesday, December 30, 2003 8:27 PM

I have stopped all major development with asp.net until this bug is fixed.

Danny Jones

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Wednesday, December 31, 2003 1:03 PM

public string opinionator(string DiscussionTopic)
{

if(DiscussionTopic.IndexOf("Microsoft") > 0)
{
return "bad";
}
else
{
return "good";
}

}

alex

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Wednesday, December 31, 2003 1:04 PM

forgot my smiley... ;)

alex

# re: Happy 2004!@ Thursday, January 01, 2004 2:27 PM

Hi Frans,

Best wishes to you too from Voorschoten!

Fizgig

# Introducing Multiple Inheritance@ Sunday, January 04, 2004 11:02 AM

TrackBack

# re: A plea for full multiple inheritance support in .NET@ Sunday, January 04, 2004 2:34 PM

They are some more issues with MI. Imagine an object that inherits from MarshalByRef and MarshalByValue or a RealProxy. How this object will be marshalled ?
Also class attributes carry some ambiguities. Testing for the existance of an attribute in some cases all base classes must have it (ie Serializable), for some any class may have it and for some others only one class (AllowMultiple=false).

I had posted (a year ago) a suggestion for Ruby-like mixins, that seems that might be implemented in some next C# version (orcas?)

see what Chris Brumme said about MI at :
http://blogs.gotdotnet.com/cbrumme/commentview.aspx/ec40acce-4ae4-44b8-93ce-27dd896b0d1d

Panos Theofanopoulos

# re: A plea for full multiple inheritance support in .NET@ Sunday, January 04, 2004 3:07 PM

Panos, of course there are issues with silly inheritance trees, but that's the problem of the developer doing the silly inheritance. It's not the problem of the platform developer what the user of the platform will do with it, like it's also not hte problem of the platform user how complex it is to write such a platform.

Frans Bouma

# re: A plea for full multiple inheritance support in .NET@ Sunday, January 04, 2004 3:21 PM

I find I want multiple inheritance, not because of things I've done, but because of things Microsoft has done.

If, for example, the core control architecture were based on IPage (an interface) instead of Page (a class), then I wouldn't need to have some contortions I do.

Here's a simple example:

I want a base class called AbstractHttpHandler, which gives a bunch of core functionality (I'm speaking of code here, not interfaces), to help me implement HTTP handlers. I also want my page class to inherit from this, so I can bring along all this code without any effort, since all the base HTTP handler code really applies to the base page code.

With things as they sit now, I have to derive from AbstractHttpHandler from Page, rather than just implementing IHttpHandler, because of the inheritance tree. An alternative, that's also not very tempting, is to contain AbstractHttpHandler within AbstractPage, and set up a whole bunch of mechanical method forwarding, or expose the handler through a property and create a dichotomy of "helpers in the handler class vs. helpers in the page class". None of that is very clean.

Why? Because someone on the ASP.NET team didn't make IPage. Thanks, Microsoft. :-p

I will say, though, that I will be missing MI a lot more when we get generics. I loved the ATL-style usage of MI (mix-ins), and I could strongly vote for MI on this basis alone.

Brad Wilson

# re: A plea for full multiple inheritance support in .NET@ Sunday, January 04, 2004 8:41 PM

I don't want MI. I want Ruby Mixins, or Traits

http://www.cse.ogi.edu/~black/publications/refactoringsACM.pdf

As far as I can tell.. you will be able to sort of simulate mixins with generics.
Do a search for Generic Mixin in google, and see what turns up.

Sean

# re: My wish-list for the next Visual Studio.NET release@ Monday, January 05, 2004 12:40 AM

for one thing - persistent bookmarks are a necessity - one thing that can be learnt from JBuilder 8 is numbered shortcuts - Ctrl + Shift + <number> to set, Ctrl + <number> to recall... the one area the .NET IDE has a real edge over the JBuilder 8 IDE is in 'outlining' ...

dylan pereira

# re: My wish-list for the next Visual Studio.NET / .NET api release, part II@ Monday, January 05, 2004 12:43 AM

IDE - persistent bookmarks are a necessity - one thing that can be learnt from JBuilder 8 is numbered shortcuts - Ctrl + Shift + <number> to set, Ctrl + <number> to recall... the one area the .NET IDE has a real edge over the JBuilder 8 IDE is in 'outlining' ...

dylan pereira

# re: My wish-list for the next Visual Studio.NET / .NET api release, part II@ Monday, January 05, 2004 12:50 AM

IDE - persistent bookmarks are a necessity - one thing that can be learnt from JBuilder 8 is numbered shortcuts - Ctrl + Shift + <number> to set, Ctrl + <number> to recall... the one area the .NET IDE has a real edge over the JBuilder 8 IDE is in 'outlining' ...

dylan pereira

# A plea for a more concrete example of why MI support would be useful in .NET@ Monday, January 05, 2004 8:48 AM

Almost every time I read or hear a justification for MI, it falls into one of three camps:

(1) The explanation is excessively abstract.
(2) The explanation contains 'toy' examples.
(3) The explanation contains really bad examples, where MI was positively the wrong thing to use.

I'd really like to see (4): an explanation with compelling examples, because I'd really like to understand why some people want this so much. I was disappointed by this article, as it seems to fall into camp (1) - the first paragraph of "When SI doesn't cut it" doesn't present a credible example, it just presents an abstract scenario: a world of As, Bs, and Cs, rather than anything real.

To the extent that it is specific - talking about ServicedComponent - it is specifically somewhat non-credible. Do you *really* build your distributed systems like this? Don't you always build a facade that presents the external remotely accessible face of your application, and which then calls into internal business logic components? To me it seems like if you're in a position where you actually want to derive from ServicedComponent *and* something else, then sooner or later you're going to find that things are easier to maintain if you seperate out those two concerns (presenting a business operation facade, and implementing the guts of operations the facade exposes) into two seperate classes anyway.

(Or, if you're not making these things available at a network or process boundary, do you really use COM+ at such fine granularity? I've just finished work on a system where we tore out such use of COM+ because it killed the system's scalability.)

Deriving from ServicedComponent in a class that forms part of the implementation guts just seems wrong to me. But of course everyone's views are coloured by their experiences, and I was hoping to be able to learn from your work.

So I'd love to read about a concrete situation where the lack of MI in .NET caused you a problem. (Even if it is ServicedComponent-bassed - I'm prepared to believe that you might have a perfectly reasonable example in mind despite my bad experiences with fine-grained COM+, but it's really hard to tell when the names of all the classes have been replaced with letters...)

In 3 years of working with C# I've not yet come across a situation in which MI would have made my life easier. You've evidently had different experiences, and I'd love to learn from them, so it would be great if you could supply a little more detail; from this article I simply ended up with a feeling of "Nope - I still have absolutely no desire to see MI in .NET!"

That said, I did use mix-in MI quite a lot in my ATL days. But mostly to deal with the kind of COM plumbing that has pretty much vanished (hoorah!) in .NET. It's not a technique I miss.

Ian Griffiths

# re: A plea for full multiple inheritance support in .NET@ Monday, January 05, 2004 9:11 AM

Ian, I didn't include a specific example because when you do that, it makes the article's point be based on the specific problem illustrated by the example and it will most of the time make people react like "But if you do it this way [insert method here], your example's problem is gone", which will make the reader think the problem is gone, which is not the case.

But if you want a specific example, I'll give you one. First I'd like to add that you too didn't address the problems with ServicedComponent. You too are very vague about how to solve it by mentioning the usage of proxies, which is most of the time not what you want due to their 'chatty' nature. However, let's cut to the real problem.

In the LLBLGen Pro framework I wrote, I have support for ADO.NET and COM+ transactions. These 2 types are serviced by two different classes: TransactionBase and TransactionBaseComPlus. One derives from system.object, the other from ServicedComponent. I can't do it another way, because that will break the COM+ control flow as I understand it. This means that the shared code of both has to be implemented two times. (both contain the same code for managing which objects participate in the transaction etc.) I can't write it in another class hierarchy.

This limitation brought me to the choice of should I keep on supporting COM+ in a new templateset (with new base classes) I'm writing? That template set uses 'adapters' to persist/fetch entities and related objects. The base class is pretty big however I would need 2 versions of this class as well if I want to support COM+, and that's pretty ugly in my eyes.

That you haven't had the need for MI doesn't mean it's not handy to have it. If you are used to casting, generics are not that required, you can write code just as easily now as you can with generics. If you think about patterns, it's easier to apply patterns with MI than with SI, because you can work with abstract classes a lot which provide plumbing code for you. You give the example yourself: COM and ATL was great because you could mixin the COM+ plumbing using MI. .NET code today also contains a lot of plumbing code. We now have to jump through hoops (and often re-implement an interface we have implemented a dozen times before) to mixin plumbing code into our class which derives from another class.

With the specs of ServicedComponent, MI is REQUIRED to be as flexible as people say you CAN be with .NET. For other situations, MI will bring a lot of conveniance to the table and ease of use, especially for library writers.

I find the example Brad Wilson posted earlier in the thread also illustrative for a situation where it can (and SHOULD) be available. Gui related code is often better of with MI, for the same reason as some other code is better of: mixing of data structure (with little behaviour) and behaviour (and abstract data structures)

Frans Bouma

# re: A plea for full multiple inheritance support in .NET@ Monday, January 05, 2004 10:47 AM

It's nice to see a "non religious" case for MI, for a change :)

However, what the formal case for MI needs, IMHO, is a scientific study (meaning a statistically valid sample) of many applications in other languages/platforms that actaully use MI to solve problems of *all* kinds. The solution could be judged on several factors to classify them i.e.

- Was MI necessary to the solution or could SI have been used at little or no cost?
- What did MI buy the developer/user/project in terms of effort, functionality etc.
- What limitations did MI introduce to the code?
- What amount of complexity did MI introduce to the code?

.. and so on. What I'm getting at is this: how can we expect MS to go to the extensive trouble of implementing MI (and making it as backwards compatible as possible) unless we have some objective measure of what it will do for us AND also have some assurance it won't be abused, causing maintenance programmers and others having to work with APIs a lot of heartache.

I would like this big picture.
Richard

Richard A Lowe

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, January 05, 2004 4:59 PM

Frans has it right "Databases are one of the most high-tech software systems we all work with today, although not a lot of people will recognize them as such..." It's true!! They are amazing when you think about how fast they find what you're asking of them.

Most people (esp. developers) think of a database as a repository for data, not realizing all the benefits it can give them. Naturally, they like to fix problems with code. To that end, developers would rather not admit there's a need for a DBA, which is why *some* hate Oracle.

Oracle is complex and overboard for most applications. The MVCC alone makes me run screaming from SQL Server, but that's because I expect accurate results when I run SQL. Most can live without it because they're systems don't see that much action. For these systems, I see no reason to pay for Oracle either.

The bottom line is that if a system doesn't require a full-time person to manage the database systems, then it probably doesn't need those features. Enter SQL Server: good, fast but not made for super high-end systems. It also seems like GUI folks prefer the "self-managing" type of software, which Oracle is truly not though they are beginning to claim it. Command-liners don't mind getting their hands a little dirtier and typically don't gripe so much about Oracle's complexity.

Oh yeah, and the Oracle docs are actually good although they have come a LONG way in a short time.

re

# re: A plea for full multiple inheritance support in .NET@ Wednesday, January 07, 2004 2:32 PM

If every specific example could be countered with an example of why MI is not in fact necessary, wouldn't that tell you something? If a problem is only apparent in abstract examples, never in real scenarios, is it really a problem? (Actually I just find concrete examples more compelling...)

By the way, I don't think I mentioned proxies. I'm not really sure what you mean there.

To be a little more clear about what I was trying to say about use of ServiceComponent, I just think that it's a bad idea to put anything much in a class derived from ServicedComponent. This is for much the same reason I think it's a bad idea to put anything much inside a class that is exposed via .NET remoting. Either kind of class should be little more than a shim, dealing with the job of being at the edge and deferring to other components to get the job done.

But I think we may be talking at cross purposes here. I regard deriving from ServiceComponent as being not that different a kind of thing from being accessible via .NET remoting. But this is largely because that's how COM+ has always been used on projects I've worked on - it has sat at 'big' boundaries, usually network or process boundaries. Deriving from ServicedComponent seems to be making a strong statement: "This class sits at the edge of the system."

However, it sounds like you're using it on a much finer grained scale. But isn't this precisely the kind of situation that Services Without Components was designed for? They free you from the tyranny of the enforced base class. Deriving from ServicedComponent is not the most appropriate way of using COM+ here is it?

Or were you in a situation where you couldn't use Services Without Components? In which case you were forced to use an inappropriate mechanism.

If that's the case, this would be an example of where MI would provide an expedient hack because bad design has been imposed on you due to the constraints of the system. (And Brad provides another example of the same thing.) I'll buy that.

Do you have any examples of where MI is the most elegant solution, rather than merely a workaround to an unfortunately system? Even if MI were available, you surely wouldn't feel that the resulting solution to this, or to the problem Brad discusses, were ideal?

Ian Griffiths

# re: A plea for full multiple inheritance support in .NET@ Thursday, January 08, 2004 9:34 AM

Ian, I presented an abstract way of the problem, because that would avoid discussions like this. I gave an example, and the answers can be: "but you don't have to do it like this", or "the platform made an error there indeed". It's not a design error, nor a flaw from my side: the problem is generic: mixing 2 or more implementations of interfaces into a new class by BORROWING these implementations from the .NET framework. You can't do that now, you can only do that by doing extra work (wrapping aggregated object or re-implement an interface entirely). I don't call that 'advanced', it's 2 steps back, since C++, COM and ATL have that for years. Furthermore some errors in the framework may be there, the necessity for mixin implementations of several interfaces into a new object is not something that goes away if the design of .NET's framework is changed in some area's. The extra work stays, no matter what you do. In 2004, doing 'extra' work because some designer thought it would be complex to implement MI (generics are also complex, have multiple implementations in the field, still they add them) and 'no-one will use it anyway', is stupid. We're not in 1996 where computerpower was just beginning to increase. Mixin's will solve it forever, plus will opt for more abstract code, because you can write a lot of abstract classes you can finalize in the mixin class. I call that great use of OO. However in .NET I can't, I have to copy/paste the same abstract code over and over again because I can only inherit from 1 class.

Frans Bouma

# re: Serious ASP.NET Editor flaw lives on in VS.NET 2003@ Thursday, January 08, 2004 12:56 PM

I am also having issues with the .net HTML editor, in addition to the automatic formatting problem. Has anyone expereinced the disappearance of OnClick events, set in asp:imagebutton properties, upon saving HTML formatting changes in .net???

Diana

# re: A plea for full multiple inheritance support in .NET@ Thursday, January 08, 2004 2:08 PM

You did indeed, and thank you for your efforts.

The reason I asked for more specifics (and many thanks for providing these too) is mainly because I've heard any number of highly theoretical arguments in favour of MI, and found none of them sufficiently convincing to compete with my practical experience of MI. (And I have actually used it a great deal over the years by the way - you seem to have got the impression that I don't like it simply because I've never used it, which is not the case.) Many years ago, I did buy the theoretical arguments, but my practical experience with MI has mostly turned out a great deal less positive than the theory. So I'm always keen to hear of specific success stories from people who like MI more than I do.

So far my direct experience with actually using MI leaves me feeling that its use is usually a sign of trouble. Brad's example is clearly just another instance of this - he explicitly put forward his example as a workaround to a design flaw in ASP.NET. (The heavy use of mix-ins in ATL is arguably another example - it was there because you didn't really have any choice but to deal with lots of difference concerns in a single object, given the grungy intermingling of the COM binary interface model and the C++ object model implementation.)

I've changed my opinion on this one over the years. I went from not being able to fathom why it might conceivably be useful (that was about 10 years ago), to thinking it might be useful, to thinking it was great, to thinking that it's not so great. (And incidentally, I'm not so against it that I really don't want to see it in .NET. It's just not on my personal wish list.) That's where I am now, but I'd hate to get stuck there on account of closing my mind, which is why I sought your opinion.

(By the way, COM didn't have any kind of implementation inheritance at all last time I looked, so I don't think it's accurate to say that it has had MI for years.)

Anyway, thanks for taking the time to share your point of view!

Ian Griffiths

# re: A plea for full multiple inheritance support in .NET@ Thursday, January 08, 2004 4:05 PM

Saying that MI is not necessary is like an old-style C programmer saying you don't need C++ objects: hey, you can do the same thing with structs and well designed code.

It's about expressiveness in a language. If expressing the problem in MI makes it easier for me, it's necessary. If I perceive the MI solution as better, then MI is necessary.

If you don't share that perception, maybe your problem solving strategies are simply different from mine. Not necessarily better or worse, just different.

John Q. Public

# Great article@ Sunday, January 11, 2004 3:44 PM

This is one of the best blog articles that I've read in a long time, thanks. Remember "Make everything as simple as possible, but not simpler"? - As I see it, _not_ having MI is a case of over-simplification in the language/runtime. The over-simplification leads to unneeded complexity for the application programmers.

Troels Arvin

# re: Weblogs.asp.net / .Text screensaver!@ Monday, January 12, 2004 11:49 AM

Too bad. I am getting into the habit of doing a copy all before hitting the submit button. I got burned a few times when the next page crashed and doing a back got me back into a blank form.

Abdu

Abdu

# Diana - Yes @ Wednesday, January 14, 2004 2:46 PM

See my comment just above yours. This bug has bit me several times.

It really sucks to get a bug report from a client on something that worked yesterday.

Rip Ryness

# re: Stored procedures are bad, m'kay?@ Thursday, January 15, 2004 8:41 AM

What the hell are you saying???

Ericko

# re: Weblogs.asp.net / .Text screensaver!@ Thursday, January 15, 2004 11:00 AM

Any steps to do a clean uninstall? It's nice, but a total CPU hog on my machine.

Charles

# re: Weblogs.asp.net / .Text screensaver!@ Thursday, January 15, 2004 11:05 AM

Set the screensaver of windows to another screensaver, remove the directory you installed it in, done :)

It is a cpu hog, but you don't need that cpu when the screensaver is used ;)

Frans Bouma

# re: Weblogs.asp.net / .Text screensaver!@ Thursday, January 15, 2004 12:34 PM

Well, just wanted to make sure that removing the directory will leave it clean.

And yes, I realize that it's a screen saver :) and I shouldn't need my cpu when it's running, but:

1) My machine is also a web server (application development) which sometimes testers have to access

2) I'm one of those eccentrics (I always turn my machine off when not in use) that believe that every component has a lifetime. Working it harder will shorten that lifetime. I don't think that my system could benefit from the increased heat output of the CPU.

Very nice ss though (just a CPU hog)!

Charles

# re: Weblogs.asp.net / .Text screensaver!@ Thursday, January 15, 2004 12:40 PM

Ah I understand :)

Thanks, yes it is a cpu hog, it just runs around in loops to render as much frames as possible, calculating a lot of matrixes, sines, cosines and projected coordinates in each frame :) so the CPU has erm... a lot of work ;)

Frans Bouma

# re: A plea for full multiple inheritance support in .NET@ Friday, January 16, 2004 3:27 AM

Good discussion. I know i'm late to the party but i've got things to say. Will post that in detail. But do check out my earlier post about MI and my question to Chris Brumme on the same. Here's the link.

http://dotnetjunkies.com/weblog/unknownreference/posts/1401.aspx

Vijay

# re: A plea for full multiple inheritance support in .NET@ Friday, January 16, 2004 8:19 AM

The first commenter has pointed out the link where Brumme answers my question. Well in fact it's not a complete answer but he explains the reasons and difficulties on why it would be too hard to implement it in the .NET Framework. Check it out.

Vijay

# re: A plea for full multiple inheritance support in .NET@ Friday, January 16, 2004 9:55 PM

I too am joining the party late. It's an interesting discussion. As already mentioned, there are those situations where the .Net classes force you to derive from a .Net class to get the required functionality from the framework. This almost always means a duplication of some code. For example:

I wrote a set of DataValidator classes that I can assign to parameter, property, etc. via attribute programming. This requires that I derive from the .Net Attribute class. However, doing this precludes me from deriving from my own set of classes. I managed to get around the vast majority of it with very little duplicate code...but I still had to. Generics may help the problem but they will never be a total solution.

-Mathew Nolton

Mathew Nolton

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Friday, January 16, 2004 10:22 PM

Good points, I have been a Sybase/Microsoft user for years (sybase version 4.9.1 was my first...right b4 microsoft oem'd it). Recently I had the chance to work with Oracle pretty hard-core for about 6 months and I liked it. It took a few days of figuring what went where but the programming language (plsql) was overall much better an more intuitive the t-sql (it will be interesting to write c# with yukon but that's another train of thought).

I also don't buy enjoy the flamewars b/w the developers Oracle versus Microsoft. It makes great print but they are both very nice systems. A good friend of mine once said that to sell a lot of software you need 1,000 people loving you and 10,000 people hating you. I am sure the debates help both sides sell a lot of software for Microsoft and Oracle. (consider pepsi versus coke).

Frans, you make some good points but I don't buy the UDT argument. To me it appeared a poor mans implementation of an Object database. True. .Net does not handle UDT's so there benefit is truly limited and therefore they were difficult to explore....but does Java (i really don't know). If they are so nice why doesn't Oracle provide a means to serialize .Net objects in and out of the database (not a blob but an object)? That would be a killer application that would make me consider it a valuable service and possibly switching over to Oracle....

Per the comment made by "re" about Microsoft not being good for super high-end systems. I don't by that either. There are too many numbers out there that state otherwise. The MVCC debate is an interesting one though and one I will read up on.

-Mathew Nolton

Mathew Nolton

# re: Stored procedures are bad, m'kay?@ Sunday, January 18, 2004 12:50 PM

Being from the admin side of the planet, I've have to support applications that both use stored procedures and don't. "In My experience" applications don't perform nearly as well and have had to purchase more equipment to scale vs applications that use stored procedures. Now that doesn't say applications that use dynamic sql don't scale as well. I just have to live the pain everyday of throwing more hardware at enterprise applications that don't use stored procedures.

Steve Schofield

# re: What about Templates and Multiple Inheritance@ Monday, January 19, 2004 4:43 AM

TrackBack

# Followup: The Absence of MI@ Monday, January 19, 2004 5:31 AM

TrackBack

# re: In Defense of Stored Procedures@ Monday, January 19, 2004 6:54 AM

TrackBack

# re: In Defense of Stored Procedures@ Monday, January 19, 2004 6:54 AM

TrackBack

# re: Oracle 9i is only one generation ahead of MS SQL@ Tuesday, January 20, 2004 2:10 AM

I recently had a deep dive into the MS SQL Yukon pre-beta. This can reabilitate it a little:
1. It supports schemas independent of users; users can be granted various schema access
2. It supports snapshot MVCC, and a little better than Oracle does - while Oracle deals with versions on page level, MS SQL works with individual records. This means less data being copied when a record is being split
3. It supports synonyms
4. It supports UDTs. In the complete sense of 4GL languages - fields, methods and properties. It also allows, or course, CLR functions (scalar and table-valued), custom aggregate functions, stored procedures and triggers (both on DML and DDL statements). The promised optimizations in processing all those CLR stuff inside SQL queries are not ready yet, but I was looking to the pre-beta only, so I guess they will make it before the final MS SQL Server 9.0 is released. Thanks.

Sinclair

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Tuesday, January 20, 2004 11:05 AM

Sinclair, thanks for the update! It really looks promissing!

Frans Bouma

# Move away from stored procedures or not?@ Wednesday, January 21, 2004 5:23 AM

cannot we use table functions instead

Girija

# re: Thought experiment: Objectspaces will limit interest in O/R mapping@ Thursday, January 22, 2004 6:25 AM

Just a few random thoughts:

First of all, the fact that OS is used both in MBF and in WinFS IMHO show that MS has a lot of interest in this tool and that it is putting adequate resource to the problem. Much more than most of the 1-man-show-O/R mappers in the market can muster. I really have a lot of respect for people like yourself who can build such a great tool as LLGLGen (I never seem to get the spelling right :), so this is by no means meant in personal way.

Availability: Since the PDC many developers have access to OS in one way or another. I have met a fair number of people who don't have MSDN Universal, are not in the Alpha, haven't been to PDC and still have a nice copy of the Whidbey package sitting on their desktops, so I don't think that availability really is a problem.

Maturity: Many tools are called v1.0 when they are in fact v0.9b. Especially a problem with smaller companies. I am working for a small company, so I am not trying to dis small corps per se, it is just a matter of statistics.

Features: My impression is that OS covers >80% of the stuff that is needed for most people. No, it is not a be-all, end-all solution. In fact, no tool is and will ever be. Talking about Oracle, I am fairly sure that someone will use that Provider structure of OS and produce an OS provider for Oracle even before OS ships. It certainly is not a big deal to do that.

Price: OS is free. Kind of. Other tools aren't. So what? - I think most decent projects/companies can easily afford a couple 100 or even 1,000 bucks if the benefit is there. Many amateur programmers don't have that kind money, but they can always use Paul's tool (which is great, btw) :)

Monopoly games: When MS bought that Canadian CMS company a while ago, many MS-based CMS vendors and partners of MS were really pissed. I certainly was. But this is how life goes. In hindsight, it did not do much damage to the market as far as I can see. Some vendors lost some business and had to move their ass to innovate beyond the crappy MS CMS. Some did well, others failed. But the same thing would have happened if some brand-new Corp X suddenly came up with a new and brilliant CMS. So, I don’t think MS is going to ruin the O/R landscape by putting out a new (free) tool.

Result: I think O/R vendors have a tremendous opportunity ahead if the manage to innovate. Analyze OS as I am sure you already did, find the problematic areas, difficiencies and things that suck and build a tool that does better. Given your stance in the ‘community’ I think you will do pretty well!!

Marc Hoeppner

Marc Hoeppner

# re: Thought experiment: Objectspaces will limit interest in O/R mapping@ Thursday, January 22, 2004 6:47 AM

Just some answers:

::First of all, the fact that OS is used both
::in MBF and in WinFS IMHO show that MS has a

Since WHEN is Objectpaces used in WinFS?

Must be new news.

Thomas Tomiczek

# re: Thought experiment: Objectspaces will limit interest in O/R mapping@ Thursday, January 22, 2004 7:26 AM

If I remember correctly, I got that from Luca's presentation on the PDC, but I'll try to find a good quote somewhere.

Marc Hoeppner

# re: Thought experiment: Objectspaces will limit interest in O/R mapping@ Thursday, January 22, 2004 8:08 AM

::If I remember correctly, I got that from
::Luca's presentation on the PDC

If I got it right, they use the same API and query language, but ObjectSpaces is not really used as engine.

WinFS is imho NOT built on ObjectSpaces.

Thomas Tomiczek

# re: Thought experiment: Objectspaces will limit interest in O/R mapping@ Thursday, January 22, 2004 8:53 AM

Objectspaces will limit interest in 3rd party O/R mapping solutions.

Yes it will, unfortunately.

Paul Gielens

# re: Thought experiment: Objectspaces will limit interest in O/R mapping@ Thursday, January 22, 2004 8:54 AM

While I don't disagree that MS can kill competition I disagree that ObjectSpaces will result in O/R mappers going away. There is already a growing group of vendors/communities writing O/R mappers. Each one has its pros and cons - which ObectSpaces will have to beat or not be used. For me personally, ObjectSpaces will have to support more databases than SqlServer and Access.

We really have two classes of developers in .NET - the enterprise developer and the business guy who is developing. This is a huge generalization - but I would consider the business guy lost to MS - unable to explore beyond the namespaces that ship with the framework. What we have to be able to do as developers is sell the best of breed solution to our management, regardless of who the vendor is. It seems we so often fall into the trap of doing the easy thing and just using what is given to us by MS.

The enterprise guy is someone who reads a blog entry from a company president and is open to giving it a try - even when they have used an MS product for years, or sees a "N" infront of a Java project (Ant,JUnit,etc...) that they have used for years and realizes that it should be tried in .NET, or etc...

The enterprise .NET community is really growing, you can tell by some of the new sites popping up and better discussions on blogs. We are getting beyond the discussions of how do you drag a table onto a form. This is the group that will use any technology because it is superior - wether it comes from MS, Thona Consulting, or from SourceForge.

Don't sell the enterprise community short by saying MS will kill O/R mappers. If you develop a good product and put a good face out there it will probably find a market. Maybe the enterprise community can hollar loud enough to get MS to start producing open specs along with their products. Even though there are alot of complaints about the JCP, atleast it exists.

Mike Doerfler

Mike Doerfler

# re: Thought experiment: Objectspaces will limit interest in O/R mapping@ Thursday, January 22, 2004 9:12 AM

Guys, correct me if I'm wrong, but if the Java O/R mapping scene is vibrant and healthy, surely there'll be no end in sight to porting these same tools to C#, thereby keeping the.Net O/R mapping scene just as vibrant simply because it's so easy to do (porting I mean).

senkwe

# re: Thought experiment: Objectspaces will limit interest in O/R mapping@ Thursday, January 22, 2004 11:36 AM

senkwe,

Frans point is that since MS is providing OS for free in the Framework that most people will choose to use that or stick with DataSets rather than buy a 3rd party O/R mapper. I'd agree with that. I don't think we'll see a lot of O/R mappers, ported or created from scratch, once OS escapes....err...is released.

I think he makes a good point about OS being limited to SQL server. I think that developers that are used to doing O/R mapping using a framework and that need to use !MS SQL as their data store may look to 3rd party tools. But that will be MUCH smaller audience than exists now.

If I were planning on writing positive articles about O/R mapping, and I may if I can get off my lazy butt and write, I'd take the tact that you end up doing O/R mapping in your code whether you use an O/R mapper or you use DataSets. Show how it's easier to do that mapping using a 3rd party O/R mapping framework rather than in your application code, especially when it comes to refactoring your application.

Scott

# re: Thought experiment: Objectspaces will limit interest in O/R mapping@ Thursday, January 22, 2004 12:29 PM

I don't see why companies like Business Objects would be interested in supporting yet another layer. You might know that Business Objects is successfully implanting their semantic layer in the products since the early 90s. And a special layer already drives whatever database you might think on whatever platform. In this regard, supporting ObjectSpaces would be just another Business Objects driver.

I see ObjectSpaces as the "yet another ultimate universal data access canvas" that will be superseded by the next one. And those balls are rolling for a decade or so. I don't see why ObjectSpaces would become the de facto standard to access SqlServer in an object manner while there have been many improvements on the ADO.NET 2.0 side. And this, not to mention the xml queriers.

There is also one thing about ObjectSpaces and the like. Translating automatically an object-like query into an SQL statement is fine but there is just one problem : in the real world, there are many issues regarding really useful SQL statements used in data mining or so-called layers that insulate people from the technical intricacies of the database. And this lind of things involve aliases, integration resolution, loop solving, ... basically what a lot of products and data access layers are doing (the Universe in BusinessObjects's semantic layer). Unless I have missed something, there does not appear to be anything related to this in ObjectSpaces.

Stephane Rodriguez

# re: Thought experiment: Objectspaces will limit interest in O/R mapping@ Thursday, January 22, 2004 7:00 PM

You, of course, are assuming that ObjectSpaces sucks. However, quite to the contrary, ObjectSpaces blows away any O/R mapper currently available (even without any IDE support). OPath queries alone are a huge feature that every other implementation should have supported a long time ago.

Jesse Ezell

# re: Thought experiment: Objectspaces will limit interest in O/R mapping@ Thursday, January 22, 2004 7:01 PM

PS: Oracle, etc. support will come with time (and can be implemented by anyone). 99% of .NET developers are going to be running on SQL server anyway, so it is almost a moot point.

Jesse Ezell

# re: Thought experiment: Objectspaces will limit interest in O/R mapping@ Thursday, January 22, 2004 8:15 PM

At the PDC2003 a new, powerful framework for developing flexible business objects, called MS Business Framework (MBF), was presented. This framework will come as a layer on top of VS.NET and will be introduced with Whidbey Enterprise Architect at no cost. Many programming chores will be automated and with Orcas this automation will go even further. Here's the key point: MBF will be intimately tied to Object Spaces (OS). Therefore, my guess is MS will put a LOT of resources in improving OS with respect to features, speed, etc. because otherwise the MBF is doomed to fail and with it MS's grand vision of dramatically boosting programmer productivity. See the corresponding PDC video presentation at http://microsoft.sitestream.com/pdc2003/ --> click "Data Systems" --> click "DAT34o-Developing Apps Using the MS Business Framework".

Reto Caviezel

# re: Thought experiment: Objectspaces will limit interest in O/R mapping@ Thursday, January 22, 2004 8:22 PM

You, of course, are assuming that ObjectSpaces sucks. However, quite to the contrary, ObjectSpaces blows away any O/R mapper currently available (even without any IDE support). OPath queries alone are a huge feature that every other implementation should have supported a long time ago. Oracle, etc. support will come with time (and can be implemented by anyone). 99% of .NET developers are going to be running on SQL server anyway, so it is almost a moot point.

Jesse Ezell

# re: Thought experiment: Objectspaces will limit interest in O/R mapping@ Friday, January 23, 2004 3:17 AM

The "YOU" in your remark, Jesse, is that someone in the comments or is that me? If it's me, you're mistaken, I never assume things and say something else. I never said it sucks, so I don't assume it will suck totally. There are severe disadvantages of using Objectspaces over another O/R mapper tool.

OPath IS bad. It is not typed, it's strings parsed at runtime, which will result in typo's causing errors you'll only see at runtime (and after testing), while it can be done in a full typed way. I don't know what you mean by "that every other implementation should have supported a long time ago.", because every O/R mapper out there has an object query system using some sort of query language. A lot of them use strings which are parsed at runtime, some use 100% typesafe objects to construct the queries like mine.

Oracle will not be implemented by a 3rd party, simply because it requires changes to the query engine of objectspaces: it now cranks out SqlServer SQL which is totally incompatible with Oracle and for example sequenced fields require extra information that can't be stored at the moment in the objectspaces files.

Frans Bouma

# re: Stored procedures are bad, m'kay?@ Friday, January 23, 2004 12:24 PM

I came across this thread while looking for some concrete evidence on weather I should move my all to SPs or stop using SPs all together.

I have to say that this argument over performance, reusability, ease of change is very interesting but…..

Every time I have this discussion with my developer buds it breaks down into two camps; those that come from a classic programming background and those that come from a relational database background. Programmers want to proceduralize everything because this what they are used to. The database people what to use the power of the relational database to (as I term it) “let the data flow”. I come from both backgrounds; I started as a developer but then moved on to using case tools to do full life cycle development. Most of these tools require a firm model upfront so eventually I turned into a DBA and relational modeler.

What I am getting at is; stored Procs were included for classic programmers, people whom are comfortable with procedural programming.... i.e. I want to get result “C” but to get “C” I first need result “B” and I can only get result “B” if I have result “A” therefore I’ll write a proc that gives me A and then B from A and then C from B.
Views are for those who can think in a multidimensional way and can be a convenient short cut around this type of logic. I want “C” so I’ll just build a view that puts A and B and C together and gives me what I want. (or I’ll build a view that gives me “B” and then write a bit dynamic SQL to give me “C” from “B”)

I think it is really important to take this into consideration when we are talking about application performance. From the posts I have read, I don’t think everyone has been talking about the same thing. People need to specify if they are talking about SQL sever performance or total application performance. Let me give you and example, regardless of weather I use View or SPs what I want from my database will determine how I write the complete application. One of the posts I saw up above made a comment about how an SP could save you multiple round trips to a server. I assume that by this context this person is only familiar with writing very simple views and is not thinking that I might WANT to make multiple round trips to the SQL server. If I need the data separately and persist it on my application side then by far multiple trips is more efficient for my “Application” especially if I never get to the point where I need “C”. Now on the other hand if I only need it all and I made multiple round trips to the server for it yeah, it would be a waste of resources. My point is that from the point of view of the server, the calls are the same. It could SP-A, SP-B, SP-C, or View-A, View-B, View-C… I doesn’t matter performance is not a really a matter of SP versus View it is really a matter of application design. No SP or View or SQL Cache is going to go to save you if you application design sucks.

Use what you are comfortable with and what is appropriate, BUT don’t be afraid to try and use the other. Or use them together. There is nothing that says an SP cannot access a view or multiple views. I love SPs for things where it is appropriate, say.. deleting an entire object tree from the database. This requires a simple param or two, can hit 100 entities and doesn’t require anything other than a go from the application side. On the other hand if I need to aggregate data and get it out of the database, transform it merge it, filter it etc. etc. I’m going to use a view because it just makes more sense because this is what a view is for. Not only that but if I ever have to migrate to another platform (MySQL, Oracle) I can migrate my views in about 1/3 the time it will take to migrate an SP. I’ve done this, just try to migrate an SQL SP to Oracle… it’s not easy.

Ok my last point…. I promise… regardless of weather you use SPs or Views if you want to improve performance test it and look at the SQL execution plans, pick the best one and provide a pre set execution plan for the SQL server for the proc or the view. If you can determine the most efficient execution plan for either and provide this upfront, you will save the SQL server significant time in trying to figure this out when it as fallen out of the cache.

Justin Ohms

# Source Safe is slow when checkin or checkout a project from Visual Studio .NET@ Friday, January 23, 2004 1:06 PM

Besides defragmenting hard drives, slow hard drives, size of database on VSS. Is there any feature or option in Visual Studio .NET causing slowness when checking out a project from Visual Studio .NET.

Thank you
Hung

Rich

# re: My wish-list for the next Visual Studio.NET release@ Sunday, January 25, 2004 1:15 PM

Editor tabs in VS are displayed like tabs and behave like MDI Child windows. When you press control+tab, the focus goes to next in the "Z-Order" not to the next tab page!. This is confusing and is moving away from the normal working of Tab Sheets!

harry

# re: My wish-list for the next Visual Studio.NET release@ Sunday, January 25, 2004 1:23 PM

Oh! I forgot to add one more.
In Delphi *which is still better and easier component oriented IDE, according to me*, has very good Bookmark handling. You can press Control+Shift+<number 0..9> to anchor a bookmark and Press Control+<number 0..9> to go back there. That makes navigation very easy. I would really like to have that. Probably there should be an option to treat bookmarks across files, so that you can press Control+number to go to a book mark in another file (which may not be opened yet). And as Frans Bouma said, bookmarks must persistent with an option to clear them all, when you want to do it.

harry

# re: Thought experiment: Objectspaces will limit interest in O/R mapping@ Monday, January 26, 2004 9:30 AM

Whinning that MS "is thus killing businesses" is soooo lame. Write a superior product ( that supports the major RDBMS ...2 DBs is a joke) and there you be quite a few people that will be interested in it.

Gheorghe Marius

# re: Thought experiment: Objectspaces will limit interest in O/R mapping@ Monday, January 26, 2004 9:36 AM

You really didn't get the point of the article, Gheorghe.

It's about where developers START and where they eventually end up. Perhaps you think developers start with Google and search for "The" best tool, but most developers start with the MSDN docs and vs.net and only if that truly fails they'll look for something else.

Frans Bouma

# re: Thought experiment: Objectspaces will limit interest in O/R mapping@ Monday, January 26, 2004 8:13 PM

Actually Gheorge, LLBLGenPro is a superb product (and Frans didn't pay me a dime to say that!). Support for SQL and Oracle is great and not a joke at all, given their marketshare in the PC environment. You want support for tens of databases, go pay your $100 000+ to someone...

Further comments: O/R mappers are not just for enterprise shops. My small dev shop is benefitting greatly from using LLBLGen, as I am sure are other more lateral thinking businesses, employing O/R tools right now. Geez, O/R mappers save so much time, the benefits are immense.

I certainly won't be jumping over to MS OS V1 when it eventually arrives, as long as tools like LLBLGen are delivering the goods TODAY.

Don't give up Frans!!! (...or Thomas, or any of you other guys doing great work)

John Butler

# re: Thought experiment: Objectspaces will limit interest in O/R mapping@ Tuesday, January 27, 2004 3:47 AM

Hi John! :)

We won't give up, don't worry :) O/R mapping is a great technology, and once you've used it, there is no way back :)

Frans Bouma

# re: Stored procedures are bad, m'kay?@ Tuesday, January 27, 2004 1:51 PM

I use stored procedures exclusively. No one is allowed direct access to the tables. Here's why:

1) Using inline (or 'dynamic') SQL, you assign permissions for a give table for select, insert, updates and deletes. When you give select permission to a user/group/role, you allow them to execute whatever they want against the table (or tables). By using sprocs, you keep a newb from opening access (or excel for that matter) and running a cross join that takes down your entire production server.
2) SQL injection - If you run inline sql and aren't scared of this, well, you should be using access anyway.
3) Complexity - In a big datashop, a two table join just ain't gonna cut it. Try setting isolation levels, nested transactions with save points and doing server side performance traces.

Dynamic SQL has it's place. Usually it's in smaller projects that don't have security, performance or ACID concerns.

Darren Fix

# re: Stored procedures are bad, m'kay?@ Tuesday, January 27, 2004 8:05 PM

Everyone seems to be ignoring the performance tuning aspect of this debate. Its very difficult to evalutate index usage when all of your data access code is in the middle layer. So much for tuning your indexes.... Also, since so many people have refernece the MS SQL server docs, you might all be wondering what Microsofts position is on this debate: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/optimsql/odp_tun_1a_6x45.asp

Mike

# @ Tuesday, January 27, 2004 11:40 PM

TrackBack

# @ Tuesday, January 27, 2004 11:42 PM

TrackBack

# .NET Reality Check - a matter of 'Pragmatic R@ Wednesday, January 28, 2004 2:19 AM

TrackBack

# .NET Reality Check - a matter of 'Pragmatic R@ Wednesday, January 28, 2004 2:25 AM

TrackBack

# re: .NET Reality check, my €0.02@ Wednesday, January 28, 2004 5:42 AM

Valid point, although I think a lot of effort does goes into current-version-software support - but not necessarily on the weblogs.

Snorrk

# re: .NET Reality check, my €0.02@ Wednesday, January 28, 2004 5:47 AM

If that's true, why isn't it showing? Can you point me to a set of fixes to problems in .NET 1.1 or better: vs.net 2003? I can't.

Frans Bouma

# re: .NET Reality check, my €0.02@ Wednesday, January 28, 2004 6:15 AM

Hmm...well, Weblogs are not really 'customer support forums' - in the actual newsgroups and ASP.NET forums, MS employees pretty much exclusively talk about .NET 1.1 - I do agree that there's too much emphasis on MSDN to do with Longhorn and Whidbey (for Longhorn at least, this is probably the whole marketing ploy thing - trying to increase the number of Longhorn apps way in advance of launch to increase the 'critical mass' for product launch).
For Weblogs however, MS employees are in no way obligated to provide support in any capacity, they are however talking about the cool new technologies they work with (as we all are) - they just happen to be working with technologies that most of us won't be using commercially for 2-3 years yet...

Scott Galloway

# re: .NET Reality check, my €0.02@ Wednesday, January 28, 2004 6:18 AM

Good point from Frans though...I've seen lists of bugs, but very few 'here's the bug' and 'here's how to fix it' type posts (usually have to trawl through dozens of Knowledgebase articles which are only vaguely related then discover I have to call PSS to get the fix - which I can't redistribute to my clients...). On the bright side, .NET Passport is WAY worse...it doesn't even work properly on .NET Server 2003!

Scott Galloway

# re: .NET Reality check, my €0.02@ Wednesday, January 28, 2004 6:25 AM

Scott: I don;t consider weblogs as 'support', though they add to the hype building, but I don't consider them the cause of the frustration, the general channels towards developers are the cause of it (PDC, DevDays, MSDN etc.) and the lack of support which IS there. I read the C# newsgroup mostly (and the ADO.NET newsgroup) and I never see an MS employee explaining things in the ADO.NET newsgroup and rarely in the C# newsgroup. It's on the shoulders of the MVP's and other volunteers however these people can't fix broken code in .NET. Reading the VS.NET newsgroups is even more frustrating. I mean, if you count the amount of threads about the project listing on the start page in vs.net, you'll be stunned.

Frans Bouma

# re: .NET Reality check, my €0.02@ Wednesday, January 28, 2004 9:09 AM

I agree that the current crop of problems need to be fixed. Where is the ASP.NET 1.1 update that has been talked about in the support knowledge base for at least 6 months? You have to call MS support to get it. That's where the problem.

However, I disagree on some other issues. I don't object to MS talking about Yukon, Whidbey, and Longhorn though. As a customer I want to know what MS is doing and the directions that they are headed in. They have never said that Longhorn was right around the corner. All signs have pointed to 2005 or 2006 for a release. I have heard unofficial talk of release dates on other products, but I have not heard anything definite from MS. Anyone that has seen Whidbey and Yukon knows that MS still has a ways to go. They have alwaysed used the term "When its completed" to state when they are planning on shipment. I think that doing that is healthy for the community and helps me as an author and developer know where things are going, what to concentrate on and what not to. I do not object to this type of marketing provided MS is providing code samples, bits, and suggestions. That is the best way to market to a developer.

Wally

Wallym

# re: .NET Reality check, my €0.02@ Wednesday, January 28, 2004 10:52 AM

Too often the examples provided by MS are trivial.

Design time support in VS.Net is a great example of this.

I can't sell designers (people) on the idea of something that says "[This is the control]", they wont accept it.

I read Nikhil's book recently and it was a great review, but there could be a book that size just on design time.
Lots of people here have read the book, and they make controls that display "[the control is here prop1 = someVal]"

I have gone down the rabbit hole with designers.

It is commonly believed that you cannot get at the web config at design time and yet to do so is trivial once you realize how.

AndrewSeven

# .NET Reality Check...@ Wednesday, January 28, 2004 12:16 PM

TrackBack

# Keeping up with Microsoft.@ Wednesday, January 28, 2004 2:24 PM

TrackBack

# re: Stored procedures are bad, m'kay?@ Wednesday, January 28, 2004 4:32 PM

Effective system design is never a 1-size fits all. To be an effective application architect you need a full set of tools in your tool-belt. Otherwise, if you all have is hammer, everything looks like a nail.

Never say never. Use the appropriate technology for the job. Appropriate has a lot of meaning here, standards and common techniques are important in a large organization.

Small one-off business needs can often be met quite cost-effectively with tools like MS-ACCESS. (Even though I don't want to be an ACCESS programmer, my personal choice is rarely in alignment with the goals of the business)

The one thing that really gets me the most, is that when some folks talk about 3-tier design, they really only include the middle tier and the client interface, and simplify the database server to the role of 'persistence'.

If you aren't maximizing the capabilities of all 3 tiers how can you call this 3-tier design? (Isn't it really 2-tier design that comes along with a database...for reasons that aren't very clear to some Java guys who prefer flat files!)

Dave

# re: .NET Reality check, my €0.02@ Wednesday, January 28, 2004 8:37 PM

I don't mind the weblogs talking about future tech, or the hype at PDC, TechEd, newsgroups etc... What I mind is the saturation and promotion at microsoft.com. The fact that the old tech suddenly "sleeps with the fishes" and is persona non grata in the resources we use every day. Not to mention the obvious manipulation of the search engines at MSDN.

weird huh? I made similar comments over in Korby Parnells comments.
http://weblogs.asp.net/korbyp/archive/2003/12/16/43952.aspx

"<rant>I'd like to point out that of the top 3 "Technical resources" links that search.microsoft.com returns, 2 of them are for Whidbey. Which isn't even out yet?!

That's the biggest problem with searching MSDN, every time Microsoft puts a fricken app into beta suddenly that's all you can find at MSDN. Information about the new tech that we can't use yet. That's great that you are giving us new information that we'll need in the future. But what about now? I'm not using Whidbey now, I'm using 1.1. I've even got Longhorn and Indigo crap turning up in my searches and that won't be out for 4-6 years! I dont' need to see that. </rant>"

P.S. quoting myself? Where will the ego stop!?

Scott

# re: .NET Reality check, my €0.02@ Wednesday, January 28, 2004 8:42 PM

(This is my opinion and my opinion only, and has nothing to do with my employer’s opinion. This post is presented as is and all the usual legal warning…)

I don't really agree. "Hype" tends to imply some sort of marketing buzz, which purpose is just to get people excited about partial information. I do think there is a deliberate marketing effort put into "hyping" Whidbey from Microsoft, I also believe most of it (in this community at least) comes from MS employee on their blog that just talk about their job and what they're doing. They don't hype "the future", they talk about their present and what they are doing every day of the week. I completely understand that what they're talking about is often months away or more and this is the source of a lot of frustration. But this is a radical change from the past where MS would just keep everything more or less secret until quite late in the development cycle.

I also get the frustration of making every answer to most problems “the next version is going to solve that”. For the most part, working on the web minimize that problem: upgrading and evolving software can be a continuous process. You develop an improvement to the current version; you can just deploy it to the server. The dependencies are minimal.

So why does it end up being like that? For the most part, I think this is due to the nature of shipping “shrink wrapped” software. When we code a given version, at some point we say “stop” and we don’t add any new feature, we stabilize the code for a while, then we branch the tree and ship a beta. At this point we have two branches, the current branch to which we start to add new things again and the “beta branch” we’re trying to get stable enough to publish. The fact that we have to stop adding things to get the software above what we think is the quality bar for a release creates the “it’s all going to be better in the next version” problem. We don’t touch the beta version, except for bug fixing and as we’re getting closer and closer to the ship date the bar on what’s an acceptable change keeps rising until we only accept critical fixes (security is a good example).

Meanwhile the other version is already far along and moving thing from one branch to the other is very time consuming since a lot of things have moved and changed. So once the software is shipped, and to be honest, even once it’s in the beta stage; it is very costly to do something about an issue in any other place than “the next version”. That’s the precise reason why we want people to take the opportunity to review what we’re doing before reaching that point.

I am not sure I made my point clear enough for everyone to understand :) And I am not sure my English is very good today either... but in the end I think it's all a matter of balance in the way we present things. We tend to get excited about the work we do (I mean, show me a programmer who isn't?) and thanks to blogs some of us are now talking directly to the public. But I believe that's the cost of getting the raw information and being able to participate in the feedback loop early on. Is that "hype"? I personally don't think so. Do I like it when people get excited about what we're doing in Whidbey? I sure do and it's a great motivation.

Julien Ellie [MSFT]

# re: .NET Reality check, my €0.02@ Wednesday, January 28, 2004 8:50 PM

Oh, btw, reading answers that came while I was typing this message I completly agree that when you search for something on MSDN, beta software should be in an independant section and you should be able to limit your search to "current technologies only" easily.

Once again I think this comes from a different reality for MS employees and other developpers. For MS the present IS the next version and when you're burried every day in whidbey stuff, you're excited about it, it really takes an effort to step back and realize that most of people are using Everett. I personally think this is something we need to work on harder in the future and your post is a great way of making us realize that.

Julien Ellie

# re: Thought experiment: Objectspaces will limit interest in O/R mapping@ Thursday, January 29, 2004 8:43 AM

@Frans w/ regards to your reply to Gheorhe:

It is true that many developers will start with OS in the future, simply because it is 'free' and 'there'. But the same is (was) true with LLBLGEN and other tools. (Of course one didn't find it in MSDN, but these tools are easy to find in Google and/or newsgroups). And IMHO OS will be fine for many of them.

BUT: there are still a lot of developers out there who may or may not be interested to go beyond what OS offers to them. You named quite a few deficiencies yourself. Unless MS changes that in their finally release, I believe that many developers will first try OS, release the problems, make a decision to look for something else and indeed end up opening Google and/or ask for help in the newsgroups to look for 'O/R' and other keywords...

Marc Hoeppner

# MySQL and .Net@ Thursday, January 29, 2004 9:59 AM

TrackBack

# re: .NET Reality check, my €0.02@ Thursday, January 29, 2004 7:32 PM

I'm also getting a tired of the whole FVPS (Future Version Promotion Syndrome) going on. It's not just MSDN, it is also GotDotNet, ASP.NET and countless other websites trying to show how cool and on-the-ball they are by publishing articles on all the great things we'll be able to do....one fine day, subject to countless features changes and things that got dropped because there wasn't enough time to put them in etc.

Enough already....keep us informed, yes....swamp us with endless articles on how cool the "new" stuff is compared to the current version us schmucks have to use is...no!

John Butler

# re: Hostile attitudes@ Friday, January 30, 2004 6:33 AM

This is really great! I'm dutch too and as you I don't speak/write English that well. I can understand most English movies without subtitles but when people use not often used words or technical stuff, I get confused. And I never use those 'difficult' words myself, because I just never think of them.

Anyway, I just think people can't handle the truth. I always hear on projects that we're all professionals and that we should be able to take criticism. But believe me, not many people can. For me, I like it. Sometimes I too feel offended, but then think about what I gain when I take the advice of the other person.

Ofcourse, sometimes people can be a little rude. I don't think you are. At least not on a level where people should feel offended! :)

Dennis v/d Stelt

# re: Hostile attitudes@ Friday, January 30, 2004 6:55 AM

Frans, I have found you to be hostile and misinformed when posting about my code generation tools. For example, <a href="http://weblogs.asp.net/pleloup/archive/2003/06/17/8802.aspx#16797">this comment</a> you left on this post about nTierGen was just wrong. I am all for competition, but I do not believe in just belittling the competition without even researching it first.

Gavin Joyce

# re: Hostile attitudes@ Friday, January 30, 2004 7:06 AM

Perhaps you should add, Gavin, that you didn't nor don't leave any oppertunity pass by to promote your tool as god's gift to mankind. We had our discussions in the past, I haven't forgotten them.

The comment you link to I make a 1 sentence remark about your tool and I still think it's a correct remark. The rest of the comment discusses the 'n-tier' term which should be seen as a general term instead of be seen as a tight set of rules (i.o.w.: if I think n-tier means something else than you think it means, I can)

If you can't stand me being honest about my opinion about the code your tool produces, Gavin, I'm sorry, but I'm not shutting up because you can't stand criticism. Perhaps you've improved it in the period passed, after all the comment is rather old and the version I tested was even older.

If you're one of these persons telling others how rude I am, I'd like to ask you to tell me first in the future instead of talking to others about me.

Frans Bouma

# re: Hostile attitudes@ Friday, January 30, 2004 7:10 AM

<goldmember>I'm Dutch! Isn't that wieeerd?!?</goldmember>

Goldmember

# re: Hostile attitudes@ Friday, January 30, 2004 7:22 AM

Dutch here as well, i completely understand what you mean

One side effect of this is: when a native-english person WANTS to be hostile towards you we could interpret it as normal... :p

David Cumps

# re: Hostile attitudes@ Friday, January 30, 2004 7:40 AM

Frans,
The problem is not only language, there are also large cultural differences between English speaking countries.
The British are more able to give/receive criticism and less able to be complimentary and pat each other on the back than the Americans, so both perceive praise and criticism levels differently.

Daren

# re: Hostile attitudes@ Friday, January 30, 2004 7:51 AM

Frans said - "If you're one of these persons telling others how rude I am, I'd like to ask you to tell me first in the future instead of talking to others about me."

I came across your blog entry today, and left a comment. No more, no less.

Frans said - "Perhaps you should add, Gavin, that you didn't nor don't leave any oppertunity pass by to promote your tool as god's gift to mankind."

Emm, I don't really know what to say. I have never held these beliefs.

I just wanted to point out that your comments were on an early beta version of my tool, the version at the time was v1.3.

I think your reply to my comments have validated that fact that you have a Hostile Attitude.

Gavin Joyce

# re: Hostile attitudes@ Friday, January 30, 2004 8:01 AM

It's not just the cultural difference, it's a person's attitude and background. You are mostly very outspoken about things, and that's your right to be. But when opinions are presented like that's the only truth, and there can be no other thruth, you reveal you beta-background. As a result, your statements can be considered bold, not hostile per se, in any language. My alfa-background tells me that my view on reality is only my view, and I appreciate and investigate other views as well. At least I try to...
Oh, I'm Dutch also as you may know.

Sander

# re: Hostile attitudes@ Friday, January 30, 2004 8:03 AM

Gavin, you point to 1 comment I wrote in june 2003. That's then your proof I have a hostile attitude, because that's what you said in your first reply in this blog.

I don't know what to answer to that, other than to recall some of the discussions we had in the past, which weren't friendly I admit. I can only conclude that you added that single line I wrote to the old discussions and made that the basis for your conclusion: Hostile Attitude.

You then take my reply here and use that too for your conclusion. I can only say: that's your opinion. You say you just left a reply, no more no less, but I doubt that, as you can't deny what happened in the past.

"I just wanted to point out that your comments were on an early beta version of my tool, the version at the time was v1.3."
No, you didn't point that out, you linked to 1 line of text which said something bad about your tool to show that what I say is a result of a hostile attitude. Btw, I didn't test the 'early beta' I tested the 1.1 version if I'm not mistaken

Frans Bouma

# re: Hostile attitudes@ Friday, January 30, 2004 8:08 AM

Frans said - "Btw, I didn't test the 'early beta' I tested the 1.1 version if I'm not mistaken"

You are mistaken. You original comment stated -

"My comment on the nTiergen code was more towards that it seems very 'hacked together' (at least to me). I've betatested it, and it fell apart a lot, however some ideas were good. "

You tested a beta.

Frans said - "I can only say: that's your opinion [that you have a hostile attitude]"

Yes, this is my opinion. Thank you.

Gavin Joyce

# re: Hostile attitudes@ Friday, January 30, 2004 8:13 AM

Sander: with the risk to brag, I can say I'm really good in what I do: writing software. That's not because I was born that way, but because of education and a long period of experience. I'm not the average employee who sits his hours in an office waiting to go home, I spend 12+ hours per day on my profession. That makes me, IMHO entitled to have an opinion about things related to my field which IMHO can be seen as an opinion which might be close to a reality (different POV's can result in different realities, see economics for that :)). Therefore I don't see my opinion about stuff in my field as just an opinion anymore. That's very arrogant perhaps, but I'm not every day's nittwit with a keyboard.

HOWEVER I do know where my weaknesses are. If you've read Eric Sink's article on MSDN, you know that if you want to keep your business, you have to know your weaknesses. A couple of years ago, I'd argue that my opinion about a random topic was how it truly was, but that's of course stupid. So what you say about appreciating input of others, investigate further until a view is formed/expressed, that's something I try to do too on areas I'm a dumb newbee, or in areas where I'm not an expert but a novice at best.

However, it's sometimes hard to be outspoken and not be seen as an arrogant bastard, even though you're right. I think that's life, and I'm comfortable with that, however when I do my best to not to be blunt or impolite, which is in the vast majority of messages I write, it IS hard to face conclusions like "Hostile attitude". I'd like to know where these conclusions come from. :)

Frans Bouma

# re: Hostile attitudes@ Friday, January 30, 2004 8:18 AM

Gavin, do you have a problem with the conclusion I wrote down or do you have a problem with my attitude? Do I have to dig up the stuff you said about LLBLGen?

If you have a problem with a conclusion I wrote down, you can write me, my email address is well known and I believe you even have it. I then can take the time to elaborate it, ask it to be withdrawn, give an appology etc. However you never did that. You simply read it, and drew conclusions which seem to be valid till today, and which are based on a few blog replies apparently.

Frans Bouma

# re: Hostile attitudes@ Friday, January 30, 2004 8:27 AM

I've personally learned a lot from both you Frans and Thomas, so I very much thank you for the debates. I appreciate boldness, although sometimes all of us bold guys don't leave much room for a different view. Note that I didn't say you were hostile -- I said others have said that, although maybe I shouldn't have repeated it in those words. I think of your debate with Rob as a great example where most readers never had a clue that you were talking about O/R mappers -- it just appeared that you were taking on Rob to many. I learned once again from that discussion, but you failed to get the simple message across -- which you should appreciate since you also came from the stored procedure side of the fence. Anyhow, I do very much appreciate your bold words, even those about the simpleness of my tool since that is very true -- what's not true (which you didn't say) is that I'm ignorant just because I made different design decisions. One last thing, I do tend to forget that you and Thomas and others are not native English speakers, which must be very difficult, so I'll try to be more understanding, but just keep in mind that you have many readers that also never consider this aspect.

Paul Wilson

# re: Hostile attitudes@ Friday, January 30, 2004 8:36 AM

Paul: I think the debate with Rob was for some a reason to think I'm an arrogant prick. However Rob was wrong in a lot of things he said and admitted that later on. I could have written the texts smoother, not that bold, but I think that enough has been said about a lot of topics, like how stored procedures are supposed to be great or other 'holy war' material :) and I think it's time to put an end to a lot of myths out there in our field. Writing a bold, outspoken article can then indeed be a reason for others to believe that the writer has a hostile attitude. Thanks for reminding me of that discussion, I think some people's conclusions can be traced back to that discussion I think.

Frans Bouma

# re: Hostile attitudes@ Friday, January 30, 2004 8:45 AM

Paul rubs me the wrong way at times too, so I wouldn't sweat it. He frequently comes off intolerant of noobs, but it's something I try to overlook because he generally has some good things to say.

jeff

# re: Stored procedures are bad, m'kay?@ Friday, January 30, 2004 9:30 AM

Well you argue your point very well. So long as your goal was to arbitrarily manipulate facts and data to simply propogate your own personal ideal. The problem with this train of thought, is that you are trying to place a global solution blanket over all problems and this automatically diminishes your effectiveness in the IT industry. You see, the simple truth of the matter is, dynamic sql, in-line sql, and stored procedures all have their place in todays application world. I have spent the better part of the last 6 years working on large scale web applications with million+ count user-base and I can tell you from research and real-world observation and study, that stored procedures are not bad. In two specific applications, we received a 15% performance improvement just by changing from dynamic sql to stored procedures. Despite what you say, maintenance nightmares exist for either method, you simply chose to ignore those of dynamic sql and focus on those of stored procedures. Dynamic sql simply is not as fast, is not as secure, and has just as many (if not more) maintenance issues as stored procedures. But.... some applications don't require that and based upon the needs of a particular application dynamic sql may indeed be the better option. Be careful throwing around blanket statements especially without real-world examples and observation from BOTH sides of the street. Your clients will appreciate it as well.

Brian Duncan

# re: Hostile attitudes@ Friday, January 30, 2004 9:36 AM

It's often hard for people to deal with someone who points out obvious mistakes, people tend to take it very personally.

I myself haven't had much problems with Frans' direct approach (maybe because I'm Dutch too :) )

Thomas on the other hand can be quite rude, even to potential new customers (which made me decide not to buy his tool...), so I agree 50% with Pauls remarks.

Peter

# re: Hostile attitudes@ Friday, January 30, 2004 12:00 PM

I find that Frans's very direct approach is one of the few things on these blogs that will really start up dialog.

I love stored procedures and yet I really appreciated everything that came out of that (nearly flame war) discussion about SPs and dynamic SQL.

I'm sure that everyone who followed those threads learned something.

ps Frans , I don't think your english is bad at all.

AndrewSeven

# re: Hostile attitudes@ Friday, January 30, 2004 2:06 PM

Frans, your blog is on my a-list along with 25 others. I try to keep up with your blog entries.

On this thread or on Paul Wilsons, I saw a comment about lacking professional courtesy, and I have to say that I agree to some degree.

I think you present your arguments strongly and clearly, and I seldom disagree with the content (I can't remember if I have ever disagreed). Recently I posted a "sideways opinion" about support for current .NET coding, because I actually agree with you - that too much emphasis is being placed on future technologies. But I disagree that MS is doing little about helping us to use today's technologies. Less than they need to do? Perhaps. Nothing? Far from it.

At any rate, you gave the example above that if you say "You're wrong." you could be perceived as hostile. A suggestion that I was given many years ago about the way to provide criticism constructively is to precede your comments with "I think". So, "I think you're wrong" is different from "You're wrong." You could say that when you are writing from your own perspective, the "I think" is implied, but that is probably only in your own head. If you actually say or write it, it leaves the reader with room to decide for themselves that they agree or disagree with you.

Someone else said there is little room for others opinions when you establish a position. I think your readers will feel more comfortable with your comments if you start them with "I think".

(Repeat the previous sentence to yourself, omitting the first "I think" and see for yourself.)

Mike

Mike

# re: Hostile attitudes@ Friday, January 30, 2004 2:23 PM

Good suggestion, Mike. Thanks :)

Frans Bouma

# re: Hostile attitudes@ Friday, January 30, 2004 4:06 PM

1-2-3-4, I delcare a blog war! ;)

Funny, I always thought Thomas was from England; An assumption I made based on the contact info for the company hosting EntityBroker.

I never picked up on a hostile tone in the comments you left in Paul Wilsons blog, although it did seem like you were picking on him. Every time he made a post, you were right there tearing it apart. I thought you were using a "I've been there, here's what I've learned" tone though.

I picked up some advice from posting on the BBS's a long, long time ago. Always post your messages with the same language and tone that you would want used if someone were talking to you in person. Would you want someone to tell you to your face "You're arrogant and wrong, here's why you're an idiot."? You can also think of it like this: Pick your words as if you were saying them to yourself in person. I'm about 6'4" and built like an ex-NFL lineman so I pick my words VERY CAREFULLY. ;) I wouldn't want to be rude to me in person. (btw I started typing this comment at about 9:30AM Pacific Time I think and I'm just now submitting it at 1:05 PST. I wanted to make sure I chose my words right.)

A rule of thumb that works well for all forms of electronic communication is to always wait and re-read your message a few times before hitting "send" or "Submit". If you're angry, save the message aside and re-read it later when you aren't angry anymore. You'll probably want to edit it some. (I'm not saying that Frans doesn't put a lot of into his posts or posts when he's angry. Just a general comment)

Scott

# re: Hostile attitudes@ Friday, January 30, 2004 4:15 PM

::Funny, I always thought Thomas was from
::England

German. As german as a german can be.

::An assumption I made based on the contact
::info for the company hosting EntityBroker.

Europe: you select the legislation for your company not based on what country you live in :-)

Thomas Tomiczek

# re: Hostile attitudes@ Friday, January 30, 2004 6:44 PM

THis thread shows that although we live in a global village, there are still cultural differences between us!

Here in England, we pussy-foot around each other with politeness, over on the Continent, people tend to be more direct and frank with each other. In the US, for people who regard free speech so highly, people can be surprisly sensitive at times. Generalising of course, but more often than not, it holds true.

Added to that, I would suggest that some people might mistake passion, for something else. Both Frans and Thomas are passionate about O/R, and leap into discussions about OR quite quickly and readily. Maybe this is what has ruffles some feathers.

It shouldn't though, after all most New Yorkers tend to be more "in-your-face" and forthright than someone from the Mid-West...but that doesn't usually stop people from either place communicating effectively with each other.

I guess what I am saying is, knowing the background and context that people have, can help one to better understand what it is they are trying to say...not how they are saying it!!

Ps. I own both LLBLGenPro, as well as a subscription to Paul Wilson's website (love those MasterPages!), so you can call me neutral on this one!

John Butler

# re: Hostile attitudes@ Friday, January 30, 2004 7:21 PM

I just asked my girlfriend to read this because I was fascinated to know how it would come across to someone who's never had any kind of contact with you before.

You might be interested to know that she thought your (Frans) response to Gavin's first comment was extremely hostile...

(Incidentally, she worked for a long time for an internet community which was English language based but which had sizeable Dutch and German communities. She says that most of these people didn't come across as hostile, even in very heated discussions. So evidently it's not something she feels about all Dutch people.)

As for me, I'm not so sure it has that much to do with language, but I'd like to test something. You gave the example of "You're wrong". Now in English, there's a *world* of difference between that and "I think you are wrong." Does this distinction not exist in Dutch? It would surprise me a great deal if that were the case, because to me this doesn't come across as a simple case of nuance of language. It actually has a very clearly different *meaning*, and that's the main reason that "You're wrong" can be very offensive when "I think you're wrong" typically isn't.

The distinction between the two is that by saying "I think you are wrong", you are dealing with opinion. By saying "You are wrong" you have left the realm of opinion and are accusing the person of being somehow at fault.

By using the phrase "I think you are wrong" the speaker leaves space for the fact that they respect your right to hold the opinion. But to say "You are wrong" does not. In English this is not a matter of nuance, it's simply that the two statements mean different things.

If this distinction doesn't exist in Dutch, then it might explain why you sometimes come across as hostile.

Of course if you genuinely feel that other people's opinions are worthless, then go right ahead - you're using the right language.

Ian Griffiths

# re: Hostile attitudes@ Saturday, January 31, 2004 5:23 AM

Ian: Gavin and I had a long 'war of words' in the past, I'm not surprised he's not that friendly towards me and I'm sure he's not surprised about my reactions towards him.

We have a different word for 'you' if you're not on first-name terms with that person you mean by 'you'. So we have 2 different sentences for "You're wrong". Of course we can say "I think you're wrong", however in the following situation no dutchman would say that:
person A: 1+1=3
person B: You're wrong.

I asked my wife about this, she's a writer and a language-geek ;), and she said that men more tend to say "You're wrong" (in dutch) than "I think you're wrong". To me, if someone says to me: "I think you're wrong", I think.. you don't know it for sure? :)

So, the rules for showing respect / politeness are different, at least that's how I see it, even between english speaking countries as it seems.

But a wise lesson for me has been: "Add 'I think'", even though I definitely know I'm right. (which is hard for me to do, but I'll try :)) and I have made a mistake in the "can you give me the book" example, I should have said "Could" :)

It's perhaps also a bit about how you look at things. If I read a book about programming for example, I don't expect "I think" sentences, I expect that the writer thinks he's right and that every sentence in that book contains truth. Is that different with a

Frans Bouma's blog

This Blog

Syndication

Search

Tags

News

Navigation

Archives

About me

Fun stuff I created

My work

Comments

# re: I'm alive!@ Monday, May 05, 2003 11:04 PM

# re: I'm alive!@ Monday, May 05, 2003 11:06 PM

# re: I'm alive!@ Monday, May 05, 2003 11:55 PM

# re: I'm alive!@ Tuesday, May 06, 2003 12:05 AM

# re: T-SQL Tip of the day@ Tuesday, May 06, 2003 6:48 AM

# re: T-SQL Tip of the day@ Tuesday, May 06, 2003 7:12 AM

# Frans Bouma's blog@ Tuesday, May 06, 2003 7:59 AM

# re: T-SQL Tip of the day@ Tuesday, May 06, 2003 11:37 PM

# re: T-SQL Tip of the day@ Tuesday, May 06, 2003 11:44 PM

# re: I'm alive!@ Wednesday, May 07, 2003 1:59 AM

# re: I'm alive!@ Wednesday, May 07, 2003 3:19 AM

# Emitter@ Wednesday, May 07, 2003 4:03 AM

# ShowUsYour-Blog!@ Wednesday, May 07, 2003 4:28 AM

# re: It's not all bizznizz apps@ Wednesday, May 07, 2003 11:11 PM

# ISerializable@ Thursday, May 08, 2003 3:54 AM

# re: Borland's prices are too high?@ Thursday, May 08, 2003 6:31 AM

# re: Borland's prices are too high?@ Thursday, May 08, 2003 11:40 AM

# re: Relationships@ Friday, May 09, 2003 3:32 AM

# re: Relationships@ Friday, May 09, 2003 3:40 AM

# ISerializable@ Friday, May 09, 2003 6:30 AM

# re: XPath in T-SQL?@ Saturday, May 10, 2003 4:43 AM

# re: Relationships@ Saturday, May 10, 2003 5:36 AM

# re: XPath in T-SQL?@ Saturday, May 10, 2003 12:31 PM

# re: XPath in T-SQL?@ Saturday, May 10, 2003 8:51 PM

# re: Relationships@ Saturday, May 10, 2003 8:58 PM

# re: XPath in T-SQL?@ Monday, May 12, 2003 2:44 AM

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 13, 2003 2:15 AM

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 13, 2003 2:42 AM

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 13, 2003 2:53 AM

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 13, 2003 6:23 AM

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 13, 2003 8:05 AM

# re: Stored Procedures vs. Dynamic Queries.@ Tuesday, May 13, 2003 9:56 PM

# re: Stored Procedures vs. Dynamic Queries.@ Tuesday, May 13, 2003 10:17 PM

# re: Stored Procedures vs. Dynamic Queries.@ Tuesday, May 13, 2003 10:20 PM

# re: Stored Procedures vs. Dynamic Queries.@ Tuesday, May 13, 2003 11:36 PM

# re: Stored Procedures vs. Dynamic Queries.@ Tuesday, May 13, 2003 11:47 PM

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 12:13 AM

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 12:21 AM

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 12:27 AM

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 1:27 AM

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 1:53 AM

# Frans Bouma's blog@ Wednesday, May 14, 2003 4:24 AM

# Andres Aguiar's Weblog@ Wednesday, May 14, 2003 4:24 AM

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 8:55 AM

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 7:39 PM

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 7:50 PM

# re: Serious ASP.NET Editor flaw lives on in VS.NET 2003@ Thursday, May 15, 2003 12:06 AM

# re: Stored Procedures vs. Dynamic Queries.@ Thursday, May 15, 2003 1:47 AM

# Frans Bouma's blog@ Thursday, May 15, 2003 5:19 AM

# Frans Bouma's blog@ Thursday, May 15, 2003 6:01 AM

# re: VS.NET 2003 isn't all that bad (sort of)@ Saturday, May 17, 2003 9:33 PM

# re: VS.NET 2003 isn't all that bad (sort of)@ Saturday, May 17, 2003 9:40 PM

# re: #define debugging testing@ Sunday, May 18, 2003 12:42 AM

# re: #define debugging testing@ Sunday, May 18, 2003 1:14 AM

# re: #define debugging testing@ Sunday, May 18, 2003 1:21 AM

# SBC DotNet Weblog@ Sunday, May 18, 2003 7:29 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 1:18 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 1:24 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 1:47 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 1:57 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 2:04 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 2:21 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 2:24 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 2:29 AM

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 20, 2003 3:29 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 4:33 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 5:17 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 6:19 AM