This looks really cool. The thing that makes me sad is that there are way too many resources on stuff like React and python and not much material on stuff like webgl. I wanna learn webgl!! Where do i go
Here is the Class Central page with reviews:
https://www.classcentral.com/course/udacity-interactive-3d-g...
You can search for other courses on class central, though searching for webgl didn't actually find the Udacity course - had to look at related courses for a no longer available Coursera course listing that searching did find.
Edit: Also, Packt's free ebook of the day is currently Learn Three.js, which is a wrapper around webgl. Only available for the next 9 hours or so. If you don't have a packt subscription, you can only read it in a web browser. https://www.packtpub.com/free-learning
I have been reading the beta version of the books and it's really really good. Highly recommend to anyone looking to up their resume game. Great stuff @gregdoesit
I read the beta and the final copy. Great to see it evolve based on real feedback from hiring managers and job seekers.
I used the advice to spruce up my resume a bit and tailor it to specific employers. But more importantly, it helped me know when I was “done”. I had spent a lot of time making small optimizations without knowing how effective they were. After reading the book, I knew when to stop.
This is an incredible thread. Thank you all for sharing.
For me, a good programmer realizes that "everything is code". Like, sometimes it's easy to think X problem is too hard for me or I don't have enough experience or this bug is unfixable but end of the day, it's all just code. You can change it however you want and if someone else did implemented something before, it's highly likely that you'll be able to do the same. Having a level of distance from the code one writes really helps.
I did some stuff with WebRTC a year ago and it was so hard to find relevant learning materials. The technology is so cool and I can't wait to dig into this book. Thank you for putting this out!
While that's not what I had in mind, in principle yes.
That said, in my experience, trying to use a real programming language's REPL for shell-like things is (at best) almost as bad as trying to write a meaningfully sized program in a shell's language.
I've many times tried to pin down exactly why. I think it's mostly a matter of focus and the various affordances provided by the ecosystem that have in fact been developed over the past however-many years.
I wouldn't be terribly surprised if you've found a niche and setup where it works out great for you - the important things are compositionality and putting what you need close at hand.
Using Windows as example, have a REPL (e.g. Powershell, C#/F# interactive) that interacts with the OS via COM/UWP, DLLs, OLE Automation.
So you can from the confort of your REPL get the text selected in e.g. Excel, and use it as input for a function that was actually imported from a DLL for data conversions, for example.
- The constraints force designers to use the space efficiently. That means less details like borders, shadows or hover effects which is relaxing.
- It has a (relatively) uniform look and feel and automatically uses my system colors through the terminal configuration.
But I don't think every GUI program needs to be TUI. Like, if it's a bad fit for your user base or inconvenient to use or implement for you, it's fine. Do what works best for you, not every app is equal.
(Aside from that, most of my "apps" are just shitty Bash scripts that store data in some ad-hoc plain text or JSON file, break when you look at them the wrong way and are hell to debug but I love it. Do give me a good non-interactive CLI or API if you can!)
I'm not opposed to GUI's, but they should function like Emacs or the Bloomberg terminal: efficient and dense display of information, keybindings, and preferably some way to input commands directly (where each keybinding is bound to command). Unfortunately, GUI apps today are all slow, based on electron, don't have any keybindings, and are designed with the assumption that the user is stupid.
TUIs could be designed in a similar way to GUIs, but the culture around their development is much different. So while TUIs aren't inherently better (and based on their limitations, they should be worse), they almost always are.
> are designed with the assumption that the user is stupid.
Probably because the average user is. I don't mean that offensively, but literally everyone on this site lives in a tech power-user bubble. The average user doesn't care to have a dense display of information, keybindings, and ways to input commands directly. They want an easy to use and nice looking app that does what they want.
They generally are, as each feature adds more work and there's only so much time and money available. While this isn't exclusively the case (some things are universal), the more you work on a feature specifically targeted at power users, the less you work on features targeted towards the general population.
For an app that's specifically meant for and targeting power users, that might be an acceptable choice to make, but if you want to target "people", then you're likely not going to be investing in power user features.
I know right. The same old UNIX crustaceans still want to relive the glory days of 1970 with "Everything should live in the terminal" with the chaos of X11, spending countless time editing their dotfiles or starting silly 'Vim/Emacs is better' wars. That ship has sailed. If not, already sunk.
I found this toy to be very cute. Too bad my friends are not the typical software engineer that can use this. I'll just point them to a native macOS habit tracker on the app store instead. Friendly enough for them and efficient enough unlike the Electron alternatives.
Actual progress rather than re-creating the prehistoric 'good old UNIX days' or turning the users laptops into stove burners with many Electron apps running.
The more I lean into using the terminal and emacs for programming, the more productive I find myself becoming. I can learn one command-line tool and apply it to so many other things by way of the pipe.
In GUI-land, this is hardly ever the case. I can't compose different software together, which is something I do all the time with the shell.
There are certainly some tools that work better as GUIs, but there are also tons and tons that really are great as terminal tools. No, this may not be a very approachable design for the average non-terminal-user, but that doesn't mean we should decry those who will find it useful. It's okay for different people to use different things.
I think I don't agree with the top-level comment in this thread that "everything should live in the terminal", and instead I believe what another response to that comment said: "everything should be exposed to the shell". Being able to compose tools is a huge productivity gain for those of us who care to do it and are used to it.
Hardly ever the case in GUI-land? That doesn't sound right at all. You can do the same kind of piecemeal work with GUIs that you do in the command line. Unless every piece of GUI software you use has a proprietary file format (which isn't unique to GUI software) it's all composable. Photos, videos, text files, etc. are all interoperable.
One contrived but possibly very common workflow for video creators: snip out a piece of a video with one tool, record new video from webcam with another, edit an image with photoshop, create sound effects in sfx util, create/record music with another, import all of the above into video editor and export a composited/rendered out video, do more lossless video compression/reduction with another utility.
These are tools I use all the time throughout the day. There is no simple pipe-like interface that allows me to easily take the output (graphical display) and pass it elsewhere to do something with it. In the terminal, everything shares a universal output system: text.
GUIs are not composable in principle. Sure, there are some workflows where you can do it, but that is not generally the case because they lack this common interface as a standard. CLI tools, on the other hand, have the standard of text output.
Right, my point is that most CLI applications use text as output, versus most GUI applications do not.
Saying "Your point isn't true when there are exceptions" is a lazy argument, honestly. It is overwhelmingly the case that CLI applications use text as output, and my original point was specifically about how I wish this were more often the case with GUI applications — that you could somehow interface with them and compose them in the same way you generally can with CLI applications.
> In GUI-land, this is hardly ever the case. I can't compose different software together, which is something I do all the time with the shell.
Assuming those programs have been written to be usable from the CLI to start with.
Likewise GUI applications can be written to be automated by REPL environments automation, specially if the OS exposes application IPC like COM, DBUS, XPC, Binder, REXX, ....
Also not, Electron apps are Windows HTA revisited, not willing to do the right stuff.
And yes even Microsoft does it, but what to expect when younger teams have the cool ideas to rewrite VS installer with node or use it to drive VS plugins.
Still not every graphical application is Electron based, whereas in what concerns the UNIX terminal hardly anything has changed in 50 years.
I think both GUI and TUI applications have their place. For developers and people who are comfortable with it, a CLI can be really extensible, allowing for every application to be opened or used instantly from the same location, and you can automate series of processes. GUIs have their place too. Some applications are more ergonomic with a GUI. I think the two of them can live in harmony.
Everything a UNIX cli does can be done better in a REPL.
Modern UNIX has the necessary IPC tooling for REPL workflows like on Xerox Workstations REPL, Amiga REXX, Oberon, Powershell/COM/.NET, Inferno, yet the large majority uses it hardly any different from V6.
I would argue that people want a more traditional app instead, with what I'm sure you'd consider a bloated and inefficient GUI. Considering that most people don't even know what a terminal even is, and that form regularly trumps functionality in day-to-day lives.
I don't think the parent comment was speaking for anyone but themselves. They expressed a preference, it was rejected as opposed to "progress". The comment about progress being giving people what they want was a refutation of that - like, "it can't be progress for me if it's not what I want." The fact that other people may want what they've been given is great - for them, progress! but it's also irrelevant to the point being picked at.
Perhaps I'm being overly charitable to the original commenter.
It is not about then terminal, rather using it as if the world hasn't changed since V6 came out.
Ignoring REPL based workflows, structured IPC with GUIs apps for automation, ability to use any library directly, cramping text into a little window in a high definition screen.
Yes, use a language REPL, whatever you do with pipe in UNIX shell, is done via function calls or composing operators like |> in F#, or -> threading macros in Lispy languages.
Then since it is a full programming language REPL, not only you have text, there is also structured data to act upon.
On top of that comes the capability to directly access dynamic link libraries, the libraries of the language being used, and when the OS exposes it, application automation APIs.
So you can do stuff like select an open application, or something inside it, then switch to your REPL and execute some script over that selection.
Basically you open something like Jupyter Notebooks on the OS, and interact in a graphical way with everything that is running, not just executables that can only talk text via stdio.
Some real life examples, were the Xerox PARC workstations (Interlisp-D repl, Smalltalk transcript, Mesa/Cedar devenv), AmigaDOS shell with REXX, OS/2 with REXX as well, Native Oberon with its command modules, and for something more up to date, Powershell with COM/DLL/.NET/OLE Automation/WMI integration, AppleScript / Automator.
In modern UNIX clones something similar could be achieved via DBUS, KParts and a scripting language of your liking, like Python, Ruby whatever, but it remains a niche thing.
