|
Sponsored Links
Resources
.NET Research Library
Get .NET related white papers, case studies and webcasts
|
News
News
News
|
Messages: 33
Messages: 33
Messages: 33
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
TechTalk: Anders Hejlsberg on Creation of C#
In this TechTalk, Anders Hejlsberg talks with Ted about the influences on the creation of the C# language, the benefits of a unified type system, as well as development languages as a "lifestyle choice". He also discusses the long term benefits of generics and hints at work being done to unite general purpose programming with database programming....It was important to have some conceptual simplicities in the language, and one of them that I think is fairly subtle, but I am really happy that we got in, is the unified type system. The notion that in C# you can just say everything is an object. You can start with that premise and then you can later delve into the sort of subtle differences between reference types, value type, but you can put anything in an object to begin with and the mechanisms, like boxing for value types, and so forth are all sort of technically interesting. But the broad simplification or the deep simplification you get by starting there, as opposed to say a language like Java, where you have to immediately up front say well there are classes and everything is class, except these eight guys over here that are specially blessed and only the language will do those. In discussing generics, Anders describes first and second tier effects of generics, the first being the obvious use of typed collections. But the second level effect will be how closely our object models will be able to mimic real world relationships.
In looking ahead to future language enhancements, Anders talked about the impedance mismatch between general purpose programming languages such as C# and those of databases, such as SQL. One of the things that made .NET incredibly successful was the fact that we took all of that housekeeping and put it in the platform; garbage collection, type safety, exception handling, whatever, all these things that programmers just get wrong, if they have to do it manually. Put them in the platform, just allow you to think about the algorithms. I am like trying to shift my focus to that space and try to do some of those same things. Truly integrate the database with the programing language. Of course, that is a very broad vision and many people lie on the rocks of unsuccessful database integration, and I am hoping not to be one of them, but I think we have some interesting thoughts about it. Watch the entire TechTalk here.
|
|
Message #151625
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
language-database integration
There were many attempts brings database into a language (4GL languages, foxpro, powerbuilder etc) They proved to be wrong. It is time to look at this problem other way around bring language into a database (OODB). If Anders Hejlsberg will try to integrate OO languages with existing relational databases, i'm afraid he will be lying on those rocks he talks about.
|
|
Message #151632
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
Databases Misunderstanding
Related to “integrating databases and general purpose programming languages” it is amusing to hear such nonsense from Anders Hejlsberg. His thoughts about databases and their role is the typical mixture of fallacies and ignorance. Databases or RDBMS (relational systems are only truly DBMS) were invented exactly for the purpose of storing and manipulating data INDEPENDENTLY of any application or general programming languages. This is not the only benefit of using RDBMS but is certainly the biggest one. Of course his talk is exactly on the line of what is promoted heavily today in the form of so-called persistence layers that are turning today’s sophisticated and powerful RDBMS into a bit buckets or simply data dumps. Databases exists to allow data to be stored and processed independently of application and not to just extend application or language related data structures. To develop application using one language is just a big regression. Another issue is in what from OO (or better to say type theory) is relevant to databases and very detailed answer can be found in Chris Date’s and McGoveran book Third Manifesto, which was unfortunately ignored by the whole industry and standards. Again, very disappointing interview.
|
|
Message #151638
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
I will never go back!
"There were many attempts brings database into a language (4GL languages, foxpro, powerbuilder etc) They proved to be wrong."
"it is amusing to hear such nonsense from Anders Hejlsberg. His thoughts about databases and their role is the typical mixture of fallacies and ignorance."
I have to agree with the preceding speakers. I never forget the elevating feeling when I first accessed the database with low level C-api from VB 1 and was free to use any database with an ODBC interface. Freedom at last. No more dBase, Omnis, 4th Dimension, Powerbuilder..
And to see the face of the customers and colleagues alike when you in a database application choose Open from the menu and picked up another database, even one from another vendor! :).
Regards Rolf Tollerud
|
|
Message #151645
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
language-database integration
There were many attempts brings database into a language (4GL languages, foxpro, powerbuilder etc) They proved to be wrong. It is time to look at this problem other way around bring language into a database (OODB).If Anders Hejlsberg will try to integrate OO languages with existing relational databases, i'm afraid he will be lying on those rocks he talks about. Very true; and the irony is that OO database are there for quite some times but big companies are afraid to commit towards it due to their monoply on RDBMS. I am always wonder why people don't think simply and start opting/using OO databases over RDBMS for new development.
|
|
Message #151655
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
language-database integration
If Anders Hejlsberg will try to integrate OO languages with existing relational databases, i'm afraid he will be lying on those rocks he talks about. You seem to forget, that Anders Hejlsberg created a very successful RDBMS/language environment: Delphi. As he has this time the backing of Microsoft it might be even more successful.
|
|
Message #151687
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
Delphi RDBMS language?
This is the first time I have heard Delphi characterized as a RDBMS language. Even if Borland had Interbase it also could use any ODBC database, and through a custom DLL every database on earth. It had absolutely nothing in common with the 4GL languages IMO. It was a better VB but too late to market.
Regards Rolf Tollerud
|
|
Message #151689
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
TechTalk: Anders Hejlsberg on Creation of C#
"impedance mismatch between general purpose programming languages such as C# and those of databases"
Maybe this is refering to the new nullable types which seems to smooth out one big mismatch.
Wonder if comega will may its way into C# in some format. Cant remember the details since I looked at this. I know it let visual studio IDE understand the database and let you type in SQL statements as strongly typed constructs with intellisense, rather than a bunch of text. Similar for XML.
I just hope to see a good Object relational mapping inbuilt to VS, I know there are a million of these out there but a great one built into VS would be better. When is objectspaces coming ?
But at end of day code is code and databases are databases.
|
|
Message #151703
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
Delphi RDBMS language?
This is the first time I have heard Delphi characterized as a RDBMS language. To be correct I called it an RDBMS/language environment, what is a slight difference. I refer to the IDE, language and class library that was targeted for database development and very successful in exactly that area.
Borland made the mistake not to distinguish between language IDE and framework, pretty much the same that Sun did to Java...
Anyway, there is a lot of things that can (and should be) be done at language level to support database programming. nullable types and Generics come to mind. Some interesting work around null checking on compiler level is done in Spec# a research project of Microsoft: http://research.microsoft.com/SpecSharp/
|
|
Message #151709
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
different perspective
I can't blame the guy for making statements that are not his strengths. There aren't many people that can write compilers like anders, but when it comes to building business applications, I think anders is not the right person to go to. Writing compilers and building business applications are very different and take different skills. Sometimes I think the guys writing compilers need to spend a few years writing business apps to really feel what developers go through. Writing a compiler is much more rigid, whereas most of the business apps I've worked on, the functional requirements change constantly. Just goes to show how different developers are and how diverse the field is.
|
|
Message #151712
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
language-database integration
The RDBMS often seems to be the limiting factor, rather than the programming language. Add a column in a table: all programs the use that table have to be recompiled (at a minimum) in order to access that information (no matter what language they are written).
Do OO databases improve this situation.
There have been attempts to create new types of databases that are neither relational or OO (e.g. Sentences).
P.S. It's odd to hear Powerbuilder and Delphi described as "wrong" or unsuccessful products. Both are used by 1000s of companies around the world.
|
|
Message #151739
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
language-database integration
The RDBMS often seems to be the limiting factor, rather than the programming language. Add a column in a table: all programs the use that table have to be recompiled (at a minimum) in order to access that information (no matter what language they are written).Do OO databases improve this situation.There have been attempts to create new types of databases that are neither relational or OO (e.g. Sentences).P.S. It's odd to hear Powerbuilder and Delphi described as "wrong" or unsuccessful products. Both are used by 1000s of companies around the world. It's wrong only because MS wants people to use the latest greatest .NET release. It has nothing to do with the merits of Delphi or Powerbuilder. heck, bill gates slames older versions of windows to push the latest and greatest stuff. blame the sales guys and execs for shamelessly over selling their own products.
|
|
Message #151748
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
Peter is confused
Why are you bundling Delphi with Powerbuilder? They have nothing in common IMO. Delphi is a great product, Powerbuilder was just a throwback to old 4GL technology with thousands of bugs.
"bill gates slames older versions of windows to push the latest and greatest stuff"
hi there, it is Microsoft that are the good guys, remember?
http://www.theserverside.net/news/thread.tss?thread_id=30880#151365
Regards Rolf Tollerud
|
|
Message #151757
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
misunderstanding
Why are you bundling Delphi with Powerbuilder? They have nothing in common IMO. Delphi is a great product, Powerbuilder was just a throwback to old 4GL technology with thousands of bugs."bill gates slames older versions of windows to push the latest and greatest stuff"hi there, it is Microsoft that are the good guys, remember? http://www.theserverside.net/news/thread.tss?thread_id=30880#151365RegardsRolf Tollerud My own fault for not being clear. i didn't mean to confused powerbuilder with Delphi. Since I haven't used either one and have zero experience with both product.
What I was trying to say is Executive from all big companies over sell their latest and greatest products. Even if it really isn't better or provides any real benefit to the user. Just about every fortune 5000 company has done it repreatedly, so no one should be surprised when person X from Compan Y says "that's the wrong solution, here is the right way." The bottom line is to think for yourself and resist the temptation to believe in hype.
peter
|
|
Message #151758
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
OODB is the future becoming reality
Delphi is a very good (at some time best) and very successfull product. But it is not RDBMS specific tool. It is general purpose OO language + IDE + nice set of components, including components to connect to databases.
But it is definitelly not an attempt to bring databases to language itself. Delphi as a language does not have anything to work with databases, unlike 4GL languages like PowerBuilder, Foxpro, Dbase. These have builtin support to work with databases, and they all are gone, history. Do not confuse their existence nowadays with real life. MS still releases new versions of Foxpro, but it does not mean product is alive.
Anyway my point is, so far many attempted integrate RDBMS support into language and they all fail. I do not see how Anders Heilsberg can succeed where many others failed.
About RDBMS wining over OODB. Reason is simple. Cheaper technology always wins over the best. 30 years ago hardware resources were very expensive, comparing to programmers workforce. That's why it was cheaper to put more work on programmes than on hardware. That's why such inferior technologies as RDBMS and imperative programming won over it's rivals OODB and functional programming. But progress in IT changed all this. And same economic rule that once granted victory to RDBMS and imperative languages now is working against them. Now it is cheaper lo load more work on computers than on programmer. That's why we see last years growing popularity and talks about OODBs and functional languages as Haskell or Clean. Their time has come. They do more work for us programmers, and allow us concentrate on business requirements rather than code persisting information to database or work with variables through for loops.
That's the direction a true innovator like Anders Heilberg should thin of. Bringing Functional programming to unwashed masses with nice IDE integration. Easying work with databases, providing seamles integration of language inside a database, storing language artifacts, objects, instead of requiring developer to disassemble information in peeces and putting those peeces onto shelves, called tables.
|
|
Message #151785
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
OODB is the future becoming reality
That's why we see last years growing popularity and talks about OODBs and functional languages as Haskell or Clean. Their time has come. I don't really think that functional languages are "the future" or will ever replace imperative languages. After all they are around (and live in their niche) for 30 years. Hardly ground breaking stuff. However it's interesting to see them implemented in the CLR and I am sure they will have their place within a .NET programmers toolset.
I hear people talking about OODB's now for over 10 years but nothing has really happend. They seem not to be used in many projects and _many_ have failed in that area. I think the reason is that storing data in a relational model really makes sense. (Imperative) programming however makes sense in an object oriented way. The best way to combine it in my view is an OO mapper that is backed by a programming language that supports it. And - as far as I interpret Anders Hejlsbergs interview - that's what he tries to do.
That's the direction a true innovator like Anders Heilberg should thin of. There is actually quite a lot of research work done at Microsoft in terms of programming languages (F#, Spec#, Comega). Anders Hejlsberg job is though to develop the main stream tools and I think that's what he does very well.
|
|
Message #151791
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
functional languages
I don't really think that functional languages are "the future" or will ever replace imperative languages. After all they are around (and live in their niche) for 30 years. Hardly ground breaking stuff. Old stuff does not mean it is not ground breaking. Functional languages were far ahead of time when they appeared due to very limiting capabilities of hardware. There was no ground to break at that time. Now there's :))
I think the reason is that storing data in a relational model really makes sense. You mean when you go to party and vallet parking guy takes you car, it is really makes sense to him instead of just parking your car somewhere, disassemble it into smallest pieces, put tags with id numbers everywhere and store each piece on the shelf that hold other pieces of same type of other cars ?
Probably it also makes sense for this guy assemble your car back when your party is over and you going home. :))
The only reason behind relational databases is gone long time ago. It is severe hardware resource limiting factor. Remember Year 2000 problem ? When they tried to save so expensive memory, cutting storage space for year portion of data fields ? Same thing with RDBMS. We still work with data as if we do not have enough storage or processing power.
|
|
Message #151797
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
functional languages
Nice example there with the valet parking. Let me do another example: If you have to put your furniture in storage because you are leaving the country for a while would you put it in storage exactly how you have it set up at home? No, you would put the stuff togehter, disassemble some pieces, empty the fridge and get rid of some unused items.
Anyway, all this example proves is that you can prove whatever you want if you just chose the right example...
Same thing with RDBMS. We still work with data as if we do not have enough storage or processing power. I don't know if these are the main reasons:
- There are benchmarks that prove ODBMS to be as fast if not faster than RDMBS.
- I don't know why a ODBMS should take up much more storage. After all a good object model should not store redundant data, exactly like a good database design.
I think however ODBMS lacks a formal mathematical foundation, unlike the relational model.
Don't get the wrong idea though: I am not really keen on writing SQL and stored procedures. I would love to have an object oriented persistence layer that works. The way to go though IMHO is not an ODBMS. I think rather that the two worlds (RDBMS and OO programming languages/frameworks) should come together.
|
|
Message #151798
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
functional languages
Let me do another example: If you have to put your furniture in storage because you are leaving the country for a while would you put it in storage exactly how you have it set up at home? No, you would put the stuff togehter, disassemble some pieces, empty the fridge and get rid of some unused items. LOL Your example just proves what i said. You disassemble furniture because you are short of space. But would you bother if you had unlimited storage space ? Of course not.
- I don't know why a ODBMS should take up much more storage. For the same reason why disassembled furniture takes much less space than assembled. Records in tables and fields do not vary in size, while objects vary greatly. For example yoг can have hierarchy of objects that starts with simplest and lihgtest one, and ends with big and fat classes with many fields and methods. So you end up with much more unused space. Also do not forget RAM and cpu requirements. Object databases require a lot of that too.
|
|
Message #151801
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
OODB
I think however ODBMS lacks a formal mathematical foundation, unlike the relational model. If you read excelent book "Third Manifesto" by Chris Date’s and McGoveran, you will see great examples of ignorance of a matematical foundation by all RDBMS vendors. None of existing RDBMS conforms to relational theory.
Besides, if ODBMS lack mathematical foundation, this also means that OO programming also lacks it. But it does not affect the role OOP plays in modern programming.
Anyway, when mathematical foundation is needed, it is created. Google for "object calculi" and you will see there's lot's of work done in this direction.
|
|
Message #151808
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
functional languages
You disassemble furniture because you are short of space.But would you bother if you had unlimited storage space ?Of course not. Even if I had unlimited space I would empty the fridge because the stuff in it go off, and I would cover stuff up because it collects dust and the sun shines on it. I would maybe put the stuff in storage simply because it's safer there than leave it in an unprotected house.
I can could of course take your valet car parking example and try to match it to an IT world: I might would dissasemble a car to put it in storage if it only takes 5 milliseconds and a robot can do it without my help. I might actually not park the car at all because it only takes 2 milliseconds to build a new car and it does not cost anything.
Anyway, again my point is: You can prove whatever you want with an example. We are though not parking cars or storing furniture, we try to persist data.
Records in tables and fields do not vary in size, while objects vary greatly. For example yoг can have hierarchy of objects that starts with simplest and lihgtest one, and ends with big and fat classes with many fields and methods.So you end up with much more unused space.Also do not forget RAM and cpu requirements.Object databases require a lot of that too. ?
I think you are proving here that an ODBMS can store data more efficently:
If the records do not vary in size a string for a customer surname will always take up say 60 CHAR (given it's not a VARCHAR, but let's not be fussy).
However in a ODBMS the string will only take up as much space as it's length (5 bytes for "Jones"). As objects are by definition dynamic in size an ODBMS could never allocate the size of a class biggest possible instance.
Depending on the task the query of an ODBMS can be less processor intensive.
"One of the main reasons is that ODBMS do not use joins to associate objects but references which are usually implemented as pointers. In SQL-based RDBMS, a join would often require a search through a B-tree index (although some vendors offer short-cut technology). In general, navigation in an ODBMS is via traversing references, whereas in SQL data is joined in an ad-hoc fashion (which is better for arbitrary queries)."
|
|
Message #151809
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
OODB
That's interesting. I assumed the mathematical base is one of your arguments for functional programming languages instead of imperative languages?
|
|
Message #151816
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
functional languages
That's interesting. I assumed the mathematical base is one of your arguments for functional programming languages instead of imperative languages? Not really. Mathematical base is very good thing indeed. But it is more important for language and compiler creators than to us end users. What is more important for me - Higher level of abstraction, lot's low level technical stuff (juggling with variables etc) is done by compiler, - declarative nature of functional programming, - more powerfull instruments at my disposal (Higher Order functions, function guards, closures, built in support for lists, tuples, list comprehensions) - type inference (yet another work taken off me and passed to compiler)
Comparing to this work with traditional imperative languages is like work with assembler, too low level.
|
|
Message #151922
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
functional languages
I don't know if these are the main reasons: - There are benchmarks that prove ODBMS to be as fast if not faster than RDMBS.- I don't know why a ODBMS should take up much more storage. After all a good object model should not store redundant data, exactly like a good database design.I think however ODBMS lacks a formal mathematical foundation, unlike the relational model. Don't get the wrong idea though: I am not really keen on writing SQL and stored procedures. I would love to have an object oriented persistence layer that works. The way to go though IMHO is not an ODBMS. I think rather that the two worlds (RDBMS and OO programming languages/frameworks) should come together. Joe I couldn't agree more. I am gald that you demistify the myth about OODBMS but at the same time put some very pragmatic reasoning for not using it. Even though "Vagif Verdi" arguing his best I don't think so he has any serious validity in his argument. Besides that coding daily business logic in Functional paradigm is a far fetched dream, not becuase of harware/sofwtare limitations, but due to the fact that business logics doesn't blend very well to functional paradigm, my 2 cetns:-)
|
|
Message #151936
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
functional languages
coding daily business logic in Functional paradigm is a far fetched dream, not becuase of harware/sofwtare limitations, but due to the fact that business logics doesn't blend very well to functional paradigm How so ? Have you had frustrating experience with functional programming ? Cause i'm not. I love my days way back working with lisp. And never found that it was hard to put any logic in functional style. Actually i'm still using many functional style tricks i learned from lisp in my everyday work. But you are right probably in that sense that junior programmer having experiense only with imperative languages will have hard time trying to grasp the functional paradigm first few months.
|
|
Message #152002
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
functional languages
Actually i'm still using many functional style tricks i learned from lisp in my everyday work.But you are right probably in that sense that junior programmer having experiense only with imperative languages will have hard time trying to grasp the functional paradigm first few months. Yes my friend and you nailed it down intelligently. I never claimed to be a functional paradigm expert even though in the past I had coded in Lisp. Instead a big number of programmers are like me who has good expereince of imperative paradigm (BTW I consider OO part of it just with a flavour of classes but it doesn't chnaged the paradigm much) becuase we brought up in C/C++ age with the sugar coting of Java:-) So if you think practically shifting paradigms are the toughest thing to achieve, specially when the new kids in CS shcools are getting away and away from all other paradigms due to strong market demand of imperative languages.
|
|
Message #152021
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
functional languages
So if you think practically shifting paradigms are the toughest thing to achieve, Never said it would be easy. What i claim, that this shift is inevitable. With programmers yearly salaries 20 times higher that cost of average server pc, It is crucial for business to make them work faster, achieve more, and with less bugs. So it does not really matter what new kids in CS schools are getting today. They will get tomorrow what business will tell them to get. An by the way, I do not mean that days of java will be over soon. What most probably will happen, more and more technologies from functional languages will appear in mainstrim languages as java and C#.
Do you know where Garbage Collection come from to java ? Do you know that all functional languages even 30 years ago had Garbage Collection ? Look at the trend with popular scripting languages like Python, Groovy and Ruby. They all have alot of fucntional style technologies in them. And more will come.
|
|
Message #152086
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
functional languages
Do you know where Garbage Collection come from to java ?Do you know that all functional languages even 30 years ago had Garbage Collection ? Look at the trend with popular scripting languages like Python, Groovy and Ruby. They all have alot of fucntional style technologies in them. And more will come. Yes I do. GC has been in the existence since long long time ago. Smalltlak, Lisp etc. But these kind of thing doesn't impact the programming paradigms becuase these are low level details. I am in favor of these kind of advancement but mixing two paradigms together (Functional imperative etc etc) is a no no in my book. The reason is the high learning curve and the impedence mismatch between the two paradigms. Remember that is what made C (you can code in all styles imperative/functional/assembly ) such a hard language to master as compared to Java where you can think only in one paradigm. See how fruitful the expereince has been where even a guy like me can dare to do programing:-) And that is what it counts most my friend.
BTW I know this fashion to add all the features ever existed in any language to these new platforms (specially .NET); and unfortunatley the Java is also following the same path due to peer pressure. But in my humble opinion that is a path to disaster..
|
|
Message #152088
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
functional languages
Look at the trend with popular scripting languages like Python, Groovy and Ruby. They all have alot of fucntional style technologies in them. And more will come.
I absolutly agree with Rashid that this is the
path to disaster
There is no point in polluting exisiting languages with features from functional programming languages. That's the beauty of .NET: Use an existing funtional language (and there are - existing or planned - implementations of Haskell, F# and Lisp) to access code written in an imperative language.
|
|
Message #152094
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
functional languages
<blockquoteThere is no point in polluting exisiting languages with features from functional programming languages.Agree with you completely. I also prefer to have 2 separate languages, purely functional and imperative. The only exception would be lists. I think lists and sets are so important in programming, that should be made first class citizens in all languages, not only functional. And I have high hopes on dotnet, to allow me someday use functional language to write actual logic, and use imperative language to exchange data with outside parties (be it GUI or database) Right now there's no commercial attempt to bring fucntional language to dotnet, only research projects, with no IDE support, no documentation etc.
|
|
Message #152128
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
IntelliSense statement completion and types
One of the great things that types buy you is IntelliSense statement completion. Because we have a strongly typed language, because every variable and every expression has a type, we know what members of a particular type are, and we can show them in a list and filter them for you and we can give you help and guidance because of type. If we had no type, I mean we could sometimes guess, but sometimes we did get it wrong No Anders, you are wrong. It all depends on how you design your tool and how it's expected to be used. I know you can ask any object in Smalltalk on which methods/messages it supports. Granted, you can't do that design time, but I have also learned that in Smalltalk, the debugger is commonly used as a coding tool.
There are no reason in this scenario that you can't have intellisense and whatnot. In addition you can verify runtime behaviour at coding time. If the idea of coding in the debugger disgusts anyone, I would say I would have done it all the time in VB6 if it weren't for that tool did not allow me to save in those circumstances. Another point is: Why should I write any code which don't have a caller?
Unit testing and debugger coding would ensure that.
|
|
Message #152231
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
IntelliSense statement completion and types
No Anders, you are wrong. It all depends on how you design your tool and how it's expected to be used. I know you can ask any object in Smalltalk on which methods/messages it supports. Granted, you can't do that design time, but I have also learned that in Smalltalk, the debugger is commonly used as a coding tool. This is really about strong and weak typing. It's a little bit like religion you are either in one or the other camp... I am definitely a "strong typer". Main reason is that I beleive that the sooner you discover an error the better. Why wait until the program is running to discover an error if you don't have to?
The main argument against strong typing was that you had to write additional code. However this is not an argument anymore as we are using IDE's with code completition these days. This even starts to convince some "weak typers" like Guido van Rossum, designer of Python: http://www.artima.com/weblogs/viewpost.jsp?thread=86641 (Adding Optional Static Typing to Python)
|
|
Message #152232
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
IntelliSense statement completion and types
This is really about strong and weak typing. Haskell is strong typing language. Yet it does not require programmer write types in the code. It figures out types at compile time, and you get compile time type errors same way you get them with languages like java. This is called type inference.
Issue Anders discusses is type inference, not strong vs weak typing. What he says is that type information is needed at the time of coding, to assist programmer with intellisense, code completion, and quick info.
Now what I do not understand is, if Haskell is able to figure out types at compile time, why it is so difficult to fugure out types while typing code ? Looks like same kind of task for me.
|
|
Message #152234
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
IntelliSense statement completion and types
This is really about strong and weak typing. Haskell is strong typing language. Yet it does not require programmer write types in the code. You are right, I was a bit simplistic about the strong and weak typing. I looked that up http://en.wikipedia.org/wiki/Weakly_typed and there are a lot of definitions of the term weakly/strongly typed out there...
|
|
 |
| |
|
New content on TheServerSide.NETNew content on TheServerSide.NETNew content on TheServerSide.NET |
 |
 |
Language "mashups" will become more prominent, and developers will become polyglots, one programmer suggests.
SearchWinDevelopment.com offers an introduction to the language, performance, testing and data management improvements in VS 2008.
VBCode.com code snippets cover all aspects of application development, from data binding to security to the user interface.
Get up to date on XAML best practices with a variety of articles, tutorials and webcasts. [SearchWinDevelopment.com]
One team's experience with the VSTS DB edition suggests that it can improve workflow for dev teams. It also enhanced Agile efforts.
(June 24, Article)
Microsoft has begun to include DSL tools in the VSTS kit. A new book by Steve Cook and other VSTS team members helps set the stage.
(June 24, Article)
Cartoon: Be it ever so humble there is no place like your home after you get a Microsoft Home Server .
(June 18, Cartoon)
Microsoft's Thom Robbins says new technology to highlight in NET 3.5 includes AJAX, LINQ for both C# and VB, as well as tooling enhancements intended to ease the task of building WPF, WF and WCF apps.
(June 29, Podcast)
Venkat Subramaniam discusses AJAX bottlenecks, the tenets of Agile development and more. He spoke at the Ajax Experience.
(June 25, Tech Talk)
In the second of a two-part series, Michele Leroux Bustamente discusses design decisions related to the claims-based security model. Read the story and walk through the process for creating a set of claims-based utilities to encapsulate claims authorization at the service tier.
(May 24, Article)
Understanding why the Entity Framework exists and learning where it can fit into your projects can get you prepared for the eventual release early next year.
(May 10, Article)
Resource: This learning guide gives you quick access to useful links on Windows Communication Foundation security information.
(April 24, Article)
TSS.NET's Jack Vaughan spoke recently spoke with Microsoft's Brad Abrams to find out what he is seeing in the field and what the chefs in Redmond are cooking. Along the way he discusses patterns of AJAX frameworks.
(April 11, Article)
In a two-part series, Michele Leroux Bustamente explains how claims-based security is supported by WCF, and how you can implement a claims-based security model for your services.
(March 29, Article)
Windows Workflow Foundation is a new technology that many developers will need to get their heads around. In a brief excerpt adapted from Programming Windows Workflow Foundation: Practical WF Techniques and Examples using XAML and C#, K.Scott Allen considers aspects of workflow definition.
(March 22, Chapter Excerpt)
|
|