I completely agree with both of you too. I previously had a UT Starcom (or Audiovox in some places) PPC 6700 running Windows Mobile Smartphone Edition. It technically has all the same features as the iPhone (except for maybe line-item voicemail access), but they're so poorly designed that I rarely bothered to use them. Since getting the iPhone, I actually use the calendar for all of my appointments--a novel idea, I know.:-)
This free program (PFE) [if you can still find it] was only 20KB or so and was an excellent notepad replacement. It could probably handle 30 MB files (it could do about everything else).
I wish more systems/languages used the 'image-based persistance' idea. And, its message passing is elegant simplicity--easy for humans to wrap their minds around.
I actually don't have a problem with catch everything--it allows you to format the error message for the user and to gracefully die instead of leaking exceptions. And, I think that both Java and C# will essentially force you to have the catch-all as even innocuous-looking statements in your main can throw underlying framework exceptions (and in the case of C#, asynchronous exceptions can pop in from any thread at any time--really annoying).
Of course, I think the catch-all should be used in conjunction with proper context-sensitive catches throughout your program with exception specificities essentially being proportional to the depth in the call graph where they are caught--the outer catch-all catches the most generic type of exception whereas catches near the lowest level are most specific (and likewise all shades in between).
I agree completely.:-) There is no crisis, but the sooner that people realize that Haskell can help them in this area (and allow writing many fewer [and more elegant] lines of code), then the sooner I will get to start using it in production. [A current search of dice.com for 'Haskell' returns only 10 results--and the other functional langs, not so much more].
The 'do/while(0)' idea is completely idiotic. I am glad I do not work with those people. It is structurally identical to multiple returns yet with unnecessary clutter syntax around it. It's the same level of difficulty debugging either and I would bet the same assembly code is produced in both cases.
Limiting multiple returns values and to a lesser extent number of input variables should not be on that list. This respect is one of the reasons that Python is such a productive environment.
Yea, but client-side GUI programmers understand that too. Message queues are great for this. WIN32 is not the best system by any stretch of the imagination, but its message passing is a fairly simple model for concurrent programming.
Yea, but I guess my point is to prefer the Python way to the.NET way when one exists. For instance, prefer
list = [a, b, c, d]
over
list = new System.Collections.ArrayList();
list.Add(a);
list.Add(b); ...
and, in fact, I would venture that the DLR probably implements the Python list in terms of the.NET ArrayList anyway, but that is abstracted from you.
This is the same concern you would have if writing C++ on top of UNIX or Windows--you should prefer the pure language and the STL over system-specific APIs. (Except that.NET framework calls are not exactly system-specific as there can exist an implementation of CLR for any platform you wish to target. So, in that way, the.NET framework is both cross-language and cross-platform).
[And, another side-note-- each language has its own way of calling into the framework which is syntactically appropriate. For example:
System::Collections::ArrayList (C++)
VB of course has its own funky way too which I won't both with looking up right now as you probably get the point.]:-)
Umm... there's no such thing as 'C#' libraries. In.NET, it's the.NET framework that is the library and it is equally invocable from any language. You might be thinking of P/Invoke, but that is for invocing the underlying Win32 API (which is essentially a C API).
If you were to use the DLR and write Python for the.NET framework, then you would still do everything the Python way and it would be compiled into CIL. The CIL is fully Turing-complete, so it can support any language on top of it that is also Turing-complete. Of course, the efficiency of the resulting code depends on how good the compiler (or DLR) is at compiling one paradigm into another.
Re:How come nobody uses anonymous delegates?
on
Head First C#
·
· Score: 1
It sounds like you are working with a group of flat verbose types. I used to do C# with some folk like that. They had such rules as 'no reflection' and 'no anonymous delegates', but I managed to come in at a time when the rules were relaxed a bit. I took more advantage of it than they had anticipated I'm afraid. (But, the reflection by itself reduced 600 lines to about 50).
I think you're missing some things about the CLR's support for other languages. Look at the DLR for instance--C# is and never will be a dynamic language, but Python, Ruby, et al are supported by the DLR. And, even though C# now has support for some functional programming with anonymous methods and LINQ, it is not a purely functional language (like say Haskell, LISP, of F#).
Re:How come nobody uses anonymous delegates?
on
Head First C#
·
· Score: 1
I totally agree with you there. But, you can still get into quite spaghetti looking code with them. The back-end jumps to the front-end and back and forth and so on. The whole IsInvokeRequired/BeginInvoke fiasco contributes to that a little too (that should've been taken care of automatically by the framework).
Re:Redundent -- read selectively.
on
Head First C#
·
· Score: 1
There is no difference between a pure abstract class and an interface at the conceptual level. At the implementation-level maybe so, but we're talking about two completely different languages--of course the implementations will differ. Please elaborate a little if you disagree.
Re:easy way to fill a book
on
Head First C#
·
· Score: 1
OOP is not the magic bullet. Personally, I think functional programming makes even tighter code. Using them together is ideal.
Re:easy way to fill a book
on
Head First C#
·
· Score: 1
Very true, and I've found this to be true in my experience. It's the experienced C veterans who always say "but we can do the same thing in C". They just don't get it. Of course you can do the same thing in C, if you really want to manage v-tables manually and so on. But, you could also do the same things in assembly. The point is that it is more time-efficient to leverage language features instead of re-implement them.
Re:Redundent -- read selectively.
on
Head First C#
·
· Score: 1
Actually, I think they must have been referring to using containment and exposing inner functionality via wrappers as a way to simulate MI in C#. Pure abstract base classes and interfaces *are* the same thing.
I actually wrote a Visual Studio Add-in to automate the process of exposing contained objs' methods (and it is the best of 3 known approaches to simulating MI in a lang like C# or Java).
Slashdot Mirror
I completely agree with both of you too. I previously had a UT Starcom (or Audiovox in some places) PPC 6700 running Windows Mobile Smartphone Edition. It technically has all the same features as the iPhone (except for maybe line-item voicemail access), but they're so poorly designed that I rarely bothered to use them. Since getting the iPhone, I actually use the calendar for all of my appointments--a novel idea, I know. :-)
Don't forget the 2nd gen XBOX (360)--it's way better than 3rd gen Sony offering and like 10th gen Nintendo offering.
Mod parent up.
This free program (PFE) [if you can still find it] was only 20KB or so and was an excellent notepad replacement. It could probably handle 30 MB files (it could do about everything else).
Actually, it's only the right hand that needs to move--and only whilst typing that one word!
I wish more systems/languages used the 'image-based persistance' idea. And, its message passing is elegant simplicity--easy for humans to wrap their minds around.
I actually don't have a problem with catch everything--it allows you to format the error message for the user and to gracefully die instead of leaking exceptions. And, I think that both Java and C# will essentially force you to have the catch-all as even innocuous-looking statements in your main can throw underlying framework exceptions (and in the case of C#, asynchronous exceptions can pop in from any thread at any time--really annoying).
Of course, I think the catch-all should be used in conjunction with proper context-sensitive catches throughout your program with exception specificities essentially being proportional to the depth in the call graph where they are caught--the outer catch-all catches the most generic type of exception whereas catches near the lowest level are most specific (and likewise all shades in between).
I agree completely. :-) There is no crisis, but the sooner that people realize that Haskell can help them in this area (and allow writing many fewer [and more elegant] lines of code), then the sooner I will get to start using it in production. [A current search of dice.com for 'Haskell' returns only 10 results--and the other functional langs, not so much more].
The 'do/while(0)' idea is completely idiotic. I am glad I do not work with those people. It is structurally identical to multiple returns yet with unnecessary clutter syntax around it. It's the same level of difficulty debugging either and I would bet the same assembly code is produced in both cases.
Limiting multiple returns values and to a lesser extent number of input variables should not be on that list. This respect is one of the reasons that Python is such a productive environment.
Yea, but client-side GUI programmers understand that too. Message queues are great for this. WIN32 is not the best system by any stretch of the imagination, but its message passing is a fairly simple model for concurrent programming.
Please: Haskell, LISP, O'Caml or any of a number of other 'real' functional languages deserve your attention far before SQL or Excel.
Don't forget the iPod.
Yea, but I guess my point is to prefer the Python way to the .NET way when one exists. For instance, prefer
...
.NET ArrayList anyway, but that is abstracted from you.
.NET framework calls are not exactly system-specific as there can exist an implementation of CLR for any platform you wish to target. So, in that way, the .NET framework is both cross-language and cross-platform).
:-)
list = [a, b, c, d]
over
list = new System.Collections.ArrayList();
list.Add(a);
list.Add(b);
and, in fact, I would venture that the DLR probably implements the Python list in terms of the
This is the same concern you would have if writing C++ on top of UNIX or Windows--you should prefer the pure language and the STL over system-specific APIs. (Except that
[And, another side-note-- each language has its own way of calling into the framework which is syntactically appropriate. For example:
System::Collections::ArrayList (C++)
VB of course has its own funky way too which I won't both with looking up right now as you probably get the point.]
Umm... there's no such thing as 'C#' libraries. In .NET, it's the .NET framework that is the library and it is equally invocable from any language. You might be thinking of P/Invoke, but that is for invocing the underlying Win32 API (which is essentially a C API).
If you were to use the DLR and write Python for the .NET framework, then you would still do everything the Python way and it would be compiled into CIL. The CIL is fully Turing-complete, so it can support any language on top of it that is also Turing-complete. Of course, the efficiency of the resulting code depends on how good the compiler (or DLR) is at compiling one paradigm into another.
SEE:
http://en.wikipedia.org/wiki/Common_Intermediate_Language
and
http://en.wikipedia.org/wiki/Dynamic_Language_Runtime
It sounds like you are working with a group of flat verbose types. I used to do C# with some folk like that. They had such rules as 'no reflection' and 'no anonymous delegates', but I managed to come in at a time when the rules were relaxed a bit. I took more advantage of it than they had anticipated I'm afraid. (But, the reflection by itself reduced 600 lines to about 50).
Oops. I meant '... is not and never will be ...'.
I think you're missing some things about the CLR's support for other languages. Look at the DLR for instance--C# is and never will be a dynamic language, but Python, Ruby, et al are supported by the DLR. And, even though C# now has support for some functional programming with anonymous methods and LINQ, it is not a purely functional language (like say Haskell, LISP, of F#).
I totally agree with you there. But, you can still get into quite spaghetti looking code with them. The back-end jumps to the front-end and back and forth and so on. The whole IsInvokeRequired/BeginInvoke fiasco contributes to that a little too (that should've been taken care of automatically by the framework).
There is no difference between a pure abstract class and an interface at the conceptual level. At the implementation-level maybe so, but we're talking about two completely different languages--of course the implementations will differ. Please elaborate a little if you disagree.
OOP is not the magic bullet. Personally, I think functional programming makes even tighter code. Using them together is ideal.
Very true, and I've found this to be true in my experience. It's the experienced C veterans who always say "but we can do the same thing in C". They just don't get it. Of course you can do the same thing in C, if you really want to manage v-tables manually and so on. But, you could also do the same things in assembly. The point is that it is more time-efficient to leverage language features instead of re-implement them.
Actually, I think they must have been referring to using containment and exposing inner functionality via wrappers as a way to simulate MI in C#. Pure abstract base classes and interfaces *are* the same thing. I actually wrote a Visual Studio Add-in to automate the process of exposing contained objs' methods (and it is the best of 3 known approaches to simulating MI in a lang like C# or Java).
It's also perceptible via peripheral vision.
Hahaha... i just found your reply after my last one. GP was the database post I was referring to. :-)