The geographic aspect of russian agents being in vincinity of the traintracks. Week before supply trains in Germany also derailed, as they do once per month.
I'm not saying it couldn't have been the Russians, but it would be strange for them to target Spain, since it's the only NATO country that doesn't want to increase its defence spending.
Not that one actually has anything to do with the other, but I'd rather have useful functionality than meaningless aesthetic crap that I'd never notice if I wasn't examining the pixels with a magnifying glass.
Glamorous toolkit has always looked interesting to me, but feels a bit unapproachable. It just feels so foreign between smalltalk and a whole sort of philosophy that goes with it.
For those with more experience, is it still relevant? Can the same be accomplished with python and jupyter notebooks?
Yes, still relevant. The same can be accomplished with other tools, but it will probably be more difficult.
The idea of Glamorous Toolkit is that it’s a collection of tools you use to solve software problems by making little explanatory tools. You might start out with some bigger problem like “I need to make this service fast”, come up with a question like “what does the flow of data I care about look like through the service?” and then try to answer that question by making tools that could analyze/visualize logging output or a stack trace or whatever makes sense in your software’s context.
The technique of “making little tools that explain to help answer a question” is Moldable Development, similar to how Test Driven Development is “make a failing big feature test loop, write little tests and make them pass until the big one passes”.
You can make little tools to explain away questions you have while you’re working with plugins or shell scripts or whatever you’re comfortable with and that’s “Moldable Development”. The Glamorous Toolkit just happens to be a nice system of tools that make it easy to make more little tools to help explain away problems.
Hope that helps! Lmk if you want to see some examples.
Source and bias: I worked closely with the developers before I had to take a break from work and computer stuff.
What a great idea. I believe in this a trillion percent, due to the personal experience of watching myself and a stronger developer tackle similar problems at the same time. I relied on my brain and the standard tools of my system. He of course did the same, but also made a custom visualizer for the core of the algorithm. Night and day improvement!
So I'm a believer in the principles. But I'm also curious about throwaway743950's question. What are the things in the Glamorous Toolkit that concretely make it better for this style of programming than traditional tools? You say "[it] just happens to be a nice system of tools that make it easy to make more little tools", but that's got to be downplaying it. Switching environments is an agonizingly costly thing to do. What rewards await those who make the jump? Rubies? Emeralds? Custom views-with-nested-sub-custom-views? Curious (but not yet won over) readers want to know.
I would add one thing that makes GT very different from other tools and is very hard to recreate, is that these tools are ACTUAL objects and the things you see, are also ACTUAl objects, and not just a dummy representation of them as you see in other dataviz tools like plotting libraries or shell scripts.
This means your tools and visualizations are just a specific context-specific view of your objects. Meaning you aren't limited in how these tools can interact with said objects, because you are never working with static data, it's always with the actual objects.
It's hard to put into words, but it's similar to the difference between println debugging and a lisp repl or smalltalk debugger. They technically do the same thing but the actual implementation of them makes a world of difference.
Actually it wouldn't be difficult to add similar view protocols to Python objects as well (I used GT extensively a couple years ago). Pretty much everything is possible, but the live debugger and driller would be really difficult to replicate, which is where GT really shines for me. Alas it was just too much to properly bridge it with Python, where the majority of my work lies, and GT becomes overwhelmed when passed a fraction of data Python handles with ease.
Simple views sure, but tools like the driller or debugger are great examples of what I'm trying to highlight about when I say having the views work over actual objects is really important.
Because if it wasn't for the fact the graphical stack was implemented as smalltalk objects, you couldn't build tools like the driller or debugger since they would have to be implemented as a secondary piece of software that loses the original context.
Like for example, I built a custom tool for myself when I was working on this p2p network and had a section of the codebase with some non obvious control flow, since it was handling multiple different p2p networks at the same time. Normally this is where you include a diagram in the docs, but in about an hour I built a custom code editor for the class, that visualized all the control flow and explained the cases in a flow diagram by simply introspecting on the methods defined in the class. And this tool never fell out of sync like a static diagram, since it wasn't hardcoded by me. And from that point on, I worked within this tool whenever hanlding anything related to this.
And fwiw, the python story is pretty seamless from my usage of it a few months ago. I was able to integrate and use python libraries into this project without much hassle.
Over the last couple of years we added a reasonably extensive infrastructure for working with Python from within GT. You can define contextual inspector views both in GT and in Python for live Python objects, for example. There is also a debugger for Python.
Also, GT is now also a distributed Smalltalk system, too. We use it in productive settings to compute large jobs on large data sets :)
I think moldable development needs a few tutorials demonstrating concrete use cases. Without those it feels promising in the abstract, but I doubt many developers are able to connect with it and figure out how to actually use it.
It feels so open ended that I wouldn’t know where to start. And I’ve actually spent several hours exploring Glamorous Toolkit!
Thank you for the interest and for taking the time to explore the environment!
There are quite a number of videos and explanations now, but we are still struggling to package them in a way that seems more approachable.
We would need help with this. If you are interested, I would offer to have a session with you that we record and in which we go through your questions and I provide live explanations. Join us on Discord and we take it from there: https://discord.gg/FTJr9gP
> and then try to answer that question by making tools that could analyze/visualize logging output or a stack trace
We already have industry standards for doing this. Why would I want to build some micro-tool/throw-away code to do what another tool does much better and battle tested?
That's the pitch but it does not seem the reality. It seems like the exact opposite of unix philosophy, one tool to rule them all, rather than doing one thing really well.
I can achieve the same with unix philosophy, using the tools and languages I already know.
Indeed, it is possible to build tools elsewhere. The question is: do you build them, and if yes, when?
What we show with GT is that it is possible to build such tools for every development problem. This leads to thousands of micro tools per system that should co-exist.
GT is not a large tool to rule them all. In the Unix analogy, it is Unix, not one of the tools :).
This still leaves the question of why would want to build those tools when there are standard tools already? Because systems are highly contextual. This means we can predict classes of problems but not specific ones, which then means that any clicking tool built before the problem is known will not be addressing the specificity of that problem.
This is actually not that new of an idea. Testing is already done like that. We do not download tests from the web and run them on our system. We develop them as part of development after we know the problem. It's that contextualization that makes us stop every time a single test fails as we know that each of them captures something that our system specifically cares about.
Now, a test is a tool. We can extend the same idea to any other tool.
I think you believe we all struggle with your framed problem and your tool is some panacea. In reality, every tool and process has its limitations and rough edges, including yours as you've hopefully gleaned in comments here.
Being married to a specific tool like GT is limiting. GT doesn't work with most industry languages _today_, even though _in theory_ it could. It's written and scripted in a language few use, which makes it unapproachable
I definitely do not want people to marry to tools. That does not sound like a good idea not even if the tool is glamorous :).
More seriously, thank you for sparring with me.
GT is free and open-source. It's extensive. It comes with documentation, too. We even document the practices and the process, too. With public case studies. With peered reviewed publications. And we even bet our own livelihood that it works for tackling hard problems in significant systems that others cannot tackle.
So, yes, we are not just claiming that the problem exists. We have seen it validated first-hand over a large period of time (15+ years) so we are reporting on it :).
This experience points to the idea that decreasing the cost of creating a tool is much more important than the tools that exist out of the box.
Regarding the support for other languages, it's true that we only have analysis support for a couple of dozen languages. But creating the support for a new one is often measured in days. For example, it took a couple of weeks to add COBOL to the set. I challenge you to find even one properly working open-source parser (we looked and could not really found one). In GT you can find a whole free and open-source infrastructure :).
GT is certainly not a panacea. It's a documentation of how the approach can work. I am not aware of any other environment in which tools can be built in minutes and in which thousands of them practically co-exists. If this appeals to people, and it does appeal to some, now they have a vehicle to practice with. And for those that choose to not do that, that's Ok as well :).
I've played with GT and even pull it out every once in a while for small tasks, though I haven't in about 6 months.
I think the idea is good, but it's a tough sell for working programmers because the whole culture of it is so foreign. I think there's a version of GT that would do well if it described itself in terms of paradigms working coders know (POSIX, IDEs, blub-y languages, text files) instead of in terms of SmallTalk. Maybe something nearly as cool can be done as a VSCode plugin? I personally think of it as kind of a supercharged Emacs for SmallTalkers.
The first goal was to help us explore how far can the idea of contextual tools go. It helped discover what today we call Moldable Development. It is also the first extensive case study of Moldable Development, itself offering 5+K contextual tools that we used to develop the environment itself. And when we work on a system, we build thousands more.
That said, now that we know what Moldable Development is, it can be copied. We want people to copy it. Our worry though is that we want people to copy everything, not only the visible parts.
For example, I understand the Emacs parallel. But think of this: while Emacs can be extended, how many extensions do you actually use that are specific to your system? We literally use thousands. Per system. That quantitative difference leads to a qualitative difference and it's made possible because of the totality of the environment.
Moldable Development is not specific to Smalltalk. We already show how it works for other languages. Some ideas are already inspiring other environments, like Clerk.
In the meantime, consider GT as an extensive blueprint of what's possible. If there is one thing we learnt is that the technology is the smallest investment. The real investment is in learning how to exploit the idea of contextual tools for solving hard problems. That's what takes the longest, but the difference to how those problems are approached today can be measured in orders of magnitude.
I'm thinking a market correction, like when the dotcom bubble burst and a lot of value disapeared from the stock market overnight. This is really not a good thing, and almost definitely would affect the IT industry as a whole.
There may also be engineers working harder because of being worried about getting laid off. How could they separate those productivity increases from AI?
Don't you get the majority of that with buying movies from Apple? You can get 4K and Dolby Atmos. If there's DRM anyway, it seems like the difference isn't worth it.
I agree with the problems. I'm a bit uninformed, but in theory ending privatization isn't the only option, right? Hasn't there been problems with corruption in centralized healthcare as well? It seems like regulation could be an option (though I know that it has its own trade-offs as well).
Also, healthcare isn't the only industry suffering this pain though obviously a very important one.
Also, there's a question of how much of this is a cultural problem. How has this sort of thing been addressed in the past? Is the same solution even possible now with the power imbalance created with the current state of capitalism and technology?
Yes. In the UK the state gets to make the life/death decisions, even if you want to fight for your life they can decide you’re a lost cause and too expensive. There’s no perfect solution here, as one is nihilistic & utilitarian and the other is expensive and rife with greed
regulation is what caused this nonsense. there's no reason for our medical care to be inaccessible for most people in the US. it's sort of like kidnapping or enslaving the entire population who isn't rich.
> there's no reason for our medical care to be inaccessible for most people in the US.
A limited number of physicians, especially general practices? High cost therapies and treatments? Capital-intensive diagnostic devices? Lack of access outside of cities?
There are certainly a lot of things that could be done better, but this isn't 1950 -- some available medical technology is incredibly expensive.
Simply unshackling Medicare/aid and allowing it more freedom to negotiate costs would go a long way towards reducing US health care expenditures.
There's a big difference between training, staffing, and funding free health care when we're talking about a doctor's bag and penicillin vs MRIs and monoclonal antibodies.
> every single other country has free healthcare, lower costs, and better outcomes than USA.
Aside from those first two being mutually exclusive, no, they don't all.
There are a large variety of funding methods, ultimate out of pocket costs, and outcomes throughout the world.
The US is certainly an outlier based on {total spent of healthcare}:{health outcomes}, but it's generally in the middle of the pack in terms of GDP-adjusted out-of-pocket costs. (Mostly as a consequence of private insurance + Medicare/aid)
It's easiest if you sort by decreasing coverage, then look at all the 100% coverage countries, which tend to be developed.
To summarize though, aside from single payer, mandatory public-private hybrid and private are also used.
And you should look into the numbers before making absolute statements.
The facts, in contrast to how you stated it:
- The US spends more per capita on healthcare than many (all?) other countries
- Of that, an average amount is out of pocket (relative to developed country peers)
- The US has some poor metrics, particularly in maternal mortality and lifestyle diseases, but is average on others (relative to developed country peers)
- Because of EMTALA [0], all Americans within range of a hospital (that accepts Medicaid) have access to emergency care, whether or not they're insured. The primary problem with access is the scarcity of rural doctors, especially generalists (an AMA/federal-government problem because of limits put in place in the 80s)
