3 ms·

PART I The responses in this thread are off on 'style', 'scene', 'culture', parties, hook ups, buying wine at 2 AM, housing, commuting, employment contracts, e

PART I The responses in this thread are off on 'style', 'scene', 'culture', parties, hook ups, buying wine at 2 AM, housing, commuting, employment contracts, etc. and, thus, avoiding the main issue of the actual post and much more: Look, guys, the main issue is information technology (IT) startups in NYC. Just what is it about that focus that is difficult to keep in mind? Keeping this focus in mind, I continue: A big deal in the article was the difficulty of hiring programmers. Total BS. If you are doing an IT startup, an early prerequisite is that you BE a programmer. What you don't already know about programming, LEARN. Got some problem with learning how to program? Go back to CA and pick lettuce. I taught myself to program and taught computer science in college and graduate school. Teach YOURSELF to program. If you don't, IT entrepreneurship is not one of your more promising career directions. Uh, the current programming tools are so powerful they are quite complicated and fairly new, and a consequence is that you will spend more time learning the tools than using them the first time. Indeed, the big pattern is that the tools change so fast over the decades you may spend more time learning tools than using them. In particular, as a programmer, most of your work is JUST learning tools. Right: In the research universities, the professors don't know these tools. So, as has been the case for decades in the US computer industry, to program, you have to teach yourself, over and over, continually. Uh, PL/I is actually a terrific language, and for some years OS/2 was actually by a wide margin the best PC operating system; so, I've got a nice OS/2 PL/I compiler if you want! The idea of hiring a Wall Street programmer? They have to learn the new stuff, too. Likely they concentrated on one of user interface and graphics, relational data base, computational algorithms, or Web site development. Well, in that case, for an IT startup, they still have more to learn and spend more time learning than doing. Okay, if you are the CEO of an IT startup, then it is your solemn obligation to understand ALL the software. For this you MUST have learned the software tools. Then, once you have learned those tools, for you, by yourself, to use these tools to write the software you need for your startup should be doable, e.g., less work than just the learning and, generally, less work than just communicating with a 'programmer'. So, then you won't need a programmer. So, the supply of 'programmers' in NYC or Silicon Valley is irrelevant. Sorry 'bout that. Or the solution to the 'shortage' is just one more programmer, YOU, so start learning. So, venture partners with minimal current software knowledge (is there any other kind?), this is the day of the IT startup with just one person, the founding CEO who wrote all the software. We know you couldn't do it, but they did, and there are some big advantages. Get used to it. Uh, just because you cook your own breakfast does not make you a Denny's short order cook; just because you drive your own car does not make you a chauffeur; just because you wrote your own software does not make you 'just a programmer'. Uh, now, Visual Basic .NET is an excellent programming language and no longer very 'basic'; .NET already has essentially every subroutine or function of any general usefulness you can think of; ASP.NET is cute and more fun than throwing peanuts in the zoo.

