3 ms·
https://news.ycombinator.com/item?id=35663742 https://news.ycombinator.com/item?id=35663742 DonHopkins 10 months ago | parent | context | favorite | on: PHP Po
by DonHopkins 3y ago
https://news.ycombinator.com/item?id=35663742 https://news.ycombinator.com/item?id=35663742
DonHopkins 10 months ago | parent | context | favorite | on: PHP Popularity: Is it decreasing and what to do ab...
That's exactly Jeff Atwood's point, which I quoted above (and will repeat here):
"From my perspective, the point of all these "PHP is broken" rants is not just to complain, but to help educate and potentially warn off new coders starting new codebases. Some fine, even historic work has been done in PHP despite the madness, unquestionably. But now we need to work together to fix what is broken. The best way to fix the PHP problem at this point is to make the alternatives so outstanding that the choice of the better hammer becomes obvious." -Jeff Atwood
https://blog.codinghorror.com/the-php-singularity/ https://blog.codinghorror.com/the-php-singularity/
Leaning hard into the IDE (or ChatGPT these days) because your language design is flawed is a hella/totally stereotypical "West Coast" thing to do, as described in "Evolution of Lisp", "Worse is Better", and "History of T", and exemplified by Interlisp and Warren Teitelman's "pervasive philosophy of user interface design" and implementation of "DWIM".
https://en.wikipedia.org/wiki/DWIM https://en.wikipedia.org/wiki/DWIM
https://www.techfak.uni-bielefeld.de/~joern/jargon/DWIM.HTML https://www.techfak.uni-bielefeld.de/~joern/jargon/DWIM.HTML
https://escholarship.org/uc/item/6492j904 https://escholarship.org/uc/item/6492j904
If your language isn't terribly designed, then your IDE doesn't have to be such a complex non-deterministic Rube Goldberg machine, papering over the languages flaws, haphazardly guessing about your intent, "yelling at you" all the time about potential foot-guns and misunderstandings.
As you might guess, I'm firmly in the "East Coast" MacLisp / Emacs camp, because that's what I learned to program in the 80's. I can't stand most IDEs (except for the original Lisp Machines, and Emacs of course), especially when they keep popping up hyperactive completion menus that steal the keyboard input focus and spew paragraphs of unexpected boilerplate diarrhea into my buffer whenever I dare to type ahead quickly and hit return.
But my point is that you can have and should demand the best of both coasts, unless you start off with a Shitty West Coast Programming Language or a Shitty East Coast IDE.
(Of course those philosophies are no longer bound to the geographical coasts they're named after, that's just how those papers describe their origin.)
Jeff Atwood's point an my point is that we should demand both well designed programming languages AND well designed IDEs, not make excuses for and paper over the flaws of shitty ones.
There are historic existence proofs, like Lisp Machines and Smalltalk, and we should be able to do much better now, instead of getting stuck in the past with Lisp or PHP.
I mentioned the East/West Coast dichotomy in the discussion about the conversation between Guido, James, Anders and Larry:
https://news.ycombinator.com/item?id=19568860 https://news.ycombinator.com/item?id=19568860
>DonHopkins on April 4, 2019 | parent | context | favorite | on: A Conversation with Language Creators: Guido, Jame...
>Anders Hejlsberg also made the point that types are documentation. Programming language design is user interface design because programmers are programming language users.
>"East Coast" MacLisp tended to solve problems at a linguistic level that you could hack with text editors like Emacs, while "West Cost" Interlisp-D tended to solve the same problems with tooling like WYSIWYG DWIM IDEs.
>But if you start with a well designed linguistically sound language (Perl, PHP and C++ need not apply), then your IDE doesn't need to waste so much of its energy and complexity and coherence on papering over problems and making up for the deficiencies of the programming language design. (Like debugging mish-mashes of C++ templates and macros in header files!)
More discussion of West Coast -vs- East Coast language design:
Evolution of Lisp:
https://redirect.cs.umbc.edu/courses/331/papers/Evolution-of-Lisp.pdf https://redirect.cs.umbc.edu/courses/331/papers/Evolution-of...
Worse is Better:
https://dreamsongs.com/WorseIsBetter.html https://dreamsongs.com/WorseIsBetter.html
History of T:
http://www.paulgraham.com/thist.html?viewfullsite=1 http://www.paulgraham.com/thist.html?viewfullsite=1
The Interlisp Programming Environment
http://www.ics.uci.edu/~andre/ics228s2006/teitelmanmasinter.pdf http://www.ics.uci.edu/~andre/ics228s2006/teitelmanmasinter....
https://news.ycombinator.com/item?id=5966328 https://news.ycombinator.com/item?id=5966328
https://news.ycombinator.com/item?id=5966399 https://news.ycombinator.com/item?id=5966399
>gruseom on June 30, 2013 | parent | context | favorite | on: The Interlisp Programming Environment (1981) [pdf]
>Interlisp was the so-called "west coast" Lisp that emphasized an interactive programming environment and in retrospect looks more like a hybrid between Smalltalk and Lisp than modern Lisp implementations. It was developed at PARC for a while. I don't know if there was cross-pollination between Interlisp and Smalltalk or if the similarity was a zeitgeist thing.
>This article talks about the design values of the system and communicates the flavour of what a Smalltalkish Lisp would have been like.
>As someone who's only read about this, I'd be interested in hearing from people who actually used it.
- shrubble 3y agoDon, have you played around with the Interlisp.org "try Medley in your browser" or the downloadable version? And if so, what did you think of it?
- DonHopkins 3y agoNo, I have't had a chance to check that out. Thanks for the tip!
- kragen 3y agoi hope i get a chance to hear what you think! larry has been putting a lot of work into it since his disability
- anonzzzies 3y agoThese are really nice, I have been playing with them lately. They work really well.
- anthk 3y agoOn programming, I like awk (more gawk because of sockets and nice I/O), and editing with just ed/vis (vis is like vi but with syntax highlighting and Sam's Structural Regexen) and entr to monitor the files at read/write so it spawns a make subprocess. Make, not gmake. Proper guide to simple makefiles git://bitreich.org/english_knight I know awk it's kinda the opposite to MIT/GNU/Emacs/Lisp, but with awka I can compile it nicely into C to do lots of prototypes on math calculations and plots with Gnuplot. This is the Unix philosophy done right, albeit 9front/plan9 takes it further with Acme and I/O to any device as a file and from any language. Emacs and Elisp (and Common Lisp as the 'biggie' language) would be nice if Emacs didn't hang on I/O (hello gnus, back in the day I did tweak a config file so it read slrnpull's Usnet spool so it lasted 5 minutes on parsing and not 45), I'd truly use it, as it has lots of nice modules inline help and discoverability. But with the Unix philosophy first I write down schematics with paper and pen, I protoype stuff with awk (awk does far more than reading lines, with the BEGIN clause you can even write a Tetris without touching a file), and then, awka -> C. People doesn't know, but you can do a lot with just tcc, a full busybox set, gnuplot (no wx, no qt, just X11), and netcat if you don't want to use GNU awk for sockets. Also, call me weird/odd, but a lot could be done with gopher, simple CGI with awk and an sqlite database. I know some -not small at all- book store in Spain using just AS400/DOS terminals to search between a networked array of machines with books ISBN's, availabilty and so on and the bookstore people looked up for books at light speeds. Imagine that today with the ubiquitous Java EE stack, or worse, Electron and bloated VS Code IDE's to generate a very subpar tool.