I agree with you. And I wonder how the working paradigms and, importantly, the tools, got defined as they are. Not a criticism, but the tools that won. In the younger days of interactive computing, there seemed to be an explosion of creativity on how to manipulate, use and present information, in systems like these and others. Then continents arose (Lotus 123, Excel, Visicalc), (Wordstar, Word, etc), Emacs.. Office quantized a lot of domains, I think. It locked us into tools as the standard of productivity tools and human computer interaction patterns. And, the majority of users use these in their productive use of their time.
This article talks about two main things. Accepting "help" applies more broadly than engineering or software.
And I agree with his overall goals of his project..I believe the same. We get trapped into this bigger and better and more complicated stacks and the hardware resources required, but you can reach a lot of folks with simplicity and the basics.
If you are working more than 40 hours a week on average for a salaried job then the job is either mis-specified, or the person in the job isn't qualified for the job.
It's not clear to me how to build a business based on RPi availability. And the clones don't seem to be really in the game. Are Raspberry Pis becoming more readily available? I don't see that.
This is a great synopsis of the state of things..thanks for posting. Having all this information on one page really helped me grok all the action this year. It really highlights that there is a lot of activity in this space, which is great to see, because CL continues to be my secret weapon! ;)
The synthetic fuels are made from sources such as hay, which, theoretically is a net neutral to the carbon cycle since the hay's carbon came from the atmosphere already. This approach doesn't contribute additional CO2 to the atmosphere like traditional fuels do. However, not sure what the carbon costs are to create this synthetic fuel so that is a variable in the total carbon gain to the system.
Well, this is not necessarily a bad thing. If it was approachable by a non-IT person in HR, and business rules could be updated without contacting IT and waiting, then more power to them. I have seen this sort of thing developed as a coping mechanism because the official IT team could not be used, either due to time, cost, priority, or whatever. Also, even being in IT, 1 multi thousand line file can be a lot more manageable to work in vs. a dozens of smaller files where it's not clear where to look without being in an IDE.
I agree. These types of fines are relatively small potatoes on the earnings that occurred during this time. Having worked for a large US bank for a large portion of my career, everyone is typically trained yearly in an online course that covers records management practices and what to do. I know this because I was accountable for records management practices at the bank. The other question is, what happened internally? How come internal audit didn't catch this back in 2018-2019 time period?
At the end of the day, it's often more profitable, and in the shareholder's best interest to say I am sorry, vs. actually follow policy. At the end of the day, regardless if the C-level knew about it or not, they are accountable. And even if one of the largest banks in the US has to pay a relatively paltry fine like this, the CEO and the management chains that were participatory in this behavior should forgo bonuses. That will change things. Otherwise, this behavior will continue.
Really good article. My first synth, that I had to save up for as a teen, was a DX7. However, wasn't FM synthesis part of the New England Digital's Synclavier system, which was available in the late 70s? Certainly the DX7 was really the first mass-market commercial offering, but I believe the Synclavier was first to market with frequency modulation. I wonder what the arrangement was with John Chowning, if anything, on this.
It can really come down to a business case. What are the chances or risk of a virus or ransomware occurring? And what are the potential costs and challenges of dealing with that? If I can reduce my exposure to information, legal and operational risk, which is hard to directly quantify and yet is ever-present, plus some anticipated reduction in operating expenses, it can start to look good for a large portion of businesses with office operations.
I read the article and the GitHub page, looking for specific examples that characterize their objectives. I believe they are on to something, but without specific illustrations, it is too abstract. Context matters in decisions, and I believe they are trying to say: just don't default to using a framework based on what you know (everything is React or Rails or...) but ask yourself "do I really need this for this project based on scope and maintainability?" Everything has a cost to it in a project and over time, and the bigger picture must be considered.
One itch I think it is trying to scratch is that often times frameworks stand in for a gap between what the core language and standard libraries support and what is required by the application. For example, web delivered applications have shifted from the traditional server rendered web interface, to single page applications. Web apps that act like applications have requirements that browsers out of the box don't support: often you need to have tables that can be sorted and shifted for example. There are not "native" javascript/DOM mechanisms for this. So enter third party code to facilitate. Which to choose from? In desktop applications, this facility is handled by the UI layer running on the OS. The JS/DOM doesn't provide it and so if you need it: roll your own, use a third party app, etc. But that has baggage you may not want: dependencies, potential security risks, and maintainability. So I think, at least in the web area, there is a gap in what people need for SPAs, and what the underlying JS/DOM provides.
I use Common Lisp daily on macOS and Linux, but use SBCL and Emacs with Sly. Never tried out a commercial implementation so I cannot compare to Emacs and SBCL. Are they worth the money vs. the open source tools?
Thank you for this write up. Mostly agree - been using Common Lisp seriously (almost every day as part of my work). At our company almost all NEW back end work is done in Common Lisp as the first choice.
FWIW, in my computing career there have been two crucial pivot points. Exposure to and programming and using Unix (SunOS/HP-UX and later Linux) and its powerful mode of working was the first epiphany. And later Common Lisp, and the degree of freedom it enables in expression of code and ideas, as well as its speed and interactivity model: REPL/SLY, EMACS etc. I have become a much better programmer because of my exposure to this mode of working.
When I was first starting though, my frustration with the language was large, and it was compounded with learning Emacs (which I love and curse at on a daily basis). Libraries seemed poorly and very inadequately documented for someone new to the language, especially compared to Python for example. But the newish culture of hosting open source projects in Github is improving and READMEs/project descriptions are getting better. And, doc strings are in the code themselves, mostly...
Common Lisp gets criticized for not changing. Sometimes it can be a bit verbose (setf (gethash mykey my-hash-table) my-value). A lot of programmers will instantly gravitate to "that's a lot of words to set a value in a hash table". But it really isn't the problem it turns out to be in real life because you learn to read it pretty damn quick, and you save key strokes elsewhere (for example using loop or CLOS). So it balances out. However, I have come to learn that having a rock underneath that has no problem running years old code is a HUGE benefit. Things generally continue to work with the updated compilers and that reduces the cost to maintain the code base. I trust the language to stay solid underneath. You can extend it, but you generally don't need to use reader macros and other features to solve most problems. So while the world is changing around you, you aren't updating your python2 to python3. Instead you can stay focused on app level changes.
I believe I have noticed this as well with Ruby as well. All Gems work great, then, after a brew operation, I need to reinstall/rebuild against an updated Ruby. It's certainly frustrating and can bite you, especially since it is unexpected.
Does System76 make a laptop with a high dpi screen? It seems that is table stakes these days...Seems like this is a pretty expensive laptop (portable desktop), but perhaps for gaming it's not a big deal. However, if you are programming or doing some other text intensive activity the low-dpi screens would be deal breaker.
Our experience as well. We run a stack that comprises Python, Javascript via Node, Common Lisp and Ruby/Rails. It's been completely transparent to the application code itself.
I think the bigger story here is that computing based on ARM64 has been, and continues to, surround the traditional x86-64 territory. ARM dominates phones, and is popping up in server environments as well, where it is cheaper to run for many workloads than X86-64. We have migrated to ARM based Gravitron processors to deliver our services at my company, and we have been able to reduce our AWS EC2 costs by 40% or so, with almost the same performance. The M1 based Macs certainly show the potential on the desktop. Other vendors will produce better, more competitive desktop power level chips, too, that are completely adequate for desktop computing experiences.
We are seeing the classic Innovator's Dilemma pattern whereby the lesser technology slowly overtakes the more brittle incumbent tech. x86 did the same with minicomputers, and then mainframe type workloads.