HilbertSpace 16y ago
PART II Uh, my padawan learner, you need a little more, and I will outline some 'principles' that actually have some lasting value: Some major events in programming language design were in the 1950s -- Fortran (arrays, IF statements, and loops), Cobol (hierarchical data structures, IF statements, and loops), Algol (nice source code nesting, name scoping, and call by reference, value, and name, that last one a bit amazing), APL (clever things with arrays and a very sparse syntax -- interpretive), and LISP (a programming language that can examine and change its source code as it runs, with too many parentheses, interpretive). Then, for icing on that cake, the 1960s were the 'golden age' of programming language design. So, there was PL/I (borrowed from Fortran, Cobol, Algol, and a little from assembler; had some exceptional condition handling NICELY connected with storage management and task management) and Algol 68 (oops, I never learned it!). Somewhere in or near there was C, Pascal, Ada, and Simula. 'Object-oriented' programming (OOP)? Given a language with aggregates, e.g., Fortran arrays and/or Cobol data structures, memory pointers, and dynamic memory allocation, the basics of OOP were immediately obvious and commonly reinvented by any programmer who ever hit a keyboard. IBM had it in microcode in the early 1970s. Fortran? It didn't have pointers, but after a few lines of assembler it did! Another way was just to have a COMMON block (that is, an 'external' name, that is, 'resolved' by the linkage editor) with one array and use array addresses as memory pointers. If need a little more for manipulating addresses, then write a few, very short assembler routines. Dynamic memory allocation? Not a lot new there. Actually, for each power of 2, have a root of a chain of pointers for free space of size that power of 2. So, an array of 64 pointers each 64 bits long should be sufficient for a while! Then, roughly, if want some memory of size m where 2^(n - 1) < m <= 2^n, then go to the root for size 2^n and allocate the first block on the chain and correct the chain. If there is no free block of memory on that chain, then for some k > n allocate a block of size 2^k, use that memory to put its blocks of size 2^n on the chain, and allocate one of those. Can also slightly modify this scheme to free the block of size 2^k when it is empty of blocks of size 2^n. The scheme is fast and easy to implement and especially effective on a virtual memory computer where can get a lot of page alignment and where the 'wasted' free space is mostly just disk space. Garbage collection (that is, compress out holes)? Not a lot new: Keep references and then move the memory and update the references. Can have some advantages for long running, complicated, production software but has a well deserved reputation for being slow. So far Microsoft's implementation seems to be at least reasonably fast. 'Collections'? Use AVL trees as in the first edition of Knuth's 'The Art of Computer Programming'. Hashing? Don't miss extensible hashing! C? A toy language written at Bell Labs for word whacking and so small the compiler could run in 8 KB or 5 KB or some such of main memory. It was so lacking in features that the usual fix-ups people did for OOP were eventually provided in a pre-processor called C++.

HilbertSpace 16y ago

PART II Uh, my padawan learner, you need a little more, and I will outline some 'principles' that actually have some lasting value: Some major events in programming language design were in the 1950s -- Fortran (arrays, IF statements, and loops), Cobol (hierarchical data structures, IF statements, and loops), Algol (nice source code nesting, name scoping, and call by reference, value, and name, that last one a bit amazing), APL (clever things with arrays and a very sparse syntax -- interpretive), and LISP (a programming language that can examine and change its source code as it runs, with too many parentheses, interpretive). Then, for icing on that cake, the 1960s were the 'golden age' of programming language design. So, there was PL/I (borrowed from Fortran, Cobol, Algol, and a little from assembler; had some exceptional condition handling NICELY connected with storage management and task management) and Algol 68 (oops, I never learned it!). Somewhere in or near there was C, Pascal, Ada, and Simula. 'Object-oriented' programming (OOP)? Given a language with aggregates, e.g., Fortran arrays and/or Cobol data structures, memory pointers, and dynamic memory allocation, the basics of OOP were immediately obvious and commonly reinvented by any programmer who ever hit a keyboard. IBM had it in microcode in the early 1970s. Fortran? It didn't have pointers, but after a few lines of assembler it did! Another way was just to have a COMMON block (that is, an 'external' name, that is, 'resolved' by the linkage editor) with one array and use array addresses as memory pointers. If need a little more for manipulating addresses, then write a few, very short assembler routines. Dynamic memory allocation? Not a lot new there. Actually, for each power of 2, have a root of a chain of pointers for free space of size that power of 2. So, an array of 64 pointers each 64 bits long should be sufficient for a while! Then, roughly, if want some memory of size m where 2^(n - 1) < m <= 2^n, then go to the root for size 2^n and allocate the first block on the chain and correct the chain. If there is no free block of memory on that chain, then for some k > n allocate a block of size 2^k, use that memory to put its blocks of size 2^n on the chain, and allocate one of those. Can also slightly modify this scheme to free the block of size 2^k when it is empty of blocks of size 2^n. The scheme is fast and easy to implement and especially effective on a virtual memory computer where can get a lot of page alignment and where the 'wasted' free space is mostly just disk space. Garbage collection (that is, compress out holes)? Not a lot new: Keep references and then move the memory and update the references. Can have some advantages for long running, complicated, production software but has a well deserved reputation for being slow. So far Microsoft's implementation seems to be at least reasonably fast. 'Collections'? Use AVL trees as in the first edition of Knuth's 'The Art of Computer Programming'. Hashing? Don't miss extensible hashing! C? A toy language written at Bell Labs for word whacking and so small the compiler could run in 8 KB or 5 KB or some such of main memory. It was so lacking in features that the usual fix-ups people did for OOP were eventually provided in a pre-processor called C++.