> As someone correctly mentioned you should certainly stay from hype > languages like Java, Perl, etc. They may make you more employable in > the short term, but in the long term they will make a crappy > programmer out of your, and there's no going back: bad habbits die > hard.
Can you please explain yourself a bit here. Just because Java and Perl are popular, how will using them make you a bad programmer? Clearly, this a false statement to begin with - you can be good or bad in any language. I would just like to know how you arrived at this conclusion, because it is fasinating how you can damn an entire language for inflicting bad habits.
>Yes it is vague, but it is real life. This task has real-world programming >issues stamped all over it.
>It has a deadline and a specification.
This is *much much much more* true of ICFP. In fact a web server does not have a specification ( otherwise it would not be vague ).
Put in simpler words if someone wanted to hire me and handed me a sheet of paper saying:
Project: Write a web server. Deadline: 30 days.
I would say "hand me a lot more pages describing what you want" before I even consider taking the jobs. Even if handed (IIRC) RCF2616 I would not take the job. ( RCF2616 is a description of a protocol, *not* a specification. )
OTOh there are many who do use the ICFP as a specification because it is a specification. Yes it's for teams of people, it's meant to be worked on full-time and it's not for someone learning a new language, but those limitations are overcome by extending the deadline to thirty days.
> Then I moved to the Vax and 68k-based Suns, where I was vaguely > aware of how the instruction set worked. Eventually I moved to > machines (PowerPC, Sparc, Alpha) where I honestly have no clue what > the architecture, let alone the assembly language, looks like. It's > just not important.
Actually I think it's important to be able to move up and down the ladder of abstraction. Implement your ideas as abstractly as possible but not more so. :-)
You should be able to take on lower-level concerns as necessary. Perhaps you find your program running more slowly than you expect. You should be able to look at a disassembly and see what it's doing in case the problem is that you've tickled some inefficiency in your compiler.
And there's nothing like a good assembly language hack....like the time I patched a terminal driver on a Honeywell DPS-6 so some guys could do print-screens on dumb terminals they were using to replace a batch of unreliable microcomputers. I walked down to talk to them and saw them using the dumb terminals. I said, `Notice any difference?' `Uh, no, not really.' I went away happy.
-- Fred Gilham gil...@csl.sri.com Behold, how good and pleasant it is when brothers dwell in unity. It is like the precious oil upon the head, running down upon the beard, upon the beard of Aaron, running down on the collar of his robes. It is like the dew of Hermon, which falls on the mountains of Zion. For there the LORD has commanded the blessing, life for evermore. -Ps 133
> Virtual machines have been "old hat" for quite some time now. It's > just another way of implementing layers of abstraction, after all. > .... > Why do I get this strange feeling that each new wave of newbies has > to reinvent the past? Oh well.
Yea, you can often recognize us old farts by the fact that we sometimes `accidently' refer to Java byte code as `P-code'.
-- Fred Gilham gil...@csl.sri.com || "If I thought there was anything at all in your arguments, I should have to be not only a theist, but an Episcopalian to boot," he said, after one interchange, reckoning that since Episcopalianism was, in his book, that than which nothing could be worse, this was an effective reductio ad absurdum. - J. R. Lucas
"Scott Palmer" <Scott.Pal...@sympatico.ca> wrote in message <news:n28h9.520$cg7.206413@news20.bellglobal.com>... > Perl is certainly not a good language to learn as a beginner. Most Perl > code you will find is obfuscated, as Perl syntax promotes obfuscation. > (After learning another language then taking a look at Perl, this will be > self-evident.) Only a very disciplined Perl programmer would be able to > escape the self-obfuscating nature of Perl.
Only very discpilined programmers are able to write clear code in any language. Perl is no better or worse than the others.
> Perl is the ultimate shorthand. You can express quite a bit in only a few > lines of Perl... quite powerful.. but those few lines will look like a > monkey was bashing at the keyboard unless you are a Perl expert.
So become an expert. I would rather analyze a few lines of Perl than wade through 100 lines of some other language.
> Perl has it's place, but learn something easier first.
Perl is easy to learn because it is interpreted, and fun to learn because the CPAN makes it easy to write useful programs immediately. Example: I need to automatically FTP some files periodically. This would have been a day or more of work in C++. With Perl, I just downloaded Net::FTP, played with it in the debugger for a couple of minutes, and soon I had a finished, working script.
The Perl syntax seems 'ridiculous' to someone with experience in only a couple of other languages. To a beginning programmer, the Perl syntax isn't any weirder than the syntax of C++, FORTRAN, or Ada. And it's a whole lot easier to get started with Perl.
> >Scince someone mentioned Assembler as a way to learn how the basics of > >a computer work, perhaps Brainf**k and Unlambda might be of interest, > >to go down to the basics of computability... ;-)
> What about Befunge? ;)
> Befunge teaches you stack-based programming, and the true horrors of > writing spaghetti code...
* Michael Sullivan wrote: > Yes it is. It's neither Turing complete, nor general purpose, nor very > well designed, but it's definitely a programming language.
I think you are pushing it rather hard to count something with no conditional, variable binding, iteration or recursion constructs as a programming language.
* Michael Sullivan | Yes it is. It's neither Turing complete, nor general purpose, nor very well | designed, but it's definitely a programming language.
* Tim Bradshaw | I think you are pushing it rather hard to count something with no | conditional, variable binding, iteration or recursion constructs as a | programming language.
There appears to be a serious failure to understand the difference between languages that general programs accept as input and languages that compilers, interpreterrs, and other language processors accept as input. Just because it is interpreted and produces some response in the interpreter does not make it a programming language. From a Lisp perspective, the irony in the failure to distinguish code from data is particularly enjoyable.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
Erik Naggum wrote: > * Michael Sullivan > | Yes it is. It's neither Turing complete, nor general purpose, nor very well > | designed, but it's definitely a programming language.
> * Tim Bradshaw > | I think you are pushing it rather hard to count something with no > | conditional, variable binding, iteration or recursion constructs as a > | programming language.
> There appears to be a serious failure to understand the difference between > languages that general programs accept as input and languages that > compilers, interpreterrs, and other language processors accept as input. > Just because it is interpreted and produces some response in the interpreter > does not make it a programming language. From a Lisp perspective, the irony > in the failure to distinguish code from data is particularly enjoyable.
(Matt puts on his devils advocate costume with flame retardant underpants and enters the fray)
A definition I found stated that a programming language is "a vocublary and set of grammatical rules for instructing a computer to perform specific tasks" (http://www.webopedia.com/TERM/P/programming_language.html). A definition for an interpreter is "a program that executes instructions written in a high-level language" (http://www.webopedia.com/TERM/I/interpreter.html). Both of these suggest that HTML is a programming language: it has a syntax, grammatical rules, and an interpreter.
(Matt removes the stupid costume)
HTML is not a programming language. In fact, it's name tells you that: Hyper-Text Markup Language. So it's a markup language, nothing more, nothing less. The failure is not really to with knowing the difference, it's all these damn acronyms and peoples inability to remember what they stand for.
Having said that though, I do sometimes wonder if the line between languages has not become a little blurred.
Matt (who now wonders if removing the underpants was a good idea)
p.s. To the original post about what makes a better programmer:
On Mon, 16 Sep 2002 18:57:50 +0100, Matthew Denner
<m...@noreply.denner.demon.co.uk> wrote: >HTML is not a programming language. In fact, it's name tells you that: >Hyper-Text Markup Language. So it's a markup language, nothing more, >nothing less. The failure is not really to with knowing the difference, >it's all these damn acronyms and peoples inability to remember what they >stand for.
While I agree that HTMl is not a programming I language, I would poiint to TeX. TeX is a markup language, which if not a programming language, comes as close to a programming language as you can.
* Matthew Denner | HTML is not a programming language. In fact, it's name tells you that: | Hyper-Text Markup Language. So it's a markup language, nothing more, | nothing less. The failure is not really to with knowing the difference, | it's all these damn acronyms and peoples inability to remember what they | stand for.
HTML is based in SGML, which is only a syntax. It has no semantics at all. If you wanted to, you could implement a programming language with the syntax of SGML (or XML). Some people who believe even harder in living forever than I do so they do not have to prioritize anything in their lives, have actually done this. HTML has chosen not to do one crucial thing for a programming language: define user abstractions (like functions, macros). Even XML alone falls short here, but a given XML application can of course invent ways to define new elements and perhaps even what to do with them.
| Having said that though, I do sometimes wonder if the line between languages | has not become a little blurred.
It has always been blurred, but all that means is that there exist languages that are hard to categorize because they are viewed from several vantage points, not that the categories overlap or are ill-defined concepts.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
On Mon, 16 Sep 2002 11:58:14 +0100, Kenny Chaffin wrote: > In article <pan.2002.09.16.05.53.58.131460.13...@dave.org.uk>, > d...@dave.org.uk says... >> On Sun, 15 Sep 2002 23:43:25 +0100, Scott Palmer wrote:
>> > Perl is certainly not a good language to learn as a beginner. Most >> > Perl code you will find is obfuscated, as Perl syntax promotes >> > obfuscation.
>> This is nonsense. Please present some evidence to back up your claims.
> check out the obfuscated perl contest....
I am well aware of the obfuscated perl contest, It has no relevance to this discussion. Just because it's possible to write obfuscated code in a language, that's not the same as saying that the syntax promotes obfuscation.
Dave...
-- And crawling on the planet's face, some insects called the human race Lost in time, and lost in space. And meaning.
alec2...@ziplip.com (Alec) wrote in message <news:f2da8e5d.0209160047.1d0106e@posting.google.com>... > And this is coming from someone who has worked with Lisp 2 through > Common Lisp for years in several teams and solo. Besides, he already
I've noticed from some of your postings that you seem to have something personal against Common Lisp. Did something happen to you which made you hate it, or maybe hate someone who was using it?
I'm not claiming it's a panacea and all programmers should start using it. Just that I personally find it the most productive language for the way I work, after so many years of experience with so many other programming languages. The issues most people complain about, when they say they don't like Common Lisp, seem like nitpicking to me. What matters to me is how fast and how well I can program. At the end of the day, I want to see high quality production software which people can use and be happy with.
I had an argument like this with someone who gave a lot of reasons to hate Common Lisp, but all of those reasons seemed silly to me. Finally I asked him to post some of his Common Lisp code, as an example of what he was referring to, and he didn't have any. Before I spend any time arguing the merits of Common Lisp with you, could you please tell me upfront whether you have any actual Common Lisp code which we could discuss?
r...@stanford.edu (Russ Allbery) wrote on 15.09.02 in <yl8z23drdb....@windlord.stanford.edu>:
> In comp.lang.lisp, Simon Harvey <notha...@homtaild.com> writes:
> > Holy s$t - you cant be serious right? Where did you pick up form the OP > > that he wanted to learn assembly language! I really love learning > > computing and all sorts of programming language but I dram the line at > > assembly. I'm grateful that some people like it though!!
> I think it's a useful learning exercise for someone planning to do a lot > of programming to learn an assembly language at some point and write some > simple routines in it. I'm not saying that you should use it for anything > significant, but it's valuable to know how the processor actually executes > one's code in the end (even if you can and should ignore that knowledge > most of the time).
Personally, I believe that every good programmer needs to know at least one assembly language, *and* needs to have looked what sort of (assembly or machine) language at least one compiler actually generates from the high-level source code.
More than once I've seen people who didn't understand why their program was extremely slow, which would have been quite obvious for anyone understanding the above. (Such as, no, copying a string is not as fast as copying an integer.)
Doesn't mean you need to actually use assembler daily for anything, but that knowing these things makes for better understanding what you do when uusing a high-level language.
In the same vein, when using a declarative language, it can help having seen what sort of imperative code is used to implement such a language.
Or in general, when using a compiled or interpreted language, having seen source for a compiler or interpreter.
(Or, if you want, when driving a car, understanding at least some of the stuff an auto mechanic does.)
> I've found it useful in the same way that I found useful the experience of > implementing a file system when I took a class in operating systems. I > likely won't ever work on a file system again, but I now really > *understand* (for example) what an inode is, which has helped me a lot in > understanding, troubleshooting, and drawing conclusions about file systems > and file system behavior in areas even unrelated to programming.
flav...@mail.cern.ch (Alan J. Flavell) wrote on 15.09.02 in <Pine.LNX.4.40.0209152103290.5042-100...@lxplus071.cern.ch>:
> I've been involved, at various times, with the lowest levels of > programming, i.e writing microcode below the normal assembler level, > as well as writing assembler code per se. On the whole, I would be > inclined to say that those experiences make me a worse programmer of a > high level language, since I find myself worrying quite > inappropriately about bit-level optimisation when I _ought_ to be > worrying about proper selection of algorithms and such.
Doesn't seem to work that way for me. I've searched for better algorithms in practically every level of language, from assembly up to at least SQL ("how do I convince this SQL engine to do this without creating and scanning a full join?") - I don't remember if I did enough Prolog to do the same there.
> by inserting NOP instructions at strategic places. But the later > optimizing compilers _knew_ how to do that anyway, and experts of that > calibre had more important things to do than save a tiny fraction of > the overall execution time of an individual piece of software.
Which is why the general optimization rule is, *first* you *measure* where the program spends the most time, *then* you optimize *that point* - or (often better) you change your algorithm so you don't need to do that particular bit so often.
Because it isn't particularly rare that the hot spots are in a completely different place than you had assumed.
I think there's a tale about some early (Fortran?) compiler which, it turned out, spent most of its time fairly ineffectively reading the source code. Not analyzing it, or compiling it, just plain reading it. Speeding up that compiler turned out to be fairly easy, *once the problem was* *recognized*.
In comp.lang.lisp Friedrich Dominicus <fr...@q-software-solutions.com> wrote: : mich...@bcect.com (Michael Sullivan) writes:
:> Peter Ward <h...@ha.ha> wrote: :> :> > Newbie wrote: :> > :> > > :> > > :> > >"Scott" <otmorozok1...@yahoo.com> wrote in message :> > >> So, one of my friends tells me that I should learn C++, because "it's the :> > >best". :> > > :> > >The guy must be joking. HTML is the king. Learn it first. :> :> > I hope you are joking. HTML is not a programming language. :> :> Yes it is. It's neither Turing complete, nor general purpose, nor very :> well designed, but it's definitely a programming language. : Well counterexample write a loop in HTML.
I said I'd never post here again. But I guess I'm just stupid.
Here is a loop in HTML:
In a file called "loop.html". ------------------ <a href="./loop.html">This is a loop.</a> ------------------
Click on the link to go to the next "iteration".
I didn't say it was a *good* example of a loop.
-- -pete
E-mail address corrupted to stop spam. Reply mail: psilord at cs dot wisc dot edu I am responsible for what I say, noone else.
Tim Bradshaw <t...@cley.com> wrote: > * Michael Sullivan wrote: > > Yes it is. It's neither Turing complete, nor general purpose, nor very > > well designed, but it's definitely a programming language. > I think you are pushing it rather hard to count something with no > conditional, variable binding, iteration or recursion constructs as a > programming language.
Of course I'm pushing it. I certainly think the original person to suggest it was either joking or trolling or both, and I'm being extremely pedantic and half-joking myself.
But HTML does represent a language of instructions that an appropriate interpreter/compiler can translate into computer actions.
In the most general possible sense, it is a programming language. Not that I would use it for anything other than web-page markup, and that, only because it's a standard.
This appears to be something of a religious issue among programmers, many of whom want to set a line where scripting ends and programming begins, or where usage ends and scripting/programming begins. I can't say there's no point in trying to categorize like that, but it's pretty clear that any line you try to draw on that continuum will necessarily be *very* fuzzy.
The commonality of using certain complex programs and doing programming was striking to me, who went from a CS curriculum in college, to doing typesetting outside. Using something like TeX, typesetting clearly can be programming, by any standard. But even in a GUI like QuarkXpress before it was scriptable, I was surprised by how much my understanding of programming abstraction and problem spec definition (learned studying CS), ended up applying to preparing documents for maximum reuse potential.
The intro to _How To Design Programs_ does a really good job of getting the universality of programming as a skill across. Everyone programs, in the most general sense, whether they realize it or not. The problem with not realizing it is that you tend to do it badly.
Michael
-- Michael Sullivan Business Card Express of CT Thermographers to the Trade Cheshire, CT mich...@bcect.com
>>>>> "MS" == Michael Sullivan <mich...@bcect.com> writes:
[...] MS> Of course I'm pushing it. I certainly think the original MS> person to suggest it was either joking or trolling or both, MS> and I'm being extremely pedantic and half-joking myself.
It seems so.
MS> But HTML does represent a language of instructions that an MS> appropriate interpreter/compiler can translate into computer MS> actions.
As is the language of mouse movement and clicks.
MS> In the most general possible sense, it is a programming MS> language. Not that I would use it for anything other than MS> web-page markup, and that, only because it's a standard.
The point is not whether you would or wouldn't, but whether you could. You most certainly cannot.
MS> This appears to be something of a religious issue among MS> programmers, many of whom want to set a line where scripting MS> ends and programming begins, or where usage ends and MS> scripting/programming begins.
This is an entirely separate issue. Scripting languages are Turing complete. HTML is not a scripting language.
MS> I can't say there's no point in MS> trying to categorize like that, but it's pretty clear that any MS> line you try to draw on that continuum will necessarily be MS> *very* fuzzy. [...]
* Michael Sullivan wrote: > This appears to be something of a religious issue among programmers, > many of whom want to set a line where scripting ends and programming > begins, or where usage ends and scripting/programming begins. I can't > say there's no point in trying to categorize like that, but it's pretty > clear that any line you try to draw on that continuum will necessarily > be *very* fuzzy.
I don't want to set a line between scripting and programming. I do want to set a line between things that are programming languages and things that are not. HTML is a grammar: it says that certain strings are valid and certain are not, and it may also be assign a structure (a parse tree) to the valid strings. Saying this is a programming language is like saying that the *syntax* of C is a programming language.
