Re:No language that I like better
on
What is Perl 6?
·
· Score: 1
Object Oriented programming is *distinguished* by inheritance. The rest of OOP without inheritance is called "object based programming".
It's possible to program object oriented in C. One example of this is the file system interface in the BSD kernels (the VFS layer). With a language designed for OOP, however, I find that its often easier to create good designs. I also find it easier to think about large problem domains in OO terms (and found it so almost immediately, and I had programmed for 10 years before I learned OOP).
Actually, I don't mean properties. That creates (somewhat) contorted code in the class, and "magic" around the property - including the ability of getters/setters to be weirdly named.
Uniformity of access makes refactored code look like the design originally was that way. And it makes it possible to also move what was method calls to be attributes. In Ruby, this is done by only relating to messages, of course.
Point (B) - packet relay through unknown computers - also applies to phone calls. Since the mid 1990s, the telephony system itself works almost exclusively by packet relay through unknown computers. It's traditionally been ATM based, and these days I hear it's mostly VoIP based.
As for point (A), store-and-forward: This only increase the time the data is accessable. You're still transmitting data in fairly much the same way - the question is just if you're possibly storing it for a brief time on one kind of computer (queueing on a router), or for a slightly longer time on a mail server.
I'm fairly certain there's precedents around this - I distinctly remember a precedent setting a distinction between archieved mail, which it was OK for the gov't to prowl around in, and non-achieved mail, which was private communication. Archived mail was defined as mail older than 6 months.
I see the end braces or end statemetns as a code scanning aid. I use them as visual markers when I look at code. You find them gratious, I find Python hard to read because they're not there.
You find empty lines to make code more friendly to read. I, on the other hand, find the use of empty lines to be gratious and make the code harder on the eyes.
I believe both of these are mostly questions of habit.
Most static typists are very very afraid of runtime. Runtime isn't a problem. The question is if the bug is hard/takes time to find and fix; getting it at compile time help a little compared to getting when I run my tests, of course. However, even in the abscense of unit tests I very often catch errors *before* compile/start time, from reading the diffs my own changes. With tests, I get the errors when I run the tests (as I usually don't diff before running tests.)
I think you might be surprised if you checked out how few type errors you get when you're used to programming without them.
Of course, it might help that I've been used to programming without them on machines where my entire environment crashed and I had to wait ten minutes for a restart of the OS if I made a serious error, or that I've been used to work on software where a single cycle error somewhere would mean I'd have to get the oscilloscope to find out what the heck was up with the timing, or (very very very seldom) an error in my algorithm could mess up sensitive hardware, or (more frequently) corrupt my filesystem and force me to reinstall the entire machine from backup. It's amazing the number of ways you can mess up while doing file system programming and still not lose your data, BTW. Starting programming at 8 and having programmed professionally for two decades probably hasn't hurt, either (though my error rate is somewhat higher now than it was at one point, it's very seldom anything a type checker would take - it's minor algorithmic errors.)
Anyway, I don't make many type errors. My guesstimate (from observing and thinking about my errors compared to static types) is that I - at the moment - get about 5% of my errors from something where a static type checker could catch them. Well over 90% of these again are trivial bugs to fix, even without unit tests. With unit tests, these problems have always been easy to fix - as easy as a compiler error, and with about the same machine time involved.
I would expect that teaching programming didn't expose you to truly good programmer much? I'd expect it expose you to NEW programmers, and these days I would expect it to expose you to programmers that, if they have experience at all, have only programmed in memory protected environments. Environments that don't blow up in any way if you make an error...
My experience is that the missing block termination ("end") in Python makes it hard to scan Python programs - they get so "jaggy", visually. That is probably a question of habit, yet it's a mark against Python for being easily available to people that have habits from other languages.
I also find Ruby programs easy to think about, though I've got 20 years of habits to carry over to thinking about Ruby, so that's not certain to be important for somebody else.
You are ignoring one thing about Ruby that I see as quite important: Uniform access, borrowed from Eiffel. Python people generally don't intuitively "get" this (no wonder - they've not been exposed to it) - yet it's a significant thing when you're working with code later. Methods and attributes are accessed that way, so you can refactor an object to use code instead of an attribute, or an attribute instead of code. Without changing the client code.
There has also been a fair amount of Ruby programmers out there before Rails; not infinite, yet not so few that they don't count. Ruby and Python are about the same age, it's just that Python took off earlier in the western world (due to being developed in english rather than japanese).
And I'd like to note the difference in the ATTITUDE of the Ruby and Python programmers - the Ruby community is extremely friendly and fairly tolerant of different ways of doing things, while the Python community is reported to have the attitude of There-Is-One-Way-To-Do-It-And-Python-Is-Right-In-C hoosing-That-And-You-Are-Wrong.
There are probably other sides of Ruby vs Python discussion, too - I've never got around to learning Python, as everybody I talk to that know both prefer Ruby, language-wise - even some that program in Python for interpreter speed.
At least I find that I make so few errors that would be caught by a static type system that the costs of static typing (especially when used with type declarations) usually aren't worth the hassle - type declarations getting in the way of refactoring, expanded code size, etc. This will vary by programmer and by environment, of course.
*You* (CmdrTaco) are talking to us, at least occasionally, so you feel like a person. No complaints. ScuttleMonkey isn't.
And I've got some idea of the kind of work; I've been part of the team of about 5 running the world's largest joke site at one time. Kudos for your work!
I think the problems with "conspiracy theories" are easily resolvable: Just talk to us! You (CmdrTaco), Hemos, and Rob Limo have been around in the comments and participated, and have some "level of trust". In this case, ScuttleMonkey has posted 3 (three) comments, and has completely ignored the discussions that are going on about his posting * * Beatles Beatles submissions all the time.
If he'd gotten into the pits with all the rest of us, been there, been a person, commented "I don't know * * Beatles Beatles, it's just that he's always submitting during my shift" or "He happens to submit stuff that's the kind of thing I care about, stuff that the others don't submit, that's why I'm always approving him" or "* * Beatles Beatles continually hangs on the same IRC channels as me and point out interesting stuff, and I tend to ask him to submit the cool stuff" or whatever is the background, I think the problem would have gone away.
However, being just a name that appears on the stories creates distance, and makes it easy to talk about conspiracies...
"Usually". Except that it can't. You're asking for people to take the expense of losing all calls from unknown numbers - or accept that there's going to be someone in the other end saying "Oh, I want to push my cock in your ass Adam, can you feel it pounding, can you feel the hotness, how you're being torn apart by sex".
That's not acceptable. It is pushing a very significant cost onto a significant number of women. Probably close to all of them - even with it being illegal I know several that's been harassed by phone. Harassed, in some cases with the result of distrusting all men (at least for a period of time.)
Oh, and I don't want to pay for investigation of burlaries at your place when I'm all fine with having bullies break the arms of anybody that I think stole stuff from me.
Public debate doesn't belong in a wiki. That's what message boards are for. The wiki is for content and conclusions made from the end result of flame wars or debates. Controls need to be implemented so the content is of good quality (like a rating system). Its the same reason Wikipedia is not considered a legitimate source of info.
Actually, public debate among technicans have worked way better in the c2.com wiki than in any public "message" I've seen. It's been a brilliant way to distill wisdom and avoid undue repetition.
Making state saving easy makes software tend to save more state. That makes said software behave differently each time it's started up. With bad developers, this can be highly annoying.
Anyway, boycotting restricts me from the popular culture. That's from experience - I've done boycott of TV for years (reading books instead.)
As far as I can tell, whether that cost is less than a hunger strike is irrelevant. Being imprisoned for saying things the gov't dislike is less of a price than being killed for having slept with somebody other than your husband - and that's completely irrelevant when I'm discussing the imprisonment as being unjust.
WRT the ethics, the present situation involves actively forcing people to not break copy protections or create extra copies. Therein lies a major part of the problem. With the active enforcement of restrictions there should come a careful look at the entire value situation.
The works in question have a large part of their value - maybe their primary value - because they end up as part of culture (people buy/see them due to recommendations and cultural habit). As a such, evaluating them as "only entertainment" is to miss a significant part of them.
I use version control religiously and have done so for over a decade. What I find useful about version control is a few different things:
Difference display. I can see what changes I am making *before storing them*. This let me review code and I usually cut down any change to be a single logical change per commit, to be able to review it. If I have changes in my tree that's multiple logical changes (e.g, mixed whitespace changes and code changes), I take out a diff and massage it to be a single logical change, patch it into another three, and commit it from there. This makes reviews very very effective (catching a large fraction of bugs). It also makes the next point more useful:
Documentation. By using 'cvs annotate', I can see *why* a particular code line is the way it is. I can see who introduced it, when, and if necessary ask that person if this was intentional or a mistake. Very very useful for being able to do good changes (even with code that I only touch myself).
Ability to do experimental changes in a tree, and only keep some of them. This let me test out various directions, see how it works together, and pick out the stuff that's relevant.
Cooperative development, without stepping on each other's toes (much. Indenting changes are a pain...)
Ability to have local changes on some machines while not on others, while updating the software.
Convenient software distribution (for some cases).
Backouts for code that's already committed? Don't need 'em much, could almost always do that as easily from a backup.
I feel there is an important point getting lost: This is culture.
Boycotting it does not only cut you off from the entertainment, it also cut you from the culture that is part of. My experience is that that is a significantly higher cost than they boycott itself.
Yes, it takes time. However, Ruby is 10 years old, and if that problem doesn't occur inside ten years with thousands of programmers, it's - in my opinion - not worth worrying about. Even with more and worse programmers.
This leaves me with time to worry about real problems in Ruby. Close to what you're talking about is the lack of a global namespaceing system, giving library conflicts. These happen. Or blocks not checking parameter counts. This also gives real errors. And the lack of type declarations can be a documentation problem - it makes it hard to see what set of methods (messages) a parameter is supposed to respond to.
These are things that happen, things that actually impact code and development. Identical interface signatures for interfaces that really do different things is a mythological "could be" problem.
No, you're not guaranteed that something that respond to the same methods with the same parameter counts is really implementing the same interface. However, while writing an article and a bunch of code for type checking in Ruby, I read've read probably hundreds of discussions on this and certainly thousands of messages. I've not once heard anybody claim that they'd seen this happen or heard of it happening as a problem in practice.
I find even the punctuation moving around between Norwegian and US standard keyboards to be bad enough when having to type the simplest of texts (text with only letters, digits, period, comma, and exclamation marks; the rest of the punctuation has moved around). It isn't like I cannot use it, but once I get to a point where there should be a question mark and i get an underscore instead, or a left parentheses and not the right one, I have to slow way down from the "typing while looking at the screen"-mode, where the thoughts, the fingers, the keyboard and associated circuitry run like a smooth-flowing pipeline, about as easy as talking, to "hunt-and-peck" mode, where the flow is more like the stop-and-go traffic of a city street grid.
Actually, this is just lack of training with switching between these.
And again in norwegian: Dette er faktisk bare fordi du mangler trening i å bytte mellom disse.
I use both layouts, and have for two decades. When you've used both in parallel and switched a lot, it's trivial, and it sits in the fingers for both. It can take quite a while to get used to, though.
:make will run make in the present directory, and jump to and display errors (assuming use of the standard Unix error format). I think it also can display the output in a buffer and let you jump to it, like M-x compile - this isn't something I use much (in either editor), so I'm not sure.
Doesn't C-x v = give diff only for that particular buffer? I'm doing directory diffs all the time, including before every commit, so it still doesn't fit well with my development style. It's a good idea if I end up managing somebody that use emacs again, though.
And by all means, continue using emacs - as long as it's right for your use, and you can avoid contorting your wrists when using it, it's a very nice editor.
My usage patterns are probably somewhat unusual, see below:
Yeah, vi is a useful editor in many ways too. But I like being able to use the same keys in everything I do, from browsing the web to reading my email to using newsgroups to coding in Lisp or Python or C to editing my blog. And so far emacs is the only editor which is extensible enough for me to do that.
I find vi keys in nearly everything, except text editing boxes on the web. And there I mostly type straight forward, anyway - and the emacs keys don't work.
You're a bit of an unusual case, methinks: not too many people have gotten deeply into emacs only to return to vi. Heck, for me M-x compile was reason enough to stay. Well, and C-x v v (which prompts for a comment, then checks a file into CVS, RCS or SCCS version control, automatically picking the correct system).
vim has built in compilation (though I don't use that, as I almost exclusively program either in the kernel or in scripting languages.) C-x v v is something I actually find to be sort of in the way - it actually encourage me (or at least encouraged me) to do the wrong thing, as it does a check in *without* giving me a diff for review, and without checking the entire workspace for changes. I've even once had to prohibit a group member from using it, because he was regularly doing wrong checkins when using it.
As for getting vi-keys in emacs: There's viper-mode, which is fairly good at this.
And startup times: I'm unusal again, I tend to edit on a bunch of different machines, in different context, from various terminals and locations (moving my laptop around sometimes, using desktop boxes sometimes, working on both desktops and servers, fixing stuff on prod boxes when I'm short of time). There's ange-ftp and screen and etc, yet it still ended up with me creating and killing a LOT of sessions.
Slashdot Mirror
It's possible to program object oriented in C. One example of this is the file system interface in the BSD kernels (the VFS layer). With a language designed for OOP, however, I find that its often easier to create good designs. I also find it easier to think about large problem domains in OO terms (and found it so almost immediately, and I had programmed for 10 years before I learned OOP).
Eivind.
Eivind.
Uniformity of access makes refactored code look like the design originally was that way. And it makes it possible to also move what was method calls to be attributes. In Ruby, this is done by only relating to messages, of course.
Eivind.
Point (B) - packet relay through unknown computers - also applies to phone calls. Since the mid 1990s, the telephony system itself works almost exclusively by packet relay through unknown computers. It's traditionally been ATM based, and these days I hear it's mostly VoIP based.
As for point (A), store-and-forward: This only increase the time the data is accessable. You're still transmitting data in fairly much the same way - the question is just if you're possibly storing it for a brief time on one kind of computer (queueing on a router), or for a slightly longer time on a mail server.
I'm fairly certain there's precedents around this - I distinctly remember a precedent setting a distinction between archieved mail, which it was OK for the gov't to prowl around in, and non-achieved mail, which was private communication. Archived mail was defined as mail older than 6 months.
Eivind.
I see the end braces or end statemetns as a code scanning aid. I use them as visual markers when I look at code. You find them gratious, I find Python hard to read because they're not there.
You find empty lines to make code more friendly to read. I, on the other hand, find the use of empty lines to be gratious and make the code harder on the eyes.
I believe both of these are mostly questions of habit.
Eivind.
I think you might be surprised if you checked out how few type errors you get when you're used to programming without them.
Of course, it might help that I've been used to programming without them on machines where my entire environment crashed and I had to wait ten minutes for a restart of the OS if I made a serious error, or that I've been used to work on software where a single cycle error somewhere would mean I'd have to get the oscilloscope to find out what the heck was up with the timing, or (very very very seldom) an error in my algorithm could mess up sensitive hardware, or (more frequently) corrupt my filesystem and force me to reinstall the entire machine from backup. It's amazing the number of ways you can mess up while doing file system programming and still not lose your data, BTW. Starting programming at 8 and having programmed professionally for two decades probably hasn't hurt, either (though my error rate is somewhat higher now than it was at one point, it's very seldom anything a type checker would take - it's minor algorithmic errors.)
Anyway, I don't make many type errors. My guesstimate (from observing and thinking about my errors compared to static types) is that I - at the moment - get about 5% of my errors from something where a static type checker could catch them. Well over 90% of these again are trivial bugs to fix, even without unit tests. With unit tests, these problems have always been easy to fix - as easy as a compiler error, and with about the same machine time involved.
I would expect that teaching programming didn't expose you to truly good programmer much? I'd expect it expose you to NEW programmers, and these days I would expect it to expose you to programmers that, if they have experience at all, have only programmed in memory protected environments. Environments that don't blow up in any way if you make an error...
Eivind.
I also find Ruby programs easy to think about, though I've got 20 years of habits to carry over to thinking about Ruby, so that's not certain to be important for somebody else.
Eivind.
There has also been a fair amount of Ruby programmers out there before Rails; not infinite, yet not so few that they don't count. Ruby and Python are about the same age, it's just that Python took off earlier in the western world (due to being developed in english rather than japanese).
And I'd like to note the difference in the ATTITUDE of the Ruby and Python programmers - the Ruby community is extremely friendly and fairly tolerant of different ways of doing things, while the Python community is reported to have the attitude of There-Is-One-Way-To-Do-It-And-Python-Is-Right-In-C hoosing-That-And-You-Are-Wrong.
There are probably other sides of Ruby vs Python discussion, too - I've never got around to learning Python, as everybody I talk to that know both prefer Ruby, language-wise - even some that program in Python for interpreter speed.
Eivind.
Eivind.
And I've got some idea of the kind of work; I've been part of the team of about 5 running the world's largest joke site at one time. Kudos for your work!
No reply necessary.
Eivind.
If he'd gotten into the pits with all the rest of us, been there, been a person, commented "I don't know * * Beatles Beatles, it's just that he's always submitting during my shift" or "He happens to submit stuff that's the kind of thing I care about, stuff that the others don't submit, that's why I'm always approving him" or "* * Beatles Beatles continually hangs on the same IRC channels as me and point out interesting stuff, and I tend to ask him to submit the cool stuff" or whatever is the background, I think the problem would have gone away.
However, being just a name that appears on the stories creates distance, and makes it easy to talk about conspiracies...
Eivind.
That's not acceptable. It is pushing a very significant cost onto a significant number of women. Probably close to all of them - even with it being illegal I know several that's been harassed by phone. Harassed, in some cases with the result of distrusting all men (at least for a period of time.)
Oh, and I don't want to pay for investigation of burlaries at your place when I'm all fine with having bullies break the arms of anybody that I think stole stuff from me.
Eivind.
Actually, public debate among technicans have worked way better in the c2.com wiki than in any public "message" I've seen. It's been a brilliant way to distill wisdom and avoid undue repetition.
Eivind.
Eivind.
Eivind.
Anyway, boycotting restricts me from the popular culture. That's from experience - I've done boycott of TV for years (reading books instead.)
As far as I can tell, whether that cost is less than a hunger strike is irrelevant. Being imprisoned for saying things the gov't dislike is less of a price than being killed for having slept with somebody other than your husband - and that's completely irrelevant when I'm discussing the imprisonment as being unjust.
WRT the ethics, the present situation involves actively forcing people to not break copy protections or create extra copies. Therein lies a major part of the problem. With the active enforcement of restrictions there should come a careful look at the entire value situation.
The works in question have a large part of their value - maybe their primary value - because they end up as part of culture (people buy/see them due to recommendations and cultural habit). As a such, evaluating them as "only entertainment" is to miss a significant part of them.
Eivind.
Backouts for code that's already committed? Don't need 'em much, could almost always do that as easily from a backup.
Eivind.
Boycotting it does not only cut you off from the entertainment, it also cut you from the culture that is part of. My experience is that that is a significantly higher cost than they boycott itself.
Eivind.
Again, let's take the language back: It's as strict as possible restrictions, not "protection".
Eivind.
This leaves me with time to worry about real problems in Ruby. Close to what you're talking about is the lack of a global namespaceing system, giving library conflicts. These happen. Or blocks not checking parameter counts. This also gives real errors. And the lack of type declarations can be a documentation problem - it makes it hard to see what set of methods (messages) a parameter is supposed to respond to.
These are things that happen, things that actually impact code and development. Identical interface signatures for interfaces that really do different things is a mythological "could be" problem.
Eivind.
Eivind.
Eivind.
Actually, this is just lack of training with switching between these.
And again in norwegian: Dette er faktisk bare fordi du mangler trening i å bytte mellom disse.
I use both layouts, and have for two decades. When you've used both in parallel and switched a lot, it's trivial, and it sits in the fingers for both. It can take quite a while to get used to, though.
Eivind.
Doesn't C-x v = give diff only for that particular buffer? I'm doing directory diffs all the time, including before every commit, so it still doesn't fit well with my development style. It's a good idea if I end up managing somebody that use emacs again, though.
And by all means, continue using emacs - as long as it's right for your use, and you can avoid contorting your wrists when using it, it's a very nice editor.
Eivind.
Yeah, vi is a useful editor in many ways too. But I like being able to use the same keys in everything I do, from browsing the web to reading my email to using newsgroups to coding in Lisp or Python or C to editing my blog. And so far emacs is the only editor which is extensible enough for me to do that.
I find vi keys in nearly everything, except text editing boxes on the web. And there I mostly type straight forward, anyway - and the emacs keys don't work.
You're a bit of an unusual case, methinks: not too many people have gotten deeply into emacs only to return to vi. Heck, for me M-x compile was reason enough to stay. Well, and C-x v v (which prompts for a comment, then checks a file into CVS, RCS or SCCS version control, automatically picking the correct system). vim has built in compilation (though I don't use that, as I almost exclusively program either in the kernel or in scripting languages.) C-x v v is something I actually find to be sort of in the way - it actually encourage me (or at least encouraged me) to do the wrong thing, as it does a check in *without* giving me a diff for review, and without checking the entire workspace for changes. I've even once had to prohibit a group member from using it, because he was regularly doing wrong checkins when using it.
As for getting vi-keys in emacs: There's viper-mode, which is fairly good at this.
And startup times: I'm unusal again, I tend to edit on a bunch of different machines, in different context, from various terminals and locations (moving my laptop around sometimes, using desktop boxes sometimes, working on both desktops and servers, fixing stuff on prod boxes when I'm short of time). There's ange-ftp and screen and etc, yet it still ended up with me creating and killing a LOT of sessions.
Eivind.