' I talk to a lot of JavaScript devs and I find it really interesting that the ones who spend the most time in Angular tend to not know JavaScript nearly as well. I don't want that to be me or our devs. Why should we write "not JavaScript?" '
You mean like going to the super market without having a shopping list, buying everything that attracts your attention which all goes out of date in your fridge because you forgot you had all that food and not having any time to plan your house hold duties?
Sibling comment to mine thinks you're harsh, but I think you nailed it. I have an Arduino and a Raspberry Pi both just sitting around because I never came up with interesting things to do with them.
I also have a lot of food in the fridge and pantry that's expired or near-expiring because of the promises I made myself at the supermarket that I've totally reneged on.
I think that's overly harsh. It's closer to wanting to learn how to make cocktails, taking advice from a friend on how to stock a basic bar, but not really feeling comfortable enough with the domain to experiment beyond fixed recipes.
That's me when I visited Shenzhen. I came back with close to $1k worth of electronics - boards, controllers, sensors, actuators, stuff. Donated half of this to my local Hackerspace though.
Thank you for spending some of your time here and writing your thoughts.
I would like to ask you for some advice.
The idiom "Everything old is new again" is currently picking up steam, especially in the hardware and software scene.
Amazing stuff is happening but it is being drowned in the mass pursuit of profit for mediocrity in both product and experience.
What would you say to those who are creating wonderful (and mostly educational) machines but finding it difficult to continue due to constraints and demands of modern life?
Most don't have the privilege to work at a modern day Xerox PARC. Then again there is no modern day Xerox PARC.
"The problem I have with PHP has nothing to do with the language, it’s its reputation. I can’t count the times I’ve started a conversation with a programmer who upon finding out I primarily do PHP got awkward with me."
The HN post title is sure helping with the reputation.
Of course, one could phrase the question the opposite way. Many people have, over the years.
> After all these decades, Unix and Linux people are still limited and encumbered by the antique typewriter-mode way of interacting with a computer?
This sword cuts both ways, remember. In many people's minds, the typewriter-oriented way of interacting with computers -- with all of its concomitant problems of multiple incompatible escape code sequence sets, control sequence tearing, terminal mode enquiry from the host end, modal character encodings, modal display, 8-bitness, 7-bitness (!), and of course all of the modem and serial line hoops to jump through -- is something that the world got away from in the 1980s and early 1990s.
The console subsystems in Windows NT, and in OS/2 1.x before it, provided simple manipulation of cursor and attributes without worrying about which escape sequence set to use or without danger of escape sequence tearing. They provided simple enquiry mechanisms for reading characters and attributes back out of the display, and for reading the cursor. There were no worries about "having bit #7 set", or accidentally dropping into "great runes mode". One could use full UCS-2 (this was pre-Unicode 1.1, remember) if one wanted to avoid worrying about code pages. The kernel didn't impose a fixed number of devices or (at least in Windows NT) a low limit on the total number of consoles. The input stream included both keyboard and mouse events in a single machine-readable form, and application softwares didn't have to decode human-readable (sic) protocols for the latter. Keyboard events comprised key press and release information. There were no worries about BPS settings and carrier detect.
All of these were 1980s advances on the state of the art with respect to typewriter-oriented interfaces, and from them in the same decade we got a whole range of TUI programs (even on MS/PC/DR-DOS) whose textual user interfaces did things like incorporate the mouse, draw UI widgets with actual box/line/arrow glyphs, react to modifier keys as they were pressed and released (the most memorable perhaps being a press and release of the [ALT] key activating the menu bar), and save and restore what was displayed "behind" a window/dialogue box. So one should understand the non-Unix non-Linux world's amazement at people who bemoan the lack of systems inferior to even that.
And after that in the 1980s, they will tell you, we gave you the ability to have graphics with the text, multiple fonts, more than 16 colours, a cross-application clipboard, a unified message queue, message passing between different programs, and so forth.
There's another "after all these decades" question that could be shot back, as well.
> After all these decades, it's only in 2011 that the Unix and Linux worlds finally got a workable mouse event protocol for their typewriter user interface? The OS/2 MOU subsystem could handle 16-bit row and column positions, without any of these problems and in the same recognition that consoles were no longer 80 by 25, in 1987!
