CSNYC Presents Paul Ford At Silicon City
Next Thursday night, December 10th, our non-profit CSNYC is hosting a great event at the NY Historical Society. Here’s what’s happening:
TOUR: 6:00pm – 7:00pm
Experience the New-York Historical Society’s new exhibit “Silicon City: Computer History Made in New York.”
TALK: 7:00pm – 8:00pm
Listen to Paul Ford, author of popular Bloomberg Businessweek article What Is Code? discuss true nature of digital talent & how to create it
RECEPTION: 8:00pm – 9:30pm
Celebrate CSNYC’s Founding Partners + supporters and their contribution to bringing computer science education to every child in NYC
This event has been sponsored by Silicon Valley Bank and we are grateful to them for their support.
If you have an interest in the history of NYC’s tech sector and it’s future, please come. You can RSVP here.
Comments (Archived):
Looks like a great event!
That’s it? No pun? 🙂
Maybe he’s got a chip on his shoulder about the name of the exhibit.
Clearly an event of *historical* significance.
Good try, Jim.
Maybe it should be titled “Beads to Bytes”
So, it sounds like “Silicon City” is sticking for NY?
14 City
14?
Names like that are pretty silly. I work at a startup in NY, not Silicon City.
We’re stuck with Silicon Beach but Silicon City is worse.
How are any of them worse than “Silicon Valley” now? The exhibit Silicon City directly relates to early steps in the computer industry…
Silicon City is an exhibit – directly related to this history of transistors – not a new nickname
I was responding to William’s comment about it being a nickname for NY’s startup community, not about the exhibit
why not add ‘Events’ to your header tabs list?
one more thing to manage
I didn’t even realize you had header tabs until now.
then a ‘Calendar’ tab, crowd sourced by trusted citizens of the community.
Paul is a great speaker and incredible writer. This still ranks up there as one of the best reads ever. https://medium.com/message/…Looking forward to hearing him speak.
great read. thanks kirk.
Don’t thank me, thank Paul! 😉
Thanks for reminding me about that article, it’s a classic. @ftrain on Twitter for those who want to keep up with Paul.
I was enjoying that article (thanks) until I came upon this passage (but I do intend to finish it):Here’s a polite person’s trick, one that has never failed me. I will share it with you because I like and respect you, and it is clear to me that you’ll know how to apply it wisely: When you are at a party and are thrust into conversation with someone, see how long you can hold off before talking about what they do for a living. And when that painful lull arrives, be the master of it. I have come to revel in that agonizing first pause, because I know that I can push a conversation through. Just ask the other person what they do, and right after they tell you, say: “Wow. That sounds hard.”Why that advice? Well here is the reason:Because nearly everyone in the world believes their job to be difficult. “Nearly everyone”? I think it’s not actually like that. In many cases people tend to think someone elses job is difficult simply because they don’t know the job, don’t do the job, aren’t comfortable with the job, and therefore it seems difficult. [1] I am not talking about jobs that people underestimate the difficulty (for example many people think being an actor is easy but it’s not, or being a rock star) but other more everyday jobs. If someone told me that what I do “sounds hard” I would think they were patronizing me.[1] I am thinking of Fred who is constantly traveling and meeting with people or even you who spends a great deal of time with your kids or plays musical instruments. To me both of those “jobs” are “difficult”, not easy because they are not things that I feel entirely comfortable with or would find interesting. I could never (and did never) spend a great deal of time with my kids when they were growing up doing kids things was boring to me I hated it [2]. I am guessing though that both of you truly enjoy doing that and it’s not “hard work” in the way we think of “hard work”. And I could never play a musical instrument (but always wanted to).[2] And they turned out to be really good kids and don’t resent it at all. (So there..)
I wouldn’t take everything Paul says literally. His writing is laced with brilliant acerbic wit.And spending time with my 4 and 2 year old is definitely hard work ;p
On my calendar.
are you going to live stream / record it? you should!
Just read the Paul Ford essay. Yup, back in June, also saw the June version, maybe the same as the current version.He’s entertaining, in places nicely insightful, has some good overviews of SmallTalk, Python, Cloture, GitHub, SQLlite, and agile development, and is quite perceptive about some of the social and management issues.In a few places has some gaps:Gap 1: Likely the main reason Python is slow is not Python is usually slower than C; this is the price you pay for all those sweet levels of abstraction. Instead, Python, a.k.a., CPython, is slow because it is interpretive instead of compiled.Microsoft’s IronPython is compiled and likely faster by a factor of several. A ballpark estimate of the speed advantage of compiled versus interpretive is a factor of 10. If have a big server farm busy running Python, a factor of 10 could add up to big bucks.Gap 2: What he says about the programming language C is not so good: C is a simple language, simple like a shotgun that can blow off your foot. It allows you to manage every last part of a computer—the memory, files, a hard drive—which is great if you’re meticulous and dangerous if you’re sloppy. Software made in C is known for being fast. When Not really: He seems to suggest that in C one can take full control of the computer, e.g., as an operating system does. Sure, if the operating system is written in C. Otherwise, nope: If C is used as an applications program, then, except for operating system security holes, C is no more able to take over the computer than any other programming language, including assembler. Means to keep an applications program from taking over the computer go way back in computing.On C being fast, not so much:(A) In many applications, handling character strings is really important, but C has nothing good for that. Instead, for good string handling, C programmers must use a lot of additional code, mostly some tricky subroutine libraries; however such code cannot be very efficient in comparison with a well designed language that has character strings as a built-in, native data type This is a very old story: In string handling, PL/I blew the doors off programming languages with collections of subroutines for string handling. E.g., on IBM mainframes, PL/I was able to exploit the machine instructions for some important string operations — subroutines just in C can’t do that.(B) Now with the Unicode character set, native C is still further behind in handling character strings; again, a well designed language handling Unicode characters strings can be both faster and much easier to use than anything a programmer can do in C.(C) Generally, as a programming language, C is a toy: It was designed at Bell Labs to run on a DEC computer with only 8 KB of main memory with a very simple compiler. Soon the language was seen as so meager in the features it offered programmers that also at Bell Labs the source code preprocessor C++ was developed.(D) Memory management is C, to borrow a word from the essay, just “sucks”. Memory management is a very important subject with no solution with all of general, powerful, fast, and simple. Basically, for complicated production software, the memory management in C, e.g., the functions malloc and free, must be replaced (by more software that then calls malloc and free). Even then, the important issue of garbage collection remains much harder to do than in a well designed language where garbage collection was carefully considered from the beginning.Since C++, at least in its definition, is just a source code pre-processor to C, the same issues apply to C++. Then with the relatively heavy usage of dynamic memory by the object-oriented features of C++, the poor memory management in C++ renders C++ as a serious obstacle for large scale, production, commercial software development.Then, with its objects, C++ brings a lot of indirect indexing that is really slow; a well designed language with good features for aggregates of dissimilar elementary data types, which is most of what the C++ classes are used for, can be much faster.(E) C is short on arithmetic data types, e.g., decimal.(F) The definition of C has nothing on multi-threading.(G) C and C++ are weak on scope of names, an important feature for good modularity in large programming projects.(H) C and C++ have essentially no, that is really poor, means for handling exceptional conditions. Good exceptional condition handling should exploit some good, integrated work in scope of names, multi-threading, and memory management, and here C and C++ are just hopeless.Result: C++ production software has a monster called memory leaks where memory keeps getting allocated but never freed.(I) C has no arrays and, instead, forces programmers to supply their own array indexing code. Instead, a well designed language with arrays as a native data type can be much faster and much easier to use, especially for debugging, than what a programmer can do just in C. Thus, compared with C, even very old Fortran has some really big advantages, including speed, in array handling.(J) C stands to be nothing short of an unanesthetized root canal procedure for accessing a SQL database.(K) C has an admittedly idiosyncratic syntax that in places is a serious puzzle to understand, teach, learn, read, and write.The importance of C?It was designed for really small computers with really simple operating system support for really simple work. So, C can be a good choice for some cases of embedded software, say, for a really old, simple microprocessor for, maybe, a microwave oven, maybe for a low end IP router.Generally, when some software can be written in a reasonably straightforward way in C, the work will be easier than writing the software in assembler. But, really, C is a close to assembler but missing the really big advantages that writing in assembler has.Gap 3: He heavily ignores the Microsoft efforts in C#, the .NET Framework, IIS, and more. He doesn’t mention the .NET version of Visual Basic (VB): For its features, it is nearly equivalent to C#, that is, is mostly just a different flavor of syntactic sugar. But C# borrows heavily from the unfortunate, obscure, deliberately idiosyncratic syntax of C while Visual Basic has traditional programming language syntax easily taught, learned, read, and written by people who know Fortran, the original Basic, PL/I, Pascal, etc.Gap 4: He keeps implying that JavaScript is from a leading candidate to essential for development of both the client-side code in Web pages and the server side code of Web servers/services. Nope: There’s still no law against writing Web pages with just HTML and CSS. Indeed, quite widely, client-side JavaScript has made a total train wreck of many Web sites. E.g., due to poor use of client side JavaScript, the BI Web site has the client processor running at 100% busy constantly, with memory leaks growing virtual memory sizes into the GB range, essentially an infinite loop — really big bummer. Now, due to wildly overactive client side JavaScript, far too many Web sites are next to unusable.For the server side, JavaScript is an interpretive language and, therefore, slow. Also, so that Web pages couldn’t cause user security problems, client side JavaScript was carefully designed to be very limited in what computing it could do. So, some serious server side programming will have to have extensions to JavaScript, and then we are back to a language that is too simple with a huge pile of extensions difficult to fathom.Finally, Ford gives a lot of mention to Silicon Valley, its disruption, and valuable startups, but there he misses the crucial central points: The crucial parts of that work, that is, making billions, is just not the code. The bigger issues are:(A) Who are the millions or billions of users, and what the heck is to be done that they will like a lot?Or, similarly, what the heck are the must have product and/or service for what market?(B) What is especially good about what is to be done for the users?(C) What are the barriers to entry?(D) How the heck to have a project that can get to profitability without tons of losses?For all of (A)-(D), mostly the answer is not code or coding.Or, Ford’s focus on production software for some big company UGE is a bit far from what a startup needs. E.g., while all that stuff about GitHub, branches, automatic testing, and commits is nice, in fact, with a well considered project, one or a few guys can just type code, fairly carefully, into a simple text editor, do the testing that seems appropriate, do a beta test, and go live avoiding most of what Ford describes.
… and right after sigma typed “When”, the C program running the building power plant controller entered an unexpected execution path for the first time in its 22 years of existence. The following instruction incremented a short integer variable holding the array index, making it negative and initiating an unfortunate chain of events leading to sigma lying unconscious, prone over the mat. There were subtle markings on his forehead.. YTREWQ..(to be continued)
This sounds awesome. Makes me wish I was in NYC.
Looking at the history of these entrepreneurial tech centers is a nice contrast to the fixation on newness and the present/future focus that comes with the tech scene.I ended up watching a documentary on Silicon Valley that Amazon “suggested” to me based on what it perceives as my interests. (Good job Amazon) One minute in I was tempted to turn it off because it seemed so dated. We’re talking OLD Silicon Valley. But it turned out to be fascinating and I found myself recognizing something about these guys and appreciating them (they were true pioneers) even though in some ways they seemed foreign to what we now associate with modern tech. Is there really “nothing new under the sun”? (Ecclesiastes)
Hi Fred: Thanks so much for the CSNYC event last night. Paul’s subject matter on what is talent, along with the other speakers comments, gave me lots to think about. And the exhibit is really fun. Love that women are recognized throughout it!