I would agree with you. The blogs and before them the website discussions and before them the newsgroups do quality investigative reporting providing you have tons of time.
What is needed now is blog summarizers with linking to make the terrific blog content available quickly and easily.
COBOL isn't the modern programmer's enemy unless they've been completely brainwashed by OO concepts; it's the entire mainframe environment (and let's be honest, there isn't all that much COBOL running on other OSes) regarding JCL, CICS, TSO, and all the rest. COBOL isn't any better or any worse than any other language; it's the culture that's so radically different that your average born-in-Java developer simply has no choice but to run screaming.
Well that was point of my post its the environment COBOL programs live in that creates the complexity the problem isn't COBOL.
Also, how is a class/object with multiple properties different than a C structure or a COBOL table?
The COBOL may be defined system wide, and it may use OS related automatic data structures. So the programmer needs to know: the individual COBOL program, the family or programs, the OS level data conversion services (often invoked non obviously), and custom definitions in books/tables.
As for DB2 it is not having DB2 that is the problem but code that makes use of non relational features. For example implicit sequencing that exists in a COBOL table which would be a join, group by, order by in a RDBMS environment and they would have to figure this out.
The real issue of Cobol is not Cobol in and of itself but that so many other ideas are used which are not currently in fashion.
Operating provided data structures Tables with multiple types of data ISAM/VSAM rather than databases job control cards with values need for the programs to run etc....
That will make the environment highly unfamiliar to younger programmers. The IT management has been very irresponsible in creating a situation where code crucial to most companies is undocumented and uses concepts which are difficult for new programmers to understand. Heck most companies did excellent work for the Y2K crisis in documenting their systems which they have lost and not maintained over the last decade.
If your father was into hobbyist electronics up until any point before the late 70's he built analog computing circuits. And she probably wasn't a housewife during WWII. She would have been 21 when WWII started which means husband got drafted. You've seen the pictures of Rosie the riveter. That's her 53 years ago.
Also women in the 30's knew practical things. Depending on where she grew up she might had to fix the phone or the electrical generator. That means understanding regulators. For that matter is she worked during the 1950s or early 1960s when analog technologies in consumer goods exploded. Or she could have been aware.
Again she might have been clueless her whole life. But then 75 isn't the problem. And that's what I object to. This idea that stupid old people are stupid because they are old.
I'm not sure how windows is relevant but no Windows was not a drastic change. Windows came in slowly. At first it was just a system for particular smaller apps to be used together. You still used DOS for your big apps which is what you spent most of your time in (unless you part of the Desqview crowd). By about Windows for Workgroup / Win95 you started to have people that never needed to go to DOS. There was no drastic change with Windows which is why it was so incredibly successful.
How the hell would she have even known? she's 75, for christ's sake. She thinks a computer is a computer is a compute
Because if she is 75 she was around when digital computers were invented. Probably if she was educated, she worked with analog computational devices which most certainly are different from the ground up. During the WWII when she was a young married working in the factories would have been another opportunity. She might for example have seen technologies like overlapping signal cancelation (massive use of XOR that digital computers don't really do so well), the kinds of direct control systems that didn't exist until the late 80's with digital computers.
Lets cut the old people are stupid nonsense. If she doesn't know the difference its because she choose to ignore 3/4s of a century of human progress and stay uninvolved.
The linux distribution model is not based on stores. Genealogy is well supported by Linux and Ubuntu (for free, you don't have buy software). What is not supported is the go to a store model of distribution.
The original parent was looking for easier. ConTeXt syntax is easier since it isn't designed to give the low level TeX controls. It also has cleaner handling of fonts and typefaces, color-separation for CMYK printing, page layout and entirely custom page-design, color support, XML input, multi-language and UTF-8 input.
Sure it should. Cyrillic has multiple encoding and they often differ on the encodings. Their are 4 main ones in use. Change fonts and don't properly map the encodings and this is likely to happen. Windows and Mac do a nice job of shielding you from this and you are seeing it in LaTeX because it is important fonts different ways but without the shielding.
If you want to manually adjust the automated features why are using LaTex and not just pure TeX? Also you can force if you modify the @ variables directly.
Actually TeX is ahead of most applications in terms of font technology. You don't notice this because you write in English (I'm assuming). With something like XeTeX you can access a system font directly. With something like fontinst you can burn copies of the font with adjustments (microtypographical, encoding changes...) If you use pdflatex you can make these kinds of adjustments on the fly. You can remap encoding easily and design your own glyph replacements. TeX is handling arabic and is taking a serious crack at Hindi (which is really, really hard BTW). Languages like Japanese and Chinese are done.
Lets say someTransform has a line like:
cout << item then I can't execute the loop out of order. Same issue of it has a line like:
if (test (item)) {last;}
What I was wondering is does it prohibit those sorts of things?
Well no to use the advantages of these esoteric languages today and not 25 years from now. The people using LISP in the 1950s hard garbage collection, reentrant functions, complex data structures....
Since this sounds practiced thought I'd comment that Software Transactional Memory essentially uses the approach you are suggesting. Then just certain parts of the compiler need to be functional not the apps themselves.
Right but what I can't do is is be sure in looking at your code block that someTransform didn't have a side effect that pollutes item when I want to run anotherTransform. Nor can I be sure that one of these two doesn't have some something like a "last" so I can't go through list in whatever order I want.
Huh? Real Mike, you got me here. I'm hard pressed to even see how D is remotely like a functional language: -- order of execution is explicit -- functions have side effects -- there are explicit looping structures etc...
So what's the advantage of this language over, say, using threads in a language like Ruby or Perl? It seems to me that it's extremely difficult to master and lacks features that exist in virtually every interpreted language in existance today.
Because in practice if you don't stay pure you'll end making assumptions that are false in a multi execution system. It is very hard for people to picture all things that go wrong if the environment their code executes doesn't execute in the same order they expect.
The whole industry of relational databases exists because once we were out of batch: Read a record, modify, write was too difficult. The issue of what happens if the record has changed since you started, made VSAM type (COBOL) structures impossible. So we invented a whole application to handle record locking and a whole sub programming language.
The goal is to not have to do that every time you want to be safely parallel for some object in the universe.
Where is LISP. Slowly taking over all the other languages. More and more ideas are incorporated into mainstream languages with every generation (say a decade). The only thing missing from most scripting languages now is the interchangeability of code and data.
Actually if you read the LISP documentation they agreed that being purely functional was a huge advantage. SICP for example spends a long time talking about how dangerous any kind of side effect is, and trying to justify why one would use an environmental evaluation (object oriented for example) vs a purely functional method. They also talk about the advantages of laziness vs. eagerness which is another big difference between Haskell and Erlang.
In the end LISP went with eager to simplify computation (its from the early 50s). Until monadic programming was invented too many problems (like a random number generator) were just too complex. I don't know they would make the same choices today.
It depends what you mean by niche. Really the theory says that everyone has niche tastes but may not be aware of their niche. So offering them a variety of less well known products similar enough to the ones they like....
Because people know how to construct plain HTML pages themselves and thus don't associate their creation with technical competence. If you are in the website building business using HTML pages means:
1) You can't use the site as an example site 2) Your customers often think their sites aren't "cool enough"
Further plain HTML does not work "well enough". HTML is stateless most desktop apps are stateful and people like their computer experiences stateful. AJAX and JAVA are essentially the other solutions to this problem.
Slashdot Mirror
I would agree with you. The blogs and before them the website discussions and before them the newsgroups do quality investigative reporting providing you have tons of time.
What is needed now is blog summarizers with linking to make the terrific blog content available quickly and easily.
COBOL isn't the modern programmer's enemy unless they've been completely brainwashed by OO concepts; it's the entire mainframe environment (and let's be honest, there isn't all that much COBOL running on other OSes) regarding JCL, CICS, TSO, and all the rest. COBOL isn't any better or any worse than any other language; it's the culture that's so radically different that your average born-in-Java developer simply has no choice but to run screaming.
Well that was point of my post its the environment COBOL programs live in that creates the complexity the problem isn't COBOL.
Also, how is a class/object with multiple properties different than a C structure or a COBOL table?
The COBOL may be defined system wide, and it may use OS related automatic data structures. So the programmer needs to know: the individual COBOL program, the family or programs, the OS level data conversion services (often invoked non obviously), and custom definitions in books/tables.
As for DB2 it is not having DB2 that is the problem but code that makes use of non relational features. For example implicit sequencing that exists in a COBOL table which would be a join, group by, order by in a RDBMS environment and they would have to figure this out.
That is what makes it more challenging.
The real issue of Cobol is not Cobol in and of itself but that so many other ideas are used which are not currently in fashion.
Operating provided data structures
Tables with multiple types of data
ISAM/VSAM rather than databases
job control cards with values need for the programs to run
etc....
That will make the environment highly unfamiliar to younger programmers. The IT management has been very irresponsible in creating a situation where code crucial to most companies is undocumented and uses concepts which are difficult for new programmers to understand. Heck most companies did excellent work for the Y2K crisis in documenting their systems which they have lost and not maintained over the last decade.
If your father was into hobbyist electronics up until any point before the late 70's he built analog computing circuits. And she probably wasn't a housewife during WWII. She would have been 21 when WWII started which means husband got drafted. You've seen the pictures of Rosie the riveter. That's her 53 years ago.
Also women in the 30's knew practical things. Depending on where she grew up she might had to fix the phone or the electrical generator. That means understanding regulators. For that matter is she worked during the 1950s or early 1960s when analog technologies in consumer goods exploded. Or she could have been aware.
Again she might have been clueless her whole life. But then 75 isn't the problem. And that's what I object to. This idea that stupid old people are stupid because they are old.
I'm not sure how windows is relevant but no Windows was not a drastic change. Windows came in slowly. At first it was just a system for particular smaller apps to be used together. You still used DOS for your big apps which is what you spent most of your time in (unless you part of the Desqview crowd). By about Windows for Workgroup / Win95 you started to have people that never needed to go to DOS. There was no drastic change with Windows which is why it was so incredibly successful.
How the hell would she have even known? she's 75, for christ's sake. She thinks a computer is a computer is a compute
Because if she is 75 she was around when digital computers were invented. Probably if she was educated, she worked with analog computational devices which most certainly are different from the ground up. During the WWII when she was a young married working in the factories would have been another opportunity. She might for example have seen technologies like overlapping signal cancelation (massive use of XOR that digital computers don't really do so well), the kinds of direct control systems that didn't exist until the late 80's with digital computers.
Lets cut the old people are stupid nonsense. If she doesn't know the difference its because she choose to ignore 3/4s of a century of human progress and stay uninvolved.
The linux distribution model is not based on stores. Genealogy is well supported by Linux and Ubuntu (for free, you don't have buy software). What is not supported is the go to a store model of distribution.
The original parent was looking for easier. ConTeXt syntax is easier since it isn't designed to give the low level TeX controls. It also has cleaner handling of fonts and typefaces, color-separation for CMYK printing, page layout and entirely custom page-design, color support, XML input, multi-language and UTF-8 input.
LaTeX is older more mature and better supported.
Sure it should. Cyrillic has multiple encoding and they often differ on the encodings. Their are 4 main ones in use. Change fonts and don't properly map the encodings and this is likely to happen. Windows and Mac do a nice job of shielding you from this and you are seeing it in LaTeX because it is important fonts different ways but without the shielding.
There is a replacement for LaTeX on up
http://wiki.contextgarden.net/What_is_ConTeXt
The idea is access with TeX without all the headaches. It is popular though I know LaTeX so the headaches don't bother me so much.
Spend the $100 get the book set...
http://www.amazon.com/LaTeX-Companions-Third-Revised-Boxed/dp/0321514432/
If you want to manually adjust the automated features why are using LaTex and not just pure TeX? Also you can force if you modify the @ variables directly.
Actually TeX is ahead of most applications in terms of font technology. You don't notice this because you write in English (I'm assuming). With something like XeTeX you can access a system font directly. With something like fontinst you can burn copies of the font with adjustments (microtypographical, encoding changes...) If you use pdflatex you can make these kinds of adjustments on the fly. You can remap encoding easily and design your own glyph replacements. TeX is handling arabic and is taking a serious crack at Hindi (which is really, really hard BTW). Languages like Japanese and Chinese are done.
Sorry you are just sort of 100% wrong here.
I'm not sure you are following.
Lets say someTransform has a line like:
cout << item
then I can't execute the loop out of order. Same issue of it has a line like:
if (test (item)) {last;}
What I was wondering is does it prohibit those sorts of things?
OK that's useful. Does it also prevent all side effects (like a file write)? What about the issue of one of them having a last statement?
Well no to use the advantages of these esoteric languages today and not 25 years from now. The people using LISP in the 1950s hard garbage collection, reentrant functions, complex data structures....
Since this sounds practiced thought I'd comment that Software Transactional Memory essentially uses the approach you are suggesting. Then just certain parts of the compiler need to be functional not the apps themselves.
Right but what I can't do is is be sure in looking at your code block that someTransform didn't have a side effect that pollutes item when I want to run anotherTransform. Nor can I be sure that one of these two doesn't have some something like a "last" so I can't go through list in whatever order I want.
Huh? Real Mike, you got me here. I'm hard pressed to even see how D is remotely like a functional language:
-- order of execution is explicit
-- functions have side effects
-- there are explicit looping structures
etc...
Erlang = massively parallel systems
OCaml = most practical / mainstream
Haskell = best language to make sure you really "get it" because the constructs just don't exist to do it your old way.
LISP/Scheme = Most books by far. Best language for really seeing that code is data and data is code. Very old fashioned though.
So what's the advantage of this language over, say, using threads in a language like Ruby or Perl? It seems to me that it's extremely difficult to master and lacks features that exist in virtually every interpreted language in existance today.
Because in practice if you don't stay pure you'll end making assumptions that are false in a multi execution system. It is very hard for people to picture all things that go wrong if the environment their code executes doesn't execute in the same order they expect.
The whole industry of relational databases exists because once we were out of batch: Read a record, modify, write was too difficult. The issue of what happens if the record has changed since you started, made VSAM type (COBOL) structures impossible. So we invented a whole application to handle record locking and a whole sub programming language.
The goal is to not have to do that every time you want to be safely parallel for some object in the universe.
Where is LISP. Slowly taking over all the other languages. More and more ideas are incorporated into mainstream languages with every generation (say a decade). The only thing missing from most scripting languages now is the interchangeability of code and data.
Where's my 'print "hello\n"' that works most other places?
Well
#!/usr/bin/env escript
main(_) -> io:format("Hello World\n").
And for something less trivial here is 99 bottles of beer:
simple more standard erlang
Actually if you read the LISP documentation they agreed that being purely functional was a huge advantage. SICP for example spends a long time talking about how dangerous any kind of side effect is, and trying to justify why one would use an environmental evaluation (object oriented for example) vs a purely functional method. They also talk about the advantages of laziness vs. eagerness which is another big difference between Haskell and Erlang.
In the end LISP went with eager to simplify computation (its from the early 50s). Until monadic programming was invented too many problems (like a random number generator) were just too complex. I don't know they would make the same choices today.
It depends what you mean by niche. Really the theory says that everyone has niche tastes but may not be aware of their niche. So offering them a variety of less well known products similar enough to the ones they like....
Because people know how to construct plain HTML pages themselves and thus don't associate their creation with technical competence. If you are in the website building business using HTML pages means:
1) You can't use the site as an example site
2) Your customers often think their sites aren't "cool enough"
Further plain HTML does not work "well enough". HTML is stateless most desktop apps are stateful and people like their computer experiences stateful. AJAX and JAVA are essentially the other solutions to this problem.
Why did