hylander wrote:
>
> I need an answer for the question above. Please answer it in detail!
Actually, I think your request for detail may indicate that you're
missing the point (if I understand what the point of using Scheme is).
I think the idea is that Scheme has a very simple syntax and does not
require you to remember whether you are trying to index an array out of
bounds, is a number floating point or integer, etc. This means (at
least in theory) that the teaching staff spends less time discussing
syntax and students spend less time debugging, and everyone spends more
time on the big questions. Think of how long it takes to teach someone
the standard Hello World in Scheme. Of course, if you *already* know
C++, then you may spend more time debugging Scheme, but that's sort of
beside the point.
I suppose that if you want to get into the details, there are other
reasons that have to do with Scheme supporting some features and not
others in such a way that it promotes a style of programming that the CS
dept thinks, in its #.# wisdom, is preferable, but I'm just seeing
Scheme for the first time myself, so I don't know what those features
are really.
It's a strange language, and sort of unsightly (forest of parens), but I
rather like it.
hylander wrote:
> I need an answer for the question above. Please answer it in detail!
The question is not learning the launguage because the language must be one
of the easiest in the world. There is no sytax to learn (besides () and who
cant do that?), no types, no idex out of range errors, no reserved words,
functions can be called anything you can think of, and it makes recursion
far easier than any other language i know (ive learned basic, c++, visual
C++ and some java, html ect.). The whole point in learning sceme is that you
dont have to spend time learning it. Most C classes spend weeks learning
syntax variable typing ect. without even getting to the major ideas of
functions, object oriented programing, ect.
The other answer is that they chose the text and not the launguage. Since
the text is in sceme they teach the course in sceme.
oh and this was all goneover during the first class and ma be in the packet
you got that day.
The only reason it's Scheme is because the book uses Scheme. This is
stated in the first handout you got and AFAIR was said in class too.
Now, the reason it's this book, is because Brian Harvey conciders it to
be the best CS book ever written. You may agree or disagree with him
(and neither one will win IMHO :), but he is Da Boss here, and he gets
to pick the book to use (besides, I'd assume that he knows a little more
about CS and CS books than 99.9% of students in CS61A (myself included),
so his choice is probably more or less intelligent).
So, the big question is, "Why did the book use Scheme". There can be
different passible answers for that (#1 in my list is "The authors
didn't know any other language" :)))
The reason is probably because Scheme is dialect of Lisp, and they
probably didn't really care which dialect to use. The difference between
C/C++/etc and Scheme is that you don't have to know much of
implementation details to write code for the ideas authors/class tries
to teach you. It turns out, that it also has extremely small number of
keywords, and everything else can be defined/redefined. Also, the nature
of this language allows you to build code and then execute it. You don't
see it, but it's used to provide various functionalities that illustrate
different ideas. It would take more time to implement the thing that
shows normal and applicative order in C, than it took in Scheme. Later
on, you'll see that both OOP and Logic programming can be implemented in
Scheme just as easy.
Yes, it may sound reasonable to expect CS students in CS61A to know at
least C, but this is not always the case. So another advantage of Scheme
is that it's extremely easy and fast language to learn. Besides, 99.9%
of students didn't know it before, so it demonstrates the important
fact: language is a tool, and we can do anything we want (if we know
how) using virtually any language. Plus it gives you experience of
learning a new language (and you'll have to do that over and over again
if you'll ever code something for real world. C is extremely powerful,
but if you just went through college course, you don't know it (because
they don't teach NICE stuff about it). But C is not always the best way
to do things. Sometimes perl or even awk and sed are the best ways, not
talking about special languages like SQL)
And, coming back to the fact that Scheme is a dialect of Lisp, it's one
of the best ways to do many things (like AI), which are PITA to do in C.
And you're about to go further than just 61A, so you will probably learn
hot stuff like AI and knowledge of Lisp-like language is a Good
Think(tm) to have.
Yes, it it's possible to code any program we do in Scheme in C. Yes,
it'll be more efficient. But such program will usually be bigger
(because Lisp is higher-level language than C), and sometimes it'll
require you to be pretty good in C.
Conclusion: We use Scheme, only because the book uses Scheme. But there
are bunch of good logical reasons why book is using Scheme.
Vadim.
Kal
hylander wrote:
> I need an answer for the question above. Please answer it in detail!
Well, I wouldn't say that we use Scheme just because the book uses
Scheme; rather, we use for the same good reasons that the book uses it.
These reasons include (stated succintly):
1) It is interpreted, and therefore programs are easier to modify.
2) It has extremely little syntax; thus, instead of learning syntax for
weeks on end, as you would do in a class which teaches C, you can
instead be thinking about the "big ideas" -- which happen to be easier
to understand because syntax isn't getting in your way.
3) One of the big ideas Scheme is good, which you'll get to much later,
is the "metacircular evaluator" -- the idea that you can write your own
interpreter for Scheme, in Scheme! What better way to understand how
programming (languages) work, than by writing an interpreter for one. I
think in the lecture notes, it says something to the effect that at
"that other college down the peninsula," they wouldn't even *let* you
write an interpreter until your third or fourth year. And this is your
first class!!
However, all though these are all valid reasons for learning Scheme, you
should also perhaps consider the fact that this class is not really
about learning Scheme -- nor is 61B about learning Java, or 61C about
learning C. Each of these classes is about learning a set of big ideas
which happen to be able to be implemented well (clearly, easily, etc.)
in that given language. The point of these classes is that you should be
able to take these big ideas and do them, with no trouble at all, in
just about any programming language.
Have fun,
Josh
This came in the middle of a message that I otherwise liked, but I do have
to quibble about this point. It's not that we think functional programming
is *preferable* to other paradigms. It's that we think you should know
*several* approaches to programming style, so that you can pick the most
appropriate one for a particular problem. Later in the semester we get
to object-oriented programming, for example.
There are pure functional languages in which you *must* use functional
programming (and indeed you can solve any problem in such a language),
just as there are pure OOP languages in which you must program in OOP style,
and so on for other paradigms. What's nice about Scheme is its flexibility.
There is a crucial meta-idea here: The tools with which you will actually
work during most of your career haven't been invented yet. The really
first-rank computer science professionals are the ones who know how to
adapt to new approaches -- and who also know the fundamental ideas that
endure through changing times. That's why we don't have courses with names
like "Programming for Microsoft Windows" and so on; you can learn those
details on your own, easily.
> 3) One of the big ideas Scheme is good, which you'll get to much later,
> is the "metacircular evaluator" -- the idea that you can write your own
> interpreter for Scheme, in Scheme! What better way to understand how
This is true for many languages. Yet I did point out that Lisp (and
Scheme) allows you to build an expression and than evaluate it. This
also implies that you can build Scheme interpeter in Scheme without
implementing all the functionality, but rather use already working
functionalities of the underlying Scheme interpreter. BTW, if you look
around, writing Scheme interpreter in Scheme seems to be the standard
excercise for many Scheme tutorials/books.
Vadim.
Somehow I missed the original message that started this thread, but
fortunately one of the people who replied quoted it.
A lot of people come into the study of computer science thinking that it's
mainly a matter of programming languages. Some colleges think so, too,
which is why many junior transfer students arrive at Berkeley having taken
half a dozen courses named after programming languages (Fortran, C, C++,
Pascal, Java, Visual Basic, etc.) and are dismayed to learn that they
still have to do the entire lower division CS curriculum here.
** We are not teaching you Scheme in this course. **
We are using Scheme as a vehicle to teach functional programming,
object-oriented programming, declarative programming, data abstraction,
programming language interpretation, and a bunch of other ideas that will
be important to you no matter what language you use.
Scheme is a good vehicle for this purpose because it doesn't get in the way
as much as other languages do. I think, for example, that you'll understand
better what object-oriented programming is really about after seeing how it
works in Scheme than you do after learning C++ or Java. But you'll have to
wait a while to decide for yourself whether I'm right.
If you want to know about practical applications of Scheme, there are two
main ones: prototyping and extension language.
Prototyping means writing a quick-and-dirty version of a program so you can
get the users to try it and see if the design is good. You can write a
program faster in a high level language than in a low level one, so you can
write several versions with slightly different designs and see which the
users like best. Then you write a more efficient version of the winning
design in a lower level language.
Extension languages are used to allow the users of a program to customize
how it works. For example, there is a Lisp interpreter inside Emacs; that's
how things like "Scheme mode" (in which Emacs knows about how a Scheme
program should be formatted, etc.) are implemented. A version of Scheme is
the standard extension language for programs from the Free Software
Foundation and is also used by other software developers. As you'll see
later in the course, a Scheme interpreter is a pretty small program, as
language interpreters go, so you can put one in your application program
without making it huge.
But none of that has anything to do with why Abelson and Sussman chose
Scheme as the basis for their text. It's because Scheme is an elegant
expression of the technique of using a few powerful ideas (LAMBDA is the
central one) to allow a wide variety of programming styles without
clutter. (Sussman is one of the inventors of Scheme, but it's not just
a matter of choosing his own language; the same aesthetic that went into
Scheme also went into SICP.)
Brian Harvey wrote:
> Extension languages are used to allow the users of a program to customize
> how it works. For example, there is a Lisp interpreter inside Emacs; that's
> how things like "Scheme mode" (in which Emacs knows about how a Scheme
> program should be formatted, etc.) are implemented. A version of Scheme is
> the standard extension language for programs from the Free Software
> Foundation and is also used by other software developers. As you'll see
Not only emacs uses e-lisp to implement MOST of its functionality (emacs
itself is relatively stupid program that knows how to run e-lisp), there
is also such thing called
guile(http://www.gnu.org/software/guile/guile.html), which is a library
used for adding support for Scheme into other programs.
As a result we have things like scwm(http://scwm.mit.edu/), which is a
Window Manager (a program that controls behavior and appearence of
windows/etc on X Window System. Unlike windows and mac gui, the
appearance of windows in X is not built-in, so you can choose a window
manager that you like and configure it the way you want. gives you much
more flexibility). And I should say it's a damn powerful window manager.
Go to their site and see some screenshots. Note that different windows
can have absoletuley different appearance at the same time.
Another example would be THUD
(http://www.glug.org/people/ttn/software/thud/), which is a register
transfer level simulation environment, where the design (i.e. the logic
built into your piece of hardware) is expressed in Scheme-based
language.
Whoever thinks that Scheme or Lisp are not practical, is wrong.
BTW, if you think you're smart enough to become a Real Programmer (read
"The Story of Mel, a Real Programmer") then obviously you don't need no
Lisp/C/etc. As well as you don't need all those concepts :)
If you're not smart enough to be like Mel, but you think you still want
to be a Real Programmer, then you should know that (I assume you know
FORTRAN well enough)
Real Programmers do List Processing in FORTRAN.
Real Programmers do String Manipulation in FORTRAN.
Real Programmers do Accounting (if they do it at all) in FORTRAN.
Real Programmers do Artificial Intelligence programs in FORTRAN.
Real Programmers like Arithmetic IF statements -- they make the code
more interesting.
Real Programmers write self-modifying code, especially if they can save
20 nanoseconds in the middle of a tight loop.
(read "Real Programmers Don't Use Pascal")
or, you might decide to become a Real Computer Scientist:
Real Computer Scientists admire ADA for its overwhelming esthetic value,
but they find it difficult to actually program in, as it is much too
large to implement. Most Computer Scientists don't notice this because
they are still arguing over what else to add to ADA.
Real Computer Scientists regret the existence of PL/1, PASCAL and LISP.
ADA is getting there, but it still allows people to make mistakes.
(read "Real Computer Scientists Don't Write Code")
By the fact that you're in 61A I think you hope to become Real Computer
Scientist some day... So, you can start to regret the existence of
Scheme, but for very different reasons :)
Vadim.
hylander wrote:
> I need an answer for the question above. Please answer it in detail!
> I know that Berkeley is one the few Universities that requires every cs
> student to learn scheme. I did ask the same question in the Calso
> Orientation and i got an answer which was too general to understand.
> Well, the teacher did mention about the use of scheme as a tool in
> dealing with certain kinds of problems, but he never
> mentioned about ," what kinds of problems?" You can possibly use c, c++,
> and java to deal with most of the problems already, so why learn scheme?
BTW, one of the authors of scwm I mentioned in another post is actually
teaching a class in Scheme (just like Brian I guess) at MIT (the
"origin" of Scheme).
Vadim.
Joseph Dale wrote:
>
> "Vadim E. Kogan" wrote:
> >
> > Joseph Dale wrote:
> > > Well, I wouldn't say that we use Scheme just because the book uses
> > This is clearly stated in the handout. It is the only reason. "If they'd
> > used COBOL, we'd teach COBOL" :))
> >
>
> I don't think I made my idea clear; what I meant is that some explaining
> is necessary in order for one to understand why this book is so great
> that
> we'd use it no matter what language is used.
That's the other side of the story, which is about why this book was
chosen, not about why the language was chosen. I merely stated that as
handout points out, the algorithm used for choosing the language for
this course was close to the following:
find the best CS book
Use the language that is used in that book. (for exactly the reasons you
stated - to read it in "original")
I, as probably most of students in the class, have no reason to think
that SICP is "the best CS book ever written" (I never saw it before, so
I cannot say anything about it). So for us, it's "because the book uses
it". Yes, we sure can say that it's the best, because Brian says so. But
I hope I'm not the only one who tries to reach conclusions by themselves
if it is possible, instead of using somebody elses conclusion. Yet it's
a great hint toward the right direction.
[the great argument skipped - I liked it :)]
> "big ideas" of SICP as well as Abelson and Sussman express them in
> Scheme. And as
> we would all agree that reading SICP in the original will help you
> become a much
> better programmer than, say, "Learn COBOL in 24 Hours".
Hmm... Maybe I misuderstood something or I'm in the wrong place. I
didn't come here to become a programmer. I _am_ a programmer (not the
best one though), and so far I was able to solve all the problems I was
paid to solve. Coding is relatively easy. I came here for the theory,
the math of it, the beauty of things like AI and ability to prove
security of the systems I build. It is unimportant for me how to
actually code it. If I don't know a fast algorithm to do something, I'll
invent it or look it up. If I begin to get lost in my programs, I'll
find a way to manage the code in a reasonable way. If I need to learn
another language, I'll do it. This is relatively easy and unimportant,
compared to building the theoretical background. In my understanding,
computer science is more or less part of the mathematics. Some physics
and electronics is envolved, and it's important to understand it, but
I'm not EECS, so I don't plan to go beyond understanding the basics of
hardware (i.e. I don't think about designing new chips or something).
IMHO the things studied in 61A are not that much about programming, but
more like about theory of programming. It it possible to be great in
theory of programming, but still not be a good programmer. And for many
people it is the goal - to be good in theory and be able to develop new
things, instead of being good at coding.
I should say that from the programmer's point of view, most of this
theoretical stuff is BS. It turns out that many great, efficient, etc
programs were written by people who don't care about simplifying things.
They care about using the hardware the best way. They provide
abstractions only when it's actually giving them something, but not
because that's the idea of "good" programming. And it sure takes talent
to be able to become a good programmer. Different kind of talent, then
it takes to become good computer scientist.
>
> > > 3) One of the big ideas Scheme is good, which you'll get to much later,
> > > is the "metacircular evaluator" -- the idea that you can write your own
> > > interpreter for Scheme, in Scheme! What better way to understand how
> > This is true for many languages.
>
> Yes, it is -- it just happens to be notably easy in Scheme, not least
> because
Yeah, that's exactly what I meant by saying that runtime evaluation
allows you to use underlying interpreter for many operations, instead of
implementing them yourself.
> the rest of SICP is in Scheme. After all, if Abelson and Sussman did a
> COBOL
> interpreter in COBOL instead, we'd study that instead. :)
Oh boy... Wonder if it's possible to do ANY interpreter in COBOL :)) But
I don't know cobol that much, so I better shut up :)
Vadim.
I don't think I made my idea clear; what I meant is that some explaining
is necessary in order for one to understand why this book is so great
that
we'd use it no matter what language is used.
For example, consider the argument:
"Nietzsche was a great philosopher, and he wrote in German.
Therefore, if I write in German, I will be a great philosopher too."
This is obviously fallacious; I believe it is somewhat like what is
known in
logic as the fallacy of affirming the conclusion. It happens to
correspond
pretty closely to:
"Abelson and Sussman are great programmers, and they use Scheme.
Therefore, if I use Scheme, I too will be a great programmer."
which is also fallacious.
On the other hand (and this is closer to what I was trying to say the
last time),
most scholars believe that if you read Nietzsche in the original German,
you will
be able to achieve a better understanding of his ideas (than if you were
to read
him in English), and you would thus be closer to becoming a great
philosopher.
Likewise, learning Scheme enables you to read SICP "in the original",
rather than
having to use some other book -- for example, one which translates
SICP's Scheme
code into COBOL, if that is even possible -- which could not possibly
express the
"big ideas" of SICP as well as Abelson and Sussman express them in
Scheme. And as
we would all agree that reading SICP in the original will help you
become a much
better programmer than, say, "Learn COBOL in 24 Hours".
> > 3) One of the big ideas Scheme is good, which you'll get to much later,
> > is the "metacircular evaluator" -- the idea that you can write your own
> > interpreter for Scheme, in Scheme! What better way to understand how
> This is true for many languages.
Yes, it is -- it just happens to be notably easy in Scheme, not least
because
I have no intention to flame; I just like to think that someone else
might have an interest I_M_HO. :)
>
> Joseph Dale wrote:
> >
> > "Vadim E. Kogan" wrote:
> > >
> > > Joseph Dale wrote:
> > > > Well, I wouldn't say that we use Scheme just because the book uses
> > > This is clearly stated in the handout. It is the only reason. "If they'd
> > > used COBOL, we'd teach COBOL" :))
> > >
> >
> > I don't think I made my idea clear; what I meant is that some explaining
> > is necessary in order for one to understand why this book is so great
> > that
> > we'd use it no matter what language is used.
> That's the other side of the story, which is about why this book was
> chosen, not about why the language was chosen. I merely stated that as
> handout points out, the algorithm used for choosing the language for
> this course was close to the following:
>
> find the best CS book
> Use the language that is used in that book. (for exactly the reasons you
> stated - to read it in "original")
>
> I, as probably most of students in the class, have no reason to think
> that SICP is "the best CS book ever written" (I never saw it before, so
> I cannot say anything about it). So for us, it's "because the book uses
> it". Yes, we sure can say that it's the best, because Brian says so. But
> I hope I'm not the only one who tries to reach conclusions by themselves
> if it is possible, instead of using somebody elses conclusion. Yet it's
> a great hint toward the right direction.
All you say is true enough -- kind of. It is true that, to most people
who take CS61A, "the algorithm used for choosing the language for this
course" **seems** to be the one you give, and yes, the handout **seems**
to reinforce that view. I just happen to find it very unfortunate that
most people do not look past this view towards the reasons why it is
such a great book; most people are willing to concede: "OK, Brian says
its a good book, so I'll take some time off from learning C [a "useful"
language] and learn this dumb ol' language Scheme." I believe that to
take this view risks not gaining the full advantages of Abelson and
Sussman's knowledge. To revisit my analogy, this is like someone who, in
order to read Nietzsche, learns German from "1001 German Phrases for
Tourists" (probably the human-language equivalent of "Learn COBOL in 24
Hours").
>
> [the great argument skipped - I liked it :)]
Thank you. :)
> > "big ideas" of SICP as well as Abelson and Sussman express them in
> > Scheme. And as
> > we would all agree that reading SICP in the original will help you
> > become a much
> > better programmer than, say, "Learn COBOL in 24 Hours".
> Hmm... Maybe I misuderstood something or I'm in the wrong place. I
> didn't come here to become a programmer.
Perhaps I should have emphasized the becoming a "better" programmer
part...
>I _am_ a programmer (not the
> best one though), and so far I was able to solve all the problems I was
> paid to solve. Coding is relatively easy. I came here for the theory,
> the math of it, the beauty of things like AI and ability to prove
> security of the systems I build. It is unimportant for me how to
> actually code it. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^
I disagree; what would our budding Nietzsche's ideas be worth if he
didn't know how to write them down? Or, what is more, if he didn't know
how to express them verbally in any way. Many would argue that one
cannot even **think** a thought if one does not know how to express it
in language. Yes, I know that there is plenty of mathematical,
non-code-type language for you to use, but *somebody* has to code it for
it to be worth anything.
>If I don't know a fast algorithm to do something, I'll
> invent it or look it up. If I begin to get lost in my programs, I'll
> find a way to manage the code in a reasonable way. If I need to learn
> another language, I'll do it. This is relatively easy and unimportant,
> compared to building the theoretical background. In my understanding,
> computer science is more or less part of the mathematics. Some physics
> and electronics is envolved, and it's important to understand it, but
> I'm not EECS, so I don't plan to go beyond understanding the basics of
> hardware (i.e. I don't think about designing new chips or something).
> IMHO the things studied in 61A are not that much about programming, but
> more like about theory of programming. It it possible to be great in
> theory of programming, but still not be a good programmer. And for many
> people it is the goal - to be good in theory and be able to develop new
> things, instead of being good at coding.
>
> I should say that from the programmer's point of view, most of this
> theoretical stuff is BS. It turns out that many great, efficient, etc
> programs were written by people who don't care about simplifying things.
> They care about using the hardware the best way. They provide
> abstractions only when it's actually giving them something, but not
> because that's the idea of "good" programming. And it sure takes talent
> to be able to become a good programmer. Different kind of talent, then
> it takes to become good computer scientist.
Hmm... yes. It certainly was a different talent that Marx (a great
theoretician) had than the people who actually had to try to "program"
using his ideas... They tried to write great, efficient programs, but
didn't care about simplifying things... They certainly aimed to use the
hardware in the best way... They only cared about abstractions when they
were of benefit. And they turned out to be crappy programmers.
Political ruminations aside, I find it very unfortunate that "from the
programmer's point of view, most of this theoretical stuff is BS."
Programmers who think this way usually aren't just trying to be
practical, write good code without letting theory get in the way. What
they are, with an attitude like that, is intentionally ignorant. They
would be much better programmers if instead of scoffing at radical,
complex ideas they tried to understand them. Twenty-five years ago, the
average "practical" programmer might have thought OOP to be bizarre,
arcane, and useless; now, that same "practical" programmer could be
writing every single line of code he writes in an object-oriented
language like Java! Now, wouldn't he be a better programmer if he'd paid
attention to theory all those years ago? For some people, 61A is a great
introduction to theory; but maybe what 61A really aims to do is to get a
bunch of thick-headed teenagers who want to be "practical" programmers
to pay a little bit of attention to the theory that they really
shouldn't live without!
>
> All you say is true enough -- kind of. It is true that, to most people
> who take CS61A, "the algorithm used for choosing the language for this
> course" **seems** to be the one you give, and yes, the handout **seems**
> to reinforce that view. I just happen to find it very unfortunate that
> most people do not look past this view towards the reasons why it is
> such a great book; most people are willing to concede: "OK, Brian says
Hmm.. IMHO you shouldn't care about such people... A person who doesn't
like to explore, but rather accepts answers will not be a scientist,
and, if my understanding of what UCB is trying to be is correct, then
such person will not survive. Unfortunatly, in US the education is
f(**ed up, and most universities don't have a clue what people they
accept (grades from a local college + bs "how great I am" essay don't
count) So far, this class seems the _only_ place that tries to filter
out people on their actual knowledge and abilities, but does it
minimally and does not enforce it. Anyway, enough of that.
> its a good book, so I'll take some time off from learning C [a "useful"
> language] and learn this dumb ol' language Scheme." I believe that to
Part of what Brian said about it + my additions were to show that Scheme
is actually being used in real life for not-very-scientific
applications.
Actually, after I played with Scheme I figured that I can play with Scwm
(unfortunatly, as all WMs I saw so far, it doesn't really have normal
support for multi-headed configuration :()
> take this view risks not gaining the full advantages of Abelson and
> Sussman's knowledge. To revisit my analogy, this is like someone who, in
First thing to do is to prove to yourself that A&S posess knowledge you
want to borrow. This is the only way it seems. At this point I haven't
really read the book (too busy w/ other stuff), but that will be the
first thing I'll do if/when I'll read it. If they do posess knowledge
that I want to borrow, I obviosly will borrow it (unless I'll turn out
to be stupid enough to not to understand it, as it happened with me in
the past with math)
> Perhaps I should have emphasized the becoming a "better" programmer
> part...
A better programmer, as we know, is Mel, who optimizes his programs so
than next instruction will be needed exactly when it's under the reading
head :))
>
> >I _am_ a programmer (not the
> > best one though), and so far I was able to solve all the problems I was
> > paid to solve. Coding is relatively easy. I came here for the theory,
> > the math of it, the beauty of things like AI and ability to prove
> > security of the systems I build. It is unimportant for me how to
> > actually code it. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ^^^^^^^^^^^^^^^^
> I disagree; what would our budding Nietzsche's ideas be worth if he
> didn't know how to write them down? Or, what is more, if he didn't know
> how to express them verbally in any way. Many would argue that one
> cannot even **think** a thought if one does not know how to express it
> in language. Yes, I know that there is plenty of mathematical,
> non-code-type language for you to use, but *somebody* has to code it for
> it to be worth anything.
Yeah, this is true... But somehow I have a feeling that ability to
express themselves in computer languages is built-in into every
wanna-be-CS person. Maybe I'm wrong on that. When I said that it's
unimportant, I didn't mean that I shouldn't know how to do it. I meant
that I should be able to do it by myself with no need to waste time of a
smarter person for explaining that to me. Maybe I overestimate the
real-world people around me. It just happens so that I come from a
background, where an 18 year old person is concidered adult and is
responsible for what he/she does. That includes choosing the career. And
I kinda tend to assume that if berkeley is #3 or so in the country for
CS, only people who are truly interested in the field will get in.
"Interested" is not "it's cool, man", it's being interested to learn
more no matter what it takes. And obviosly know more than it was told in
class in college. E.g. at some point I got a book on IBM basic. No
access to computer. When I finally found a place, and talked them into
allowing me in sometimes, I fugured that they aint got no IBM-clones
there. They had some weird russian machines. Different BASIC, but that
didn't stop me. Every single true CS person I saw back there started
something like that. Nobody was given a "green light" in form of the
computer at home or an easy access to it somewhere or even a good book.
But that was Russia. We coded with whatever we had. Don't have enough
RAM? Use Video RAM! This kind of stuff. Now, computers here are
something that is much more accessable (and it was so 10-15 years ago
too). Gimme a good logical reason, why a truly interested person (unless
he/she came from a weird country like Russia) wouldn't have the skill of
coding? Not talking about genious stuff (I can't do it either). Just
being able to code every single idea he/she has. In almost every
language he/she knows. This is like being able to read/write. Except I
don't give a damn about human languages.
> > to be able to become a good programmer. Different kind of talent, then
> > it takes to become good computer scientist.
>
> Hmm... yes. It certainly was a different talent that Marx (a great
> theoretician) had than the people who actually had to try to "program"
> using his ideas... They tried to write great, efficient programs, but
> didn't care about simplifying things... They certainly aimed to use the
> hardware in the best way... They only cared about abstractions when they
> were of benefit. And they turned out to be crappy programmers.
- So, let's drink for Lenin!
- You crazy???
- But what a revenge for a brother, eh? :)
(excuse my translation :)
I'm not experienced enough on the topics of Marx theory, so I can't
really know whether the ideas were that great after all... But
implementation suxx, no question 'bout it :) They didn't aim to using
the hardware the best way though. Trust me.
>
> Political ruminations aside, I find it very unfortunate that "from the
> programmer's point of view, most of this theoretical stuff is BS."
> Programmers who think this way usually aren't just trying to be
> practical, write good code without letting theory get in the way. What
> they are, with an attitude like that, is intentionally ignorant. They
> would be much better programmers if instead of scoffing at radical,
> complex ideas they tried to understand them. Twenty-five years ago, the
Yeah, the idea is correct. Now tell me why old good C coders produce
better programs than all those new Java/C++/VB/etc coders? It turns out,
that old coders arrive to the same ideas too (if they never learned it).
But they don't abuse them, unlike people who learned them before
actually writing the real-world code (thus not knowing WHEN to apply
those ideas). IMHO, despite all those reasons why learning is important,
_practice_ is the only way to become a programmer. The only point of
education IMHO is for your brain to take a note that such and such thing
exists and how to get more info on it. So, when you think about a
problem, you'll be able to "scan" your pool of know ideas if needed.
(not restricted to CS, IMHO true for many fields)
I still think that when you're actually coding for real world, you rely
on experience. Yes, sometimes I use ADTs like linked lists.. sometimes I
even introduce OOP things. That doesn't make me write the WHOLE program
that way though. That's the difference between applying when needed, and
applying in general. Even this class uses one idea at a time (I hope
that's because of time restrictions). IMHO it's a bad idea to "think" in
such-and-such way when starting the program. The idea is to thing
"machine-level" and go from there, thinking about other things if your
experience/intuition tells you that it might make things better.
> attention to theory all those years ago? For some people, 61A is a great
> introduction to theory; but maybe what 61A really aims to do is to get a
> bunch of thick-headed teenagers who want to be "practical" programmers
> to pay a little bit of attention to the theory that they really
> shouldn't live without!
oh, these "practical" programmers should've learned that in college
and/or at some small institute. 61A doesn't seem to be a "practical"
class. It's not about "practical" problems. At least I don't see
anything practical in those little homework assignments and step-by-step
projects. Again, you don't _learn_ practice, you _experience_ it. IMHO
for becoming practical programmer it's more useful to read other
people's good code than taking this class.
Vadim.