Parsing CSV files
in [MFC]
|
From: Tom Serface on 2 Feb 2010 02:25 I think the world will move more and more away from languages that compile to native code and more and more towards intermediate code languages like ..NET. When you get to that point it's just a matter of choosing a syntax you like and the result is the same. C++ has a lot of momentum so I suspect it will be around for times when native coding is required for a long while, but it will be tough for it to compete with the simplicity of paradigms like C# and Java that are just starting to live up to their promise. I never did APL and from what I can see I didn't miss out on much. I never wanted to learn a different keyboard. Tom "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:#FAttW9oKHA.1548(a)TK2MSFTNGP02.phx.gbl... > Well, APL was my among my first and favorite among the 20+ or so languages > under my belt. It molded my problem solving and programming thinking for > everything that followed. As a current compiler writer, I appreciate all > languages for what they do or are. I doubt anyone can design a perfect > language for all - unless of course, you wish to force it down their > throats. >
From: Hector Santos on 2 Feb 2010 02:32 Joseph M. Newcomer wrote: > You seem to be very confused. You are thinking that CR has meaning in parsing text lines. > Except in the one rare exception of older Macintosh text files, it has no meaning in > parsing text lines. It has relevance in rendering output, but you are confusing storage > and rendering here. I was talking about the original topic, the parsing of text lines > from Windows-compatible files. I'm not at all sure what you are talking about. > joe Of course you don't because you took something and total discombobulated it to show a meaningless point. Storage/Rendering are parts of the same coin. You are reading or more specifically, your LINE READER is done for a purpose, either for display, printing or what have you. A generalized line reader understands all the conditions for EOL for all platforms. You said the \r was meaningless since 1968 when in fact, you were incorrect in it value in not only for rendering but storage. You said it is ignored, well, first of all, thats not a meaningless action. You took it into account. I could only be meaningless if it didn't provide value to some rendering or print or output process - a total waste in storage and for rendering. This is not reality across the board. Maybe you might had been attempting to suggest it is "transparent", as in a cooked I/O functionality under windows, but thats only because the cooked functions themselves do the interpretation for you - that is not meaningless. Bye -- HLS
From: Hector Santos on 2 Feb 2010 03:52 Tom Serface wrote: > I think the world will move more and more away from languages that > compile to native code and more and more towards intermediate code > languages like .NET. When you get to that point it's just a matter of > choosing a syntax you like and the result is the same. Right. .NET is not the first. Its the basis of our product name sake, "Wildcat! Interactive Net Server" (winserver.com) - a centralized and virtual p-code "network" environment with a common language interface framework. Same principles in single source managing the I/O, the interfacing and of course, the security. Not comparing, .NET is extremely rich, but the same ideas that others are doing as well, so I agree its definitely a direction. Embedded languages into server environments is big. > C++ has a lot of momentum so I suspect it will be around for times when > native coding is required for a long while, but it will be tough for it > to compete with the simplicity of paradigms like C# and Java that are > just starting to live up to their promise. I agree. But I decided I am going to invest in C# for development products but only provide the .NET interface and examples for our server. > I never did APL and from what I can see I didn't miss out on much. I > never wanted to learn a different keyboard. Well, APL definitely faded due to its complexity perhaps, but I do believe if you were privy to it, it definitely would of made you a different person. :) APL was totally symbolic with ideas that are being duplicated today such as greater focus with FP, refactoring and prototype stacking. -- HLS
From: Hector Santos on 2 Feb 2010 04:00 Hector Santos wrote: > I agree. But I decided I am going to invest in C# for development > products but only provide the .NET interface and examples for our server. Correction, "I am NOT...." -- HLS
From: Joseph M. Newcomer on 2 Feb 2010 15:32
I once passed a PhD qualifying exam based, I am absolutely convinced, on the fact that the question which gave a piece of APL code was erroneous, and I pointed out that the could not pssibly work (an incompatibility in the rho operator operands), then went on to say "But if you meant to write <new APL expression>, then it would make sense, and in that case the answer would be..." I know I blew two other questions, which should have resulted in failure, but I passed. Only four of us did (the exam was commenmorated by a song, which everyone of that era can still sing to this day, and we remember all the words, nearly 40 years later; www.flounder.com/battle_hum.htm). APL was a fascinating language, and the last time I wrote a serious APL program was about 1969. There is no perfect language. C++ has been forced down our throats already, so I'm not sure that forcible usage is a criterion. C# and Java are being forced down right now. joe On Tue, 02 Feb 2010 02:02:32 -0500, Hector Santos <sant9442(a)nospam.gmail.com> wrote: >Well, APL was my among my first and favorite among the 20+ or so >languages under my belt. It molded my problem solving and >programming thinking for everything that followed. As a current >compiler writer, I appreciate all languages for what they do or are. I >doubt anyone can design a perfect language for all - unless of course, >you wish to force it down their throats. > >-- >HLS > >Joseph M. Newcomer wrote: > >> If you look at functional programming closely, especially along the dimensions of concepts >> such as "total" functions, "partial" functions, "pure" functions, and such, you see a >> powerful evolution of the thinking of ways to do software. Sadly, none of these languages >> has a significant following outside a few academics. >> >> As a former compiler writer, functional languages contain massively interesting amounts of >> information that can be used to create super-quality code; languages like C, C++ and even >> C# have a lot of issues that prevent good code generation. >> >> Personally, I'd love to be able to look back on languages like C, C++ and C# as the >> antiquated artifacts they are. But if you can't use a motorcycle, you might at least use >> a competition-quality racing bike, or even a really good 10-speed, instead of a >> "bone-shaker" (look up the history of bicycles if you don't know what this means...) >> joe >> >> On Mon, 25 Jan 2010 15:36:37 -0500, Hector Santos <sant9442(a)nospam.gmail.com> wrote: >> >>> Pete Delgado wrote: >>> >>>>> Joesph M. Newcomer wrote: >>>>> >>>>> Huh? I'd be embarassed to publish an algorithm that was based on K&R C. >>>>> It represents the best of mediocre programming of thirty years ago. >>>>> When I first read it, in 1975, I said "This language is really >>>>> badly done", >>>> ..... I think you are confusing the defects in the >>>> implementation of the standard library with the true language defects. >>>> Additionally, I think to compare a 30+ year old language that was originally >>>> designed as a system implementation language with the modern general purpose >>>> languages of today is misleading. C met its goals and became wildly >>>> successful despite its flaws and is still very widely used even today. >>> >>> Excellent point Pete. >>> >>> My opinion on a related note: >>> >>> I find it increasing harder to shallow how even today, people are >>> getting locked into thinking or "mindset" molded that what you did in >>> the past was all wrong and today's method is the better way. While >>> one might be able explain why the "militants" of this mantra are they >>> way they are, I just find the "stubbornness" very vexing, especially >>>from those who are obviously veterans of the industry. Generally, it >>> is the opposite. >>> >>> Again, a rhetorical opinion. >>> >>> I personally find it very odd that a dialect of the C language or any >>> language for that matter, has been "kludge" to support a syntax that >>> is cluttered with type casting. >>> >>> So as Joe might has stated 25 years ago in regards to C: >>> >>> "This language is really badly done" >>> >>> I can easily say the same thing today with today's C/C++ syntaxing to >>> support unicode. I say that because 25 years from now, programmers >>> will most likely be saying the same sort of thing: >>> >>> "This language is really badly done! It isn't >>> necessary today. Why all the extra coding?" >>> >>> I only say that because I am firm believer in functional programming >>> where such specifics are excluded from the overall "thinking" and >>> interfacing, I/O transformation or function generators. >>> >>> This is closer and it also it is a rebirth direction of where MS and >>> others are going with its languages. It is more "natural" per se, >>> without the wasteful "think time" to address minor details one has to >>> put into current C/C++ programming. >>> >>> These minor details are quite often SO "touchy" in its required >>> construct that if one subtle mistake will create the same or worst >>> problem that it attempted to resolved or be part of the two part solution. >> Joseph M. Newcomer [MVP] >> email: newcomer(a)flounder.com >> Web: http://www.flounder.com >> MVP Tips: http://www.flounder.com/mvp_tips.htm Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |