I'm going to teach programming to somebody who's going to study it more formally in a year, but wants to be learning part of it in the mean time.
What SIMPLE, CLEAN, STRUCTURED language would you recommend me to use for teaching? Please, refrain from language wars as this is not a fanboy thread but a serious question. Before yuo mention it, I'm not going to start with either Python or Ruby because they're too complex and get too much in the way, and no, I'm not stupid enough to start with Java because a radical OO language (and a crappy one at that) with a shitty enterprise API is not the best either.
I'm thinking Pascal. As much as it sucks, it has strict/anal types (it's better to start anal than to start easy-going and botch it), simple yet not messy syntax, simple stdin/stdout input and output to play with (that's all I'll need), and none of the complexity of OO. Yet it sounds so useless. But I don't know of other languages that meet these requirements.
Name:
Anonymous2006-09-18 11:24
>>1
From what you just posted, I seriously doubt you're even old enough to teach anything properly.
Name:
Anonymous2006-09-18 11:41
C
Name:
Anonymous2006-09-18 11:52
Since you're just going to do simple calculations, string manipulation, and possibly file IO, Pascal will do (although so will the other languages you mentioned). Then if the person you're teaching is moderately smart and understands all that within two weeks, you should probably introduce objects to them, and if you picked Pascal you could go with Delphi or Free Pascal. CONCLUSION: It doesn't matter which language you pick, as long as it's not ancient (>>3).
>>5
Yeah, but modern Pascal dialects at least have good built-in string support, which is nice if you don't want to have to mess with objects or memory management yet.
Name:
Anonymous2006-09-18 13:12
Python.
Name:
Anonymous2006-09-18 14:18
Real men use C style strings.
Name:
Anonymous2006-09-18 14:43
>>8
C style strings are utterly braindead. They combine the inconvenience of arrays with the performance characteristics of a linked list.
Name:
Anonymous2006-09-18 15:39
>>9
You combined not having a clue what you're talking about with being a fat ugly virgin.
>>10
Not guilty on both charges, but otherwise a decent burn.
Name:
Anonymous2006-09-18 18:10
C string are retarded though. What is supposed to be so great about them?
Name:
Anonymous2006-09-18 18:31
>>14
They're simple, straightforward and transparent. Furthermore, it's trivial to teach how to write your own string handling functions. It also illustrates how there's very little in C that's "magical" and what you couldn't build for yourself. (varargs is one, primitive types is another, main() is one more, I can't think of any others.) This is very useful in a teaching context, because it lets the students think of strcmp() and the like as just something that someone has already written for them.
It's not like >>1 is going to be teaching complicated data structures beyond, say, the humble doubly-linked list or anything, right?
Name:
Anonymous2006-09-18 19:36
>>15
With C you already have a==b instead of intcmp(a,b), might as well go all the way and get a language with proper string support.
>>14
Needing only a single byte of overhead for strings of any size, I guess. Thirty years ago when you only had 5 bytes of memory this might've seemed like a good idea.
Name:
Anonymous2006-09-18 20:04
C-style (null-terminated) strings are retarded. Many operations on them are O(n), which would be O(1) with Pascal-style strings. Imagine what strcat does in the general case:
* Find length of string A (O(n))
* Find length of string B (O(m))
* Allocate lenA + lenB (depends on allocation scheme)
* Copy string A (O(2n))
* Copy string B (O(2m))
Strings that start with a size byte or int (Pascal-style) reduce the first two to O(1).
Furthermore, null-terminated can't contain anything that might contain nulls, which you'll know is a useless if you've ever operated on binary data. And for the finishing touch, it's a lot easier to overrun the lenght of a null-terminated string (forgot that null? whoops!), leading to stupid flaws and possible security vulnerabilities.
The reason we're stuck with a default string library that's gay like this? The PDP-fucking-11. Awesome 1970s Batman!
Pascal-style strings are simple to implement. All they are is:
typedef struct {
int length;
char *array;
} string;
Or you could use a sane system language that uses them by default, like D, or even C++'s STL.
Name:
Anonymous2006-09-18 22:34
>>17
>The reason we're stuck with a default string library that's gay like this? The PDP-fucking-11.
Yeah. Because there was no way to implement pascal style strings on that machine, amirite? You motherfucking toolbox.
Name:
Anonymous2006-09-19 0:17
>>18
Copying null-terminated strings was faster than Pascal-style on a PDP-11. And thanks to that, we're still stuck with it several decades later.
So I'm >>1. I like the discussion on C strings (BTW: C strings suck, sure they are simple, but they just can't do O(1) operations, come with an ugly standard library, and are ZERO TERMINATED, which means they are NOT BINARY SAFE), but that won't help my student.
I plan on teaching him C (or at least wait for it to get teached to him because it will), and of course he'll learn to deal with them, but right now I'm worried about teaching programming, not a particular language, so I want it simple and purist.
>>2
I'd bet I'm older than you, also working on real software and making more than you do.
>>7
Python is a great language (RUBY IS TOO, WEEABOOS, SO JUST SHUT UP), but perhaps some features of modern languages may bite to people who are learning programming and can't be bothered to deal with classes, exceptions, bound objects, iterators, range objects, etc. yet.
>>8
Real men master C strings, after which they realize how crappy they are and how a waste of time string handling in a low-level language is, so unless they need the best performance, and especially if they're getting paid, they move on to higher level languages equipped with PCRE.
>>9
Uh, no. C strings suck because they can't hold any character, have O(n) strlen and most operations, and come with a crappy standard library to handle them.
>>11
I've considered PHP. It's simple, and has a more common syntax than Pascal or Python. The problem is it's so loosely typed I think it might do bad. I want to differentiate data types before we can introduce variant types, automatic conversion, and why is "" == 0.
>>15
The same could have been done with length-based strings. Actually, I had a great idea, but never bothered to implement it: to have a struct like:
typedef struct {
int size; //Allocated size, increased or decreased logarithmically
int length; //Character size of the string; always <= (size >> 1) - 1
wchar_t chars[]; //Struct hack to hold characters
} string;
then move the pointer so that it actually points to character 0 in chars. This way you keep the array access to characters, but string functions (which should be the only ones to know about this structure) can access size and length, and deallocate/reallocate the block if necessary (base is the address of string.size). You get a O(1) macro for strlen. As an extra utility, the functions always guarantee that the string is terminated by a zero so that, when not using binary strings, read-only C string functions and functions which expect C strings will work.
>>19 Copying null-terminated strings was faster than Pascal-style on a PDP-11. And thanks to that, we're still stuck with it several decades later.
I still can't believe that. It doesn't make sense, unless perhaps if all your strings are "Hello world!" and shorter.
Name:
Anonymous2006-09-19 10:26
right now I'm worried about teaching programming, not a particular language, so I want it simple and purist.
I'm surprised no one has mentioned Scheme yet. Beautiful language, very pure, very simple, no gargantuan, poorly implemented standard lib that you have to learn before you can do anything nontrivial, and yet still very powerful and expressive.
>>23
>no gargantuan, poorly implemented standard lib that you have to learn before you can do anything nontrivial
Translation: you can't do anything with it
Name:
Anonymous2006-09-19 11:23
>>17>>22
Oh I call bull on this shit. All operations on strings are O(n). There's a library called Ropes (that comes with the Böhm GC), which provides for crazy things like an O(1) strcat (since it just makes a string head structure which contains the two other strings in a left-right reference fashion), but even Pascal-style strings require a O(n) strcat. Don't believe it? Copying everything from string A and string B into string R depends on the lengths of string A and string B. Therefore, O(lA+lB), which is O(n); indeed, O(2lA+2lB) would be O(n) as well. Habeeb it.
And before the peanut gallery chimes in about "BUT BUT BUT TWICE AS SLOW!", allow me to introduce you to cache miss latency. On a minty-fresh Intel processor, one L2 cache miss is going to cost you far more (that is to say, ~200 cycles on a 2.4GHz P4 at minimum) than a few redundant strlen()s over strings of lengths typical to an average C program! Profile first, kids. Better yet, use a memory profiler like cachegrind before you scream omg slow. Bestest yet, remember that the best optimization is that which moves a program from a non-working state into a working one!
For what it's worth, no Pascal-like language implementation that I know of uses a rope-like data structure for strings. Ropes are ropes and strings are strings.
All that said, perhaps it would be a passable idea to teach programming with something simple that >>1-san can understand. Like BASIC for instance, or Python -- both of those are wonderful for simple and trivial examples that don't need to grow up into real programs.
Name:
Anonymous2006-09-19 11:40
Oh, and I forgot: O(1) strlen? Precious. How about you pass the length in an auxiliary parameter if that really matters so much? Likewise for buffers that may contain a null byte. '\0' isn't actually a character in most of the encodings in use on systems where the word size is a multiple of 8.
Requiring that a string type be "binary clean" is retarded in any case and speaks of a background where strings are commonly abused to represent arbitrary byte-oriented data, when strings are more properly a container type for _character_ data. (Hint: ASCII and Unicode 0 are the NUL codepoint, which is a control character commonly used as a terminator or invalid character.)
Name:
Anonymous2006-09-19 12:30
>>25,26
Nice job aggressively defending an utterly retarded design decision. You still haven't given any reason not to use length-prefixed strings though.
Name:
Anonymous2006-09-19 12:53
>>25 All operations on strings are O(n)
Oh I call bull on this shit. strlen is O(1). The rest are, of course, at least O(n).
About the cache, how does that affect accessing one dword that's always in the same address (at least as long as you don't resize the string), and not affect reading the whole string till the damned final zero?
Besides, C strings are not just a matter of performance, but functionality. They are not binary safe. Useless for binary data, which is something you're supposed to deal with often in a low-level language such as C. C strings, therefore, fail hard and inflict double damage.
Finally, would you care to explain why, if C strings are so great, every modern language, almost always built on C, offers Pascal-style strings? I can't think of a modern language that goes OMG is that a zero!? End of string lolol.
Name:
Anonymous2006-09-19 14:09
>>27
How about tradition. They've been in use for, oh, longer than like 98% of 4chan's user base has been alive. Also, string operations on zero-terminated strings are a couple of instructions shorter than their length-prefix equivalents (i.e. the test against zero can be folded into the load from memory), which as any embedded system developer will tell you does matter. Plus, length-prefixed strings either limit you to 256/65536 bytes, or you end up wasting one or three bytes most of the time.
>>28
Oh very well. All operations that need to touch the string data proper, or if you prefer, all operations on zero-terminated strings.
The cache bit is to remark about how optimizing for omg one loop over a string is pretty much insignificant on today's processors, where fetching extra data from non-cache storage (or even the L2 cache) can be slower in relation to the processors' core speed than memory used to be in the early nineties. Certainly, grabbing the length value from a negative offset in the string pointer is quick. But let's face it: how many strlen() operations do you actually have that aren't immediately followed by accesses to the string contents?
Binary safety I took a stab at in >>26. Nutshell version: silly pythonist, strings are for characters and buffers are for bytes.
Name:
Anonymous2006-09-19 14:31
>>29
String copy certainly is not a couple of intructions shorter than the length prefix equivalents. You need to do a compare operation on every byte as opposed to straight up copying with memcpy or similar.
Name:
Anonymous2006-09-19 14:55
Null terminated strings still exist BECAUSE IT'S FUCKING IRRELEVANT. YOU TALENT AMPUTATED NON PROGRAMMERS ARE THE ONLY ONES BITCHING ABOUT NON ISSUES LIKE THAT WHILE SMART PEOPLE CARE ABOUT THE STUFF THAT REALLY MATTERS.
IN A SITUATION WHERE THE STANDARD STRING FUNCTIONS REALLY COST SIGNIFICANT PERFORMANCE, THE PROGRAMMER WILL JUST USE SOMETHING ELSE, BECAUSE HE'S USING GOD DAMN C AND NOT SOME SHITTY SCRIPT LANGUAGE WHERE EVERYTHING HAPPENS MAGICALLY AT SOME MAGICAL HIDDEN PLACE INACCESSIBLE FROM YOUR HAPPY UNICORN AND RAINBOWS PROGRAMMING ENVIRONMENT.
NOBODY, I REPEAT NOBODY GIVES THE SLIGHTEST SHIT ABOUT HOW MANY CYCLES IT TAKES TO COPY A COMMAND SOMEBODY JUST ENTERED AT A PROMPT INTO SOME OTHER BUFFER. GET A LIFE YOU HORRIBLE ANIME FAGGOTS.
Hi, OP. Microsoft implemented the string hybrid you describe (where the pointer is to the data but the length is just before it in memory) in their "basic string" - or BSTR - in COM.
Actually there's very little difference between copying a C string and a Pascal string. Think about it - one involves copying bytes until you hit a zero, and the other involves copying a certain number of bytes. That goes for the PDP-11 as well as more modern architectures.
Name:
Anonymous2006-09-19 18:43
>>29 Plus, length-prefixed strings either limit you to 256/65536 bytes, or you end up wasting one or three bytes most of the time.
Lame... Just an int, for 4 GB strings. OMG 4 bytes. Just two characters.
fetching extra data from non-cache storage (or even the L2 cache) can be slower in relation to the processors' core speed than memory used to be in the early nineties
True, but something as hot as a string's length should be in the cache.
Binary safety I took a stab at in >>26.
Still, a good feature to have. Makes implementing stuff such as network protocols easier, interfaces cleaner.
>>31
Lol angry Internet man. BTW, nobody's defending scripting languages (bash, csh, etc.) here.
>>32
Looks good (don't know about string operations though); too bad it's not portable.
Pascal-style involves moving the number of bytes (or words if you want it to go faster) into ecx, then doing a rep movs* (the stos* family is stone-age). This is as fast as you can possibly get.
Null-terminated strings on x86 (and every other modern architecture) involves a comparison per byte (or word if you get fancy). Does this sound faster to you? Because it's a lot slower.
Name:
Anonymous2006-09-19 19:48
Binary safety I took a stab at in >>26.
Okay, as someone who mucked around often with binary data in C, allow me to say a hearty *FUCK YOU*.
Why the fuck should I have to write all this extra gay shit or drag in yet another library when C's standard library should have supported it properly in the first place? So instead of having one set of functions that operate on all data, now we need TWO sets?
You'd make a piss poor SE. Reinvent the wheel much?
Name:
Anonymous2006-09-19 21:17
Erm, here's another overwhelming reason why char* C strings are completely useless today (I don't care about thirty years ago): Unicode. People confusing a byte and a character in 2006 is an utter failure. Of course Pascal strings are just as useless in this respect.
Name:
Anonymous2006-09-19 21:19
>>1
if you're willing to give up anal types (which i'd personally recommend) TCL seems to be a good choice. the syntax is very simple, and a handful of common commands can be learned in minutes, but the language is powerful enough to do pretty much anything he'll likely want to use it for at this point. it can also be run interactively, allowing for instant gratification.
this lets buddy learn the basics of program flow and I/O without having the language itself distract him. once he's figured that out, then you can worry about the boring ugly stuff like data types and null pointers when you teach him C.
Name:
Anonymous2006-09-19 21:49
>>1
My first formal course in programming used OCaml (with no reference to the object-oriented aspect), and that's a pretty good learning language, which, unlike Scheme, has types (a nice way to understand complex data structures) and a standard library that makes it usable in real life as well.
It allows for a mixture of different programming styles that may get somewhat unsavory though, if you teach too many (the same problem Perl can suffer from in the hand of beginning students). So Clean might be a better idea, although you can't call it a popular language.
Name:
Anonymous2006-09-19 22:23
real men learn AMN based languages such as B, where strings are arituary. (or not really defined as such)
But then i'm not sure you cna call it a programming language as such? It models specifications but allows you to go all the way through towards an implementation.
Obviously, i'm not recommending this as a first language.
I begun on Visual Basic (omfg) back when i was 15. I may not be so experienced as you guys, but this language is 'decent' as a starter, provided a few things:
You guide the guy in reguards to programming style. Bad habbits are really easy to pickup early.
Teach him its not THE godly language (as i guess many people who started on xxxx language seem to appraise it?).
I'd recommend VB for the following reasons:
using m$'s IDE, the student can learn a few points about GUI design as well.
Being able to make a GUI will actually encourage a newbie programmer to think before they code. (Most students will visuallise what they want their app to look like, thus they will think of what is presents, thus what data is required, thus what operations etc.etc. teaches refinement and synthesis.)
The language is easy, sequential and has many premade functions he can use.
Being sequential, they'll find programming in it easier. Obviously there are many sequential type languages, indeed every language supports sequential programming. But you do not want to overwhelm the poor kid with OO and what not.
Having premade functions will allow the kid to branch out and 'explore' what he can do. (Oh look, i've made this cool command line notepad thing... maybe if i integrate this with the inbuilt networking protocols i could build me a chat client etc etc) Of course, once the kid gets teh basics down you can ask him to make his own versions of functions.
I guess VB can be loosely typed, but just enforce 'option explicit' and stuff.
And no, im not calling VB a godly language. I much preffer more elegant languages, but the kid has to start somewhere. And why not start off where many have? Theres many guides tutorials etc...
Plus, being able to make a GUI, the kid might take a liking to it. Also introduces him to event driven programming later on.
In first year in uni, they started us off on Haskell. They focused on teaching us the basic principles of programming, and the basics of teaching us how to solve problems programmatically.
Haskell may be obscure, but it certainly does re-enforce certain values.
C is decent for technical minded people, but for beginners? The technicallity of it all may overwhelm him.
Of course, the final decision is actually the kid's.... But remember to consider how experienced he is, how much time he wants to dedicate, and how enthusiastic he is?
An enthusiastic kid wouldnt mind diving straight into C, where as a mildly interested kid, will only be frustrated by C, calling it ancient, archaic and completely useless. (but of course they'll learn its use later on).
After starting the kid off on some language and teaching him the basics, i'd probably try to teach em Java. (*gasp*)
Despite all the haters of Java, its a decent language to teach Object Orientation in. I'd have to say its rather important to instill the concepts of OO early on. So that they have the advantage of being able to solve problems both ways and selecting the right method where appropriate.
I guess if they started on C, they could move on to C++ , but then theres the whole thing where the kid could be lazy and default back to programming in (sequential) C more than using OO principles.
If the kid likes electronics, why not introduce him to a basic FPGA? or an AVR or ARM board afterwards? Tho i doubt many will take a liking to such low level things.
Name:
Anonymous2006-09-20 3:02
Erm, here's another overwhelming reason why char* C strings are completely useless today (I don't care about thirty years ago): Unicode.
There are wider character types that can be used, such as wchar_t, although I'm sure you knew this.
I don't know how this thread went so wrong. We went from "oh try this language here!" to "C sucks chocolate salty balls" >:[
Name:
Anonymous2006-09-20 7:44
>>37
Oh, of course. Note that, even though I was talking about C strings, I believe I was differentiating characters from bytes in my proposal and said the maximum number of characters is (length >> 1) - 1 or something like that, and using wchar_t, too lazy to check. (This is also an approximation, as we're using UTF-16 and not taking surrogate pairs in consideration.)
There's somewhat of a vague implementation of Unicode in C99 with wchar_t and the wcs* series of functions, even if it's so poorly and vaguely defined in the standard it's not too clear what the heck does this do. The C standard is really shitty there; instead of fully adopting and embracing Unicode UTF-16 and including a proper library and Unicode metainformation, they come up with vague "wide characters" and multibyte shit.
>>38-40
Thanks for the useful comments, I'll consider all you mentioned. Except Java :p . As for electronics, I won't get that far, but I sure will attempt to give him a rough idea of how it's all done with logic gates, for example with the logic for a simple 4 bit register.
Name:
Anonymous2006-09-20 11:11
>>30
Do you have a reading impediment there? I think I made myself pretty clear. Some architectures allow you to set condition flags based on the value loaded and its signed comparison with zero. Therefore, one fewer compare given an architecture where you can do shit like this.
Let's have a concrete example, shall we? The Motorola 68000 instruction set architecture, though I can't remember whether MOVE.B sets condition codes or not.
loop:
move.b (a0)+, d0
move.b d0, (a1)+
bne loop
That's a 3-instruction strcpy right there. Copies the terminator, too. Contrast with the length-prefixed form:
This assumes that SUBQ.L sets condition codes too, and there's no reason why it wouldn't; this being the 68k architecture after all, and back then minimizing the instruction count was a big deal. So in this example, the length-prefixed version takes one more instruction per character than the zero-terminated version; that's one third more instructions total. (If the 68k supported memory operands on both sides of MOVE.B, it'd be 2 and 3 instructions respectively.)
Name:
Anonymous2006-09-20 11:12
>>42
Avoiding "technicality" in a programming course is something you most certainly don't want to do. I mean, that's heavy gloves territory right there.
Assuming that the S bit in the LDRB instruction means "set condition codes based on value loaded"; my ARMish is a little rusty.
Name:
Anonymous2006-09-20 11:34
>>36
Oh boo hoo. Your toy language background is obvious from the way you whine, and your failure to remember that there's a whole fucking family of standard routines in C stdlib for moving around blocks of memory. Also known as buffers. Also known as shit that's binary safe. I mean, fuck, people, learn the language you're using for crying out loud!
Oh, and >>31
This should've ended the thread already.
>>51
No, because checking whether the string fits the buffer is O(1) and is therefore always done.
Name:
Anonymous2006-09-20 17:37
>>46
Newsflash: I've been writing software in C for the past decade. But don't let that get in the way of your religion.
I can see what the language's shortcomings are. Only a complete dolt can't see that null-terminated strings are an ugly relic of a bygone era. Only someone who hasn't working with C a great deal thinks it's the greatest thing since sliced bread. It has problems, C-style strings being only one, got that?
What you missed is that there's a whole duplication of functionality going on because of a single corner-case (\0). Is that stupid or what?
Now, we've listed all the reasons why null-terminated strings are stupid. Are you going to come up with a few compelling reasons why they're not, or are you going to childishly call names again?
loop:
move.b (a0)+, (a1)+
dbra d0, loop
But wait! There's more! Since we don't need to check what each character is, we can use a move.l! And we haven't even tried tricks with movem yet! Oh nooooooes!
>>55
This is turning out to be an entertaining thread after all. Perhaps a holy war, even. In the red corner, length-prefixed strings! In the right corner, zero-terminated strings! Match refereed by Haskell strings, where each character is a node in a singly-linked list.
Seriously guys, the only real difference between length-prefixed and zero-terminated is that length-prefixed wastes a byte or three of memory in the common case, and zero-terminated has an O(n) strlen(). There, we happy now?
>>54
Well, if you have a better name for a group of functions that have to do with strings and whose names start with "str", please to be informing us.
Yes, I have. Look up the "REPNE" prefix. It will instruct the following MOVS* instruction to repeat only while it's moving non-zero data. So to do a C-string copy, set ECX to 0xFFFFFFFF, DS:ESI to your source and ES:EDI to your destination, and fire off a REPNE MOVSB.
Name:
Anonymous2006-09-20 19:06
>>53
Well well, status dropping. I've been using C from 1995 onward on a hobby basis (i.e. demo programming and such).
As for your challenge, let's start with the obvious: zero-terminated strings are a nice thing to have, because a pointer to the middle of a zero-terminated string is exactly as good a string as any other. That is to say, O(1) head, tail and drop operations (where "tail" is obviously just "drop 1") though you still need to manage memory on your own. Arbitrary slicing that doesn't collapse to head, tail or drop is still O(n) where n is the length of the slice. Under some circumstances (parsers come to mind), this is not only rather intuitive but also relieves the programmer from having to create and then destroy a slice copy of the string being processed.
Another, just because I'm feeling like it: it's trivially simple to write a routine that takes character data read from a file, replaces all instances of the line feed with a '\0' and stores the appropriate pointers in an array, thus making for a line splitting function which allocates no extra memory for the resulting lines.
I'd rather like to hear what the matching idioms would be, if strings in C were length-prefixed rather than zero-terminated. Both of these examples assume that no garbage collection is being used; I think this is reasonable given that neither C-the-language or C-the-library require nor specify any such thing.
>>57
Oh holy fuck. I forgot just how weird the processor architectures got in the seventies and eighties, when they started making them explicitly for running C programs.
And that'd work for length-prefixed as well, right? Just set ECX to the number of bytes you want to copy and use a REP prefix instead of REPNE?
mov ecx, length
rep movsb
Or get fancy and integer divide the length by four and use a movsd. You probably don't need a movsb on the remainer unless you're not aligning things.
BTW, I do not know of a repne movs. There is a repne scas or repne cmps though, neither which do what we're after. You're free to look at it here on page 404 (434 in the PDF): http://www.intel.com/design/pentium/manuals/24319101.pdf
Name:
Anonymous2006-09-20 19:55
>>58
Hardly status dropping, mate. I was merely making obvious that my background isn't a "toy" language. It's C.
because a pointer to the middle of a zero-terminated string is exactly as good a string as any other.
A valid argument. However, if the language supports length-prefix strings, this doesn't hold. Have a look at how D does it (ignore the C++ bit): http://www.digitalmars.com/d/cppstrings.html
Just because you can do some things nicely doesn't mean it's a good general policy. Hark back to the ever-popular example of goto.
You're right, I fail it at recognising what instructions REPNE can prefix.
Name:
Anonymous2006-09-20 20:30
>>58
line splitting function with length prefixed string would be pretty much the same thing.
struct {
int len;
char *str; }
The struct is how length prefixed string look like. So just pointers to the beginning of the lines with the length of the line is enough. Extra memory being sizeof(int) times number of lines. You can have a pointer to the middle of the string and you can slice in O(1) oh shi-
Name:
Anonymous2006-09-20 20:45
>>64
The only problem with that is C doesn't support it natively. Having a standard external pointer to the middle of a string won't work, because the string isn't null-terminated. How does any function using that external pointer know where the end of the string is?
In order to pull that off in C, you'd need to use the structs and explicitly calculate the lengths when initializing it. The result is either additional cruft everytime you need to initialize a new struct, or more function calls.
D is an example of a language that supports it natively. I really recommend any C types out there look at that link.
>>67
Because string operations are rarely performance bottlenecks.
Name:
Anonymous2006-09-21 13:44
>>64
This is O(1) only for slices that are not written into however, and isn't practical in plain old C for the reasons >>65 gives. For a pristine, fresh runtime, I don't see much of a problem, but you'll want to note that even D puts an implicit zero at the end of char[] -type strings for compatibility with C libraries. (Plus, D is garbage collected and thus not suitable for a number of contexts for which C is.)
>>61
What, D has a string type now? Last I remember, the D people were dead set against doing that, arguing that it was better to check every write through a char[] (combined with static analysis for e.g. loops and such) and fake copy-on-write semantics that way. Anyway, if anything this reinforces my original point, namely that strings are collections of characters rather than collections of arbitrary bytes. This is further driven home by various languages' (excluding Python, apparently) transition to an Unicode encoding, making a bytes-as-characters interpretation tenuous at best and claims that C strings are of bytes rather than characters, even given that the usual C idiom for an unsigned 8-bit quantity is "unsigned char", strange.
Is this sufficient common ground, or would you like to go further? :-)
Name:
Anonymous2006-09-21 15:07
Python. Syntax is easy and it can be used to represent complexity in very simple ways.
Pascal is not a real programming language, it's a "trainer" language. A screwed up version of academic pseudocode.
Name:
Anonymous2006-09-21 15:19
10 REM A SIMPLE CALCULATION PROGRAM
20 PRINT TAB(20) "HI I'M A CALCULATOR."
30 PRINT : PRINT : PRINT
40 PRINT "FIRST NUMBER"
50 INPUT FIRST
60 PRINT
70 PRINT "ADDED TO..."
80 INPUT SECOND
90 RESULT = FIRST + SECOND
100 PRINT : PRINT
110 PRINT "RESULT IS " RESULT
120 END
>>69 (Plus, D is garbage collected and thus not suitable for a number of contexts for which C is.)
Yes, that is true. I wasn't presenting D as an alternative though, but rather providing a real-world example of Pascal-style strings in a C-style language. The fact that D is garbage-collected is (nearly) orthogonal.
Anyway, if anything this reinforces my original point, namely that strings are collections of characters rather than collections of arbitrary bytes.
After thinking this over for a few minutes, I'm inclined to agree. Even so, I don't think using null-termination with any collection of characters is a good idea. For example, some codepoints in various UTF encodings use \x00.
Name:
Anonymous2006-09-22 2:52
C# maybe? You can design a GUI in it, and it has C-like syntax.
I'm being taught Alice in CS105. ;_;
As a hobbiest programmer of more than 16 years I'm irritated to have to jump through the hoops to get a formal education, but looking at that crap makes me think it might be worth letting a student with no experience play with it for a week or two before teaching a more advanced (yet still basic) language.
difference between hobbyist and pro is the pro did made a site for his pa and got paid for it.
Name:
Anonymous2006-09-24 22:26
Ruby is too hard to start out with?
I'm in the same situation as your friend, and my friend who is in your situation is teaching me Ruby, I've only had half a lesson over the phone, but it worked out fine.
Name:
Anonymous2006-09-25 8:51
I guess if you omit the more obscure, abstract features of the language, you could do fine with Ruby or Python. Just make sure you play with the basics before even bothering to look what's a class object or a closure.
Name:
Anonymous2010-03-16 19:51
Why can't we have interesting flamewarsdiscussions like this anymore?
>>90
We do, but they're extra hard to find with all this necrobumping.
Name:
Anonymous2010-03-16 20:54
>>91
I am deeply offended! I slave over a hot anus all day, looking for interesting threads to bump, and you can't even appreciate all the work I do! Why don't you just go back to that whore, Leah Culver?
data structures are nouns, functions are verbs, operands are adjectives.... you get my point.
actually, just switch up to teaching linguistics, and mathematics.
programming languages are just slutty representations of those.
>>40
This, I agree with VB. I also started myself with it, it's the first language I was teached at college and we were clearly told it was the shit tier of the programming world. Most of us there learn good habits at first and we learned a lot from it, then moved to Java/C++/PHP/blah blah and eventually went back to .NET with C#/VB for optimum corporate performance today.
- Soon to be Microsoft certified ENTERPRISE developer
>>117
Now You Just Make Up Acronyms. Its a /frog/ meme.
Name:
Anonymous2010-03-18 18:46
Basic is basic enough
Name:
Anonymous2010-03-19 2:08
To all you assholes who are saying Visual Basic
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Bringing /prog/ back to its people
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy